Axle counter

Hardware
Software
LocoNet

Hardware

Currently a prototype is under test that implements a single axle sensor based on two light barriers for detection of wheel flanges and the direction of travel.

The light barrier mechanical implementation is described on the pages of Michael Weinert

Software

Software update over LocoNet is available with the IPL protocol using a BootLoader.

The current test version supports software update, configuration over the SV protocol, 1kHz polling of the sensor inputs and display with status LEDs.

diagram The main design driver is the fact that the light barriers have a distance of 3,5mm, which is space enough for a wheel flange to be in between without being recognized by the sensor. The detection zones do not overlap. Therefore tricky logic is needed to be sure to count in the right direction. The following graphic shows the nominal sequence of events:

The logic for evaluation of the input signals for generation of counter information is currently under review. The following state maschine is a request for comments:

State Chart

States

The state names are choosen by the following rule: They begin with a human readable part and are followed by the state of the sensor inputs that lead to this state. H=blocked, L=free, left one is sensor 1, right one is sensor 2. Example: ENTER1_HL means: "flange enters sensor over barrier 1, state is barrier 1 = H = blocked, barrier 2 = L = free".

Transitions

The transitions are composed of a name for the edge type (rising = getting blocked = L ⇒ H, falling = becoming free = H ⇒ L), followed by the number of the sensor that it applies to.

Paths through the chart

The nominal path for a flange that enters over sensor 1 as shown in the diagram above is green-grey-green and leads to a counter decrement (shown by action Dec). The oposite direction goes over green-blue-green and leads to a counter increment. The red states are normally not reached, as the light barriers are too far apart to be both blocked at the same time. They are shown only for completeness sake.

Timing

In case of a direction change on a barrier or due to a detection error, the state maschine cound get confused and interpret wrongly, whether an axle is between the barriers or not. This error situation can only be caught by timing analysis. The idea is that the time the axle stays between the barriers is much shorter than the time between two axles passing the sensor. Therefore the time is measured for a flange staying on the sensor area between the two rising edges - see actions SampleStartTime when leaving IDLE_LL and SampleEndTime when entering CHECK?_LL.

When the flange is assumed to leave the sensor and the end time gets sampled, the state maschine does not directly go to IDLE_LL, but goes to an intermediate state in order to check for the assumption. If for a short while (equal to the previously measured) there is no further edge detected, everything is assumed to work normally. But if the barrier opposite to the just left barrier is entered, the above mentioned error situation is detected. The correction is a double counting in the opposite direction and a jump to the EXIT state of the oposite branch (blue transitions).

CVS server directory with AVR software

LocoNet message to report counter state

We need a LN message that can carry an address for the sensor and a counter value. The current plan is to abuse the message OPC_ANALOGIO for this purpose.

Message format

Byte Index 0 1 2 3 4 5 6 7
Mnemonic OPC=0xE5 len=8 ANALOG_CMD ANALOG_1 ANALOG_2 ANALOG_3 ANALOG_4 CHK

Usage of data fields

Mnemonic Usage
ANALOG_CMD <0,WR,aa-aaaa>
WR=0, because counter value is to be read by the world.
aa-aaaa is 01-aaaa, because not yet defined in spec 1.2c, see below

0x10 old data send after boot

0x11 old data send after reception of OPC_GPON

0x12 new data

ANALOG_1 low 7 bits of address
ANALOG_2 high 7 bits of address
ANALOG_3 low 7 bits of counter state
ANALOG_4 high 7 bits of counter state