I have a dream: standardization for GPS trackers

The Rocketry Forum

Help Support The Rocketry Forum:

waltr

Well-Known Member
Joined
Jul 18, 2021
Messages
104
Reaction score
74
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.
 

WillMarchant

Well-Known Member
TRF Supporter
Joined
Jan 15, 2009
Messages
2,482
Reaction score
145
That’s easy, GT Viewer. I have a lot of experience with it and I’m good friends with the author. It’s available for Windows, iOS and android devices and it’s fully supported.

It’s not a universal solution without Linux & macOS support.
 

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
4,676
Reaction score
2,228
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...
 

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
7,226
Reaction score
4,405
Location
Butte, Montana
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.
 

AllDigital

Lifetime Supporter
TRF Lifetime Supporter
Joined
Jun 14, 2013
Messages
332
Reaction score
247
Location
SoCal
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
 

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
7,226
Reaction score
4,405
Location
Butte, Montana
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.
 

Crayok

Well-Known Member
TRF Supporter
Joined
Oct 23, 2017
Messages
91
Reaction score
72
Location
Calgary, Canada
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
 

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
TRF Supporter
Global Mod
Joined
Jan 24, 2009
Messages
28,306
Reaction score
5,890
Location
Glennville, GA
This is a fantastic idea,
 

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
7,226
Reaction score
4,405
Location
Butte, Montana
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?
 

ChristineZ

Member
TRF Supporter
Joined
Oct 7, 2021
Messages
18
Reaction score
59
Location
Acton, Massachusetts
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. ;)
 

Crayok

Well-Known Member
TRF Supporter
Joined
Oct 23, 2017
Messages
91
Reaction score
72
Location
Calgary, Canada

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
7,226
Reaction score
4,405
Location
Butte, Montana
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.
 

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
4,676
Reaction score
2,228
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.
 

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
7,226
Reaction score
4,405
Location
Butte, Montana
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?
 

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
4,676
Reaction score
2,228
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.
 

plugger

Well-Known Member
Joined
May 1, 2009
Messages
589
Reaction score
269
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.
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
6,122
Reaction score
3,708
Location
Melbourne Australia
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.
 

plugger

Well-Known Member
Joined
May 1, 2009
Messages
589
Reaction score
269
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.
 

plugger

Well-Known Member
Joined
May 1, 2009
Messages
589
Reaction score
269
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
 

FredA

Well-Known Member
Joined
Jan 19, 2009
Messages
2,359
Reaction score
511
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.
 

UhClem

Well-Known Member
Joined
Feb 6, 2009
Messages
1,893
Reaction score
325
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.)
 

FredA

Well-Known Member
Joined
Jan 19, 2009
Messages
2,359
Reaction score
511
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.
 

gtg738w

FlightSketch - flightsketch.com
Joined
Dec 27, 2018
Messages
329
Reaction score
330
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!
 

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,730
Reaction score
1,264
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
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
6,122
Reaction score
3,708
Location
Melbourne Australia
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:

rocket_troy

Well-Known Member
Joined
Sep 9, 2013
Messages
290
Reaction score
138
Location
Melbourne, Australia
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
 
Top