I have a dream: standardization for GPS trackers

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Standards, NOT most times.

I like the NMEA (I use egg Finder GPS) since it a standard.

Another way to have other info that wasn't anticipated in the original protocol is 'extended' protocol. This is simply adding Codes for additional info.
Example maybe adding accelerometer data to a NMEA stream. Define the Acc data with a "$ACAAA, , , " that should be ignored by existing NMEA decoders but a decoder with 'extensions' would decode this.
 
Hi Will!
That’s true. Also I’d like my wife’s Apple Watch supported.
Maybe it should just be an HTML interface. 🙂
You'd be surprised how different browsers interpret the same HTML code. The WiFi pages on our altimeters/switches can look very different depending on your browser. Straight HTML code... down to not specifying fonts, simply using the header tags. List boxes on Safari are interpreted as tick boxes on Chrome. You wouldn't even know that it was the same code...
 
You'd be surprised how different browsers interpret the same HTML code. The WiFi pages on our altimeters/switches can look very different depending on your browser. Straight HTML code... down to not specifying fonts, simply using the header tags. List boxes on Safari are interpreted as tick boxes on Chrome. You wouldn't even know that it was the same code...
I'm not surprised at all.
 
This is an intriguing thread. It is an ambitious idea that would benefit both fliers and (most) developers, but as others have pointed out, there is not enough market demand (low customers/revenue) and too many layers of complexity (technical requirements) for an easy answer that would meet all the different price/performance objectives.

A lot of the technical considerations have been discussed, but a few big ones haven't. To have a "standard" I think you would need to align on three layers of the stack: 1) the frequency ranges (e.g., 900 Mhz vs. 433 Mhz, etc.). 2) the radio type (FSK, ASK, Lora, etc.) 3) the software protocol and speeds (NMEA, APRS, New Standard?, etc.).

If your design objective was the lowest cost standard then you would likely design to a 900Mhz FSK NMEA subset, but your range and breadth of data would be limited. On the other end of the spectrum, if you wanted something more full featured you might use a mesh network Lora radio in Amateur bands (70cm/433Mhz) with a protocol that supported both GPS and other telemetry data. Building devices that support a broad range would get a lot more expensive.

In my thought experiment, I considered that a club could build a "universal base station" with multiple radios that could read/receive signal and protocols from all the top trackers and then "repeat them" to club handheld trackers. That would be an interesting way to create a "universal" receiver and would take the immediate pressure off the manufactures to standardize, although it doesn't align incentives with developers, as it cuts out half (or more) of their revenue on the receiver side. That proprietary "universal" base station/repeater would also be very expensive - defeating the purpose.

I could see a path to a standard if two or more developers got together, likely that share similar radios/frequencies, and decided on offering an alternate protocol -- like a switch for basic (standard) vs. normal protocol. This would be analogous to a stereo that outputs in Dolby 8.1 normally, but can be switched to just output in stereo. The basic mode would allow for compatibility with their universal trackers (or others to come). They would have the first mover advantage, but would also have more work. I think this path of cooperation is more realistic than Tripoli publishing a standard and hoping the developers will follow.

-Mike
 
This is an intriguing thread. It is an ambitious idea that would benefit both fliers and (most) developers, but as others have pointed out, there is not enough market demand (low customers/revenue) and too many layers of complexity (technical requirements) for an easy answer that would meet all the different price/performance objectives.

A lot of the technical considerations have been discussed, but a few big ones haven't. To have a "standard" I think you would need to align on three layers of the stack: 1) the frequency ranges (e.g., 900 Mhz vs. 433 Mhz, etc.). 2) the radio type (FSK, ASK, Lora, etc.) 3) the software protocol and speeds (NMEA, APRS, New Standard?, etc.).

If your design objective was the lowest cost standard then you would likely design to a 900Mhz FSK NMEA subset, but your range and breadth of data would be limited. On the other end of the spectrum, if you wanted something more full featured you might use a mesh network Lora radio in Amateur bands (70cm/433Mhz) with a protocol that supported both GPS and other telemetry data. Building devices that support a broad range would get a lot more expensive.

In my thought experiment, I considered that a club could build a "universal base station" with multiple radios that could read/receive signal and protocols from all the top trackers and then "repeat them" to club handheld trackers. That would be an interesting way to create a "universal" receiver and would take the immediate pressure off the manufactures to standardize, although it doesn't align incentives with developers, as it cuts out half (or more) of their revenue on the receiver side. That proprietary "universal" base station/repeater would also be very expensive - defeating the purpose.

I could see a path to a standard if two or more developers got together, likely that share similar radios/frequencies, and decided on offering an alternate protocol -- like a switch for basic (standard) vs. normal protocol. This would be analogous to a stereo that outputs in Dolby 8.1 normally, but can be switched to just output in stereo. The basic mode would allow for compatibility with their universal trackers (or others to come). They would have the first mover advantage, but would also have more work. I think this path of cooperation is more realistic than Tripoli publishing a standard and hoping the developers will follow.

-Mike
That’s very interesting and even visionary. All I was really looking at to begin was a common software interface between the base hardware and whatever software on whatever device the flyer wants.

And just so there’s no confusion, this has nothing to do with Tripoli. Although I’m still on the board my intent all along was for this to be something completely open. I certainly don’t want anyone to think this is TRA trying to control something.
 
A lot of the technical considerations have been discussed, but a few big ones haven't. To have a "standard" I think you would need to align on three layers of the stack: 1) the frequency ranges (e.g., 900 Mhz vs. 433 Mhz, etc.). 2) the radio type (FSK, ASK, Lora, etc.) 3) the software protocol and speeds (NMEA, APRS, New Standard?, etc.).

Hey Mike

In the world of SDR (software defined radios) the first two are pretty easy to overcome (for receivers). SDR are frequency flexible, generally cheap but you can spend more for better, and flexible on modulation type. Now some programming time would need to be spent on creating an "codec" per manufacturer for their modulation and data stream. Maybe there is a standard API for multiple codec so manufacturers don't have to spend time on the various platforms interfacing with the SDR (Yes, someone would have to write that piece too) The issue and this is where my knowledge is suspect if folks are using spread spectrum techniques.

Just throwing ideas out which lets us explore what might be able to be done

David
 
This is an intriguing thread. It is an ambitious idea that would benefit both fliers and (most) developers, but as others have pointed out, there is not enough market demand (low customers/revenue) and too many layers of complexity (technical requirements) for an easy answer that would meet all the different price/performance objectives.

A lot of the technical considerations have been discussed, but a few big ones haven't. To have a "standard" I think you would need to align on three layers of the stack: 1) the frequency ranges (e.g., 900 Mhz vs. 433 Mhz, etc.). 2) the radio type (FSK, ASK, Lora, etc.) 3) the software protocol and speeds (NMEA, APRS, New Standard?, etc.).

If your design objective was the lowest cost standard then you would likely design to a 900Mhz FSK NMEA subset, but your range and breadth of data would be limited. On the other end of the spectrum, if you wanted something more full featured you might use a mesh network Lora radio in Amateur bands (70cm/433Mhz) with a protocol that supported both GPS and other telemetry data. Building devices that support a broad range would get a lot more expensive.

In my thought experiment, I considered that a club could build a "universal base station" with multiple radios that could read/receive signal and protocols from all the top trackers and then "repeat them" to club handheld trackers. That would be an interesting way to create a "universal" receiver and would take the immediate pressure off the manufactures to standardize, although it doesn't align incentives with developers, as it cuts out half (or more) of their revenue on the receiver side. That proprietary "universal" base station/repeater would also be very expensive - defeating the purpose.

I could see a path to a standard if two or more developers got together, likely that share similar radios/frequencies, and decided on offering an alternate protocol -- like a switch for basic (standard) vs. normal protocol. This would be analogous to a stereo that outputs in Dolby 8.1 normally, but can be switched to just output in stereo. The basic mode would allow for compatibility with their universal trackers (or others to come). They would have the first mover advantage, but would also have more work. I think this path of cooperation is more realistic than Tripoli publishing a standard and hoping the developers will follow.

-Mike
What àbout something based on Meshtsstic T-Beam devices?
 
Hi Will!
That’s true. Also I’d like my wife’s Apple Watch supported.
Maybe it should just be an HTML interface. 🙂

Now that would be cool! Just a big arrow pointer with a distance to target number...lol

I'll wait for the two way video feeds in a later release when integration is established with my 3 on-board video cameras. ;)
 
Now those are cool devices, multiple freqs, some in amateur bands, multiple modulations techniques. Not sure on the wifi piece but the LoRa might work. Looks like lots of flexibility. Price seems to be too good to be true.

https://meshtastic.org/docs/hardware/tbeam-hardware

David
And a long wait to get them in the USA because of the shipping logjams. The one I was looking at was the T-Beam - M8N & SX1262, but I really have no hands on experience yet.
https://meshtastic.org/docs/hardware/tbeam-hardware
 
The SX12xx series are pretty old nowadays, there are much better LoRa modules available. For 900 MHz, LoRa is the way to go now, however for 70 cm Ham a FSK solution is probably better... narrow-band fits in better with the ARRL band plan for 70 cm. LoRa wasn't around when we designed the Eggfinder system in 2013, if it was we probably would have gone that route, although most of the modules don't lend themselves to a "dumb" GPS transmitter solution.
 
The SX12xx series are pretty old nowadays, there are much better LoRa modules available. For 900 MHz, LoRa is the way to go now, however for 70 cm Ham a FSK solution is probably better... narrow-band fits in better with the ARRL band plan for 70 cm. LoRa wasn't around when we designed the Eggfinder system in 2013, if it was we probably would have gone that route, although most of the modules don't lend themselves to a "dumb" GPS transmitter solution.
The sx1262 appears to be somewhat better than the previous sx1276: lower standby/receive current being one benefit. I didn't see many other LoRa modules that had a different radio and that incorporated GPS, but I'm pretty ignorant about these. Which do you think would be better?
 
There are a lot of LoRa modules out there now, I think that one that's getting the most traction is the ST Micro STM32 series. Or at least it will be when they're available... nobody has any stock right now and they're not quoting delivery dates.
 
Limits are built onto the GNSS receivers firmware to limit their usefulness in nefarious applications. Good luck trying to pin down what the actual limits are, as uBlox are notoriously shy about providing that.
I'm not sure what to say OTT other than from my perspective u-blox provide the relevant information clearly in their datasheets, as highlighted on page one of the Tripoli u-blox GPS receiver PDF I linked to above.

for u-blox 4-8
1636008444668.png

and for u-blox 9
1636008475217.png

For me I think the bigger problem is that cheaper chipsets that advertise their receivers as having "Airborne Mode" or "Balloon mode" configuration options available in their datasheets but they're still unsuitable for rocketry use. Strud and I played with both MTK3333 and MTK3339 chipsets back in late 2019/early 2020 and both produced garbage data during below Mach sport rocket flights.

YMMV, but for me I've done enough experimenting with other chipsets and am happy to rely solely on u-blox chips moving forward given their proven ability to provide accurate fixes for our use case.
 
Thanks Plugger. They may have improved their situation in the past year or so but it has been notoriously difficult to get that information in the past. Just have a look at some of the balloon forums and it will be quite evident. Great that they have elucidated that, as they should have done earlier. I too use uBlox and have recently got the NEO-9M which is nice step-up from the earlier series. Looking forward to getting it flying one day.
 
Thanks Plugger. They may have improved their situation in the past year or so but it has been notoriously difficult to get that information in the past. Just have a look at some of the balloon forums and it will be quite evident. Great that they have elucidated that, as they should have done earlier. I too use uBlox and have recently got the NEO-9M which is nice step-up from the earlier series. Looking forward to getting it flying one day.
No worries OTT. From my perspective I try to steer clear of the HAB people when it comes to GPS chipset selection for rocketry use. I find their experiences anecdotal at best given the relatively gentle flight profile their balloons have in comparison to our rockets. And my NEO-9M evaluation board (the U.FL antenna model) arrived yesterday. Looking forward to flying that guy in 2022, that's for sure!

I hope you're well over there mate.
 
And to be honest, maybe those balloon folk have their heads in the clouds! The u-blox 6 manual published in April 2013 clearly states on page 2:
1636012628754.png
 
As I recall - they G limit on these is often driven off the oscillator performance under stress.
You pull hard G's on a XTAL and it's frequency will drift.
In pure timing applications like GPS, this is death.
Some XTALS are better than others. Some orientations are better than others.
But 4G limit is probably come from the XTAL.
 
You pull hard G's on a XTAL and it's frequency will drift.
In pure timing applications like GPS, this is death.
GPS requires a stable clock but accuracy is not required. (Vibration causes clock jitter which is a killer of course.) The acceleration limit comes from the internal tracking loops that are trying to keep a copy of the satellites PRN aligned with what it is receiving.

A quick change in acceleration will cause trouble but steady acceleration is not a problem.

It has been a while since I looked, but a typical tracking loop had input from early, on time, and late correlators. Where early and late were offset by a half bit time. (Half a bit of the 1.023MHz spreading function.)
 
A quick change in acceleration will cause trouble but steady acceleration is not a problem

Yep - a hard spank off the pad and the oscillator can unlock the GPS for a fair bit .... if the XTAL is particularly susceptible. Some really take a while (many seconds) to get back on frequency. I've even saw one part that jumped to another vibration node if shocked.....clearly we rejected that one. Once un-locked due to timing, re-lock can take some time.
 
As I recall - they G limit on these is often driven off the oscillator performance under stress.
You pull hard G's on a XTAL and it's frequency will drift.
In pure timing applications like GPS, this is death.
Some XTALS are better than others. Some orientations are better than others.
But 4G limit is probably come from the XTAL.

The correlators have to track in both time and Doppler. It's like a grid search and the peak bin is what's used for the fix. The search area is narrowed down after acquisition and depends on the mode you select. Even with a perfect oscillator, if it moves fast enough, or faster than its expecting to, the signal will end up outside of the correlator's bins and it will lose the code. if only uBlox would just add a 50g air mode we'd be all set!
 
The correlators have to track in both time and Doppler. It's like a grid search and the peak bin is what's used for the fix. The search area is narrowed down after acquisition and depends on the mode you select. Even with a perfect oscillator, if it moves fast enough, or faster than its expecting to, the signal will end up outside of the correlator's bins and it will lose the code. if only uBlox would just add a 50g air mode we'd be all set!
Ublox with keep lock on a 34g flight with the proper antenna
 
As I recall - they G limit on these is often driven off the oscillator performance under stress.
You pull hard G's on a XTAL and it's frequency will drift.
In pure timing applications like GPS, this is death.
Some XTALS are better than others. Some orientations are better than others.
But 4G limit is probably come from the XTAL.
Crystals are not too bad for frequency stability and can withstand surprisingly high G accelerations without failure. The frequency drift effects can be quite small also, but are highly dependent on the cut and size of the crystal. Quoting from an article on the web (link): "Acceleration force can alter the performance of a quartz crystal or crystal oscillator. The nature of the effect depends on the type of force that is being applied. Changes in the static gravitational force such as tilting or rotation will cause a step offset in frequency. Time-dependent acceleration or vibration will create frequency modulation in an oscillator. This will generate discrete sidebands in the case of sinusoidal vibration or an increase in the noise floor with random vibration. A shock pulse will cause a sharp temporary perturbation in the output frequency. What follows is an examination of the effects of acceleration force on the performance of quartz crystals and crystal oscillators.
The magnitude of these frequency shifts is a function of the quartz crystal's acceleration or "g-sensitivity" vector and the magnitude and direction of the applied acceleration force. The acceleration sensitivity of quartz crystals is caused by stresses resulting from the mass of the resonator blank reacting against its mounting structure.1 This sensitivity is determined by many factors such as the type of cut—such as stress compensated (SC) or AT, the design and processing of the quartz blank, the package type, mounting structure and orientation in the holder. The range of typical g-sensitivities for bulk-mode quartz crystals can span several orders of magnitude, from less than 1 × 10-10 per g for a carefully made precision SC crystal to greater than 1 × 10-7 per g for a low cost AT crystal."


Nowadays there are MEMS-based crystal oscillators that are more robust and exhibit far less (~ order of magnitude or better) less frequency pulling due to acceleration. These should be the device of choice for rocketry where timing is important in high G flights. Most flights will not likely see any measurable difference in timing IMHO.

I looked into this reasonably deeply a while back as I am designing a rocket that currently simulates at 110G at launch. Lots of things become important then.

GPS requires a stable clock but accuracy is not required. (Vibration causes clock jitter which is a killer of course.) The acceleration limit comes from the internal tracking loops that are trying to keep a copy of the satellites PRN aligned with what it is receiving.

A quick change in acceleration will cause trouble but steady acceleration is not a problem.

It has been a while since I looked, but a typical tracking loop had input from early, on time, and late correlators. Where early and late were offset by a half bit time. (Half a bit of the 1.023MHz spreading function.)
Agreed. These days where they have so many correlators (20, 50 or more in some cases) in the chips I suspect they can even look more widely for timing variations, although not looking too wide allows the unit to conform to the lockout requirements required by the relevant regulatory bodies.
 
Last edited:
Ublox with keep lock on a 34g flight with the proper antenna
John, can you provide anymore specifics or reasoning on that? Is this assuming a UBLOX M9N? I recall last year you mentioned the acceleration limitations can be improved with using satellites on the oblique (non overhead) to reduce the doppler freq change rate the module has to deal with - so is it safe to assume a better antenna opens out a wider angle of available sats? Also, with a "proper" antenna, are we looking for better gain or better filtering or both?

TP
 
Back
Top