bytes to read function? is it slow?

[Luis Bertel]

holas, estoy desarrollando un programa para mi proyecto de grado el cual comunica una red zigbee de 4 nodos y un coordinador implementado una interfaz grafica en labview. actualmente realice pruebas con 2 dispositivos finales y el coordinador recibiendo datos de estos cada 100ms y 500ms , los datos recibidos constan de una cadena de caracteres hexadecimal de 28 bytes maximo, note que al recibir la trama se estan perdiendo datos de una cadena o se estaba partiendo la cadena en 2 cadenas diferentes, al mirar a travez de un loopback me fije que este error no aparece, luego de cambiar la funcion bytes to read a una constante fija (28) el problema se soluciona pero se limita a leer siempre el puerto serial.

existe alguna forma de solucionar este problema.

Adjunto el vi usado, la parte de la derecha es solo para particion y reconocimiento de la trama, la izquierda esta la lectura y escritura del puerto serial

*************************

I am developing a program for my graduation project that linked a 4-node ZigBee network coordinator and a graphical interface implemented in LabVIEW. i have tried with two end devices and the coordinator, the data  receiving of these devices is every 100ms and 500ms, the received data consist of a hexadecimal string of 28 bytes maximum, note that on receipt string some data have been lost, or split in two different chains, looking with a loopback  I noticed that this error does not appear, then i have changed the function "bytes to read"  to a fixed constant (28) the problem is solved but is limited to always read the port serial.

is there anyway to fix this problem? can i use the function BytesToRead when devices send me data every 500ms ?

first code is the one using a fixed constant

the second one is using the bytetoread function

[MarcoMauri]

Hi Luis!

Try using an End Of Line character instead of a fixed number of byte to read.

BytesToRead simply tells you the number of characters available, but you can't be sure that they are *all* the characters you need.

Marco

[Luis Bertel]

hi Marco,

i cant use the end of line character cause the data (strings) send by zigbee device ends with a random hex byte which is the checksum of string, thats why i use the bytestoread, its work great when i use a loopback on the "com1" but when i activate zigbee transmission wont work like i said before he seems to loose some bytes or parse the string

[johnsold]

Luis Bertel,

I looked briefly at your code but did not study it for long.

How is the beginning of the message defined?  Is there a unique character or group of characters (a header)?  Or is the only framing of messages by the pause between messages?  I hope not the latter because that is a very poor way to break up messages in an asynchronous communications system.

You mention 28 bytes maximum.  Can this number vary from message to message?

There are ways of dealing with some of these issues, but it is best to know what the communications protocol is before selecting one.

Lynn 

[Luis Bertel]

its a group of chars, i can only check when new packets arrive, the data string size can change , about the framing is the most common error it displays. i believe it happens since its has not enought time to read string , thats my guess im not sure

thank for any reply

[Luis Bertel]

 DATA STRING 7E001492010013A200405CA3B353170101000003021E021421

PROTOCOL:

7E START BYTE

0014 LENGHT

9201 API FRAME

0013A200405CA3B35317 -------SERIAL+PAN ID WILL NEVER CHANGE

01010000 -------COMMON OPTIONS  WILL NEVER CHANGE

03021E0214 --------DATA VALUE, THIS ONE I NEED FOR GOOD, CAN CHANGE

21 --------CHECKSUM CAN CHANGE

[johnsold]

Good.  There is lots of information about how the string is put together.

This now becomes a two-step process. The first step is reading data from the serial port. The second step is extracting the data value.  Do the steps independently.

The read serial port step: Read all the bytes available.  Send the bytes to the analysis part.  Repeat.

The extract data step: Get bytes from read part.  Append bytes to string (use shift register).  When string is longer than 28 bytes search for "7E".  When you find "7E" break down the following bytes according to the protocol you posted.  Leave any bytes left over in the shift register because they may be part of the next message.

I would put the two steps in separate parallel loops.  They can run at different speeds so long as the data extraction loop on average keeps up with the data sent from the device.  Each loop needs to have some kind of wait so the processor will switch between loops. 

In the example you posted it appears that the length is reported in hex and the count starts after the API frame bytes and includes the checksum byte.  Does that match what you have been told about the instrument?

Lynn 

[Luis Bertel]

ill problably misstype 2 bytes more , but length start with the api frame bytes included but not includes checksum byte, my bad.

acording to the separated  loop, u will be talking about like a FIFO structure? and this part i dont really get it "Append bytes to string (use shift register)." , what u mean by that'?

thx

[johnsold]

You should probably take some time to look at the on-line tutorial to pick up some of the basics of LabVIEW.

Here is a little VI which simulates reading from the serial port (in the for loop)  and appending to a string in the while loop.  It does not have everything you need to make a working program but if shows the basic concepts.

Lynn 

[Luis Bertel]

ty for the vi, i see what u mean now, i will try this way.