I have a dream: standardization for GPS trackers

SilicdyneTRF
shop deals on amazon
the model rocket show
Wildman Rocketry
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
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 said:
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.
Click to expand...

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:
"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...
 
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.
 
cerving said:
Actually, a number of manufacturers, notably Apple, have done quite well forcing everyone into their closed ecosystem. Ditto for Microsoft.
Click to expand...
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 said:
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?
Click to expand...
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.
 
Grant_Edwards said:
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.
Click to expand...
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.
 
Dan Griffing said:
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.
Click to expand...
Who the hell said anything about anything involuntary? Way to assume, Dan.
 
@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.
 
kjs said:
John and Dan are right...

Let's use motor hardware as an example (also non standard)...
Click to expand...

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
 
kjs said:
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.
Click to expand...
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.
 
plugger said:
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.
Click to expand...

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.
 
kjs said:
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.
Click to expand...

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.
 
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.
 
Tobor said:
@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.
Click to expand...
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 Shannon said:
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?
Click to expand...

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
    • add detected events
    • error correction
    • data compression
    • lots of other stuff
  2. APRS
    • location basics
    • data compression
    • no error correction
  3. ADS-B
  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
 
Steve Shannon said:
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?
Click to expand...

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.

But on the developer side, the systems we have today are different because they offer different points on the cost/performance scale and one of the big features that sets them apart is data display. If a developer invests time (money) in their app but it works with other hardware, they probably won't offer it for free. Then how do you manage updates? New version that you have to buy again? Subscription? When the app cost is built into a one time hardware purchase, people don't question the price. If you asked for $5-10 a month (rocketry) people would loose their minds. Maybe there is a market for a good quality, universal rocket tracker app but right now it's a chicken/egg question. Who will develop it without deployed, compatible hardware and who is going to make universal hardware without user pull to support a 3rd party app?

Either way it's a great question and we should continue to revisit this...
 
Steve Shannon said:
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?
Click to expand...
Steve, lets do a thought experiment in this thread. Suggest an application (as a start) you would like any GPS hardware solution to work with, and we will go from there.
 
jderimig said:
Steve, lets do a thought experiment in this thread. Suggest an application (as a start) you would like any GPS hardware solution to work with, and we will go from there.
Click to expand...
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.

https://www.graphictechnologiesinc.com/
 
Steve Shannon said:
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.

https://www.graphictechnologiesinc.com/
Click to expand...
That's easy. If the application just needs a Nmea stream then hardware providers just need to supply a driver that converts their proprietary stream into an industry standard Nmea stream. How much would you pay for that driver?
 

Similar threads

StreuB1
Featherweight Raven + GPS = ?
Replies
9
Views
1K
Neutronium95
Neutronium95
Adrian A
Adding a magnetic switch to a Featherweight GPS tracker
Replies
2
Views
1K
Adrian A
Adrian A
OverTheTop
Automatic Antenna Tracker
2
Replies
39
Views
6K
OverTheTop
OverTheTop
Adrian A
Combining a Featherweight Tracker and Raven into a 38mm av-bay
Replies
9
Views
2K
Adrian A
Adrian A
Kane
Design and Build Thread: ARO-B Two-Stage
Replies
22
Views
2K
Kane
Kane

Latest posts

Back
Top