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]

Hi,

There is really no short answer to your question other than to say it is fully configurable. The example will as you indicate use the NRF_SDH_BLE_GATT_MAX_MTU_SIZE you set for both UART and BLE packets, but this is just the way is setup. You are free to modify the project and use any combination of size, on any layer of the protocol, you may even split and reassemble packets in the application if you like.

Best regards,
Kenneth

[Demetrio Magrin REEL]

Hello Mr. Kenneth,

I ask her for advice on the following.

The HW at my disposal to do the BLE tests is as follows:
- EVAL NRF52-DK as "BLE pheripheral" with "ble_app_uart"
   (file ble_app_uart_pca10040_s132.hex).
   The VCP made available is accessible from my external DockLight tool.
- Dongle "nRF51 dongle" as "BLE central" with "ble_app_uart_c"
   (file ble_app_uart_pca10031_s130.hex).
   The VCP made available is accessible from my external DockLight tool.

1st Test: a buffer of 200 bytes is sent from the VCP "BLE Pheripheral" (for example).
         The "BLE central" VCP displays 10 frames of 20 bytes each.
        The time elapsed between a frame received of 20 bytes and the next one is 75 ms.
         Why is this time of 75 ms? How can you reduce?
         On the code I saw that there are the following two definitions:
         #define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS (20, UNIT_1_25_MS)
         #define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS (75, UNIT_1_25_MS)
         It seems to me that the pause time between the plots is linked to the definition
         "MAX_CONNECTION_INTERVAL".
         I tried to decrease this number to 30 ms on "BLE pheripheral and central" but nothing works.
         If I change this number from 75 to 200 I see that the time between the frames is 200 ms.

2nd Test: The "nRF51 dongle" dongle is associated with the Nordic "nRF Connect v.2.6.1" TOOL PC
              In this case the Nordic TOOL PC programs the "nRF51 dongle" dongle in the mode
              "Ble_connectivity".
              A buffer of 200 bytes is sent from the "BLE Pheripheral" VCP.
              The Nordic "nRF Connect v.2.6.1" TOOL PC displays 10 frames of 20 bytes each.
              The times elapsed between the received frames of 20 bytes have a minimum value of 0 ms
              and a maximum value of 13 ms.
              How come there are times so different from the previous test ?

In my final use the dongle "nRF51 dongle" as "BLE central" will be replaced by an APP. on android or iOS where the buffer size will be greater than 20 bytes.
For now I wanted to simulate a MODBUS communication using the HW described above
(EVAL NRF52-DK as "BLE pheripheral" and dongle "nRF51 dongle" as "BLE central").
How can I minimize the time of 75 ms by modifying the source code ?
Is it possible that this time is deterministic ?

I await a kind reply.
BR

Demetrio Magrin

[Kenneth]

It is as you already indicate depending on the connection parameters, and in specific the connection interval. It may be a better idea to use the central peer example in the SDK: \nRF5_SDK_15.2.0_9412b96\examples\ble_central\ble_app_uart_c in this case.

And set the min and max interval to for instance 20ms, then I would expect them to negotiate to use 20ms.

Best regards,
Kenneth

[Demetrio Magrin REEL]

Hello Mr. Kenneth,

I have modified the define as follows(Pheripheral and Central):

#define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS (20, UNIT_1_25_MS)
#define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS (20, UNIT_1_25_MS)

Perfect. Now the buffers are received without pauses.
I have seen that if I decrease the time from 20 ms to 10 ms nothing works.
Thank you very much for your availability.

BR

Demetrio Magrin

[Demetrio Magrin REEL]

Hello Mr. Kenneth,

1st Test: a buffer of 200 bytes is sent from the VCP "BLE Pheripheral" (for example).
        The "BLE central" VCP displays 10 frames of 20 bytes each.
        The time elapsed between a frame received of 20 bytes and the next one is 20 ms.
         Is it possible to reduce this time by 20 ms ?
         On the code I saw that there are the following two definitions:
         #define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS (20, UNIT_1_25_MS)
         #define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS (20, UNIT_1_25_MS)

         Logger:

         28/01/2019 14:28:57.093 [RX] - 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.113 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.133 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.153 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.173 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.193 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.213 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.233 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.254 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         28/01/2019 14:28:57.273 [RX] - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02

         Is it possible to reduce this time by 20 ms ?

2nd Test: The "nRF51 dongle" dongle is associated with the Nordic "nRF Connect v.2.6.1" TOOL PC
              In this case the Nordic TOOL PC programs the "nRF51 dongle" dongle in the mode
              "BLE_connectivity".
              A buffer of 200 bytes is sent from the "BLE Pheripheral" VCP.
              The Nordic "nRF Connect v.2.6.1" TOOL PC displays 10 frames of 20 bytes each as follows:

              14:39:20.706    Attribute value changed, handle: 0x0F, value (0x):    
                                          01-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.712    Attribute value changed, handle: 0x0F, value (0x):     
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.712    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.726    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.730    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.736    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.746    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              14:39:20.749    Attribute value changed, handle: 0x0F, value (0x):
                                          00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
             14:39:20.752    Attribute value changed, handle: 0x0F, value (0x):
                                         00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
             14:39:20.764    Attribute value changed, handle: 0x0F, value (0x):
                                         00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-02

             As seen, the time between a frame and the next is always less than 20 ms.
             Why this diversity of behavior compared to the first test ?

I await a kind reply.
BR

Demetrio Magrin