Ideas for stress testing GPS via GadgetBridge

I'm searching for a method to stress test the GPS via GadgetBridge changes in https://github.com/espruino/BangleApps/p­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 https://codeberg.org/Freeyourgadget/Gadg­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.

Maybe unrelated, but since I updated my daily-driver bangle from 2v16 to 2v17.54 (and Gadgetbridge to another nightly, but I think without relevant changes for Bangle) this seems to be happening a lot less. I am down from practically every second day to maybe once a week.

I have tested a bit again with current stable firmware and GB (2v17 and 0.74) and the changes for android from https://github.com/espruino/BangleApps/p­ull/2534 since without them I can not get GBGPS to activate on GadgetBridge:

• Connect watch to GB and start GPS Info to get GPS updates -> works fine
  
  • Battery level available in GB
    
  • Connected shown in GB
    
  • Sending notification works
    
  • characteristic write messages in logcat
    
• Put watch into metal box
  
  • Battery level vanished from GB
    
  • Few ms of disconnected (grey) state, then connected state shown again
    
  • After "reconnect" still no battery level
    
  • GB still trying to send GPS, but not characteristic write messages
    
  • Debug notification does not work, just added to queue like GPS messages
    
• Take watch out of box
  
  • nothing changes, stays fake connected without battery level
    
• Reload watch (2 sec button press)
  
  • nothing changes again
    
• Disconnect and reconnect watch with GB menu
  
  • Everything returns to normal
    
    

It seems there is a problem in the GadgetBridge GPS handling code, not the GPS code on the watch. It is in the metal box when the problem starts, so no influence on GB at that point in time. Without triggering GBGPS on the watch the "fake" reconnect does not happen and the actual reconnect after the box is openend restores full functionality.
Somehow some state in GB seems to be not cleared as it should be when the GPS service is active.

I think I found the issue:
The location manager was not cleaned up when the Bangle was disconnected by connection loss. This pull request should fix that.
https://codeberg.org/Freeyourgadget/Gadg­etbridge/pulls/3132

Excellent, thanks! It'd be great to get that in