Maxbotic Sensor Protocol

["Frank Mc Alinden" <frankmc@xxxxxxxxxxxxxxxx>]

Hi Ian / Paul

Heres a copy of the protocl Gerry intends to use regarding the Maxbotic
sensor...Im not sure if he intends to do a pcb for it at this
stage...........He intends to be able to connect up to 12 devices to a
master pic micro........

HTH
Frank

**************************************************************************
Once I get that working and write a quick parser for received reports, what
is
left is:

1) Logic to continually poll each device (poll each one for a few samples).
2) Logic to update internal values for each device and trigger reports when
a value changes (if change reporting is enabled for that device).

I don't think either will be that hard.  That will provide

1) Ability to monitor 12 devices
2) Keeps the polling/scanning/comparing/constant reading isolated to
the PIC

I think that gives the ability to have each sensor independently configured
as

1) Polled.  Never sends an unsolicited report, only responds when queried
2) Triggered.  Sends a report anytime there is a change greater than a
defined
threshold (default threshold: 1).  Can still be queried like a Polled
sensor at any time
3) Periodic.  Sends a report every X seconds regardless of whether there is
a
change or not.  Can still be queried like a Polled sensor at any time

I can't think of any other ways that I'd want to track a sensor.

Using a 16F88/87, I'm seeing:

RA0-3, RA5-7, RB1, RB3-4, RB6-7 as sensor select lines that are held
high until it's time for the sensor to report.

RA4 is an input only, so we can leave it as MCLR (since it's not of much
other
value) or just ignore it.  Or we could use it as a single bit baud rate
selector (low = 9600, high = 19200 or 38400?).

RB0 is where all the sensors feed their serial stream into (use steering
diodes and a single pull-up resistor so they don't drag each other down --
it
appears that even when disabled (RX low), they put out +5 on the TX line

RB2 is serial in (RX) to the UART
RB5 is serial out (TX) from the UART
RB2/5 go to a MAX232 and then the computer.


For a protocol (serial), my initial thinking was

$CCSS...
CC is a command/report code, SS is the sensor # and ... is any
parameters.


Commands:
---------
$10SSFFPP
Configure sensor SS (00-0C) with flags FF and parameter PP

Bit
0-3 - Reporting Mode
0000 - Polled.
0001 - Triggered
0010 - Periodic
1111 - Disabled (not checked/tracked)
(other values reserved)
4-7 - Reserved

If Periodic, then PP is # of seconds between reports.
If Triggered, then PP is # of units change before a report is sent
For other configurations, PP is ignored

All sensors initially are defined as disabled.  Sensor configuration
is stored in EEPROM so it only has to be set once.

$20SS
Query Sensor SS for it's current value.  Causes a $80 value report
to be sent.

$21SS
Query sensor SS for it's configuration.  Causes a $81 report.

Reports
-------
$80SSVV
Result of a $20 Query, returns the current value, VV for sensor SS

NOTE: Disabled sensors will report 00 if queried

$81SSFFPP
Current configuration for sensor SS with FF and PP having the same
definition as they have in the $10 command.

$90SSVV
Triggered report, result of a change in a sensors value (for triggered
sensors) or periodic time (for Periodic sensors).  SS is the sensor,
VV is the value.

Note: I generally have my reports use the top nibble to indicate the
reason for the report and the lower nibble to define the report itself.
That
means all $8x and $9x reports will have the same parameters and meaning for
a
given value of "x", so a parser that doesn't care why it got the
report can
just look at the low nibble to determine what report it is.  If a parser
does
care about a status vs triggered report, they can check the top nibble. 
Not
all reports have a corresponding trigger version and vice versa.


$F0
Sent to confirm last command was received, valid and completed.  Note
that for some commands, the command may generate responses before
the command completes.  So you may receive reports or triggers after
a command is sent but before the $F0 or $F1 is returned.

$F1
Sent to indicate the last command was invalid or encountered an
error while executing (i.e. bad command code, invalid sensor #,
invalid configuration command, etc).

This is substantially similar enough to my sprinkler protocol that I can
adapt
my sprinkler xPL gateway with only 1-2 hours work to it.  The nice thing
with
the $F0/1 response codes is that it creates an automatic command pacing --
send a command, wait for a response (with some large timeout value -- I
usually use about 10 seconds) so you don't have to worry about delays (like
you do with the RGBLED controller).