The BLE chip will randomly stop writing responses, however logs seem to indicate everything is alright

[Burzo]

It's easy to reproduce, the BLE chip will stop writing back responses. Logs seem to indicate that the phone does send the command successfully, but the phone simply stops receiving anything even though everything seems in order.

To reproduce this, just download the test app I sent you and use it for a while, you will see that commands stop getting responses in around a few minutes. And if you have the USB terminal open simultaneously, you'll notice that the messages do get to the BLE chip but no responses seem to be sent.

If you reset BLE via the button, everything starts to work for a while again.

[acutetech]

I am aware of an issue of communication between the BLE chip and the LoRaWAN chip. It is probably this issue that you have encountered. I have not spent much time on understanding the cause, but it seems to relate to timing as the two chips wake from sleep. It is more pronounced on some boards than others, and I had hoped you had a board that did not show the fault, but perhaps not.

When the LoRa-E5 module came out it seemed an easy-to-use LoRa module, so I adopted it. I had an idea that adding BLE comms might be a useful add-on, so I created a footprint for a BLE chip.

When I came to implement BLE comms it turned out to be more difficult than anticipated. This was mainly due to the need to have both chips in a very low-power shut down state for most of the time, but for one chip to be able to wake the other when needed. There are only serial port RxD and RxD between the chips (it would have been better if there were RTS and CTS as well), so the wakeup has to happen by one chip sending a character to the other.

This usually works OK, but sometimes there is a problem and characters get lost or corrupted.

The fix is the WW130 (see below).

[acutetech]

Partly in response to the complexity of having two processors on the one board, and partly because of newer devices/modules becoming available, and also because I now think that BLE coms is a must-have rather than a could-have, I have created a new board, the WW130.

It is based on the MKL62BA module.

In this case the main (only) processor is the Nordic Semiconductor nRF52832 (same as used on the WW120), so it has BLE comms by default.

The module also include a (dumb) LoRa radio peripheral chip. So unlike the WW120, where the LoRa-E5 module (which has LoRa peripheral) does most of the work and the BLE chip just does BLE comms, now the BLE chip does BLE comms and connects to a LoRa chip for LoRa comms.

At the time of writing the WW130 is working as a BLE device. I have a preliminary program (REWILD 2) which should implement the same BLE message exchange as the WW120. Separately, I have had it doing LoRaWAN communications. Soon I will get both radios working together.

I hope to get a WW130 to Miha very soon: Victor offers to take one to Europe next week.

[acutetech]

The WW130 implements over-the-air (OTA) device firmware update (DFU). This will make it much easier to make firmware changes on the target baord.

I attach preliminary explanation of how the OTA DFU works. OTA_DFU.txt

[Burzo]

The new board does not experience these kind of issues, so all is well.