Data rate

RE: Data rate

run_ar — Tue, 16 Nov 2021 14:43:20 GMT

I do not think BLE transmission will be disrupted, as these time sensitive operations are running on the highest priority. It is more likely that the application doesn't have time to place data in the TX buffers before the next connection event. As an experiment you could try to increase the interval to see if that helps.

Do you know how much time is needed by the app to have everything in place for the next ble transmission? Do you prepare the data right before the next event or right after the previous event? Have you tried using the radio notification api to update the data?

RE: Data rate

Yano — Mon, 15 Nov 2021 09:13:24 GMT

We sniffed the communications and we don't think its a radio / packet loss issue.

We have two i2c devices on two separate buses one is on the PCB (IMU) the other (senor) a clip on/off device.

Both these devices are scanned using a timer on interrupt and they work reliably without error.

Both reads are done in the background together at APP_IRQ_PRIORITY_HIGH.

The data from these devices is then transmitted.

If we remove the clip off sensor the code detects an i2c error and breaks out putting all zeros in the place for transmission.

When we do this the delays are removed and we get a steady stream of data (see scan).

The Tx is done at the same time after the scan.

The only difference are:

1. The i2c read is cut short

2. The sensor portion of the data is all zeros.

Could the SD and/or BLE transmission service be disrupted by two rather than one background TWI events and if so is there a way around this?

Thanks

Ian

RE: Data rate

run_ar — Thu, 11 Nov 2021 11:57:19 GMT

Hi,

My first thought on this is that you are likely loosing some packet every now and then? Maybe you could check with a sniffer to see if there is a failed transmission or acknowledgement in the "failing" connection event? then you should see the packet being re-transmitted in the next connection event 10ms later (which will give a 20ms delay).