Counting Poo/Version 1: Difference between revisions
No edit summary |
No edit summary |
||
Line 50: | Line 50: | ||
==== Serial Comms and Programming ==== | ==== Serial Comms and Programming ==== | ||
The unit | The unit has an 8-way connector on board for power, comms and programming. The connector pinout is shown in this image: | ||
The | |||
<gallery> | |||
File:LatrineSensor_8Way_Pinout.jpg | |||
</gallery> | |||
==== Test Mode ==== | ==== Test Mode ==== | ||
In the bottom-right corner of the PCB, there are two jumpers. If the left-hand jumper is bridged on power-up, the unit enters a test mode. In this mode, the test LED reflects the state of the IR input. When lit, the input is registering an IR reflection. This mode is useful for range and sensitivity testing. | In the bottom-right corner of the PCB, there are two jumpers. If the left-hand jumper is bridged on power-up, the unit enters a test mode. In this mode, the test LED reflects the state of the IR input. When lit, the input is registering an IR reflection. This mode is useful for range and sensitivity testing. |
Revision as of 01:14, 8 March 2014
Introduction
This page summarises the first version of the [Counting Poo] remote sensor unit.
The complete unit comprises:
- Electronics mounted on PCB and stripboard.
- Software to running on an onboard microcontroller.
- Casing, and other mounting/protection components.
System Components
PCB/Electronics
The remote sensor is designed around an ATTINY84V microcontroller.
The primary hardware blocks are:
- Two thermistors (in potential divider configuration)
- One IR sensor comprising:
- Transistor switched IR emitter
- Matched IR photodiode (reverse biased)
- LM358 op-amp operating as comparator
- Potentiometer providing comparator voltage reference
The schematic of the main PCB is
The PCB has two IR inputs, but only one is used. In addition, the capacitor filter and pullup resistors are not populated on the used IR input.
The IR components are mounted on stripboard, as the circuit on the PCB was not effective in practice. Further revisions of the hardware will bring these improvements in, along with power reduction improvements.
Using the remote sensor
When powered, the unit immediately begins polling for flushes (the test LED will briefly flash when doing so).
When the unit first detects a flush, it will increase its polling rate, and continue to test for flushes until 10 seconds have passed without detection. Only then will it consider a flush to have stopped.
The unit will then send a "WAKE" serial string, followed by a "aAAFEttooddd" string, where:
- a is the LLAP start char
- AA is the unit ID
- FE is a constant string for "flush event"
- tt is a two-digit ambient temperature in degrees celcius
- oo is a two-digit outflow temperature in degrees celcius
- ddd is a three-digit flush duration in seconds
- This duration only counts detection time, not the entire duration. For example, if the unit sensed for 11 seconds, followed by a 5 second gap, followed by another 20 seconds of detection, followed by the final 10 seconds of no detection, the total time reported would be 11 + 20 = 31 seconds.
Serial Comms and Programming
The unit has an 8-way connector on board for power, comms and programming. The connector pinout is shown in this image:
Test Mode
In the bottom-right corner of the PCB, there are two jumpers. If the left-hand jumper is bridged on power-up, the unit enters a test mode. In this mode, the test LED reflects the state of the IR input. When lit, the input is registering an IR reflection. This mode is useful for range and sensitivity testing.
Note this this mode does NOT send any serial messages, and leaves the IR emitter LED permanently switched on. As such, it is NOT to be used in a real environment. It will eat batteries and provide no useful data.
The right-hand jumper is currently not used.
Software
The software can be found in this GitHub repo. Note that this requires the libraries found in this GitHub repo.
It should be noted that the unit does not implement the full LLAP protocol, due to flash and RAM limits. This is a recommended improvement for subsequent designs.
The UART is currently a receive-only software implementation. It is recommended that future versions use a microcontroller with a hardware UART.
TODO: Summarise build options