Long / short press button...but reading ADC

[fratello]

Already tried ... it's act like I always press SHORT !

[richard]

the dataset you are trying to infer information from consists of two pieces of data
1. the adc reading
2. the timestamp of the reading
The periods you are interested in are between .2 and 1 sec. if you sample the input volts at 200 times / sec (5mS)
then you need to store at least 200 samples and their timestamps . when you have those samples you could analyse the dataset
for press/longpress data. you need to understand that if you sort the data on the adc value then the time stamp value needs to be included in the sort otherwise the data becomes useless [all the time info is lost].
If the data is so noisey that my method fails the the above method could work but it would not be possible on a 12f675 [insufficient ram]
lowering the input impedence, altering the sample rate or increasing the "pressed"/"not pressed" tolorance may help.
Write a pgm to capture and print the adc reading at a 5mS sample rate .then you can examine the data statistically for a fundamental noise frequency that may be possible to filter out or maybe some other ways to mitigate the noise problem. without real data i'm just speculating.
my method could also be turned around to count the number of "valid" reads in a period rather than the number of "periods" of valid reads ,
which may perform better in noisy environments

[tumbleweed]

One thing I will say is that with the code from post #14 you need to rearrange the threshold levels
or the order of tests so that they go from the lowest value to the highest.

Right now the code is

trigger_thresshold_1   con 600  ; adc reading must fall below this to count  as a pressed button 1
trigger_thresshold_2   con 500  ; adc reading pressed button 2
trigger_thresshold_3   con 400  ; adc reading pressed button 3

if DataW <  trigger_thresshold_1 then
    b_level =1
elseif  DataW < trigger_thresshold_2 then
    b_level =2
else  DataW < trigger_thresshold_3   then
    b_level =3
endif

For that to work it needs to check from lowest value to highest value...

trigger_thresshold_1   con 400  ; adc reading must fall below this to count  as a pressed button 1
trigger_thresshold_2   con 500  ; adc reading pressed button 2
trigger_thresshold_3   con 600  ; adc reading pressed button 3

Otherwise everything will look like button 1

[richard]

your correct tumbleweed , I think there is another issue there with that code too but fratello has not indicated that multiple buttons actually are on the agenda so I left it as is.
if anyone is interested I do have a multiple button version that is complete and works .i'm quite surprised just how well the idea actually works so I developed it a bit further .its a good option if pins are limited.
I would be interested to see fratellos raw data and see if noise is really the issue

[tumbleweed]

Another thing that the sort and average routine in post #11 does is to perform the routine twice and compare the two resulting averages before declaring "I see a valid key" (if adca=adcb then gosub efectuez).

That could be adapted to fit into the "check_sw" portion of your code by changing some of the post#11 averaging variables around and only
changing the "result" DataW on a match...

if adca=adcb then
  DataW = adca
endif
return

How well all that works depends on the noise, how many switches (and how far apart the values are), etc, but I could see where it'd be better than just using a single adc value for sure.

if anyone is interested I do have a multiple button version that is complete and works

Sure. Love to see it.

[fratello]

Thank you all for support !
Very interesting suggestions and points-of-view ...
@Richard :

if anyone is interested I do have a multiple button version that is complete and works ...

Of course !!!

[LinkMTech]

I could be wrong but I have to ask about using "CALL" instead of GOSUB for the sub routines CHECK and achizitie.

From the MCS Help section:

CALL Label

Execute the assembly language subroutine named Label. GOSUB is normally used to execute a PicBasic subroutine. The main difference between GOSUB and CALL is that with CALL, the existence of Label is not checked until assembly time. Using CALL, a Label in an assembly language section can be accessed that is otherwise inaccessible to PicBasic.

Example

CALL pass ' Execute assembly language subroutine named _pass

I've never used it in place of GOSUB so don't know if a RETURN works the same in this case.