Eggfinder Map tracks

[ksaves2]

Ok, Here are some EggFinder "live" map tracks on some rocket flights using a hacked ham radio
app APRSIS 32 on a tablet. Did screen snapshots.



This was with a Rocketry Warehouse 38 Special that went about 4800 feet predicted on
an H220. Double click to blowup. The numbers are supposed to be the AGL GPS altitude
from the SirfIV GPS chipset on the EggFinder. I believe the numbers aren't the greatest as far as accuracy is concerned but serves so I can describe the datapoints. Where ROCKET and Base are seen is the endpoint. The 807 is the launchpad. Wind was blowing from the WSW towards the east. I had the rail pointing east just a bit thinking it would "cock" into the wind.
Well I put too much downwind tilt and it tore off with the wind towards the east.
The 820 datapoint doesn't seem far enough but nonetheless, the winds aloft were different.
Rocket blew back to the 1411 data point on the west side and as it got lower blew back to the east.

The rockets resting place was at the 1023 datapoint. I had my map zoomed out too far and
couldn't locate the rocket. Frustrating. The black line is my recovery track and you can see I wandered around for awhile. Zoomed in the map and went right to it after I figured it out.

Those little red breadcrumbs are only laid down when the position is moving slowly and I'll need to see what can be done about that.

Next one:



Punisher Sport on an H250 predicted to 3800'. Started to weathercock but blew way the heck
towards the east. Can readily see where the pad was at datapoint 795. That's were it was for the flight I detailed above. Black line is the tablet tracker painting my track on the map to get to the rocket at 782,

I used a patch antenna for the above two flights.



Next one with "duck" antennas or small screw on vertical dipoles to an SMA connector:



This is the Punisher Sport with an H238 at the last Midwest Power. Predicted altitude was a
little over 2200 feet. Please note all these reports are predicted as they are "tracker dog rockets" running on motor ejection and the Jolly Logic Chute Release for "pseudo" dual deploy.
The weather was great at the last MWP. Wished I got a room and stayed the whole time.
Pad was at 731 rocket went west and then drifted back to the road. You can see the black line on the map of me walking out to get the rocket. The end of the line is where the rocket lay. Was easy as the flight was generally within sight but good practice.

The breadcrumbs and the icons are the walk back to my SUV/prep site.



This last one was of a Formula 54 with an H250 at MWP. Predicted altitude 3800'.
Pad was at 739 and I erased a bunch of the black line tracks to simplify the screen save
when I did the recovery.
I could have sworn the rocket went more to the west but I did get a visual at datapoint
1042. I walked a bit out, erased myself and completed the recovery. The final screensave
is me at the rocket and I didn't record the walk in.

The bottom line is the Eggfinder will find your rocket. It's not for GPS altitude telemetry.
Finding it is the big deal. The SirfIV is highly accurate for position as long as it's not
in a high speed dynamic state. With the 100mW output of the EggFinder, a patch antenna
improved plotting but to simply find a sport rocket, it's not necessary.

This is good news and confirms the already good results others are having by simply typing in the last known coordinates to a handheld mapping GPS device and proceeding to that position. With sport rockets, one will likely get within the ground footprint of the EggFinder and get a new position if the rocket isn't already seen by then with stock
antennas. Higher gain antenna solutions will extend the range a bit.

I am aware of a report that a person flew an EggFinder in a high altitude balloon and with the
lazy speeds of a drifting balloon, had adequate position reports. The altitudes were reported pretty good too though I believe the dynamics of a high speed, rapidly tumbling rocket outstrips the ability of the Sirf IV chipset to give an altitude reading that can be considered accurate.

Hmmmm, I have two "broken" v1 EggFinders I "repaired" with the generally considered, better for flying Ublox GPS chipsets....... Maybe I need to fly those next and perhaps do some comprehensive flying with GPS Rocket Locator on my Android device..... The maps are
nicer on GPSRL. Enough for now. Kurt Savegnago

 

[kevinkal]

I've had a number of flights with my Eggfinder Tx and only one of them had great position reporting for most of the flight. Generally, the position data will become bogus immediately after launch and remain bogus during ascent and rapid decent under drogue. However, shortly after the main chute opens and the descent rate slows down, the Eggfinder position data finally looks valid. I don't know why, but on one single flight the Eggfinder gave good data close to Apogee and all the way down to the ground. Here's some screenshots of Mapsphere that show the typical performance I've seen and then the one flight that had the best performace:

Typical Performace that I've seen thus far: Bad data after launch, bad data during boost and coast to 6,427' AGL, and bad data during rapid decent under drogue. Good postion (latitude and longitude) data only after the main chute opens for the last 30 seconds of the flight. Altitude data was bad for the whole fight. (Eggfinder Tx).



And here was the best data flight I've had so far after about 8 flights with the Eggfinder Tx: I had to remove one single outlier data point to make this nice plot. It seemed to only loose data during boost and coast to apogee, but quickly regained good position AND altitude data near Apogee at 4,750' AGL. (Eggfinder Tx).


I've just completed an Eggfinder TRS and hope to get better altitude data from this unit if nothing else. I may have it integrated for a flight this weekend.

 

[cerving]

A lot of it has to do with how many satellites you had, and the position of the antenna. Keeping a good fix during boost is a bit of a crapshoot, but you'll almost always get it after apogee. If you fly at a site with a good 360 degree view of the horizon then you'll get better performance; at Lucerne Valley I can usually keep the fix through nearly an entire flight.

 

[ksaves2]

The TRS of course will transmit the baro altitude to the LCD receiver. Any B/T positions that get sent to an outboard device display the GPS altitude which is
MSL (Mean Sea Level) or altitude above sea level. I've noted some decent reports during my single TRS flight to near 9,000'. That was with
GPS Rocket Locator last year but it couldn't cache maps at that time. I used the bare screen. I was still able to find the rocket nicely that landed
1.66 miles away completely sight unseen with a stock screwon SMA duck antenna.

The other unknown (so far) is the ability of the tracking software to keep pace with packet plotting. I noted on that first flight reported above, the EF LCD
was beeping a reception but I didn't see a datapoint on the map with every beep. APRSIS32 last I checked didn't have an easy logging command so I couldn't look at the received sentences. I will post that question on that group and see if that has changed.

Nonetheless, the EF will find rockets easily and I am very satisfied with that. Kurt

Kurt

 

[kevinkal]

The other unknown (so far) is the ability of the tracking software to keep pace with packet plotting. I noted on that first flight reported above, the EF LCD
was beeping a reception but I didn't see a datapoint on the map with every beep. APRSIS32 last I checked didn't have an easy logging command so I couldn't look at the received sentences. I will post that question on that group and see if that has changed.

Nonetheless, the EF will find rockets easily and I am very satisfied with that.
Kurt

That's a good point. I have been noticing that Mapsphere seems to have a discrete level at which it does not update the position if the reported position is sufficiently close to the point already plotted. But once things are moving (not too fast) the position will update nicely. I looked to see if there was a position difference threshold setting in Mapsphere, but I could not find any in the menu options.

 

[ksaves2]

That's a good point. I have been noticing that Mapsphere seems to have a discrete level at which it does not update the position if the reported position is sufficiently close to the point already plotted. But once things are moving (not too fast) the position will update nicely. I looked to see if there was a position difference threshold setting in Mapsphere, but I could not find any in the menu options.

The only problem with Mapsphere is it's a pain to lift the lat/long out of the log if depending on it to track plus it only keeps track of the rocket.
It won't keep track of the local position so it's useless to navigate.

That makes it o.k. only for getting a record of the flight which if fine if that is what one wants. Yes one can now get the lat/long off the LCD screen but I
prefer to just go after the rocket as soon as possible so I can get back and fly another rocket. Especially useful if one can't get to fly as often as they like. Kurt

 

[kevinkal]

I had a nice flight to a little over 7,300 ft last weekend, and finally got a good test for the EggfinderTx to EggfinderRx and Maphsphere. The winds were light on the ground, but there was a wind shear about 2,000 ft AGL with roughly 20+ mph winds that carried my rocket away quickly even under the 60 ft/sec descent rate drogue. I also had my Eggfinder LCD running and was monitoring it during the flight also.

The 2D position data, Latitude and Longitude, was pretty good for the whole flight! However the altitude data was terrible. The altitude data didn't start to show a climb until the latter part of the flight when it showed a gradual climb to ~2000 feet, then a gradual decent to ~400 ft. I'm looking forward to seeing how well my new TRS unit does given the baro altitude feature.

Here's a screen shot from Mapsphere. No problems receiving data out to 0.7 miles until the rocket dropped below a shallow hill out of sight. When I walked to the rocket, my eggfinder LCD would pick up position information when I was on top of each small hill between the rocket and I. Finally, when I was close, the Eggfinder LCD was continuously beeping 1 second interval updates... assuring me that I was close. The rocket landed perhaps 50 to 100 yards away from the last reported position that I received at launch before the rocket dropped out of line-of-sight.

 

[ksaves2]

Not so good for altitude telemetry but perfectly good for finding rockets. The TRS gives a better indication in that regard. The baro altitude is embedded in the NMEA sentences
so logging them would be possible. GPS Rocket Locator would work.

If one needs a record of flight track and altitude, they would best be served by a system with onboard recording memory. If one just wants to have a better chance of finding
sight unseen rockets, especially a sport flier, the EF's fit the bill economically. Kurt

 

[kevinkal]

I suppose I want to get the most out of everything. I have on my to-do list to merge my altimeter's baro alt with the Eggfinder's position. Not sure when/if I'll ever find the time to do that this holiday season.
When I get around to mounting my TRS in the nosecone, I'll look forward to the deployment status information on the LCD as well.

I'm debating whether or not to use the TRS as one of the two redundant deployment altimeters in the standard altimeter bay of my next project. (Madcow 4" FG Frenzy XL) The bay will have 2 steel all-threads running though it... so I'd need to solder in an SMA connector and locate a 900 Mhz antenna somewhere. I also wonder if the TRS' GPS reception would be negatively impacted with the TRS sitting in the Av Bay next to 3 batteries, 1 other altimeter, 1 raspberry Pi zero, redundant charge wiring and the two all-threads. Seems I should just stick the stock TRS in the nosecone and not use the deployment capability. What do you think?

 

[cerving]

I had a nice flight to a little over 7,300 ft last weekend, and finally got a good test for the EggfinderTx to EggfinderRx and Maphsphere. The winds were light on the ground, but there was a wind shear about 2,000 ft AGL with roughly 20+ mph winds that carried my rocket away quickly even under the 60 ft/sec descent rate drogue. I also had my Eggfinder LCD running and was monitoring it during the flight also.

The 2D position data, Latitude and Longitude, was pretty good for the whole flight! However the altitude data was terrible. The altitude data didn't start to show a climb until the latter part of the flight when it showed a gradual climb to ~2000 feet, then a gradual decent to ~400 ft. I'm looking forward to seeing how well my new TRS unit does given the baro altitude feature.

Here's a screen shot from Mapsphere. No problems receiving data out to 0.7 miles until the rocket dropped below a shallow hill out of sight. When I walked to the rocket, my eggfinder LCD would pick up position information when I was on top of each small hill between the rocket and I. Finally, when I was close, the Eggfinder LCD was continuously beeping 1 second interval updates... assuring me that I was close. The rocket landed perhaps 50 to 100 yards away from the last reported position that I received at launch before the rocket dropped out of line-of-sight.

View attachment 307049

I've thought about having the LCD receiver optionally inject the baro's altitude data into the NMEA data stream. That would probably help the 3D tracking. I might do that in a future Eggfinder LCD software build; I have a few features in mind for next year. There's a lot of space left in the flash, so I can do a lot of playing around.

 

[kevinkal]

I've thought about having the LCD receiver optionally inject the baro's altitude data into the NMEA data stream. That would probably help the 3D tracking. I might do that in a future Eggfinder LCD software build; I have a few features in mind for next year. There's a lot of space left in the flash, so I can do a lot of playing around.

Chris,
Thank you for all that you've done for rocketry.. your products are both fun to build, work great and provide that extra sense of satisfaction to use. Adding the Baro into the NMEA data stream sounds like a great idea.

 

[SpaceManMat]

If any of you are interested in merging / recombining egg finder data I've done that for a number of different file types.

Follow my posts here
https://www.rocketryforum.com/showt...re-In-flight-Position-and-Altitude-Peformance

Happy to give new file types / combinations a shot.

 

[ksaves2]

I suppose I want to get the most out of everything. I have on my to-do list to merge my altimeter's baro alt with the Eggfinder's position. Not sure when/if I'll ever find the time to do that this holiday season.
When I get around to mounting my TRS in the nosecone, I'll look forward to the deployment status information on the LCD as well.

I'm debating whether or not to use the TRS as one of the two redundant deployment altimeters in the standard altimeter bay of my next project. (Madcow 4" FG Frenzy XL) The bay will have 2 steel all-threads running though it... so I'd need to solder in an SMA connector and locate a 900 Mhz antenna somewhere. I also wonder if the TRS' GPS reception would be negatively impacted with the TRS sitting in the Av Bay next to 3 batteries, 1 other altimeter, 1 raspberry Pi zero, redundant charge wiring and the two all-threads. Seems I should just stick the stock TRS in the nosecone and not use the deployment capability. What do you think?

I think your efforts would best be applied to a system where the device has onboard logging that can be downloaded after a flight. Trying to deal with the vagaries of Rf reception at this level of economy would be difficult.

The Missileworks device has onboard logging as does the offerings from Beeline. One can choose the interval that the positions are logged to memory at 1/sec if one was so inclined. The APRS trackers can really reliably only get a tracking packet out to Rf once every 5 seconds and even then, one's receive station may fail to decode the position due to the vagaries of propagation, distance, power output of the tracker, the efficiency of the receiver antenna and the polarity of the transmitted signal. A better strategy if one wants to pair altitude with position is onboard writing to memory of the position which can be downloaded after recovery. Heck, the EggFinder/TRS is perfectly capable of
finding the rocket no doubt. Once found, can have at downloading the data. I wouldn't be surprised if Cris were looking into this type of arrangement for future building. Perhaps looking at a different GPS chipset that might be better suited for altitude recording too. Kurt

 

[ksaves2]

I've thought about having the LCD receiver optionally inject the baro's altitude data into the NMEA data stream. That would probably help the 3D tracking. I might do that in a future Eggfinder LCD software build; I have a few features in mind for next year. There's a lot of space left in the flash, so I can do a lot of playing around.

I stand corrected here as I thought that was already happening. The channel status is injected in there as I show in the following Xastir screenshots:


The screen on the left shows the information and positions of the TRS out in the garage.
There is a perl script I run that takes the NMEA strings from the Eggfinder LCD and turns them into a pseudo APRS packet. What is plotted is the converted NMEA to APRS packet in real time.
That comes in over a networked link /dev/rfcomm1 (comm0 is a Mobilinkd TNC that is running at the same time). The second shot to the right is the live
NMEA strings coming in over a minimized terminal screen from the EggFinder TRS. You can see the status of the deployment channels are in there. The Baro altitude isn't. I was mistaken in that supposition.
The third shot from the left is a zoomed in picture of the TRS, the Rocket with the number 8 in it and my local APRS station position. Xastir is still connected to a handitalkie with a Mobilinkd B/T TNC decoding local APRS packets besides handling the data stream from
the EggFinder TRS/LCD combination.
Last picture/screen save on the right is the log of the positions recorded up to that time.

I wished Xastir was easier to setup as I'd do some instructions on it. Fliers who are hams and have some APRS skills would more likely be able to pull it off. The other thing is a powerful, cheap, true linux tablet is not available out there yet. Xastir takes quite a while to
load the maps on this old dual boot tablet I run in the basement but heck, I have Xastir running, tracking the TRS plus doing this email at the same time. Not bad for an outdated
laptop. Yeah baro altitude in the NMEA strings might be O.K. as long as it doesn't mess up
end application decoding of packets be it the hacked ham stuff out there or the Android
GPS Rocket Locator. Time for lunch with my good buddy the Foley catheter!! Kurt Savegnago

 

[kevinkal]

The second shot to the right is the live NMEA strings coming in over a minimized terminal screen from the EggFinder TRS. You can see the status of the deployment channels are in there. The Baro altitude isn't. I was mistaken in that supposition.

In your second shot, I thought the Barometric AGL altitude was coming in as the <0>, <-1>, and <1> values right next to the deployment status "DM", .. those values at least, seem to be inline with the TRS / LCD altitude displayed after syncing.

 

[ksaves2]

In your second shot, I thought the Barometric AGL altitude was coming in as the <0>, <-1>, and <1> values right next to the deployment status "DM", .. those values at least, seem to be inline with the TRS / LCD altitude displayed after syncing.

I believe that's the status of the deployment channels. One can see that in one of the screen saves of the screen save on the left. The altitude is the GPS altitude coming across not the baro altitude. I don't see another string that
suggests that so I believe Cris when he says it's not in there but gets piped to the LCD
screen.

I spent the afternoon tooling around with the YAAC program: https://www.ka2ddo.org/ka2ddo/YAAC.html

Though it's a Java app, it's one that has the potential for EggFinder tracking. One problem is bluetooth under
Winblows sucks big time. The program runs like a champ under the linux environment.
There is a bluecove plugin that's supposed to work and I messed with it again since the last time 6 months ago.
Close but no cigar.

The potential is attaches their NMEA Bluetooth GPS to the program for local position and the program allows one to monitor another NMEA string a.k.a. the EggFinder B/T enabled receiver. No sleight of hand, no scripts to run just
setup the local NMEA GPS and the EggFinder NMEA receiver and one can track just fine.
The maps are Open Source and free for YAAC so it would be perfect to plan a recovery. Oh well, I have a post up and see if the developer can work with it. Kurt

 

[SpaceManMat]

I've previously had these discussions with Cris so I'll quote him.

"The LCD ignores non-NMEA data. The altitude and status data are surrounded with characters that tell the LCD what the data is... <> is for the altitude data, and {} is for deployment channel status. The baro values are in feet, a future version of the LCD software will display the baro altitude figure in meters if you selected that in the LCD setup screen. It currently only does the conversion for GPS altitude data."

You'll be able to see this in my excel spreadsheet that it rebuilds the NMEA data using the baro details. It also validates the checksum encoding so you know that only good NMEA sentences are used, I found in the trial file I used that there was quite a lot of corrupt sentences in there. Unfortunately Cris did not add checksum to the additional altimeter data so there is no way to verify it.

 

[kevinkal]

If any of you are interested in merging / recombining egg finder data I've done that for a number of different file types.

Follow my posts here
https://www.rocketryforum.com/showt...re-In-flight-Position-and-Altitude-Peformance

Happy to give new file types / combinations a shot.

I've previously had these discussions with Cris so I'll quote him.

"The LCD ignores non-NMEA data. The altitude and status data are surrounded with characters that tell the LCD what the data is... <> is for the altitude data, and {} is for deployment channel status. The baro values are in feet, a future version of the LCD software will display the baro altitude figure in meters if you selected that in the LCD setup screen. It currently only does the conversion for GPS altitude data."

You'll be able to see this in my excel spreadsheet that it rebuilds the NMEA data using the baro details. It also validates the checksum encoding so you know that only good NMEA sentences are used, I found in the trial file I used that there was quite a lot of corrupt sentences in there. Unfortunately Cris did not add checksum to the additional altimeter data so there is no way to verify it.

Thanks Mat. I need to find some time to do this.

 

[ksaves2]

Since I have some downtime recovering from a surgery I futzed around with a "Pocket Chip"
which is basically a linux laptop in the hand. It's cheap and the guts can be purchased for
$9.00 and can be popped in and out of the case. It runs Debian jessie and even though it
only is a 1Ghz single threaded chip, it will run the tracking program Xastir. I do not use
the Pocket Chip BIOS and flashed the 4.4 Debian GUI that is available from the makers
site. It runs fine with it. A full blown linux box in the hand. I have an Rf mouse I use to control it and it's essential if going to be used for tracking.

https://getchip.com/pages/pocketchip

I do not recommend one unless one knows a bit about Linux and Ham Radio APRS tracking.
Below are three screen saves of some tests:


As one can see, the icons can carry a lot of information directly. Xastir is a Ham radio tracking app and a rocket flier/Ham who is much more adept at computers than I, wrote a Perl script so the incoming NMEA streams from an EggFinder/TRS are converted into an
APRS packet. Hence can use this for Ham APRS tracking or with this hack script, as a tracker for NMEA trackers. Altitude is displayed (GPS) and the test EggFinder is one that was wrecked that I restored with a UBlox GPS chipset that is said to be better for use at altitude.

What I am wondering is if this application will recover and plot positions better than the
APRSIS32 app I show in the first posts of this thread. I am amazed that even though the screen is quite small, it is quite usable but that will only be shown when I go out and fly with it. I guess I should have assumed the small screen was viable as folks use their phones
with the Android app "GPS Rocket Locator". I've only used a tablet with it so far and at the time, offline maps weren't available.

APRSIS32 of course is Windows and Xastir is Linux. We'll see if there is a difference as to
the processing efficiency when I get a chance to fly in the spring.

Kurt Savegnago

 

[ksaves2]

Did a tracking launch last weekend and jpeg will follow. I've come to the conclusion that the mapping software has some timing considerations as far as displaying all the wanted information with the NMEA/Eggfinder/Arts/Missileworks trackers. I'll elaborate later but what I believe is occurring is the software timing might miss decoding some of the incoming information. I have to say, I don't have a Missileworks system to test so there could be a chance it could work with the software setups I use better than the EggFinders/Arts I have access to. It's not a problem with the devices at all, it's the tracking software used.

I was playing with an ARTS GPS tracker last night. (Pictures of the hardware below) When I piped the data through a python script so it was converted to a "pseudo" APRS packet that Xastir could use, the altitude wasn't displayed by the icon on the laptop. That was odd as the altitude was seen in the GGA NMEA strings. I then stopped the script and piped the NMEA sentences directly into the port that was identified as the GPS input for the base station location. Of course that is essential if one wants to be able to navigate to the rocket. In that case, every single altitude report was decoded and placed above the icon like I show above in the Xastir scans. Positions were better decoded and plotted though altitude display is spotty sometimes. Now I know SirfIV chipsets aren't so great
for altitude but it's the trend I desire to see in order to be able to be looking where there will be the main chute deployment.

Hmmmmmm, timing problem. Oh well, at least with a few of the tracking solutions the raw streams of the NMEA sentences can be saved for manual review
later.

I am going to have to get a second person to look at my LCD screen as I could hear it beeping even though the rocket positions were being incompletely
plotted. I have to keep my eye on the tablet in order to keep the patch antenna pointed on the rocket. Once a rocket goes out of sight, one might as well be paying attention to their tracking solution. If one gets a direction and altitude indication, they know where to look to try to get a visual on descent before main deployment. I've stolen glances at the LCD before and sometimes don't see the screen change even though there is beeping to indicate signal reception. I ordinarily wear the LCD in a yellow Black Aero case with a neck strap:
https://www.blackaero.com/shop-2/eggfinder-lcd-case. I'll start flying with the LCD I have in the stock black case and lay it on the ground so it's easier for me to look at if I can't find anyone to monitor it. The patch antenna is connected with a cable so positioning of the LCD receiver isn't critical as the antenna is on a pole.

I'll have an answer if the EggFinder LCD successfully decodes each sentence with every "beep" that signals reception. If the information on the display changes
every time, then there are software issues. Of course that is not a fault of the device itself EggFinder or otherwise.

I will say, I've never lost a rocket while tracking it in this manner as I've always managed to capture "the last reported" position. Also by looking at the map even if I can't see the rocket coming down, I can establish a drift pattern from the intermittent positions that do get plotted. That is extremely helpful.
I had a rocket last weekend where the chute didn't fill and I never saw the rocket at all. The rocket and tracker survived so I was able to walk right up to it.
I wouldn't have had any idea where it went. The rocket landed to the north of me and others were landing to the south of me. If I hadn't established a track,
I could have spent all my time futilely looking for it in the wrong place. Kurt

 

[cerving]

The Eggfinder LCD will only beep if the received NMEA packets are good, i.e. it can decode all of the fields and the checksum matches. There may be OTHER packets that are incomplete, and that may be what you're seeing... the Eggfinder display won't show those packets.

 

[ksaves2]

The Eggfinder LCD will only beep if the received NMEA packets are good, i.e. it can decode all of the fields and the checksum matches. There may be OTHER packets that are incomplete, and that may be what you're seeing... the Eggfinder display won't show those packets.

I'll take a closer look Cris. Like I've mentioned, I think it's a timing issue with the tracking software but the display is nice. Since the behavior is related to the software and the display
hardware (ie. the laptop or external hardware device running the tracking software) I'm going to take a look at it again with the Pocket Chip handheld linux computer.
https://getchip.com/pages/pocketchip For $9.00 I just got extra "CHIPs" and optimize each one for a particular app. The Pocket Chip firmware is some useless gaming
thing but Debian 4.4 Jessie can be downloaded from the site. The firmware was updated so 8Gb of memory can be used instead of 4. Nice for maps.

If I recall correctly I had more altitudes plotted when using it to decode. I don't know why that would be as the single CPU is working hard to run Xastir. I have to
give this setup a try in a real tracking situation. Very easy to carry around in a small box the inside of which is painted flat black for glare reduction.

Another thing. For the fans of the Android app "GPS Rocket Locator" I suspect Google caught up with them and I can no longer get tiles to be saved of their
maps. I suspected that was going to be an issue someday. Either that or a "new" cheap Android tablet I have acquired and the BLU Adroid phones are the ones with the problem.

Looks like someone setup a remote launcher with a C.H.I.P.: https://blog.nextthing.co/blast-off-with-rocketc-h-i-p/


Kurt

 

[ksaves2]

Here is the latest map of a totally sight unseen rocket flight to 3k'. Harness was twisted and the Jolly Logic chute release worked but the chute must have been stiff as it didn't open until I picked up the harness. It was lying on the ground out in the open and the chute release was off of it. North is up and other rockets were landing to the South with shifting winds. I used the patch antenna and I didn't realize it at the time but it improved the recovery/decode rate of the positions. The sun was at my back and even with my tablet inside a flat black painted box I had a hard time seeing the screen. That's one thing to consider when using laptops/tablets out in the sun. Inside the "suncreen" box, facing the sun and looking down into the box leads to a more readable screen.

That's one advantage to using a Garmin GPS attached to an APRS tracking rig:



Can't save a live map with the Kenwood/Garmin setup but the Kenwood can be setup to monitor the GPS altitude during the flight while one can
"look" at the map to see where the rocket is. The handheld Garmins are designed for one to be able to position the screen and read it in full sunlight.

A changing lat/long on screen doesn't "do" anything for me. :fly: Add one's main deployment altitude
to field elevation and one can monitor the descent and be ready to look in the direction the main chute event is expected to happen.
This is a nice barebones setup to track and find BeelineGPS trackers. (As an aside, get that same cable and one can directly plug-in a
Yaesu VX-8GR. Too bad the -8GR went out of production. Was quite a bit cheaper than a D-72A.)




Wind was from the southeast mainly but like I mention it appears the winds aloft were quite different at times with several rockets landing to the southeast that
was opposite from the prevailing ground direction. The winds were shifting though I didn't pay much mind to them as I concentrated on keeping the patch
antenna pointed at the rocket.

The fact that the chute didn't fully deploy probably determined the touchdown point.

As an aside, I messed around with the old ARTS GPS tracker last night again. I was using a DB9 serial to bluetooth converter that finally died while I was using it.
It was an old Iogear GBS301: https://www.iogear.com/product/GBS301/
Tried to wire in an HC-06 Bluetooth module but no dice there. With the GPS tracker out in the garage with a 9 satellite lock and the HC-06 receiver paired to the laptop, the only thing seen in the datastream was a bunch of commas. The format of the datastream was that of the NMEA sentences but no data. When using a DB9 serial to USB cable the datastream was fine as was the GBS301 before it croaked. (I think the power jack is broken now leading to intermittent contact) If anyone has figured out how to add bluetooth connectivity to the old ARTS tracker receiver, drop me an email.

I don't have access to a Missileworks GPS tracker but I suspect with the 250mW power output and a Ublox chipset the results might be different than with
the EggFinders/TRS. I do have two modified EggFinders with outboard Ublox GPS receivers. I broke two Eggfinders in various ways (busted off the GPS antennas)
and salvaged the boards with the Ublox units. Have to build a rocket that can fly them.

To their credit, the Eggfinders "do" find the rockets they fly in so they perform as advertised. The SirfIV lat/long is plenty accurate. I haven't lost a single rocket that's flown them and several flights were totally sight unseen with one being ballistic. I dug that one out and if I hadn't busted the nosecone getting it out of the clay, I would have only had to replace the broken EggFinder. The plywood nosecone mounted sled was reduced to "sawdust" in that one!:lol:

In the scans above, that is the ground radius with the patch antenna I use that's on a 10 foot pole. I lost the signal once the rocket was down but I picked it up again when I held the patch antenna pole up in the air. Of course, landing by the access road in soft dirt made for an easy recovery and the rocket was unharmed by the tumble recovery. Kurt