I see the Zymbit 4i module is using I2C as the communications interface between the module and the RPi (in my case the RPi-3). I am curious if you are looking to implement the SPI interface in place of the I2C interface for faster throughput between the two devices.
@gnmckinney - SPI and UART are in the next generation of Zymkey (ZK6). Curious to ask what transaction speed you think you will need between Pi and Zymkey ?
I am working on a project that will require multiple customers to access their Containers in K8s clusters. I am planning to use the RPi and Zymkey as the hardware lock for this (not going into details here 
)
Speed will be one of the requirements to perform the encryption/decryption operations so I was wondering what the max speed is that I can obtain using the Zymkey module.
Curious as to what speed the current Zymkey module communications is on the I2C buss between the module and the RPi?
We have reliably tested Zymkey up to 400Kbps on i2c. The default for Raspberry Pi is 100Kbps, but you can change this in config.txt as you see fit caveated with the fact that i2c is a “lowest common denominator” bus. In other words, your bus speed must be set to the speed of the slowest device. So, if you have any other devices on the i2c bus that are 100Kbps, you will have to set the bus speed to that speed. If you don’t plan on having any devices on the bus, you can set it to 400Kbps.
Having said that, what are your performance requirements and what operations will you need Zymkey to perform?
Hi. Sorry for the delay as I have been discussing actual throughput needed with others in group.
I am working on a project that will have multiple IoT device access with unique certs from the individual devices connecting to a central database. All of the devices communicate every 6 minutes or so through a mesh network and can be updated remotely if the certs match (as well as any data downloaded over the air). If some event occurs with a device (tampering would be one such event) it will communicate with the central server outside of it’s normal communications ‘slot’ so being able to authenticate the device will need to happen quickly to handle or at least record the event in very near real-time. All of the certs will live in a database encrypted and the Zymkey will be used to lock/unlock the specific cert for the IoT device for data collection, event detection and remote updates.
Starting out it will not require real fast communications between the Zymkey and the application for lock/unlock activities but as more IoT devices come online the speed requirements will increase due to the number of devices needing service in the 6 minute time slot and also cover events of interest that might occur.
I hope this makes sense without going into further details
For data unlocking something that is the size of a certificate, I could imagine up to 500ms. Having said that, we have not done a specific benchmark for this.
The 500ms is for just the unlocking? Is it the same for Locking as well? I will need to do some experimenting to see what the total throughput is at the 100Kb/s and 400kb/s for the I2C interface as well (grin).
Also in the process of getting a Zymbit module setup to run on an OrangePi 3 using a Debian Stretch with Armbian Linux 5.3.0-rc3-sunxi64 build - so far the Zymbit zk_install.sh ran without any trouble - now just have to redefine where GPIO4 (pin-7 on a RPi connector) is located in the H6 processor GPIO mapping. I see from your instructions for changing the GPIO-4 pin to a different pin on the RPi that it is defined as an input pin. Is this correct??
I see from your instructions for changing the GPIO-4 pin to a different pin on the RPi that it is defined as an input pin. Is this correct??
Yes, that’s true. The Zymkey software will attempt to define the pin that is called out in the configuration file as an input, so you just need to make sure that the required pin is not already configured as something else vis-a-vis DTB, etc.
To answer your first question, the 500ms would apply to the locking as well as the unlocking. In reality, 500ms would be a worst case guesstimate.