IF2C: Rapid Scan?

In Brief: The solid state solution is good for rapid scan. As shipped and by design (use-case: low power, long intervals between readings), the communications overhead would make the channel-change scan rate very slow. With a few tiny and easy firmware revisions on the host you could probably speed that up for immediate experimentation.

Rapid Scan Applications

“Rapid scan” here means continuous, multi-channel round-robbin pulse and receive at rates and measurement densities sufficient for surface mapping or statistical extreme estimations from (ideally) relatively non-sparse data sets.

With the IF2C/GXN prototype stack, for example, you might keep the GXN close to your data station, run your pulse and receive coax a good distance, and then locally at the transducers use the IF2C as a 4- or 8-channel multiplexer. At the moment, the length of the data line to control the IF2C would probably be the limiting factor. Or you could embed the whole stack at your transducer scanner end and run your communications the distance. Lots more options.

Why the IF2C

The IF2C prototype accessory demos usable waveforms via solid state solutions and thus lends itself to these kinds of continuous acquisition scenarios.

As Shipped

The short and conservative answer to the question “Can we use it now for our Rapid Scan application?” is… “Please be patient, a related solution is on its way …!”

The use-case for the first IF2C demo was that of a data acquisition (DAQ) schedule with very long intervals between readings, in a battery-powered sit-in-the-field kind of system.

Though there is overlap, the rapid-scan use-case is different. The rapid-scan scenario preferences performance over power savings. (Isn’t that an old paradigm? Can’t we have both? Uh… yep…later…)

As shipped, that is why the IF2C logic and control elements are configured to run slowly and sleep when possible. And, as a demo, the default communications delays and the API preference reliability and options over, respectively.

Tweaks for Testing Now

The “let’s just test a little bit now anyway…” answer to the same question about IF2C rapid-scan is actually useful. With a few tweaks perhaps.

The biggest result for the least effort is probably modifying the POST_SELECT_DELAY_NS and POST_COMM_DELAY_US values in the demo Host firmware file “hdl0108if2c-dl0102.h”. Together, those two items comprise more than 99% of the delay in the demo firmware comms cycles for changing channels.

Say you want to get close to 16 readings per second for 4 transducers. That is 15.6ms time slot per sample, assuming an even distribution of DAQ cycles over time.

The current low-power demo, safe, and left-over from rapid dev of Host firmware examples, in theory (not tested), are at least nearly 1 second for a channel change. Just based on looking through the code and looking for intentional delays, allowing for wake from sleep, etc.

However, even if you just change the values above such that the comms still worked, but those two delays came down to 1ms instead (which could be a silly leap to try, or maybe not – incremental is probably best), you could probably get things closer to 12ms per channel change. Which easily fits into the 15.6ms window for the 16 * 4 readings per second. This is just based on looking at the code and estimating. Even if you lose functionality below 20ms for the sum of those delays, you’re still at a huge upgrade in timing.

In any case, that’s a huge difference, all without even touching the IF2C logic implementation or firmware.

The biggest delays here across the board are the communications delays and baud rates either way. And all of that can be changed in firmware too, if not just in the settings.

For example, (1) you can increase the serial-connection baud rate, (2) we could speed up the IF2C hardware execution, and (3) slim down the API for some single-command implementations.

It might be that in trying to reduce the POST_COMM_DELAY_US you can’t get a small enough value because that functionality breaks before you do. From there it’s just an IF2C logic, API, and thus firmware update. Not a big deal. Just a different use-case.

Lots of options. Lots of use-case dependency. Lots more to say, but best left as assumed tl;dr.

How to Measure Latency

One idea: Maybe connect the Tx and Rx lines to the board from a USB-Serial cable via a breakout and probe them, watching for the timing from first packet start to last packet end for a single cycle of channel change from Ch 1 to Ch 2. Or use a logic analyzer. Or use a serial terminal with timing. And watch for the return “OK” messages at the beginning and end of commands to switch channels.