Forum

Replies

  • Thanks Jason, that explains the difference in start-up time and location stability. Every restart of your firmware is in fact a warm start. I didn't know that.

    I did have the impression that your firmware resulted in a more stable solution. But that is simply due to the fact that your location solution is based on more satellites.

  • Default firmware from webstore product page or this test program all store ephemeris to internal Flash, so after recycle power it will have position fix in couple seconds after enough satellites tracked. Not needing to decode ephemeris data from signal, it'll will have much faster time to first fix than normal cold start TTFF. The Arduino compiled code does not have this feature, due to making remaining Flash memory space for user programming, so cold start will have ~30sec TTFF under open sky, which is the correct cold start behavior.

  • Your firmware really performs remarkably better than the stuff i write in the arduino environment. Which is puzzling because i don't configure any strange setting. My little program does little more than show some numbers on a lcd and store location values to be written to a card.

    Nevertheless your firmware performs acquisition much faster, uses more satellites and does not lose lock like my programs do. I have tested your firmware and mine after one another. I have not run two navspark-BDs side by side. So it is difficult to put numbers to it.

    This weekend i will test an "empty" program on the navspark. It should performs as well as your firmware.

  • Only Beidou satellite PRN search range is extended, firmware should behave like NavSpark-BD. This 115200 version will avoid potential flying mouse problem cause by 9600: http://navspark.mybigcommerce.com/content/BD_33_34_tst_fw_115200.zip

  • The firmware works fine. It can see 34 at this moment.

    I noticed how stable the location solution of this firmware is compared to my own. I do not see anything special in the configuration other than the lower baudrate for the serial connection. You're using 9600 rather than the standard 115200 baud rate. Can that be the difference?

  • Hi Edwin, Beidou PRN33 & PRN34 signal contain no data thus not useful for position fix, only interesting to see new test satellite can be acquired and tracked. So no plan to update library yet to maintain best possible Beidou weak signal performance. Users interested in seeing Beidou PRN33 and PRN34 can use the test firmware below. 

  • Thanks Jason. Do you have the libraries for building sketches as well?

  • Very cool, it works.

    Cheers,

    Michele

  • After modify code, we can track PRN34 (BEIDOU-3 M1) in below figure, PRN33 (BEIDOU-3 M2) is too low to track at the time. PRN34 signal has no ephemeris data, so cannot use for position fix.

    Here is NavSpark-BD test firmware that works with Beidou PRN1 ~ PRN37: http://navspark.mybigcommerce.com/content/BD_33_34_tst_fw.zip

    Note that default NavSpark-BD firmware only work for Beidou PRN1 ~ PRN14, ones available. Not looking for non-exit Beidou satellites for better weak signal TTFF performance.

  • Ah! Interesting read.
    So the new satellites should be usable with a Beidou-2 receiver.
This reply was deleted.