Maxboxtix Controller Change Log

March 4, 2007 (firmware V1.1.1)
 * Bugs in the serial receive code that could cause command lockups have been
   fixed

 * EEPROM integrity has been further enhanced.

 * Unused sensor control pins can be used as digital outputs.  These outputs
   can be controlled by sending commands to the controller to set their state
   (so called "manual" mode) or can be "coupled" to a sensor and reflect
   various changes in the sensor (for example, an output changing states when
   an object moves into or out of range of a sensor or whever the sensor
   reading changes).

 * Unused sensor control pins can be used as digital inputs.  These inputs read
   TTL logic level inputs and can either be periodically polled/queried from
   the attached computer or be configured to send a report out anytime the
   status of the input changes.  In addition, an option "debounce" feature can
   be turned on to provide debouncing for inputs attached to mechanical
   switches and prevent false reports during switch transition.

 * Sensors can have an optional anti-jitter filter available.  Anti jitter
   addresses the problem where sometimes the sensor will misread and return a
   really odd/out of the ordinary value.  This can be non-linearities in the
   sensor mechanics, thermals or other difficult to track down issues.  With
   anti-jittering turned on, a sensor must read the same value 3 times in a
   row before it'll consider it a valid value.  This can delay reporting by up
   to 1/3rd of a second, so it may not be appropriate for all uses (hence the
   option).

xPL Interface

* The "reporting-mode" xPL item nas been changed to "sensor-mode"

* Support for outputs and input has been added to the schema and gateway

* Support for the anti-jittering option for sensors has been added

* Correctly support setting a name for a sensor and preserving that 
  between restarts in the config file


September 12, 2006 (firmware V1.0.4)
 * Added additional flags in the $90/$80 report indicating why the report is
   being sent (power up, brown out or watchdog).  Details in PROTOCOL.txt

 * The Baud rate pin meaning has been reversed/fixed.  It is now interpretted
   as HIGH=9600, LOW=19200.  This matches the legends on the PC Boards, but if
   you have a hand wired unit, you may need to reverse the jumper


August 28, 2006 (firmware V1.0.3)
 * Updated routines that store and retreive settings from EEPROM to be more
   robust.  The 16F8x chips are occasionally iffy on writting EEPROM, so there
   is code to write each byte 3 times as well as a 16 bit checksum and 8 bit
   CRC and after it's written, it's then read completely back and re-written,
   if needed.  On reading at startup/reboot, if the data does not have a valid
   checsum and CRC, any settings read up to that point are reset to "factory"
   defaults.

   This is solving a problem where by on occasion, the data would not all
   stick, leaving an incomplete configuration which is then read in and
   confuses the actual sensor logic (as it doesn't expect invalid
   configurations).  This can result in the chip getting stuck and staying
   stuck until it's reflashed (ans the EEPROM reset).  Now it should be more
   solid about storing good data, have a number of integrity checks on reading
   and a method to reset to factory defaults if things are wrong, preventing
   any lockup.

* Added a set of controller status flags to the $80/90 report.  Currently,
  there is only one bit that, if set, indicates the EEPROM was invalid and the
  factory defaults have been installed.

August 4, 2006 (firmware V1.0.2)
 * Initial Release