CoCom GNSS limits (maximum altitude/elevation+speed)

[kozuch]

I wonder whether RTKLIB does actually implement the CoCom GNSS limits that are required for hardware receivers? The limits impose a maximum altitude/elevation of 18km and maximum speed of 1000 knots. I wonder if this is implemented for computation of a "single" solution from raw GNSS observations. Where is the code that deals with the computation of altitude and speed for "single" solution?

I would actually be happy to hear no limits are applied in code. There is a growing demand for "unlocked" GNSS receivers in the fields of high-altitude ballooning or amateur rocketry etc. I think being able to use RTKLIB for these may be a huge plus and possibly cost saving for these projects.

[tomojitakasu]

No implementation in codes.

But if the receiver hardware is unable to output raw data, RTKLIB is also unable to compute PVT. I'm not sure whether the CoCom limitation is applied to raw data or not. It's hard to be tested without GNSS simulators. I would like to know the limitation of raw data in each receiver.

Anyway, in OSS, such a limit is almost meaningless. It is easily removed by modifying the source codes.

[tomojitakasu]

The following blog article (in Japanese) shows the topic. According to this, some receivers like JAVAD and NovAtel can unlock the limit as an receiver option.

https://blog.goo.ne.jp/osqzss/e/ed527c1701e3383e0ffa1df96bef788e

[kozuch]

Thanks for answer. I am happy to hear no limts are applied. I also think implementing such restriction in OSS does not make sense but I just wanted to confirm.

Do you think it may be technically possible for a HW receiver to "alter" raw data output in a way that it would make it harder to do the final positioning which would be beyond the CoCom limits? Looks like this may not be technically possible without also compromising the accuracy/precision within the CoCom limits (=make the positioning worse in all cases). I am just wondering...

[tomojitakasu]

Most of things are "technically possible".

A simple way to comply with CoCom is to stop raw data if the altitude or the speed over the limits. Some receivers take this way.

The following article (in Japanese, OSQZSS is the author of an OSS software simulator GPS-SDR-SIM, https://github.com/osqzss/gps-sdr-sim) reports u-blox LEA-6T's case. LEA-6T outputs PVT by 80km as altitude. Raw data keep by 100km. But, raw data stop if reaching the speed limit. Other receivers may show different behavior.

https://blog.goo.ne.jp/osqzss/e/237adc74e6717b47147accd1794193ce

[kozuch]

My brain really is too small not being able to think of a case where the receiver computes PVT internally and then decides whether it outputs raw signal or not. How simple though.

Seems like one needs to go with a fully fledged SDR radio for truly unlocked GNSS. I see quite few GNSS-SDR projects out there. Can you recommend any of them? Are they using your code or are these parallel codebases?

These are the projects I found so far:

• https://gnss-sdr.org/
  • https://github.com/gnss-sdr/gnss-sdr
• http://www.taroz.net/
  • https://github.com/taroz/GNSS-SDRLIB
• SoftGNSS

[tomojitakasu]

GNSS-SDR may be the most active OSS SDR project. It has integrated (a little old version) RTKLIB after modifying codes since v0.0.10.

https://github.com/gnss-sdr/gnss-sdr/tree/master/src/algorithms/libs/rtklib

[kozuch]

Thanks a lot for your help!