LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

reading serial spp Bluetooth device

I have A device that sends a message over blutooth (spp) once a second and i want to read the device and record the output with out missing messages. problem is it seems like the timing gets off and i miss messages or get half messages sometimes. cant find a way to read consitant. The device does not seem to have a termination char being sent so its hard to find end of message and the number of bytes sent can vary. Any ideas???

 

thanks 

brian

0 Kudos
Message 1 of 11
(3,332 Views)

example of message 

 

A1A2 A3A5 0000 9903 0012 020C 0805 1036 1824 2019 2801 3000 3800 4000 0017 020D 0800 1000 1800 2000 2800 3000 3894 7348 0050 0058 0000 1B02 0D08 0110 9803 1898 0320 9803 2800 3000 3893 3C48 8B25 5000 5800 0018 020D 0802 1000 1802 2000 2800 3000 3894 6348 EC0E 5000 5800 0018 020D 0803 1000 1800 2000 2800 3000 3894 6348 A65E 5000 5800 0018 020D 0804 1000 1802 2000 2800 3000 3894 6348 FA32 5000 5800

0 Kudos
Message 2 of 11
(3,331 Views)

Is there anything in the message stream that tells you how long a message is?  Such as the first 1 or 2 or 4 bytes saying how many bytes there are to read?  If so, read that many bytes, then immediately decode that to determine how many more bytes to read (thus getting rid of the the bytes at port method).

 

If not, how do you know where one message ends and another message begins?

 

You can read conitnuously and build your message stream up in a string shift register.  Keep looking at the string and once you get a complete message, delete that out and process it, leaving the remaining bytes in the shift register.

0 Kudos
Message 3 of 11
(3,319 Views)

there does not seem to be message lenght. The message does start the same way every time but the end can change

0 Kudos
Message 4 of 11
(3,312 Views)

Okay, then you can do what I said in the last paragraph.  Keep accumulating your reads in a shift register until you can determine that one message has ended and the next one has begun.

0 Kudos
Message 5 of 11
(3,308 Views)

maybe im not fully getting your idea there is alot of time when there in nothing in the buffer if i read all the time since the device only sends message once a second

0 Kudos
Message 6 of 11
(3,293 Views)
If there is nothing in the buffer, then you don't do a read. A simple case statement will do.

How are you interpreting the data? Is it one byte at a time or do you need multiple bytes? What is sending the data? Do you have a manual that you can attach? There's not a lot of detail on your posts and its hard to provide specifics.
0 Kudos
Message 7 of 11
(3,284 Views)

Then why do you have a .02 second delay in your loop? You are reading 50 times per second on something that is only being sent once per second?

 

Why are you flushing the receive buffer?  If your message is incomplete, you are discarding any bytes that arrive arrive during that .02 seconds.  What made  you think it was a good idea to flush the buffer?  Flushing the buffer rarely, if ever, needs to be used.

0 Kudos
Message 8 of 11
(3,280 Views)

was flushing the buffer to make sure there was no parts of a old message on the next read

0 Kudos
Message 9 of 11
(3,271 Views)

But in reality those are probably bytes that belong to your current message.

 

Flush a toilet.  Don't flush a buffer.

Message 10 of 11
(3,265 Views)