“Byte Gaps and Data Latency – The way Bluetooth is designed and operates random byte gaps of 5 msec to 20 mesec are common. Packet size will vary from transmission to transmission. The faster the UART speed the smaller the byte gap delay.”
I’ve made a program to read in real time , but in BlueRadio statement mentions there is a gap between bytes. Currently i’m using serial MAX232 and it works fine , until i change to bluetooth , it gives miscellanious data and not correct. Even if i change the baud rate more than 115K . (My source 115K & Receive 115K)
… Does it means there’s a loss of data in every byte?
Or … is this Blueradio not compatible to such enviroment like real time?
It’s just referring to the fact that the Bluetooth module doesn’t transfer the bytes one-by-one as they come in over the serial port; they get transmitted in packets. So if you watch the bytes coming out of the receiving module, they’ll arrive in clumps with 5-20 msec between each clump. You should be getting the same sequence of bytes, they might just have little hiccups.
This kind of thing will be true of any radio link, fwiw, as long as it’s doing error detection/correction (like bluetooth does). The alternative is to get the bytes immediately, but have them possibly be the wrong bytes. If you need low/constant latency at the expense of possibly seeing noise/corrupted bytes sometimes, try one of the simpler modules like the Laipac modules. Those just translate the voltages directly to RF, without any buffering or smarts.
wiml:
It’s just referring to the fact that the Bluetooth module doesn’t transfer the bytes one-by-one as they come in over the serial port; they get transmitted in packets. So if you watch the bytes coming out of the receiving module, they’ll arrive in clumps with 5-20 msec between each clump. You should be getting the same sequence of bytes, they might just have little hiccups.
This kind of thing will be true of any radio link, fwiw, as long as it’s doing error detection/correction (like bluetooth does). The alternative is to get the bytes immediately, but have them possibly be the wrong bytes. If you need low/constant latency at the expense of possibly seeing noise/corrupted bytes sometimes, try one of the simpler modules like the Laipac modules. Those just translate the voltages directly to RF, without any buffering or smarts.
Does this mean the bluetooth naturally have to make this protocols (buffers) ? Causing gaps in data ?
One more thing … i use the Bluesmirf with a third party Bluetooth Module (Taiwan made) that connected to USB . I found there are some bluetooth module connected to RS232 port (not USB). Are these different?
My taiwan made bluetooth module succesfully sends data to my Nokia phone usually. But when doing it with my project , it seems not right …
mrmerell:
Does this mean the bluetooth naturally have to make this protocols (buffers) ? Causing gaps in data ?
Yes … I might call them “pauses” not gaps if I were writing the documentation. No bytes should get lost. Just delayed by a few milliseconds.
I found there are some bluetooth module connected to RS232 port (not USB). Are these different?
In theory any bluetooth module should be able to talk to any other one … I use the built-in bluetooth in my laptop to communicate with a bluesmirf, and it works fine. I’m not an expert though.