Math operations execution time

[HenrikOlsson]

Yeah, the problem, as I see it, isn't that the PIC and your math is too slow...the problem is it's "too fast". This makes the ADC sample the signal very quickly so that between two samples the difference in altitude (or at least in the result given by the ADC) is so small that the actual change may drown in the noise. This fools the deployment algorithm into thinkin the altitude decreased.

When you introduce the PAUSE 200 the ADC only samples the signal 5 times per second (or there abouts) so the difference in signal from the pressure sensor is large enough not to allow the noise on the signal to trip the deployment algorithm.

There are several ways around this. The easiest is to do what you've done but tweak the PAUSE time to make sure the signal actually changes enough AND allow you to store enough samples depending on estimated time of flight. Another aproach might be to take 10 ADC samples and average them to filter the signal a bit, and then make sure that the a certain number of concecutive samples shows a decrease in height - not just one.

/Henrik.

[rasciodc]

Yeah, Henrik, I think the problem is exactly what you said, because I´ve just implemented the code to use ad raw data in comparision (to skip the math) and the result is the same!

The best result I got is with 190ms, which is the minimum pause that will not cause a false trigger. But it is still too high for a 15 second period of logging.

The filter is a good idea but I´ve also thought about using a higher adc sample time (ADC_SAMPLEUS 500 or something like that..) do you think that it would work?

Anyway, I think it´s a good idea to start thinking about a filter...

Thanks a lot!

[Dave]

One question I have is, How do you have the pressure sensor mounted? If it mounted in such way that the thrust is being impressed on the sensing element then the pressure readings will be offset. I would mount the sensor so that the sensing element is perpindicular to the rockets thrust. It should give you a much more stable and reliable reading. I would also take about 64 readings and do a right shift 4 places to the give you a 12 bit reading. I do this as a mater of fact for all of my A/D readings from the PIC internal A/D. I only use a 40uS. delay when changing channels. You should easily be able to captute the data at 100 Hz.

[rasciodc]

One question I have is, How do you have the pressure sensor mounted? If it mounted in such way that the thrust is being impressed on the sensing element then the pressure readings will be offset. I would mount the sensor so that the sensing element is perpindicular to the rockets thrust. It should give you a much more stable and reliable reading. I would also take about 64 readings and do a right shift 4 places to the give you a 12 bit reading. I do this as a mater of fact for all of my A/D readings from the PIC internal A/D. I only use a 40uS. delay when changing channels. You should easily be able to captute the data at 100 Hz.

Yes Dave, you´re right! I still have to think about how the circuit will be disposed inside the rocket, calculate the pressure vents in the fuselage and etc...
Anyway, as I said, I am very noob to this so, is there any material where I can read about this 12bit reading with a 10bit AD?

[spcw1234]

I would also take about 64 readings and do a right shift 4 places to the give you a 12 bit reading. I do this as a mater of fact for all of my A/D readings from the PIC internal A/D. I only use a 40uS. delay when changing channels. You should easily be able to captute the data at 100 Hz.

Can you explain this in more detail? Sounds like an interesting trick to me. Thanks!

[Dave]

Just accumulate 64, 10 bit readings in a row into the same word variable, then do a shift to the right by 4 places which will give you a 12 bit result. Here is an example:
'************************************************* ********************
READAD: 'READ SYSTEM A/D VOLTAGES (AVERAGE 64 READINGS) 18F2620
'************************************************* ********************
TMPCHAN = CHANNEL 'COPY CHANNEL DATA
IF CHANNEL = 3 THEN TMPCHAN = 4 'SKIP CHANNEL 3 AS IT IS USED AS REFERENCE
ADCON0 = $01 | (TMPCHAN << 2) ' Set A/D to Channel X, On
PAUSEUS 40
VOLTS(CHANNEL) = 0 'CLEAR A/D READINGS
SCRATCH = 0
WHILE SCRATCH < 64 'SUM 64 READINGS
ADCON0.1 = 1 ' START CONVERSION
WHILE ADCON0.1 = 1 'WAIT FOR A/D TO FINISH
WEND
VOLTS(CHANNEL) = VOLTS(CHANNEL) + (((ADRESH & $3) << 8) + ADRESL) 'BUILD SENSOR WORD
SCRATCH = SCRATCH + 1
WEND
VOLTS(CHANNEL) = VOLTS(CHANNEL) >> 4 'TURN INTO 12 BIT RESULT

RETURN

[gadelhas]

Hi;

Following what Dave has said, take a look at this link, by Darrel Taylor;
http://www.darreltaylor.com/DT_Analog/

By the way rasciodc, i'm Portuguese too, i'm from Maia.

[spcw1234]

Thank you Dave, and Gadelhas! I am excited to try this!

[rasciodc]

Hi;

Following what Dave has said, take a look at this link, by Darrel Taylor;
http://www.darreltaylor.com/DT_Analog/

By the way rasciodc, i'm Portuguese too, i'm from Maia.

Thanks, gadelhas, for the link! very useful!! mainly for beginners like me!
And, actually I´m Brazilian! living in São Paulo at the time....

Just accumulate 64, 10 bit readings in a row into the same word variable, then do a shift to the right by 4 places which will give you a 12 bit result.

Dave, thanks for the explanation! How much time would this algorithm take to do this, any idea? (just wondering if I can use it in my altimeter...)
Thanks!

[rasciodc]

Well, I think the problem is finally solved! The problem was indeed the lack of a filter algorithm. Searching about this kind of issue I´ve found this: http://www.pbpgroup.com/modules/wfse...hp?articleid=7
This algorithm by Darrel Taylor solved the false deployment in my circuit.

I just changed the number of averaged samples from 16 to 8. Now I can fullfill my eeprom using the desired amount of time on "PAUSE" depending on the interval between samples I need.

This problem I think is solved, but you know how things go with programming... I´ll keep looking for bugs before I breadboard it and finally build the final circuit.

I´d still appreciate any comments and sugestions on my code. An "outsider" always has better view than the author himself (looking the same code for hours and hours...).

Thanks guys!!