Wow, and I thought I was meticulous when explaining things. Well, it was not in vain, I read through everything.

In a nutshell, I didn't know you were intending to read multiple swipes quickly in order to simulate multiple button presses. Now the multiple timers and if statements make more sense. I think you went just a bit farther with the software operation in your first iteration than I would have expected. Not that this is bad, especially considering your background, but I would strongly suggest starting with a much simpler program like your 02 revision (sorry, I have not studied it in detail yet) for the beta testing. Once proven, we can then move to your original version with multiple swipe detection.

Note the PICAXE uses a bootloader and it is sloooww. I see how you're thinking and wholeheartedly agree with your logic in your coding for microcontrollers in general. The PICAXE typically runs at a slower pace, so much so that it cannot reliably generate its own clock signal for a simple clock display and keep accurate time if you need to do anything else like read buttons. This isn't to say toss away your considerations, just don't be surprised if the PICAXE cannot react as fast as you're planning for. We can of course increase the clock speed to 32MHz for a 14M2 or swap it with a X2 part capable of 64MHz if needed or use interrupts if that happens to give us an advantage, so there are options to explore.

I've taken another quick look at the AT42QT1070 breakout board you mentioned. According to the description, only one contact will be detected at any one time. I assume this means it is impossible to touch two or more contacts (touch sensors) and have more than one output triggered. If this is true, we might save some complexity by looking for the second touch sensor as soon as the first is detected since, in theory, only one output can be on at any one time. This saves us having to look to see if the first sensor was released. Not that it wouldn't be good practice to verify the first sensor was released before looking for the second, but this might save valuable processing time in detecting the sensors quickly. I wouldn't change anything right now, just something to keep in mind if we need to speed up detection.

Yes, the size and placement of the touch sensors will have a large impact on performance. For testing purposes, I might suggest you attached two bare wires a couple of inches long to a piece of wood or plastic at a distance of your choosing so they are laid out like guitar strings but flush against the material. Then attach the wires to the breakout board and strum away to "see" how fast the LEDs react. Alternately, you could add buzzers to the outputs to better "hear" how fast the sensors detect. Once that is working to satisfaction, I think we can move to a circuit and a simple program to test basic operation. Once proven, we can move to multiple swipe detection.

The actual size and placement of the final touch sensors will be another task, but the above should allow us a proof of concept design to be sure the circuit and software are able to do what you intend.

Yes, lots of people will view the thread without commenting. Some are simply curious about the subject title, others may be checking in periodically to see if they have another idea that may help as the posts develop. Having a lot of responders is good and bad. On one hand, you'll get a lot of different ideas on how to tackle your problem which can be insightful, on the other hand, you'll get a lot of different ideas on how to tackle your problem which could be overwhelming. This is not to say my suggestion of using a PICAXE will be ideal in the end - you may find it to be too slow, but you can always move to a PIC or something similar if that becomes the case.

 

Thanks for going through it all. I know I went pretty low-level, but some of it was me talking to myself. Actually, I was pretty pleased to see that upon close inspection, the code that I wrote in my head was pretty tight, and didn't need any modification (self-pat-on-back)

Yeah, the chip speed may be an issue. Going to 32Mhz I'd imagine would be enough. I think a complete code loop duration at anything sub-millisecond would be sufficient, and 32Mhz internal speed would certainly be able to do that, no? The way to tell would be to get the entire set of code looping and generating an output signal at each loop, then hooking up a scope. I might do that. We'll see if it just works first.

As for the one-switch-at-a-time limits of the AT42QT1070, the heavy-handed solution is just to use two of them, one per strip. Well, one to handle "strip1" of both pairs, and the other to handle "strip2" of both pairs. So each module would run two in total, but for each module those two are programmatically and physically separated.

I'm going to have to order a PICAXE to find out about all this, I guess. Once I have that, I can start to look into how to physically configure the sensor strips. The 14 model seems adequate without being overkill. Just to confirm - which variant would you recommend? There's pluses, and x2s and what-not. I think you mentioned the 14M2, and I looked at it, and it seems right.

And I suppose I should order a three-pin socket that I can add to my project board, so that I can upload the program(s). What else? I see kits like the "PICAXE-14 Starter Pack", which seems to have a) a battery clip that I don't need, b) a CD with software and docs that I could just download, c) a small board I could make myself, and d) a USB-miniphono cable.

The cable is the only thing that I think I really need, other than the chip. I have at least one spare FTDI cable around, and I might try this: http://letsmakerobots.com/node/19013 or something similar. I'd prefer to use a three-pin header on my project board to save space, and a homemade USB- or miniphono- to 3pin adapter is pretty easy. Or I might get lazy and just order a pre-made one with the microcontroller. Thoughts on all that please?

Oh, and for the output side of the assembly - the actual replacement for the SPST momentary switches (program 1). You suggested MOSFETs. I have several BS170s at home - have to see if they're the small-signal versions. While I like the simplicity, I wonder about whether MOSFETs are the most bulletproof solution for this. I suppose I'd have to have a pulldown resistor between the PIC output and the FET gate? And maybe another resistor in series, for some load for the PICAXE? And then there's the problem that the schematic doesn't actually say what current or voltage is getting grounded by those switches. I could assume 7V, and I could assume miniscule voltages, but I can't be sure. I worry because, won't the MOSFET possibly misbehave if the voltage is too high? And I just don't know what it's Roff would be, in consideration of the unknowable sensitivity of the synthesizer on the other end. I think maybe I could instead just take the "safe way" for a couple bucks, and use a dual bilateral IC normally-open SPST with low Ron in a DIP package. I found ADG511, MAX323, MAX4544, MAX4590, MAX4608.

I'm thinking we have worked through a long ways at the conceptual level, and in order to make much more substantive progress, I'm gonna have to start building soon. Please let me know of your hardware recommendations.

 

BTW - $3.50 for the microcontroller, and $25 the USB-phonomini cable! HOw much outta whack is that!? Seriously, I've got to get into the cable-making business. I could make mine with unobtanium or adamantium or neutronium, and charge even more.

 

As for the one-switch-at-a-time limits of the AT42QT1070, the heavy-handed solution is just to use two of them, one per strip. Well, one to handle "strip1" of both pairs, and the other to handle "strip2" of both pairs. So each module would run two in total, but for each module those two are programmatically and physically separated.

Would the same hand be used for both sets of strips? My question being if only one hand is will be used to trigger the strips, then in theory one board should be enough since you won't be using multiple fingers on one hand to make swipes across both sets of sensors (or will you?).

Yeah, the chip speed may be an issue. Going to 32Mhz I'd imagine would be enough. I think a complete code loop duration at anything sub-millisecond would be sufficient, and 32Mhz internal speed would certainly be able to do that, no? The way to tell would be to get the entire set of code looping and generating an output signal at each loop, then hooking up a scope. I might do that. We'll see if it just works first.

I'm not sure, as I mentioned, trying to get an accurate clock using 1Hz from the PICAXE was next to impossible, so I worry about sub-millisecond timing and reaction. But I agree, ain't gonna hurt to try it first.

The 14 model seems adequate without being overkill. Just to confirm - which variant would you recommend? There's pluses, and x2s and what-not. I think you mentioned the 14M2, and I looked at it, and it seems right.

Yup, just the defacto 14M2. I don't think it comes in pluses, but if you find one, post the link and I'll look into it. The X2 versions are faster, but more expensive.

And I suppose I should order a three-pin socket that I can add to my project board, so that I can upload the program(s). What else? I see kits like the "PICAXE-14 Starter Pack", which seems to have a) a battery clip that I don't need, b) a CD with software and docs that I could just download, c) a small board I could make myself, and d) a USB-miniphono cable.

Nah, all you need is a breadboard, a CP2102 module such as this or this, and an inverter such as the 74LS14 or a pair of BJT NPN transistors with some resistors. Altogether, you shouldn't have to spend $10 if that. Yeah, you can spend a lot on a simple cable which is why I like the options above better. If you already have a 5V FTDI cable, all you need is an inverter or you can invert the signals in software as shown in the link you provided. In any event, getting a 3-pin connection to program is easy, although you may want a fourth pin to read data back to PC to debug.

Oh, and for the output side of the assembly - the actual replacement for the SPST momentary switches (program 1). You suggested MOSFETs. I have several BS170s at home - have to see if they're the small-signal versions. While I like the simplicity, I wonder about whether MOSFETs are the most bulletproof solution for this. I suppose I'd have to have a pulldown resistor between the PIC output and the FET gate? And maybe another resistor in series, for some load for the PICAXE? And then there's the problem that the schematic doesn't actually say what current or voltage is getting grounded by those switches. I could assume 7V, and I could assume miniscule voltages, but I can't be sure. I worry because, won't the MOSFET possibly misbehave if the voltage is too high? And I just don't know what it's Roff would be, in consideration of the unknowable sensitivity of the synthesizer on the other end. I think maybe I could instead just take the "safe way" for a couple bucks, and use a dual bilateral IC normally-open SPST with low Ron in a DIP package. I found ADG511, MAX323, MAX4544, MAX4590, MAX4608.

You can keep the outputs of the PICAXE latched so the MOSFETs remain off. The only time this becomes an issue is at power-up. If this is critical, then pull-downs can be added.

With a logic-level MOSFET, you simply apply 5VDC at the gate to control 10-50V at the source-drain depending on the rating of the MOSFET. I can't imagine your switches draw much in the way of power, but you can hook up an ammeter in series with one side of a switch and measure the current when the switch is pressed to be sure.

MOSFETs have some capacitance across the gate, so adding a resistor helps speed things up if you need to switch rapidly - a high PWM signal for example. For this case, you shouldn't need one, but you could use a 100Ω if you'd like.

You can also check the voltage across the switch with a meter with the switch open to see what the voltage across the MOSFET could be. What is the highest voltage going into the synthesizer?

However, if you'd prefer, using a switch would work fine, although you'll still want to know the current and voltage going across the switch as these devices usually aren't rated for much (I think).

I'll try to post a full schematic tomorrow.

 

Hi again. Thanks for the feedback on the hardware!

I dug up one FTDI cable. I think the Mouser part number was 895-TTL-232RGVSW5VWE. I have the datasheet (attached), but I haven't gone thru it yet. My guess at first glance?... it might work.

My head is reeling from the speeds you imply for the PICAXE. I can't conceive of how a chip running an internal clock at 32Mhz could possibly get stalled trying to produce 1Hz output. Great Caesar's ghost, that's abacus speed! And that doesn't jive with having 'pause' commands being in increments of milliseconds. I must have read you wrong. When I mentioned that I'd like to be able to loop through the entire code sequence at once per millisecond, I thought I was being way too ridiculously generous. So all I can say is.... HUH?

I think we may have one tiny disconnect left on the manual/physical operation of the project. So I make a couple more pictures.

Picture '0' shows the guitar, with the control knobs showing in what will be their actual locations, and with the underlying cavity (accessed from the back) outlined with the dotted black line. One pair of associated capacitive touch sensor strips is indicated with red strips, and the other set with blue strips. Which is which per program1/program2 is immaterial. Remember, these are actually underneath the laminate surface of the guitar, hidden.

Picture '1' shows a hand swiping multiple fingers across one pair of sensor strips (a la Program1). This action is what I referred to as "strumming", to use a term that was familiar to me - sorry if it was misleading - it has nothing to do with strings. See how the fingers will pass in sequence over one strip and then the other? See how, depending on finger and strip spacing, a second "program swipe" could be initialized before the first one was terminated? The bi-directional arrow is simply meant to show that a swipe or strum could go in either direction, NOT that the user is expected to be waving their hand back and forth.

Picture '2' shows a hand swiping a single finger (a la Program2), across the other pair of sensor strips. The diagram shows the "active swiping area" of the two pairs of strips are pretty well separated, largely mutually exclusive. But I may end up trying to get them closer together. One thing that will remain is the almost-perpendicular orientation difference between the two pairs' effective swiping directions - it should be pretty hard (a good thing) for the user to swipe the wrong set by mistake.

Yeah, the hands are in different orientations. Makes comparing pictures a bit strange. It just worked better pictorially. I've fiddled around with my guitars, and it's all comfortable from a normal playing position.

If you already had this picture in mind, sorry for bringing it up. But if not, then I hope this helped.

I'll be shopping online tonite for PICAXEs and associated miscellanea. Any recommended vendors?

 

... and in case you want to know what the heck this is all for, the synthesizer is a Roland GR-55. Here's a couple of YouTube videos. The playing you hear includes some "backing tracks", pretty much just drums. Most of what you hear is coming from the guitar and synth. Pretty cool. And lotsa fun!

Here are the videos.

Demo of a lotta pop songs, multiple instrument sounds. Feel free to skip past the heavy metal parts, like I do.
https://www.youtube.com/watch?v=tmsio4QHJuI&list=PLYzbITpTaBDfPRjhmx1Dxu0vubzu5UEa-&index=6

Piano simulation only:
https://www.youtube.com/watch?v=YqKZYUExYCs&list=PLYzbITpTaBDfPRjhmx1Dxu0vubzu5UEa-&index=7

Demo at a music trade show. Skip the first 2 minutes
https://www.youtube.com/watch?v=4h_5Zx55ong&list=RDFvRe24a4A1E


You see in the first video quick flashes of the synth as it changes settings. This is what program1 swipes could do. He's doing it by stomping on switches with his feet. The swipe functions could be alternatively be remapped to change parameters of the sounds, like echo on/off or stuff like that. If you look close, you can see the switches I'm replacing installed in the guitar face. And trust me, he's using them a fair bit, it's just that the video's edited so that monkeying around doesn't show.

 

One more. This one's pretty good
https://www.youtube.com/watch?v=7-3SDAbJA00

 

I dug up one FTDI cable. I think the Mouser part number was 895-TTL-232RGVSW5VWE. I have the datasheet (attached), but I haven't gone thru it yet. My guess at first glance?... it might work.

Yes, that should work. I have a similar one with a 0.1" female header on it in both 5V and 3.3V flavors and both worked fine. Connections shown on schematic below. There is a small possibility I messed up - if you can't download, reverse the RXD and TXD connections (from the FTDI cable to the rest of the circuit).

My head is reeling from the speeds you imply for the PICAXE. I can't conceive of how a chip running an internal clock at 32Mhz could possibly get stalled trying to produce 1Hz output.

I'm sorry, I'm not explaining it well. The PICAXE can certainly produce a 1Hz or much, much faster pulse, it simply has trouble trying to execute a bunch of tasks in rapid succession and maintain an accurate clock. I attempted to have the PICAXE keep time while constantly updating a 4-digit display through a display driver IC and look for and act on multiple button presses at the same time. Didn't work, but adding an external 1Hz clock and using interrupts fixed this. For your application, I don't think you'll have a problem, but I wanted to mention it in case there is an issue related to rapid response.

I think we may have one tiny disconnect left on the manual/physical operation of the project. So I make a couple more pictures.

Yes, and I think this is the piece:

See how, depending on finger and strip spacing, a second "program swipe" could be initialized before the first one was terminated?

Now I think I fully understand your four timers and if statements - it is possible 1-3 (4?) fingers trip the first sensor 1-3 times before the second sensor is tripped once. And yes, the pictures helped, thank you.

In theory, if the sensors are thin enough and close enough together, could you set it up so that one finger always trips both sensors before there is a chance the next finger triggers the first sensor? This might make the program simpler by only requiring you perform a count and timeout with each completion of a swipe. Just a thought - I imagine this would be tricky to do.

I'll be shopping online tonite for PICAXEs and associated miscellanea. Any recommended vendors?

There are a handful in the U.S. and Canada, but I think PH Anderson is a good bet. The prices are good and the shipping should be as well. Alternately there's Sparkfun who offers free shipping if you spend $75 (I think) or more.

Neat videos. So the synth allows you to use the guitar to get different sounds out of it? Cool beans. I love the variety of projects one can apply electronics to.

 

Hey, thanks for the updated schematic.

I thought I had some LM317Ls lying around, but none left. I'll be heading out in the morning to pick up a couple. I'm not 100% confident in the software inverting for my FTDI cable, so I thought I'd grab an inverter while I was out. Local electronics supply sources 'round here are not good. Apparently no MC74HC14s in stock. I can get OnSemi 4069 or TI 4009, which I suspect both might work. I'll probably pick up one or two of both - they're only 50cents ea..

Of course, I'll soon be online ordering my IC switches anyway, so I can get all the good stuff then.

And I found an in-town distributor for the PICAXE! So I'll grab one or two of real soon, and then I can start to get the serial comm cobbled together.

I got home late tonite, but wanted to get the capacitive touch sensor physical configuration spec'd out.... then found I had no 5V reg and no (living) small batteries. I have some 9Vs and even a couple little Pololu units and lying about, but only 9V regs and step-ups. Alas, no proper 5V tonite. Tomorrow. But tonite I'll work up the sensor strips and ground plane. Easy peasey.

But I still have to figure out what's wrong with my Programing Editor. I'm gonna get the FTDI installed, config a COM port, uninstall the IDE and install it again. Wish me luck.

 

I uninstalled the Program Editor, updated the FTDI cable and configure a COM for it, re-installed the Program Editor in a new location. All good!

I got all the syntax right on both programs. Had to laugh... the IDE is not much help with that. Pretty much just "you gotta problem here". But it's all ironed out.

It was a little buggy until I realized that my single-byte variables "overflowed" into the range where I started my word-sized variables. Fixing that cleared up some strange behavior.

Ran simulations on both programs. Program 2 worked almost right away, needed another (!!) IF statement. Made that change in Program 1 too, but getting it off the ground was a little tougher, as I had to add in a way to ensure that a closed sensor strip didn't trigger a "pin high" more than once. Not that it'd really hurt to set it high over and over, but it was messy so I fixed it.

At least now you can sim it yourself, hit the pins C.0 and C.1, watch the variables change and the outputs get generated. Please let me know if you find any bugs. Of course, it'll all fall apart when it gets used in real life, but that's just part of the development cycle.

Cheers

 

I loaded program 2 and ran the simulator - I didn't play with it for long, but it seems to simulate fine.

For a 5V source, you could use an old cellphone charger. Anything with an output of 3V - 5VDC should work. If you have an old charger with a USB cable you're set.

You could also use a 3x AA battery holder if you have one handy.

The LM317 will work, but you'll need resistors to set the output voltage. For 5V, a 7805 works well and are usually cheap.

A CD4069 is common and should work in place of a 74LS14.

 

Hi

Sorry for the absence. Things get busy, you know? Bt today I got busy again on the project.

Previously I'd mounted two of the capacitive touch controllers, and rigged up some sensor strips. The controllers have small LEDs on them, so I could test it out just like that. I did go for a pair of them, because the one-switch-at-a-time constraint was going to get in the way of trying to detect swipes. As it turns out, the capacitance of the bulk of my hand, which is further from the surface, seems to dominate the capacitance of my finger, even though it's closer to the surface. So just one controller was just picking up my hand, and wasn't differentiating well the motion from one sensor to the other. Instead, the first one would trigger, then even though I'd move my finger/hand across to the other, the first one would "lock out" the other. But two controllers fixes that.

I found some small wood pieces lying around that I've used for testing sensitivity. Oh, by the way, the "guard" channel thing really isn't going to work here either. Because the "guard channel" seems to act just like another switch. So if I have a large guard, it triggers early, and locks out everything else! Maybe I'm using it wrong. It seemed like a good idea. I'll keep trying with that.

As I'd planned to have a huge guard, I'd also envisioned small sensors. But they have a harder time working through the wood. Apparently, without any guard, the sensor sensitivity is just size-dependent. Bigger is better. Although there's probably a practical limit to that. I did try a couple different sizes, but the larger ones worked better - more reliably. And as I have two controllers now, the larger size doesn't introduce any detriment to differentiating one sensor from the other.

The wood block seem not to be an impediment for the sensors. Yaay!! They detect my finger/hand through the wood just fine. It does introduce some "blurring" or "fuzziness" in their ability to detect me, but still as I swipe perpendicularly across them, they trigger nicely in the right order. But weirdly, the wood seems to have some capacitance of its own. Or something like it. I know ... "huh"? But if the controllers are turned on, then I put the wood blocks over the sensors, they trigger, and stay on. It seems to work a lot better though, if I have the controllers off, then place the wood, then wait, then turn them on. Better, but still some spurious/random triggering. It works best if, after placing the wood, I wait a while, then turn the controllers on. Why should that make a difference? I honestly have no idea.

Today, I got the inverter and the PCIAXE on breadboards. And finished rigging my FTDI cable. Checked, re-checked. But the software couldn't find the hardware. I looked, and looked, and looked... and finally found my rookie mistake. I forgot the ground wire from the FTDI to the board. Curse. Plug in. Tadaa. Sigh.

I plugged in a couple of LEDs, so I could see the PICAXE working, and increased the pin-high/pin-lo pause time (to 50), so they would stay on long enough for me to see better. It works pretty much. I have some unforeseen and as-yet unknown fail in the program tough, because it isn't doing swipe after swipe well. There's some triggering of swipes in the opposite direction. Yes, even with all those "if"s in there, there's still a way for the thing to trigger falsely. But I'll track that down.

Attached is a pic of the rig. I have two 5V regulators there, only because I had done the two boards separately at first, and was too lazy to unplug one and chain them together. The two sensors that are connected are the ones that work best while still being small. The "ruler" at the bottom was to keep me oriented when the sensors were covered by the wood. A sample of bigger and smaller sensors are also shown, unconnected. One of the wood blocks also shown. And the FTDI cable.

Will let you know when I can get the program more solid. Hopefully tomorrow night.

 

You might be seeing some stray capacitance from the breadboard and/or table surface. Not much you can do about the breadboard until you move to a PCB, but you might try moving the sensors so they are floating in space, so to speak to see if that helps.

I noticed a big difference when I had my power supply grounded (not a problem here since you are using a battery) or when my PICAXE cable was connected to the PC. I'd suggest making sure the PICAXE cable to the computer is disconnected whenever you do your testing.

Interesting stuff on detecting your hand and less so on your finger. Sounds like it is almost too sensitive. When I used the PICAXE touch sensor function, I didn't see much change when my finger was right next to the sensor, but I did see a big change as soon as my finger was actually touching the sensor. You may considering giving this a shot as a backup plan.

Can't wait to hear, er, read about your next results.