I am wondering why there is a 512 Byte limit on the BLE characteristic size? Is this to keep the data transmission rate slower? Can I change it to, say, 10,000?
I am currently modifying the ArduinoBLE library for faster real-time transmission of a 3-byte protocol I developed and am looking for speed optimizations.
Sorry, I have no answer for your question to the 512 Bytes. But ...
I am interested to hear/read more about your real-time transmission.
I am developing my own library for a real-time communication on Nano BLE 33 (bypassing mbedOS and ArduinoBLE) based on non-connectable and non-scannable advertise-pdus. My aim is to transfer 6x16Bit (acceleration and gyro) with 10 measurements per second for each of about 50 devices (distributed multi-channel measurement).
Hi profrob. I suggest using the standard ArduinoBLE library functions for this transmission, except when before transmitting the packets, you should include a buffer which holds <27 bytes of payload (3 packets at a time). You can also try larger values <125 bytes but I had some reliability issues with the board stalling.
Send these packets to a peripheral or relay board to be sent serially or through another BLE transmission to your computer/device. You could also run the Bluetooth transmission concurrently to your board's CPU activities for more speed optimization.
With this method, I was able to get 40kbps which satisfies your desired throughput.
Thank you very much for the answer.
It is a pity, that we did not met earlier for discussing the usage of the library.
I have no experience with the ArduinoBLE library, because it does not fit to my own environment based on software-timer scheduled state machines.
But I thought about using ArduinoBLE without my environment (about 6 month ago) and the main problem for me was to build a network with 50 devices transferring 10 measurements (6*16Bit) per second. I had no idea how to do this.
Now I nearly finished my own protocol with a master/slave structure (1 master, 50 slaves). The master is polling the slaves. With response time-out of about 1 ms I can control the channel quality and I am working on a channel switching which is fast enough to guarantee the measurement rate also in case of disturbances by other radio transmitters (WLAN).
It took awhile, but I am knowledgable enough to provide you a more suitable answer to your first question. Though it may be too late!
Throughput can be maximized to about 1.5Mbps if you have a dedicated transmitter and receiver which should be more than enough for your needs. I was able to transmit at that rate without any data at close range so if you would like to add acknowledgements, etc, the bandwidth is there for your setup. Further away, you may be looking more at 1/8th that (because the Radio sends 8 duplicate symbols per bit sent), while using the PHY (Long-Range capability) of the NRF52840 RADIO Peripheral.
Your network setup should still operate well within this spec. Developing a custom protocol, and removing all the unnecessary abstraction freed up significant amount of overhead and latency and allowed me to free up CPU usage elsewhere on the device, especially while running the measurements continuously in parallel to the CPU (recording data through EasyDMA in a rotating buffer).
I spent the better part of November working on optimizing this system and found some revelations that may be helpful. My response yesterday to an older forum post may also be helpful (below). Let me know if this all makes sense!
thank You for the answer.
I've also read your other thread and now I see, that we both did nearly the same (bypassing mbedOS/ArduinoBLE).
But I did not have problems with the interrupt handling, may be, because I have overwritten the vector table at run-time with NVIC_SetVector(irq, isr).
Communication was more easy and had less interrupt load by using the wiring of TASKS and EVENTS via SHORTS (registers of the nRF52840).
My bigger effort was to use BLE beacons according to the BLE specification instead of sending raw data via RADIO. My hope was, to find a way for integrating tablets and smartphones via own developed APPs. But that did not work (till now).
My master/slave-polling is running good and because my polling speed is about ten times faster than my measurement rate, I have a rather reliable data transmission. Very seldom losses of measurement values (< 1/1000).
My next step is to switch channels in case of disturbances and to combine more masters and slaves on different channels. I also want to test larger distances with lower transmission speed and lengthening the pdu-preamble.
But that will not get true before the next year.
So have a nice Christmas and a happy New Year (all readers).
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.