No power to Bristlemouth unit when connected to Spotter

Hi all, relaying another problem and solution here to share with the community.

Problem: We’re looking to start testing again but have run into an issue with the Bristlemouth unit. The unit will power up when connected to the dev kit power adapter, but not when connected to the spotter (SPOT-31591C). We have already confirmed that everything is hooked up the same as when we were doing our initial testing, and the spotter was left off and connected to its charger since noon yesterday to ensure it was charged. Is there something else we need to do to get the bristlemouth talking to (and receiving power from) the spotter again?


"Regarding your Bristlemouth connector, I suspect the bridge is turned off. Can you please connect to the Spotter’s USB serial terminal, and issue this command:

gpio get 3v3_bridge_en

If my suspicions are confirmed, you’ll likely see:


gpio set 3v3_bridge_en

Spotter should respond with:


You can then issue the first ‘get’ command again and it should respond with 1 (one) instead of 0 (zero).

[ASL]: We were able to it out figure out after being pointed in the right direction by your (@zack_j ) suggestions.

gpio set 3v3_bridge_en allowed the bristlemouth unit to power up, but it still wasn’t able to see the spotter and vice versa.

Turns out that the bridge had been completely disabled as per the spotter config, so it came back up once I set the bre parameter to 1, saved the config, and rebooted the spotter.

Note that I had plugged in the spotter until it reported fully charged (solid green System and Go lights with the power switch off) and rebooted it several times (connecting to its serial terminal each time to watch it’s boot process, GPS acquisition, etc.), so if it had disabled the bridge due to low power it didn’t re-enable it upon exiting the low power state.

[@zack_j , SOFAR]: I recall now that the bre might have been due to the telemetry issues which were discussed a couple of months ago with others on this thread. Good catch.

@aslenv this is very helpful! Thanks for posting the solution. I’ll tag in a few folks to see if we can find out how things went that way.

1 Like

@zack_j the system had an issue with excessive data transmission and we were working to alleviate to issue while communicating with the customer. The bre (bridge disablement) command actually was not expected to go through, as the system had been turned off before it was issued.

1 Like