@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
@Jesus - There is no PWM in our older products - you might be confusing us with another company 
- but we can provision for a special firmware version that would be compatible so I’ll add it to the request list.
Dont get me wrong. I know you are not “other company” 
I meant older versions of arducopter for example.
Pwm is simple
Hi LD,
I honestly think that for the time being supporting both I2C and serial is the best approach.
I also think you should include 10K+ termination resistors on board or at least provide a spot for them for the I2C.
For DIY use most lasers will be incorporated with short cables and I2C would work very well with many of them.
Because of the issues you have mentioned you cannot guarantee that I2C is going to work for every application and I really think you are covered by simply stating what you view the limitations to be and then letting the customer figure out if it’s actually going to work for them based on that and possibly testing.
Serial is a no brainer, there are a lot of traditional (military and civil) applications which can and do make use of it and is reliable and easy to use and even for DIY’rs it can be easier and quicker to integrate.
I currently do not think CAN is a good candidate, in spite of much work, a solid usable DIY or affordable commercial codec still does not really exist (I know some will disagree with that), but there are multiples and they are not cross compatible at best.
The worst part as you said is that it is a high power interface. It operates well in a noisy environment but the price you pay is power consumption (and or speed).
You can’t do everything for everybody, but for the time being, offering both a I2C and a serial interface, should I think give you the widest initial customer base.
Probably just fine to offer both serial only and I2C only enclosed versions, mostly people who are going to want one of those are already going to know which one they want.
An interesting alternative might be USB to add further confusion to the mix.
DIYers in particular can often work well with USB, that said, serial and I2C are still probably the most important 2 basic options.
Personally I am very interested in the open one (2 actually) for an interesting biscan concept I have.
Best Regards,
Gary
@Gary - I think we’ve both come to the same conclusion. There is room internally to add other protocols like CAN or RS485 but the standard offerings will be serial and I2C, both buffered to improve noise immunity and to allow for 3.3V or 5V operation.
Biscan? Do tell more ;). I’m blown away how many people have approached us with totally new applications for the LW20 simply because it is so small.
Hi all. This turned out to be an interesting thread. I noticed that we used the term termination resistors on I2C, but the correct term is probably pullup? Anyway I edited my posts for clarity.
@skyscraper - pullup is the correct term and I think that a default of 10k is a good compromise even though it is not strictly allowed in the standard.
To make things more complicated the resistors should pull up to the positive supply rail which could be 3.3V or 5V. So I’ve used the PCA9509 to act as logic level converter/buffer and provided for a voltage selection that affects both the external side of the PCA and the pull up resistors.
Hi, Skyscraper,
You are right I used “termination” because it was used elsewhere.
In fact I2C specifically uses a pullup for the function of termination as well as to compensate for the open drains so either term is in fact correct.
The “termination” is required to be a pullup because it is open drain.
Multiple pullups are not a problem unless you have so many of such a high value that the I2C chip can’t pull the line low.
10K is generally a good choice even if every line is “terminated” the current won’t get too high even with six or seven branches.
I have made several boards and multiboard devices which used I2C both internally and externally with both single and multiple pullups.
reducing the resistance allows you to go faster and operate in a noisier environment at a cost in power consumption and heat.
I generally terminate (pullup) each external device and use 10K.
http://www.i2c-bus.org/termination/
Best regards,
Gary
As discussed above one of the problems with i2c is its poor performance over longer cables. Recently there is a solution to this differential I2C, which promises to extend I2C performance to a 1 MHz clock rate over a 3 meter cable, while remaining compatible with existing devices. The link nominally describes an IC but in fact describes the hardware quite well too:
http://www.nxp.com/products/interfaces/ic-bus-portfolio/ic-fast-mode-plus/2-channel-multipoint-fast-mode-plus-differential-i2c-bus-buffer-with-hot-swap-logic:PCA9615DP#overviewExpand
You need a 6 way cable but it looks like a neat option