This schematic and source code are
intended for demonstration purposes only.
They are offered "as-is". Use at your own risk.
Code and circuits (and more) are here.
This circuit is liquid level detection and communication system for conductive
(and non-flammable) liquids that utilizes a variant of Raytheon's proprietary
marine-oriented Seatalk® bus. It was designed for marine applications (fresh
water tanks and waste holding tanks. The former is unpleasant when empty; the
latter is unpleasant when full!)
Up to four detection units, all in talker-mode, can transmit onto the bus.
The receiver displays each of the liquid levels as a percentage.
- Transmitter: Two tank number bits, five detection bits (20, 40, 60, 80, 100%)
10-second averaging. The transmitter board was fabricated using the ExpressPCB
Click on photo to display full size version.
This version uses surface mount components.
Click on photo to display full size version.
This is a probe assembly.
Click on photo to display full size version.
- Receiver: Pulls data line up (presently has no timeout for loss of
- Power: 8-16VDC at 5mA
- Data: protocol (as best it's known) is 12V, 4800 baud, 1 start
bit, 8 data bits, 1 cmd bit, 1 stop bit bit, all are talkers)
Transmitter sense rods are arranged in the tank(s) as illustrated.
It doesn't matter which rod goes to which input, except the ground
must be connected to the lowest rod. This is because the software simply
adds 20% for each rod that is in the liquid. Order doesn't matter.
The receiver and one or more transmitters are connected
to the +12, Data, and Shield wires of the bus. Hot plugging is OK.
Pins A0 and A1 are set low or high to define the tank number of a particular
transmitter. Connect to ground to make low; leave open to set high.
Tranmitter 1 | 1 1
Tranmitter 2 | 1 0
Tranmitter 3 | 0 1
Tranmitter 4 | 0 0
The transmitters have an adjustable holdoff period based on the two bit
tank number assigned to each transmitter. Thereafter, each transmitter broadcasts
it's number and level once per second.
The receiver listens for data messages and after validation, displays the
level value broadcast by each of the transmitters. In the particular design,
only the first three of the four tank numbers are used and displayed.
Water 1 23%
Water 2 85%
- Transmitter transistors Q1 and Q2 can be any suitable small-signal NPN type
that can handle at least 12V. Q1 is the transmitter; Q2 is the receiver.
Both invert the sense of the software, meaning that when the software sets
RA0 (the Tx pin) to HIGH, transistor Q1 pulls the data bus to 0V. And,
when +12V is received by transistor Q2, the transistor pulls RA1 (the Rx
pin) low. Pin RA1 should always follow RA0; if it doesn't a bus collision
is assumed by the software. Refer to Bus Software notes, below.
- R2 (5K) in the receiver pulls the entire data line up
for any number of transmitters, thus the weak R1
pullup may be omitted in each transmitter. However, if testing a transmitter that is
not connected to the bus, R1 will be necessary if you want to
see the broadcast 12V data levels on an oscilloscope.
(I noticed that certain Raytheon marine instruments that were connected to
the same bus as my three level transmitters had trouble pulling
the bus low if each level transmitter had the R1 pullup installed.
I removed R1 in every level transmitter.)
- You may need to install a 22K resistor from Q2-base to ground. This
will make it possible to sense marine instruments on the bus that are
(for some reason) not pulling the bus low enough during their
- If you are testing the transmitter microprocessor alone in a
stand-alone test socket
without the peripheral Q1/Q2 circuitry, be sure to connect pin 18 (the Rx monitor) to
pin 17 (Tx). Otherwise the code will think that a data collision occured (because
Rx won't match Tx bit-for-bit), and will
immediately stop the message transmission, and will attempt to retransmit the
entire message continuously, in which case all you will observe on
an oscilloscope will be a continuous stream of start pulses.
- To observe the messages on the bus with a PC terminal emulator
such as Procomm or Hyperterm, connect RS-232 pin 2 (assuming a 9-pin RS232
connector) directly to the Rx pin on the PIC. Connect RS-232 pin 5 to ground.
Remember to include the parity bit in the setup of the terminal emulator.
Another DOS-based display program is found on
web site called SEAMON1.EXE.
- The reason for the Q2 inverter stage in the receiver (instead of the INVERT
keyword on the "#use rs232" statement in the receiver code) is because the bus
is running 12V data. I suppose a series current limiting resistor could be used
instead of the transistor, letting the PICs ESD diode to Vdd clamp the incoming
voltage at 5.7V, but that just doesn't seem like a clean solution.
- Any 5V regulator may be used.
- Diode D1 is simply for reverse polarity protection and may be omitted if
reverse polarity won't happen.
- The transmitter Port B bits have external pull-up resistors activated
in the software code. Thus, the drains of the five FETs, as well as the two
tank number bits, do not need external pullup resistors.
- The liquid must be conductive and must not be flammable.
The 2N7000 FETs provide a high impedance input and allow for wide variations
in liquid conductivity.
- Fouling of the tank rods will result in inaccurate readings.
This may be a particular issue in a waste tank where
conductive solids could stick to the rods.
This would have to be mechanically prevented.
- There are five sense rods that correspond to 20%, 40%, 60%, 80%, and 100%
capacity. These rods extend downward into the liquid to depths that correspond
to those percentages.
A sixth rod (ground) extends into the liquid below the other five rods.
- If the tank is not cubical in shape (tanks having
a triangular cross section are often found on boats) the rods are extended
to adjusted depths so that the five percentages are still correct.
It's advisable to
locate the rods in such a manner to maintain level accuracy despite rolling motion
of the tanks (if in a boat.) Often that will be in the lateral center
of the tank.
- Galvanic corrosion of the stainless steel sense rods due to DC sense current
is not expected to be a problem. Assuming the liquid is water, the
DC resistance in a test setup of stainless steel rods exhibited something like
100K ohms. That, plus the 1M resistor results in a current of approximately
5uA, and that current is applied to each sense rod for only 2.1mS, and then only
once per second.
The ground rod would return the total of the five sense rod currents, or 25uA at the
same period and frequency. Thus, corrosion is not expected to be an issue.
- Data messages are broadcast in the form: FE 01 0x yy where
- hex FE is the message ID (in this application)
- hex 01 is the number of bytes in the message beyond the mandatory three bytes
- hex 0x contains the tank number (00, 01, 02, or 03)
- hex yy contains the percentage (0 thru 100)
- A message is sent at essentially 4800-9-P-1, where the parity bit is really a
command bit that is set to +12V to define the first byte of a message;
0V in the remaining bytes. If messages require more than three bytes (as
in this application) any additional bytes follow and the second byte is set to
the count of the additional bytes beyond the mandatory three. This application
requires four, thus the second byte is set to 01.
- The interesting thing about the protocol is that it is a serial data
protocol operating at 4800 baud in which no marine instrument on the bus has an
"address" and there is no master/slave or talker/listener relationship. They
are all considered talkers. A talker simply listens to the bus for 5mS to
ensure it's idle then transmits the three or more bytes in the message. The key
element in the protocol is collision detection. Each talker monitors it's own
transmission to ensure that no other talker corrupts the message during transmission.
If a collision occurs, both talkers retransmit again after some period of time, sooner
for the higher priority devices. Since talkers listen for longer than one character
time (2.28mS which is 11 bits x 208uS) prior to transmission, the only time a collision
might occur is if both talkers happen to be listening at the exact same time and
then start transmitting, and statistically that is a low probability because Raytheon
marine instruments typically broadcast their messages (such as depth, knots,
temperature, etc.) every second or two (and lower priority messages are sent even less
often.) Thus, there is plenty of room in which to successfully insert immediate
(high priority) messages from devices such as a remote control.
- The hardware UART in the 16F628 could have been used, but this code
was written so that it could be embedded in the GPS Repeater (on this website)
whose UART pins are already occupied with other data. Thus, special provisions
had to be made in this non-interrupt-based software,
such as timeouts if no start bit is received in a reasonable period of time.
- The SendBit procedure is tuned code such that bit times are as close to 208uS
as possible (4800 baud.) An entire four-byte message should take 9mS from the
falling edge of the first start bit to the rising edge of the last stop bit.
That stop bit itself takes 208uS more, for a total message time of 9.2mS.
Future versions may make use of the timer, periodically checking it for timeout
while monitoring the transmitted bit (more often than the present code does) to
ensure no data collisions occur.
- A good reference is Thomas
Knauf's web site, part of which is listed in the source code comments.
- If the liquid height is somewhere between two rods and if there is any
motion of the liquid, there may be times when the upper rod will sense the liquid
and other times when only the lower rod will sense the liquid. The levels are
read at one-second intervals and averaged over ten seconds. Thus, level readings
other than 20%, 40%, 60%, 80%, and 100% will sometimes be transmitted.
CORRECTIONS OR UPDATES