Poking around in 3rd party hardware, baudmode?

xanatos · 2014-03-05 15:43

I've got some RF tank level monitors and their receiver. I'm looking to be able to read the receiver's output. It's serial data, of unknown flavor. I've hit it with the usual 9600/8/N/1 and it returns garbage. So I put together the program below which looks at the output (the receiver outputs automatically every 7 seconds, so I just change the baudmode parameters, then listen for and debug the output each time, for five consecutive samples). Everything comes out garbage, but at least 4800 baud at various settings seems to give a more consistent garbage.

So after getting nowhere with that, I set up my brand new scope on the output and obtained the pic below.

The level rides high (1) at idle. The scope screen shown is set for 2ms/div.

Anyone out there who can help me understand what to look for on the scope output to recognize what baudmode ranges I should try here?

Thanks,

Dave

' =========================================================================
'
'   {$STAMP BS2px}
'   {$PBASIC 2.5}
'
' =========================================================================
' -----[ Constants ]-------------------------------------------------------

#SELECT $STAMP
  #CASE BS2, BS2E, BS2PE
    T2400       CON     396
    T9600       CON     84
    T19K2       CON     32
  #CASE BS2SX, BS2P
    T2400       CON     1021
    T9600       CON     240
    T19K2       CON     110
  #CASE BS2PX
    T1200       CON     3313
    T2400       CON     1646
    T4800       CON     813
    T9600       CON     396
    T19K2       CON     188
    T38K4       CON     84
#ENDSELECT

' -----[ I/O Definitions ]-------------------------------------------------

  Crx           PIN     1               ' White
  Ctx           PIN     0               ' Green

' -----[ Variables ]-------------------------------------------------------

  serStr        VAR     Byte(24)
  x             VAR     Nib

  ' -----[ Program Code ]----------------------------------------------------

PAUSE 1000
DEBUG "Polling", CR

  Main:


    DEBUG "8/N/I/1200 - 19697", CR
    FOR x = 1 TO 5
      SERIN Ctx, 19697, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/I/2400 - 18030", CR
    FOR x = 1 TO 5
      SERIN Ctx, 18030, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/I/4800 - 17197", CR
    FOR x = 1 TO 5
      SERIN Ctx, 17197, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/I/9600 - 16780", CR
    FOR x = 1 TO 5
      SERIN Ctx, 16780, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/1/1200 - 3313", CR
    FOR x = 1 TO 5
      SERIN Ctx, 3313, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/1/2400 - 1646", CR
    FOR x = 1 TO 5
      SERIN Ctx, 1646, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "8/N/1/4800 - 813", CR
    FOR x = 1 TO 5
      SERIN Ctx, 813, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

        DEBUG "8/N/1/9600 - 396", CR
    FOR x = 1 TO 5
      SERIN Ctx, 396, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/I/1200 - 27889", CR
    FOR x = 1 TO 5
      SERIN Ctx, 27889, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/I/2400 - 26222", CR
    FOR x = 1 TO 5
      SERIN Ctx, 26222, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/I/4800 - 25389", CR
    FOR x = 1 TO 5
      SERIN Ctx, 25389, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/I/9600 - 24792", CR
    FOR x = 1 TO 5
      SERIN Ctx, 26222, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/1/1200 - 11565", CR
    FOR x = 1 TO 5
      SERIN Ctx, 11565, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/1/2400 - 9838", CR
    FOR x = 1 TO 5
      SERIN Ctx, 9838, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/1/4800 - 9005", CR
    FOR x = 1 TO 5
      SERIN Ctx, 9005, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

    DEBUG "7/E/1/9600 - 8588", CR
    FOR x = 1 TO 5
      SERIN Ctx, 8588, [STR serStr\24]
      DEBUG STR serStr, CR
    NEXT
GOSUB sep

DEBUG "END OF OUTPUT", CR


    STOP


' ----[ Subroutines ]-------------------------------------

sep:
  DEBUG "-----------------------", CR, CR
RETURN

PropGuy2 · 2014-03-05 17:11

Assuming it could be anything at any baud rate, I would probably use a good PC terminal program. At least you know the chosen baud rate and can easily change all the parameters: inverted signal, parity types, etc. Ooops - forgot lots of computers nowadays don't have a RS-232 port. Sigh!

Tracy Allen · 2014-03-05 17:43

Expand the timebase to get a better fix on the durations of times Low. Use the 'scope time cursors to assist with that. Find the shortest duration, and others should be a multiple of that. My a quick look at the scope shot (2ms/div) looks like a time low = ~0.4ms, guess 2400 bps.

It is possible the device is using a binary protocol and/or a parity bit either of which could show up as garbage even if the baud rate is correct.

LoopyByteloose · 2014-03-06 05:37

Try using a copy of RealTerm on a Windows machine. It is intended for exactly this kind of a problem.

http://realterm.sourceforge.net/

And it is Free.

A scope may be useful to determine the baud rate, but stop bits and parity and whether you have 7 or 8 bit ASCII (or EBIDIC) really require a terminal application that lets you try things.

xanatos · 2014-03-06 09:36

Thanks folks - I found the duration of the lows and highs was just a little over 205uS, which runs to about 4800 baud, which gives me the most consistent looking data, but it was all still junk. So I did hook it up to my terminal program, and walked through every combination of baud rates, inverted/non-inverted, parity even/odd//none, 8 bit, 7 bit... Still looked like junk.

So I finally broke down and called their tech department and actually got someone who understood what I was doing - and it's serial data sort-of - it's not byte formatted, it's actually their own proprietary format that generates counts to drive their display, so it has to be interpreted.

Hence, terminal programs and basic stamps, expecting serial data, see serial junk.

Thanks for your help folks. It was fun poking around with the terminal program and being able to change formats with just a click - hadn't really thought to do that before.

Mark_T · 2014-03-06 19:21

This signal from the receiver could be the off-air packet itself?

It doesn't have to be UART serial, and if it is it doesn't have to be ASCII - binary values and a binary CRC are likely. The start of
the sequence could be a preamble. The coding may be designed to limit the max number of consecutive 0's or 1's for reliable clock-
reconstruction. If its off-air the timing might be a bit jittery too.

You need a "known-plaintext" attack - start capturing signals as the level changes by small amounts, look for patterns...

These are general observations for any kind of RF serial link - there are considerations of signal integrity that lead to
more complex coding schemes being used.

xanatos · 2014-03-07 05:52

Hi Mark,

I get a signal every few seconds even without the transmitting units being on. I suspect the receiver has its own internal rom that loads values from the received signals, and just steps through the locations for the receivers in a round-robin sequence, outputting the last received value for that tank.

I'm hoping to get the document from the company today that outlines how to interpret their data stream. Should be interesting to see how close my observations and guesses were

LoopyByteloose · 2014-03-07 07:47

Take a look at RealTerm.... It doesn't require the serial data to be byte-sized. In other words, it is very flexible on confirming your data... more so that just about anything else.

Proprietary serial can have all sorts of odd stuff. You serial mouse and serial keyboard transmit 11 bits in one direction and 12 in the other.. just to keep us from easily hacking.

xanatos · 2014-03-07 10:33

Hi Loopy,

I'll try realterm... especially if it doesn't expect byte data. I'm looking for something that doesn't require 1, 1.5 or 2 stop bits... Just the bits, ma'am.

Thanks,

Dave

Tracy Allen · 2014-03-07 11:14

Another useful tool is the Saleae logic analyzer. For starters, it lets you see long stretches of activity, zoom right, left, in and out. Pick apart the bits. The serial protocol analyzer can help too, with hex or ascii display, number of bits selectable from 4 to 64 as well as flexible options for baud, polarity, parity etc.

Screen shot 2014-03-07 at 11.08.32 AM.png

xanatos · 2014-03-07 11:22

I might as well try that too! Thanks... I figure the more tools I have to poke into other manufacturers' proprietary hardware/software protocols, the better.

Uhm... well, at $299.00... maybe AFTER I get the contract!

Publison · 2014-03-07 11:40

$149 for the 8-bit at Parallax.

http://www.parallax.com/product/32314

You were probably looking at the 16-bit.

Dave Hein · 2014-03-07 19:54

I wrote a program to look at one scan line in your scope image, and this is what I decoded:

-----------------------------------------------------------------------------------------------
    |    9f   |    81   |    00   |    8e   |    0f   |    0f   |    0f   |    c1  |    00   |
-----------------------------------------------------------------------------------------------

----_-----__--_-______--_________-__---___--_----____-_----____-_----____-_-_____--_________--

It looks like its coded as 1 start bit, 8 data bits and 1 stop bit. The baud rate is 4800.

LoopyByteloose · 2014-03-07 22:51

I ran into some lanugage about Stop Bits being the minimal indicator of a stop. In other words, 1 stop bit is equal to one bit of timing or more. And 1 1/2 stop bits would be equal to 1.5 bits of timing or more.

This may or may not be a factor.

But if this is really 8N1, it all is rather easy to use RealTerm to display in HEX rather than ASCII. From there, you might begin to decode what the reality is as it does seem that the code is NOT ASCII.

Dave Hein · 2014-03-08 04:48

It's been a few years since I used a Basic Stamp, but I think it might have problems receiving and storing a stream of bytes with only one stop bit in between them. Maybe someone who knows the Basic Stamp can comment on that. You may need to do this on a Prop where you could dedicate a cog to listen to the serial port.

LoopyByteloose · 2014-03-08 05:53

I don't think 1 stop bit would be an issue with the BasicStamp2. No Stop bit seems to be an oddity. All asynchronous serial is framed by a start bit and a stop bit.

What is in between can be 4, 5, 6, 7, or 8 bits. So it might be that what the OP is considering as a No Stop bit 8 bit is really a 7 bit packet with a 1 bit Stop bit.

Also, I believe that the BS2 can dump Hex or Decimal values to a terminal, rather than interpret data as being ASCII. But for the sake of verification, it might be wise to set aside the BS2 until something is confirmed.

The thing that the BS2 cannot do is Full duplex. Having Real Term running a Full duplex port might provide more insight into how the device interacts in the real world.

In any event, Real Term is intended to work with a serial port on a Windows computer and you can fool around quite a bit. So try 7N1 as well as 8N1. And also see the feature about reception of 'bursts' of more than one byte.

Dave Hein · 2014-03-08 08:12

I don't know how the serial port works on the BS2, but from what I understand it doesn't monitor the serial input unless the program is waiting for it. So if the BS2 starts listening to the serial input in the middle of a transmission it will get garbage. That may be why xanatos is getting bad data even at 4800 baud. A Prop running FullDuplexSerial should have no problem with this. The only thing left is to figure out what the received byte stream means. Maybe it can be reversed-engineered by testing out various tank levels.

xanatos · 2014-03-08 12:57

Hi folks,

I've tried 8N1, 7N1, even/odd/no parity, etc. The data is apparently NOT ASCII or anything directly recognizable by human reading. I played around with RealTerm for a few hours last evening and no matter WHAT settings I had - and I stepped through a bunch, I would get the little "Framing Error" light blink on every TX from the unit.

As for receiving the data, either from a BS2 or via RealTerm, I'm getting the same strings. The nice thing about the data is that there is a data burst every three seconds - and nothing in between but the level riding high (mark). SO even if the BS2 was to start listening in the middle of the first burst, it just spits that out in a debug and goes back to waiting for the next burst, where it gets it all.

When I have the baud rate set to 4800, it appears to give me the most consistent data, whether I'm looking at the binary output or hex values, or even ASCII. With ASCII, the first two characters are always 0? followed by 7 characters which are all in the extended ASCII set (the little y's & a's with dots and lines above them, that kind of stuff). And the scope trace, as mentioned by Dave above, does seem to indicate pulse widths that correspond to 4800 baud, and my own measurements show a pulse width of approx. 205uS, which concurs.

The issue now seems to be that the system does not output human readable data directly, but rather some other type of data that needs to be interpreted in order to become readable data.

I now have access to a device that would normally take in that data and - display it as human readable. I'm going to try to feed that some data and see if I can figure out how to get it to read stuff, then - assuming I can accomplish that, I'll have a way to translate the initial devices' output stream. Theoretically. Maybe. ...

I'll post my level of success in this endeavor up here

Dave

Gadgetman · 2014-03-08 14:58

There's a fun thing about the word 'assume'
To assume is to make an *** out of yoU and ME...

You're assuming that all 'packets' are of the same length...

Maybe it's not binary values as such, but just a row of pulses that the receiver has to count?
Possibly with some sort of 'break' inbetween to signal the end of one count and the start of the next?

xanatos · 2014-03-08 15:57

Gadgetman wrote: »

There's a fun thing about the word 'assume'
To assume is to make an *** out of yoU and ME...

You're assuming that all 'packets' are of the same length...

Maybe it's not binary values as such, but just a row of pulses that the receiver has to count?
Possibly with some sort of 'break' inbetween to signal the end of one count and the start of the next?

You're assuming that I'm assuming - and I'm not!

It's just that the data I have been able to acquire so far has been limited by the tools at my disposal. The scope display is the best reference I have yet simply because it is unfettered by any preconceived notion of what the incoming data should "look like". Additionally, in conversation with a tech who has some familiarity with these devices, he also suggested it was an interpreted binary stream, possibly, as you state, something that has to be counted in some way; however, with there being no section of data that is consistently 1/0 alternating transitions, it's an odd count.

Here is a sample of the output. It seems to repeat in blocks of 20 lines - which makes sense... 20 tanks. Each line is one data burst, with a three second rest in between. This is the data I will feed to the monitor box and see if I get intelligible readouts from it. If I do, I can start messing with values to see how it changes the display, and thereby, hopefully, figure out how to speak its language. Is it weird that I kind of enjoy this process? :nerd:

00110000 00111111 01100011 01000010 01100001 01100001 01110011 01111101 00000000 
00110000 00111111 01100011 01100000 01100001 01100001 01110001 01111100 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01101111 01111010 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01101101 01111101 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111101 01111010 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111011 01110110 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111001 01111011 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111101 01111110 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111011 01111110 00000000 
00110000 00111111 01100011 01100000 01100001 01100001 01111001 01111111 00000000 
00110000 00111111 01100011 01100000 01100001 01100001 01110111 01111110 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01110101 01111111 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01110011 01111111 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01110001 01111110 00000000 
00110000 00111111 01100011 01100001 01100001 01100001 01101111 01111110 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01101101 01111111 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111111 01111101 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111101 01111010 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01111011 01111010 00000000 
00110000 00111111 01100011 01000010 01100001 01100001 01110111 01111010 00000000

Tracy Allen · 2014-03-08 16:02

With 205µs as most likely time per bit, Dave's picture in post#13 looks like a good bet. It is consistent with either 4800 baud true, 8 bits, or 4800 baud true, 7 bits + even parity. A longer sequence might serve to strengthen the case one way or the other for 8 bits vs 7+parity. Assume standard 8 bit units until shown otherwise.

With 3 seconds between packets, and 4800 baud using the Stamp's STR modifier, it should be able to sync up and capture the packets. Absolutely so, since you are doing this with the speed demon BS2px. I'd do it something like this, dumping the hex values at a higher baud rate.

[SIZE=1][FONT=courier new]' {$STAMP BS2px}
' {$PBASIC 2.5}
serstr VAR BYTE(24) 
idx VAR BYTE
Ctx PIN 0
DEBUG "8/N/1/4800 - 813", CR
DO
  SERIN Ctx, 813, [STR serStr\24]   ' or 813+$2000 for 7/E
  FOR idx = 0 TO 23
    SEROUT 16,84,[HEX2 serStr(idx),32]   ' send to terminal as HEX at 38400
  NEXT
  SEROUT 16,84,[CR]
LOOP[/FONT][/SIZE]

"Framing error" means that one or more of the bytes did not have a proper stop bit. That is the sort of thing that the Saleae logic analyzer can point out in detail.

xanatos · 2014-03-08 17:53

OK, the original receive device doesn't seem to see at all the data I'm sending from my stamp, despite it looking very similar on the scope to the original data... Think I'm going to pick it back up tomorrow. Maybe I'll have a revelation overnight

Dave Hein · 2014-03-08 18:39

In my previous attempt at decoding the scope image I got the following sequence of bytes that I posted earlier.

 9f 81 00 8e 0f 0f 0f c1 00

This was based on a bit duration of 6 pixels in the image. After measuring the width of the scope grid in the image it seems like the bit duration is closer to 5.75 pixels, which corresponds to 4800 baud. When I used this value I got the byte sequence

 9f 81 00 8e 0f 0f 0f 81 00

The only byte that changes is the second last one. The significance of this byte sequence is that all of the bytes have an even number of 1-bits. So it appears that the data is sent as 7 bits plus an even parity bit.

LoopyByteloose · 2014-03-08 22:43

Well, I had high hopes that RealTerm would help out. At least it is free.

There is some discussion of the older versions of RealTerm (aka Terminal) being more useful in some ways. That may be worth looking into if you can get a download of the earlier version. The latest expanded into being much more than an RS232 interface.

Just the fact that you can confirm that the data to the BS2 is the same as the data to RealTerm is a very useful piece of information. From there, you can focus more on what the binary code represents and not so much of the format.

If Dave Hein has it right at 7E1, you may finally move ahead with some clarity.

Gadgetman · 2014-03-09 00:48

Jut thinking out loud for a bit...

Are the sensors analog, or are they some sort of switches?

I'd start with making certain that all the inputs are tied to the exact same value.
That should get you data packets that are identical, except for any packet/port IDs.

Are the inputs numbered?
(Of course they are... )
Fiddling with one input should get you one data packet that is different.
And hopefully only one...

xanatos · 2014-03-09 09:57

Just banging away, I think I've found some parts that are making sense. The data is ODD as can be - it's almost like it's fed backwards (note the last two bytes, for example, tank 01 is 81 00, tank 02 is 82 00, tank 18 is 88 81), but the one sensor that's hooked up reads in bytes 2 and 3. Below is the raw HEX2 byte codes from the output and my notes as to what tank, etc. Plus the code that got it at the top. Still not sure my formatting is correct, but it is intelligible to some reliable extent!

SERIN Ctx, 813, [serStr(0), serStr(1), serStr(2), serStr(3), serStr(4), serStr(5), serStr(6), serStr(7), serStr(8)]
DEBUG HEX2 serStr(0), HEX2 serStr(1), HEX2 serStr(2), HEX2 serStr(3), HEX2 serStr(4), HEX2 serStr(5), HEX2 serStr(6), HEX2 serStr(7), HEX2 serStr(8), 

CR

Raw HEX2 bytes      T# - Comments
9F81008E0F0F0F8100  01
9F81008E0F0F0F8200  02
9F81008E0F0F0F0300  03
9F81008E0F0F0F8400  04
9F81008E0F0F0F0500  05
9F81008E0F0F0F0600  06
9F81008E0F0F0F8700  07
9F81008E0F0F0F8800  08
9F81008E0F0F0F0900  09
9F81008E0F0F0F0081  10
9F81008E0F0F0F8181  11
9F81008E0F0F0F8281  12
9F81008E0F0F0F8481  14 - No tank 13
9F81008E0F0F0F0581  15
9F81008E0F0F0F0681  16
9F81008E0F0F0F8781  17
9F000F0F0F0F0F8881  18 - Only tank present, reads 0 (all others read E01, tank not present)
9F81008E0F0F0F0981  19
9F81008E0F0F0F8182  21 - No tank 20
9F81008E0F0F0F8282  22
9F81008E0F0F0F0382  23

Gadgetman · 2014-03-09 10:24

How does it look if you swith the bits around?
(Swap bit1 with bit8, bit2 with bit7, and so on)

What kind of chip is used as the 'brain' in the system?

Dave Hein · 2014-03-09 10:27

The MSB is an even parity bit. If you ignore that then the tank numbers make sense.

EDIT: Oh, I see what you mean by it being backwards. The digits seem to be least significant first. Can you try different liquid levels on tank 18 to see what you get? These are liquid level sensors, correct?

Tracy Allen · 2014-03-09 11:53

The BS2px is evidently able to capture bytes at 4800 with the syntax you have,
SERIN Ctx, 813, [serStr(0), serStr(1), serStr(2), serStr(3), serStr(4), serStr(5), serStr(6), serStr(7), serStr(8)]

On slower Stamps, the PBASIC interpreter would really bog down on the individual array elements. The faster syntax for capture of 9 byte packets is...
SERIN Ctx, 813, [STR serStr\9]
Also could add in a timeout. I know the OP is familiar with PBASIC syntax! Are the packets always 9 bytes long?

In these tank packets, it looks like 9F is the Start key, so...
SERIN Ctx, 813, [WAIT($9F), STR serStr\8]

xanatos · 2014-03-09 13:16

Tracy Allen wrote: »

The BS2px is evidently able to capture bytes at 4800 with the syntax you have,
SERIN Ctx, 813, [serStr(0), serStr(1), serStr(2), serStr(3), serStr(4), serStr(5), serStr(6), serStr(7), serStr(8)]

On slower Stamps, the PBASIC interpreter would really bog down on the individual array elements. The faster syntax for capture of 9 byte packets is...
SERIN Ctx, 813, [STR serStr\9]
Also could add in a timeout. I know the OP is familiar with PBASIC syntax! Are the packets always 9 bytes long?

In these tank packets, it looks like 9F is the Start key, so...
SERIN Ctx, 813, [WAIT($9F), STR serStr\8]

Lol... ya, the individual serStrings were a leftover result of a few dozen different iterations of code...

Always seem to be 9 packets, so far. I'm capturing a huge file full of the data now just to see if it's consistent over time, but it does appear stable.

Now I have to fill a 5 gallon bucket & drown my sensor

Hopefully I'll be able to see raw non-zero level data from that. Life should get easier after that... all I have to do is store it all and package it every hour into an email from my Spinneret, which I've done many times now.

More for the interested soon!

PS., the BS2px screams. I love to develop with it, and then, once the full thing is designed, if I'm not needing to take advantage of the PX's speed & memory features, I can use a less steamin' stamp... but that PX is my favorite.

xanatos · 2014-03-09 15:18

Got it - working perfectly, replicating the data as displayed on the local monitor display of the device.

Basically it's an "every other nibble of the bytes" arrangement. Not sure why, still wondering about the format - but it's rock solid right now. Code below, including the commented out lines that show the code's evolution (along with viewing the output to figure out the nibble positions).

Thanks everybody for your suggestions and thoughts.

DO
      SERIN Ctx, 813, [STR serStr\9]
      'DEBUG HEX2 serStr(0), HEX2 serStr(1), HEX2 serStr(2), HEX2 serStr(3), HEX2 serStr(4), HEX2 serStr(5), HEX2 serStr(6), HEX2 serStr(7), HEX2 serStr(8), CR
      'DEBUG HEX2 serStr(8), " ", HEX2 serStr(7), " ", HEX2 serStr(6), " ", HEX2 serStr(5), " ", HEX2 serStr(4), " ", HEX2 serStr(3), " ", HEX2 serStr(2), " ", HEX2 serStr(1), " ", HEX2 serStr(0), CR
      'DEBUG HEX1 serStr.LOWNIB(17), " ", HEX1 serStr.LOWNIB(16), " ", HEX1 serStr.LOWNIB(15), " ", HEX1 serStr.LOWNIB(14), " ", HEX1 serStr.LOWNIB(13), " ", HEX1 serStr.LOWNIB(12), " ", HEX1 serStr.LOWNIB(11), " ", HEX1 serStr.LOWNIB(10), " ", HEX1 serStr.LOWNIB(9), " ", HEX1 serStr.LOWNIB(8), " ", HEX1 serStr.LOWNIB(7), " ", HEX1 serStr.LOWNIB(6), " ", HEX1 serStr.LOWNIB(5), " ", HEX1 serStr.LOWNIB(4), " ", HEX1 serStr.LOWNIB(3), " ", HEX1 serStr.LOWNIB(2), " ", HEX1 serStr.LOWNIB(1), " ", HEX1 serStr.LOWNIB(0), CR
      tankNum.LOWNIB = serStr.LOWNIB(14)
      tankNum.HIGHNIB = serStr.LOWNIB(16)
      tLvl.NIB0 = serStr.LOWNIB(2)
      tLvl.NIB1 = serStr.LOWNIB(4)
      tLvl.NIB2 = serStr.LOWNIB(6)
      DEBUG HEX2 tankNum, " ", HEX3 tLvl, CR
LOOP