Wow! That was extremely thorough! I certainly owe you a beer!
So, what simulator were you using? Is that SPICE? I really need to get some experience with it. Sure saves a lot of time and effort.
I’m noting that the additional resistor mirrors the envelope detector design that you pointed to on Wikipedia.
I’m sure not looking forward to reworking that board again… this will be the third time. But once I’ve breadboarded the new values I’ll be a lot more confident in having something that works!
warcher1:
So, what simulator were you using? Is that SPICE? I really need to get some experience with it. Sure saves a lot of time and effort.
I used LTSpice, it's a free download and there's lots of tutorials on the WWW as to how to use it. Naturally it comes stocked with lots of Linear Tech parts/models but you can D/L and install others.
One thing I did notice was that you had an 1N914 diode in your schematic, and so I switched to it. While the sim didn’t point out any problems, I do know that the reverse breakdown voltage on that part is only 100V. A diode with a higher breakdown voltage would be my choice, something like a 1N4004 - 1N4007.
Let me offer up an idea. When I was looking for ways to detect an airsoft hit I really wanted something very simple and cheap. A switch of some sort would be ideal as any MCU can easily detect a switch closure (or opening) via it’s digital IO. Indeed there was one kid who made an AS hit detector using that concept. His idea was simple; a vertical plate suspended on a spring with a bunch of switches behind it. When hit the plate would compress/bend the spring and the plate would touch one or more of the switches. He used cheap “intrusion switches” but you could also make your own with a “bed of nails” behind the suspended plate. The backside of the plate would conductive and so the plate/nail would made a contact closure. His implementation of that idea didn’t quite work for me at it might for you. Seems you fling a fairly weighty (compared to AS) projectile and that might be enough to guarantee a contact closure for any hit.
Assuming you’ve gone too far down the present road to switch paths, I would like to see what you finally end up with. In particular any data you collect for envelope magnitudes and PW for whatever “bleed” resistor and cap you think is good. You’ve already used the Arduino as a low end DSO, when you end up where you end, up save the data for one or more hits and post it as a text file. That will stand in for a beer ! :mrgreen:
Lastly what are you using for the piezo ? Where did you get them and at what $$ ?
FWIW I’m not breaking out the champagne quite yet. There’s 2 discrepancies that bother me. First you said :
This is in addition to the usual 1m resistor across the piezo terminals. The additional components work to keep the piezo signal active and readable for about 300ms instead of the normal 20-30ms the raw signal would give.
I just don’t see how your existing circuitry would stretch a pulse from 30 ms into 300 ms. Secondly you also had measured envelope magnitudes of 870 - 1023 with the existing circuitry. If true then adding any “bleed” resistor may reduce those magnitudes too much. I guess you’ll see.
Yes, LTSpice has been on my radar to download and try out for a while now. But until today when you showed how it can be used in this simulation I didn’t realize I had any projects with practical application for it.
I have a pack of 1N4004’s hanging around but thought they would be overkill. Great! Yet another thing to rework on that board. Well, practice makes perfect! Sadly my solder workstation blew its ceramic element last weekend and I’m now working with a temporary Radio Shack replacement.
I am a little too far down the road to go the switch route. We are scheduled to show this project at two events prior to the Maker Faire, and maybe there will be more afterwards. So it needs to be very portable. In that respect I would like to minimize the moving parts (especially anything that can be affected by humidity.) That’s why I chose the piezos.
Frankly I think your work on this should be published somewhere. My initial impressions about piezo input were based on the tutorial on arduino.cc. That totally glosses over the detail we’ve gotten into here and gave me a false sense of security. Obviously it’s already published here… but I mean it should be a tutorial or reference model for general use. (The ABC diagrams pop to mind actually.)
I’m definitely happy to share anything I find regarding the envelope generated by the piezos. It’s too bad I didn’t save the console output of any of my initial tests.
I got the piezos from Amazon Marketplace. The seller is CB Gitty which is set up to sell supplies for cigar box guitar crafters. http://www.amazon.com/gp/product/B0076C … UTF8&psc=1. I’m finding the 20mm units fine for reading vibrations on a 9x9 inch plexiglas sheet. The seller has sent these out pretty promptly… I usually have them a week after ordering. The only issue I’ve had was that the leads are pretty delicate. One of my units lost both leads after some abuse during testing. It looks pretty easy to solder other leads on though.
It does hardly seem that a 47pf cap could extend the signal that long. Maybe I’m seeing the cumulative charge effect of all of the caps in the signal chain?
And yes, I totally expect that I’ll need to replace the 47pf caps with something beefier once I add that resistor.
warcher1:
I got the piezos from Amazon Marketplace. The seller is CB Gitty which is set up to sell supplies for cigar box guitar crafters. http://www.amazon.com/gp/product/B0076C … UTF8&psc=1. I’m finding the 20mm units fine for reading vibrations on a 9x9 inch plexiglas sheet. The seller has sent these out pretty promptly… I usually have them a week after ordering. The only issue I’ve had was that the leads are pretty delicate. One of my units lost both leads after some abuse during testing. It looks pretty easy to solder other leads on though.
Thx. Mounting them to about that size piece of Plexi is almost exactly my starting plan. Well, that and other sizes/shapes. Looking at the specs for the piezo I see it has a resonant frequency of 6.3 kHz, a tad lower than the 10 kHz I used in the last analysis but close enough to not matter. Ideally to get the maximum output from the piezo (?not sure if that really desired?) the plate would mechanically resonant at the same frequency as the piezo. Alas I don’t know how to compute the resonant frequency of a 9x9" Plexi plate. I’m sure such calcs can be found on the WWW.
As for altering the boards … let me state the obvious and suggest you use a solderless breadboard to gin up the new circuit, as you’ll probably be swapping in/out differing values for the “bleed” resistor and perhaps the detector cap. The frequencies and current levels involved are a well with that type of BB’s capabilities. Beats having to solder stuff.
It would be interesting to have you point Mark Mayhew towards this thread and see if he agrees with the analysis and proposed solution.
warcher1:
It does hardly seem that a 47pf cap could extend the signal that long. Maybe I’m seeing the cumulative charge effect of all of the caps in the signal chain?
Absolutely. But even then I think the best that happens is a tripling of that 47 pF to maybe 150 pF. Still not enough by a long shot. And while the model for the piezo output is very arbitrary and so likely to be different from reality, the model of the detector and the rest of the circuitry and it's cumulative time response should be very close to reality. That's why testing is still needed even with computer aids like Spice.
let me state the obvious and suggest you use a solderless breadboard
Sure, of course. I did that previously but didn’t test more than one target. It looked like it was working right so I moved that mockup to a prototype PCB. Specifically this one: http://www.amazon.com/gp/product/B0040Z … UTF8&psc=1.
Of course, I got one of the connections wrong so had to do some rework. And now I’ll need to swap those components out. Don’t worry, I’m just whining about causing myself extra work… plus the fact that my solder skills need some work makes it even more so. By the time I’m done with this project my rework skills will be up to par.
I will definitely be putting this together on a breadboard before committing it to solder.
It would be interesting to have you point Mark Mayhew towards this thread
I am planning on pointing Mark Mayhew over here. I got a pretty quick response from him when I reported the issue on his site but haven’t gotten a reply to any of my emails. I think they are probably going to his spam box for some reason.
Aaaah, the circuitry is a little different from how I envisioned (and modeled) it. I figured you had 12 piezos w/12 detector boards near the piezos. Those were then run through 10' of cat5 to the shield (or some interface board tied to the shield). What I think now seeing the pic, is that you have 12 piezo's whose outputs are run though cat5 cable to the board in the picture. That has 12 detectors whose outputs are wired to the shield. No *real* difference in what has been done model-wise. The 1 ohm wiring resistance in the model circuit was more a place holder than a real concern. Moving it to be btw the piezo and detector makes no difference.
Yes, you are correct. I thought it would be more durable if I put the envelope detector on the board as opposed to locating it on the target. I considered doing it the other way but didn’t think the 10’ of cat5 would make much of a difference in the piezo output.
The rest of the board is dedicated to driving the target LEDs. They are recovered from 110v LED light bulbs that died the sad death of being connected to a fader. They require 12 volts (the red and black wires in the lower left of the board). I use an Adafruit PWM board to drive a pair of Darlington Arrays to provide a nice interface for the LEDs. That works pretty well except it seems like the PWM board tends to latch on permanently if I send commands to it too quickly.
I’ll try to post a video of the 3 target panel that I’m testing right now. The LEDs side-light the plexi panels for the same effect you see on those flourescent menu boards at restaurants. It’s a nice effect.
Mixed results tonight. I breadboarded the envelope detector as spec’d in your last diagram (1N4004 diode, .01uf cap, 100k resistor). I decided to test with two channels for now. Unfortunately the reading with that was always 0. It didn’t seem to matter what resistor value I used I never got a reading. If I dropped the resistor I got 1023 when tapping the piezo and a trailing off of the signal even though I was reading the second mux channel. Here’s my trace:
Notice that after the signal breaks my threshold of 400 the system registers hits for all reads until the signal drops below 400. This means that every read is for the opposite port (i.e. target 1 or target 2.) It takes a little over 10 seconds for the charge to bleed off. I guess its interesting to see the values consistently drop on both ports. Its definitely not random readings were getting.
So, I guess the right value of resistor must be between 100k and 0. But even an 82 ohm resistor showed 0 on all of the reads.
Here’s a photo of the breadboard:
Not sure that helps because it’s hard to see and I didn’t show the connections to the mux. So, I guess don’t try to trace the circuit too hard. In that photo the resistor is out on the left channel and in on the second one. The rightmost channel isn’t being used.
Here’s a plot of the results. I am a little confused by a few things it shows. First is there no reading before piezo 0 reads 1023 ? I’d have guessed that there would be a period of time where it showed something > 400 but less than 1023. OTOH perhaps the sampling rate (~300 msec when both are sampled, 115 msec when only 1 channel is sampled) was too slow to catch it as this was a case where you just tapped the piezo with your finger or pencil or the like. I also note that the “false” reading on the un-hit piezo crosses the real reading. That’s odd. And lastly the decay for both detectors doesn’t look exponential, it looks more like a straight line. That’s not what I expected.
I think it should have a curve that looks more like this:
Perhaps the decay is that obtained by having the cap (in the detector) looking into a very very very high resistance but with a constant current leak. Hmmmm.
As for the bleed resistor … it’s to be expected that adding it reduces the sensitivity. What’s surprising (a bit) is that the piezo is as insensitive as it seems to be. Then again how would you rate the force of your test tap vs how hard it’ll be whacked by the filled ping pong ball ? As something to try you might get rid of the 1 Mohm resistor that I believe is in parallel with each piezo. See if this makes any difference at all. Meanwhile I’ll mull the results over.
You are correct that the 1m resistor was still across the piezo leads. This morning I tried without it and also without the 100k resistor still got all 0’s for the readings.
And just to make sure I had connections on the piezo leads I put the 1m back in (still with no 100k) and got readings that were quite different:
As far as I know the only thing I did was turn the system off for the night and come back to it this morning. But those are completely different results. This is with the .01uf cap and no drain resistor so I should have seen about 10 seconds of bleed on the second port. Instead I’ve got zero readings. Maybe I just need some coffee before I perform this test! Maybe I tapped a little harder on the piezo last night.
Let me make sure I’ve correctly understood the experiment you did. You have 2 piezos wired up to 2 detectors wired in the MUX shield. The code samples the 2 channels looking for any reading > 400. When that happens, it seems a hit is declared and some printouts are done to the serial monitor. For some reason, one channel continues to get prints even when the value gets below 400, the other channel stops printing out. For the experiment I called the 2 piezos 0 and 1 after the printouts of targetnum 0 and 1. I believe from the data you tapped piezo/target 0, the response on the other channel was due to this tap.
This AM you removed to 1M resistor and got all 0’s, not hits declared. Replacing it and repeating last nights test it looks like you got 1 sample at 1023 and then the rest were all 0’s or the print stopped for some reason.
Can you post the test code used so I can better understand what it’s doing ?
When things aren’t repeatable it’s hard to figure out what’s happening. Check the wiring for good connections, perhaps unplugging and replugging in components to ensure some really good connections. See if you can get repeatable results. If not perhaps it’s time to simplify and see if the experiment can be repeated. Remove piezo1 and see what happens. If the source of the false signal is the crosstalk as the Spice results seemed to show, it (the piezo 1 readings) should still be there. Or sample just the 1 channel and see if the tap gets semi-repeatable numbers. For the tests you might think about reducing what gets printed out so the loop runs faster. Perhaps just print the time and piezo reading with a comma in between so the output becomes a CSV file.
That the unhit channel was eventually larger (in ADC counts) than the hit channel is odd. It’s not just simple crosstalk. It appears as if there’s a leakage current involved. If that’s the case then perhaps the fact that one detector’s cap will be different from the other detectors might explain the “crossover” in the plot I made. An interesting test would be to wire a single piezo into 2 detectors (though with just one 1 M resistor across the piezo). Whatever voltage is put on the caps should be nearly the same (the diodes will be very close in their drop). The decays in each channel should ideally be the same, if every component were the same. Then swap 1 detectors cap with the other and repeat the tap test. If the decays were different in the first case, I’d hope the decay rate follows the cap when swapped, even if the tap doesn’t produce exactly the same input. That would prove one explanation. Another test would be to simply swap what MUX channels the 2 detectors go into (leaving the caps as they were originally). That would tend to show what effect the MUX is having on the decay rates.
For the 2 MUX channels you used, was the same Arduino input pin used for both channels or were they different pins ? Bypassing the MUX and wiring the detector(s) into the Arduino directly would be another interesting test. This would show if the MUX was injecting any leakage current into the circuitry.
If you can get to a setup where what you think are repeatable taps are getting you repeatable results, you might want to vary the force of the tap just to see how sensitive the piezo is to the force applied. It also occurs to me that with a 10 sec decay time, you might be able to put a DVM on the detector output and get an idea as to the peak voltage put on the cap. While the plot I made makes it appear the 1023 is just exactly the correct value (and not saturated) I have to wonder if that will always be the case.
I’d hate to think the only way to solve this is to put an op-amp into every detector. But if the root cause isn’t obvious after a few tests that may be the expedient route to go.
BTW given how one channels piezo response is showing up on other channels, how sure are you that the piezo you’re hitting is really on the channel you think it is ? To be absolutely sure I’d ground the 2 channels you’re using via a 10k or so resistor and verify each reads near 0 counts. The use that same 10k to connect 3.3V into one, and then the other, channel and verify the counts read as expected. There should be 3.3V on the shield power header, it’s the pin between the 5V and reset.
Yes, I’m a little concerned at seeing a different result like that. Consistency is good when you’re testing like this. I can only say there must have been something different in my setup.
I think I may have confused you about what the sketch is doing right now. What is happening now is that I start by setting the max number of targets. This week I’ve been setting that to 3… but last night I reduced it to 2 for the breadboard circuit. The sketch then activates the first target (port 0). By ‘activate’ I mean it lights up the LEDs and reads the piezo on that target. It continues to read that piezo until it detects a hit (meaning that the MUX port value exceeds the threshold value of 400.) When that happens it flashes the target LEDs and activates the next target in the chain (in this case port 1.)
At this point the sketch is only reading the piezo on the activated target. It does not read any of the other ports.
So, what you saw from last night is that port 0 was scanned until it got a hit and registered 1023. Then the script switched to read port 2… however the crosstalk effect showed that port with a value of 850 which is higher than the threshold. So that target registered a hit and the sketch moved back to read the first target again. The targets kept alternating until the leakage dropped the value below the threshold… and then the sketch just kept reading the one target.
This morning I used the same sketch. So when I tapped the piezo the first port registered 1023. But when the sketch started scanning the second port it showed 0… indicating no crosstalk. There were other reads after that but I didn’t post them because they were all for the second port and were all 0’s. I would guess that if I had continued reading the first port we would have seen the same cap leakage going on. But in this case it looks as if the cross-talk just magically disappeared.
I hope that clears that up. I’ll post the code tonight… I don’t have access to it right now.
For the 2 MUX channels you used, was the same Arduino input pin used
Yes. They were port 0 and 1 on the 3rd mux chip, and therefore would have been read from the same arduino adc.
Check the wiring for good connections
The piezo leads are hard to get a good connection on so I’ve been checking and double-checking their connectivity during the tests. I may have to alligator clip them. But if there wasn’t a good connection we wouldn’t have gotten any read on the tests this morning.
how sure are you that the piezo you’re hitting is really on the channel you think it is
Positive. I’ll take a better photo tonight that includes the connection to the mux board.
FYI… I just got a note from Mark Mayhew. He is out of the country right now with spotty internet access. But he is now aware of this thread and is on board with the description of the issue. He also thinks it’s awesome that it has been modeled. He has no additional suggestions for a solution but believes the issue will turn out to be either the interaction between my discrete components and channels, or the high impedence of the piezo. He also suggested that we may need to include an op amp in the circuit to adress the output impedence.
warcher1:
He also suggested that we may need to include an op amp in the circuit to adress the output impedence.
Yup, there's a lot of good that goes with an op-amp. It can present a high resistance to the piezo so as to maximize it's sensitivty. And if that gets too high, it can be tamed independant of the rest of the circuit. It can allow you to tune the decay time and so stretch the hit to cover a slow polling rate. Or allow you to have a fast decay so quick back-to-back hits can be distinguished. It drives the MUX and Arduino with a low resistance output so the crosstalk issue goes away as would any need for dummy or toss-away reads of the ADC. It's just more board space, circuit and wiring complexity and $$s.
Perhaps a 2 pronged approach is a good idea. I’ll see if I can’t quickly come up with a fair op-amp design and “prove” it via LTSpice and if testing doesn’t reveal some other easy and quick way to fix what you’ve been seeing, the fall back plan will be ready.