Lower speed sonar connection through I2C

Hello,

I’d like to create a custom obstacle avoidance application, which requires 6 (or more) sonars I plan to connect via I2C. I’ve chosen MaxBotix I2CXL-MaxSonar sensors, which seem to work flawlessly with vanilla Raspberry Pi and image, but given that I2C 1 is already utilized by Navio2 hardware, there’s an issue arises: MaxSonar is able to operate at maximum of 400 kHz I2C bus speed (with clock stretching, which Raspberry seem to provide with some issues, still it works for me), but the default I2C speed set up in Navio image is 1 MHz.

So my questions on that are:

  1. I’ve read some relevant threads here, and it’s mentioned somewhere, that it’s possible to decrease the speed to 400 kHz, which is theoretically enough, and 1 MHz is set to have some reserve. To my quick experiments, 400 kHz setup works for me, but is it really safe to set 400 kHz speed and not to have any reserve for everyday work?

  2. Is there any possibility to use e.g. I2C 0 bus to have these low-speed sensors in separate bus? Or any other variants for this.

  3. Maybe there’s alternative well-known and proved-to-work solution to have many sensors (6+) connected to the board, other than I2C? I thought, it’s the easiest solution, but maybe I’m mistaken here.

  4. What is the voltage on I2C power pin of Navio2? According to the datasheet, MaxSonar works with 3.3V and 5V, still I prefer 5V in terms of beam pattern.

An simpler solution (not the cheapest one though) is to use the four camera TeraRanger Tower

Yes, also seen this) Thank you for suggestion! Not the cheapest thing, yes, but it’s also interesting for me, if it’s possible to build such an application with sonars, rather than cameras or LIDARs.

  1. Depends on the number of sensors, their polling rate and amount of data they pass. We do not recommend lowering the speed and overloading the bus. But this should be tested for each particular setup.

  2. Theoretically this is possible, but it would require a lot of hacking and programming. It will also disable RPi camera port.

  3. It may be better to look for alternative solutions, like the one suggested by @Al_B.

  4. It’s 5V.

Thank you for detailed answers!

  1. According to the sensor specs, maximum polling rate is 40 Hz. Agree that it’s a compromise approach, but I’m afraid it’s the only working for now.

  2. Could you please suggest, where to start with this? I’ve seen mentions of I2C0 of Raspberry’s GPIO header and another port on its P5 header, but can’t find the information of whether they are used/masked/disabled by Navio2.

  3. Yes, I’m looking at such alternatives, too, but the sonar setup is of higher priority for me, so wanted to get most of it.

  4. Nice, thanks for clarification.

@mikhail.avkhimenia What is the reason for the 1MHz I2C speed? From the Navio2 pinout diagram, it looks like the MS5611 is the only sensor on the bus and it only has an update rate of 50Hz. Seems unnecessary to have such a high I2C speed. Maybe I’m missing something.

@4ernov

  1. I2C0 is on 40-pin header now. It’s used for HAT EEPROM and for camera control. You can enable it using config.txt, parameters can be found on Raspberry Pi forum. Then you would need to modify Ardupilot in order to use both buses. I strongly suggest not to take this approach, only if it the only choice. Otherwise you would spend a lot of time fighting the code and end up with unsupported configuration.

@larssoltmann yes, you are right, it is not necessary for single MS5611 to work on 1MHz, but the faster we get the data the better.

@mikhail.avkhimenia thanks for the reference, and yes, I see it’s quite experimental approach, so I’ll stick with 400 kHz bus for now. As an option for the case of some instability I found a couple of USB to I2C master converters (Devantech USB to I2C Interface Adapter | Acroname and http://www.harbaum.org/till/i2c_tiny_usb/index.shtml) which could also help. The former seems to be semi-software solution and unknown if it’s compatible with Linux kernel I2C subsystem, which is not so good, but the latter seems to be pretty much what’s needed to have auxilliary I2C bus to not bother the main one.