Main Site Documentation

Driver - Event Driven GHI Potentiometer


#1

[title]Event Driven GHI Potentiometer[/title]
http://code.tinyclr.com/project/442/event-driven-ghi-potentiometer/
[line]
My goal was to use the GHI Potentiometer Gadgeteer Module to adjust the volume of the Music Module, but readings were jumping all over the place.

I ended up writing a custom “Event Driven” driver for the module. It will poll the potentiometer value every 5 miliseconds and calculates the average value over 10 polled values. If the average value differs more than 1 from the last reported value, the event will be raised.

To use the custom driver:

  • Do NOT add the potentiometer module to the Gadgeteer designer
  • Add a new class to your project
  • Replace the contents of the new class with the source code below
  • Add the following line after your class definition
GTM.MischaBoender.GHIPotentiometer potentiometer;
  • Initialize the module with
 potentiometer = new GTM.MischaBoender.GHIPotentiometer([SocketNumber]);
  • Wire-up the event handler with
potentiometer.PotentiometerChanged += new GTM.MischaBoender.GHIPotentiometer.PotentiometerEventHandler(potentiometer_PotentiometerChanged);

In the usage example I use the LED7R module for some visual feedback.


#2

Nice contribution! Thank you.


#3

It really took me a long time to come up with code that could give me some stable readings. Using “currentValue != lastVale” doesn’t do the trick because the readings are jumping all over the place. I ended up using a byte value, buffering 10 readings and take the average of that. It’s not a coincidence that the Music Module also uses a byte value for volume, but I also think this is a good scale.

There are some improvements to be made (note to myself): Don’t use a byte[] buffer, but a use double[] buffer and then calculate the average (as byte) to get more stable readings. The buffer size can then be decreased from 10 to about 5. I haven’t tried this jet, just tought of this last night when I was already in bed (are you guys also dreaming in C# like me? ;)).

I’m using this driver in my streaming radio project, but didn’t include the code for the music module to keep the usage example as simple as possible.


#4

Maybe the driver can have parameters to set a “window” for events to fire. This will take care of little noise but then the user may want to have a larger window, or slower/faster readings.


#5

I have these public properties on my to-do list:
[ulist]Polling interval
Event interval (minimum time between raised events)
Precision (currentValue < lastValue - X)
Pollingbuffer size[/ulist]

Is this what you’re referring to Gus?

I’m also not sure if I should start the poller automatically (like it is now), or on request (with the StartPollerThread() method).


#6

You are one step ahead of me :slight_smile: