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

35
Benefits of In Band Mode
The reasons for Innovate using MTS In Band Mode are pretty clear, it makes OBD-II
compatible with our existing product line and all of our software. But your objectives are
probably quite different, so you may wonder if you should bother with MTS data packets
and normalized PIDs at all.
This is a reasonable question. There is some complexity, and some real limitations, like
fitting everything into 10 bit samples. But there are some benefits as well.
First, there is basically the same reason that motivates us, it lets you concurrently sample
OBD-II data and our other instruments. Our lambda instruments are, demonstrably, the
fastest and most accurate that you can buy, and MTS in band support lets you sample
their output digitally.
Second, if your OBD-II needs are relatively simple, just using normalized PIDs and
reading the resulting MTS Data Packets may be a lot simpler than learning the underlying
protocols so that you can use them directly.
The third and final advantage is a bit more subtle. Using an MTS data stream offloads the
responsibility of tracking time. For some applications, consistent and steady sampling is a
must, but circumstances can conspire against achieving that on the host. For example,
some platforms and environments will intermittently freeze, as processing power is
yielded to other activities.
A less obvious culprit is connectivity. In computer terms, the MTS data stream is very
slow. By comparison, Wi-Fi is very fast. One would assume that there is no problem of
time. But, in networking, you have to make a choice between immediacy and reliability.
The OT-2 uses “TCP” as the protocol for connectivity (see the section on connectivity
and transports later in this document). The advantage to TCP is that delivery is
guaranteed. That is, data is not lost. The downside is that when network errors occur, and
they do occasionally occur (1% is common on a typical wirless network), then there is
often a pause of 200 mS or more before the host’s network stack attempts to retry.
If you are using MTS data packets, this is a non-issue, the lost packets are resent. But if
you are polling the ECU yourself, then this timeout/retry gap becomes a gap where you
have no sampled data.
The point of this is not to pressure you into using MTS data streams. But merely to point
out that there are tradeoffs depending on how you use the instrument. Some applications
absolutely need a much more direct, ECU aware, approach than the default behavior of
the OT-1b/2. For those applications, there are…