MPXA4115A picbasic code

[ScaleRobotics]

First try success? Nice!

Maybe you are already converting feet to meters in your code, but this seems to work for me. And I think it is better than a new metric lookup table, because there are more feet per increment, which should make it more accurate.

    if metric = 1 then   'convert from feet to meters
        finalALT = finalalt * 2500
        finalALT = div32 8203
    endif

So it looks like you are making an altitude hold circuit. An altitude hold has been on my back burner for a few years now. Darrel's code has really made part of this easy, so it looks like I may be able to move this up a burner or two myself!

How smooth is your servo at 4 mhz and 8 mhz? I would think that 20 mhz would be a bit smoother for sensing pulse width, but have not tried the lower mhz.

[bitmaniac]

Altitude hold : oh! you gave me another idea!

For the moment it will be an ALT+TIMER motor cut-out for moto-gliders for F5J-GR . I am trying to make a circuit that will cut motor after 30sec or to an ALT of 200m what comes first!

about your question I think we will have problems with internal 4mhz. I am thinking of going to 12f683 (8 Mhz internal) and more code space , we are in the limit here with f675. Also may be asm is used to pass servo pulses through and/or maybe as final solution we will go to an external low profile crystal and two decopuling caps.

I will experiment and see....

(Now I get 51m here (project running!) the funny thing is that I have closed the door of my lab now , the weather got very hot here now . I think there will be no problem with the calibration because the only think I want to measure is ALT differece of 200m so 1st you have to power the device just 1minutes before flight. It will read the ground alt and if 200m reached motor will cut that's all.

[ScaleRobotics]

Modified the code to handle 0 to 25,900 feet, and a 16 bit conversion lookup table. Now you can select your conversion oversampling rate for Darrel's code, and your result gets shifted to match the 16 bit lookup table for altitude conversion. Works for 10 to 16 bit oversampling rates. My favorite is the 15 bit for accuracy and speed, but it is selectable.

See http://sites.picbasic.net/component/...,91/pageid,81/ for more info.

[bitmaniac]

scalerobotics , you have done excellent work again my friend!.

But you made me wonder ... (as I have already design the pcb of my ALTMTR) MUST I include a Crystal (20Mhz) after all or I can leave/ and rely on internal 8Mhz oscillator (12f683) with any drawbakcs of it?
May be I need to redesign my mcb and loose button activation option.
Or may be I use led indication both as input and / or output this will make me think.... )

[ScaleRobotics]

Thanks Bitmaniac,

Don't let me worry you! The speed difference will probably have a bigger affect on your PWM sensing and pass through, than altitude conversion. But I think 8mhz is reasonable for this. Yours is the motor control for a glider, so even if it is a little glitchy, you are not going to notice much, since to get to altitude you will probably be at 50 to 100 percent throttle, or you will be at 0 looking for lift.

I was originally thinking of speed for the higher bit conversions, like 15 and 16 bit. But I think the speed of your conversion will be 2 us, where with 20 mhz, the conversion is 1.6 us. So just the 16 bit analog oversampling takes 100 ms with 20 mhz and 125 ms with your 8mhz internal. Not a big difference there! Of course the 15 and 14 bit samples are MUCH quicker.

So no, really, I think you will be fine.

[bitmaniac]

So you think I have to stick to my already made pcb and don't try an 20 MHZ crystal.
Here it is the final pcb in 3d and shematic I am going to use.
I am finishing the firmware part now thanks to Darrel ADC convertion and your help. I will use 14bit with 8mhz internal (12f683). The pcb will support ICSP an optional button and a led indicator. I have not try the pcb (in real) only in Proteus sim. I will let you know of the progress. for the moment take a look...

EDIT: in schematic the 100n pic decoupling is missing (in pcb is ok)

[ScaleRobotics]

So you think I have to stick to my already made pcb and don't try an 20 MHZ crystal.

I think your design is feasible. There is no harm in designing the board before the firmware is completed. But there might be some harm ($$$) if you have them made before testing. I would recommend that you wait till you write your PWM sensing and generating code, and test it, before you decide on a final layout. On a breadboard, adding a crystal is easy, if you need to...

[flotulopex]

Thanks bitmaniac,

I have read Alain's explanation about "oversampling" and "rolling mean value" in a previous post but I'm still not clear why it is necessary to declare a DEFINE to do so.

I think, I don't understand what the DEFINE does.

Any clue for me?