Hello all,
I’m having a problem deploying my system.
Our system uses one Arduino that communicates with all sensors, collects data in its own SD card, and sends it by UART serial to the Spotter SD card log file and Spotter TX.
The Mote is installed with the “Serial-Bridge” example code, with a few more lines to enable Vout.
On the deployment, we found three problems that I’m not sure it is independent or not.
The Serial communication between the Mote and Arduino did not work after 30 minutes submerged in the water. The power was still supplied to the Arduino so that we could check the sensor data inside the Arduino SD card after the recovery. I couldn’t find any physical damage on our bottle or cable shorted. When I turned on the Spotter outside of the water, it did not have this issue. I guess that it could be a ground issue? Can I know where the ground of the Spotter goes? If it’s seawater or not.
The duty cycle is not running as we set in the configuration. I have set it to 20 min off and 15 min on, but it’s working like 8 min off, 15 min on. 8 min off, regardless, I set sampleIntervalMs to 15min or 20 min.
Overcurrent error message. Our system uses 9V,130mA on average. Couldn’t find any peak higher than 220 mA through the oscilloscope. But when the system is connected, it has the overcurrent message; when disconnected, it does not. Every function was still working well, even though I saw this message, but I’m wondering if this could be related to problems 1 and 2.
Any suggestions or help would be appreciated.
Best,
Spotter ground is internal and not connected to seawater.
To understand the duty cycling of the Bristlemouth bus, please check out Sensors & Payloads in the Spotter documentation. If you want 15 minutes on followed by 20 minutes off, then you should sampleIntervalMs to 35 minutes (2,100,000 ms) and sampleDurationMs to 15 minutes (900,000 ms).
Your Spotter may have an incorrect threshold set for that overcurrent error. In the Spotter USB console, type the cfg boc command. That should be set to 3500, but your system may have 400 or a different value. To change it run cfg boc 3500 followed by cfg save.
Hi @zachary, thanks a lot for looking into the issue
Your answer solved problems 2 and 3.
We still need to figure out 1.
Do you think that in any case, the “serial-bridge” can miss anything for deployment in a program-wise?
I met another friend who said he used the serial-bridge with circuit python, and had a similar issue of the UART not working only inside the water. That’s why I thought of that probability.
Excellent! Good luck debugging your things in the water. If your hardware works when out of the water no matter how long you run it, and then it reliably stops working once you put it in the water, then that points to a likely mechanical issue where you need to seal and protect things better.
One helpful troubleshooting tip is to use bm_fprintf (v0.12 and earlier) or spotter_log (latest, upcoming in v0.13) to write logs to Spotter’s SD card periodically, for example once every minute, run a long dry test, like overnight, and then check the logs. Then run a similar test in the water and check the logs.
@cwl20 are you able to post a few pictures of your hardware setup with the dev kit tube? Would be helpful to see what you are working on and might inform the suspected water issue.