Altitude Hold?

[Tristar500]

Just wondering what any of you have experimented with so far as altitude hold.

Lawrence

[kd7ost]

Here is one option I'm aware of and use. This works most excellent. I don't mean pretty well. I mean it nails the altitude and keeps it there.

Dan


http://www.u-nav.com/picoalt2.htm

[Cats Eyes]

Here is one option I'm aware of and use. This works most excellent. I don't mean pretty well. I mean it nails the altitude and keeps it there.

Dan


http://www.u-nav.com/picoalt2.htm
US $250 :eek:

Why so pricy? Isn't this just a pressure sensor chip and a microcontroller? :confused:

-- Kevin

[rjet]

Cats Eyes,
It probably only costs u-nav about $80 to build it, but they may have spent a thousand man-hours developing it and they hold the copyrights to the source code so it is difficult to compete with them.

[Cats Eyes]

You're probably right about that. Nobody else is making things like this, so they can charge what they like. Probably just my ignorance, but I can't see why it would take all that long to develop the thing. Has anybody tried to duplicate something like this? Doesn't seem that hard too me!? :confused:

For instance, take the components of MX's ZLog (http://www.hexpertsystems.com/zlog/). He's using the Motorola MPXA6115 (http://rocky.digikey.com/WebLib/Motorola/Web Data/MPXA6115.pdf) as the pressure sensor. Feed the output to the D/A of a PIC, but, instead of recording it, just use it to vary the PWM of a standard servo signal. 10 ft too low = 1000µS, 10 ft too high = 2000µS, correct height = 1500µS. Or maybe that's reversed. Feed that to your ESC (if you're varying throttle) or your elevator servo and you're done, right? :D

OK. I guess that's just too simplistic. Must be more to it than that...

-- Kevin

[rjet]

Kevin,
There are several IC's on u-nav's board. Likely an op-amp and/or ADC converter. It might possible to build one in a week of hard work, but it would be a good idea to flight test it for another hundred hours to adjust the controls and verify the dependability of the hardware. Then the manufacturing process can take a few weeks to organize. If you want to prototype one for yourself it could be fun, but it would be very time consuming.

[kd7ost]

Or maybe that's reversed. Feed that to your ESC (if you're varying throttle) or your elevator servo and you're done, right? :D
OK. I guess that's just too simplistic. Must be more to it than that...-- Kevin


Kevin,

Sounds cool dude. Let us know when you get it done.

Dan

[Bert Brown]

I am in the process of developing exactly what you suggest. Motorola MPX5100AP & a microcontroller. It is quite straight forward except for the resolution needed if you want to use A-D conversion (as opposed to an analogue closed feedback loop). Some signal conditioning is required to achieve a 1m resolution.
Bert

[Cats Eyes]

Interesting to see everyone rush to defend U-Nav. I see the point -- I was thinking "mass produced for the hobby market" (i.e. where the occasional failure is par for the course), rather than "limited production for the professional market" (where rigorous testing and QA are applied, etc.)

Another thing that occurred to me is, how many products have they tried to develop and failed? They gotta pay for their losses for those too. We all owe U-Nav a debt of gratitude for showing us that this stuff can indeed be done. (Even if they won't share their source code. I'm kidding, I'm kidding! :rolleyes: )


Sounds cool dude. Let us know when you get it done.That's what I get for opening my trap! In fact I was thinking of attempting it at some point. No doubt I will run into lots of issues and will see that it's not in fact as easy as it seems.

For instance, I can see right away I need at least two inputs from the RX, one for the pilot's command when the thing isn't in autopilot mode, and another to switch modes (autopilot vs. manual). Well, that's just software, eh? Shouldn't add to the component count much.


I am in the process of developing exactly what you suggest. Motorola MPX5100AP & a microcontroller. It is quite straight forward except for the resolution needed if you want to use A-D conversion (as opposed to an analogue closed feedback loop). Some signal conditioning is required to achieve a 1m resolution.Ah, good. Then you can make all the mistakes and I can learn from them! :D

Seriously, the ZLog (http://www.hexpertsystems.com/zlog/) claims an altitude resolution 1 foot. How's he doing it? Maybe I should PM him and ask him to join the discussion?

I was thinking D/A would be the only way you could to it to maintain stability. Can't even imagine how you'd do it in analogue. The PIC12F675 for example has a 10-bit D/A on-chip. I would think that would be good enough resolution for our purposes?

-- Kevin

[Crash Pilot]

Don't know if you have already seen this . May be worth looking at.

http://cvs.sourceforge.net/viewcvs.py/rcpilot/rcah/

Crash pilot1

[MX]

...Seriously, the ZLog (http://www.hexpertsystems.com/zlog/) claims an altitude resolution 1 foot. How's he doing it? Maybe I should PM him and ask him to join the discussion?...

I've been watching. The MPXH6115 uses "temperature compensation...and bipolar semiconductor processing to provide an accurate high level analog output signal proportionate to applied pressure" (per the data sheet). Then it goes into a 16-bit A/D to get the resolution I need. There is also some software processing to eliminate noise.

MX

[LukeZ]

I am currently working on my own altitude sensor using the MPX4115AP. I don't need it necessarily for altitude hold per se, but it's an interesting thing to think about.

Cats Eyes, I'm sure there would be some unforeseen challenges, but on the other hand I wouldn't want to think U-Nav knows something us dedicated hobbyists can't figure out just as well. I bet it could be done, and for easier than $250. I think U-Nav makes some neat products, and I have nothing against the company personally - but as an economist my feeling is their prices reflect the fact that their products are largely one-of-a-kind at present: if they had some competition (from you?) I don't think their prices could stand at anywhere near their current level.

Partly through reading the adventures of Cats Eyes and Ironsides I got motivated to jump into PIC programming myself less than a month ago. With no previous experience, I already have an altitude and airspeed sensor (currently they just display their values on an LCD). They're in testing stages right now but seem to work well so far. Whenever I get my custom PCB sent back I'm taking this thing up to a local mountain to test out the altitude.

As I mentioned I'm using the MPX4115, the output of which goes through an op-amp (just a buffer though) into a 12 bit A/D (LTC1291) and then to my PIC. Resolution with 12 bit A/D is around 7 feet at sea level, but due to the properties of the atmosphere, the resolution decreases with altitude: at 45,000 feet above sea level (the highest the sensor can read) resolution is more like 35 feet. Of course this could be much improved with a 14 or 16 bit A/D like MX uses, but for my purposes 12 bits was enough and anyways I had the LTC1291 laying around. It's a two channel converter and I use the other channel for airspeed (MPX5010 sensor for that).

Freescale (makers of the MPX sensors) has an app note (http://www.freescale.com/files/sensors/doc/app_note/AN1646.pdf) on hardware filtering with a few caps to decrease noise. I took their advice on that count, and I also do a bit of additional filtering in software, but nothing fancy: just a rolling average of 10 to 20 samples (still tweaking it).


LukeZ

[zenoid]

For my setup, I'am using a swiss component named intersema MS5534 that embed a dsp and give temperature and pression reading trough a serial link. The resolution should be 30cm or 1 ft by computing and resolving some given equations. My platform is build around a microchip 16f8xx.

[Bert Brown]

Ah, good. Then you can make all the mistakes and I can learn from them!

Seriously, the ZLog claims an altitude resolution 1 foot. How's he doing it? Maybe I should PM him and ask him to join the discussion?

I was thinking D/A would be the only way you could to it to maintain stability. Can't even imagine how you'd do it in analogue. The PIC12F675 for example has a 10-bit D/A on-chip. I would think that would be good enough resolution for our purposes?

-- Kevin

No problem - if interested I'll send the completed design. 1 foot resolution means that he's using a 15 or 16 bit ADC. This will drive the price up. The 10 bit ADC's in Ucontrollers will only get you to several 10's of feet resolution - not really fine enough for a UAV. The ceiling altitude can be traded off by some signal conditioning (level shift & some amplification) but the best you can probably hope for is in the region of 10 feet resolution for a ceiling of 5,000 feet. My current intention is to use the MPX5100 and 16F877 ucontroller (10 bit ADC), use a ceiling of 2,000 feet (don't care if I'm above that - its pretty flat where I fly) and hopefully achieve a resolution of < 5 feet.
Bert

[Tristar500]

for those of you thinking of making or having PCB's made, Check out this website. This guy has a nice process for making PCBs. Also check out this turbine and other engine projects.

Lawrence

http://www.5bears.com/pcb.htm

[Cats Eyes]

The 10 bit ADC's in Ucontrollers will only get you to several 10's of feet resolution - not really fine enough for a UAV. The ceiling altitude can be traded off by some signal conditioning (level shift & some amplification) but the best you can probably hope for is in the region of 10 feet resolution for a ceiling of 5,000 feet. My current intention is to use the MPX5100 and 16F877 ucontroller (10 bit ADC), use a ceiling of 2,000 feet (don't care if I'm above that - its pretty flat where I fly) and hopefully achieve a resolution of < 5 feet.
Ah! I was thinking that you'd need the A/D to cover the complete range of the sensor. But of course, you could use an op-amp to amplify & level shift to pick out the range your interested in. DUH! Why didn't I think of that? :confused:

Thanks to everyone for their input. Anyone have a preference among these devices, MPX4115, MPX5100 or MPXH6115? (I looked at the intersema MS5534, but all that math you have to do looks way too complicated for my little cat brain :eek: )

-- Kevin

[kd7ost]

I have a request/ recommendation. This should be the easiest part though.
Futaba PCM receivers put out pulses at 3.3 vdc. I don't know all that do that. I also don't know if any other manufacturers employ the 3.3 vdc processors in some of the product line. My JR doesn't. PIC chips see 3.3 vdc as ambiguous. It's not a high or a low so isn't decoded properly. If there was a pull up resistor on the input signals or a buffer amp, like a CD49049 that would be very cool. It would be readily versatile no matter what PCM system you use. You wouldn't need to put separate buffer amps in line.

Dan

[Cats Eyes]

I just looked up the spec for the 12F629/675 and it looks like you are correct. For the Schmitt trigger inputs a low is 0.2 Vdd and a high is 0.8 Vdd. With 5V supply that would be 1V and 4V respectively. So 3.3V would not be high enough to register a "1".

Would a pull-up resistor do anything? Would depend on the output stage of the RX. Note that the PIC pins (or some of them at any rate) have "weak pull-ups" that you can enable in the firmware. I think they're somewhere in the 10-15K range. You could give that a try. However, I guess you were looking for something more universal. It would be a realy pain in the butt if you had to buffer every RX signal before feeding it to the PIC. :mad:

I wonder if other RXs are like this. I've never had any problems with Hitec or Berg. There are lots of commercial PIC-based signal processors out there that take a servo signal from the RX as input. I wonder if they all suffer from the same problem?

Maybe we should start a different thread on this topic?

-- Kevin

[kd7ost]

Sounds OK by me. Some one somewhere once suggested we do a "how to" thread on starting out with building UAV's. I've often thought issues like this, and the same Futaba PCM receivers connecting up to co-pilots should be covered. It might effect peoples choices for purchases in the future, and if nothing else be a Q&A source.

[rjet]

Are you sure that you need 4 volts to get a logic high from a PIC? If I recall the TTL high is only around 2.4v. One problem I do sometimes have is the schmidt triggers have a lower threshold than TTL, which can cause problems if another device does not drive close enough to the negative supply rail.

[Cats Eyes]

No, I'm not sure of anything, just reporting what the spec says for the 12F675. 0.8Vdd required for logic high. So if Vdd=5V, then 4V would be required for logic high to be registered. That's my interpretation of what the spec says, but I could be wrong. Certainly wouldn't be the first time.

You should have stuck with your original post. Use 3.3V supply for the PIC and you should have no problem. :) I was thinking PICs required 5V, but I just checked the specs and they say the PIC will still run down to 2.5V (lower if you don't use the A/D, but we'll need that) as long as you stick to 4 MHz. If you are running off 5V from the RX, perhaps you could just stick a couple of silicon diodes in the supply to drop it down to around 3.8V -- that should work fine. Did I get all that correct?

-- Kevin

[Tristar500]

Anybody have a circuit for a good 3.3 vDC power supply that can handle a wide imput range of voltage?

[MX]

Anybody have a circuit for a good 3.3 vDC power supply that can handle a wide imput range of voltage?

How wide? I use a SEPIC regulator on my altimeter to handle input from 3.5 up to 16 v or more. Output is 5v for the pressure sensor, then a simple linear regulator off of the 5v to get 3.3v for some of the other ICs.

MX

[Tristar500]

6 to 16 would be more then wide enough..
LF

[MX]

How much current?

[kd7ost]

I use a Low drop out, fixed 3.3 vdc LM1085 in a TO220 case. It operates up to 3 amps and is simple and efficient. You can put 3.4 to 25 vdc into it. I have routinely flown them in excess of 100,000 feet powering a Garmin geko 201. You need a .1uf and a 10uf capacitor with it and that’s it. Some guys like the converters but these are simplicity in action. The small amount of loss is not typically significant unless you’re operating without surplus current. I use a single 3.7 vdc 1400 mah LiIon cell and run the geko in excess of 12 hours. (I don’t know for sure how long it will run because I’m not going to deep discharge the cell to see where it fails at.)

Dan

[MX]

And you can probably use the excess heat to keep the rest of your electronics warm.

MX

[kd7ost]

I just found this link posted on Mr. RC-Cam's site. (http://www.rc-cam.com/forum/index.php?act=idx)

http://www.dimensionengineering.com/DE-SW0XX.htm

I never knew there was such an animal but I'm going to get me some. This should work nicely, but there's no information on it being cold soaked at high altitude. I think it would be worth checking out, but it's hard to trust new systems without redundancy in an application like yours. All the eggs are in one basket. It does use a TO220 form factor though so if you started out with a fixed component, you could switch to this later with just a little solder work. Thank you Mr RC-Cam.

Dan

[Tristar500]

So basically this little gem could be used as a stand alone BEC?

[kd7ost]

So basically this little gem could be used as a stand alone BEC?

Looks that way. Provided you meet the input requirements of course. They have a 3.3 volt version which is what I'm going to get for my UAV. On my capsule I don't think I'll use one. Since I have a small differential between my input and output, I don't get any heat off my fixed LDO unit. I'm probably as efficient as this new device but with the security of small parts count and no noise being generated by switching. (Something that you might have to deal with in a switching power supply) In a fixed regulator you get your worst efficiency when your voltage differential is greatest. 30 volts in for 3.3 volts out is bad. You’ll get a lot of heat at full rated current. I’m using a 3.7 VDC battery to a 3.3 volt regulator for my GPS. The Lipo reads 4.2 VDC without load and the geko isn’t much. That’s in the capsule. It runs for a long long time and I’m not worried about too much current in that set up. I don’t generate heat, and I don’t seal my capsules to ambient conditions.

In my UAV I have a 6 volt source that I would like to use. That would allow me to remove the 3.7 VDC Lipo and get out one more cell that I need to charge. I think that will make enough of a difference to justify the switching unit there.

I’m going to be doing a test flight with a couple other TVNSP members here in the next month or so. I’m running my geko oriented poorly in a small parasitic capsule just as a worst case test. I wouldn’t be apposed to putting one of these units in for power and reporting the results to you if you like. I plan to packet at about a 30 second rate up to 75,000 feet or better. (They have bigger capsules so I’m not sure we’ll get to 85k’ to 100k’) I don’t know when you plan your flight though. You might launch before we do.

You’re welcome to peruse our yahoo site to keep up with launch information.

http://groups.yahoo.com/group/tvnsp/

Dan