RN42 Bluetooth on Photon disconnecting

My Photon weather station sends data to a serial LCD display via a pair of RN42 (Sparkfun BlueSmirf Gold) modules. Normally, this works very well but a couple of times a month, the connection mysteriously drops and both modules start flashing red. I have to manually connect to the Photon’s RN42 from my phone’s Bluetooth terminal app, put the RN42 into command mode, and then reboot it (“R,1”). That’s a pain.

I have it in auto mode so it immediately recoonects upon booting. But I’d like the Photon to reboot the Bluetooth automatically when the connection drops. But how to do that?

The RN42 manual shows a GPIO pin, GPIO2 that does exactly what I want. When this pin is high, the device is connected. When it’s low, it’s disconnected. I could have the Photon monitor this and send a R,1 whenever GPIO2 goes low. Unfortunately, on the RN42 all the GPIO “pins” are virtual and their state can only be accessed via the UART. But that’s busy sending data. The Photon happily continues to send data to the RN42 even after the connection drops.

It’s not really an option to continually put the RN42 in command mode to check for an event that only happens a few times a month. The manual doesn’t give a command to read GPIO2 anyway. So is there any way to read GPIO2 out of band on the RN42?

One thing I thought of would be to just connect RX to TX on the receiving RN42 to echo all its received data back out and then periodically do a serial.read on the Photon. If that fails, then the connection has been lost. Would that work? Is there a better way?


I always hate answering my own posts but here goes. In the absence of any other suggestions, I will simply break out GPIO2 myself by tacking a short piece of wirewrap wire directly to the pin on the chip. Digikey sells RN42’s with all the pins broken out, but this is cheaper. Unless I ruin it in which case I’ll then just get the Digikey version anyway.

I also found buried in the manua a command that returns the connection status: GK. That’s still not as good as reading the GPIO pin because you have to interrupt the data flow to put the device in command mode.