Innovate Motorsports OT-2 SDK User Manual

Page 10

Advertising
background image

10

When our host connects to the OT-2 via Wi-Fi, it is virtually connecting to the physical
serial OUT on the device. That is, it starts seeing the same MTS data that is streaming to
the gauge. But it does not see the gauge, or any other devices chained from the OT-2’s
serial OUT on.

Because of the way the protocol works, everyone (including the host) only has access to
data generated ahead of them in the chain. Anything behind you is invisible to you.

So, from the point of view of our host (presumably an application running on the retro
looking ‘smart phone’ above), the gauge simply does not exist. We can put our finger
over it and see a straight line chain, with us at the left side of it.

At the other end of our chain from our host we have our chain’s “Head” unit. How does
that particular LC-1 know that it is the head unit? Simple, at power-up each device (but
not the host) sends an “H” to its serial IN port. If the device hears an echo, it knows that it
is the one at the end of a chain with the loop back plug.

There has been some confusion about loop back plugs (sometimes called “Arnold”, for
the sake of a pun too painful to repeat here). User’s seem confused about rather the plugs
are necessary or not. The bottom line is that a working MTS chain must always have a
loopback at the end. The reason that it seems like it is sometimes not necessary is that
most new MTS devices (like the OT-1b/2) self terminate when nothing is plugged into
them. Only the earlier MTS devices, like the LC-1, actually require a physical plug.

Once a unit has determined that it is ‘Head’, it begins to start sending data packets, each
containing what information it has (in this case, an AFR measurement) to the device’s
serial OUT connection. Data packets are always generated once every 81.92
milliseconds
.

This is important because it means that the MTS stream does not just represent data
values, but also represents a timeline. As to ‘why 81.92 milliseconds?’ the answer is that
automotive science suggests that a sample rate of at least 12 Hz is very good for the types
of measurements we normally do with our equipment. But dividing 1 with 12 gives 83
and 1/3 milliseconds (lots of 3333…) But if you take an 8 MHz clock and divide it by
65536 (a 16 bit counter), you get 81.92 milliseconds. Care to guess at the clock rate of the
original LM-1 or the size of the counter registers used to generate the MTS sample rate in
it?!

So, now we have a ‘timeline’ (or sample clock) where each packet represents a ‘tick’, a
measurement from the first LC-1, and a history lesson, but what happens next? To
understand you need to remember that devices ‘see’ data from all the devices that
proceed them (it arrives on their own serial IN port). So, our second LC-1, just after the
‘head’, ‘sees’ the MTS packets transmitted by the first one.

Advertising