GPS, barometer and microprocessor

Hi,

I'm using a GPS to know where my rocket is, but the altitude of a gps is innacurate, by design. So, I had an idea, but I wanted to know if someone else did that before.
The idea is to use a real altimeter (barometer), and a little microprocessor that replace altitude in the NMEA sentence for the one from the barometer.

Did someone else did that before ? I would be practical for the Rocket Locator software.

I think most people that use both just handle them separately. Altitude isn't really important for tracking anyway. Recover the rocket, get the data from the altimeter. In theory, doing what you suggest wouldn't be that hard. You might need a somewhat fast micro, with at least 2 hardware serial ports to reduce overhead. You would need to parse the strings, replace the altitude, and replace the checksum if there is one, I think NMEA uses checksums.. If I were to do it, I would start with a version that just re-transmits everything you get to make sure you have the basics before trying to modify things.

Yeah, It's been done in the manner of an EggFinder TRS. The Baro altitude is telemetered instead of the GPS altitude to the EggFinder LCD. https://www.eggtimerrocketry.com/page23.php. The only setback is the TRS doesn't record the positions, its purpose
is only to find the rocket. You can try logging the on air positions with your tracking software but that might be +/- as far as recovering all the positions. A logging board for the TRS or a TRS like device would be nice. There is a logging board for the
earlier versions of the EggFinder GPS tracker. Kurt

You can easily connect a TRS to an OpenLog datalogger, three wires.... two power plus one data. When I get a chance to revise the TRS manual, I'll write it up.

fantasiiio said:

Hi,

I'm using a GPS to know where my rocket is, but the altitude of a gps is innacurate, by design. So, I had an idea, but I wanted to know if someone else did that before.
The idea is to use a real altimeter (barometer), and a little microprocessor that replace altitude in the NMEA sentence for the one from the barometer.

Did someone else did that before ? I would be practical for the Rocket Locator software.

Click to expand...

Personally, I wouldn't touch the NMEA sentences from the GPS but add additional proprietary sentences (starting with P). You can use Garmins barometric altitude sentence as an example:
https://aprs.gids.nl/nmea/#rmz

Reinhard

Reinhard said:

Personally, I wouldn't touch the NMEA sentences from the GPS but add additional proprietary sentences (starting with P). You can use Garmins barometric altitude sentence as an example:
https://aprs.gids.nl/nmea/#rmz

Reinhard

Click to expand...

That's what we do with the TRS... there's a framing character before the added data to tell the receiver what kind of data it is, and there's a terminating character so we know when it's done. That's the easy part. The hard part is making sure that this data is inserted into the data stream in the dead space between the NMEA sentences, without disturbing them.

You are correct about the inaccuracies of GPS. It is caused by the geometry of the system. The way it works out is that the vertical error is about three times the horizontal error.

This used to be a great problem years ago when "selective availability" was turned on. Your ground position was guaranteed to be within 100m 50% of the time IIRC. That also meant that the altitude reading error was greater than 300m 50% of the time!

These days the altitude error is greatly reduced (because SA has been switched off) but people really bag the accuracy. It isn't that bad really, within about 30' most of the time from what I have seen.

With altitude it depends upon what you are flying. The high-altitude Balloon Guys sometimes fly a sirfIV chipset next to a ublox and when floating lazily at altitude the altimeter readings are very close to one another in spite of the vagaries of each individual chipset. In the Dynamics of a rocket flight the limitations of the different chipsets are seen.

The difference in altitude will not make a significant difference to the geometries of the pseudoranges in the solution. 30km closer in the 20000km orbit is not significant.

Some receivers do have better front ends and also process the correlators (and/or have more of them) much better than others, hence the difference in performance between chipsets with different flight profiles.

If you really want some improvement go for the multi-system sets that are available these days. Because the different systems use different frequencies the pseudoranges from the satellites can be corrected for things like tropospheric variation (which varies the pseudorange by about 1m IIRC) and other factors. That tightens up all the position determinations. It still does not get rid of the geometry issue making the vertical about three times worse than the horizontal, but everything is smaller than it otherwise would be :wink:.

Don't forget the speed and altitude limitation imposed on consumer GPS devices too. Highest I've seen is 150,000 feet guaranteed but of course according to the Wassenaar Arrangement it can't exceed 1200 mph. Some chipsets stop at 60,000 feet no matter what the speed. Plus high G forces and the Doppler effect wreck havoc with GPS signal reception on the "up" side. Hoping for a lock as the rocket is coasting up at <1200mph/1000knots is desirable and at least getting one when the drogue is deployed on the
downside is helpful for drift trending. Kurt

Interesting, I didn't realize Wassenaar was less restrictive than COCOM. Anybody playing in that area yet?

dhbarr said:

Interesting, I didn't realize Wassenaar was less restrictive than COCOM. Anybody playing in that area yet?

Click to expand...

COCOM expired in 1994: https://en.wikipedia.org/wiki/Coordinating_Committee_for_Multilateral_Export_Controls

I believe the limits established then remain unchanged. It has been discussed here before about the prospect of getting access and using an unrestricted GPS chipset but I recalled it required a lot of paperwork, waivers and money. Something
in excess of $10,000 to be able to use a device. Perhaps they've done that at UP Aerospace given the projects they've done?
Some manufacturers interpret the rules differently. 1200mph OR >60,000' they lock out. The high altitude balloon guys usually keep tabs on what chipsets keep working above 60k if it's not clear in the particular spec sheet of a GPS chipset.
Some keep working at altitude 'cause they ain't going nowhere near 1200mph with a balloon. Kurt

ksaves2 said:

COCOM expired in 1994: https://en.wikipedia.org/wiki/Coordinating_Committee_for_Multilateral_Export_Controls

I believe the limits established then remain unchanged. It has been discussed here before about the prospect of getting access and using an unrestricted GPS chipset but I recalled it required a lot of paperwork, waivers and money. Something
in excess of $10,000 to be able to use a device. Perhaps they've done that at UP Aerospace given the projects they've done?
Some manufacturers interpret the rules differently. 1200mph OR >60,000' they lock out. The high altitude balloon guys usually keep tabs on what chipsets keep working above 60k if it's not clear in the particular spec sheet of a GPS chipset.
Some keep working at altitude 'cause they ain't going nowhere near 1200mph with a balloon. Kurt

Click to expand...

Eggfinders work in a balloon above 60K, so at the very least the SIRF IV chipset is enforcing the COCOM limit properly. I would be surprised if a UBlox 7 did not as well.

cerving said:

I would be surprised if a UBlox 7 did not as well.

Click to expand...

From first hand experience, Ublox-7 works just fine in rockets above 60K feet altitude. However, they do enforce a hard limit on velocity at just over 500 m/s. (1640 feet/sec)

ksaves2 said:

I believe the limits established then remain unchanged.

Click to expand...

GPS limitations changed recently.

GPS used to be on the US Munitions List but except for GPS systems
having specific features (not present in consumer units) they were dropped last year.

Now they fall under the export controls of the State Department. Which I don't understand. Most GPS systems would appear to fall under ECCN 7A994. That includes this note:

License Requirement Notes: Typically
commercially available GPS do not employ
decryption or adaptive antenna and are
classified as 7A994.

Click to expand...

ECCN 7A105 is more specific to GPS systems designed for airborne applications that provide data at speeds over 600 m/s. I don't see any mention of encryption or fancy antennas there. (The Munitions list does mention those things though.)

It is very confusing but it does appear that the altitude limit is gone.