DIY Project but app always show "No fix to satellites".

Hi everyone,
I try to implement a DIY project with Bluepill(STM32F103) + BLE(HM-11) + 10hz GPS(M8TLF).
Now I successfully bind BLE and GPS module to my mainboard and connect to RaceChrono but it always show "No fix to satellites.".

So I try to send the fake data to app but it is still not work (No fix to satellites.).
I am sure my UUID3 byte, index 4 have put the data (0x4A, GPS, 10 satellies).

Is there any un-document conditions caused this happen? (such as real time, valid altitude, UUID4 cannot read, etc.)
The packet will be
0x22 0x20 0xBA 0x4A 0x0E 0xC4 0x2D 0xD0 0x48 0x1F 0x31 0x80 0x13 0x88 0x00 0x00 0xFF 0xFF 0x00 0xFF

My fake data is here,
gps.hgps.year = 21;
gps.hgps.month = 2; = 17;
gps.hgps.hours = 14;
gps.hgps.minutes = 4;
gps.hgps.seconds = 20;
gps.milliseconds += 100;
gps.hgps.latitude = 24.77377989286238;
gps.hgps.longitude = 121.00038602734459;
gps.hgps.speed = 0;
gps.hgps.fix_mode = 1;
gps.hgps.sats_in_use = 10;

And I use the BLE test tool to snap my packet.


  • aolaol
    edited February 17
    Sorry, it might take some time for me to get around testing this (and verifying the GPS API still works). I will need to re-build my device first :)
  • Thanks for the reply, please let me know if your need my source code.
  • Hi Aol, would you have any idea about situation?
  • aolaol
    edited February 26
    @lak Yes, sorry just got around to this.

    I rebuilt my device, which I had dismantled by mistake. I will now keep it as permanent test device for this API, so it's now much easier to confirm it is still working.

    The API still works so you must have a problem with the implementation.

    1st thing I look for is the byte 3, in your case 0x4A. It means your GPS has a fix (anything between 1 and 3) and locked to 10 satellites. So everything is good there.

    2nd thing I look, is you got the correct characteristics. The UUID 3 looks good, it has read and notify supported, and the read value seems correct in a quick glance. BUT, I see a problem with UUID4, it is write only. It should be readable, and should output a value according to the spec. No write access needed for UUID4, only read.

    Also make sure to look at the device status in RaceChrono, the one from the red/green button on bottom left. From there it's easy to see if there's a problem with only one value in the protocol. Or if it doesn't display anything for it, then you have a bigger problem, for example with the BLE characteristics.
  • @aol Have you seen You can "have" a Subaru BRZ in your garage for testing your DIY device with realistic looking data. Needs no fuel, just USB power :wink:
  • @timurrrr Haha, that's great! Now make it support OBD-II too... I already have a KTM 790 Duke simulator, and will add that BRZ to my test tools too! :)
  • @aol
    ok.. you mean my raw data looks good, the problem may be caused by the properties of characteristics, right? (So your app will not to check whether the data is correct, such as time, or something else.)
    Unfortunately, my BLE module (HM-11) don't let me to change the properties of characteristics, if the problem is caused by a mismatch of properties, then I need to change my BLE module. (Actually, I bought Bluefruit LE Friend today, hope to solve my problem...)

    And, my screenshot is below, it doesn't seem like to accept any data...
  • aolaol
    edited March 1
    @aol As I said in earlier message, the UUID 4 on your device is not readable. It's an integral part of the protocol and you cannot skip doing it correctly. Your UUID 3 looks correct, so if you fix the UUID 4 it might work.
  • Got it, thanks.
    When I receive the new BLE module, I will update the progress, hope everything goes well.
  • aolaol
    edited March 1
    The reason for using two UUIDs is that the default payload size is 20 bytes, and there's some complications when changing the MTU (= payload size). The GPS data just does not fit properly to 20 bytes.
Sign In or Register to comment.