Bluetooth buffer question -- tracking down an issue..

Probably one for @Gordon, but please chime in if others have help - I'm trying to track down an issue with a couple of my designs. After some long-ish period of time (many hours or days) of not being connected, my sensor designs 'crap out' and need to be reset and reloaded with js code.

I'm doing something probably bad which is just to keep writing to Bluetooth (Bluetooth.println()) without putting it into a NRF.on(){} construct. In other words, it is trying to output to Bluetooth when not connected. I'm going to guess that not only is this not a good practice, but it may be filling up some buffer to the point of producing the 'crap out' behavior.

I'll try putting it into the appropriate NRF.on and putting some test time on it, but if you could let me know if this is indeed an issue it would help me feel like I'm on the right track to getting the sensor more reliable.

Thanks!

I... keep writing to Bluetooth (Bluetooth.println())

That really shouldn't be a major issue. It detects if there's no connection and just throws the data away immediately.

When it 'craps out', what happens? Does it lock up, does all the code get removed?

If at all possible, I'd either leave a PC connected via bluetooth so you can see any log messages, or wire up a USB-TTL converter so you can see your log messages when not connected via Bluetooth. It might give you some idea if something is printed before it dies.

There are other things you can do (writing log messages to flash), but if you can avoid that it'd be better as there's always a chance it'll die so badly it doesn't get a chance to write the data away.

Hi @Gordon,
Sorry for the delay; other (paying) work... As it turns out, your suggestion got me to the right track inadvertently. I've had a serial-output sensor connected to Tx, Rx. When you suggested I connect to the default TX/RX, I couldn't because they were used. I think you get the picture... It was spitting out data whether or not the device was connected to Bluetooth. It appears that Espruino took it for debug port when disconnected and was sometimes messing things up when I tried to reconnect (or while disconnected).

I moved the sensor UART to a different GPIO and it seems to be much happier. Does that make sense to you?

The project is an air quality sensor made from Adafruit parts. We've had a horrible fire/smoke season on the US west coast this year, and the air quality monitoring stations are rather sparse and do not report in real time. Most of the consumer sensors are handheld with a display and a bit expensive. I now have a Bluetooth, battery powered sensor. I'll be posting it once I get it tidied up into an enclosure. Probably post it to hackaday as well so that others can use it.

Thanks!
Bill

1 Attachment

Quite interesting... and the phone is the display and hub which can add the location to the data and send it up into a mapping app on the public Web... it is like Neighborhood Watch: any one can contribute any time, and the mapping app can do some interpolation and compose charts and it becomes the means to get great coverage...

Yep!

As far as moving the UART over to a different pin and getting better results, I'm wondering if it's related to an issue I was having where the console was taking over to the USART1 pins on the Puck when I disconnected from the IDE. Basically the same as this troubleshooting post:

http://www.espruino.com/Troubleshooting#console

Except instead of calling USB.setConsole(), for me the fix was to call:

Bluetooth.setConsole(true);

I did this both on the init event, and at the top of my code, and it addressed the issues I was having where it looked like console activity was appearing on my serial connection when I connected and disconnected from bluetooth. This allowed me to interact with a UART device on the tx,rx lines...

Gordon or others, please correct me if I'm wrong here, but if this is correct, it might be worth it to add bluetooth related info to that troubleshooting page.

Looks great!

I moved the sensor UART to a different GPIO and it seems to be much happier. Does that make sense to you?

Not really - the pins shouldn't make any difference. As @jijidad says, Bluetooth.setConsole(true); should do the trick for you. That's a good point - I'll see about adding it to the Bluetooth LE troubleshooting.