Innovate Motorsports OT-2 SDK - Manual (Page 11)

11
Not only does it see them, the second LC-1 specifically has to pass them on, transmitting
them on its own serial OUT connector, for the data to ever reach our host. But, it does not
have to pass on exactly what it hears!
What the second LC-1 does is to alter the packet header before passing it on. It increases
the ‘length’ field, so that the packet the next unit in the chain (our OT-2) sees is larger –
by the size of the data that the second LC-1 itself has to provide (again, like the first LC-
1, just one AFR measurement). Then, after altering and relaying the header, the second
LC-1 relays the rest of the original packet it receives unchanged. Finally, it sends its own
data which, because of the altered header, is now properly part of the packet which the
next device in line (the OT-2) receives.
For most of the life of an MTS chain, this is what occurs. The head generates a data
packet, and each device in the chain expands the ‘size’ portion of the header, and then
tags its individual sample data at the end of the packet it is passing on, until the ever
growing packet reaches the host, where it is typically recorded or displayed.
In our illustration above, this is data flowing from right to left, over and over and over.
But there are two other basic cases; ‘Commands’ and ‘Queries’. Both are single
characters sent from devices downstream (the left side of our diagram) to devices
upstream (the right side of our diagram). That is, they start by flowing in the opposite
direction from the data packets described above.
Commands are easy. They are received on each device’s serial OUT port, acted on (if
applicable), and then passed on, unchanged, to the device’s serial IN port. Take the case
of ‘c’, the calibrate command.
Either our host, or our gauge, can transmit it. It is received by the OT-2 on either the
‘real’ or ‘virtual’ serial out port. The OT-2 has no need for calibration, so it does nothing,
but it passes the command on by transmitting it via its serial IN port.
Next, an LC-1 receives the command, and it does have a need to calibrate. So it starts free
air calibration, and then passes the command on to the next device upstream. That LC-1,
in turn, also starts free air calibration. But, because it is the ‘head’ unit, it does not bother
passing the command on to its serial IN port.
Queries are sort of a combination of these two cases. They are one byte, with the high bit
set, that are generated by the host. Unlike commands, they are not immediately acted on
by devices in the chain, but are passed on. The Head unit is the first unit to take action.
Instead of a data packet, it generates a response packet, with its own response to the
query. That packet then flows down the chain just like a data packet, with each device
altering the size of the header and adding its own response information to the end of the
packet, so that the packet is a collection of responses by the time it reaches the host.
So, to recap, we have three basic cases. First, typical sample data flow: