我不建议将集成 GPS 解决方案（包含 MCU 和闭源固件）用于卫星应用。这可能无法正常工作有几个原因：

1. 可以针对有限的多普勒范围优化前端频率计划。通常，RF 前端会将信号混频到低于 10MHz 的 IF（更高的 IF 将需要更高的采样率并消耗更多的能量）。这个IF不是随便选的！商 IF/采样率对于整个多普勒范围应该是非谐波的，以避免来自采样信号中的 a/d 截断误差的杂散音。您可能会观察到跳动效应，使信号在某些多普勒速率下无法使用。
2. 数字域相关器需要以正确的速率复制载波和 C/A 码，包括多普勒效应。它使用 DCO（数字控制振荡器）来控制载波和代码生成，通过 MCU 的配置寄存器进行调整。这些寄存器的位宽可能会被限制在地面接收器预期的多普勒范围内，如果您行驶得太快，就无法将频道调谐到信号。
3. 如果没有可用的位置/时间估计，固件将不得不进行冷采集。它将搜索多普勒频段和编码相位以找到信号。搜索范围将限制为地面用户的预期范围。
4. 固件通常会使用卡尔曼滤波来解决位置问题。这涉及接收器位置/速度/加速度的模型。虽然加速度不会成为卫星关注的问题，但如果固件不适合在轨使用，该模型将因速度而失败。

如果您使用可自由编程的前端和具有自定义固件的相关器，所有这些问题都可以得到解决。你可以看看Piksy。

有些人将 COCOM 实现为or，其他人实现为and。无论哪种方式，对于 EAR 或 ITAR 下的合格客户，供应商都会很乐意向您出售一个 $$$ 的固件选项，它会禁用该功能。硬件是一样的。

除了这个硬性限制之外，它还成为一个射频通信问题，同时设计您的硬件以容忍辐射效应。您的 Eb/N0 可能会好一些，因为您（字面上）更接近 SV 并避免大气路径损耗，但您的接收电路也需要承受相当多的多普勒。

顺便说一句，尽管 CubeSats 感兴趣的不仅仅是位置——GPS 时间是一种有价值的数据商品，可以帮助卫星根据 TLE 确定它的位置。即使接收方因为 COCOM 而拒绝给你一个职位，如果它给了时间，那也是值得的。

这真的取决于实施。例如，我研究过的一个接收器在每个相关器通道中都有一个定点载波 NCO 频率寄存器，宽度为 17 位。可以存储在该寄存器中的最大值对应于大约 6 km/s，并且还必须包括接收器时钟频率误差的影响。因此，它无法跟踪距离速率超过该限制的任何卫星，如果接收器以轨道速度移动，这将是相当多的卫星。

如果这篇关于 GPS 架构示例的论文具有代表性，那么这些芯片由射频前端、数字域中的硬件相关器组成，并且信号的所有实际解码都在软件中执行。

在这种情况下，唯一可能的问题是多普勒。该软件可能会丢弃“异常”值，但如果您想绕过 CoCom 限制，则无论如何都需要更换或修改固件。

一个更有趣的问题是，您是否可以借用一个 GPS模拟器，该模拟器可以通过编程来模拟高速情况。我原以为这是可能的——毕竟，制造商将如何测试他们的设备是否应用了 CoCom 限制？