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.
1 Like
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.
@Jarno - surprisingly, we get more requests for RS232 than for CAN from professional and military grade users. This maybe due to specific certification requirements such as blanket approvals for RS232 as an aircraft grade protocol.
Hi
Just wanted to point you to the following project:
Sounds similiar, or do I get this wrong ?
@flo-vienna - I can’t comment on products from other companies since I don’t know for sure if they work or even exist. On the Internet there are lots of people offering products with the hope of one day making it big, but it’s a long road from having an idea to producing a world class product that is reliable and effective. For us, our new laser is another short step along this road.
1 Like
Have to say that none of these protocols is that great. On the surface I like USB. There are various backward compatible flavours with ascending bandwidth It uses a star topology, which is just more practical than the CAN “ring” for aircraft, which tend to be star shaped (unlike cars where a ring works and which CAN was designed for), provides a power spec and with more and more sbc or soc computers like RaspberryPi etc which have USB interface, seems like the way to go. Certainly there are many microcontrollers ( e.g STM32) which have a USB peripheral and drivers. That said, it is quite easy to interface a UART to USB so maybe that is the simplest option. A UART to [insert other protocol] converter might also be an interesting project.
@skyscraper - I must agree with you about USB. We do all our testing using USB, either through a native port or using a serial to USB converter cable. To make things easier we also prefer ASCII messages over binary so that any standard terminal application can be used to check performance and configure a device.
Our strategic focus is on supporting the “single board computer” developers by allowing for totally asynchronous operations and providing drivers that have additional features rather than building these features into the unit itself. We will soon have a serial port expander module available so that multiple serial devices can be run from a single serial or USB port. Also, we’re testing a scanning system that can run from a USB port with internal data buffering and time/position stamping so that the data can be analyzed by non-realtime applications.
I don’t have knowledge to give an opinion were or how to connect but, as a diyer I have preference for products “plug and enjoy” like the sf11, try to provide everything that do it, cables, resistors, connectors, etc., I have a bad experience with Lidar lite about that, probably a good product, but first I have to find a resistor so I have to learn about resistors and find one but still not work, perhaps need a bec, I have to wait a month to recive a bec If I don’t have one, etc. …the Lidar is still on my desk not flying and I’m not recommending anyone arround me perhaps for a silly resistor or a silly bec, who knows.
Thank you for reminding me Cala that we should always be humble in our approach to technology. Making something simple is much harder than making something complicated 
1 Like
Thank you to everyone for your valuable input. The preliminary specifications for the LW20 and SF20 Miniature Laser Rangefinders are now as follows:
Introduction:
The LW20 and SF20 miniature laser rangefinders offer high performance in a very small form factor. The LW20 is a sealed unit designed to withstand water splashes and dust whilst the SF20 is a light weight, open frame unit ideal for OEM integration. Both units can measure beyond 100m in sunlit conditions and can measure down to almost zero distance. These professional grade sensors can take up to 678 readings per second and provide distances to both the first and last signals with each measurement.
Features:
- Very small size and low weight
- Choose either a water and dust resistant unit (LW20) or a lightweight open frame module (SF20)
- Weight of < 10 g for the SF20
- Water and dust resistant to IP67 for the LW20
- Long measuring range beyond 100 m
- High speed readings up to 678 per second
- First and last signals measured with each reading
- Serial or I2C interfaces compatible with 3.3V and 5V systems
- Low power consumption with standby mode
Applications:
- Distance measurement
- Laser altimeters for small or large drones
- Scanning laser systems for mapping or obstacle sensing
Specifications:
Model number… LW20 … SF20
Product feature …Water resistant … OEM open frame
Maximum range [m / ft] … 110 / 360 …110 / 360
Minimum range [m] … ~ 0 … ~ 0
Update rate [readings per second] … 84 to 678 … 84 to 678
Resolution [cm] … 1 … 1
Accuracy [cm] … ±5 … ±5
Weight [g / oz] … 20 / 0.7 … 10 / 0.35
Dimensions [mm] … 20 x 30 x 35 … 20 x 30 x 32
Housing material … Aluminium … open frame
IP rating … IP67 … –
Operating temperature [C] … -20 … +60 … -20 … +60
Power supply [V] … 5 ± 0.5 … 5 ± 0.5
Operating current / standby current [mA] … 170 / 45 … 170 / 45
Notes:
- The maximum range is measured against a stationary, large white target in full sunlight at 84 readings per second
- The maximum operating temperature depends on suitable airflow or heat sink
1 Like
That is certainly compact and lightweight and I would have no problem fitting it on my planes. What is the rationale for the minimum 84 samples per second. I would also hope there is a binary mode as well as a text mode?. The disadvantage of I2C bus is that there can be a lot of devices on it so bandwidth can get limited. Ideally therefore it would be good to be ablt set the update rate , and /or have a “one shot” mode to take one reading on command. That allows for a so-called “stable decay” in data rate as the bus gets busy.
84 readings per second is the highest speed at which the maximum measuring range is achievable (preliminary specs only). Of course, it can be run slower than this using the “on-demand mode” where the host can ask for one reading at a time or request data streaming at a slower rate. Maybe the terminology is misleading, I’ll change it.
At higher speeds some of the signal processing functions may be turned off, limiting the range but improving the response time. The higher speeds are designed for scanning and mapping rather than altitude measurement. I like the idea of selecting either ASCII or binary data strings to reduce bus loading on the I2C - it’s on the TODO list.
Maybe I am a little bit late but my two cents go for an additional PWM signal.
Along with a “real” interface like i2c, CAN or RS485 (best imho), a PWM would add a simple and backwards compatible interface that is already supported in older versions. It will provide a nice simple interface that can be enough for most uses.
Regards