Home > Brew gear, Tech geeks > Calibrating serial comms

Calibrating serial comms

Thank god I am an engineer is all I can say. I can’t seem to leave things alone until I get an answer that makes sense and I can accept as truth.

I have been fighting communications to my pump skid control box for the past few days and was nearing the end of my rope. The outbound serial communications seemed to work just fine – the data arrived to the PC as expected, the packets were correct, and everything was great. Then I tried sending commands TO the grant skid and my messages kept getting corrupted. I would send a command and nothing would happen, or the skid would time out. I finally decided to implement a “loop back” debug routine so the PICAXE microchip simply read in 4 bytes and spit them back out so I could see if ANYTHING at all was working.

As it turns out, I would send something like “20 21 22 23” and get back “40 41 42 43”. I tried some other sequences like “01 02 03 04” and they worked fine, but once I got above about “08” things started going haywire. I’d send “09 0A 0B 0C” and get back “19 0A 1B 1C”, and the corruption only got worse as the values increased.

I tried all kinds of stuff to fix the problem. I dug into the VB code several times to ensure I was actually sending the correct bytes. I tried different XBee units. I checked solder joints, replaced some components, and many other fruitless ideas that just increased my anxiety over it all. Ultimately I pulled out my stock XBee board that I knew didn’t have circuit problems and tried the same thing – all the data echoed back just fine. I knew it was a difference between my board and the “commercial” one.

Long story short (might be too late at this point), the serial communication travels through several more components and a longer distance before it arrives at the PICAXE chip in my control box. The chip was sampling an extra 1 or zero at places because it was running just a little faster than the serial communication was actually coming in, leading to some data corruption. This is supported by an Excel analysis I did of the bits using the HEX2BIN function, showing where an extra 1 or 0 here or there resulted in the “bad” values it was returning. I fixed the issue by a simple “CALIBFREQ -4” in my PICAXE basic code, as shown below.

calibfreqcalibfreq2

I have little doubt that this also is the root cause for why my Grant to control box communications must run at 1200 Baud in order to be received properly, particularly with really long wires. The slower BAUD rate allows for the extra distance in wire, connectors, etc. I suspect I could probably tweak that grant communication with a CALIBFREQ command and increase the rate to a more respectable 2400 or 4800, and may end up doing that at some point.

At least I know what is going on now and should be able to implement the “real” inbound interrupt routine. At some point I need to seriously consider reworking and etching the main control board as a single unit (and perhaps take advantage of the new 28X1 features like background hardware serial buffering, since I understand them a little better) but I should be able to stick with this iteration for a little while longer.

Advertisements
Categories: Brew gear, Tech geeks
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: