Why am I Missing ACK Signals with the Aardvark I2C/SPI Host Adapter Using the Python API?

Question from the customer:

I am using the Aardvark I2C/SPI Host Adapter to imitate a temperature sensor on an I2C bus and am experiencing problems with request replies. I am using the Python API to reply to I2C requests. Everything seems to work fine until I decrease the delay between the requests to 1 ms.

The ACK signal is not being sent once the request is received and I get “error: non-I2C asynchronous message is pending” immediately. Sometimes, I do get the correct responses. My questions:

  • What is the cause for not receiving an ACK signal?
  • Is there a lower boundary for delay between communication?

Response from Technical Support:

The cause for receiving an ACK signal some of the time is due to a limitation on the throughput of the Aardvark I2C/SPI Host Adapter.

Aardvark I2C/SPI Host Adapter as an I2C Master

The Aardvark adapter can act as an I2C master at 1 kHz - 800 kHz.  It is not possible to send bytes at a throughput of exactly 1/8 times the bitrate.  The I2C protocol requires that 9 bits are sent for every 8 bits of data.

There is also a finite time required to set up a byte transmission. The Aardvark I2C/SPI Host Adapter has been optimized to decrease the setup time. This allows byte throughput within each transaction to be very close to the theoretical maximum byte throughput of 1/9 of the bitrate.

The Aardvark I2C/SPI Host Adapter User Manual section 2.3 details the I2C signaling characteristics.

Aardvark API Latency

There is extra overhead introduced by the operating system between calls to the Aardvark Software API. The aa_i2c_write (or aa_i2c_read) call must complete before the next API call. Each time this function is called, a 2 ms round-trip latency is incurred caused by the full-speed USB link between the computer and the Aardvark adapter.

In addition, the target device may require some delay time in order to commit the write to a specific address, and before performing the next read for that address. Take a look at the target device datasheet in order to find the value of this required delay. The operating system may also add additional delays due to internal overhead.

For the Aardvark API functions, everything is a block function that waits for the response from the device, meaning any function has a USB latency around 1-2 ms. This is a bit slower than other devices since the Aardvark adapter is using USB full-speed (12 Mbps).

More Options with the Promira Serial Platform

The Promira Serial Platform is an advanced serial device with configurable I2C and SPI applications. With the I2C Active – Level 1 and Level 2 Applications, the Promira Serial Platform supports active communication on the I2C bus as an I2C master/slave up to 3.4 MHz, level shifting 0.9 V – 3.3 V, and USB High-Speed/Ethernet connectivity.

Please note: The maximum bitrates are only achievable within each individual transaction and do not extend across transactions. There can be delays across the Ethernet/USB bus within a transaction. The GUI and the OS may add delay due to internal overhead.

When using the Promira Serial Platform, the USB roundtrip latency is reduced to 250us when using the High-speed USB over Ethernet connectivity. The roundtrip latency is reduced further when using Ethernet connectivity. The Promira Serial Platform also offers an API queuing mechanism that may provide additional speed-up. For additional information take a look at the Promira Serial Platform User Manual and AC Characteristics.

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you need more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo