When comparing a couple of I2C (digital) sonars with the normal (analog) sonars I noticed the range reported by the analog sonar appeared to be wrong. A tape measure proved the digital sonars were spot on and the analog data was well off. Other users have reported similar problems (here and here).

Some work with a spread sheet, schematics and the sonar data sheets helps point to the causes of this.

First the sonar module analog output is in proportion to the Vcc input to the sonar - this is a particular problem when running on USB where your Vcc can be down around 4.8 volts - you can not assume an accurate 5 volts to the sensor. This means you can not just measure the analog voltage output and hope to calculate an accurate range.

Second different Maxbotics sonar models output different voltages per centimetre. Even within the XL model range there is a 200% difference in output voltage for the same range. eg (from data sheets):

LV - EZ0 MB1000:(Vcc/512) per inch
XL- EZ0 MB1200: (Vcc/1024) per cm.
XL- EZL0 MB1260: (Vcc/1024) per 2 cm.

Third the analog port on the APM / IMU shield uses the ADS7844 external Analog to digital converter. This device does a 12 bit conversion relative to a reference voltage. The 'Foxtrot' version schematic shows this reference is 3.3 Volts. The ADS7844 data sheets says in this configuration it will digitize a signal in the range 0V to 3.3V. This appears to mean we cannot reliably use the sonars to their maximum range as they will output greater than 3.3 volts at some point (any range over 5 meters for the MB1200 and over 7 metres for the 1260). I wonder if this is why some users report strange 'zoom climb' behaviour when in altitude hold - particularly in the 4 to 8 metres altitude range.


The Rangefinder library makes no allowance for either of the three points above. It assumes the numbers coming out of the ADC are directly proportional to centimetres, and this is not the case at all. If you have a MB 1200 it will read twice the range of a MB1260 if you have a MB1000 then you have to convert from inches to metric and allow for half the resolution. If your power supply voltage (Vcc) is not known then you can not accurately calculate your range. If your sonar signal goes over 3.3 volts you may not get the correct result from the ADC.


Below is a screen grab of my google spreadsheet that shows the difference in reported range and actual range and the ability to calculate an fairly good adjusted range by taking the points above into account. I haven't tried this at longer ranges yet so cannot test the 3.3 Volt limit theory.

Before we charge off and re-write the Rangefinder library I'd like to hear what people think of the theories outlined above.

(for those that are curious the digital (I2C) sonars use timing of pulses to indicate distance so no voltages are involved and so they avoid all of these issues)



Views: 2697

Reply to This

Replies to This Discussion

Uh. My ignorance almost make me blush.

I thought we were using the PW signal. Thats called whishful thinking, right?

Your findings are really very interesting @agmatthews, I hope this will be followed up.


I suppose there are good reasons for reading the analogue signal (hardware resources on ACM and Oilpan), but it certainly makes the data collection more vounerable. Depending on Vcc and sensitive to electromagnetic buss, which is inevitable among multiple ESC, XBee transmitter, and even worse for many of us, a high power video downlink.

Think I might dig into my boxes for some ferrite toroid...


Would it be possible and reasonable to develop I2C-option for the ArduCopter sonar?

Yes, this analysis all started as part of my testing two different i2c sonar options. A DIY version that does all the noise filtering etc on an arduino mini, and an off the shelf (SRF02) version. The tests continue - so far the i2c sonars are more accurate and more immune to noise. The srf02 seems to be less sensitive than the maxbotics mb1200

That sounds promising, Andrew!

Whats the pros and cons of the DIY vs the SRF02?

I could see in the spec for the latter that it has 6 meter range. One would hope for a little more, but rather 6 meter rock solid than 7,5 or 10 with guttaperka tendencies.

I hope you´re moving forward on this. Many will benefit from such an improvement!


ps. How about using same sensor as today, but reading PW signal instead of the analogue one? Difficulties?


The DIY i2C sonar does use the same sensor as today (the Maxbotix MB1200 or MB1260) with PW signal. Have a look at this blog post for more detail.

It took me a while to translate 'guttaperka' - but yeah - on the bench the srf02 appears to be more 'rubbery' than the maxbotics MB1200.

I hope to do some testing on a day off tomorrow as we have a public holiday for a horse race!


I don't know if there is any suggestion about forum post but people (and I) could save huge amount of time if the post linked the datasheet and/or info page about the parts being involved:

Sonar wiki

Sonar MB1200

Oilpan IMU(see schematic)



I agree with your conclusions:

- ADC readings will be clipped above 3.3V (@675.84cm with MB1200), but since this is more or less the max range of the sonar it's not a problem.

- The sonar is ratiometric (aka its output depends on its input voltage), so the most reasonable thing to do its to use the 3V3 supply (the same as the ADC's Vref uses) instead of the 5V, to null out any voltage drifting. (As done with accels and gyro chips)

MB1200 behaves almost the same using 3.3V instead of 5V, although slight less max range (6m vs 7M) and narrower beamwidth but, as the target is floor, I don't thing this is a major issue.



Yeah - I agree I could have linked to the datasheets etc - it was 1 o'clock in the morning when I was posting so please forgive me. :-)

You are right in that the clipped readings should be out near the maximum range of the MB1200 and the altitude calculation code (in arducopter.pde) also helps here it basically blends out the sonar data at 6 metres and uses the barometer from then on - no matter what the maximum range of the sonar is. (don't bother buying a 10 metre range MB1260 just yet!) Also because of the need to scale readings by approx 3.3/5.0 we are really only getting about 4 metres of sonar before barometer takes over. So in theory the ADC clipping is not much of a problem. In reality the behaviour of the ADS7844 is undefined when the signal (sonar) is greater than Vref (3.3).

if(baro_alt < 1000){

            #if SONAR_TILT_CORRECTION == 1
                // correct alt for angle of the sonar
                float temp = cos_pitch_x * cos_roll_x;
                temp = max(temp, 0.707);
                sonar_alt = (float)sonar_alt * temp;

            scale = (sonar_alt - 400) / 200;
            scale = constrain(scale, 0, 1);
            current_loc.alt = ((float)sonar_alt * (1.0 - scale)) + ((float)baro_alt * scale) + home.alt;
            current_loc.alt = baro_alt + home.alt;


Yes unfortunately I think analogue is being used. Perhaps because it is easier to do it that way when it is on the Pitot port.Someone who knows the hardware should comment.


I've seen blog posts here which describe using shielded cable to reduce noise and that has a tangible effect on alt hold performance. However with PWM/Serial comms available from the Maxbotics devices I think we are really missing a trick here. It is always better to eliminate noise sources rather than reduce them.


Some one correct me and set the record straight if digital comms is working for sonar...

The question is if PWM or serial are available on APM hardware or maybe its less CPU intensive to use the external ADC.

However, anyone tried to use the sonar with 3V3 voltage and benefit from ratiometric properties (ADC and sensor same Vref)?
I see the point on using the sonar @5V and ADC "zooming" the usable 3.3V of its output, but voltage drifts and noise on 3V3 and 5V could ruin the desired precision.

As a quick fix can I just put a ferrite ring on the cable until I can locate a shielded cable? Does it do the same thing more or less?

I am blind in the world of ferrites. I have been interested many times but never found out info enough.

Can anyone spread light over this topic? ferite diamaters, number of loops, etc?



     Great work once again.

     We use to cater for the LV-EZ0 but the consensus was that the output was the same for both so we removed the special code for the LV.  It was messy anyway because it couldn't be done in the CLI..it was a compile time option.  I swear I saw a datasheet with the LV reporting in cm...but I must have been mistaken.

     Anyway, it's not terribly difficult to allow for the different versions and Michael Oborne probably wouldn't mind adding a dropdown into the APMP.  I don't think it would lead to any performance impact.  I can take care of this although I can't do it this week.

     The 3.3v cut-off is a bit of a concern...I would definitely not want to provide 3.3V to the sensor's power because according to the datasheet that does affect distance.

     I've added it to the issues list here.


Hi everyone,

We saw your post on here and wanted to add some information. We recently completed a  study of noise immunity of our sensors.  Please click this link to view the post in DIY drones http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A2891...


Thank you for showing how accurate our analog voltage is.  If you have any specific questions about your above post please let me know. 


Best regards,

Scott Wielenberg
Technical Support & Sales
of MaxBotix Inc.
Phone: (218) 454-0766
Fax: (218) 454-0768
Email: scott@maxbotix.com

Web: www.maxbotix.com

Follow us on Facebook at: http://www.facebook.com/pages/MaxBotix-Inc/125159384204938

Technical support and sales are subject to



Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service