Modbus RTU protocol over "BLE UART"

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Fri, 01 Mar 2019 13:36:40 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Sun, 10 Feb 2019 13:04:40 GMT

[quote user="Demetrio Magrin REEL"]After the transmission
of this frame the FW on the EVAL crashes and the message "UART started" reappears.[/quote]

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

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Thu, 07 Feb 2019 11:00:56 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Tue, 29 Jan 2019 20:02:42 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Mon, 28 Jan 2019 14:48:01 GMT

Hello Mr. Kenneth,

         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

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Mon, 28 Jan 2019 09:36:05 GMT

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.

Demetrio Magrin

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Sun, 27 Jan 2019 12:03:49 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Fri, 25 Jan 2019 11:38:55 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Wed, 23 Jan 2019 13:31:59 GMT

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

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Tue, 22 Jan 2019 13:31:16 GMT

Hello Mr. Kenneth,

It confirms that to transmit BLE packages of size greater than 20 bytes I have to modify the row
#define BLE_GATT_ATT_MTU_DEFAULT 23 and then recompile my application and the related softdevice ?
This must be done for both BLE (pheripheral and client).

Is this the only way to use for MODBUS RTU over BLE communication or are there other possibilities?

Thank you for your availability.

Demetrio Magrin

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Mon, 21 Jan 2019 17:35:57 GMT

The UART service may be by default be setup for 20bytes, but longer is possible by modify the software. I could not find any specific requirement in iOS that prevent longer packet, they seem to support up to 251 bytes (ch. 11.11 and 11.7):

https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

In terms of software deliveries I guess you can find what we have to offer in the SDK documentation, maybe this link is a good starting point:

https://www.nordicsemi.com/DocLib/Content/SDK_Doc/nRF5_SDK/v15-2-0/transport_libraries

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Mon, 21 Jan 2019 16:58:50 GMT

Hello Mr. Kenneth,

With the examples provided by Nordic as UART over BLE (pheriferal and client) the transmission of a buffer of 300 bytes (for example), is received in 15 packets of 20 bytes with a pause between a packet and the next.
If I send, through the UART, these 15 packets to my external control I would have the intervention of the end-of-frame modbus RTU interrupt at the end of each pack of 20 bytes.
To solve this problem it is necessary to receive all the data in 20 bytes packets and then transmit all the received buffer to my control. Similar to Bluetooth BR/EDR.
Note: for iOS systems it is advisable to use an ATT_MTU of 20 bytes.
For this reason we have chosen to use ATT_MTU = 20 (default).
We ignored the possibility of using an ATT_MTU> 20 bytes.
I await a kind reply.

Best regards,

Demetrio Magrin

RE: Modbus RTU protocol over "BLE UART"

Demetrio Magrin REEL — Mon, 21 Jan 2019 15:54:41 GMT

Thank you.
I have seen that this topic has already been dealt with at the following link:

devzone.nordicsemi.com/.../regarding-rs-485-to-ble-links-for-Modbus

In particular I saw that there is already a Texas gateway visible at the link:

www.ti.com/.../TIDC-BLUETOOTH-SMART-TO-RS-485-GATEWAY

Is there already something similar already done by Nordic ?

Thanks again for the support.

Best regards,

Demetrio Magrin

RE: Modbus RTU protocol over "BLE UART"

Kenneth — Mon, 21 Jan 2019 13:53:32 GMT

Hi,

The link layer of BLE will ensure all packets are successfully received by peer and in the correct order. It's only a link loss that may interfere with this.

To transmit large buffers it may be a good idea to use data length extension (include gatt_init in your project to handle this), this allow the two peers to exchange the maximum data packet size on-air, which overall will increase throughput and reduce latency.

You can in the application have a large UART buffer, e.g. 1kByte, and in addition use hardware flow control on UART. This should ensure that the application can buffer the next packet while the current is transmitted. Enabling flow control will ensure that the peer don't overrun the buffer.

Best regards,
Kenneth