EggfinderTx --> Mapsphere, In-flight Position and Altitude Peformance?

[kevinkal]

Just this weekend I was able to try out my first ever tracker, an Eggfinder Tx. I use the Eggfinder LCD with a HC-06 Bluetooth Module to receive and transfer data to either my android tablet or my Windows 10 laptop. After a nice flight to 4600', I saw that the landing position shown on Mapshere running on my Laptop looked correct. I then closed Mapsphere and saved the track file upon exiting.

Now that I've been able to open the track file, I see that the GPS position and Altitude appear to be significantly in error, except for where the rocket sat on the pad before launch, and the portion of the flight where the main chute had opened. The ascent straight up was not represented correctly by the track data. Rather that a straight up flight, the track data shows a horizontal shift about 1000', then another shift back 1000' with an increase in altitude of 250 units.. which I assume are meters. The track should have shown a straight up shot to 4600 ft (roughly 1500 meters), and a slight northerly drift under the drogue. The data then appears to be correct where the main chute opened and the rocket slowed down from 60 fps to 15 fps and began to drift south until it landed. The GPS shown landing position was also correct.

So, is this normal performance? (My EggfinderTx uses the stock wire antenna, but I have the Upgraded SMA antenna sold by EggtimerRocketry. on the Eggfinder LCD). Supposedly, it should work well beyond 10,000 ft)
I was hoping to see useful altitude profiles.

Below I've attached a few descriptive pictures of my Tx install, track file, Mapsphere plots and corresponding in-flight video to show how straight up the flight was vs. what the Eggfinder/Mapsphere track looks like.


Here's the saved Mapsphere track, where I had to change the file extension from .gpx to .txt in order to upload here.
View attachment gpslog_16072016_151524 GPX.txt

Top Down Position. Starting point looks right, then only the last downward line to the ending point looks correct.


3D side view looking to north. Starting and Ending points look correct, but both position and altitude between launch and the main chute opening do not look correct. The line should basically go straight up, then come down slightly north, then just as shown in the last line segment before landing it should drift down from 700 ft agl and land.



Video of flight in which track data was recorded. Note how straight up and down the flight was until the southernly drift at the end under the main chute.
[video=youtube;zJxMuFOmZ1s]https://www.youtube.com/watch?v=zJxMuFOmZ1s[/video]

 

[SpaceManMat]

Ignore the altitude, the eggfinder does not reliably calculate it especially if it changes fast.

Ive played with using altimeter data to produce a corrected GPS file but only for google earth. Your file looks better than a Google earth one as it has the timing information present. If you have the altimeter data I might see if I can get you a better file.

 

[kevinkal]

Ignore the altitude, the eggfinder does not reliably calculate it especially if it changes fast.

Ive played with using altimeter data to produce a corrected GPS file but only for google earth. Your file looks better than a Google earth one as it has the timing information present. If you have the altimeter data I might see if I can get you a better file.

Thanks for the reply. I didn't know eggfinder had this issue. I does seem as if both the position and altitude data are incorrect when the rocket was moving fast such as the ascent and falling under the drogue chute. Should I just try to match the timescale and overwrite the elevation data with that from the altimeter?

Here's the data from the StratologgerCF, which is what drove the dashware gages in the video.

View attachment 20160716 Flite23 Level2 J415W-14.pf2

 

[SpaceManMat]

Take a look at the GPX data in a text viewer. One thing I noticed is there is a field <valid>0<\valid> But this in only present at the beginning and end coordinates. I'm wondering if the eggtimer was having issues getting enough satellites while moving? Do you remember such details? Don't suppose you have the full NMEA stream logged?

I thought I posted details here about recombining data but apparently I only posted at Australian Rocketry
Anyway the method I used was for KML data from Google earth and csv from an eggtimer.
https://www.ausrocketry.com/forum/viewtopic.php?p=61642#p61642

 

[ksaves2]

Ignore the altitude, the eggfinder does not reliably calculate it especially if it changes fast.

Ive played with using altimeter data to produce a corrected GPS file but only for google earth. Your file looks better than a Google earth one as it has the timing information present. If you have the altimeter data I might see if I can get you a better file.

SirfIV chipset can be off with altitude reporting. Use the altitude data from your electronics after you recover.
The GPS is pretty darned accurate with lat/long and that's what really counts when you want to get it back.

For more info on the altitude thing read John Coker's article: https://www.jcrocket.com/gps-tracking.shtml
Ken Biba mentions about the situation if you scroll down. Kurt

 

[kevinkal]

Take a look at the GPX data in a text viewer. One thing I noticed is there is a field <valid>0<\valid> But this in only present at the beginning and end coordinates. I'm wondering if the eggtimer was having issues getting enough satellites while moving? Do you remember such details? Don't suppose you have the full NMEA stream logged?

I thought I posted details here about recombining data but apparently I only posted at Australian Rocketry
Anyway the method I used was for KML data from Google earth and csv from an eggtimer.
https://www.ausrocketry.com/forum/viewtopic.php?p=61642#p61642

Thank you. I'll look at that this evening.

 

[kevinkal]

SirfIV chipset can be off with altitude reporting. Use the altitude data from your electronics after you recover.
The GPS is pretty darned accurate with lat/long and that's what really counts when you want to get it back.

For more info on the altitude thing read John Coker's article: https://www.jcrocket.com/gps-tracking.shtml
Ken Biba mentions about the situation if you scroll down. Kurt

Thanks Kurt.

 

[SpaceManMat]

Take a look at the GPX data in a text viewer. One thing I noticed is there is a field <valid>0<\valid> But this in only present at the beginning and end coordinates. I'm wondering if the eggtimer was having issues getting enough satellites while moving? Do you remember such details? Don't suppose you have the full NMEA stream logged?

I've managed to get the data mostly into the spread sheet. When the valid=0 entries stop then I can see by the timestamps that there are lost packets. There is an initial 15 sec where it does not receive co-ordinates with valid=0, I believe this corresponds to the launch of the rocket. After that there is a single co-ordinate with valid=0 and afterwards there are less lost packets corresponding to decent. I need to work on it some more still.

 

[cerving]

Eggfinder GPS data is reported once per second, with a fast-moving object the altitude will lag somewhat. If you have a relatively short flight, you may never really get a good altitude fix. My experience is that with flights above about 8,000' you generally get a somewhat useful altitude track as you approach apogee and on the way down, probably because of the longer coast time that you get with higher flights and the extended descent time. The Eggtimer TRS uses the baro reading to report altitude, it's much more responsive and less dependent on flight profile.

 

[Salvage-1]

I have lots of GPS data files from my rockets that never show the apogee.
It does seem that most of the current GPS trackers lose lock on the way up.

 

[Buckeye]

Somewhere I read that this device is called "Eggfinder" and not "Eggtracker" for this very reason.

The BRB products are more geared to recording flight profiles for kml plotting. I have a new BRB900 and just started playing around with the recorded data. Pretty good, but still some glitches showed up in my recordings.

 

[ksaves2]

Somewhere I read that this device is called "Eggfinder" and not "Eggtracker" for this very reason.

The BRB products are more geared to recording flight profiles for kml plotting. I have a new BRB900 and just started playing around with the recorded data. Pretty good, but still some glitches showed up in my recordings.

Greg Clark from BRB makes fine products. You can't go wrong with them. The APRS (Ham Radio) trackers also have the onboard memory to record the .kml files. (So does the BRB900) The earlier G-switch models took finesse but the latest units don't have the idiosyncrasies the older ones had. One of his 2 meter trackers made it to Morocco in a balloon and was recovered. The advantage of having the device store the positions in onboard memory is one doesn't have to depend on the vagaries of radio reception for an accurate position plotting. Recover the device and can download a better track for viewing. Kurt

 

[SpaceManMat]

Ok, so attached is my first conversion using StratologgerCF and Eggfinder GPX logs.

I ended up setting the altimeter logs to start at 103 seconds after the GPS logs. I think you'll find this looks a lot better.

View attachment EggFinderAdj GPX.txt

 

[kevinkal]

Ok, so attached is my first conversion using StratologgerCF and Eggfinder GPX logs.

I ended up setting the altimeter logs to start at 103 seconds after the GPS logs. I think you'll find this looks a lot better.

The altitude data looks much better. Seems like a lot of work to stitch that together. Thank you.

Here's what I see now: (as you know)




I still think the position data was shifted during the fast ascending flight and 60 ft/sec descent under drogue. There's nothing that can be done to fix that. The data looks much better with the elevation/altitude corrected. However, still, the last part of the profile where it slowed down under the main chute looks the best. Again, thank you.

 

[cerving]

I've done this a few times in testing, yes it is a bit difficult to get the NMEA data (which is sent once per second) to sync with recorded baro altitude data (which is typically taken 20 times per second). The Eggtimer TRS outputs the baro data out the RF feed once per second in sync with the NMEA data but separately, so it's easier to do this with a TRS because the baro data is already in sync. It wouldn't be terribly hard to edit the NMEA altitude and insert the baro data, if you use only the $GPGGA sentences then you can simply load the data into Excel and do it there. Save it out as a .csv file, then convert it to KML for Google Earth. Of course, if the TRS had an option to insert the baro altitude instead of the GPS altitude into the transmitted NMEA data then this would be pretty easy, but there's simply no room for that in the firmware.

 

[kevinkal]

I've done this a few times in testing, yes it is a bit difficult to get the NMEA data (which is sent once per second) to sync with recorded baro altitude data (which is typically taken 20 times per second). The Eggtimer TRS outputs the baro data out the RF feed once per second in sync with the NMEA data but separately, so it's easier to do this with a TRS because the baro data is already in sync. It wouldn't be terribly hard to edit the NMEA altitude and insert the baro data, if you use only the $GPGGA sentences then you can simply load the data into Excel and do it there. Save it out as a .csv file, then convert it to KML for Google Earth. Of course, if the TRS had an option to insert the baro altitude instead of the GPS altitude into the transmitted NMEA data then this would be pretty easy, but there's simply no room for that in the firmware.

Thanks Chris. I think my next order will be the TRS, even if I don't used the outputs, having the baro data would be worth it IMO.

I just need to come up with a way to get good pressure into the nosecone were the Eggfinder TRS would be mounted.. perhaps I'll vent the payload section down well aft of the nosecone and enlarge the internal vent into the nosecone from the payload section.. I'm not sure how it would handle the ejection charge pressure pulse.. 15psi or so. hmm.

 

[ksaves2]

There is one application that can save the Rf derived data into a .kml file directly. It's a real PITA and requires a Linux platform to run. Xastir can track and save the incoming NMEA data to a .kml file directly. Nice and clean.
Only problem is, it's Linux, real steep learning curve and an external perl script has to be started to pipe the incoming NMEA stream into Xastir. The perl script converts the NMEA data into a "pseudo" APRS packet that gets read into
Xastir through a "network" link where the EggFinder receiver is on.

You're better off editing the raw data or using a BRB 900Mhz to get the .kml. Doing it automatically is nice though.

I forgot to mention that if one has an Android device, the GPS Rocket Locator program offers offline caching so internet access is not required on field. Can record a logfile one can manually peruse. Any Android device that has B/T and Wifi should be
capable and doesn't have to be a phone. Kurt

 

[cerving]

There are some NMEA to KML converters out there, I've used them. Google it...

 

[SpaceManMat]

The altitude data looks much better. Seems like a lot of work to stitch that together. Thank you.

Here's what I see now: (as you know)

View attachment 297448


I still think the position data was shifted during the fast ascending flight and 60 ft/sec descent under drogue. There's nothing that can be done to fix that. The data looks much better with the elevation/altitude corrected. However, still, the last part of the profile where it slowed down under the main chute looks the best. Again, thank you.

Your welcome. There are a few niggling issues I need to fix then I'll post the spread sheet so you can do your own conversions for future flights. It takes seconds to get the data in and back out, the only issue is figuring out where to best set the relative time adjustment.

 

[SpaceManMat]

I've done this a few times in testing, yes it is a bit difficult to get the NMEA data (which is sent once per second) to sync with recorded baro altitude data (which is typically taken 20 times per second). The Eggtimer TRS outputs the baro data out the RF feed once per second in sync with the NMEA data but separately, so it's easier to do this with a TRS because the baro data is already in sync. It wouldn't be terribly hard to edit the NMEA altitude and insert the baro data, if you use only the $GPGGA sentences then you can simply load the data into Excel and do it there. Save it out as a .csv file, then convert it to KML for Google Earth. Of course, if the TRS had an option to insert the baro altitude instead of the GPS altitude into the transmitted NMEA data then this would be pretty easy, but there's simply no room for that in the firmware.

I don't suppose you have a NMEA log from a TRS I can play with? I Don't have a TRS but plan to record NMEA logs on future flights so will need to figure out how to pull them apart and reassemble.

I would have have thought the LCD unit could do the conversion? That way the data is available live to any linked PC etc.

 

[woferry]

As far as I know the TRS doesn't modify the NMEA messages at all. It's micro outputs additional non-NMEA messages that indicate the altitude, which the Eggfinder LCD picks up to display to the user. So the altitudes reported in the NMEA messages are those that come from the GPS module, not the barometer. But a script that post-processed the output and replaced the altimeter data in the NMEA message probably wouldn't be that hard (at least easier than combining it from the output of another altimeter like a StratoLogger, since one would first have to establish the lift-off time from both logs.

Here's a TRS log I captured at LDRS 35.

View attachment LDRS35#2_TRS_GPS.txt.zip

 

[ksaves2]

The TRS asynchronously places the altitude in the NMEA stream and the EggFinder LCD decodes it. You can see it through a terminal emulator as the NMEA stream looks normal and the altitude is tacked on in there. Perhaps Cris can comment. He said it was a trick to get the EF LCD to decode the data. If one has a tracking program processing the NMEA stream, they will likely be seeing the GPS altitude displayed on the map. Now I know MapSphere just places the icon on the map and does a breadcrumb track but if one wants to assess the information, they have to manually look at it in the logfile.

MapSphere was the first program that got me salivating for a real time tracking program. Displayed the track on a photomap, OMG. The only problem I had is it didn't do navigation and one had to manually get into the logfile to get at the lat/long. Hence I proceeded with other programs trying to find something simple enough that others could use. Unfortunately that's not the case. Sure the Ham apps can be hacked but darn, I feel it's too hard for
regular folks to setup. How about click on the rocket icon on the map and get all the positions/altitudes in a nice tabular screen? How about the rocket icon with the horizontal speed, distance, bearing and altitude displayed
next to the rocket in realtime? Xastir does that. APRSISCE/32 will display the breadcrumb trail with the altitude next to each crumb. Can click on it to pull up more information at each datapoint again all in real time.
All of the ham radio programs can track and keep the rocket in the middle of the screen too. If using an APRS tracker, the old UI-View program can actually record/track a flight to a file and play it back in real time
anytime one would want to relive the flight as it occurred on the screen.


If one just wants to use MapSphere to store the real time position data and peruse the data later, it certainly can do that. Be forewarned it's hard to triapse around out at the launch site with a laptop although it's getting easier with some of the tablets available now. Also it's hard to read a screen out in the sun if tracking pedestrian mobile. My first pedestrian mobile setup was a Kenwood D7A(G) with a cable connected to a Garmin 60Cs mapping GPS.
Holee molee, that's great and still is. Now we're getting close with no license required trackers with automatic mapping solutions that any flier can use and I think that's stupendously great. Kurt

 

[SpaceManMat]

As promised, attached is version 2 of my EggFinder conversion spread sheet.

This version takes in the file EggFinder.GPX and StratologgerCF.pf2 from the specified folder
You then need to figure out the Launch site AMSL and the Timing Adjustment
You can also enter a final set of co-ordinates which is handy where the Eggfinder signal is lost before landing.
Once complete the modified data is extracted into the file EggFinderAdj.GPX

Enjoy

View attachment EggConversion2.zip

 

[SpaceManMat]

I've done this a few times in testing, yes it is a bit difficult to get the NMEA data (which is sent once per second) to sync with recorded baro altitude data (which is typically taken 20 times per second). The Eggtimer TRS outputs the baro data out the RF feed once per second in sync with the NMEA data but separately, so it's easier to do this with a TRS because the baro data is already in sync. It wouldn't be terribly hard to edit the NMEA altitude and insert the baro data, if you use only the $GPGGA sentences then you can simply load the data into Excel and do it there. Save it out as a .csv file, then convert it to KML for Google Earth. Of course, if the TRS had an option to insert the baro altitude instead of the GPS altitude into the transmitted NMEA data then this would be pretty easy, but there's simply no room for that in the firmware.

I can see the non NMEA data in the logs, does the baro altitude in the <> belong with the $GPGGA that follows or is the baro for the previous $GPGGA

It also appears that the value holds the apogee value which I thought was a bit strange.

 

[kevinkal]

The TRS asynchronously places the altitude in the NMEA stream and the EggFinder LCD decodes it. You can see it through a terminal emulator as the NMEA stream looks normal and the altitude is tacked on in there. Perhaps Cris can comment. He said it was a trick to get the EF LCD to decode the data. If one has a tracking program processing the NMEA stream, they will likely be seeing the GPS altitude displayed on the map. Now I know MapSphere just places the icon on the map and does a breadcrumb track but if one wants to assess the information, they have to manually look at it in the logfile.

MapSphere was the first program that got me salivating for a real time tracking program. Displayed the track on a photomap, OMG. The only problem I had is it didn't do navigation and one had to manually get into the logfile to get at the lat/long. Hence I proceeded with other programs trying to find something simple enough that others could use. Unfortunately that's not the case. Sure the Ham apps can be hacked but darn, I feel it's too hard for
regular folks to setup. How about click on the rocket icon on the map and get all the positions/altitudes in a nice tabular screen? How about the rocket icon with the horizontal speed, distance, bearing and altitude displayed
next to the rocket in realtime? Xastir does that. APRSISCE/32 will display the breadcrumb trail with the altitude next to each crumb. Can click on it to pull up more information at each datapoint again all in real time.
All of the ham radio programs can track and keep the rocket in the middle of the screen too. If using an APRS tracker, the old UI-View program can actually record/track a flight to a file and play it back in real time
anytime one would want to relive the flight as it occurred on the screen.


If one just wants to use MapSphere to store the real time position data and peruse the data later, it certainly can do that. Be forewarned it's hard to triapse around out at the launch site with a laptop although it's getting easier with some of the tablets available now. Also it's hard to read a screen out in the sun if tracking pedestrian mobile. My first pedestrian mobile setup was a Kenwood D7A(G) with a cable connected to a Garmin 60Cs mapping GPS.
Holee molee, that's great and still is. Now we're getting close with no license required trackers with automatic mapping solutions that any flier can use and I think that's stupendously great. Kurt

I've had trouble seeing my Samsung Galaxy III Tablet when I'm trying to turn on my Eggtimer Quantum, or see Bluetooth GPS or RocketLocator. I've made a mental note that I'll look at brightness capability before I pick up my next tablet to be used for this purpose.

 

[kevinkal]

As promised, attached is version 2 of my EggFinder conversion spread sheet.

This version takes in the file EggFinder.GPX and StratologgerCF.pf2 from the specified folder
You then need to figure out the Launch site AMSL and the Timing Adjustment
You can also enter a final set of co-ordinates which is handy where the Eggfinder signal is lost before landing.
Once complete the modified data is extracted into the file EggFinderAdj.GPX

Enjoy

Thank you. I'll look forward to trying that out tonight after work. I have one more data set to look at, but it's only a 1450 ft flight... that landed very close by.

 

[kevinkal]

Chris,
Ignorant question here...
How difficult would it be to integrate a Ublox GPS solution into an Eggfinder Tx? Power, Grounds, Signal and Message compatibility? The idea would be to still use the 915 Mhz Tx and Rx, just try the Ublox solution. I understand they work well up to a mandated limit of 515 m/s, but may have some G limitations.

 

[cerving]

Chris,
Ignorant question here...
How difficult would it be to integrate a Ublox GPS solution into an Eggfinder Tx? Power, Grounds, Signal and Message compatibility? The idea would be to still use the 915 Mhz Tx and Rx, just try the Ublox solution. I understand they work well up to a mandated limit of 515 m/s, but may have some G limitations.

Not ignorant at all...

All you need to do is to feed the RF module with a 9600 baud feed. If it's NMEA, the LCD will decode it. I get your thought train, not sure if it's going to make any difference... I've had a few people fly uBlox vs. the Maestro Wireless A2235H that I use and there was no significant difference.

 

[ksaves2]

I've had trouble seeing my Samsung Galaxy III Tablet when I'm trying to turn on my Eggtimer Quantum, or see Bluetooth GPS or RocketLocator. I've made a mental note that I'll look at brightness capability before I pick up my next tablet to be used for this purpose.

Get a cardboard box and reinforce it with filament tape. Paint the inside of it with flat black paint. Another thing is get a matte screen protector not the "crystal clear" ones advertised. The "crystal clear" ones are fine indoors or at night but
really reflective in daylight. If you can find an Armorsuit screen protector that fits your device that has the matte finish, I recommend one. https://www.armorsuit.com/

I have an Armorsuit for my TW801 Winbook and it's very helpful along with the flat black painted box. Even facing the sun with the device in the box/shade, you'll find you have to get down close to read the screen.

When I use an APRS tracker with a Garmin 60CSX mapping GPS, the Garmin is meant to be used in daylight and one can hold it so the screen is very viewable in the direct sun. Kurt

 

[ksaves2]

Chris,
Ignorant question here...
How difficult would it be to integrate a Ublox GPS solution into an Eggfinder Tx? Power, Grounds, Signal and Message compatibility? The idea would be to still use the 915 Mhz Tx and Rx, just try the Ublox solution. I understand they work well up to a mandated limit of 515 m/s, but may have some G limitations.

Not hard at all with the 1st version of the EggFinder. I have two converted units. Two wires to 3.3V battery +/- and one signal wire to the GPS pad. Yeah, you only need one wire to one pad where the Sirf IV chip sat. I salvaged two broken EggFinders
that way. With the newer EggFinders that don't have the 3.3V terminals would have to probably pull the power from the voltage regulator. If one is going to do that, start with a fresh kit or salvage on EggFinder that has a broken GPS on it.
I'll post pictures later. Oh, I forgot to add one thing, the altitude is not reliably displayed on the EggFinder LCD screen with these converted units. The GPS altitude is in the NMEA sentences that one can peruse later but they are not displayed in
real time reliably. If one uses another tracking/mapping program, the altitudes from these converted EggFinders are fine. I think the LCD is expecting the information to be presented in a certain form. Sometimes it's seen, sometimes it isn't.

Kurt