R&D Progress Log #3 (continuing from R&D Log #2)

[Steve Gibson]

R&D Progress Log #3 Anchor.

[Steve Gibson]

Gang...

I have the chip's built-in voltage comparator configured and running.  I needed to move a few pins around, but all's okay.  I like the way it appears to be operating so I'm going to move the chip from the LaunchPad board to the ProtoBoard and wire it up to drive a delta modulator to convert a time-varying analog waveform into a time-varying variable pulse width digitized signal... which is what we need to drive our H-bridged tweeter.

More soon!

/Steve.

[Steve Gibson]

Gang...

I have confirmed that there is absolutely no need for the 4.7uf C1 supply filter capacitor in the v2.2.2 design.

I will be removing it when I next update the design.  I would do it immediately, but I also want to redesign the image of the chip so that it also looks like the actual 8-pin DIP, with the pins in the proper locations, to help future people who are building it.  But I don't want to interrupt my current delta-modulator work just now.  :)

/Steve.

[Steve Gibson]

More Sample-Rate Math

Gang...

Adrian's and Kyle's recent comments hit me when I had a bit of time this morning.

It's true that IF I could somehow figure out a way to have the uController directly involved in the PWM generation at the sampling level -- though there's really not much time for it -- then we would do away with the need for a source for analog sine waves and a delta modulator to convert the analog sine waves into digital PWM to drive our output stage.

So I looked into the absolute minimal hand-tuned interrupt service routines that could be used to have a code-based approach. Above are the three absolute minimal solutions possible.  (The instruction set is so clean that there are not many ways to optimally achieve the same thing.)  The first one shown is the fastest, with a TOTAL "Soup to Nuts" OVERHEAD -- processor wake up, interrupt response, processor shutdown -- of 21 cycles.  The trick is that it masks off the lower 'n' bits  of the indexing register thus forcing it to count modulus 2^n to wrap and repeat.

The last one shown is a 1-cycle improvement I made of the second (middle) approach, costing only ONE additional cycle over the first, "Mod 'n'" solution, which allows look-up sample table lengths of any length.

So let's assume we go with the third approach since it won't force us to round down to a multiple of 2 sample count.

With a 16Mhz clock, and 22 cycles per sample, we can produce samples under software control at the rate of: 727,272.727  samples per second.

If that absolute maximum sample rate were used to produce a 15khz tone, we could have 48.4848 samples per cycle of the tone. Rounding that down, give us 48 samples/cycle, or 12 samples per quadrant.

So that doesn't seem too bad.

The next trick, though, is the resolution of the PWM signal itself.  Its maximum resolution is the same 16Mhz. Meaning that each sample, which is 22 clocks long, must have an integer number of high and low time.  If the PWM period were the same as the sample period, then we could only have values from 0 to 21.  Now, that's not so bad... but that also means that wee only have one cycle of "PWM" for every sample.  That's really not great.  I'm unsure that it's a deal breaker... but it would be nice to have a PWM period that's several times shorter than the sample size.  We could go with a PWM period of 11 cycles, then get two PWM cycles in per sample period.

All that said... I do think it's a direction that needs to be explored since then we'd be back to a nearly all digital design with just the uC, a voltage booster, and the power output stage.

And... WHILE the tone is being sounded... what UI or other work do we really need to be doing anyway??  So my argument about the uC being able to do literally nothing else while generating the time... is moot.

/Steve.

[Steve Gibson]

Gang...

The delta modulation scheme works.  I am getting a tone out of the speaker, tied in the H-bridge, given an analogue sine wave being fed into the delta-modulator which is converting it into a digital pulse-stream.

I need to grab some lower value capacitors than I have on hand -- which I'll do tomorrow -- since the delta-modulator's filter isn't optimized with what I have.  But it's looking good so far.

/Steve.

[Kyle Smith]

Steve,

Good news.  Can't wait to see your magic.  You are tenacious and talented.  Very dangerous combination; but your definitely one of the white hat engineers, so I'm not terrified.

Best wishes from the FL Keys,

--

Kyle Smith (AG2F)

air...@me.com

[Steve Gibson]

Good news.  Can't wait to see your magic.  You are tenacious and talented.

Very dangerous combination; but your definitely one of the white hat engineers, so I'm not terrified.

No need to be terrified... unless, perhaps, you're annoying someone by barking too much!  <g>

/Steve.

[Steve Gibson]

Gang...

I have continued to struggle with ways to move as much of the complexity as possible inside the chip.  That's just the right place for it to go.  That's what it's there for.  After examining the many details of trying to do things with more hardware, it gets messy enough to have increased the pressure on me for an all-software solution.

So I have recently been exploring a new series of ideas for an all-software solution to generating sine waves with our h-bridge digital driver.

This morning I think I finally put the new pieces together.  The idea is somewhat radical, but I believe it will work:

I have been bothered by a number of annoyances about classic pulse width modulation (PWM).  Chief among them is the notion of the fixed-resolution of the PWM period.  If we had, say, eight-bit resolution for 256 "levels" of PWM... we would have 256 "intervals".  If we then wanted to output a 50% value, the pulse width would be 50%, so it would be "on" for the first 128 of the 256 intervals and then "off" for the remainder.  But that's incredibly inefficient when we could, instead (theoretically) ALTERNATE every other bit 128-times to achieve the same 50/50 level... while achieving something much closer to a "DC" level.

And it might be okay if, for example, there were time for MANY PWM periods within one "sample" period... like if our PWM was running VERY fast and we were wanting to generate various DC voltages... as with a slow DAC.  But that's not what we want here.  We want to generate a high-audio-frequency sine wave, and our PWM can only run at 16Mhz, which just isn't very fast compared to a 16khz sine wave.  That leaves 1000 bit-periods which much be sub-divided into fixed-size PWM periods.  Even if we only used 16 bit-periods for four bits of value resolution, that leaves us with about 60 PWM periods per cycle, or 15 per quadrant... and that's with NO "oversampling" where many PWM periods fit into a single sample time.  That's with just ONE PWM period per sample.

These frustrations have led me toward a new approach...

What I believe is that with extremely limited resources, we can achieve FAR GREATER FIDELITY if every single bit-period is independently and deliberately chosen. The idea would be that there would no longer be anything like a "PWM period".  Instead, we would be emitting a pure seamless bitstream where the recent average of past bits -- on or off -- would determine the current effective value.  This "boundary-less" bitstream should be able to follow the shape of a sine wave FAR more closely than any form of fixed-repetition pattern.  And... what's more, its effective resolution INCREASES during the steep slope portions of the sine wave when we're not close to the top or bottom, where we have an active mixing of 1's and 0's and can smoothly shift the percentage of those 1's and 0's at will.

Generating such a bitstream with the MSP430's limited resources is, of course, challenging... but I figured out how to do it this morning over breakfast.  The MSP430 has serial interfaces, and one of them -- SPI -- is a synchronous interface without the annoying and interfering start and stop bits of an asynchronous interface.  That means that theoretically we can emit a pure continuous bitstream of our design.

As I explained previously to some thoughts from Adrian, any classic PWM system on the MSP430 needs to use the interrupt system to obtain jitter-free sample timing. But that was imposing a significant, fixed, 11-cycle overhead per sample. Since the SPI serial interface is double-buffered, with a transmit buffer, we can now loop waiting for "buffer available" and put the next value in asynchronously, relative to the precise timing, without introducing any sampling jitter.  So this gets us away from the interrupt system's fixed 11-cycle overhead.

I have designed an absolutely minimal 20-cycle inner loop that allows us to output a continuous 8-bit bitstream at a rate of 6.4 megabits/second. A 16khz sine wave would then be expressed as a 400-bit long bitstream... or 100 bits per quadrant.  And, intuitively, that seems pretty good for approximating a smooth-curve sine function (WAY better than 16 fixed-size PWM blocks).  The entire 400-bit long bitstream, at 8-bits per byte, would therefore consume just 50 bytes of RAM.

And... assuming that we always kept the sample-rate fixed, a 500-byte table (which we do have the RAM for) would give us a 1600 khz sine wave... so that's plenty of range (more than 3.3 octaves).  And note also that we now have volume control by changing the effective sine wave amplitude.

As before... WHILE the uC is generating this tone, we are unable to do ANYTHING else.  This requires its FULL attention.  But that's okay, since our application doesn't  really require anything else during tone blasts.  And the timer system, which is now completely freed up, can "interrupt" us periodically to see whether anything needs to be done.

I don't yet know how to construct the bitstream... but I'm sure I'll figure it out.  And once I have everything running, we should have relatively high-fidelity sine waves output without needing ANY additional components or chips!  The uC would directly drive the single 8-pin DIP H-bridge output stage.  I like it.  :)

/Steve.

[sigpoggy]

I just ran an experiment on the hornification idea. I took a small audio amp and a plastic tube from my bug wand, put the tube in front of the speaker, fed a sine wave into the amp and tweaked the frequency until I got a maximum output level.

The tube is 11" long, diameter of 1 3/16". The best frequency was around 586Hz. The back of the speaker is no more than 3/8" from the end of the tube. Calculations show that the wave length for 586Hz is 23.14". So the tube is close to 1/2 the wave length but not exact.

The sound went from pretty quiet (67db) to uncomfortably loud (86db) by introducing the tube. Here is the setup:

[sigpoggy]

Correction, the tube is 10" long.

[Kindanyume]

promising indeed esp for fixed installs.. but far more limited for portable designs.

[Steve Gibson]

Cool!

Yesterday I purchased a bunch of 1.5" tubes from my local hardware store.  It turns out that 1.5" is a standard value.  I also got RTV silicon rubber adhesive for bonding the edge of a 1.5" piezo disc to one end of the tube.  I'll be a while before I stop my main work to do this... but your experiment is very encouraging.  :)

Physics in action.  What fun!!

/Steve.

[Steve Gibson]

promising indeed esp for fixed installs.. but far more limited for portable designs.

I think it's the opposite, really.

The wide dispersion "flood light" approach works best for non-aimed fixed installations I think.

And my intention is not to resonate the tube at its fundamental, but at many multiples of it, so that we get transverse wavefronts both inside the tube and emitted out one end.

What Jim's experiment DID demonstrate conclusively is that tubes can be "tuned" and "resonate"... and the ONLY WAY that can be explained is by the impedance change at the tube opening boundary.  That's key.  :)

So... My guess is that a six-inch long tube ought to be plenty long when we're up in the 16khz region.

My ONLY concern is how to automatically find the resonant sweet spot.  (Back to THAT old problem... though in different clothes.)

/Steve.

[Kindanyume]

I'd have to disagree steve.. since a portable (on hip/pocket etc)
version needs to be much smaller.. and unless it is built with a swing
out telescopic tube..(similar idea to gravity powered batons vs spring
powered) it would be rather unworldly for the avg person.

Yes the volume would be increased considerably.. but due to the
physical size it would be less "portable".

However.. a shorter tube made of a smaller diam could be helpful
there.. particularly if the entire "design" is housed in one end of
say a 6" or less pipe.

[Kindanyume]

unworldly? unworldly?

damn spell check! That is supposed to say "unwieldy" lol

[billmcf]

On Monday, January 14, 2013 1:11:32 PM UTC-8, Steve Gibson wrote:

I don't yet know how to construct the bitstream... but I'm sure I'll figure it out.  And once I have everything running, we should have relatively high-fidelity sine waves output without needing ANY additional components or chips!  The uC would directly drive the single 8-pin DIP H-bridge output stage.  I like it.  :)

/Steve.

Steve,

In constructing the bit stream, maybe there's something to be learned from the 1-bit A/D and D/A converters used in digital audio products.  They operate at sample rates of several MHz.  They aren't purely digital but might be worth a look.

[Kindanyume]

sounds interesting and reminds me of some of my test cds w/various
freq recordings.. only generated "in house" vs the cd recording.
Mind you even a 'recorded' sound if embedded could work since it would
be an very very tiny sample.

Def worth looking into IMO

[Steve Gibson]

Hi Bill!

In constructing the bit stream, maybe there's something to be learned from the 1-bit A/D and D/A converters used in digital audio products.  They operate at sample rates of several MHz.  They aren't purely digital but might be worth a look.

Yes.  I didn't mention it in my posting, but the name for this approach is "Pulse Density Modulation" (PDM) and, massively "oversampled", it IS indeed analogous to one-bit A/D and D/A conversion.

Thanks!

/Steve.

[sigpoggy]

Steve, you could take the direct approach for tuning it with one of these.

[billmcf]

In that case, constructing the bit stream is simple:

http://en.wikipedia.org/wiki/Pulse-density_modulation

 

[Steve Gibson]

In that case, constructing the bit stream is simple:

http://en.wikipedia.org/wiki/Pulse-density_modulation

Ha!  Oh yeah... it's simple from 1000 feet.  A real piece of cake!  Pretty pictures!

But when you get right down to whether the next bit should be a 1 or a 0, and you understand that the decision is based upon the past 1's and 0's that cumulatively (and diminishingly) affect the tweeter's current state (as a function of its frequency and phase responses), plus the current and upcoming waveform, and when you take into account the fact that the tweeter's current state is a function of its LC-network frequency response which is what we'll end up driving with our uC... then it becomes just a wee bit more complicated.

I'm building a mathematical model of the inductor/capacitor LC network's response.  It's a 2nd-order low-pass filter, due to the fact that we have two reactive elements, an L and a C.  Then (in software this time) we feed an ideal sine wave at the target frequency into a greater/less-than comparator which gives us a decision. That "decision" is the one-bit 0 or 1 output which we save.  We pass that one-bit output into an Infinite Impulse Response (IIR) linear-time discrete digital filter with coefficients which have been tuned to exhibit the same frequency and phase response as the output stage's LC filter (the inductor and tweeter).  The output of that filtering process will be a varying analog value between 0 and 1... which we feed back into the first-stage comparator in order to make our decision about the next single digital bit.

And, of course, all of that needs to be done in MSP430 uC assembly language for the required performance.

So yeah, like you said... "constructing a bit stream is simple."

/Steve.

[sigpoggy]

Since I'm totally lame when it comes to all that math and stuff, I'd just start pumping signals into the circuit and measure what output you get for what density.

[Steve Gibson]

Jim...

Since I'm totally lame when it comes to all that math and stuff, I'd just start pumping signals into the circuit and measure what output you get for what density.

I TOTALLY understand.  And don't (anyone) misunderstand... I'm NOT complaining.  I LIVE for this!  For me it's not "does it work" -- it's: Is it possible for it to work better??  <g>

The reason I'm pursuing this (currently) -- aside from enjoying the idea of leaving behind some beautifully written legacy code since I have taken the trouble to learn the MSP430 -- is that I have a hunch that we may be heading toward the design of a TrebleShooting "sound rifle" based upon a single piezo "bender" acoustically mounted to the back of a simple tube.  If so... we are back to a system where the frequency is CRUCIAL to the operation of the system.  And if that's the case, the non-acoustically-resonant v2.2.2 fixed-frequency design cannot be used -- unless the length of the tube is manually tuned for maximum output.

I am hoping that the uC's ADC will be able to sense a "warping" of the symmetry of the sine wave which will tell it which direction the frequency needs to be shifted to reach resonance.  We'll see.  :)

/Steve.

[Kindanyume]

Technically that is 100% accurate as you stated and my quote.

However.. creating an accurate bitstream for exactly what you want
with very limited resources... well ... might not work quite as easily
:)
(though we can wish.. or wait for Steve to pull off his usual genius work)

[Steve Gibson]

Ultra-Tight Coding Update

Gang,

I hit a bit of a glitch in my thinking/planning, when I realized that the MPS430 hardware forces our forthcoming bit-stream to run at an integer multiple of its clock rate. 

Because UARTs (universal asynchronous receivers transmitters), being "asynchronous" operate without any synchronizing clock, they MUST have bit rates which are exactly specific to the communications format.  Consequently, the MSP430 supports FRACTIONAL clock rates for its UART peripheral.

But the SPI (and I2C) serial protocols are synchronous where the "master" device generates an accompanying clock signal to instruct the "slave" recipient(s) when to clock in and clock out their data. Thus... the clock rates are NOT critical and the MSP430 only allows for integral divisions.

So here's the problem... Two days ago I wrote:

I have designed an absolutely minimal 20-cycle inner loop that allows us to output a continuous 8-bit bitstream at a rate of 6.4 megabits/second. A 16khz sine wave would then be expressed as a 400-bit long bitstream... or 100 bits per quadrant.  And, intuitively, that seems pretty good for approximating a smooth-curve sine function (WAY better than 16 fixed-size PWM blocks).  The entire 400-bit long bitstream, at 8-bits per byte, would therefore consume just 50 bytes of RAM.

The trouble is... the MSP430 WON'T output the "6.4 mbps" bit-stream that I referred to there... because we can only have integer divisions of the system's main 16mhz clock.  Dividing by 1 we get, of course, 16mhz (which is too fast for us, since we can only supply output bytes fast enough to support a rate of 6.4 mbps.) Dividing by 2 we drop to 8mhz... which is still too fast.  Dividing by 3 gives us 16/3 or 5.333 mbps... which is slow enough for us to provide the data fast enough for that bit rate.

But... can I do better?  Yep.

I realized three things:

1. Since we absolutely know the rate at which bits will be shifted out and new bytes needed for output, if we accurately count the cycles of every instruction, we can eliminate the overhead of checking for when the output buffer is free. We should be able to blindly put data into it knowing that it'll be ready.

2. On the MSP430, WORD length operations take NO MORE TIME than BYTE length operations. SO I can fetch two bytes from our previously prepared bit-stream buffer in no more time than fetching only one byte.  Register operations are faster.

3. Since we are double-buffered, we can be up to 8-cycles late in depositing new data into the transmit buffer.

Whereas my BEST CODE two days ago was only able to output ONE byte every 20 cycles... I have new code, using those new principles, that can output ONE byte every 8 cycles!!

And ONE byte every 8 cycles means that we're able to run the SPI digital bit-stream at its maximum speed of 16Mhz!!... for a maximum-resolution 16 million bits-per-second drive of our H-bridge. This is better than twice what I thought I could do before, and three times better than I could have actually done.

This means that a 16khz sine wave would be described by a 1000-bit bit-stream, or 250 bits per quadrant!

NOW we're really cooking with gas!!

/Steve.

[Steve Gibson]

What's Next for Me...

Right now, before plowing into the next phase of work, I'm going to break for this week's podcast prep and to give these new ideas some time to percolate.

Then... rather than implementing this technology first in the MSP430, I'm going to simulate the entire bit-stream code system in JavaScript. That will serve a number of functions: It will allow me to verify and tune the bit-stream system in a much more friendly interactive environment, and it will also document the algorithms in a much more easily readable and understandable format (which anyone will be able to play with) and allow other interested people to better understand how it all works.

The output of the algorithm will, among other things, generate a block of 125 bytes (1000 bits) which I'll be able to copy directly into the MSP430 source code to then use with the bit-stream blasting algorithm I just posted. That way we'll be able to SEE how our output stage hardware actually handles the bit-stream.  If it's not what we expect it'll be easy to tweak the system in JavaScript.  And once we have it nailed, the JavaScript will form a proven template for assembly code implementation in the MSP430.

/Steve.

[sigpoggy]

Great idea. Go go man!

[billmcf]

On Tuesday, January 15, 2013 12:46:19 PM UTC-8, Steve Gibson wrote:

In that case, constructing the bit stream is simple:

http://en.wikipedia.org/wiki/Pulse-density_modulation

Ha!  Oh yeah... it's simple from 1000 feet.  A real piece of cake!  Pretty pictures!

My apologies.  I should have realized you'd already be working on the optimal solution, way beyond the generic one I referenced.  Perhaps the link will be useful to others to illustrate the general concept.

[Kindanyume]

NOW we're really cooking with gas!!

/Steve.

But cooking with napalm is far more fun!!!

:)

[Steve Gibson]

 

In that case, constructing the bit stream is simple:

http://en.wikipedia.org/wiki/Pulse-density_modulation

Ha!  Oh yeah... it's simple from 1000 feet.  A real piece of cake!  Pretty pictures!

My apologies.  I should have realized you'd already be working on the optimal solution, way beyond the generic one I referenced.  Perhaps the link will be useful to others to illustrate the general concept.

Oh!, no apology needed Bill.  I absolutely knew you were simply wanting to help and contribute. But... yeah... this project has had my total undivided attention, so I'm pretty much dominating it... and your note just gave me the opening to explain what I was working on!  <grin>

And I have to say... I am really pleased that I have finally figured out how to emit a continuous 16 Mhz bitstream.  It 100 percent saturates the uC, but that's okay during tone generation.  And there's just no way that's not going to be more than sufficient to give us really lovely wave shaping!!  Oh... I'm so excited. I can't WAIT to see it happen!!!

/Steve.

[Brian Hall]

Steve,

Do you sometimes have dreams that reveal a solution? Sometimes, when I'm occupied with a particular project or task, I start dreaming it. I can only imagine that is happening to you, especially as you devote so much focus to an optimal solution.

Brian

--

Brian Hall

[sigpoggy]

If you are 100% into generating the signal, how will you monitor it? These chips are cheap enough you could use two.

[Steve Gibson]

Brian...

Do you sometimes have dreams that reveal a solution? Sometimes, when I'm occupied with a particular project or task, I start dreaming it. I can only imagine that is happening to you, especially as you devote so much focus to an optimal solution.

Dreams don't seem to be my non-deliberate vehicle.  But I've been doing this sort of problem solving for so long that what I've noticed is that solutions often come unbidden.  I'll be driving, in the shower, doing something else entirely... and the answer will pop into my head.  So other parts of me are apparently working on it when I'm not.  The effect has been strong enough that in the past there have been times when I'm completely stuck after days and I KNOW there must be a solution.  So I'll decide that I have focused upon it long enough for "the deeper parts" to have gotten the message... and I'll just distract myself, sometimes for a few days, waiting for the answer to be delivered.  Typically... it is.

And all of that is why I'm just never in a hurry.  I'm always busy... but I always have time for a better solution.

/Steve.

[Steve Gibson]

If you are 100% into generating the signal, how will you monitor it? These chips are cheap enough you could use two.

Ah!  Conveniently, the Analog-to-Digital converter is able to run all by itself, automatically performing conversions and depositing the results into RAM.  So I'm hoping that we'll be able to REALLY have that cheap little chip humping!

/Steve.

[sigpoggy]

Cool!

[Brian Hall]

Absolutely! I totally agree. Often times, just stepping away for a little while is enough to allow your brain to "defrag" and then the solution becomes clear, often when you least expect it. Isn't that amazing?

But seriously? No PDK dreams?

Brian Hall

--

Brian Hall

[sigpoggy]

I assume you will use an interrupt on release of the trigger switch to stop the output. Is is possible to limit the output duration with out adding code to the loop?

By the way, this is off topic, but you did mention fun with physics - check this out

[Steve Gibson]

Jim...

I assume you will use an interrupt on release of the trigger switch to stop the output.

I don't think so, and...

 

Is it possible to limit the output duration with out adding code to the loop?

Yes.

---

My thinking was that since we don't need anything to be "running" in any way when the button is NOT being pressed, the main "fire" button would still be the master power switch in series with the batteries... and doing nothing else.  That way we have a zero-current-leakage design.

But that doesn't mean that the device would HAVE to be running emitting sound all the while that the button is pressed!

We have two uncommitted timers which can be used to interrupt the main bit-stream loop.  So before beginning to generate the sine wave, a timer could be started, then the "interruptible loop" begins to generate a sine wave.  When the timer runs out we're interrupted and the output tone ends.

So, in that fashion, it would be possible to limit the loop's output duration.

/Steve.

[rob...@gmail.com]

There is a video on youtube about piezo tweeters to control dogs (http://www.youtube.com/watch?v=kmejVIQshMA title BARKING DOG NEXT DOOR - HIGH FREQUENCY SOUND (More Info) ). It looks like he started with the same tweeters mentioned here. But, he says that they are louder without the horn and recommends a tube to focus the sound. Steve mentioned a tube but I never found a reference to a tube in the threads I read. If the video is true the unit could be built using 1-1/2" PVC for the tube and maybe something a little smaller for the battery and PCB.

Roy

[Steve Gibson]

Hi Roy...

There is a video on youtube about piezo tweeters to control dogs (http://www.youtube.com/watch?v=kmejVIQshMA title BARKING DOG NEXT DOOR - HIGH FREQUENCY SOUND (More Info) ). It looks like he started with the same tweeters mentioned here. But, he says that they are louder without the horn and recommends a tube to focus the sound. Steve mentioned a tube but I never found a reference to a tube in the threads I read. If the video is true the unit could be built using 1-1/2" PVC for the tube and maybe something a little smaller for the battery and PCB.

I have ALMOST started a thread to house this discussion several times... but I have wanted to catch up a bit more first.

I am HIGHLY INTERESTED in pursuing this line of research with everyone here who is also interested.  But my plan is to approach it differently.

I want to use a MUCH LARGER 1.5 inch piezo disc -- which is readily available very inexpensively from DigiKey -- and affix it to the end of a 1.5 inch tube -- which is a standard "under the sink" size that's readily available in steel and plastic from anyone neighborhood hardware store, and/or also online.

BUT the trick is that such a closed on one end and open on the other end solution will be HIGHLY DEPENDENT upon the wavelength of the sound and the length of the tube.  If the theory is correct -- and tantalizing bits such as that YouTube video suggest that it is -- we ought to be able to put the tube into "resonance", which should amplify the sound level unlike anything that any of us have yet experienced.  But that requires either tuning the LENGTH of the tube to find resonance with a fixed frequency... or adjusting the frequency to find the resonance of a fixed-length tube.

Since the second approach seems more practical -- especially if I can figure out a way for the processor to sense resonance (!) -- I've been putting that research work off until I have a uC tunable sine wave generator.

/Steve.

[Kyle Smith]

Steve,

Do you feel that the inner diameter of the tube should be some whole number fraction factor of lambda?  I ask, because my guess is that this is the case, and if so, we're locked into to a few discrete frequencies, once we've committed to a particular id of tube.  In which case, it would seem easier to tune the tubes length be means of a threaded union at one or both ends of the tube.  You've previously expressed the view that a sufficiently long, vis-a-vis, lambda, tube could be tuned by adjusting the position of the driver near the rear of the tube.  My thought here is that, why not fix the driver in place, and then use a threaded joint with end cap to facilitate the straight forward fine tuning of the placement of the driver, relative to the rear of the tube.

At 14080Hz, lambda is 0.96", assuming dry air, at STP, therefore, any fine tuning necessary could easily be achieved with this threaded technique of adjustment.  At some time along the path of development of organ pipes, one would think that formulae must have been developed to calculate the optimal diameter, total length, and offset from the bottom of the tube, in which to place the whistle slit.

Then, of course, you have come full circle, and you find yourself recreating the static mechanical dog whistle.  At which point, the question should be raised, of wether or not, it would be altogether simpler to attach a supply of compressed air to an existing dog whistle, and given sufficient pressure, one could achieve what ever SPL was required.  Although not at all directional, it should be easy enough for anyone handy with high pressure tubing to construct a savagely loud ultrasonic whistle, without the need to tune anything.

I'm not suggesting that this route be taken, but since these devices already are in existence, there is likely a body of scientific literature, complete with formulae, which may well be adapted for the use in precisely determining the dimensions for a resonant and highly directional chamber into which to place the efficient piezo electric tweeter.

Sorry, I have no citations for you, but perhaps I've provided a new category of research, that the group might find fruitful to dig up the seminal papers on the topic.

Best wishes,

--

Kyle Smith, MS, MD (retired)

air...@me.com

[Steve Gibson]

Hey Kyle...

Do you feel that the inner diameter of the tube should be some whole number fraction factor of lambda?

Not as far as I understand the theory of standing waves.  The only multiple that matters -- and it DOES matter absolutely -- is the LENGTH of the tube, not its diameter/radius/circumference.

http://www.acs.psu.edu/drussell/Demos/StandingWaves/StandingWaves.html

So we could either tune the frequency or the length.  But the diameter isn't critical.

/Steve.

[Mark Ping]

You've independently arrived at what Isaac Asimov called "The Eureka Phenomenon" -- I was lucky enough to read that essay in high school.  To this day I still get some of my best ideas in the shower or mowing the lawn.  (Though mp3 players + earbuds have left the shower as the only real time I'm idle.)

[Jon Katayanagi]

I was looking around on the web and found this...

http://www.diyaudio.com/forums/multi-way/96465-piezo-tweeter-dogs.html

[JohnB]

That looks interesting. have you checked it out? It appears to operate at frequencies much higher than the TQC threads think will work on dogs but it may be useful for other pest critters. All of the commercially available devices seem to be lacking in sound pressure (volume) and it isn't clear how this one might do. If there is a way to drop the frequency by about 8kHz and run it at 110db+ it would be promising device.

[mfuri...@gmail.com]

Hi Steve, I am very interested in purchasing one of these from you.  Have you decided to sell them yet?   Also, is this effective through floors and walls?

thanks,

Mike

On Saturday, January 12, 2013 4:30:09 PM UTC-6, Steve Gibson wrote:

R&D Progress Log #3 Anchor.

[kd5...@gmail.com]

Hi Steve,
Been following this for a long time. I realize you are working on Spinrite and the many current events that happen in the security world, so no rush on a reply. My canine woe's have continued and I found some time. So I downloaded the "Latest...zip" file. Looking at the diagram for TheAdjustableTrebleShooter-v1.2.png I purchased all the parts and the MSP-EXP430G2 LaunchPad. I downloaded and ran CCS and created a project. I couldn't find the .asm for v1.2 so I used the .asm for v0.5 which was in the "Latest...zip" file. When I try to build the project, it gets down to line 124 in the linker file (.reset) and says it won't fit in memory (see below). I've tried to set the optimization parameters for size, but it seems to make no difference. Any idea what CCS parameter(s) I could try to change to remove this error? Or what code change(s) could remove it? Or is there a v1.2 .asm file that could take care of this? I searched the group and couldn't find any .asm file for the adjustable treble shooter v1.2. The chip is an MSP430G2452. Any help will be greatly appreciated.
Regards,
Van

**** Build of configuration Debug for project TQC 20140301 1857 ****

"C:\\ti\\ccsv5\\utils\\bin\\gmake" -k all

'Building target: TQC 20140301 1857.out'

'Invoking: MSP430 Linker'

"C:/ti/ccsv5/tools/compiler/msp430_4.2.1/bin/cl430" -vmsp --abi=eabi -O4 --opt_for_speed=0 --advice:power="all" --symdebug:none --define=__MSP430G2452__ --diag_warning=225 --display_error_number --diag_wrap=off --printf_support=minimal -z -m"TQC 20140301 1857.map" --heap_size=80 --stack_size=80 -i"C:/ti/ccsv5/ccs_base/msp430/include" -i"C:/ti/ccsv5/tools/compiler/msp430_4.2.1/lib" -i"C:/ti/ccsv5/tools/compiler/msp430_4.2.1/include" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="TQC 20140301 1857_linkInfo.xml" --rom_model -o "TQC 20140301 1857.out"  "./main.obj" "./AdjustableTrebleShooter-v0.5.obj" "../lnk_msp430g2452.cmd" -l"libc.a"

<Linking>

remark #10371-D: (ULP 1.1) Detected no uses of low power mode state changes using LPMx or _bis_SR_register() or __low_power_mode_x() in this project.

remark #10372-D: (ULP 4.1) Detected uninitialized Port 1 in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

remark #10372-D: (ULP 4.1) Detected uninitialized Port 2 in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

"../lnk_msp430g2452.cmd", line 124: error #10099-D: program will not fit into available memory.  placement with alignment fails for section ".reset" size 0x4 .  Available memory ranges:

>> Compilation failure

   RESET        size: 0x2          unused: 0x2          max hole: 0x2      

error #10010: errors encountered during linking; "TQC 20140301 1857.out" not built

gmake: *** [TQC 20140301 1857.out] Error 1

gmake: Target `all' not remade because of errors.

**** Build Finished ****

[Robot]

It seems that this project has died. The postings have stopped. No updates to the schematic that have been talked about. Posts about PCB boards but no more updates.

I hope I am missing something here or do I need to switch another group to stay current with this much needed project.
Anyone's help in getting me back on track here will be appreciated.

Rob

[Adam Leggo]

Rob

You are correct that the project has stopped. Steve is busy with sqrl, spinrite 6.1 and security now. He doesn't have time for this project.

I don't know when or if it will be restarted. It hasn't moved anywhere.

Regards
Adam

[Stephen Mroszczak]

I have a real problem with a couple of cats in our backyard...Does anyone know if any of the current designs in the .zip file works?  Anyone tried it against cats?

Regards,

-Steve

[lburr...@gmail.com]

Neat!