That won't do it in our case, as the different buffer slots are used for different channels rather than consecutive samples of a single channel.
In this point in the code: https://github.com/ytai/ioio/blob/master/firmware/app_layer_v1/adc.c#L192 the sample value for the i'th channel is obtained. The i'th channel is ADC channel number i in the list of all channels currently open, sorted by channel number. For example, if ADC channels 4, 6, 8 are currently open, then i=0 is ADC channel 4, i=1 is ADC channel 6, etc. The PinFromAnalogChannel function can translate the analog channel number into IOIO pin number if you wish. If you want to do any processing on that signal, this would be the place to modify it, just before it gets written to the output message. If you want to actually decimate the messages being sent without lowering the sample rate, you'd need to add some condition around the AppProtocolSendMessageWithVarArg() call. Of course, you'll decimate other channels at the same time if you do so. Having all that said, I think you'd be wasting your time with this. It is not a problem for the Android device to process 1000 samples a second and it is not a big load on the comms either. Embedded software is harder to debug and test and at best you'd end up with non-standard firmware hurting the portability of your app as well as your ability to easily get firmware upgrades. On Thu, Jul 16, 2015 at 10:23 AM, Julio Castellanos <[email protected]> wrote: > Thank you for your help, i think i will split the signal in two different > analog inputs, one for the range of 0-10 A(for more accuracy) and the other > one for 10-30 A with +/-0.1A. > > On the other hand, aside the accuracy, i would like to implement the > on-board filter to make simplier my Android app, i already have found on > these forums how to change the sampling rate and reading the PIC's > datasheet i found i could find the average value of 16 adc values with > something like this: > > for (count = 0; count < 16; count++) // average the 16 ADC value > { ADCValue = ADCValue + *ADC16Ptr++; } > ADCValue = ADCValue >> 4; > > But i'm struggling to know where to put that in the firmware code. > > El jueves, 16 de julio de 2015, 11:43:15 (UTC-5), Ytai escribió: >> >> I don't see how sampling faster is going to improve your accuracy. The >> +/-100mA that you're seeing is about you might expect of your current >> signal properties and a 10-bit ADC, regardless of sampling rate. In other >> words, if the problem you're trying to solve is that of increasing >> precision, you're barking at the wrong tree. >> Of course, if you insist, you can fairly easily change the sampling rate >> and/or introduce any on-board filtering you please. >> >> On Thu, Jul 16, 2015 at 9:34 AM, Julio Castellanos <[email protected]> >> wrote: >> >>> For example if instead of sending all the values from the ADC, i >>> calculate in the firmware the max value of the signal and send it >>> periodically, i could increase the adc conversion rate and send the max at >>> the same rate that now i'm sending the values, so my app would be faster >>> because i wouldn't need to calculate anything, just multiply by 0.707 to >>> get the rms value. It's just what i thought, please correct me if i'm wrong. >>> >>> El miércoles, 15 de julio de 2015, 16:57:00 (UTC-5), Ytai escribió: >>>> >>>> I don't see how custom firmware is going to give you higher precision. >>>> The ADC on the PIC has 10-bit resolution, which translates into 3.3mV. With >>>> your full-range scaling of 50mV/A this would translate into about 66mA >>>> resolution. If that's insufficient you can either: >>>> >>>> 1. Use an external ADC with higher resolution. >>>> 2. Sacrifice your 30A range for higher precision in the low end by >>>> increasing the gain (be sure to clamp at 3.3V or else you'll be damaging >>>> the IOIO). >>>> 3. Dynamically change the gain under software control (e.g. by >>>> using a digital output to change a configuration resistor value on the >>>> op-amp). >>>> >>>> >>>> On Wed, Jul 15, 2015 at 2:10 PM, Julio Castellanos <[email protected]> >>>> wrote: >>>> >>>>> Yes indeed i need to conditionate the signal, i though there were pins >>>>> tolerant to 5 V but i just read that is only for logic input. Until now i >>>>> was measuring currents lower than 10 A so i didn't remarked the need of >>>>> the >>>>> conditioning. Thank you for your support. >>>>> >>>>> Also i was already using the buffered version of AnalogInput, i did >>>>> just like you said, i measured the peak-to-peak voltage and converted it >>>>> to >>>>> rms, then i did a simple conversion to current, that's when i got the >>>>> accuracy of +-0.1A, but i need it to be less than that, that's why i'm >>>>> looking for the option of doing it in the firmware. I wonder if that is >>>>> possible? >>>>> >>>>> >>>>> >>>>> El miércoles, 15 de julio de 2015, 12:09:16 (UTC-5), Ytai escribió: >>>>>> >>>>>> I think I understand now. So: >>>>>> >>>>>> 1. If you're really intending to measure a signal as high as 30A, >>>>>> the output voltage will be around 4.5V, which exceeds the range the >>>>>> ADC is >>>>>> willing to accept (0-3.3V). >>>>>> 2. Unless the sensor has a built-in amplifier, it is likely that >>>>>> it has a fairly high output impedance. >>>>>> 3. To address both of the above problems, I recommend >>>>>> conditioning the signal using one of more opamp stages, so that it has >>>>>> about 1.5V bias and about 1.5V amplitude @ 30A (or 50mV/A). >>>>>> 4. The IOIO samples at 1kHz. There should be no problem sampling >>>>>> of a 60Hz signal. Moreover, since you know it is a sine wave, all you >>>>>> really need is measure the peak-to-peak voltage which you can then >>>>>> trivially convert to RMS. I suggest that you look at the buffered >>>>>> version >>>>>> of AnalogInput, so that you don't miss or depend on your application >>>>>> thread >>>>>> loop frequency. >>>>>> >>>>>> >>>>>> On Wed, Jul 15, 2015 at 7:15 AM, Julio Castellanos <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hi Ytai, thank you for your help. The signal is the output of an >>>>>>> A.C. current sensor, the frequency is the same as the network, 60 hz, >>>>>>> and >>>>>>> the sensor can measure up to 30 A with a sensitivity of 66 mV/A. The >>>>>>> signal >>>>>>> has always a D.C. value of 2.5 V so if i measure 1 A the signal will >>>>>>> have a >>>>>>> max of 2.566 V and a min of 2.434 V. The absolute maximum with 30 A is >>>>>>> 4.48 V and absolute minimum of 0.52 V, so the signal is always in the >>>>>>> range >>>>>>> of the analog input of the ioio. I want to know the value rms of the >>>>>>> current in my smartphone, and i tried obtaining the rms of the voltage >>>>>>> by >>>>>>> calculating the max value of a buffer of 1000 values and the >>>>>>> multiplying it >>>>>>> by 0.707. I get the value rms of the current with an accuracy of +-0.1 >>>>>>> A, >>>>>>> but i need it to be less than that, that's why i though it would be >>>>>>> better >>>>>>> to compute the rms value of the signal in hardware so i dont have to >>>>>>> send >>>>>>> the whole buffer of the signals. >>>>>>> >>>>>>> El martes, 14 de julio de 2015, 18:44:30 (UTC-5), Ytai escribió: >>>>>>>> >>>>>>>> Before we begin, can you please specify the signal you're trying to >>>>>>>> measure better? >>>>>>>> Specifically, its min and max (instantaneous) voltage, and its >>>>>>>> bandwidth would be important. >>>>>>>> Based on that I can recommend a way of measuring it. >>>>>>>> >>>>>>>> On Tue, Jul 14, 2015 at 3:06 PM, Julio Castellanos < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hello, i'm currently working with the IOIO analog input with a >>>>>>>>> sensor signal that comes out as an A.C. signal in the range of 2,5 V >>>>>>>>> as >>>>>>>>> mean value. I've tried to get the voltage through the analog input >>>>>>>>> and get >>>>>>>>> the rms value in software, but the value changes to much because of >>>>>>>>> the >>>>>>>>> bandwith limit of the IOIO:Android communication. I'm now looking to >>>>>>>>> get >>>>>>>>> the RMS directly in hardware and just send that value to the software >>>>>>>>> but i >>>>>>>>> gave a look at the hardware code for adc.c and i don't understand >>>>>>>>> almost >>>>>>>>> nothing, can someone point out to me a source where i can learn how >>>>>>>>> does >>>>>>>>> this code works? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "ioio-users" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "ioio-users" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ioio-users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ioio-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/ioio-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
