We’re designing a laser altimeter for small drones and we want to make sure that the configuration is suitable for both the drone manufacturers and DIY’ers. The laser module will be offered in two formats, either a complete unit with Aluminum closure that can be added to an existing drone or in an open frame format for the OEM market. It will come with a serial port interface.
The question that I’d like to pose to this forum is whether or not we should include an I2C interface. I know that I2C is popular but I cannot find any technical justification for using this protocol between a flight controller and an external device. NXP (formally Philips) who define the I2C standard make it very clear that it is designed for use on a circuit board where things like the trace capacitance and terminating impedance can be accurately controlled.
Using the I2C protocol through a cable and connectors can result in unreliable behavior, something that gets worse if the terminating resistors are not accurately matched to the cable and if the cable itself has high capacitance. The speed of the communication is compromised by the cable length and may drop below the 100k bits per second that is the typical “slow” specification.
Of course, special drivers and error checking can be added but this is something that the average enthusiastic hobby drone maker is unlikely to consider when building their own drone.
Despite these misgivings, we are prepared to offer the I2C as an optional interface but we would not be able to guarantee its performance. This worries me greatly because I don’t want to make unreliable equipment. Also, when ordering the product in its closed format, only one protocol would be available so you couldn’t buy an I2C unit then change it over to serial later if it doesn’t work.
I’d love to hear your thoughts 
I like I2C.The great advantage over serial is that you can put several devices on one bus. Serial ports are in short supply usually.
Most ArduPilot ( and other ) flight controllers have an I2C connector, where you can add your device.
I find I2C very reliable if some conditions are respected.
Specify a maximum cable length, say 400 mm.
Specify a maximum clock, say 100kHz.
Use some pullup resistors on the device (say 10k). Provide this info
Best. Provide a ready-made I2C cable
Why can you not provide both protocols on the one device? They will both work on a minimum 4 pin connector so use the same physical connector for both and an on-board jumper or switch to select the protocol.
Thanks for the input skyscraper.
From what I’ve read, putting multiple termination resistors is not recommended for I2C. This doesn’t mean that it won’t work, it’s just not covered by the standard. We will be offering a serial port expander shortly so that multiple devices can operate from a single serial port so that should partly answer the issue of not enough available ports.
I guess the difference with what we are trying to achieve with our products compared with something that “will work adequately” is that we need to have provable reliability, and the place to start with this is by following the standard. If something is provided to a customer that doesn’t meet the standard then we may become liable in the event of a failure. You can Google “Takata” to see how this can adversely impact a company.
Unfortunately, we can’t provide I2C/serial as a selection in the closed units because we want to offer IP67 environmental protection and if the unit is opened to change a connector without proper precautions being taken then it loses this rating.
If you don’t add a pullup resistor with I2C then you will get many users complaining it isnt working 
Anyway I detect that you had already made up your mind. Maybe you should look at CAN instead
As it happens my FC
Has CAN connectivity so It would work for me
No decisions made yet, we still need to provide solutions to the DIY market because of the amount of innovation going on here, but it’s hard to judge how many people are sold on I2C and how many people have had bad experiences with it.
We wanted to use CAN originally but there are too few people using it right now, even at the drone manufacturer level.
PS - love your flight controller 
Not once had I hardware problems with I2C devices. The protocol is robust and even a termination resistor value fluctuation from 5k to 10k Ohms does not make a difference for short distances.
However, as @skyscraper emphasized, have a careful look at the NXP hardware specs regarding cable length and clock frequency and you should be golden.
Just make sure that there is no blocking code in your firmware (e.g. delays between master command and slave ACK).
One remark from my side. Lately I have faced the problem of wanting to include many identical I2C devices on the same bus, with the resulting address conflicts.
If you want developers to be able to include more than one of your lasers on the same airframe, allow for reprogrammable I2C addresses.
My 2c
Interesting Georacer. Of course double redundancy or aiming multiple units in different directions is going to become more common, even on small drones. To cater for this these use cases the new laser modules have encrypted laser pulses that allow for many units to operate in the same space, without interfering with each other.
An interesting thought from your post is that sub 2kg drones fall into a different licensing category, and these are really small, meaning that they have short cables. In fact, the open version of the new laser could be mounted directly onto a circuit board so this would not break the I2C rules.
One issue with I2C is that some devices are 3.3v and some are 5V. The Basic Arduino is 5V, but more modern microcontrollers use 3.3v. This may be a reason for some issues. If you use a 3.3v device on a 5V bus, it may work and it may not or it may work erratically. The solution is to go for one option and provide an I2C level conversion cable option. I provided a 3.3v and a 5v supply on my (3.3V logic level) i2c connector for this reason.
I agree with the other comments here. Though I2C is theoretically not a great protocol, the reality is that it is ubiquitous right now, and for the most part, works just fine. I can only remember one time when I had a problem, and that was a LONG time ago when our I2C code was blocking.
I have used I2C up to 1 meter, using a shielded cable.
I would prefer to push UAVCAN forward, but it’s difficult to get traction here. However, maybe you could be one of the first. The only problem for you is that it would limit your customer base to those running full-boat autopilots with the CAN connector (Pixhawk, Pixhawk 2, not sure who else, but the mini controllers don’t have it).
Of course, the same problem exists with UART. I2C solves that.
Personally, I would suggest it might be better to offer CAN as one option, and I2C as the second, and not offer UART at all.
Another idea is to provide an “active cable” doing protocol conversion in the cable itself, so you have (say) your serial port at your device and convert that to I2C/CAN/ SPI etc at the other end. I have thought of using LVDS in the cable, which gives you a very high potential data rate.
https://en.wikipedia.org/wiki/Low-voltage_differential_signaling.
This allows a huge amount of flexibility and high bandwidth for those that want it. Also works with IP67
I agree with Rob. You are emphasising reliability and that is what CAN is all about. Right now there is only a GPS and almost an esc available via CAN. I’d love to see a Lidar too.
You already have products that offer i2c so I’m not sure what these questions are all about in the first place.
If possible, offer all 3 options. However, i2c is ubiquitous so I recommend you offer it at 100kHz.
The Pixracer has CAN I believe
terabee V1 has UART and offers I2C flashing of firmware, is that an option ?
James, I’ll add to the voices suggesting a CAN interface be added, even if that means dropping the I2C interface.
I would also add for the CAN interface vs the I2C. The wiring to connect a device like that is not short and unless special care is taken, one might loose a lot of time trying to fix problems due to interference on the I2C cabling.
CAN is not without its own issues. Any cable run over EDIT: 300 mm must be terminated in 120 ohm between the signal lines at each end( and only at each end) and in that case all devices must be chained together. It is an added complexity for use to grasp and It isnt pretty
https://pixhawk.org/_media/modules/can_nodes/px4_quad_wiring.jpg.
Each 120 ohm terminating resistor potentially has 5v across it which means you are drawing 80 mA idle, which is quite power hungry.
I would say that I2C is a much wider DIY market.
Fantastic input from everybody, thank you all so much.
In summary:
-
Serial (UART) limits the number of devices that can be connected to one since it is not a network. It is very low power, can be 3.3V and 5V compatible and has good noise immunity.
-
I2C has poor noise immunity. It is low power, can be networked, is commonly available.
-
CAN is a high power consumption protocol that is not widely used. It is very noise immune and is available on some flight controllers.
I’ve been changing my mind about this every ten minutes and don’t have a definitive reason to select one or another protocol. In terms of cost there isn’t enough to sway things but I am concerned about the power consumption of CAN because the mini laser modules have a low power, standby mode that would be far less effective on a CAN network.
My personal preference for a noise immune network is RS422/485 and this is really just an extension of the serial UART that could be added as a “cable converter” so I would like to keep the serial available.
As an additional protocol, my thinking today is that the I2C bus is so popular that if we don’t provide it then many DIY’ers will not be able to use the product and we want to support the DIY community as far as possible. Let’s see what happens tomorrow 
Clearly related. Airspeed Sensor Doesn't Provide Airspeed Data to Mission Planner I believe the problem there is the use of a 3.3v I2C bus with a 5v device on PixHawk. The solution here is to plan around being able to talk to 3.3v or 5v devices, so in my case, supply 5V and 3.3v power out which users can use to convert to from 5v <-> 3.3V and describe use of I2C level converters such as PCA9509, PCA9517, PCA9306 ( or provide a cable with these inside). Incidentally these converters can also be used to isolate external I2C busses. The advantage of that is that for on board bus you can use a fast clock and then you can switch to slower clock (which faster devices understand, but not vice versa) when accessing external devices on long cables. Not implemented on my current FC under development, but definitely would use next time.
I would also add that the same issue with 3.3V v 5v applies to UART where using 3.3v logic levels on a 5v UART is out of spec and can lead to erratic pereforamnce especially on longer cables.
You can offer a CAN interface (with custom or CANaerospace protocol) and Serial UART. This will cover professional needs.