Is that possible? Doc says that I2C is locked to 1Mbps and cant be changed, but that is really limiting. I need to talk to some SMBus sensors and SMbus is like i2c that is locked to 10-100 kHz speeds.
It would be nice if you could change the speed of the bus like on the RPI.
Can you make it selectable? this is very limiting, Most I2C sensors are limited to to 100khz, and there is no way to make them work with Odyssey. Basicaly you are limiting the i2c fucionality to i2c displays that use higher refresh.
I put a logic analyzer on the Odyssey I2C bus and it seems to be running at 400 kHz. Am I reading this incorrectly? While, I agree, having an option to set the speed of the I2C busses would be useful, it seems that the documentation that says the I2C speed is fixed at ‘Fast−Plus (1 MHz)’, this does not appear to be the case. Rather the busses are set at ‘Fast (400 kHz)’.
Thank you for clarifying this.
Hmm that is quite a revelation…unfortunately still not 100kHz that is required for the smbus devices.
I wish seeed put more effort into documentation/software/support to this otherwise fantastic piece of hardware…
BTW the workaround I found is to use adafruit USB to I2C bridge. https://www.adafruit.com/product/4471
This one does the job. And I also tried https://www.adafruit.com/product/2264 but it DOES NOT work as it should @ 100kHz and the python library is a mess.
Interesting products, glad you found a solution that is working for you. I am still trying to figure out which I2C devices I am exploring work with the Odyssey I2C. The 100 vs 400 kHz clock is one reason, however I still perplexed by some others, including finding if termination on the bus is necessary/helps, what is the right voltage 3.3v vs. 5.0v (yes I know it is a 3.3 volt system, however my success with running at 3.3 volts less reliable than running at 5.0 volts, no blue smoke yet from the blue box) and I think there are other timing issues on I2C devices that seem to with some devices.
Interested in what smbus devices you are trying to implement, this protocol seems to add even more complexity to the ‘soup’. In another thread on this forum, I have found that the smbus driver in Ubuntu 20 seems to mess with the I2C drivers. So, I think, I have removed my systems ability to run a pure smbus network, by removing the driver that seems to provide for a separate smbus network. This stuff is way above my pay grade 
…
Good hunting!
@Maciej_Eckstein as a follow up to my earlier point about I2C timing issues. I did a little exploring of using a ATTiny85 as a I2C slave to drive a string of NeoPixels. I found that the simple Arduino routine I wrote to do this on the ATTiny85, when using the first cited I2C library below ran fine with the ATTiny85 attached to a Raspberry PI I2C bus. However, if I attached the ATTiny85 to the Odyssey I2C bus, the I2C bus basically quit operating. By recompiling the same code using the 2nd I2C library cited below, the ATTiny85 code driving the NeoPixels from a Python 3 script in Linux works fine on both the Raspberry PI and the Odyssey.
This does nothing to fix I2C devices that exhibit the same bad behavior when attached to the Odyssey I2C busses. However it demonstrates the fragility of the I2C architecture, regardless of the operating speed of the I2C bus, incompatibles between master and slave devices can make the I2C bus fail for all devices on it.
Arduino TinyWire Slave Library
USIWire