Instrument I/O Assistant and Streaming Serial Data

[sonex293]

I'm trying to use LabView 8.5 to display serial streaming data from an engine monitor.  I have started a blank VI, and added the IIOA to the block diagram and it opens.  Since the device is only a output device, I add a "Read and Parse" step.  If I run the step I can see the data coming from the device but I'm having a problem problem figuring out out to terminate the data stream for parsing.  There is a starting header phrase and the data follows.  Below is all the data that  the manufacture provides....

All data is transmitted at 9600 baud, one stop bit, no parity. The first 3 bytes are a header
that is unique, and will not show up in the data stream.

All 2 byte data is listed with an "H" and an "L" following the name of the data.  To combine these
two bytes into the result, multiply the high word by 256 and add the low word to the result.

All data is scaled with the least significant bit = 1 unless noted. All data is unsigned unless noted.

$FE        ; Header word #1 (Decimal 254)
$FF        ; Header word #2 (Decimal 255)
$FE        ; Header word #3 (Decimal 254)
TACHH      ; Tachometer or N1% - Resolution = 1
TACHL
CHT1H      ; CHT and EGT follow all have
CHT1L      ; a resolution of 1 deg
CHT2H
CHT2L
CHT3H
CHT3L
CHT4H
CHT4L
CHT5H
CHT5L
CHT6H
CHT6L
EGT1H
EGT1L
EGT2H
EGT2L
EGT3H
EGT3L
EGT4H
EGT4L
EGT5H
EGT5L
EGT6H
EGT6L
AUX5H       ; Auxiliary 5
AUX5L       ; 
AUX6H       ; Auxiliary 6
AUX6L       ; 
ASPDH       ; Airspeed (units are the same as displayed on the EIS)
ASPDL       ;
ALTH        ; Alitiude in feet
ALTL
VOLTH       ; resolution of 0.1 Volts
VOLTL
FUELFH      ; Fuel Flow (Gallons/Hour) resolution of 0.1 gallons/hour
FUELFL      ;
UNIT        ; Internal Insturment temperature
CARB        ; 2's compliment
ROCSGN      ; Vertical speed - 100 fpm resolution 2's compliment
OATH        ; 2's compliment - there is no low word
OILTH       ; Oil Temperature
OILTL
OILP
AUX1H       ; Auxiliary 1
AUX1L
AUX2H       ; Auxiliary 2
AUX2L
AUX3H       ; Auxiliary 3
AUX3L
AUX4H       ; Auxiliary 4
AUX4L
COOLH       ; Coolant Temperature
COOLL
ETIH        ; Hourmeter - Resolution = 0.1 hours
ETIL        ;
QTYH        ; Fuel Quantity (fuel flow totalizer) Resolution = 0.1 gallons
QTYL
HRS         ; Flight timer hours
MIN         ; Flight timer seconds
SEC         ; Flight timer seconds
ENDHRS      ; Fuel FLow time until empty - Hours
ENDMIN      ; Fuel FLow time until empty - Minutes
BAROH       ; Baroset in In HG - Resolution 0.01
BAROL       ;
MAGHDH      ; Tach2 (N2) High Byte
MAGHDL      ; Tach2 (N2) Low Byte
SPARE       ; Reserved.

Checksum (data summed and result complimented) is transmit here - 1 word. The checksum
does not include the header, but does include the "SPARE" word. The checksum is a single, 
8-bit word.

Any help getting IIOA up and running with this instrument would be greatliy appreciated.

Thanks,
Michael

[johnsold]

Michael,

The LSB = 1 may be the clue. Look for FE FF FE as the header. This cannot occur in the data stream if all other bytes except the checksum end in 1. Then count bytes and decode accordingly. You may need to AND each byte of data with FE to get rid of the LSB ones. The document is not clear on whether the data really is 7-bit words with a data flag or what. If it is 7 bits, then why multiply by 256? That works for 8 bits. Odd values will not occur and values with odd multiples of 256 will not occur, leaving some strange data patterns!

You will likely have to experiment with some known data to verify the decoding.

Lynn

[sonex293]

Here is a sample of the data ......





--
Michael

[waiter]

Parsing data from this engine monitor presents several challenges, This is the approach I used in my program "Waiter Flight Data Recorder"

http://www.iflyez.com/EFISRecorder.shtml

I buffer the stream as it comes in into a circular buffer that is 255 characters long.

Another routine starts looking the contents of the buffer, one byte at a time. I'm looking in particular for the three "Header" characters.

When I locate the header characters, I check to make sure there are XX number of characters in the buffer (did we receive the entire stream yet). If OK, I copy the next XX characters out of the buffer and put them in an array. If the completed stream hasn't been received yet, I wait until it has, then copy.

I then go through this array and parse out each character to its correct value assignment.

With this scheme, I need to maintain two pointers, 1) the location to place the next incoming byte, and 2) the location of the first character of the header.

VERY IMPORTANT

There are several header styles that you need to look for depending on the version of firmware in your monitor;

$FE $FF $FE or $FE $FE $FE ( I think there is another for the 2000 unit, but I can't remember??)

ALSO there are a couple errors in the Parsing assignments, off the top of my head the TACH2 and the Outside Air Temp are not correct.

(I'll need to look at my code to refresh my brain)

Waiter

[sonex293]

Thanks Guys.

Waiter, I tried using your program under Windows Vista and I have two problems:

1.  The Font color and Field color seem to be the same or "close" in color so I can't see the data.  I can just make out that there is data there, just can't read it.
2.  When I capture the data to a file, the data is "out of order", i.e. it looks like GRT has change the stream a little....I'm running and EIS-6000.

Back to LabView 8.5.  I still haven't found a way to use the IIOE tool to capture/parse data.  It looks like it wants a termination character, not a header string. 
I was hoping I could take the easy path!

--
Michael

[waiter]

Send me an e-mail and I'll see if I can figure out what's going on with the colors. I have many people using Vista with no problems, but I'm not sure they are using the GR6000.

What screen are you looking at, the COMM PORT RAW screen that's shown attached to this post?

As for the order, I assume your talking about the order of the fields in the file that I generate? If so, I never made an attempt to match the field in my data stream with the GR data stream.

END OF LINE - Its quite common for programs to look for some kind of END OF LINE, i.e. a LINE FEED, or a CARRIAGE RETURN. If there is a way to turn this off, it might work. I'm not familiar with NI.

waiter AT iflyez DOT com

Waiter

[waiter]

I uploaded Version 3.2.6 of Waiters Flight Data Recorder onto my web site.

This version corrects for the Windows Vista background problem,  AND, a parsing error when writing the GR6000 data to the text file (The display info was OK)

I see a discrepancy between what the GR reports in the Altitude (410 ft), and what Waiters Flight Data Recorder reports as altitude (41 ft).  I looked at my code for computing the altitude, I see nothing wrong.

What is the altitude of the GR6000. I'll call GR on Monday and find out what's going on!

Either the GR program is in error, OR, the parsing information supplied by GR is in error (not the first time)

Good luck

Waiter

[Ted_H]

Hi Michael,

If your device is waiting for a termination character, you can pass a termination character as a string value. Like waiter said, Line feed  \n and carriage return \r are common termination characters, but are specific to the device you are communicating with. 

Ted

Message Edited by Ted H on 11-19-2007 12:47 PM