Throwing more feeds & speeds at a problem

sonar98.jpg

 


So sonar was officially back again for another swing at a home run, with a lot more clockcycles.

 

bear.jpg



AP

It was a hot one.

Unlike the last attempt, beacon triggering over USB was neither an option nor accurate enough.

sonar89.jpg

sonar88.png


So that was propagation delay over 10ft using a hard wired trigger & 266khz sampling on a PIC.  It was extremely accurate but not reality.


Past attempts to synchronize beacons with radio packets were very ineffective.  That requires a mode of communication with a constant latency.  USB was good enough for 1 meter accuracy.

The 802.11 system currently in use is even less realtime than the USB system in the old days.    The aircraft would use IR for a trigger.

sonar91.jpg


It came from a chinese toy.

sonar92.jpg


The IR emitter was toggled at 38khz & ran on 1.5V.

sonar90.png


The intended IR trigger naturally failed.  38khz modulation was too erratic.


That leaves only a draconian complex system involving a dedicated, hard modulated 900Mhz radio set. The radio set would be used to send triggers using a hard realtime bit banging protocol.  An 802.11 radio would be omitted from the ground station.

sonar93.jpg

sonar94.jpg

The MRF49XA radio in raw mode allows a trigger to be sent with 256khz precision.  Getting raw mode requires clearing the TXDEN & FIFOEN bits in the GENCREG register.  Then, the FTYPE bit in BBFCREG needs to be set for analog filtering.

Getting the maximum bandwidth requires driving the FSK/DATA/FSEL pin on the transmitter to 0 or 3.3V & reading the RCLKOUT/FCAP/FINT pin on the receiver.  You're looking at a lot of pins for a full duplex radio set.

The FSK pin outputs a lowpass filtered voltage which maxes out at 115 khz.  The FCAP pin outputs the unfiltered voltage at 256 khz, so for a sonar trigger, you need the 256 khz voltage.  The voltage is not linear, but either 0 or 3.3V.  You would need a codec to get audio through it.

It's important to get the GENCREG register address right, which happens to be 0x80, exactly the same as the TXDEN bit you need to disable. 

sonar93.png

Not as blazingly accurate as the hard wired trigger. 

a2422254-109-sonar34.png


An original graph from 2009.  The 2 graphs covered the same distance.  No dramatic improvement is jumping out from the extra firepower, but the original USB clock synchronization can be considered very high quality.

Even with the waveform massively oversampled at 266khz, things weren't decisively different than the experience with 74khz.  The massive signal processing developed in 2009 was still required.

The quest to reduce the signal processing to something that could be put in a simple analog circuit showed the comb filter is required to suppress noise.  The integral is required to further separate the pings from the noise.  Not sure why anyone thought a simple analog circuit could do it. 

A PIC at 64Mhz would be just fast enough to do all the required processing for 1 channel.  I actually implemented it on a PIC in the last week, to show how much free time unemployed programmers have.  At 40Mhz, it maxed out at 180khz.  Also, with the comb filter, subtracting a 1/2 wavelength worked better than adding a full wavelength.

A 16 bit ADC might do a better job & be $22 for anything in the 216khz range.  More gain with less noise would do the same thing.  Sort of sad to see the amount of mathematical fudging which was done in 2009, in the belief something workable was just around the corner, only to have it lead nowhere.

sonar99.jpg

Completion of the next sonar board using 168Mhz ARM revealed some interesting nuggets about the STM32.

It works with only 1 VCAP, VDD, & VSS connected, greatly simplifying the routing.  The VDDA & VREF+ can be connected to a VDD pin.  Only 1 VSS is required.

ADC sampling can go in the 600khz range with no obvious noise issues like the PIC.  8 bit sampling goes a lot faster than 12 bit.  While it can do a lot more with audio than video, it's still very limited in the 300khz range that you need for sonar, so you'll be hand optimizing.

Function calls kill it.  As much as possible must be inlined.  Those convenient GetFlagStatus calls need to be replaced with inline ->SR calls.

Some operations go a lot faster with unsigned than signed variables.  1 operation that signing killed involved multiply & divide.

The packing order of variables affects speed.  Splitting up a bunch of frequently used variables with large, infrequently used buffers slows it way down.  Having all the frequently used variables together speeds it up.  It's a caching issue.

 

sonar95.png


So with the ARM screaming at 329khz per channel, that was propagation delay with the sensors 3" apart & the transmitters 2ft away, on the bench.

sonar96.png


That was the propagation delay over 10 ft with 3 sensors.  That actually looks equivalent to the PIC sampling at 266khz.  1 of the sensors has 4x the gain of the other 2, without showing any obvious difference.

sonar97.png



The position calculation in centimeters once again lost a lot of precision.  With the 12V emitter & super fast sampling, it was almost omnidirectional, but the precision dropped as the horizontal distance increased.  This was the 1st time horizontal accuracy was seen improving dramatically with wider sensor spacing.


The pings were 8 Hz.  The sampling rate was 329khz at 8 bits.  There's no point to using the 256khz radio bandwidth.


Calculating the position has been done with very slow, trial & error pythagorean calculations on the ARM.   Despite its floating point support, there hasn't been enough incentive to load the math library on the flash, to do a fast trig solution.

The position is only calculated on the ARM in case it could be sold as a standalone position calculator.

Ground based sonar still isn't going to have the all out range that ground based vision could have.  For 1 vehicle flying in a small room, it might have the immunity to the environment to come out ahead of vision.  It's not as compact as an equatorial mounted camera, but has a lot less fabrication & costs a lot less.  It won't need a high speed connection to the computer.

 


In Feb 2010, an amazing amount of work went into getting Marcy 1 a sonar guided autopilot, in the belief that the real M.M. would have seen it in person.  It turned out Her attention was impossible to get for any normal guy & there wasn't a snowball's chance in hell of Her ever watching a normal guy fly a UAV.

Even if sonar worked in time, it was an obsurd campaign.  She had many celebrity suitors & is now settled down with a famous producer in LA, resigning from the USAF in 3 years.  In that case, it would have been truly awful for Her if the sonar panned out in time.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • That is some good stuff.  I can only dream of ever understanding how these little chips really work and how to really tell it what to do in an effective way. 

    That Marcy chick must be hot, hot, hot.

  • Jack you inspire me:) I find myself a bit overwhelmed by your knowledge.  Just out of curiosity, have you ever worked with any of the piezo actuator development kits?

  • Was wondering what happened to Evolution Robotics after last month's localization press releases.  They discontinued their RF system.  But no.  Their product would not be enough to fly Marcy 2.

  • is this how http://www.evolution.com/products/northstar/ works?

This reply was deleted.