Avatar of NUdovich2
NUdovich2 asked on

RS232 Cable Communication

I have a piece of laboratory equipment that transmits lab results to its home computer using an RS232 cable.  I have a spy cable monitoring that port for activity as I want to extract the data that comes off of it, parse the data, and place it into a database.  The problem is, the data that I recieve thru the monitor cable doesnt seem to make sense.  I am very new to this area of computers and I am thinking (hoping) that I just dont understand output enough to "see" the matrix.  I will attach a typical output file.

The machine is set at bit 7 or 8, stop bit 1, parity none and the monitor program is set to match the variables on the machine.  I can have the monitor cable output in ascii, Hex or binary what have you but none of this (even translated) makes sense.  Clearly binary or hex wont make sense unless translated, I understand that.  

For reference here is the link to the online specifications manual for the lab equipment....
http://www.olympusamerica.com/files/dsg_AU400_AU640_LISspecs.pdf


Output.txt
ProgrammingNetworking Hardware-Other

Avatar of undefined
Last Comment
NUdovich2

8/22/2022 - Mon
cool_sathish_333

Hello NUdovich2,
The topic related to 232 Communication was discussed earlier, check out whether it helps you...

-$athi$h...
cool_sathish_333

ASKER
NUdovich2

It would if i knew what any of that meant....im not a programmer.  I simply have a spy cable and a third party program to "see" the data.  What that data should say is at minimum, lab results.  Perhaps that thread would be helpful if I knew at all where to start / what to look for.  I am not looking to program anything I just want to know if the spy cable is an acceptable way to see data and then, if so, what the settings need to be and why if all things are equal does my data output look like the file attached.

Thanks,
Your help has saved me hundreds of hours of internet surfing.
fblack61
moorhouselondon

According to that Olympus link, there are two modes of broadcast Class A and Class B.  If you are "passively" listening for results (which I think you are), rather than having a dialogue with the equipment "send me the next item, got that, now send me the next", then the equipment needs to be setup in Class A mode.
ASKER
NUdovich2

Ah ha.  I bet that is it.  I know that it is in Class B mode, I will try it in class A and tell you what happens.  That said, from what you read in the Olympus link, If I am passively listening to the machine then I should "see" the data?  (Realizing it has to be parsed).  Would it show up in ASCII, and if it does need the machine need to be set up to have 7 bits whereas 8 bits is Hex?  Again, total newbie to this part of computers....

-Ill let you know Tuesday if that class A thing works...I really appreciate the possible solution.

moorhouselondon

The thing about using Class A "handshaking" (i.e., none) is that your monitoring device (Spy cable, as you call it), has to be fast enough to see everything coming down to it.  If it is not fast enough to see everything then that information is lost.  (It is just like a phone conversation:  Class A is where you temporarily take the earpiece away from your ear, when you come back to listen to the other person they may have said something and you've totally missed it;  Class B is where you say "Hang on a minute, I just need to turn the oven off", and when you come back, you ask them to continue what they were saying).

Your spy cable has no knowledge of the data you are capturing, it is just presenting the information to you in a way that thinks might be helpful - it seems to treat FF as a kind of Record delimiter, rather than as maybe a field delimiter, or part of the data, whereas I would need to look at the Olympus spec to see what its' true meaning is.

I am surprised that the Olympus doesn't come with interface software and connector cable in order to interpret the info?

As regards the data that is coming through.  RS232 is a Serial Communication method, one bit at a time is being read at a time off the wire which can either be 1 or 0.  How do you know where a "conversation" begins and ends?  Stop bits add structure to the stream, in the old days 2 stop bits were necessary, but now 1 is the norm.  The Olympus collects stuff to send down the wire in groups of 8 bits and fires them off down the wire.  In the old days noise on the line was enough to cause data to be falsely read, in a way to combat that, instead of sending 8 bits, the equipment would send 7 instead of 8, and use the spare one as a Parity Bit.  If Even Parity was used to parcel up the bits then altogether, if you added up all the bits that are sent, the bits that are 1 must add up to an Even number.  The parity bit was used to make this correct e.g.,

X0001111

X is the Parity Bit.  To ensure Even Parity, X has to be set to zero, as there are already 4 one's (an even number of 1's).

Parity is not very helpful at spotting errors (suppose that two or more bits had the wrong value, it might not be able to detect a problem), so don't bother using that, set the equipment to use All 8 bits for your data (No Parity).

Now the Output log you included with your Q could have been in submitted in binary, but that is not very readable, so hexadecimal has been used to present the info.  Each 4 bits worth of data is represented by a Hexadecimal Digit.  

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = A
1011 = B
1100 = C
1101 = D
1110 = E
1111 = F

The Olympus spec needs to be read to determine how the data is structured.  If you had a device which was sending normal text like what I am writing here, then using ASCII mode would be more appropriate, as you would see the characters forming words with a hiccup every so often where a structural barrier is reached.  I need to have a look again at the spec, but I think Hexadecimal format is more appropriate for your application.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
moorhouselondon

I've had a quick look at the spec.  All "transactions" start with

01 1F

Then the type of transaction RB (for example):-

52 42

uh?  where'd I get that from?  Have a look at http://www.asciitable.com/ You need to convert R (which is an ASCII character) into hexadecimal.  Look for R in the table and you will see it corresponds to a Hex value of 52.  Ditto with the B, which is 42.  

The next data is:-

00

which is the Unit number (I presume it will be 00 or 01, whatever it is it will be the same throughout the data).

Then you have your data, which can be any length (defined by parameters setup in the equipment), up until 01 1F is received.  (Note that the 01 1F value cannot appear in the data stream: you can ignore this comment if you find it confusing).

The last byte (8 bits) is called the BCC.  This is like the parity bit explained earlier, but it checks the integrity of the block of data just received.  Its' value can be worked out (if you have the inclination/time/patience, etc. etc.) by Exclusive Or'ing all the received data together, one by one, and seeing if it matches the value given by the BCC bit.  Hello hello.  Are you still there??
moorhouselondon

In your sample output file, I see no 01 1F occurrences, so there's something wrong somewhere.
ASKER
NUdovich2

Right, so the 'something wrong" could that be the fact that it is not on type A communication?  That is the only variable I can find....well...you can find.  I wasnt able to test that.  There are other things on the internet that individuals have built that "see" data from the Olympus but it isnt the full solution I want, they only capture the quality control data.  Anyway, those setups use a spy cable but that documentation never mentioned anything about the A vs B type.  And yes, you are right I do not intend to do anything but listen to the conversation.  

Here is the site with that third party program that looks at QC.  There is a short bit of information there to maybe help us (you) triangulate an answer.  Again, wont have the chance to try this until tomorrow but already you've been very helpful...thank you!

http://www.multiqc.com/MultiQC5.pdf
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
ASKER
NUdovich2

As I was pondering A vs B, I began to wonder if that would negate the communication between the host computer (the computer that came with the Olympus which sends commands to the machine to run a paraticular test) and the machine.  While I am passively listening, the host computer is not so I imagine setting it to A might negate that as I suspect.  The MultiQC information might lead you somewhere I have not been...they use the same setup with a spy cable...there is little information out there about getting data from the olympus directly but there is a whole slew of 10K dollar third party software out there that does it when i talk to them they seem to intimate that they too, use a spy cable.  
moorhouselondon

Thing to do is to try setting to A, and see if that changes the captured output at all.
ASKER
NUdovich2

Well, I tried that and no, nothing changed.  Pretty much the exact output.  Looking more closely at the Olympus specs I believe that the start code is 02 (not 01 1F as you thought, I believe that is the range of options as manageable by the Host computer)  It is and always was set to 02 (STX) where the end code is set to 03 (ETX).  Not that this changes anything in the output, it still doesnt seem right, although I set it to Class A, it asks for character length, i set that to 8, parity bit, none, stop bit 2 baud rate 9600.  

Im at a total loss here.  I know this is possible, I just have no idea how it occurs.

Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
dannlh

I see all RX information in the capture file what about the TX side of the link?
ASKER
NUdovich2

The host computer which sends commands to the olympus does recieve all its data, prints them etc.  The capture file should have discernable information in it after parsing such as name of lab test, lab result etc but...on translation of the hex or ascii (depending on how i have it being catpured) i dont see that.  Again, newbie to this rs232 stuff so i may not have answered your question.  

However, I can tell you that today I learned that one company that does an interface doesnt use a spy cable.  Once the results are sent to the computer, they use the second Rs232 port on the host computer to "capture" the data and send it to their interface.  Id rather not spend the cash but I might have to unless this latest insight allows an expert to point me in a direction as to how to do this.

The olympus host computer DOES store the information in a .mdb database.  Most of the information is there except in the test result / test name fields the information is stored as blobs and even with blob translation I cant get anything meaninful out of that.  Looks like Ill need to spend 5 grand.

dannlh

When I was looking at the trace file all the lines indicated [RX]. This usually would be indicative of the Recieve side of the spy cable. There should be [TX] data also. Here's the issue: If were seeing the sniffed data from the host, then you won't see any results. If we're seeing data from the diagnostic machine then there is either something wrong with the config for the capture (causing all the data to be wrong) or it may just be a mistake in decoding. I don't think we're seeing both sides of the communication between the host and the diagnosis machine. Also [RX] and [TX] doesn't tell us which machine's [RX] or [TX]. There are one of each one each end of the link.
 Minimum config for RS232 is RX<-TX from host  TX->RX to host and GND(ground). Let me know if you find a way to monitor the TX stream from the spy cable. By the way, what brand/model spy cable do you have?

You are correct when you say the data doesn't make sense. But its usually one of three things: Bad paramaters on spy setup, wrong data stream or incorrect sentence decode instructions in the manual ergo: wrong manual or wrong version of the manual.

Is the machine controlled by a front panel, or by commands from the host?

Verify the paramaters for communication 9600, N, 8, 1 or whatever they should be on both the spy cable and the machine.

Also there are parameters according to the manual that are set in the machine that can change. Such as machine ID. Please let us know what those paramaters may be set to.

dh
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy
ASKER
NUdovich2

Interesting, I hadnt thought that maybe what was being spied was the host computer...transmissions to the Olympus.  I suspect it is olympus to host because...when the host printer starts to print a patient result the spy file correspondingly goes "crazy"....the host at that point shouldnt be sending a command right?

The spy cable and program i am using is 232Analyzer, half duplex and I have verified the parameters for communication multiple times as well as fluxuated those on both ends to see if that changed anythimg....
ASKER CERTIFIED SOLUTION
dannlh

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
ASKER
NUdovich2

Went with 3rd party vendor.  Thanks for the pointers points to you.