Modbus RTU protocol over "BLE UART"

[Demetrio Magrin REEL]

I used the Nordic EVAL model nRF52-DK which uses the "nRF52832" chip.
The EVAL has been programmed as "Pheripheral" with the application "BLE over UART" made available by Nordic itself.
The "BLE over UART" profile contains the SoftDevice inside: "s132_nrf52_6.1.0_softdevice.hex".
The RX / TX signals of the UART have been connected to the serial port of an external device.
The BLE client is a PC application interfaced with the VCP of the "nRF51-Dongle" dongle.
The data frames to be exchanged have a maximum size of 512 bytes (stardard modbus RTU). The ATT_MTU = 20.
What is the reliability of BLE communication in the case of buffer fragmentation in packets of 20 bytes each ?
Is there a guarantee that the packets are always sent sequentially without the loss of packets ?
Which recommended solution to use for data exchange with such large buffers with modbus RTU ?

Best regards.
Thank you.

Demetrio Magrin

[Kenneth]

All good questions, but I don't see a short answer to your questions. I recommend reading up a bit on BLE to learn more about connection parameters and the various ways to send and receive data (for instance write command vs. notifications) between the peers. Learn the various roles between GAP central and peripheral, GATT server and client. In addition, I recommend downloading our nRF sniffer tool, that will allow you to view the actual on-air packets here.

Best regards,
Kenneth

[Demetrio Magrin REEL]

Hello Mr. Kenneth,

With reference to the project for the EVAL nRF52 present in:
                           "NRF5_SDK_15.2.0_9412b96 \ examples\ble_peripheral\ble_app_uart \".
I have only modified the following define in the "sdk_config.h" file:
#define NRF_SDH_BLE_GAP_DATA_LENGTH 27. It was 251.
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23. It was 247.

After this change I saw that:
1) A buffer of 100 bytes received from the EVAL UART is transmitted correctly through BLE.
     I have verified through the sniffer the presence of 5 frame of 20 bytes each.
2) A buffer of 160 bytes received from the EVAL UART is not transmitted correctly through BLE.
     I have verified through the sniffer the presence of only one frame of 20 bytes. After the transmission   
     of  this frame the FW on the EVAL crashes and the message "UART started" reappears.
3) If the 160 byte buffer is received by the BLE(EVAL), the EVAL UART transmits it correctly.
     I have verified through the sniffer the presence of 8 frame of 20 bytes each.

What should I change to fix this problem ?

I await a kind reply.
BR

Demetrio Magrin

[Kenneth]

Demetrio Magrin REEL said:

After the transmission   
     of  this frame the FW on the EVAL crashes and the message "UART started" reappears.

It seems to me that you have an assert, typically if you define DEBUG in your project, and set a breakpoint in app_error_fault_handler() you should find the file name, file number and error code.If you do not define DEBUG the fault handler will typically execute NVIC_SystemReset().

Best regards,
Kenneth

[Demetrio Magrin REEL]

Hello Mr. Kenneth,

With reference to the project for the EVAL nRF52 present in:
                           "NRF5_SDK_15.2.0_9412b96 \ examples\ble_central\ble_app_uart_c\".

I have modified the FW in such a way that every 500 ms the "nRF52832" transmits the same buffer to "PCA10040" (fixed table with final CRC). 138 bytes are sent in all.
The buffer is received and displayed by the PC terminal (DockLight connected to the JLink CDC UART).
Randomly the buffer received and displayed by DockLight is incorrect.
The data of the serial port (FW and DockLight) are following (default):
Baud_rate = 115200 (default).
Parity = None
Data bit: 8
Stop bit: 1

Is there any news of this problem ?
What should I do to solve this problem ?

I await a kind reply.
BR

Demetrio Magrin