Regarding the problem of using a logic analyzer to sample data, resulting in a decrease in positioning accuracy

[yuyeguiji]

I made a PCB following the open source scheme and it works fine. Then I lead out the RADIO_CLK and RADIO_SIGN flying wires on the PCB, connect them to my logic analyzer, and analyze them according to SPI (low bit first). The frequency at this time is 16.368M. I sample the data in quarters and send When it comes to back-end analysis, although it can be located, the accuracy is much worse (almost doubled). I don't know if my sampling method is wrong or other problems. I hope you can help me analyze it.

[JonasBchrt]

Hm, I don't have a definitive answer out of the top of my head. Some questions:

• Which SnapperGPS version are you using? V1.0.0? V2.0.0?
• Are you using the same antenna as before? Is sky visibility similar as before? Did you check that the antenna connector is tight?
• How long are your wires for RADIO_CLK and RADIO_SIGN? Could it be that they come close to a source of interference?
• Did you modify the PCB close to the antenna feed line? N$5 or N$32 and N$33. Crosstalk can be a problem here. Or next to the SAW filter?
• Did you try multiple datasets and recordings from different days? Localisation performance can vary over days due to different quality of the satellite navigation data and different strengths of signal delays in the atmosphere.
• If you are using a battery as power source, is it sufficiently charged?

But cool that reproducing the hardware worked for you in general.

[yuyeguiji]

Thank you for replying to me every time. Your suggestion is very helpful to me. This is a great project. I feel that it can achieve a function similar to u-blox's CloudLocate. It may be necessary to add a module that can upload data .

[JonasBchrt]

Yeah, that's right. Although, I believe that CloudLocate isn't taking a pure snapshot approach, despite there probably being some coarse-time navigation going on, too.

I once built a prototype with cloud-offloading via a narrow-band cellular connection. Kinda works. But significantly increases power consumption, size, costs, and complexity. It's a close competition with normal on-board assisted GNSS then, I believe.
Low-power LPWANs unfortunately struggle providing sufficient bandwidth/coverage for snapshot GNSS. That's why I went for cellular.

Suggestions welcome :)

[yuyeguiji]

There is a question here, does your algorithm have to have an approximate initial position, in this case it can only be obtained using the cellular network.

[JonasBchrt]

Yes and no. Coarse-time navigation needs an initial coarse position and time by design. In the web app, I ask users for an initial position with 10 km accuracy for the first fix. For the following fixes, I use the previous fix as initial position. However, coarse-time navigation for GPS can in theory work with an initial location that is 100-150 km wrong (this is because the GPS L1 C/A codes repeat every 1 ms, which corresponds to 300 km signal travel distance). Even more with Galileo (4 ms code period) and BeiDou (10 ms). And if you run coarse-time Doppler navigation before you run coarse-time navigation, you can even remove the need for an initial position at all. Demo implementation here: https://github.com/JonasBchrt/cold-snapshot-demo