Bluzdk for retrasmitting data received @57600 from Serial1


#1

Hi!, i am thinking about using BluzDK for a project, but before starting working in it, i would appreciate any opnion about if it is possible. My idea is to connect a device via Serial1 TX/RX pins to a BluzDK device in order to transfer data packets at 57600bauds, and then, retransmit the received payload from each packet (most of the cases, 2 bytes long) from BluzDK via BLE to a central device … can BluzDK support that data rate?. thanks


#2

Like many answers, it depends on the specifics of your use case.

BLE sends packets based on a connection interval. This is determined by the gateway. Basically, each connection interval the radios sync up and you can send data, mainly in 20-byte chunks. You can send multiple 20-byte chunks, depending on the gateway.

For example, an iOS device supports a connection interval down to 20mSec. You can then transfer 6 20-byte chunks during that time, but then you can’t send any more until the next connection interval.

You didn’t mention how often the 2-byte data packet would come in over Serial1, so it is hard to determine. It also depends on the gateway you plan to use, some gateways support less packets per connection interval and/or have different connection interval times.

If your data packets are coming in faster than the connection interval of bluz, you also have the option to buffer them and send them all at once. So instead of sending one 2-byte payload every connection interval, you could buffer many and send them as a bunch.

I hope that helps, please let me know if you have any more questions.


#3

Hi @eric thanks again for your answer and support. In this case i receive around 512 packets per second, and i am thinking about using a red bear duo as a gateway


#4

I don’t know what the Duo supports in central mode, so I asked the question here: http://discuss.redbear.cc/t/packets-per-connection-interval-in-central-mode/1342

That answer will help figure out the answer to your question. I will reply back when I find the answer there


#5

Hi @eric … thanks again … just another question related to BluzDK firmware … the max size of data to be sent via BLE.sendData(data, sizeof(data)) command is 20bytes? … in that case, i have to consider in that size the 0x04 header? thanks


#6

Yes, that must be taken into consideration. The answer on the RedBear forums wasn’t exactly conclusive, and I don’t have one to test with at the moment, so I can’t provide a specific answer. If you have one, you could try it.


#7

Hi @eric … I’ve added some code to a Central Device in order to detemine the delay in ms between 2 consecutive notifications received from a BluzDK acting as Peripheral which, by its side, receive a sampe of 2-bytes each 2ms via Serial1 and send it to the Central device at that rate (as you know, additionally including a header byte with value 0x04 and a tail packet with value 0x0304). The results i obtained from the terminal are the following (partial results):

...
    * Received new notification (:
    390 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 6A 2

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 A8 0

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 76 FE

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 DA FE

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    390 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 89 2

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 39 FE

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 DB FF

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 75 FE

    * Received new notification (:
    30 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 3 4

    * Received new notification (:
    390 ms)
       - Connection handle: 40
       - Characteristic value attribute handle: B
       - Notified value: 4 97 1

… so make these results sense? in case the procedure i followed is correct, why are two consecutive packets received with a relative interval of 30ms? in this sense, 30 ms could be the current connection interval, but it would mean that a single packet is sent from BluzDK each connection interval … why, and how could i send more than one packet per connection interval from BluzDK? … are the higher values (around 390ms) related to the reconnection procedure? thanks


#8

Yes, it looks like 30mSec is your connection interval.

The S110 SoftDevice that bluz runs on is capable of sending multiple packets per connection interval. However, the central determines if that is possible. We don’t know what the Duo can support, but it appears that it can only support 1. This is the same as the nrf51 in central mode (eg our hardware gateways) so it wouldn’t be too surprising if that were the case.

You could verify this by trying another central device, if you have one. I believe the Raspberry Pi can handle multiple packets per connection interval.


#9

Hi @eric … from a first experiment, i tried to send 3 consecutive chuncks with data (the third chunck is the tail with 0x0304 value) as fast as possible, from a BluzDK peripheral to a Red Bear Duo acting as central, and a BLE sniffer to capture packets between both devices.

  1. the connection parameters are established to the following values:

    No. Time Source Destination Protocol Length Info
    376 12.705595000 Slave Master LE LL 60 CONNECT_REQ

    Frame 376: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
    Interface id: 0 (\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan 1, 1970 02:25:52.656437000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8752.656437000 seconds
    [Time delta from previous captured frame: 0.001798000 seconds]
    [Time delta from previous displayed frame: 0.001798000 seconds]
    [Time since reference or first frame: 12.705595000 seconds]
    Frame Number: 376
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle:btcommon]
    Nordic BLE sniffer meta
    board: 16
    uart packet counter: 52843
    flags: 0x01
    … .0… = encrypted: No
    … …0. = direction: Slave -> Master
    … …1 = CRC: OK
    channel: 37
    RSSI (dBm): -57
    delta time (us end to start): 152
    delta time (us start to start): 560
    Bluetooth Low Energy Link Layer
    Access Address: 0x8e89bed6
    Packet Header: 0x2285 (PDU Type: CONNECT_REQ, TxAdd=false, RxAdd=false)
    …00 … = RFU: 0
    .0… … = Randomized Tx Address: False
    1… … = Randomized Rx Address: True
    … 0101 = PDU Type: CONNECT_REQ (0x05)
    00… … = RFU: 0
    …10 0010 = Length: 34
    Initator Address: AmpakTec_91:8e:17 (e0:76:d0:91:8e:17)
    Advertising Address: e7:a8:6d:31:7d:0a (e7:a8:6d:31:7d:0a)
    Link Layer Data
    Access Address: 0xaf9a9a62
    CRC Init: 0xf30043
    Window Size: 3
    Window Offset: 23
    Interval: 24
    Latency: 0
    Timeout: 72
    Channel Map: ffffffff1f
    0010 1… = Hop: 5
    … .111 = Sleep Clock Accuracy: 0 ppm to 20 ppm (7)
    CRC: 0x4775a8
    [Expert Info (Chat/Protocol): correct]
    [correct]
    [Severity level: Chat]
    [Group: Protocol]

… and from the captured data, the following packets are sent/received (not complete):

No.     Time           Source                Destination           Protocol Length Info
    852 22.424504000   Slave                 Master                ATT      53     Rcvd Handle Value Notification, Handle: 0x000b

Frame 852: 53 bytes on wire (424 bits), 53 bytes captured (424 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan  1, 1970 02:26:02.375346000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8762.375346000 seconds
    [Time delta from previous captured frame: 0.003348000 seconds]
    [Time delta from previous displayed frame: 0.003348000 seconds]
    [Time since reference or first frame: 22.424504000 seconds]
    Frame Number: 852
    Frame Length: 53 bytes (424 bits)
    Capture Length: 53 bytes (424 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle:btl2cap:btatt]
Nordic BLE sniffer meta
    board: 16
    uart packet counter: 53320
    flags: 0x01
    .... .0.. = encrypted: No
    .... ..0. = direction: Slave -> Master
    .... ...1 = CRC: OK
    channel: 28
    RSSI (dBm): -73
    event counter: 0x0144
    delta time (us end to start): 150
    delta time (us start to start): 382
Bluetooth Low Energy Link Layer
    Access Address: 0xaf9a9a62
    Data Header: 0x1b1a
        000. .... = RFU: 0
        ...1 .... = More Data: True
        .... 1... = Sequence Number: True
        .... .0.. = Next Expected Sequence Number: False
        .... ..10 = LLID: Start of an L2CAP message or a complete L2CAP message with no fragmentation (0x02)
        000. .... = RFU: 0
        ...1 1011 = Length: 27
    CRC: 0xef2639
        [Expert Info (Note/Protocol): unchecked, not all data available]
            [unchecked, not all data available]
            [Severity level: Note]
            [Group: Protocol]
Bluetooth L2CAP Protocol
    Length: 23
    CID: Attribute Protocol (0x0004)
Bluetooth Attribute Protocol
    Opcode: Handle Value Notification (0x1b)
    Handle: 0x000b
    Value: 04180024004a00340031005b0059000c00090032

No.     Time           Source                Destination           Protocol Length Info
    853 22.451115000   Master                Slave                 LE LL    26     Empty PDU

Frame 853: 26 bytes on wire (208 bits), 26 bytes captured (208 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan  1, 1970 02:26:02.401957000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8762.401957000 seconds
    [Time delta from previous captured frame: 0.026611000 seconds]
    [Time delta from previous displayed frame: 0.026611000 seconds]
    [Time since reference or first frame: 22.451115000 seconds]
    Frame Number: 853
    Frame Length: 26 bytes (208 bits)
    Capture Length: 26 bytes (208 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle]
Nordic BLE sniffer meta
    board: 16
    uart packet counter: 53321
    flags: 0x0b
    .... .0.. = encrypted: No
    .... ..1. = direction: Master -> Slave
    .... ...1 = CRC: OK
    channel: 6
    RSSI (dBm): -61
    event counter: 0x0145
    delta time (us end to start): 29473
    delta time (us start to start): 29921
Bluetooth Low Energy Link Layer
    Access Address: 0xaf9a9a62
    Data Header: 0x0001
        000. .... = RFU: 0
        ...0 .... = More Data: False
        .... 0... = Sequence Number: False
        .... .0.. = Next Expected Sequence Number: False
        .... ..01 = LLID: Continuation fragment of an L2CAP message, or an Empty PDU (0x01)
        000. .... = RFU: 0
        ...0 0000 = Length: 0
    CRC: 0x71fb5b
        [Expert Info (Note/Protocol): unchecked, not all data available]
            [unchecked, not all data available]
            [Severity level: Note]
            [Group: Protocol]

No.     Time           Source                Destination           Protocol Length Info
    854 22.454362000   Slave                 Master                ATT      52     Rcvd Handle Value Notification, Handle: 0x000b

Frame 854: 52 bytes on wire (416 bits), 52 bytes captured (416 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan  1, 1970 02:26:02.405204000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8762.405204000 seconds
    [Time delta from previous captured frame: 0.003247000 seconds]
    [Time delta from previous displayed frame: 0.003247000 seconds]
    [Time since reference or first frame: 22.454362000 seconds]
    Frame Number: 854
    Frame Length: 52 bytes (416 bits)
    Capture Length: 52 bytes (416 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle:btl2cap:btatt]
Nordic BLE sniffer meta
    board: 16
    uart packet counter: 53322
    flags: 0x01
    .... .0.. = encrypted: No
    .... ..0. = direction: Slave -> Master
    .... ...1 = CRC: OK
    channel: 6
    RSSI (dBm): -66
    event counter: 0x0145
    delta time (us end to start): 151
    delta time (us start to start): 383
Bluetooth Low Energy Link Layer
    Access Address: 0xaf9a9a62
    Data Header: 0x1a16
        000. .... = RFU: 0
        ...1 .... = More Data: True
        .... 0... = Sequence Number: False
        .... .1.. = Next Expected Sequence Number: True
        .... ..10 = LLID: Start of an L2CAP message or a complete L2CAP message with no fragmentation (0x02)
        000. .... = RFU: 0
        ...1 1010 = Length: 26
    CRC: 0x99ef58
        [Expert Info (Note/Protocol): unchecked, not all data available]
            [unchecked, not all data available]
            [Severity level: Note]
            [Group: Protocol]
Bluetooth L2CAP Protocol
    Length: 22
    CID: Attribute Protocol (0x0004)
Bluetooth Attribute Protocol
    Opcode: Handle Value Notification (0x1b)
    Handle: 0x000b
    Value: 004b0051006a002b0016005a00860028001000

No.     Time           Source                Destination           Protocol Length Info
    855 22.481251000   Master                Slave                 LE LL    26     Empty PDU

Frame 855: 26 bytes on wire (208 bits), 26 bytes captured (208 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan  1, 1970 02:26:02.432093000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8762.432093000 seconds
    [Time delta from previous captured frame: 0.026889000 seconds]
    [Time delta from previous displayed frame: 0.026889000 seconds]
    [Time since reference or first frame: 22.481251000 seconds]
    Frame Number: 855
    Frame Length: 26 bytes (208 bits)
    Capture Length: 26 bytes (208 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle]
Nordic BLE sniffer meta
    board: 16
    uart packet counter: 53323
    flags: 0x0b
    .... .0.. = encrypted: No
    .... ..1. = direction: Master -> Slave
    .... ...1 = CRC: OK
    channel: 21
    RSSI (dBm): -62
    event counter: 0x0146
    delta time (us end to start): 29480
    delta time (us start to start): 29920
Bluetooth Low Energy Link Layer
    Access Address: 0xaf9a9a62
    Data Header: 0x000d
        000. .... = RFU: 0
        ...0 .... = More Data: False
        .... 1... = Sequence Number: True
        .... .1.. = Next Expected Sequence Number: True
        .... ..01 = LLID: Continuation fragment of an L2CAP message, or an Empty PDU (0x01)
        000. .... = RFU: 0
        ...0 0000 = Length: 0
    CRC: 0xdf2b5b
        [Expert Info (Note/Protocol): unchecked, not all data available]
            [unchecked, not all data available]
            [Severity level: Note]
            [Group: Protocol]

No.     Time           Source                Destination           Protocol Length Info
    856 22.485934000   Slave                 Master                ATT      35     Rcvd Handle Value Notification, Handle: 0x000b

Frame 856: 35 bytes on wire (280 bits), 35 bytes captured (280 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark_nordic_ble)
    Encapsulation type: USER 10 (55)
    Arrival Time: Jan  1, 1970 02:26:02.436776000 Hora estándar GMT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 8762.436776000 seconds
    [Time delta from previous captured frame: 0.004683000 seconds]
    [Time delta from previous displayed frame: 0.004683000 seconds]
    [Time since reference or first frame: 22.485934000 seconds]
    Frame Number: 856
    Frame Length: 35 bytes (280 bits)
    Capture Length: 35 bytes (280 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: nordic_ble:btle:btl2cap:btatt]
Nordic BLE sniffer meta
    board: 16
    uart packet counter: 53324
    flags: 0x01
    .... .0.. = encrypted: No
    .... ..0. = direction: Slave -> Master
    .... ...1 = CRC: OK
    channel: 21
    RSSI (dBm): -84
    event counter: 0x0146
    delta time (us end to start): 150
    delta time (us start to start): 382
Bluetooth Low Energy Link Layer
    Access Address: 0xaf9a9a62
    Data Header: 0x091a
        000. .... = RFU: 0
        ...1 .... = More Data: True
        .... 1... = Sequence Number: True
        .... .0.. = Next Expected Sequence Number: False
        .... ..10 = LLID: Start of an L2CAP message or a complete L2CAP message with no fragmentation (0x02)
        000. .... = RFU: 0
        ...0 1001 = Length: 9
    CRC: 0xd587b7
        [Expert Info (Note/Protocol): unchecked, not all data available]
            [unchecked, not all data available]
            [Severity level: Note]
            [Group: Protocol]
Bluetooth L2CAP Protocol
    Length: 5
    CID: Attribute Protocol (0x0004)
Bluetooth Attribute Protocol
    Opcode: Handle Value Notification (0x1b)
    Handle: 0x000b
    Value: 0304

… so, as i see, an Empty PDU is sent from the Master device after each packet, despite the 3 packets are supposed to be sent as fast as possible (within a connection interval?), and no back to back notifications are observed … does it make sense according to BluzDK behaviour?. thanks


#10

I haven’t looked at BLE Sniffer logs in quite a while, but the normal process is that bluz DK will send a packet and there is a link layer ACK that gets sent back for each one. So yes, you should see a back and forth for each packet.

The number of packets that can be sent per connection interval is entirely defined by the central, bluz will send them as fast as possible. As we don’t know the capabilities of the Duo, I can’t say what that would be, but it looks like you are measuring that now.


#11

Hi @eric, thanks for your answer … by looking at the code of scs_data_send() function, which is ultimatelly called by BLE.sendData() for sending packets from BluzDK, i’ve seen that here, a delay of 500ms is added when there is no space on tx buffer (which can store up to 6 packets, can’t it?) when transmitting data, but this delay is just of 0.5ms when sending the tail packet … why are those delays so different?. thanks


#12

That value can probably be reduced, we had a note in the code to go back and try it. However, it only comes into play in very specific situations, like when sending more packets then the TX buffers can handle, as you pointed out. It won’t affect most situations.

I will go back and try lower values, I am pretty confident it will work but making changes to such a critical function need to be very thoroughly tested.


#13

Hi again @eric … it’s been a long time :wink: … i’m trying to update the connecton interval on a BluzDK device acting as Peripheral to 10ms from a RedBear Duo acting as a Central device, by callng the BTstack function gap_update_connection_parameters(connection_handle, 0x0008, 0x0008, 0, 0x0048); … however, at least from the timestamp of the received packets on the Central device, it is not correctly set up … is there any custom limit on the connection parameters that can be established on the BluzDK device?. thanks


#14

In any BLE connection, the central decides the connection interval. The peripheral, bluz in this case, only offers up a recommendation of supported values, but the actual value is chosen by the central.

Bluz supports connection intervals down to 7.5mSec, the lowest allowed by the standard. I am not sure what the Duo supports, you would have to check with them. It could be possible they don’t support connection intervals that low. You can try setting it to only 10 mSeconds in bluz by using the new function like this:
BLE.setConnectionParameters(10,10);

However, this may have unintend consequences, such as not being able to connect to the central at all, so you should leave yourself a way to change the value back by holding a pin high/low at power on time to exit that mode if needed.


#15

Hi @eric,thanks a lot again! That función is a great added value for bluzdk! … i’ll check ir andando post the results i obtain using it. Thanks