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 🙂
@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.
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)
btw Omar, my "xD" was a funny smile not really talking about the character 🙂 sorry but thanks again
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
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