Highest Altitude GPS?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
It takes about 30 seconds to receive the ephemeris data. For modern all in view receivers that is the limiting step. 30 seconds or so after power up and you should get data.

When I bought a Big Red Bee I looked at the heat shrink meant to keep the battery in place but also covering the patch antenna and realized that would cause trouble. Without the heat shrink it had a position 31 seconds after a cold start. It took 45 to 50 seconds with the heat shrink. The heat shrink changed the center frequency of the patch enough to degrade performance. The heat shrink wasn't all bad news since the RF inputs on GPS engines can be extremely static sensitive.

Another thing to worry about with GPS is that the national ranges will occasionally test weapon systems in a GPS jamming environment. The jammers of course cover a lot more space than that. A NOTAM is typically issued when this happens.

Could cutting a hole above where the gps pin is bring back that performance? I heat shrink and epoxy my gps modules and other components.
 
The site says: COCOM limits can be removed from a specific unit at time of purchase. I thought there was a waiver process with authorities to petition in order to fly with no limits. I get the impression that one would have to "prove" they had dispensation in the first place to get the limits removed. Correct me if I'm wrong. If it was that easy to legally get a chipset without limits, more makers would be providing it for their trackers
For sport flying, using a chipset without limits would be a waste as one only needs the location data in order to get the rocket back. Once the speed drops under the limit and G forces come down, positions start coming in again so one can effect a recovery. Dynamic flight data can be downloaded from the electronics then. The most important reason for a GPS tracker is get the rocket back with a totally sight unseen flight. Kurt
 
Could cutting a hole above where the gps pin is bring back that performance? I heat shrink and epoxy my gps modules and other components.
Probably not. The important space is where the electric field lines are fringing off the edges of the patch and returning to the ground plane. They don't go in a straight line.
 
The site says: COCOM limits can be removed from a specific unit at time of purchase.
The document I found there appears to be from before the US Munitions list was revised to remove the COCOM limits. (There are still restrictions on some GPS systems. Those designed to receive the Y code for example.) In any case, you could get a GPS unit with those limits removed but there were strings. You had to pay for the privilege and the resulting hardware was export controlled. Violate that and you could end up in jail. Noting that "export" has a very broad meaning and doesn't require shipping it out of the country.
 
The document I found there appears to be from before the US Munitions list was revised to remove the COCOM limits. (There are still restrictions on some GPS systems. Those designed to receive the Y code for example.) In any case, you could get a GPS unit with those limits removed but there were strings. You had to pay for the privilege and the resulting hardware was export controlled. Violate that and you could end up in jail. Noting that "export" has a very broad meaning and doesn't require shipping it out of the country.

Ahhhhh, That’s what I thought. Pay a bunch of money that one doesn’t have to do as all they want to do whatever they want to get their rocket back. Launch whatever rocket one want’s with a GPS tracker, with whatever system they want to use and they will stand a much better chance of getting their rocket back period. There are limits notwithstanding but once a rocket goes under them, (in descent) as long as they get some fixes, they’ll likely get their project back.

Limits notwithstanding, once a rocket goes under those limits, positions start coming in and one can find the danged thing! Download the dynamic data once the rocket is back, off the altimeters when recovered. There is nothing to be gained from realtime data (unless one doesn’t expect to get said rocket back) So plan on tracking and getting one’s rocket back!!

Kurt
 
300,000 feet is the radio range of the Featherweight GPS tracker with its standard antennas. With a directional ground antenna the range can be higher. If your rocket goes above 50 km AGL (164,000 feet) or 500 meters/second (~Mach 1.45) the u-Blox GPS receiver will withhold its data until your unit is below that speed and altitude. In the meantime you will still have communication and data on the battery voltage, communication signal strength, etc.

Would the data still be downloadable from the tracker when it is recovered? Just not transmitted live?
 
In the event of a recovery malfunction, in flight telemetry allows the data to be recorded even if the rocket is destroyed.

Plus, it adds fun to the flight, hearing real time updates and not having to wait to see the flight data.

If you're satisfied with just the landing location, then that's great. But my goal is to have as much accurate flight data as possible sent directly to me.
 
Would the data still be downloadable from the tracker when it is recovered? Just not transmitted live?

No. The GPS receiver, that is part of the tracker, withholds that information by itself. The rest of the tracker never sees this information.

u-Blox, the company that manufactures that receiver module, has been approached in the past by multiple persons regarding an "open" version of their module and it is apparent that they are not interested. I guess it is safe to assume that they don't want to deal with the potential regulatory headache or potential for misuse for a completely negligible niche market.
In addition, many of their modules are ROM based, so an updated firmware for those would need a dedicated manufacturing run.

Reinhard
 
If you really must have GPS data for the entire flight and can wait for it, the solution is to record the GPS detector (MAX2771 or equivalent) output and process it on the ground.
 
No. The GPS receiver, that is part of the tracker, withholds that information by itself. The rest of the tracker never sees this information.

u-Blox, the company that manufactures that receiver module, has been approached in the past by multiple persons regarding an "open" version of their module and it is apparent that they are not interested. I guess it is safe to assume that they don't want to deal with the potential regulatory headache or potential for misuse for a completely negligible niche market.
In addition, many of their modules are ROM based, so an updated firmware for those would need a dedicated manufacturing run.

Reinhard

Good to know, thank you! I’m nowhere close to either of these conditions but was curious and always appreciate the wealth of knowledge that can be found here.
 
If you really must have GPS data for the entire flight and can wait for it, the solution is to record the GPS detector (MAX2771 or equivalent) output and process it on the ground.
Do you have any 4-5Ms/s data loggers you can recommend for this job?
 
Do you have any 4-5Ms/s data loggers you can recommend for this job?
No. Or maybe. I have thought about it. Back when the SE4150 was in production.

The first thing you need is a MCU that has a 4 bit SD interface. Getting to be fairly common these days. (The Teensy 3.6 I have will do 25MB/s transfers so the slow step is not the data transfer but the SD internal operations.) Skipping anything resembling a file system is recommended.

Then you have to get the serial bit stream into the MCU. I suspect that an SPI port (using DMA) can be pressed into service here. If not, then some serial to parallel glue will be required.

With luck and a good DMA system, the MCU will have very little work to do.

I remember reading about some other efforts along this line: https://unreasonablerocket.blogspot.com/2015/07/gps-on-several-fronts.html
 
No. Or maybe. I have thought about it. Back when the SE4150 was in production.

The first thing you need is a MCU that has a 4 bit SD interface. Getting to be fairly common these days. (The Teensy 3.6 I have will do 25MB/s transfers so the slow step is not the data transfer but the SD internal operations.) Skipping anything resembling a file system is recommended.

Then you have to get the serial bit stream into the MCU. I suspect that an SPI port (using DMA) can be pressed into service here. If not, then some serial to parallel glue will be required.

With luck and a good DMA system, the MCU will have very little work to do.

I remember reading about some other efforts along this line: https://unreasonablerocket.blogspot.com/2015/07/gps-on-several-fronts.html
One of the features of the Teensy 4.1, besides being crazy stupid fast, is the ability to add PSRAM and flash storage directly on the board.

https://www.pjrc.com/store/psram.html
While in flight, write to RAM or the on-board flash and then once you're idle, flush it out to the SD when write speed isn't a concern.

Not sure what data rate you're logging but 16Mbytes holds alot of text.
 
Not sure what data rate you're logging but 16Mbytes holds alot of text.
2MB/s or more. (Actual rate depends on what you want. Both I and Q data? How many bits per sample? Sample rate?)
 
Aren't there at least 4 different satellite navigation systems?

What if you limited your GPS reception to just the Russian and Chinese satellites?

Would you then still be subject to the Cocom restrictions?
 
Aren't there at least 4 different satellite navigation systems?
What if you limited your GPS reception to just the Russian and Chinese satellites?
Would you then still be subject to the Cocom restrictions?
On my UBLOX M8, I've tried just using GLONASS and BEIDOU and it still locks me out on launch.

WRT logging, I am able to get about 1800 lines per second of 80 char each using an ESP32 and a fast SD card. This includes the cycles to build the 80 char log line each cycle. The trick I've found is to not open or close the file each cycle, as those are really expensive transactions. The other important factor is the speed of the SD card. So, I will open a log file at launch detect and then close it after apogee to get better performance on the way up. The danger is if you don't close the file you lose the contents. ESP32 also has two cores, so one can be doing this while the other core is doing something else just as fast.
 
This thread has inspired me to reevaluate my GPS unit. In general, I have been happy with my UBlox M8N, but I just re-read the M8N manual and then read the Ublox M9N manual and it would appear there are considerable improvements in the M9N. I am not sure if the stated specs are inclusive of the Cocom/ITAR limits, but it looks like the M8N has an altitude limit of 50K meters and vertical velocity of 100 meters/sec, while the M9N indicates an altitude limit of 80K meters and vertical velocity of 20,000 meters/sec (44K mph). The vertical velocity of the M9 seems impossible and/or like it would require unlocking. Does anyone have experience with the Ublox M9? I've ordered one to compare performance.

Here is the M8N spec (see the Airborne <4g):
Screen Shot 2020-11-29 at 5.20.16 PM.png

...and the M9N spec:
Screen Shot 2020-11-29 at 5.17.44 PM.png
 
... the M9N indicates an altitude limit of 80K meters and vertical velocity of 20,000 meters/sec (44K mph). The vertical velocity of the M9 seems impossible and/or like it would require unlocking. ...

I think the 20,000 m/s is a typo. I have seen other versions of the data sheet on the Ublox website that list max operational velocity for the M9N as 500 m/s.
 
Last edited:
What about the acceleration?

The platform states "Airborne <4g".

Don't Estes rockets exceed 4g?

It seems like this limitation might be reached before the speed or altitude...

If the acceleration is not strictly enforced like the other limits, then why do they explicitly mention 1g, 2g and 4g?
 
What about the acceleration?

The platform states "Airborne <4g".

Don't Estes rockets exceed 4g?

It seems like this limitation might be reached before the speed or altitude...

If the acceleration is not strictly enforced like the other limits, then why do they explicitly mention 1g, 2g and 4g?
Acceleration is not enforced. At higher accelerations the Doppler freq change rate becomes higher which makes the receiver harder to track the signal. So the airborne modes allow a wider range doppler shift change rate at the expense of positional accuracy.

The 4g loss of lock will only (likely) happen if the receiver depends on satellites mostly overhead. If you are using satellites on the oblique then acceleration relative to them will be less than the vertical acceleration. So in summary, that 4g limit is not a hard limit, it will depend....
 
Last edited:
This thread has inspired me to reevaluate my GPS unit. In general, I have been happy with my UBlox M8N, but I just re-read the M8N manual and then read the Ublox M9N manual and it would appear there are considerable improvements in the M9N. I am not sure if the stated specs are inclusive of the Cocom/ITAR limits, but it looks like the M8N has an altitude limit of 50K meters and vertical velocity of 100 meters/sec, while the M9N indicates an altitude limit of 80K meters and vertical velocity of 20,000 meters/sec (44K mph). The vertical velocity of the M9 seems impossible and/or like it would require unlocking. Does anyone have experience with the Ublox M9? I've ordered one to compare performance.

Here is the M8N spec (see the Airborne <4g):
View attachment 440449

...and the M9N spec:
View attachment 440448


Good find about the M9N. Glad to see they are relaxing the altitude limit. How many actual amateur flights have gone over 164,000 feet in the last 5 years? Two? Five? Nevertheless, I can sympathize with people modelling their N5800-N5800 in RASAero and thinking to themselves "someday." (I'm of them) Too bad they're not allowing 100 km, which is the generally-accepted boundary for space. Maybe when they come out with the Max-9Q module with a built-in antenna it will be time for me to order modules again.

An important note about the M8N spec is that the 100 m/sec vertical velocity limit is, like the 4G limit, more of a suggested range for good performance and not a hard limit, since real life data shows valid solutions provided up to 500 m/sec (over Mach 1.4). Maybe that's why the "sanity check type", only lists Altitude when using the Airborne dynamic platform model?

I agree they probably missed a decimal point or two in the new vertical velocity spec.
 
Last edited:
I sent an email to Ublox a while back asking for SAM and CAM M9 modules...still waiting for a response.
 
I ordered this CAN version of the M9 off of AliExpress. Orders from China usually take 2 weeks for me.
Cool. Those are both Neos though. Ublox doesn't list a CAN or SAM part for the M9 yet (both have integrated antennas, so +1 for ease of rocket tracker design/use).

The SAM-M8Q is a great little unit that's easy to integrate. Hopefully Ublox releases an even better M9 one soon. If the M9 really does have relaxed speed restrictions, it'd be awesome to have in a rocket tracker. I really, really hate it when my trackers stop reporting position while they're >500m/s. If the M9s are limited to about 500 like the 8, then, well, never mind. (Long live the SAM-M8Q.)
 
Last edited:
Good find about the M9N. Glad to see they are relaxing the altitude limit. How many actual amateur flights have gone over 164,000 feet in the last 5 years? Two? Five?

I had one such flight. We were getting packets and then they suddenly stopped. We weren't watching the altitudes in real time though (tracking 3 gps transmitters), and for a few minutes, I essentially lost situational awareness on the flight. It was confusing when the packets stopped and then confusing again when they started a minute or so later.

Jim
 
Back
Top