I need to be able to read the analog inputs as fast as possible. What is the speed that I can read those at? Is there a way to setup an event that would tell me when the values have changed? if I try to read the analog inputs too quickly I get strange things that happen. Given that I am using this as an R/C control the quicker I can respond to changes on the analog inputs the better things will be.
NETMF is not a ‘real time’ framework, so the short answer is… it depends.
Specifically what behavior? Do you have a code example? What board are you using? Provide more detail, please.
I ran into ‘strange things happen’ with my datalogger. I had to add a Thread.Sleep(1) to get stable readings. They would bounce between 0 and well above the actual reading until I did. I think there is probably a debounce feature that is not quite working.
When I have time I will revisit the code and experiment with FOR loops to find out what the fastest read I can get might be.
the inbuilt ADC is not capable of telling you when values change. It’s not like digital input, that clearly transitions from one state to another, it reads a variable voltage, so it’s theoretically “always changing” even if that is only microvolts.
If you need more advanced features, higher accuracy, etc then you might want to consider specialised ADCs. The ADC capability in most uC’s is “acceptable” for a wide range of uses, but never going to meet the demands that a high-end usage would put on it.
From a usage perspective, what are you using in an RC environment that uses analog values?
There was a lengthy discussion of this problem in the Cobra forum last week about reading an AD594 thermocouple. It was originally posted by Lars I believe. It has examples of the readings you will get by fast reading the analog in inputs which vary not by microvolts, but volts. I also posted examples from high end daqs which will still give you noise, and a workaround that worked in my application.
I am sure that the delays that I used can be shortened, but apparently not eliminated.
that wasn’t my point though - the point was that the voltage changes over time, big or small, but the concept of an interrupt is not possible to decide what change would “trigger” that.
the whole thread.sleep(1) for ADC reading stability is a separate issue - I’m certainly not discounting it as a valid point and it will change how accurate the readings might be.
Again, I’m really interested to hear what you’re trying to achieve in RC world, because analog voltage doesn’t seem to be a common means of dealing with RC inputs. That may just make this whole discussion a moot point, for this use-case.
I believe the question was how fast can he read the an inputs and I am trying to point out that there is a limit. I believe the read is faster than the internal make or break circuitry response time and a delay is required.
One obvious RC application is to use a common analog joystick as a controller instead or your standard transmitter. Useful for FPV.
After a lot more testing I have found that the analog inputs can read as fast as you need them too. I have it writing the output to a Debug.Print in a while loop with no sleeping and it is constant and consistent. Turns out its a timing issue I am having and it actually reads the input and tries to set OutputCompare too quickly. Before it has a chance to finish the previous set. I tried using SetBlocking but for some reason that appears to lengthen the first transision by 1ms So for instance if I have…
timings[0] = 300;
timings[1] = 1500;
timings[2] = 300;
timings[3] = 2000;
timings[4] = 300;
timings[5] = 1000;
timings[6] = 300;
timings[7] = 22000;
SetBlocking(false, timings, 0, timings.Length, 0, true);
For some reason the first timings[0] will actually be a 1300 and not a 300. If I set timings[0] = 0 then it is 1000 or 1ms.
In response to what I am using it for is I have what is called a Heli Chair which is a helicopter flight simulator that you sit in and it has flight controls to control a helicopter. It uses 5 potentiometers to control 5 analog inputs and several buttons for digital inputs which basically throw servos from one extreme to the other. I am building the PPM train that a R/C controller outputs in order to connect it up to a transmitter that is placed into trainer mode to control an actual R/C helicopter.
I have the PPM train working with OutputCompare as long as I don’t run it through a loop. It works perfectly as I can watch the servo positions on my Futaba 9CAP screen and moving the potentiometers and restarting the program moves them correctly.
I would like to set this up so that I can do other things at the same time with the USBizi chip so I will put it into a separate thread and figure out the best way to loop through the analog inputs and update the OutputCompare so that the timing comes out right. Worse case is I will simply do the timing manually by setting the pin to either low or high with thread.sleep(xxx) and create my own type of OutputCompare in a separate thread. Not sure what will happen when I start doing other things but I guess that is part of experimenting and trying new things.
If anyone has any suggestions or example code to look through I would appreciate the comments.
The serial debug.print may be giving you the delay you need for clean readings. When I attempt to go straight to data without a delay it bounces all over the place.
The Hell chair sounds like an interesting project. I hope you post progress reports!