# I have a dream: standardization for GPS trackers

### Help Support The Rocketry Forum:

#### WillMarchant

##### Well-Known Member
TRF Supporter
Having a mesh network, so that nodes help spread the location of other nodes, is great. APRS has done this for decades. http://www.picoaprs.de/index_en.php is an example of a tiny APRS transceiver that does such fill-in digipeating.

#### TonyL

Kevin's offshore scenario is all too real for those hobbies with a 'large enough' market. I have encountered RC products that started as some individual's innovation, and then got reverse engineered in China and are now available for the cost of the bulk pcb fabrication, driving that person's effort out of business. I have seen this in other kinds of non-electronic consumer products as well. While a lot of people can now have cheap stuff, someone else had their investment devalued to essentially nothing. This is not an argument for anything in particular, just an observation. I am happy to have stuff to buy that does what I want, and folks might notice the unprecedented variety of products available for GPS tracking. I don't see an actual need for standardization that is not far out weighed by the need for functional and effective products [which we already have]. Maybe life is good.

#### TonyL

managed to double post same thing, must be getting old...

Last edited:

#### Banzai88

##### Lvl 1,Wallet....Destroyed
TRF Supporter
Kevin's offshore scenario is all too real for those hobbies with a 'large enough' market. I have encountered RC products that started as some individual's innovation, and then got reverse engineered in China and are now available for the cost of the bulk pcb fabrication, driving that person's effort out of business. I have seen this in other kinds of non-electronic consumer products as well. While a lot of people can now have cheap stuff, someone else had their investment devalued to essentially nothing. This is not an argument for anything in particular, just an observation. I am happy to have stuff to buy that does what I want, and folks might notice the unprecedented variety of products available for GPS tracking. I don't see an actual need for standardization that is not far out weighed by the need for functional and effective products [which we already have]. Maybe life is good.
Witness so many old school RC airplane kits that got turned into ARFs made in China, as well as cheap cutting edge TX/RX/servos. Now it's almost impossible to find old school type kits and actually make a plane these days.

Last edited:

#### markjos

##### Well-Known Member
TRF Supporter
Okay, I know when I’m licked.
A worthy conversation, nonetheless.

#### Arpak

##### Well-Known Member
This brings up a really good point, maybe it'd be a fun project to make an open standard that is both lighter than NMEA and gives info more directly related to rocketry as well. Wait...

#### mikec

##### Well-Known Member
"lighter than NMEA" -- for air-to-ground links saving bytes could matter, but it really doesn't ground-station-to-phone or whatever. Saving bytes there seems like it's not worth much effort. Just make it some flavor of CSV or (bleh) XML...

#### cerving

##### Owner, Eggtimer Rocketry
TRF Supporter
More important than saving bytes air-to-ground is a robust protocol with error detection (and correction if possible), an packet retransmit. NMEA doesn't have that (except for the CRC error detection), however it is the universal serial output of virtually every GPS module. Maybe encapsulating NMEA in IP and using SLIP as the mechanism between the air and ground stations would satisfy these requirements... as well as providing for a lost rocket mechanism if a 127.x.x.x broadcast address was used as the lost rocket IP. Of course, the RF modules themselves would all have to be compatible... which they are not, right now.

#### Dan Griffing

##### Well-Known Member
TRF Supporter
Actually, a number of manufacturers, notably Apple, have done quite well forcing everyone into their closed ecosystem. Ditto for Microsoft.
One of the reasons why Apple and Microsoft have been able to throw their weight around is that they have such large percentages of their respective markets that they have become the de facto standards that must be adhered to by software developers who want to be a part of these markets.

For decades developers cried out for standards in the developing computer industry, and now that Apple and Microsoft have imposed them, developers can also see the tyrannical downside to them as well.

I’m not at all opposed to standards. Where would we be without USB, SD cards, NMEA GPS protocols, standardized computer development platforms, and standard reusable and portable programming languages like C.

But there are product contexts, technological stages of maturity, and economies of scale where they are feasible as well as when they are not.

#### Dan Griffing

##### Well-Known Member
TRF Supporter
Okay, I know when I’m licked.
I know the feeling too when our three dogs are around.

Then its a contest between them over who gets the most attention.

#### Grant_Edwards

##### Well-Known Member
In the crowded and competitive market of rocket GPS trackers, why would any manufacturer want to make changes to their product that would undermine their investment and benefit their competitors?
Having participated in standardization efforts in another (much larger) industry, I can attest that the main goal of all involved is to "make sure that nothing happens that will provide any advantage to my competitors". In practice, that usally means that everybody is motivated to make sure that nothing happens, period.

kjs

#### Crayok

##### Well-Known Member
TRF Supporter
Having a mesh network, so that nodes help spread the location of other nodes, is great. APRS has done this for decades. http://www.picoaprs.de/index_en.php is an example of a tiny APRS transceiver that does such fill-in digipeating.
wow 80Km range, up. that's going to drive digipeaters crazy...
dB

#### Dan Griffing

##### Well-Known Member
TRF Supporter
Having participated in standardization efforts in another (much larger) industry, I can attest that the main goal of all involved is to "make sure that nothing happens that will provide any advantage to my competitors". In practice, that usally means that everybody is motivated to make sure that nothing happens, period.
One of my responsibilities two decades ago working as a Silicon Valley engineer for KLA-Tencor, was to assure that the metrology instrument systems our department released met all of the compliance standards and regulations for all of the countries, states and our large corporate customers worldwide. Those regulations and standards were costly, time consuming, and complex, even for a billion dollar company like KLA-Tencor, but they were totally necessary.

But as with Grant Edwards, this aspect of my career is irrelevant to the issue of whether imposing standardization on rocketry GPS tracker manufacturers will be more harmful to some than it is to others.

And furthermore, just because something that might be nice to for consumers to have, like software that can talk to the trackers made by multiple competing vendors — is not a compelling need to impose involuntary compatibility standards on those vendors.

#### UhClem

##### Well-Known Member
wow 80Km range, up. that's going to drive digipeaters crazy...
Only if your settings are wrong.

#### Steve Shannon

##### Well-Known Member
TRF Supporter
One of my responsibilities two decades ago working as a Silicon Valley engineer for KLA-Tencor, was to assure that the metrology instrument systems our department released met all of the compliance standards and regulations for all of the countries, states and our large corporate customers worldwide. Those regulations and standards were costly, time consuming, and complex, even for a billion dollar company like KLA-Tencor, but they were totally necessary.

But as with Grant Edwards, this aspect of my career is irrelevant to the issue of whether imposing standardization on rocketry GPS tracker manufacturers will be more harmful to some than it is to others.

And furthermore, just because something that might be nice to for consumers to have, like software that can talk to the trackers made by multiple competing vendors — is not a compelling need to impose involuntary compatibility standards on those vendors.
Who the hell said anything about anything involuntary? Way to assume, Dan.

#### Tobor

TRF Supporter
@Steve Shannon,

Maybe the route to take is an open standard developed by an independent group. The PC industry has quite a few "Royalty Free" standards that have benefited consumers and manufactures alike. Examples include TCP/IP, X3D, Displayport, ePub, 7z, etc...

With the above in mind, maybe some combination of Tripoli, NAR, FAI and CAR could help lay the groundwork for such an endeavor,

Just a thought.

#### phyzzld

##### Well-Known Member
TRF Supporter
John and Dan are right...

Let's use motor hardware as an example (also non standard)...
If this is true, then why don't we have 33mm, 57mm and 95mm motors? 38, 54 and 98mm have become a de facto standard I assume not because consumers demanded it but rather for practical reasons, like available airframe or motor case tubing sizes (I admit I don't know the actual answer). Also, most average consumers probably didn't care that much if their motors were 37, 38 or 39mm.

This thread was kind of framed from the start to see how standardization could benefit the consumer, but are there any ways in which it could benefit the vendors? For example, I imagine that there are many behind the scenes details involved in developing a tracking system that most consumers know nothing about and care about even less. However, these details have probably resulted in a lot of redundant development without producing a real competitive advantage. Maybe "standardization" could be used as a way to help ensure the vendors' mutual survival or simply to make their lives a little easier, while giving them more time to develop their competitive advantage. If not so be it, just looking to offer a different perspective.

Jeff

#### OverTheTop

##### Well-Known Member
TRF Supporter
Also actually FCC certified.
I do that sort of testing on our commercial products. Not easy or cheap. Surprising and good to see it in your product.

kjs

#### plugger

##### Well-Known Member
First we need to understand though that Adrian's hardware and firmware is also pretty brilliant, and together as a package even more so. A tiny form factor that can track to edge of space.
Emphasis mine Kevin. Apologies for nit-picking, but I don't think this statement is correct. The Featherweight GPS tracker uses a uBlox M8 chipset and to my knowledge all uBlox 4-8 chipsets stop reporting a GPS fix above 50km MSL.

Here's a link (warning, PDF) to the Tripoli-Records.org uBlox GPS receiver overview document which highlights this fact pretty clearly. Even the most recent uBlox 9 chipset loses lock at 80km MSL.

#### kjs

##### Well-Known Member
TRF Supporter
Emphasis mine Kevin. Apologies for nit-picking, but I don't think this statement is correct. The Featherweight GPS tracker uses a uBlox M8 chipset and to my knowledge all uBlox 4-8 chipsets stop reporting a GPS fix above 50km MSL.
Thanks - it's not nit-picking if those specs are correct (I have no reason to doubt them at this point - thanks for linking to actual docs with links to actual specs!). Do we know if those are hard limits (GPS programmatically quits trying) or soft limits (keeps trying and might work with enough satellites)? I'm curious now; will investigate more.

#### VernK

##### Member/Vendor
TRF Supporter
Thanks - it's not nit-picking if those specs are correct (I have no reason to doubt them at this point - thanks for linking to actual docs with links to actual specs!). Do we know if those are hard limits (GPS programmatically quits trying) or soft limits (keeps trying and might work with enough satellites)? I'm curious now; will investigate more.
They are “hard limits”. The software in the GPS modules lock out reporting fixes above those limits. I believe that inside the GPS module it still has a valid fix because as soon as the altitude drops below the limit, even a tiny amount, the module resumes reporting valid fixes instantly.

#### OverTheTop

##### Well-Known Member
TRF Supporter
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. The high-altitude balloon crowd are always trying to find out and get no reply usually. It is somewhat up to the manufacturer how the limits are interpreted and applied.

Previously I think it was COCOM limits and they were well known, but that requirement has been superceded and modernised.

You can get GNSS receivers that can record the received data (pseudoranges etc) during flight and that can be post-processed to extract the data required. Been thinking about trying that for fun, in my spare time.

kjs

#### Steve Shannon

##### Well-Known Member
TRF Supporter
@Steve Shannon,

Maybe the route to take is an open standard developed by an independent group. The PC industry has quite a few "Royalty Free" standards that have benefited consumers and manufactures alike. Examples include TCP/IP, X3D, Displayport, ePub, 7z, etc...

With the above in mind, maybe some combination of Tripoli, NAR, FAI and CAR could help lay the groundwork for such an endeavor,

Just a thought.
That was kind of the idea of my original post, to help facilitate, so that the manufacturers and developers, who have the best understanding of what their systems need, could work together to develop an open standard. I knew that it was very idealistic, which is why the subject began with “I have a dream…”, a clear reference to Martin Luther King’s speech.
Maybe such a standard is too idealistic or maybe it’s as some say and would only serve to stifle innovation. But what about forming a Rocketry tracker user group and meeting at LDRS to share tips and tricks for rocket trackers. Would that gain any traction?

#### Crayok

##### Well-Known Member
TRF Supporter
That was kind of the idea of my original post, to help facilitate, so that the manufacturers and developers, who have the best understanding of what their systems need, could work together to develop an open standard. I knew that it was very idealistic, which is why the subject began with “I have a dream…”, a clear reference to Martin Luther King’s speech.
Maybe such a standard is too idealistic or maybe it’s as some say and would only serve to stifle innovation. But what about forming a Rocketry tracker user group and meeting at LDRS to share tips and tricks for rocket trackers. Would that gain any traction?
Steve, I don't think you are going down a wrong path.

Back in my younger years I was in the broadcast industry, in the analogue days, where it was extremely hard to transpose formats from one to another (NTSC to PAL or SECAM) but digital came in and eventually you flip a few bits here and there and it was done, no special circuitry required, yes some programmer had to set up the bit manipulation and create a codec to deal with the new format but it was significantly easier to deal with. And yes there was significant turf wars over what format was going to be king but consumers, as was pointed out in this tread, are looking for answers to what would help us and future rocketeers in doing this hobby.

With modern controllers and generally with good ample code space maybe think around giving consumer flexibility with selectable streams or header info of type of stream coming in, for example (List is not prescriptive or exhaustive):
1. Manufacturers proprietary data stream
• error correction
• data compression
• lots of other stuff
2. APRS
• location basics
• data compression
• no error correction
4. LARP
• Location Altitude Rocket Protocol
• add error detection and forward error correction? (adds some complexity, really required?)
• add event detection bits tied to time and altitude
• whatever an informed collaboration can bring up
5. NEMA
• Simplest to implement, slap a transmitter to a GPS, configure a sentence or two and away you go, did this in the mid 2000's
• time slice in altimeter specific info (we did this in the FC-877 days) early 2000's
6. Others
Most people don't have a beta machine, VHS, laser disk, BD, Blue ray, DV, DVD, and a plethora of other machines in our homes because there was consolidation of these technologies that made it waaay easier for the consumer and ultimately easier for manufacturers and creators to target format(s).

David

#### gtg738w

##### FlightSketch - flightsketch.com
That was kind of the idea of my original post, to help facilitate, so that the manufacturers and developers, who have the best understanding of what their systems need, could work together to develop an open standard. I knew that it was very idealistic, which is why the subject began with “I have a dream…”, a clear reference to Martin Luther King’s speech.
Maybe such a standard is too idealistic or maybe it’s as some say and would only serve to stifle innovation. But what about forming a Rocketry tracker user group and meeting at LDRS to share tips and tricks for rocket trackers. Would that gain any traction?
As a consumer I think it's a great idea. An open source protocol that could be ported to whatever device you want, expanded, supported by many would be great. LCO being able to monitor different systems on the same display. "Upgrade" your tracker without learning a new app.