Go Down

Topic: Cap sense advice please! (Read 5400 times) previous topic - next topic

TonyWilk

@TonyWilk - I like what you have done with adding that noise inducing track. Have you tried putting a high frequency signal on it. I would modify the speed of one of the PWM timers and put something like a 40KHz signal on it. *snip*
No I havn't tried any waveform on the 'driving' track - at first I just tried wiggling the pin HIGH/LOW and noticed one channel had much higher signal than the other, what I'd done was something like:

Code: [Select]
digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );
digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );
a0= analogRead( A0 )
digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );
digitalWrite( pin, HIGH );
a1= analogRead( A1 )


where a1 had a much higher signal... "ah, 'tis the rising edge we're coupling in" thought I, and that was good enough for the test, the code I posted earlier never changed after that.

Nice idea with the PWM, maybe set it for 25/75 or something - however there's still going to be that pretty small interval where the ADC is capturing the input, but if you can couple in a shift in the dc level on 100pf or so... yeh, I can see that... Let us know how it turns out.


Yours,
  TonyWilk


Grumpy_Mike

At least try:-
Code: [Select]

a0= analogRead( A0 );
digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );
digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );

a0= analogRead( A0 );
a1= analogRead( A1 );

digitalWrite( pin, HIGH );
digitalWrite( pin, LOW );
digitalWrite( pin, HIGH );

a1= analogRead( A1 );


You might get better results as the A/D's input channel is switched first to the channel you want to read so the sample an hold capacitor can charge up with the disturbance signal.

GreyArea

You boys are seriously leaving me behind...

@GrumpyMike
Sorry if what I'm doing isn't capacitive sensing and yes I'm using the library. Wanted to post code last night but at 9000 lines, couldn't.

@TonyWilks
Can't say how chuffed I am that you've done so much work on my mad idea.

Now then...much to my shame and my partner's annoyance I was up until 4am trying to find the bug. Or bugs, as it turned out. First, "not equal" should be "!=" and not as I had typed in multiple places "/=". Helllooo madly switching negative numbers...

Then I noticed that because I'd got confused in my switch...case statements for the "old" and "new" states, I was turning LEDs off when I should have been turning them on and vice versa...but...

https://youtu.be/0bS3CqB_9hs

You may applaud. If it fits on my nano trinket, I shall expect a standing ovation.

Just kidding, but for only my second project and no real knowledge of microelectronics I'm amazed it works at all...

Lemme know how I can zip or otherwise post the code if you're interested...but be gentle, like I said I'm a novice. If you think the programming is rough, you should see my soldering.

GreyArea

#33
Dec 21, 2017, 11:19 am Last Edit: Dec 21, 2017, 12:19 pm by GreyArea
Well...even my hugely bloated, "verbose enabled" code does in fact fit on my Pro Trinket 5v...it runs, but it's not as reliable as on the Mega...I'm getting "flicker" which I've learned is a sure sign of insufficient differentiation between states.

My code accurately and certainly identifies "state 1" (no sensors) and state 2 and 4 (full signal to sensor one and sensor 2)...but it's that "state 3" (finger on both contacts) that is the pain.

To go from the Mega to the trinket, I've had to switch from using pins (2 and 4) and (6 and 4) to using pins (3 and 4) and (6 and 4). I'm thinking this may not be wise as having the sensor so close to the reference may cause interference.

I've read you can use the analog pins...would it be possible to keep pin 6 as the reference and use the analog pins (on the other side of the Trinket) as sensors to maximise physical separation...

...@Grumpy_Mike, I can hear you grumbling about breadboards from here...I know...remove the long wires and solder everything and a lot of the problems go away. There's a reason I don't solder much - I have Parkinson's, so bear with me...

...but something tells me mixing digital and analog like that is not wise.

What are the BEST pins to use for capacitive sensing (again my apologies if that's not what I'm doing - insert correct terminology here!) and are there some that should be avoided at all costs?

Thanks again!

GreyArea

@GreyArea - What you are doing is not capacitave sensing and I suspect that you are using the cap sense libiary. What you are doing is what was suggested by Paul at the end of reply #1. See what I mean about reliability?
Honestly, I've no idea what I'm doing. Yes,it uses the capacitive sensor library.

I went back and read Paul's answer. I've already confirmed it works well enough on battery power...but if Paul is right, does that mean that this is unlikely to work outdoors?

@TonyWilks - regarding the variation in calbration and actual sensing steps; the part I don't understand is that because I'm using the capacitive sensing library, the calls and methods I'm using to the two sensor channels are EXACTLY the same.

I actually added in a "multisample" ("m") parameter and sent the read command to the sensor pin "m" times and took an average, thinking that might stabilise it (at the expense of some speed). Doesn't seem to make a lot of difference if I'm honest, but it has made me think...

Currently I'm assessing static values of the two sensors; the ratio of one to the other and then the relative strength compared to the calibration stage.

This is is fine for when either sensor 1 or sensor 2 has full contact...but I was wondering whether I should actually be looking at rate of change as well? Though the physical "minimum, average and maximum" values of the sensor channels do seem to drift as time goes on...the rate of change appears pretty constant (as the graph I posted shows).

It's entirely because the non-linear arrangement of the contacts I've created only permits a certain pattern of changes;

* Moving a finger from a blank area to sensor 1 results in sensor 1 rising fast and sensor 2 not moving (much)
* Moving a finger from sensor 1 to sensor 2 results in sensor 1 falling and sensor 2 rising
* Moving a finger from sensor 2 to the blank area again results in sensor 2 falling and sensor 1 not moving much.

Going in the opposite direction

* Moving a finger from a blank are to sensor 2 results in sensor 2 rising fast and sensor 1 not moving (much)
* Moving a finger from sensor 2 to sensor 1 results in sensor 2 falling and sensor 1 rising
* Moving a finger from sensor 1 to the blank area again results in sensor 1 falling and sensor 2 not moving much.

So there's unique conditions in the rate of change for each transition; this arises because the "gap" between the sensors is unequal - it's not possible to travel in a forward direction from sensor 1 to a blank area or in a reverse direction from sensor 2 to a blank area - the contacts are too close together to permit it as the gap is narrower than your finger.

Of course, along with programming and microelectronics, mathematics is another area where I am poorly prepared...but if anyone could give any advice on equations I could use that may achieve this? I realise there's going to be a "delta t" component and thus some lag may occur...but I could live with that if the tradeoff is more reliable transitions.

TonyWilk

#35
Dec 21, 2017, 01:24 pm Last Edit: Dec 21, 2017, 01:41 pm by TonyWilk
Now then...much to my shame and my partner's annoyance I was up until 4am trying to find the bug.
After 25+ years, my missus has almost gotten used to me staying up 'til 4 working on software :)

Quote
https://youtu.be/0bS3CqB_9hs
Yay !!! well done !

Some other points:
Those LEDs take a lot of current, you may need a bigger power bank at some point.

Sensing... I've not used the 'Capacitive sensing library', so this is a bit of guesswork based on that graph you posted earlier:

I don't think you need to look at rate of change or anything, you just need to determine states:

Your sensing relies on detecting: 1, both, 2 .. 1, both 2 in one direction and 2, both, 1 etc. in the other direction. If you are getting readings like in that graph and you can pretty reliably distinguish between "some signal" and "no signal" on each of the 2 inputs, then I think it can be worked out like:

Code: [Select]
int signal1, signal2;   // the 2 signals you just measured

int level1;       // a level above which signal1 is 'ON'    \ including when both are activated
int level2;       // a level above which signal2 is 'ON'    /

static int current_state= 0;
int s1state, s2state;

// State machine to determine what's going on...

s1state= 0;              // all we need to know is if the signals are ON or OFF
s2state= 0;
if( signal1 > level1 )
  s1state = 1;
if( signal2 > level2 )
  s2state = 1;

switch( current_state )
{
case 0:   // currently OFF... looking for (1) or (2)
  if( s1state == 1 )
    current_state= 1;
  else if( s2state == 1 )
    current_state= 2;
  break;

case 1:  // currently on '1'... looking for (1 and 2) or (nothing)
  if( (s1state == 1) && (s2state == 1) ){

    // just gone from (1) to (1 and 2)
    // ----- do GOING UP here ---

    current_state= 3;
  }else if( (s1state == 0) && (s2state == 0) ){
    current_state= 0;
  }
  break;

case 2:  // currently on '2'... looking for (2 and 1) or (nothing)
  if( (s1state == 1) && (s2state == 1) ){

    // just gone from (2) to (1 and 2)
    // ----- do GOING DOWN here ---

    current_state= 3;
  }else if( (s1state == 0) && (s2state == 0) ){
    current_state= 0;
  }
  break;
 
case 3:  // In the middle... looking for (1) or (2)
  if( (s1state == 1) && (s2state == 0) )
    current_state= 1;
  else if( (s1state == 0) && (s2state == 1) )
    current_state= 2;
  break;
}


The 'state machine' only switches states for particular conditions, others are ignored (like going from 'both' to 'nothing') so even if the signals are poor and you skip detecting UP or DOWN at one contact, it should process the next one ok.

Disclaimer: havn't run or tested the above code. I just typed it in.
It may, or may not, execute perfectly. But give it a go anyway.

Yours,
  TonyWilk







Grumpy_Mike

Quote
What are the BEST pins to use for capacitive sensing
They are all the same, their is no best.

Quote
I can hear you grumbling about breadboards from here...I know...remove the long wires and solder everything and a lot of the problems go away.
Which only goes to prove my point.

Quote
.but something tells me mixing digital and analog like that is not wise.
Not that but it is something you need to pay attention to. The real electronics term for this is "mixed signals".

Quote
but if Paul is right, does that mean that this is unlikely to work outdoors?
Yes it is less likely rather than unlikely. That is why Tony added that extra strip to provide it with some interference to pick up in the first place.

Quote
.even my hugely bloated, "verbose enabled" code does in fact fit on my Pro Trinket 5v
Verbose enabled is a term for the output of the compiler, it has nothing to do with the code. The C language is compiled, that is the code you write, the source code, is turned into, code the actual processor can understand, which is called machine code. The output of the compiler is a sort or running commentary it gives during this compile process. It does not affect the size of the resulting code. That is why you can have long descriptive variable and function names because in the code that is run on the machine these are just swashed into a two or three byte address.

GreyArea

They are all the same, their is no best.
That helps.

Which only goes to prove my point.
Not even disagreeing that soldered is better...but for quick and dirty tests like this a breadboard is quicker, especially with my shaky hands. I both love and hate that the electronics are so small...

Yes it is less likely rather than unlikely. That is why Tony added that extra strip to provide it with some interference to pick up in the first place.
I see. If you've seen the video I've done and my contact design, would a third strip help with reliability there too?

Verbose enabled is a term for the output of the compiler, it has nothing to do with the code.
I realise that, but "verbose" with a small "v" certainly describes what I've written. It got to the stage that I had an "output" flag. It had three settings originally;

0 - off
1 - moderate
2 - detailed

During my bug hunting last night I was forced to add

3 -  it's not working and I have no idea why!

Which flagged up "Serial.print" commands that I had entered on pretty much every other line.

Didn't realise that it didn't contribute to program size though, so thanks for that!

By the way...first outline draft attached of my idea to turn the contact lines into snakes...looks quite Nordic/Celtic, quite please with how it's come out, except for the ugly square heads which I've already decided I'm going to change...

GreyArea

Yay !!! well done !
Thank you!


Those LEDs take a lot of current, you may need a bigger power bank at some point.
That power bank and another  have drive the 44 in the chain even at 100% Brightness and 255 RGB (full white). I'll admit I've seen the board stop working at more lights...a LOT more lights (oops!) but in practice 60 will be the max and if I have to come down to 44 it's no problem. If you mean more in terms of durability, for the end use in question if I get an hour or two out of it that would be fine. Might consider a Lipo solution for the finished articles, but haven't looked properly at that yet. Whatever I use needs to be small - ideally fitting in the tube.

 
Sensing... I've not used the 'Capacitive sensing library', so this is a bit of guesswork based on that graph you posted earlier:
Neither had I until Sunday. Me and quesswork go back a long way...carry on...

Quote
I don't think you need to look at rate of change or anything, you just need to determine states:

Your sensing relies on detecting...

...The 'state machine' only switches states for particular conditions, others are ignored (like going from 'both' to 'nothing') so even if the signals are poor and you skip detecting UP or DOWN at one contact, it should process the next one ok.
I thought that too, but the trouble is the range of variation is such that the states "bleed" into each other. If a finger on sensor 1 gives me 100%, then a finger on sensor one and two together gives me 50% (on each sensor).

Which sounds like plenty...the trouble is with the variation I'm (suddenly - it wasn't like this until the code got larger) getting, a "trough" on the single sensor signal could be as low as 70% and a "peak" on the dual sensor signal could be as high as 80%. This is why the system gets "confused" between the states.

I could take more readings from the pins to even it out...but that slows things down, meaning it's not as responsive to a quick "swipe" down the lights...some get missed because the software part is reading the sensors for (example) 500 milliseconds, but my hand passes over the junction between the sensors in less than half that if I'm trying to be "dramatic". Thus the sensor reading just looks "a bit low"...but not low enough to detect the transition.

Quote
Disclaimer: havn't run or tested the above code. I just typed it in.
It may, or may not, execute perfectly. But give it a go anyway.
You're talking to a bloke who just makes stuff up as he goes along...but I will have another look at it...though probably after Christmas or my partner may arrange that I am speaking in a high squeaky voice for a while...

Once again thanks to all contributors. I've posted the code as a zipped attachment.

TonyWilk

Quote
...but the trouble is the range of variation is such that the states "bleed" into each other. If a finger on sensor 1 gives me 100%, then a finger on sensor one and two together gives me 50% (on each sensor).
With the state machine all you need is, say, anything over 30% is an ON.

As long as that's a fairly reliable "ON", then you don't need 'relative levels' for the state machine to work.

Quote
...though probably after Christmas or my partner may arrange that I am speaking in a high squeaky voice for a while...
lol... yeh, I've gotta go to Asda for all the xmas stuff (yippee!) or I'll suddenly go high-pitched as well.

Have a good Xmas

Yours,
  TonyWilk

GreyArea

Hey hey, I'm back on the Arduino trail.

I hadn't looked at the triangles options for one very specific reason...big triangles of foil over the top of the LEDs...block out the light from the LEDs!

D'oh!

However...

I have discovered the magic of copper gauze/mesh, and it works really well - and far simpler than my over complicated "count the contacts" option. It's a tad more expensive (ouch!) but it lets the light through so I don't have to worry about placement so much...

My test sensor is only 8 inches so far...but works faultlessly on both mains and battery power...I'll let you know how it progresses...

GreyArea

Tony;

Re noise channel

1. Does it have to be foil, or could a trace wire work?
2. If so, does it have to go around the edge, or could it sit between the sensors?
3. If not...I read somewhere that a conductive layer below the sensors but insulated from them could improve stability...could a similar layer function as the noise channel?

Currently I'm laminating the copper mesh which works well...response time to movement almost lag free...but I need finer mesh or laminating makes the contact plates too inflexible to work with.

Thanks again!

TonyWilk

#42
Dec 29, 2017, 04:36 pm Last Edit: Dec 29, 2017, 04:37 pm by TonyWilk
Tony;

Re noise channel

1. Does it have to be foil, or could a trace wire work?
2. If so, does it have to go around the edge, or could it sit between the sensors?
3. If not...I read somewhere that a conductive layer below the sensors but insulated from them could improve stability...could a similar layer function as the noise channel?
Hi again...

I think what is going on in the copper tape thing is like this:
Diagram:


Since there's a layer of sellotape insulator on top of the copper strips there's a capacitor formed between the strip and the finger. Driving the 'noise channel' is "ac coupling" from those strips into the finger and across to the "sense strips". The amount of coupling depends on the size of the capacitors. The size of the capacitors depends on the area between strip and finger.

In the diagram, the wider sense strip has more capacitance to the finger than the thin strip, so more 'noise' is coupled in.

So...
1. I don't think a thin wire will work because the area will be really small
- It might work if the wire is not insulated so your finger directly connects to the 'noise', but this would heavily depend on how sweaty (and conductive) your fingers are :)
I guess mesh or several narrow strips would be ok - or a thick strip with LED holes in it.

2. The 'noise' strip could go between the sense strips I think as long as your grip covers all the strips.
- I don't think the order of the strips will make any difference otherwise.

3. A layer below the strips could 'shield' the sense strips from other noise if it was connected to ground, but if it was connected to the noise channel it would simply couple in lots of noise all the time (just like another finger on the other side of the strips all the time).

I have to admit I'm guessing a lot here, the only way to know for sure is to try it I'm afraid.

Yours,
  TonyWilk




GreyArea

1. I don't think a thin wire will work because the area will be really small
- It might work if the wire is not insulated so your finger directly connects to the 'noise', but this would heavily depend on how sweaty (and conductive) your fingers are :)
I guess mesh or several narrow strips would be ok - or a thick strip with LED holes in it.
Ah, didn't realise you touched that line too. My library based system just connects a pin (no output) so it would seem to me that if there's nothing connected, you can't touch it. It would REALLY help if I knew in any way what I was doing...

Strip with holes in...erm...remind me that whilst your electronics advice is well respected, your aesthetics are somewhat challenged! The whole point with LEDS is to mask that they are point sources...not draw attention to it. I've tried it and it is effing ugly :-) - hence the mesh.

Quote
2. The 'noise' strip could go between the sense strips I think as long as your grip covers all the strips.
- I don't think the order of the strips will make any difference otherwise.

3. A layer below the strips could 'shield' the sense strips from other noise if it was connected to ground, but if it was connected to the noise channel it would simply couple in lots of noise all the time (just like another finger on the other side of the strips all the time).

I have to admit I'm guessing a lot here, the only way to know for sure is to try it I'm afraid.

I will...once I get that softer more flexible mesh. Point 3 in particular resonates though as the stabilising layer was referred to as a "ground plane", so it makes sense that it can't do both jobs...but since my smoothin routine is giving me a really nice response anyway, I think I need the noise more...and since it's fairly easy to do I may give it a go.

I'm using digital pins on my Mega and Trinket...should I be switching to Analog?

Grumpy_Mike

#44
Dec 30, 2017, 10:37 pm Last Edit: Dec 30, 2017, 10:38 pm by Grumpy_Mike
Quote
Ah, didn't realise you touched that line too.
You don't.
Quote
It would REALLY help if I knew in any way what I was doing...
Yes read reply #42 again and again until you understand.


Go Up