iirc the requirements are an AND condition for speed and altitude. >1,000 knots AND >18,000m. But many civilian receivers implement it as an OR condition much to the annoyance of the near space balloon community.
Some will even switch of the radio once one of these limits are reached and not enable it until it's been reset so make them a pain to use for even if you just wanted the location data after your payload comes back down within the limits.
EDIT: But yeah the so-called COCOM limits still apply to civilian equipment (esp to a company such as Broadcom). Unsure on the regulations for modifying the firmware on a device that doesn't put these lockouts at the silicon layer. For example: https://github.com/swift-nav/libswiftnav/blob/master/src/pvt...
Leave it to stackexchange to shed some more light on the matter[0].
The original limits appear to be for units available for export, but I would guess manufacturers didn't want to deal with the headache of producing different models for import/export and just slapped the restriction down on everything. The poster does claim the original restriction was indeed an OR[1].
And current restrictions may only be 600 m/s? [2]pg 58
"Immediate access to satellite measurements and navigation results is
disabled when the receiver’s velocity is computed to be greater than
1000 knots, or its altitude is computed to be above 18,000 meters. The
receiver continuously resets until the COCOM situation is cleared."
Look in the right places and you'll find updated firmware images for various receivers which remove the limits.
That kind of limit is implemented in firmware (all the math is done in software), and they aren't generally protected beyond being an obscure architecture. When you've decided whatever vliw dsp architecture they use, finding a simple 'if' condition near the output logic is quite easy.
