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.

Steve Shannon

Well-Known Member
TRF Supporter
Joined
Jul 23, 2011
Messages
9,092
Reaction score
8,247
Location
Butte, Montana
Recent posts about GPS tracker interfaces make me wish that our manufacturers would work together to develop a standardized live data stream at the ground station end so that real time tracking could be done with the flyer’s choice of software, regardless of tracker.
Is there any reason this isn’t possible?
If this is possible, is there anything I can do to facilitate it?
 
SMoP. Small Matter of Programming. :)

If the hardware providers documented their data stream it would be quite possible to write a "universal" tracking app. Of course, once you spec the data stream, it becomes harder and harder to upgrade the hardware and maintain backward compatibility.

Even without a documented data stream it shouldn't be too hard to reverse engineer the spec -- if you're into such activities. You already have the maufacturer's tracker and know what it's supposed to do.

Of course there are a few potential sticky bits. Here's a starter list:
hardware requirements of the tracker itself (e.g. self-GPS, internal motion sensors, etc.)
any real-time requirements
outbound controls (e.g. to rename a tracker unit, enable a simulation mode, etc.)
any nasty devices that encrypt their data stream.

My to-do-before-death list includes this sort of tracker hosted by a low-end Kindle. It's cheap and has a big screen. My progress so far: I bought a kindle ... two years ago.
 
What you're asking for are published API specs. Once a vendor publishes their API specs, then any other vendor can interact with it.

It'd be nice if everyone standardized on a single API but I don't see that happening.
 
NMEA is a standard, however it's a bit "chatty" (especially the later uBlox implementations) and you can be more efficient by taking the data that you really care about and packetizing it into a binary stream. Eggtimer doesn't do that... we send the raw NMEA stream. Others do, probably to reduce the size of the transmission and possibly to add other data, but of course we can't speak for anyone else. There's lots of software out there that will decode raw NMEA data, whereas a proprietary data format is most likely theirs and theirs alone.
 
The Featherweight system, for example, can track several transmitters at once, including ones not owned by the owner of a particular ground station. Most systems only track one transmitter at a time (pairing) and their software may not even know or even have a unique ID for the transmitter, so that's a problem, though perhaps not an insolvable one.

As with most things, market forces usually act away from interoperability, not towards it. It's not like Apple and Android have any compatibility.

My homegrown ground station just sends out the NMEA strings it's getting on Bluetooth, that's pretty generic and a standard.
 
BRB900 has the option to send its own proprietary data format, NMEA strings, or both. Best of both worlds.
 
Lol...we do this on the astronomy / astrophotography side! We have universal astronomy standards for communication: ASCOM standards drivers (On the windows side), and ASCOM/Alpaca & INDIGO (on the mac/linux side) and between mounts, and auto-focusers, and rotators, and filters, and cameras and auto-guiders, and environment controls and dome control, and power management, and guiding software and stacking software and imaging software, and scope control software and planetarium software and sequencing software and, and....well you get the idea. BUT, by using ASCOM standard drivers (which is THE standard), many if not most all equipment manufacturers use and software developers interface with, most of the times you get everything talking to each other and working as it should. It's actually amazing any of it works at all...lol. You also tend to NEVER update your equipment control computer too, simply because once it works...leave it alone.
However, ASCOM is an open group of independent developers and manufacturers who recognize the need to standardize. Astronomy is a big business from backyard hobby to advanced amateurs to professional research, pretty much using the same or very similar equipment and software. That amateurs have access to research grade equipment is only limited by your pocket book. Not sure there is enough momentum or critical mass in rocketry for this type of standardization, but perhaps there are enough of us out there with the technical knowledge to code/script at that level?
 
Steve,
If you have been following some of the other tracker threads, you may notice that it is a very small niche market. The thing you could do, [and not really a joke], is to buy at least thousand trackers [maybe five thousand] from each of the mfr's that you would want interoperability from with that requirement placed on it, and let them work together to solve it. Without a motivating market opportunity, I think we are lucky to have what we have as it is.

Something incrementally more practical would be to talk to the mfrs to find out what the threshold quantity would be for the idea to become economically viable. Then, if you could organize a group buy/kickstarter, who knows...

br/

Tony
 
Steve, I think the use cases for GPS and rocketry is still evolving and innovating. In my opinion it might be a bit early to develop standards. My opinion.
 
Steve, I think the use cases for GPS and rocketry is still evolving and innovating. In my opinion it might be a bit early to develop standards. My opinion.
Disagree. There are enough products out there that you analyze each one, note the differences, note the commonalities, identify what is missing that is desirable, design a standard information architecture around the analysis then write the standards. If the information architecture is designed robustly, it can be extended and enhanced in the future. This is pretty basic IT architecture stuff. All it take is time, money, industry experts and IT architecture expertise. Oh, yeah, all in short supply. So, there it is...
 
Lol...we do this on the astronomy / astrophotography side! We have universal astronomy standards for communication: ASCOM standards drivers (On the windows side), and ASCOM/Alpaca & INDIGO (on the mac/linux side) and between mounts, and auto-focusers, and rotators, and filters, and cameras and auto-guiders, and environment controls and dome control, and power management, and guiding software and stacking software and imaging software, and scope control software and planetarium software and sequencing software and, and....well you get the idea. BUT, by using ASCOM standard drivers (which is THE standard), many if not most all equipment manufacturers use and software developers interface with, most of the times you get everything talking to each other and working as it should. It's actually amazing any of it works at all...lol. You also tend to NEVER update your equipment control computer too, simply because once it works...leave it alone.
However, ASCOM is an open group of independent developers and manufacturers who recognize the need to standardize. Astronomy is a big business from backyard hobby to advanced amateurs to professional research, pretty much using the same or very similar equipment and software. That amateurs have access to research grade equipment is only limited by your pocket book. Not sure there is enough momentum or critical mass in rocketry for this type of standardization, but perhaps there are enough of us out there with the technical knowledge to code/script at that level?
YUP. I haven't been doing as much astronomy as rocketry the last 5 years, but the amateur astronomy community is the model for how to get it done. If anyone in the rocketry community wants to understand what it takes, the ASCOM folks are the ones to talk to.
 
NMEA is a standard, however it's a bit "chatty" (especially the later uBlox implementations) and you can be more efficient by taking the data that you really care about and packetizing it into a binary stream. Eggtimer doesn't do that... we send the raw NMEA stream. Others do, probably to reduce the size of the transmission and possibly to add other data, but of course we can't speak for anyone else. There's lots of software out there that will decode raw NMEA data, whereas a proprietary data format is most likely theirs and theirs alone.

My emphasis above - but Chris is correct. Featherweight packets include more information in a smaller footprint than a verbose NMEA packet.

The thing you could do, [and not really a joke], is to buy at least thousand trackers [maybe five thousand] from each of the mfr's that you would want interoperability from with that requirement placed on it, and let them work together to solve it.

Unless the feature would increase market size (not likely) or market share (not likely - probably the opposite) then this would just be pre-ordering the next "N" years supply and the vendor would still have to program / test / ship and handle customer support for the next N years based on a one time up front 'payment'. After the first year, it would feel like indentured servitude... (based on the definition I just looked up, it would actually BE indentured servitude...)

Realistically, any vendor would be better off getting into a different market... something like RC planes or drones...

Time for me to get back to software... ;)
 
There are enough products out there that you analyze each one, note the differences, note the commonalities, identify what is missing that is desirable, .....
You do not know what is "missing" until an innovator adds a feature that is in the bucket of "I didn't know I wanted that but now that I see it I have to have it".

As for simple tracking GPS applications, good standards already exist as mentioned. APRS or plain NMEA ascii sentances to a serial port. There is a plethora of software available to support those standards.
 
the vendor would still have to program / test / ship
With the current chip shortages it's not happening, regardless. Anyone tried to buy their favorite electronics lately? StratologgerCG ? JL Altimeter3? RRC3? RRC2+? T3 Tracking system? Flightsketch products (new one's majorly delayed)?
 
With the current chip shortages it's not happening, regardless. Anyone tried to buy their favorite electronics lately? StratologgerCG ? JL Altimeter3? RRC3? RRC2+? T3 Tracking system? Flightsketch products (new one's majorly delayed)?

You are correct. If one can even get the parts, the prices are also generally higher than they were before.
 
The aftermarket electronic parts dealers are having a field day. I got a quote for a part that Mouser won't have until February, the aftermarket dealer wanted $2.50 each for a normally 80 cent part. Unfortunately, the devices that use this part have multiples of them in it, so it would be economically unfeasible to get it from them just so I could save a few months shipping time, and I wouldn't be able to discount them for the Holiday Sale. Most rocketry people would rather wait and save some money than get it now and pay more... for most of the country, flying season is going to shut down in December until the Spring anyway.
 
Steve, I think the use cases for GPS and rocketry is still evolving and innovating. In my opinion it might be a bit early to develop standards. My opinion.
You do not know what is "missing" until an innovator adds a feature that is in the bucket of "I didn't know I wanted that but now that I see it I have to have it".

As for simple tracking GPS applications, good standards already exist as mentioned. APRS or plain NMEA ascii sentances to a serial port. There is a plethora of software available to support those standards.
Freedom to innovate has always been cited as a reason to resist standards, but I’ve never seen a standard yet that didn’t evolve. Also, having the manufacturers work together to discuss standards early is much better than later. Later on the manufacturers will say that their proprietary protocols have evolved too far to join into a standard.
So the flyers end up married to one brand or having multiple applications to use for tracking.
I’d like to be able to use one application with multiple manufacturers’ hardware.
 
Great topic Steve!

If we are "voting" as a few have mentioned the amateur radio APRS format is one that would work. APRS is a well known data transmission standard.

Name, location, altitude plus a message format that could contain proprietary info such as gps lock , temp, #of sats, continuity... Another benefit is the APRS protocol allows for compressed data format to squeeze data into tighter bursts. If using in a point to point system using non amateur radio frequencies a near real time stream could be done, you really don't want to do this on the amateur APRS band (maybe another amateur freq...).

If folks have their basic Amateur licence the world can open up and multiple recovery teams could see where other teams are, rocket components, distances etc. We did this many years ago with multiple recovery teams , multiple parts coming down. It was the main reason our team got their licences, plus we had higher power range radios for voice communication, with the digital stuff out now and offering of groups you can keep things a bit more tidy.

Nema is the wrong format, which sentence do you send? how would you deal with proprietary information. Don't get me wrong it works and is simple in a point to point system but not very flexible.

David
 
Freedom to innovate has always been cited as a reason to resist standards, but I’ve never seen a standard yet that didn’t evolve.
I have never seen a standard applied to product with a total potential market size less than 10K

Also, having the manufacturers work together to discuss standards early is much better than later. Later on the manufacturers will say that their proprietary protocols have evolved too far to join into a standard.

Correct, I for one do not have the time to implement code to comply to standard which adds no additional functionality to the product and will not bring a financial reward for that addition time spend. We also have a dream: breaking even on our time spent.

So the flyers end up married to one brand or having multiple applications to use for tracking. I’d like to be able to use one application with multiple manufacturers’ hardware.
What applications? Applications developed primarily by hardware manufacturers optimized for their proprietary hardware?
 
So the flyers end up married to one brand or having multiple applications to use for tracking.
I’d like to be able to use one application with multiple manufacturers’ hardware.

The flip side is flyers just choose those that keep to a standard... Unfortunately rocketry is such a small crowd creating standards can be time consuming and the return is not all that great.

I agree one app(s) to multiple hardware. There are a couple there already, BRB, Altus Metrum maybe more Those are the only ones I have used or played with.

I was/am working on a hardware solution using an SDR for frequency flexibility but interpreting data formats (many unpublished) was really time consuming, with some adding more data after launch is detected (real pain!!). I moved into a simpler direction using those that already use APRS, boom most problems solved. Quite a few opensource software solutions on various platforms to do the deed too.

I am suspecting that if you don't do amateur radio, the APRS direction is not even thought of.

David
 
Last edited:
Recent posts about GPS tracker interfaces make me wish that our manufacturers would work together to develop a standardized live data stream at the ground station end so that real time tracking could be done with the flyer’s choice of software, regardless of tracker.
Is there any reason this isn’t possible?
If this is possible, is there anything I can do to facilitate it?
The problem with this is that a significant part of the investment with many GPS trackers is their interface software (and sometimes their hardware).

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?

Such a strategy would favor tracker manufacturers who don’t invest in their own interface (hardware or software) but benefit from the interface made by someone else or by one of their competitors.

The general economic fact is that in competitive markets there is no motivation to give up any competitive advantage. I’m not judging this, it is simply a fact of life.
 
Last edited:
John and Dan are right...

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

Suppose we got all the motor vendors (naively) to standardize on a simple common hardware design so that reloads from any vendor would work in any hardware.

The first thing I would do (or someone would do) is get a bulk order of said hardware produced for pennies on the dollar out of China and sell it through Amazon so I (they) get a little profit for each unit but don't deal with shipping or anything. And also cheap enough to just send you another if it catos...

But now that the hardware is standard - hmm.. so are the reloads.... I (they) set up a cheap factory across the border in Mexico and produce "acceptable" reloads that anyone who likes cheap stuff would be happy enough with.

At this point there is too little profit left so the motor vendors look for other jobs (with proprietary profits) and your on site vendors quit showing up because the profit margin left can't pay for a decent living.

This thread makes me want to build the next RC plane I bought and work on iPhone (and Android) software for it instead ... and just switch hobbies...

/kjs

ps - no, I still have plans for what to do with Featherweight Tracker next....
 
Last edited:
John and Dan are right...

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

Suppose we got all the motor vendors (naively) to standardize on a simple common hardware design so that reloads from any vendor would work in any hardware.

The first thing I would do (or someone would do) is get a bulk order of said hardware produced for pennies on the dollar out of China and sell it through Amazon so I (they) get a little profit for each unit but don't deal with shipping or anything. And also cheap enough to just send you another if it catos...

But now that the hardware is standard - hmm.. so are the reloads.... I (they) set up a cheap factory across the border in Mexico and produce "acceptable" reloads that anyone who likes cheap stuff would be happy enough with.

At this point there is too little profit left so the motor vendors look for other jobs (with proprietary profits) and your on site vendors quit showing up because the profit margin left can't pay for a decent living.

This thread makes me want to build the next RC plane I bought and work on iPhone (and Android) software for it instead ... and just switch hobbies...

/kjs

ps - no, I still have plans for what to do with Featherweight Tracker next....
I like Kevin Small’s projected scenario about what would happen with standardization with high power rocket motors. We’ve all seen the same thing happen with personal computers.

At the risk of being heretical, high power rocketry is a great but also an expensive pastime. Of all of its vendors, few can do it as a full time job and there’s very little money to be made doing it. So having any successful rocketry business give up their slim competitive advantage could mean that they go out of business as a consequence.

Those of us who are able to afford our beloved sport of high power rocketry shouldn’t push for changes that might drive its surviving vendors out of business.
 
Kevin,
I’m sorry if asking about standardization makes you feel like walking away; that certainly wasn’t my intention. But it does illustrate the precarious nature of rocketry software and hardware. What if you did walk away?
Actually I would have thought that a standard protocol would create an opportunity for you to sell the brilliant application that you currently package only with the featherweight tracker for use with other hardware.

Dan,
I have to giggle a little at your negative comparison of this to the PC industry, an industry that was slow starting until proprietary firmware was reverse engineered. Then it became an incubator for innovation and resulted in creating more millionaires and billionaires than any previous industry. Was it perfect, no, but none of the lessons from the PC revolution point towards closed protocols and dedicated hardware. If they did, dongles would be popular. 😀
 
Actually, a number of manufacturers, notably Apple, have done quite well forcing everyone into their closed ecosystem. Ditto for Microsoft. If you're a software developer and you want to sell to their customers, you have to play by the vendor's rules. Such as not allowing you to side-load software into iOS... but that's another ongoing thread. An essentially closed hardware-software system isn't necessarily a bad thing... think of something like a baby monitor, does it really matter what standards (if any) they use if it gets the job done?
 
Kevin,
I’m sorry if asking about standardization makes you feel like walking away; that certainly wasn’t my intention. But it does illustrate the precarious nature of rocketry software and hardware. What if you did walk away?
Actually I would have thought that a standard protocol would create an opportunity for you to sell the brilliant application that you currently package only with the featherweight tracker for use with other hardware.

Dan,
I have to giggle a little at your negative comparison of this to the PC industry, an industry that was slow starting until proprietary firmware was reverse engineered. Then it became an incubator for innovation and resulted in creating more millionaires and billionaires than any previous industry. Was it perfect, no, but none of the lessons from the PC revolution point towards closed protocols and dedicated hardware. If they did, dongles would be popular. 😀
Steve and Kevin,

I think we’re all old enough to have lived through the computer revolution that benefited the consumers and PC-compatible makers alike from having a standardized PC. But the biggest loser from this “standardization” was IBM.

But the difference between this and four decades ago is that IBM was a billion dollar company who could survive losing the income from its premiere product, the PC because it was sold at a lower cost by a dozen other companies — even though the availability of low cost compatibles helped trigger the computer revolution.

And giggles aside, I proudly benefited from the computer revolution and spent most of my career working in it. The PC-compatible and its BIOS were brilliant designs for a standard architecture that I used professionally for a decade. I am anything but negative about them. But the difference from IBM is that no vendor in high power rocketry is well enough off to survive after letting its competitors standardize on it to make it an undistinguishable product.

One of the other lessons from Silicon Valley was that by the early 2000s the industry had become the victim of its own success. The widespread availability of standardized memory chips led to a worldwide glut and drop in prices that led to an industrywide contraction with large-scale layoffs, a major out-sourcing of jobs to India that were necessary for many companies’ survival, and ultimately a nationwide recession compounded by 9/11. But from the standpoint of consumers, this drop in prices resulted in many much more affordable electronics and computer products.

So there is no single, universal economic perspective that one can argue that something is good or bad for everyone. A standardization that benefits a lot of competitors would be at the detriment of the company who’s success had depended on keeping its innovative product proprietary.

Specifically, rocketeers benefit in the short term from having lower cost motor reloads, or from having one device with software can receive GPS data and can generate voice from all GPS trackers. But no rocket motor producer, or GPS tracker manufacturer would benefit from such a standardization of their product and some might find the resulting loss in revenue not worth continuing it business.
 
Personally I think the idea of a "standard" GNSS tracking system is a noble goal, but it does rein in evolution and development to some degree. There are a few systems out there, from seriously cheap to seriously spendy, which is wonderful for our niche application. Featherweight has some amazing features like being able to relay packets from lost rockets and other such things. This is really a leap in technology that would not likely have happened (certainly no as quickly) if we had to compose and agree on a standard and then have it implemented. Other systems work very well as they have been created too.

For anyone building to the "standard" would they be forced to add features as the standard evolved? So many questions and certainly more than at least two cans of worms. It would be nice to have some standard outputs available for some situations, but not for most users. For instance I am currently adding another telemetry stream (up to 1W at 915MHz) to my VTS to provide location information to my antenna tracker . This will be the NMEA streams as mentioned upthread. So I will have three totally independent tracking systems on that rocket.

So, although it is a noble goal to have compatibility in the real world, IMHO, it will limit development and stifle creativity. The communications area is constantly evolving and producing new features and capabilities.

I will add that having something able to spit out NMEA streams to interface to more general hardware would be a nice option to have, if the developers can see the value in adding it. I suspect the number of users that would use such a system would be quite small. Likewise supporting something like APRS would be handy too.
 
Last edited:
I’m sorry if asking about standardization makes you feel like walking away; that certainly wasn’t my intention. But it does illustrate the precarious nature of rocketry software and hardware. What if you did walk away?

I'm not really going to walk away; still have other things in mind and if I get them all done on iOS, then maybe I'll still be up for a full rewrite to support the other OS...

Actually I would have thought that a standard protocol would create an opportunity for you to sell the brilliant application that you currently package only with the featherweight tracker for use with other hardware.

I have thought of that scenario and it's implications. 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. Also actually FCC certified. That level of engineering had a price involved and therefore some might say a premium for price (for those that "only want to find their rocket" at least).

He currently sends me some royalties for each unit sold. If I went to supporting other hardware, it would cut into those royalties as some people would choose less expensive options - because that's what people do. So to make up for the difference, I would need to charge more for the software itself - and maybe give Adrian a cut as well (since I 'sold out'). But a user also only buys the software once vs multiple trackers and replacement trackers for failed deployments. So now the cost of the software has to be pretty high to make up for an even lower volume - likely to the point where the threads on TRF would be complaining about the high cost of software...

But now, back to the tracker. Now that there is common software, some people would just want the very cheapest tracker they could get. So like the motor hardware scenario above, someone would do a dirt cheap simple one with maybe range to only 30k feet or so, get it manufactured in China for cheap and sold on Amazon. Like the motor hardware scenario, it wouldn't be worth anyone's time to make exceptional tracking hardware because the volume of those users would be too low to make it worth the time.

Now, back to the software. I have to sell it for a high price to make up for all the other things above and someone else says "I only need one screen to find my rocket" and makes a super simple app for just that and sells it at a quarter of the price (or free). Now that market went away too.

And it isn't all about money - but it is about what vendors are going to do with their "free time" (because most have regular jobs and so this is in their free time - which should maybe be spent with family - or relaxing - instead).
 
Back
Top