LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview + xbee read sensor, uncoding the hex string

It seems unusual to append the checksum after a cr/lf but you can still use the termination character. Just read a single byte after the read where you get the values.
0 Kudos
Message 11 of 28
(1,838 Views)

Thanks Omar 🙂

i was stupid, didnt checked that Dennis already had a soluction for extracting my value xD

thanks for everything 🙂

Just a last question
if i were to add another information in my string, after the numbers, just a char (S or N, its for another sensor), the process is the same?

since its a character and not a number, how should i work with that?

you guys here are amazing, i should had come to the forums earlier 🙂

0 Kudos
Message 12 of 28
(1,836 Views)
The process should be the same. If, for example, you use String to Byte Array, you could use index array, a Byte Array to String with a typecast or flatten to string, join numbers with a typecast/flatten, etc. It would be helpful if you attached an image that shows the data in normal display. You might just need String Subset function.
Message 13 of 28
(1,830 Views)

@Raknugar wrote:

Also, i forgot to mention

since its in a while cycle it continues to read the valors, so i also need to find a way to stop it, or do a reading, register it into something (an array would be great, but since i cant even extract nothing from it, dont know how to do it), clear the buffer, and do the reading again

 

the final propuse of the program is to do 1 reading per minute for example, from the sensor that flows trough the xbee


How often does the YOUR device send you a message? If you wish to only take a reading once a minute, you will need to flush out old messages from the com port input buffer to be sure you are read the latest reading. Then you have to problem of reading in a partial message.

 

It would be best to keep reading all messages as they are send to stay in sync (in step) with your device and just throw away readings you do not want to keep.

Omar
Message 14 of 28
(1,827 Views)

@Raknugar wrote:

Thanks Omar 🙂

i was stupid, didnt checked that Dennis already had a soluction for extracting my value xD


The value xD is the ASCII code for "Carriage Return". What you get along with xA to mark the end of a line. I don't think it is part of you data.

Omar
Message 15 of 28
(1,821 Views)

Hey guys again 🙂

i intent to send information to labview once a minute, but i'll do modifications in the arduino (my MCU) to have a delay of 1min with each reading, so its simple, and dont need to make modifications in the labview. but if there somekind of timercount to display information in labview??

also Dennis, thanks again for helping me with the strings control, unfortonatly i dont have the material with me to test it.
I will have a indutive sensor, to monitor the speed of a motor, and for example, if the velocity is lower than whats expected within one minute (rotations per minute) i will say he is stopped (S for stop, N for non-stop), Thats why i asked
my final project would be like, display temperature, velocity of the motor (rpm) and if its stopped or not (maybe put a led on/off for it)

thats why my issue was to know how could i separate information

since it will come in the type of xx xx xx xx xx xx like we talk about

it would be like xx xx xx xx xx YY YY . YY YY SS RR RR RR xx xx

where yy yy . yy yy (its my actual 22.69 values), SS would be the information in ASCII code of the char for turned on or off (S or N) and RR is the value for rotations for minute (3 values, cause my motor wont reach more than 1000 rpm)

Am i clear enough? i'm sorry if my english sometimes is confused, i never was the best student in English classes (too much girls to look at :b)

0 Kudos
Message 16 of 28
(1,814 Views)

btw Omar, my "xD" was a funny smile not really talking about the character 🙂 sorry but thanks again

0 Kudos
Message 17 of 28
(1,812 Views)

Have you looked at regular expressions?

 

xbeeReadSensor.png

Omar
Message 18 of 28
(1,806 Views)

Thanks, i will try to implate this on my program 🙂

in a couple of days i think i'll manage to send you guys a feedback on this, once i get my hands on the rest of the material

 

you've been amazing with me

 

i wish i could pay you guys a beer or something

0 Kudos
Message 19 of 28
(1,799 Views)

An XBEE API frame of type 0x90 represents a received RF packet from another device.  In your packet, the first byte 0x7E is the start delimiter with which all XBEE API messages begin. The second and third bytes of the message you are receiving  say the message is 0x13 (19 decimal) bytes long (not including the checksum).   After stripping out one byte for the frame type (0x90) , 8 bytes for the 64 bit source address and 2 bytes for the 16 bit network address and 1 byte for the receive option,  you left with a payload of:

 

32 322E 3639 0D0A 

 

followed by a checksum of 0x85.   The checksum is calculated as [0xFF - (sum of all bytes from API frame type through data payload)] and is equal to 0x85 for this packet.  

 

In your message, the carriage return and the new line are actually part of the message you are sending from the remote device and not the end of message delimiter. I would guess that on the router end, you are ending the AT messages with a carriage return/new line.

 

API packets do not end with a new line/carriage return. The message length is given in the 2 bytes following the start delimiter (7E).  

 

The safest way to make sure your message is complete and intact is to start reading from 0x7E, the next two bytes are the MSB and LSB of the message length. Read that many bytes plus one (the checksum). Then, verify the checksum before parsing the message. 

 

In the case of frame type 0x90, the data payload always begins with the 15th byte. So you can discard the first 14 bytes and begin parsing there.  

 

If you only have one remote device periodically sending data, I would consider changing your coordinator to the AT mode, then your messages will come in the clear and look exactly like the way they were sent. All ascii and no hex.  

 

JohnCS

 

Message 20 of 28
(1,788 Views)