constraints on data rates thru dongle
On another thread , @ceremona asked about bluetooth constraints on sample rate. I split that question out here to a separate thread. The original question:
---
Here is a previous thread where some data rate calculations were tossed around, along with the idea of compression schemes.
http://openbci.com/forum/index.php?p=/discussion/94/using-dpcm-to-save-bandwith
Joel @biomurph should add a comment here, but he once mentioned that the dongle link is using a special high speed bluetooth mode that Nordic provides, called Gazelle. And that this was getting us about 130K bits/sec. But note that the data rate without the dongle, BLE, is much lower.
Ignoring the extra bytes of packet overhead for the moment,
((8 channels * 24 bits) + (3 axes * 16 bits)) * 250 sps = (192 + 48) * 250 = 60 Kbps of data to move
I'd like to hear what the actual measured values are, since there is not only packet overhead, but possibly also interpacket delays / flow control as well.
William
PS some Gazelle docs, http://developer.nordicsemi.com/nRF51_SDK/doc/7.1.0/s110/html/a00105.html
PPS interesting note by the BlueGiga people on BLE data rates; these guys seem to have missed the GZLL concept,
https://bluegiga.zendesk.com/entries/22400867--HOW-TO-Maximize-throughput-with-BLE-modules
Hiya folks, ...
Wanting to
clarify (if anyone knows) where the data speed constraint is for the
250hz sample rate? If I bypass the rfduino can I up the sample rate, or
does that sample speed limitation exist further upstream?
clarify (if anyone knows) where the data speed constraint is for the
250hz sample rate? If I bypass the rfduino can I up the sample rate, or
does that sample speed limitation exist further upstream?
Thanks, Cere
---
Here is a previous thread where some data rate calculations were tossed around, along with the idea of compression schemes.
http://openbci.com/forum/index.php?p=/discussion/94/using-dpcm-to-save-bandwith
Joel @biomurph should add a comment here, but he once mentioned that the dongle link is using a special high speed bluetooth mode that Nordic provides, called Gazelle. And that this was getting us about 130K bits/sec. But note that the data rate without the dongle, BLE, is much lower.
Ignoring the extra bytes of packet overhead for the moment,
((8 channels * 24 bits) + (3 axes * 16 bits)) * 250 sps = (192 + 48) * 250 = 60 Kbps of data to move
I'd like to hear what the actual measured values are, since there is not only packet overhead, but possibly also interpacket delays / flow control as well.
William
PS some Gazelle docs, http://developer.nordicsemi.com/nRF51_SDK/doc/7.1.0/s110/html/a00105.html
PPS interesting note by the BlueGiga people on BLE data rates; these guys seem to have missed the GZLL concept,
https://bluegiga.zendesk.com/entries/22400867--HOW-TO-Maximize-throughput-with-BLE-modules
Comments
https://www.google.com/search?q=arduino+i2c+slave
https://www.google.com/search?q=arduino+i2c+wire+library
https://www.google.com/search?q=rfduino+spi+slave
PS one other thought on I2C master vs. slave modes. Couldnt the uC (ATmega or PIC) and the RFduino do some kind of "mode switching" operation where the uC alerts the RFduino that a packet is ready to send. Then the RFduino drops into I2C master mode for the transmission; and the uC acts as a I2C slave. When the packet is finished then the link goes back 'normal' mode.
Currently the V3 packet is constant (33 bytes), it delivers 8 (or 16) EEG channels at 250 (or 125) SPS. With 115kb serial port limitation this is all we can get over the wireless link.
It would be great we the data packet could be dynamically customized, so that we can request independently:
1. how many channels (1..16),
2. how much precision (e.g. 16 bit or 24 bit samples)
3. and at what SPS (250, 500, 1000).
That way, if someone wants 16 channels at 250sps, they can select lower precision (16 bit samples).
Or, if someone needs just 1 or 2 channels but at higher SPS (this could be the most common use of the device!), it would be also possible even over slowest Bluetooth.
As long as SAMPLE_RATE * CHANNEL_COUNT * BYTES_PER_SAMPLE is less than ~1150 it would work.
Then it would be up to the client software (like BioEra or Brainbay) to make sure the required bandwidth is not exceeded.
Something like that would be more challenging to implement in the firmware. In fact I don't know if such firmware is even possible.
But it would provide ultimate flexibility so perhaps is something to consider.
Jarek
re: 115200 max serial receive baud rate for data packets sent to onboard RFduino
Do you think this is due to some "interference" from interrupts / callbacks from the radio link? In other words the UART on the RFduino may only have a single byte for buffering and if a radio callback causes that to overflow, your data packet sent gets garbled.
Is there any way to adjust the radio interrupt to avoid this? Such as either temporarily disabling it (for the duration of one packet.) Or setting up your serial receive interrupt at a higher priority level?
31 bytes @ 230400 bps = 1.3 ms
@250000 bps = 1.2 ms
@921600 bps = .33 ms
Some UARTs even support "hardware flow control" such that an extra line logic level stays low until the UART receive buffer is available. But you've probably thought of these already... :-)
Regards,
William
PS in the BLE world, since it is so much more intrusive interrupt wise, they have this API call,
https://devzone.nordicsemi.com/question/884/whats-the-maximum-of-baud-rate-supported-of-uart/
https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group__ble__radio__notification.html
You can send 1 packet (32bytes max) every 1.4ms (2 timeslots).
1000 / 1.4 * 32byte packets * 8 = 182kbit/s
182kbit would be the absolute theoretical max you can achieve. If the software interruupt priorities for the radio are reduced to that which is lower than the UART, then you will begin to lose radio packets.
The only way to increase the UART baud rate above 115200 at this point would be to use flow control.
Our serial library currently doesn't have flow control implemented, so it will be something you would have to add support for. Also, the Arduino serial library doesn't have flow control support, so support would needed to be added for it as well.