Ideas for stress testing GPS via GadgetBridge

Posted on
  • I'm searching for a method to stress test the GPS via GadgetBridge changes in­ull/2534 together with the latest GadgetBridge nightly.
    There is a test script, which exercises all states, that runs fine.
    Yesterday I had somehow reached the state of GadgetBridge still sending GPS events (seen in logcat) but the Bangle was not reacting at all. That was about half an hour after starting to use GPS. First theory was GPS cutting out on the phone and somehow getting the internal state on the bangle out of order.
    To simulate bad GPS I have devised a top notch high end RF testing bench (put the phone into grounded aluminium foil) and created about a thousand disconnects from GPS over 8 hours. The bangle code worked without failure the whole time.

    Sooo... Has anyone other ideas for testing this?

  • I can now reproduce the problem. It seems to independent of the bangle code as well as GPS reception. Forcing the problem to appear takes cutting of BT reception enough for a disconnect. The behaviour after is very similar to having a breakpoint in the loop of the dispatchThread in GB BtLEQueue and just leaving that hanging.
    Normal execution looks like this:

    nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: about to add: 20:30:52: Transaction task: gps with 8 actions
    nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: About to run action: 1. März, 20:30: WriteAction on characteristic: 6e400002-b5a3-f393-e0a9-e50e24dcca9e
    nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.actions.WriteAction: writing to characteristic: 6e400002-b5a3-f393-e0a9-e50e24dcca9e: 0x10.....

    After disconnecting bluetooth from the outside the GPS sending looks like this:

    nodomain.freeyourgadget.gadgetbridge.ser­vice.btle.BtLEQueue: about to add: 19:51:53: Transaction task: gps with 7 actions

    No WriteAction executing, just the next GPS update arriving and queuing up the next transaction task.

    This is the only log line seeming relevant for this problem after the forced disconnect:

    nodomain.freeyourgadget.gadgetbridge.ser­vice.devices.banglejs.BangleJSDeviceSupp­ort: Services discovered, but device state is already INITIALIZED for device: Device Bangle.js 773e, FF:3B:5A:19:77:3E, initialisiert, so ignoring

    Save for BT disconnects the GPS from GB works really well now. @Gordon any idea what could be the problem here or where to search further? I'm a bit out of my depth regarding the BT LE stuff in GB.

  • Any chance you can debug the Android Gadgetbridge app and check the characteristics? It's possible they are null.

    If so, it might be related to­etbridge/issues/2996 - it ends up connecting but then not being able to send/receive any data.

    I guess in this state, nothing else works?eg you can't send a test message from the Gadgetbridge debug menu?

    ... although I wonder if it is that issue, as I didn't think a WriteAction would get created in that case?

    Is it possible that a WriteAction is created for the wrong device handle or something?

  • It is probably a different issue, the characteristics are not null. In the broken state it hangs in BtLEQueue in line 177 mWaitForActionResultLatch.await(); so nothing further is transmitted. Executing mWaitForActionResultLatch.countDown() in the frame does seem to revive the processing of the transaction queue. It sends out everything it got.
    If I set a breakpoint in the queue, force the disconnect and then let the code run after reconnecting, it works just fine. So essentially something must be wrong with the interleaving of queue processing thread and cleanup/reconnect. Deactivating auto-reconnect and reconnecting manually does also hide this problem so it isn't the manual disconnect that "fixes" it.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Ideas for stress testing GPS via GadgetBridge

Posted by Avatar for halemmerich @halemmerich