I'm a Network Engineer and a Ranger Enthusiast at your service!

[wowko]

I love wheeling my ranger. I also love working on and using computers in all facets of my life. I'm currently an out of work Network Engineer with a Bachelors of Science, and would love to help anyone on here with their PC and other electronics issues! I live in Rhode Island, but most things i can help you do remotely without a problem!

I'm always open to helping people but as i said i am out of work, so if you email me and need some help and spend a few minutes or a few hours consider throwing me a few bucks on paypal to fund my wheeling adventures!

Ill get everything fixed in record time. and if you feel ive done a good job helping you out then throw me a couple bucks. if your unsatisfied then dont!

obviously im not asking for money for a two minute job!

email me at wowkomooth@gmail.com or message me on here.

 

[Psychopete]

I am programming an AVR (ATMEGA32U4) to create an electronic drum set, but noticed that at times channel 0 would trigger when using channel 1 (8 analog to digital inputs).

My input would look something similar to:
Channel 1: 94
Channel 1: 255
Channel 1: 255
Channel 0: 128
Channel 1: 145
Channel 1: 93
Channel 0: 235
Channel 1: 43
Channel 1: 76
Channel 1: 34
Channel 1: 15
...

How my code is working on the AVR microprocessor (watered down, and probably won't compile):

while (1)
{

int read  = 0;

for (int i=0; i<MAX_NODES; i++)
{
    int16_t value = read_adc(i);

    if (value > 0)
    {
        write_usb_char((char *) i); // Write channel - Adding to Buffer
        write_usb_char((char *) value * .25); // Max 1024, scaling down to send as a byte per channel.
        read = 1;
    }
}

if (read)
{
    write_usb_char((char *) 255); // Channel 255 - My end of USB data
    flush_usb(); // Send to PC
}

}

I can work around this programmatically, but really I would like to know what I am doing wrong. I have played around with using an interrupt, but the way it works is not going to work as well as I think it would, but certainly something to spend some time on. I figure pooling at this point would be the way to go, not to mention easy to debug. The problem with using an interrupt is that there's isn't a good way to know which channel triggered the interrupt. Any of the channels will trigger the same global interrupt.

My circuit is a piezo installed into a practice pad, 1 megaohm resistor, and a diode that prevents the circuit from going "negative". The diode and megaohm resistor are hooked in parallel with the piezo.

What I think is happening is that I am accessing the adc too quickly (eg, I think i need to sleep between polling the adc). But let me know if you had any other thoughts as to why this would be happening. I can certainly fix it with software, but I would save a lot of headache if I could figure out why channel 0 would read intermittently when nothing was attached. It only spews out data when the piezo on channel 1 is "doing" anything. Otherwise it's quiet.

 

[Mark_88]

Can't remember too much about programming, but if your input drops to 0 then would it not revert to channel 0? You have a IF statement there that says if (value > 0) ...

Or are you trying to spam the spam? LOL

 

[Psychopete]

That's just saying if it sees any value from the analog to digital converter that's greater than 0 on the channel I am reading, then send the channel # and reading to the computer over USB. The readings I am getting are sane, so I don't think it's the driver I wrote - I am pretty sure it's a quirk in the hardware.

I am getting readings on channel 0 (0-based) when nothing is attached to it, and it's only when I actually have output from a piezo on another channel. I haven't gotten far enough to test beyond channel 1 though. I still need to modify the rest of the practice pads and build an enclosure for the electrical stuff, but I want to make sure it's going to work before going through the trouble. I have gotten it "semi-working", but just wasn't right.

I would pay him if he had an answer for me. He said he is verse in electronic issues!

 

[Mark_88]

That's just saying if it sees any value from the analog to digital converter that's greater than 0 on the channel I am reading, then send the channel # and reading to the computer over USB. The readings I am getting are sane, so I don't think it's the driver I wrote - I am pretty sure it's a quirk in the hardware.

Ah, now I know why I flunked that course...lol

I was way better at COBOL II/CICS...

I would pay him if he had an answer for me. He said he is verse in electronic issues!

True...and from what I recall programming was a big thing for the technician courses...

 

[wowko]

id probably have to physically be there to figure it out. not too sure. are they decent quality piezos? definitely seems to be hardware. ive spent hours coding around problems just to find ive mis-wired something. my only advice is to doublecheck all your joints, and if it still doesnt work try swapping the piezo for a known working one..see if you get better results

 

[TheTopher]

id probably have to physically be there to figure it out. not too sure. are they decent quality piezos? definitely seems to be hardware. ive spent hours coding around problems just to find ive mis-wired something. my only advice is to doublecheck all your joints, and if it still doesnt work try swapping the piezo for a known working one..see if you get better results

That's definitely "Remotely and in record time"...

 

[alwaysFlOoReD]

But..... he's real.

Richard

 

[Mark_88]

That's definitely "Remotely and in record time"...

LOL

But..... he's real.

Richard

Ah, so he appears to be...

We get so many solicitations sometimes it's hard to tell who is real and who is fake...

 

[Psychopete]

id probably have to physically be there to figure it out. not too sure. are they decent quality piezos? definitely seems to be hardware. ive spent hours coding around problems just to find ive mis-wired something. my only advice is to doublecheck all your joints, and if it still doesnt work try swapping the piezo for a known working one..see if you get better results

The ones I am going to use are cheap ones in the actual drum pads, but so far my testing has been done with Radio Shack brand piezos. I am 99.99% sure it's something in the hardware (plus I am a n00b when it comes to hardware/electronics, but I've been coding for a very long time), wasn't sure if you were familiar with analog/digital conversions and how that would work with the processor. Just really strange that it's "leaking" over like it is, but I am thinking it's gotta be some kind of timing issue.

Finally have some time to crack at it some more tonight. Going to look over the datasheet again and see if the problem isn't obvious and will try a short delay in-between switching and reading between the channels to see if it goes away. I believe there is only one ADC in the chip that does conversions for all 8 channels. I may play around with the interrupt, but I doubt I would have anything useful by the end of the night going that route.

Bad thing is a delay can make it or break it - any time I can get is crucial to response. A millisecond is a very long time in the context of how it will need to work. So I would hate to wait until "~3 consecutive reads" before finally sending off something to the PC.

Thanks for your thoughts though. Will keep updated and will likely give you something for you time.

 

[COPPERHEAD85]

Thanks Pete..........I have a headache after reading that.........

 

[Psychopete]

Thanks Pete..........I have a headache after reading that.........

Haha, this isn't nearly as bad as some of the stuff I have to deal with at work.


Been messing with the project a bunch over the past could of days. I went over a bunch of documentation and figured that the interrupt may be the way to go. Polling the ADC like I was ended up being not as efficient.

I am stuck on a bit of a problem with dealing with the values coming back, but I am sure the solution will hit sooner or later. I ended up switching to 8-bit resolution instead of 10-bit - I realized that the 10-bit resolution was not necessary and have some speed to gain with 8-bit. It also appears I can overclock the ADC frequency with slightly less accurate readings, which wouldn't be a deal breaker for this project.

So far it has been working the best so far as far as accuracy and speed, but I have a long way to go!

 

[Psychopete]

My original problem was that it's taking several micro seconds for the processor to "catch up" when switch ADC channels.

Using interrupts to read in the adc values, but I may try polling to see if I can get the channels to switch faster. "Just have to see" type of thing, but the interrupt seems to be working well.

Found a huge bug in my driver with using asynchronous I/O (non-blocking). The ONLY solution at that point was to create a separate thread with a sole purpose of doing a blocking read on the USB pipe. I did a test and measured probably about 25% of signals being processed before, now I am at 100% as far as I can tell. Some code has been offloaded into the driver also, so there is some slight performance to be had there. Still more to do here though.

Still working on the Piezo circuit. Right now it's a 5.1v zener diode on the sensor, into a 100k potentiometer (for keeping the signal tame), with a 1m ohm resistor to ground. This is by far the best I have come up with, but my dad is working on a better solution for me.

Snare and bass drum are working, hard to get time to work on this thing, but I spent most of the day assembling the bass drum trigger/circuit, programming, and was able to play something on it yesterday evening.