LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

during a bluetooth read, system is dropping data in 4096 byte chunks

My program drops data in 4096 byte chunks, causing read timeout errors (the requested number of bytes never arrive). Is there some buffer of this size that is messing up? Can you adjust the BlueTooth read buffer size? Data is coming in at 230.4K. An earlier version of this program ran at 57.6K and I don't think it did this.
0 Kudos
Message 1 of 9
(3,208 Views)
More information available:

The actual data size getting lost is 4088 bytes. The total data stream is 29825 bytes. The lost block seems to occur around 23000 bytes (it varies a bit between runs) and is one contiguous block of data. It never loses the first or last bytes of data. Sometimes it works and collects all data.

With a larger data stream (49715 bytes), it lost one block of 4088 and one block of 4096 bytes. I didn't trouble shoot that data run to know where the lost blocks were.
0 Kudos
Message 2 of 9
(3,180 Views)
Hello,

There are a couple of ideas that immediately come to mind when you describe your problem. First, if you are reading in your data inside a loop, you may need to make your wait inside the loop smaller. If the program does not read in the data fast enough, the buffer will overflow. Also, are you using one of the example vis that ship with LabVIEW? If not, try using these and see if you experience the same behavior. They can be found in the Example Finder from the Help menu. Search Bluetooth to bring up some basic vis. This will help us determine exactly where the problem is. One last question, what type of information are you reading in? Is it from a data acquisition board or is it file I/O?
Finally, I am not aware of any way to change the Bluetooth read buffer size. However, by changing some features of your program, we may be able to fix the problem without altering the buffer size.

Thanks,
Caroline
National Instruments
Thanks,
Caroline Tipton
Data Management Product Manager
National Instruments
0 Kudos
Message 3 of 9
(3,150 Views)
Here is more information:

I am not reading the data inside a loop. I am trying to read it as one long read. I have also tried splitting it into two shorter reads. When I did this, the length of the first read did not move where the dropped data was. I tried reading from 1000 to 25000 bytes out of 29000 and it always dropped at around 23000. When I read more than 23000 in the first read, the first read timed out. When I read less than 23000 bytes in the first read, the first read is successful but the second read times out. It kind of acts like the first read doesn't clear the buffer. The data is streaming during the first read. Is it possible that the read buffer stops reading when LabView is reading the buffer? (ie no double buffering?)

I am using a custom VI, but I looked at the examples and I am not doing anything different. The Bluetooth VIs are pretty simple. I am connecting, calculating and then reading the set number of bytes (in either one read or two successive reads) and displaying the data. Then I close the connection, pretty much the same as the example.

The data is binary data from a D/A system of my design. I am using an off-the-shelf serial/Bluetooth converter. When I slow down the transmission to 115K, it works fine. It seems like there is some buffering problem at 230.4K read.
0 Kudos
Message 4 of 9
(3,148 Views)
Hello,

I have escalated this problem to the PSE of LabVIEW to find any possible ways to fix your problem. Unfortunately, there is currently no way in LabVIEW to alter the or clear the Bluetooth buffer. As this seems to be the problem that we are running into at this high speed of streaming data we are left with very few options. I was hoping that you could simplify your program so that I could recreate it. I can then file a Corrective Action Request so that a developer can eventually take a look at the problem. I am sorry that there is currently no way to alter the buffer, but we can look into this issue for future integration into LabVIEW.

Regards,
Caroline
National Instruments
Thanks,
Caroline Tipton
Data Management Product Manager
National Instruments
0 Kudos
Message 5 of 9
(3,114 Views)
I have a similar problem.
I am controlling a scanning system with a PDA to a PC. Basically joy stick functions with sub menus. I'm using bluetooth and for this to work reliably I need two way communications.
My question is: Is there any way to check the buffer without erroring out on a Bluetooth read?
This seems to be the only Bt function that gives a fatal error.
This would also be helpful as a check from the PC to the PDA on weather the PC needs to switch modes of operation.
0 Kudos
Message 6 of 9
(3,092 Views)
I solved my own problem.
I had the automatic error handling switched on. I turned it of and I created my own buffer flush function.
Life is good again.
Using LV 7.1 and PDA pocket PC module
0 Kudos
Message 7 of 9
(3,090 Views)
Hi I read you be able to flush bluetooth buffer.
How have you make this function? Which vis have you used?

Thank's a lot

elisa
0 Kudos
Message 8 of 9
(3,040 Views)

@gulm wrote:
Hi I read you be able to flush bluetooth buffer.
How have you make this function? Which vis have you used?

Thank's a lot

elisa


Like I said first you uncheck automatic error handling, then create a while loop that reads from the device, contiune until you get an error. The buffer should be flushed. I am also using the cr lf mode.
0 Kudos
Message 9 of 9
(3,017 Views)