Decoding a Legacy serial bitstream.

[SparkyOne]

I've got a bit of a problem, that I do not know how to approach in LabVIEW.    I have a Legacy device and controller that are communicating serially with each other, in what I believe is a DTE-DTE (null-Modem) configuration.    The problem is the 12-bit bitstream.....detailed in the attached VI, but here's the specifics:

19200 Baud

8 bits data

1 start bit

2 stop bit

1 parity bit (Even)

In HEX, the result cannot be handled in two bytes, without losing data....but if I go to 3 bytes....then I lose the beginning of the next set of data (4 bits).    I can likely decode 6 bytes....which would even-out everything, but it makes syncing on the start bit difficult.

Any thoughts on how I could grab an individual 12-bit command?

[Bob_Schor]

I may be wrong, but I think you are confusing RS-232 communication protocols with how your device encodes data.  If you are transmitting data via a serial stream with 8 data bits and Even Parity, that really means that you have only 7 bits of data (as the eighth bit is effectively the XOR of the other 7 bits in order to force the Parity to be even).  The Start and Stop bits are stripped out by the UART and never make it past the VISA Read.

So your problem is how to make a 12-bit number out of the low 7 bits and the high 5 bits (presumably the missing two bits are ignored).  When I've had to do this, I often read bytes, do some shifting and "byte-joining", and construct the required 12-bit number.  Note that you also need to know if the 12-bit data are signed or unsigned -- if signed, you may want to "propagate" the sign bit to create an I16.

Bob Schor

[StevenD]

Do you really need to read the stream frame by frame (my apologies to the network gurus if that is not the correct term)? Or are you just interesting in getting the whole data as soon as possible? If that's the case, and assuming all your settings are correct (baud rate, parity, stop bits, and especially the termination character then you can just have the visa read an amount of bytes bigger than anything you would ever to expect to see, like 1 meg. In that case when the VISA read reads the termination character it passes out all the data before that. The way you look like you are trying to do it is by reading the data bits themselves and then trying to construct a message from that, which I guess is doable, but why not let the hardware, and native LabVIEW functions do all that for you?

[SparkyOne]

Not to put too fine of a point onto the issue, but I have an old Apple II acting as a test controller, that I believe is on it’s deathbed.

I have the source code for the test program (Pascal), but to be brutally honest, the coding makes no sense to me at the moment.  

So, in the meantime What I’m trying to do, is “sniff” the Test commands off the serial stream, then reconstruct them using LabView.  I’ve done this with several other bit streams coming off Xilinx FPGAs, but this old system is just giving me fits.  

[RavensFan]

You are definitely confusing bits and bytes.  I don't even know what you mean by "legacy serial bitstream".

At the LabVIEW level, or even the VISA level, you don't see the bit stream at all.  The bits are handled by the UARTs of the serial ports on each end.  With VISA, you tell it start, stop, data, parity which gives that information to the serial port and the hardware in the serial port handles the bits, the 0's and 1's.  What gets read by using VISA are bytes.

If you are truly interested in what the bit stream looks like, then you need to read it with an oscilloscope.

If you want to sniff the commands being sent, then "tap" into the serial cable, and read that with your LabVIEW program.  Just make sure all the serial port settings match between you Apple, test controller, and PC/LabVIEW program.  The only thing I'd worry about is the apple side because Apple was notorious for using proprietary hardware that was locked down, so I don't even know if it had a true RS-232 port.

[Henrik_Volkers]

---

@RavensFan wrote:
[...]

If you want to sniff the commands being sent, then "tap" into the serial cable, and read that with your LabVIEW program.  Just make sure all the serial port settings match between you Apple, test controller, and PC/LabVIEW program.  The only thing I'd worry about is the apple side because Apple was notorious for using proprietary hardware that was locked down, so I don't even know if it had a true RS-232 port.

---

RavensFan, I don't know how old you are, but at the time of the Apple ][  all the hard and software documentation was available. I soldered my own orange ][ (clone) ... could have told you every bit (at that time 😉 ).

@ SparkyOne  if you have a a PC with a serial (com) port (better two ports), you can sniff the protocol.    Configure the settings as noted in LabVIEW ( disable termination and set flow control to none) use the Rx and the COM(GND) signal lines and connect (add)  them to the Rx (or Tx)  and GND of the old system.  If you have two serial ports at you PC configure both and hook the Rx(s) to Rx and Tx of the cable (andGND)  so you can sniff both lines.

Still possible that some hardware handshaking is used, but we ignore that at this point ...

You will get one (or two) byte streams without the start/stop bits , how it's encoded is the next question. But usually it's not too hard to make an edjucated guess 😄

If you have a scope, you can have a look at the signal flow. Is it challenge - response or a continious datastream?

How do the handshake lines behave? Fixed data length packets? ...  All this can be seens on the scope 😉

What type of device is connected to the apple?

[SparkyOne]

I'll try to answer all the questions above, as best as possible.  

Legacy serial bitstream = Very old serial program I cannot modify or edit, which send & receives both spontaneous and/or continuous data in a pattern, which I do not yet understand.  🙂

I have successfully copied one of the Tests using the program AccessPort  http://www.sudt.com/en/ap/ now I'm trying to repeat that in LabView.   For one test (of 9), I "captured" the entire "bitstream" and saved it as 5 separate text files, which I can send out to the Test Unit with the embedded "Send File" command.   I have attached one of these files "seg1.txt" as an example, not that it really shows or means anything.

The problem with all of this, is that I really cannot tell what is going on inside the Apple II....I can only see that it is sending serial data, which my Test Unit apparently understands.  The Apple II does have a Super Serial Card installed in slot 2.   I used ADTpro to rip the source code off the 5 1/4"disks, through this card.  http://adtpro.com/connectionsserial.html

I have really good documentation on the device that I'm trying to test.   As all of you have pointed-out earlier, if I configure the serial port properly....I should just get one Byte of data (8 bits), for each command sent.....but that's not what I'm seeing.   According to the manual, some of this data should be in "triplets", which is a 3-byte binary code (for one single command), and some of it is ASCII strings, in a similar triplet format.   That is what I'm trying to identify, and re-code into LabVIEW.

I have attached two snippets from the manual.....the "host" is the Apple II, the "panel controller" is a custom circuit card on the Test Unit.   Hopefully this clears-up the conversation a bit?

[RavensFan]

---

@Henrik_Volkers wrote:

---

RavensFan, I don't know how old you are, but at the time of the Apple ][  all the hard and software documentation was available. I soldered my own orange ][ (clone) ... could have told you every bit (at that time 😉 ). 

I'm old enough to remember my middle school getting Apple 2's then later 2e's.  I don't remember if they had serial ports, but then we really didn't need them as all we did was play "Math Blaster" in class.  I do remember that they came out with some communication means called "Appletalk".  I don't know what it was used for, but I do know that only Apple's had it.

[GerdW]

Hi One,

this is what your data look like when viewed in HEX display mode:

0284 8008 8180 0584 8020 8080 4881 FB20 8280 4883 FB20 8480
4885 FB20 8680 4887 FB20 8880 4889 FB20 8A80 488B FB20 8C80
488D FB20 8E80 488F FB20 9080 4891 FB20 9280 4893 FB20 9480
4895 FB20 9680 4897 FB20 9880 4899 FB20 9A80 489B FB20 9C80
489D FB20 9E80 489F FB20 A080 48A1 FB20 A280 48A3 FB20 A480
48A5 FB20 A680 48A7 FB20 A880 48A9 FB20 AA80 48AB FB20 AC80
48AD FB20 AE80 48AF FB20 B080 48B1 FB20 B280 48B3 FB20 B480
48B5 FB20 B680 48B7 FB20 B880 48B9 FB20 BA80 48BB FB20 BC80
48BD FB20 BE80 48BF FB20 C080 48C1 FB20 C280 48C3 FB20 C480
48C5 FB20 C680 48C7 FB20 C880 48C9 FB20 CA80 48CB FB20 CC80
48CD FB20 CE80 48CF FB20 D080 48D1 FB20 D280 48D3 FB20 D480
48D5 FB20 D680 48D7 FB20 D880 48D9 FB20 DA80 48DB FB20 DC80
48DD FB20 DE80 48DF FB20 E080 48E1 FB20 E280 48E3 FB20 E480
48E5 FB20 E680 48E7 FB20 E880 48E9 FB20 EA80 48EB FB20 EC80
48ED FB20 EE80 48EF FB20 F080 48F1 FB20 F280 48F3 FB20 F480
48F5 FB20 F680 48F7 FB20 F880 48F9 FB20 FA80 48FB FB20 FC80
48FD FB20 FE80 48FF FB21 8080 4981 FB21 8280 4983 FB21 8480
4985 FB21 8680 4987 FB21 8880 4989 FB21 8A80 498B FB21 8C80
498D FB21 8E80 498F FB21 9080 4991 FB21 9280 4993 FB21 9480
4995 FB21 9680 4997 FB21 9880 4999 FB21 9A80 499B FB21 9C80
499D FB21 9E80 499F FB21 A080 49A1 FB21 A280 49A3 FB21 A480
49A5 FB21 A680 49A7 FB21 A880 49A9 FB21 AA80 49AB FB21 AC80
49AD FB21 AE80 49AF FB21 B080 49B1 FB

In the first 15 bytes the pattern is somewhat different, but then it repeats quite clearly:

- each data block consists of 6 bytes: I start with "20 8280 4883 FB"

- first two bytes ("2082") contains a counter-like value, followed by "80"

- next two bytes ("4883") also contains a counter-like value, followed by "FB"

- with each following data block both counters are counted up by 2…

As you should see, which data is send by your Apple][ you should be able to reconstruct the data content…

[Bob_Schor]

I'll rehash what I said previously.  We have an ancient device that accepts "commands" (strings often starting with one or two letters, sometimes with numeric parameters, and I forget if it gets a terminator character or not, could look it up).  Each "command" can have a "response" consisting of a specified number of characters, or, in some cases, a stream with a particular "End-of-Stream" terminator character.  As I recall, communication was 7-bit ASCII (I don't recall if the Parity was Even or Odd).  For the multi-byte responses, we were told how to recognize the upper and lower sets of bits, and it was our responsibility to assemble the bits into appropriate (typically signed) Integer values.  Actually, the values were really positions and angles in mm and hundredths of a degree, so after we got the "integer number of mm", for example we divided by 1000 to get Position (in meters).

I suspect your instrument is doing something similar, and your code will need to "comply with the Protocol".  A little painstaking, but not so difficult.  As I recall, I wrote a separate sub-VI to handle each Command ("Get Position", "Get Azimuth", "Set Scale", "Set Hemisphere", etc.) and "buried" the details inside these sub-VIs.

Bob Schor