Driver - Event Driven GHI Potentiometer

[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.

Nice contribution! Thank you.

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.

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.

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).

You are one step ahead of me :slight_smile: