8 replies to this topic

[Inquisitor]

Software type needing training wheels…

I recently purchased the Ultrasonic Ultrasonic Range Finder - XL-Maxsonar EZ0. And I've read through some of their extensive website and notice they have spent some exhaustive development time to make it pretty simple to use and reduce false results. The break-out board seems to be rather full of circuitry and certainly justifies the cost to me.

I’d like to experiment with the raw transducer. I want to conceptually understand what’s going on. Please correct me if I’m off base. Basically, if I understand things correctly, this is like a small speaker. It sends a pulse out and then listens for the echo with the same diaphragm. Would it be possible using the PWM of the Netduino to send out this short pulse at 42kHz and set an Interrupt Port listening for the echo? Since the transducer only has 2 leads, I gather that I’d probably need a third digital port to switch from send mode to listen mode. The data sheet doesn’t give me much to go on. I don’t mind damaging the transducer if I screw up, but I’d rather minimize my chances of damaging the Netduino.

Would anyone have any suggestions on how to proceed (wiring examples, references on the Internet or anything)?

Thanks for you help!

[CW2]

Would it be possible using the PWM of the Netduino to send out this short pulse at 42kHz and set an Interrupt Port listening for the echo? Since the transducer only has 2 leads, I gather that I’d probably need a third digital port to switch from send mode to listen mode. The data sheet doesn’t give me much to go on.

The device can operate as both transmitter and receiver, so 2 leads are enough. You'd drive it with PWM modulated pulse (38 - 42 kHz), then wait about 1 ms until it stops 'ringing' and then listen for echo. Those devices usually require voltage ~10 - 12 V (this particular one has 20V max, 60V peak-to-peak 10% duty cycle), so apart from using transistor to switch such voltage, a relatively easy option is to use CMOS inverters connected as voltage doubler (for 5V Netduino power supply). For the receiver, you'd need an amplifier (usually two stage op-amps). There is plenty of information and sample schematics available on the internet, for example DIY Ultrasonic Rangefinder, A Sensitive DIY Ultrasonic Range Sensor, or you can simply reverse-engineer the one you've got

[Mario Vernari]

@CW2: do you think the measure could be reliable, since the unpredictable background working of the GC?

[Inquisitor]

The device can operate as both transmitter and receiver, so 2 leads are enough. You'd drive it with PWM modulated pulse (38 - 42 kHz), then wait about 1 ms until it stops 'ringing' and then listen for echo. Those devices usually require voltage ~10 - 12 V (this particular one has 20V max, 60V peak-to-peak 10% duty cycle), so apart from using transistor to switch such voltage, a relatively easy option is to use CMOS inverters connected as voltage doubler (for 5V Netduino power supply). For the receiver, you'd need an amplifier (usually two stage op-amps). There is plenty of information and sample schematics available on the internet, for example DIY Ultrasonic Rangefinder, A Sensitive DIY Ultrasonic Range Sensor, or you can simply reverse-engineer the one you've got

Boom! He does it again. I'm going to have to improve my Googling skills.

Great references and an Arduino version. Can't get much closer than that!

I don't think I'm up to the re-verse enginerring. But, my eventual project needs about ten of these things (so... ~$500) and my thought was to buy the one and cut the two leads and then use the guts through a Mux to the ten sensors and just round-robin them. But when I received the unit, they apparently have thought of that... and epoxied the transducer solid to the circuit board over all the little IC chips and other stuff I can barely see.

[CW2]

@CW2: do you think the measure could be reliable, since the unpredictable background working of the GC?

IMHO it depends on the complexity of the application, in trivial cases (i.e. no garbage collection involved) it should work fine.

[CW2]

But, my eventual project needs about ten of these things (so... ~$500)

Solid (i.e. waterproof) ultrasonic sensors can be harvested from cars at junkyard, although they can have digital interface and specific characteristics (distance range, beam spread etc.), which may not fit your needs.

[Inquisitor]

@CW2: do you think the measure could be reliable, since the unpredictable background working of the GC?

I'll take a stab at that one...

I haven't used the PWM stuff yet, so I can't talk to it. However, on receiving digital data side based on an interrupt, which is the way I would write this science project, I do not think there is an issue. The snippet of code below mentions "NativeEventHandler" which leads me to believe that the underlying code is handling it natively and bubbling up the event as necessary. Since it also sends the DateTime up as a parameter leads me to believe that the DateTime is being determined at the low level irrespective of any GC. I would image they are queued and if a GC occurs, it merely blocks what gets up to our program. But once it gets there, the DateTime will be valid. When using it in the tachometer science project I was running over 2000 interrupts per second (0.5 ms/interrupt). I would imagine any GC would be at least an order of magnitude longer. At which case I would have had some data sample saying it took an order of magnitude longer than the others. That never happened.

...That's my speculation, which can easily be checked by anyone who delves into the Micro framework code. Chris, probably knows it off the top of his head.

_highFrequency = new InterruptPort(pinDigital, false,
    Port.ResistorMode.Disabled,
Port.InterruptMode.InterruptEdgeLow);
    _highFrequency.OnInterrupt += new NativeEventHandler(
        PerHighFrequency);

[CW2]

That's my speculation, which can easily be checked by anyone who delves into the Micro framework code.

I think you are right, the time passed to the interrupt event handler is taken in the function SaveToHALQueue() called from within the pin interrupt service routine (ISR). Coincidentally, I am working on a project that uses interrupts to measure pulses roughly 100 µs long (~80 - 130 µs), I have concluded some experiments to determine the performance of the interrupts - I will publish my findings when the project is finished.

[Inquisitor]

I think you are right, the time passed to the interrupt event handler is taken in the function SaveToHALQueue() called from within the pin interrupt service routine (ISR). Coincidentally, I am working on a project that uses interrupts to measure pulses roughly 100 µs long (~80 - 130 µs), I have concluded some experiments to determine the performance of the interrupts - I will publish my findings when the project is finished.

I'll certainly look forward to your findings!