Which A/D should I use (build)?

[LukeZ]

I'm getting the hardware together for my UAV project and I'm trying to decide what A/D converter I should use. The analog inputs I need to read will be primarily from the accelerometers and gyros (I'll be using Analog Devices MEMS sensors for those). There will be some other things like temp, maybe an AOA indicator, I'm not sure what all, but the performance/resolution on those others won't be nearly as critical.

The on-board processor is a PC104 computer, so for interfacing to the A/D I can choose from either the serial port, parallel port, or the ISA bus. I've found quite a few A/D boards and projects that could work with all three. I'm not sure I'm smart enough though to figure out which one is best, or even what criteria should be most important.

I understand the bit about 'bits' :), and it seems to me that 12-bit resolution should suffice, perhaps even 10 bit would. What I'm not so certain about is this stuff to do with the sampling rate. How many samples a second would be the minimum? Of course the effective rate at which the processor will be able to read the samples is also going to depend on how it gets the data: serial, parallel, or ISA.

ISA boards seem to be the best, but are also bigger and cost the most, especially if I go with a PC104 form factor ISA card: the cheapest I've found is around $300. I kind of like the parallel port solution since I'm not likely to use it for anything else, but this guy (http://www.hardandsoftware.net/) seems to think it's not high-performing; he says practical sample rates are limited to about 1KHz/sec. However, here's a nice kit (http://www.mpja.com/productview.asp?product=8418+KT) I found that looks like it does a pretty good job. The data sheet says it can run a conversion in 10us (100K/sec), which seems pretty fast. However, the data is read serially through the port so the actual read speed will be however fast the computer can read 12 bits in a row (I guess). The input voltage for that project (0 -4) isn't the best but I suppose that can be worked around.

Using a different design than the one above it seems perfectly possible to me that you could read 12 bits of data in true parallel fashion from the parallel port, and I don't know how you could get any faster than that. I don't have a circuit for it but I think it's possible.

I'm not averse to building my own circuit; I enjoy soldering and tinkering so that's not a problem. In fact I probably prefer a homebuilt solution, as I'll get to learn new things and I'll have that nice warm fuzzy when it's all done.

Anyone have any thoughts? Anything I'm not thinking about that I should be? Any geniuses smarter than me want to help me come up with a circuit for the parallel port (I have a few ideas), or is that not a good approach?

[Gary Warner]

I wouldn’t think that fast data movement would be paramount. 'Fast', is fast enough, for most electronic/physical feedback systems. In fact, it’s usually too fast for our needs, requiring slowing, buffering and other measures to obtain stable control.

Now, resolution is a different beast. I'd go for the highest resolution I wanted to code for. In that, I mean you could end up getting more data than is necessary for the end product, just making things more complicated than necessary. Still, too little resolution and it might not be able to meet the target results.

One would have to fully understand the project and it's objectives, to be able to recommend (or conclude) that one process is better or worse than other alternatives. Can you breakout specific tasks and their functions?

For example, if you want to read altitude with a 10 bit A/D, it's safe to say that for 'auto-landing', the resolution won't be easy to deal with, so far as code. If you want to scale the input, 10 bit A/D will be fine. Of course this is a hardware pre-processor function. But if you want to read 'raw' data, 10 bit's wont' even come close, for the given task.

I'd like to provide my input for this project that's meaningful. To do so, I need to know what the goals of the 'UAV' are and what performance you are looking for. Without it, I'm just yelling into the woods in the general direction from where I hear a cry for help.

Gary
--

[william541]

I have worked with the PC104 form factor several years ago and they were none too speedy especially when the operating system gets in the way of critical timing.

My suggestion would be to off-load the A-D section to a dedicated microcontroller that could do most of the pre-processing (filtering) for you as well as scan multiple A-D ports without intervention from the host (PC104). Then too, this same board could host any analog signal conditioning you wish to do.

Micro controllers are available with 8, 10 and 12 bit A-D and many come with UARTs, I2C etc. Let the micro do the repetitive A-D tasks and the host can concentrate on large number crunching.

Done this way, you may find a serial port is fast enough. If not, you could interface to the ISA or parallel port. Since the ISA is only an 8-bit port, you would most likely need to do several R/WR cycles anyways. Lots of different ways to accomplish this.

You could also use a RS485 or CAN multipoint bus to connect all the sensors to the host. This would make it plug and play as far as adding more "smart" sensors later. RS485 (slower/less expensive) and CAN interfaces (faster/more expensive) are readily available for the PC104 (even some that are optically isolated). Then each of the sensors you build would have their own on-board micro to take measurements and report over the serial bus to the host. This would add a lot of flexability to the system.

Just my 2 cents! -Bill-

[LukeZ]

Gary:
I guess for the sake of this discussion we could say the objective is to read data from an acceleromer & gyro in order to determine the state of the aircraft in a given axis. The larger objective, of course, is to have the processor be accurately aware enough of what the aircraft is doing to fly it safely. The final platform hasn't been decided on let alone built, but in any case it will be a fixed-wing aircraft that we may assume is inherently stable- so we're not talking a heli here, and it doesn't need to do aerobatics. It won't be takeing off or landing autonomously, at least not at this stage, so as far as performance it's pretty basic. It just needs to be able to fly in a straight line and make slow turns to new headings.

Movement and angle along any axis will be measured with an accelerometer and gyro, much as you've done on the yaw axis with your project. I can probably get away with just measuring the roll axis, but I may go with the others as well. Airspeed, altitude, and compass heading will also be measured so I know where I'm going, and of course it will have GPS. Some of those other sensors will involve an analog reading as well, of course.

It's safe to assume I only have a basic understanding of many of the concepts involved here, but I do know that I will need to convert several pieces of analog data into digital form for the computer to then take action on. The piece I'm on now is how to get those analog values into my pc, given the various ways of doing it.

I'm trying to understand what you meant in your example with landing. When you say 10 bit 'raw' data won't be nearly enough, do you mean that because a 10 bit piece of data can only have about 1000 different values, I'd only be able to measure something as crude as 1000 feet, or 1000 inches, or whatever the unit? In that case, yeah, it would be awfully crude. Of course if I was measuring millibars of air pressure one thousand divisions might be enough to have a decent idea of altitude. I'm probably not understanding you right... like I say, I'm new enough that I probably don't even know the right questions to ask. If you can help me be more specific, I'd do it :o


Bill:
I am going to try to do some reading on CAN and RS485. Just from my quick search they seem to be a different beast from RS232 alltogether...

The OS on the computer is Dos (DR-Dos), so I don't know how much that is going to interfere or not... All programming will be in C or Assembly. But I agree that offloading as much work as possible to other controllers is ideal. It sounds like with this approach, the decision I have to make is what controller to use, based on two things: the performance of its on-board A/D, and how I want it to output the data (serial or otherwise)- though this second aspect is probaby more a function of how I code it, right?

[william541]

I am going to try to do some reading on CAN and RS485. Just from my quick search they seem to be a different beast from RS232 alltogether... The OS on the computer is Dos (DR-Dos

LOL, we used Dr-Dos on the PC104 I was referring to as well! All tucked inside a Disk-On-Chip... FYI, this product got replaced by a 8052 running at a slower clock speed, but had almost twice the performance.

If you are going with a "newer" version of a PC-104, it may already have two UARTS and usually at least one that is ready for RS-422/485. RS-485 is similar to RS-232 except you are using a twisted pair for bi-directional communications instead of RXD and TXD lines. For the hardware you basically need a 422/485 transceiver chip connected to your 232 lines. On the PC-104 end, if you check the voltage levels of TXD/RXD, you may not even need a 232 level translator. On the microcontroller ends, typically you can connect the 422/485 transceiver directly to the RXD/TXD lines. The transceivers are very inexpensive and usually come in an 8-pin package.

As for your communications protocol, you can do just about anything you want. As for the micros, you have quite a selection that already have UARTS in them that can be used for 232 or 422/485 communications. If you decide on using CAN, then your micro list gets much shorter unless you want to use an external CAN controller. From the sounds of it so far, I would think RS485 would work fine to start with.

As far as resolution you and Gary were discussing, even if you used a 10-bit A-D, you could always use a GPIO pin or two to change gain and end up with a resolution of 11 bits or more. The altimeter is a perfect example, high gain ( 6" /bit) close to the ground and low gain (10'/bit)when you are up high. Or you could keep the same high gain and just use the GPIO pins to level shift the analog signal as you gain altitude. The micro could keep track of this and send decimal feet to your host processor who would be none the wiser.

Have Fun, Bill

[sesat]

The larger objective, of course, is to have the processor be accurately aware enough of what the aircraft is doing to fly it safely

Luke, in your situation I see strong merits placing the AHRS function offboard from your PC104 processor. You would place your accelerometers, gyroscopes, pressure sensors et al tied to a A/D converter which is tied (via SPI) to a microcontroller. The microcontroller will do the filtering and state estimation. This microcontroller in turn will provide state estimate data to your PC104 system through a serial port.

The state estimate data is so much less than the raw sensor data, and will not saturate a serial connection. The Analog Devices part I'd suggest you look at is AD7738. Feel free to plunder the work already done at autopilot.sf.net


Ram.

[Gary Warner]

I have to agree with everyone that the pre-processor idea would be best.

I'll leave the aspects of the PC104 to others, since I haven't jet played with this.

I too am working on an UAV. The slip/skid feedback is a part of that. I've made and flown an AOA feedback system, though I'll have to readdress it to improve the results (next PIC Project thread). Next, I'll read and control bank angle, then altitude. Add a GPS to the package and I'll have a plane that can fly autonomously. Add precise control over these functions and I'll have a plane that can takeoff, fly and land without any outside input (the holly grail of UAV).

What gyro do you plan to use? Piezo or mass?

Gary
--

[LukeZ]

Bill:
Ok, let me make sure I've got you right on the RS485 stuff. My PC104 is the rather basic MZ104 (http://www.tri-m.com/products/engineering/mz104.html) from Tri-M Systems. It has two standard RS232 ports. I can get an add-on card that has 485 ports though, and I'll need to get additional ports in any case. The GPS and the modem will already take up the two on the board. Here's some PC104 add-on cards with reasonable prices: one with two opto-isolated RS485 (http://www.embedded586.com/epc/tsiso485-h.html) ports; and here's one with four serial ports (http://www.embedded586.com/epc/ts-ser4.php), two of which can be RS485. With a board like one of those, will I even need a transciever on the PC104 side?

So then on the microcontroller side, I have an A/D chip, like the one Sesat recommended, feeding data into a microcontroller, which then outputs processed information through a 422/485 transciever into the RS485 port on the PC, right?

This sounds doable...


Sesat:
I definitely do plan to use what's been done with the Autopilot project. From reading the posts on their forum I understand some considerable changes will need to be made to the Kahlman filter formulas in order to be useful for fixed wing... and so far no one has posted any information on the conversion. But that's a ways off, I'll worry about that when I get to it. I've read up on Kahlman and I get the theory, but the specific math is tough to follow. It's been a while since I was in college, so that stuff is getting rustier by the moment... ;)

Gary:
I'll definitely be looking forward to your next AOA thread. The gyro I was thinking of using is the Analog Devices ADXRS300 (http://www.analog.com/en/prod/0,,764_801_ADXRS300%2C00.html), however, I'm seriously considering purchasing it from Spark Fun electronics, which offers quite a few combinations of Analog Devices accelerometers and gyros on small breakout boards: I do like soldering, but I can't do ball grid array. This page (http://www.sparkfun.com/shop/index.php?shop=1&cart=227457&cat=71&) has the products I'm talking about, the combo boards are towards the bottom. It looks like a nice way to get a 2 degree-of-freedom sensor.

[Arp]

Thought I should chime in... since I am likewise cooking up something similar.

Until I get my smaller mainboard delivered in May, I am likewise using a 300 MHz PC-104 board (with Linux). Coincidentally, mine also originates from Tri-M. :)

My observation:

There exist various RS-232 data loggers -- with different resolution, performance and functionality. They generally contain some selection of built-in sensors (say for example pressure, humidity and temperature), which are frequently complemented by expansion inputs (for example to read battery voltage).

If you found a logger with suitable functionality (both in terms or sensors and protocol)... you might succeed in solving multiple problems described above:

-- Offloading measurement to a dedicated (and generally well tested) subsystem
-- Possibly getting more liberty with polling (no bit-banging or other nonsense consuming time on the main CPU)
-- More time to achieve robust and fault-tolerant serial communications (should never fail, and if failure is inevitable, should fail safely)

[Gary Warner]

Gary:
I'll definitely be looking forward to your next AOA thread. The gyro I was thinking of using is the Analog Devices ADXRS300 (http://www.analog.com/en/prod/0,,764_801_ADXRS300%2C00.html), however, I'm seriously considering purchasing it from Spark Fun electronics, which offers quite a few combinations of Analog Devices accelerometers and gyros on small breakout boards: I do like soldering, but I can't do ball grid array. This page (http://www.sparkfun.com/shop/index.php?shop=1&cart=227457&cat=71&) has the products I'm talking about, the combo boards are towards the bottom. It looks like a nice way to get a 2 degree-of-freedom sensor.

That was my first visit to Spark Fun. That was a salivating experience :). I now have it book marked.

Thanks.

Gary
--

[william541]

With a board like one of those, will I even need a transciever on the PC104 side?.
With the 485 expansion boards, you will not need a RS485 transceiver on the 104 end, you would be more than covered. Even a single 485 port would probably handle all the sensor connections. The nice thing about this method is that if you should decide you need more performance on the PC104 side, you can always upgrade the 104 and possibly do without the 485 expansion if the new board has the resources. Think of it as an upgrade path with the ability to reuse the same sensors...

So then on the microcontroller side, I have an A/D chip, like the one Sesat recommended, feeding data into a microcontroller, which then outputs processed information through a 422/485 transciever into the RS485 port on the PC, right?
You got it, do as much pre-processing as you can in the micro and only pass the results to the 104 on request. This will keep the message lengths down and free up bandwidth for other things. To start your project, I would choose a microcontroller with the A-D on chip if you can (personally I would choose a Mega AVR or PIC micro), it is one less interface to worry about. The few times I would go with a seperate ADC chip is if you need sampling rates so high that only a video ADC would work. Or if you are working with a very low noise or very high resolution system. With proper layout and circuit design, the on-chip ADCs work very well, especially if your ADC Vref is above 3 VDC. Make sure you have a well filtered analog supply and you will be fine.

Do some pencil pushing on the resolution requirements and see what hardware could meet those requirements, then take it from there. Typically I choose the worst most complex task first and chances are that the same micro will work for every sensor in the system. It is easier to learn one chip well than several only so-so.

One thing you have not talked about yet is the running of the servos etc. I'm guessing you still want to fly by radio and then pass control over to the on-board systems. I think some of the motor control micros with several PWM outputs may work well in this ap. And once again, you can connect it to the system via RS485. If this micro loses 485 communications with the PC104 host for what ever reason, then it can revert to radio control pass through mode with the hopes of getting it back on the ground in one piece. This may be another consideration when choosing a processor family to use.

Well I've rattled on enough, sorry about that.... Have fun, Bill

[LukeZ]

Bill:
Thanks for all your advice. It sounds like what I really need to do now is get started with PICs. Just searching this forum I've found quite a few resources, so I should have enough to keep me going for a while (probably for longer than my wallet will... :rolleyes: ) Once I get far enough in, then I may need more help with RS485 communications, but at least I now know the next steps.


Arp:
You mentioned you're getting a smaller mainboard in a month or so, mind sharing which one? I have seen some data loggers in my searching... I agree it might be a good solution if I could find the right one, but at least what I've seen seem to be for pretty specific purposes, and not always the most useful for UAV purposes. But it's not a bad idea, and I'll keep it in mind.


You know, what would be nice is if someone put together a total sensor package for UAV flight: there could be several approaches no doubt (such as IR for horizon reference), but for my example here a sensor package with 2 axis accelerometers, a gyro, temp, pressure altitude and airspeed. Maybe add the ability to include compass and GPS. Define some sort of standard communication protocol, and then the sensor package could interface with nearly any micro or PC104 or other kind of computer which could accept that interface. I guess the challenge would be to decide how much of the code would be on the micro and how much would be up to the user to customize on his end. What I don't like about most of the commercially available units out there is that you pretty much take what they give you and work with it, there's not a lot of custimization involved.

Well, when I get my sensor board worked up I'll post it up on RCGroups for what it's worth... may be a while though. ;)

[william541]

LukeZ,

Some more food for thought on your distributed sensor network. If you can make do with a slower peak network speed, then perhaps a LIN bus may work for you as well. The main advantage of the LIN bus is that it does not require a crystal based oscillator to work (unlike RS485). Most of the internal RC oscillators, like in the PIC, work just fine with LIN. There are several LIN transceiver manufacturers (Micro chip is one), but you can also bit bang an interface or in some cases, use the internal enhanced UART.

I'm not sure if there is a ready made PC104 solution for a LIN master however. More digging would be required for a solution here.

The slave transceivers also have some slick fault tolerance built in to prevent an out of control slave node from bringing the whole network down.

RS485 Up to 1Mbps, 32 nodes, 4000' bus length, twisted pair.

LIN Up to 20Kbps, 16 nodes, 120' bus length, single wire.

Anyways, thought you might be interested. If so there are several good AP notes about LIN on the Microchip web site and other sites as well.

-Bill-

[sesat]

Luke, have you looked at the Gumstix board? It runs Linux with RTOS patches on a 400Mhz StrongARM.


Ram.

[LukeZ]

Well, I ordered my first PIC, an 18F452. I also bought a programmer and my plan is to use Microchip's MPLAB and program in Assembly. The PIC has an 8 channel, 10 bit A/D built in, so I'll try using that first: if I need more resolution I can go to an external A/D later, but we'll see how this works first. I haven't purchased accelerometer or gyro sensors yet, I figure I'll work on voltage, current, temp, and things like that to start off with. I've already written my first blinking led program, just need the chip to arrive so I can test it!

I found a nice Application Note at Microchip on USART communications (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en012073) that looks like it should get me going on communication with the PC104. Bill, I plan on trying out RS 485. I still need to get a transciever chip, I'm thinking of the MAX489- I don't know if I really need full duplex or not but it doesn't look like it will hurt. Otherwise I could go with the MAX485.

I'll keep LIN in mind, but if the only advantage is getting rid of a crystal-based oscillator, then I'll probably stick with RS-485: I intend for my PIC's oscillator to be setup with an external crystal in any case. A separate crystal oscillator isn't required just for the RS-485 communications, is it?


Ram, I did look at the Gumstix, but I'm really not a Linux guy so I suppose I was a bit intimidated. When I first got the PC104 I was thinking I'd run Linux on it... I installed a SlackWare distro on the home PC I use most, and got it to dual boot with the existing XP installation. I figured I'd try to get familiar with it, but I pretty much gave up when I realized I couldn't even get an internet connection to work with it, since there are no drivers for my wireless card. I could have installed it on one of my other computers with a physically connected ethernet card, but good grief... I'm a geek, but these Linux guys take it to a whole new level. :rolleyes:

[william541]

I think you will find the half duplex will do all you need. The MAX485, LTC485 and ADM485 are all good transceivers for low power RS485.

Most of the small micros have 4 or 8 Mhz internal RC oscillators that don't do too bad a job. But if you have timing critical functions like frequency measurements or RS232/RS485 type communications, then the RC oscillators may not be time/temperature stable for reliable baud rate generation or high frequency accuracy. The LIN bus would allow both crystal and non-crystal based micros to be used together on the same bus. Just a thought, either bus should get the job done.

Good luck on the assembly programming. There certainly is something satisfying about a blinking LED on a new piece of hardware. "You spent how many dollars just to get a tiny light to blink?" Some people just don't understand.... With assembly, comments are your best friend as it gets a bit cryptic looking after a while. Once you get into it, you will be amazed how much control you have over the resources. I still prefer assembly over C, mainly because I'm not very good with C yet (too many rules and "odd punctuation"). VHDL is very fun though... I guess I just enjoy hardware more than firmware. But sometimes it takes both.

I like your idea of coming up with a standard bus and protocol for UAV sensors. A person could sure spend a whole lot of time in debate over which is the best etc and not get any real work done. That would be a busy thread for the trial UAV forum... Ha! Ha! -Bill-

[farid83]

hallo... i'm searching any ADC analog to digital converter circuit that can 'digitized' signal with serial/parallel connection... i wonder if someone here may have any information or sample circuit about adc..n would like to share with me... :)

[LukeZ]

Hmm... are you asking if there are any ADC chips that output serial data? Yes, I think they almost all do, but not usually RS232 serial, if that's what you're thinking. Typically dedicated ADC chips put out data on an SPI or I2C bus - this is then read by a microcontroller, which could easily format the data and output it over an RS232 connection or even a parallel port connection, depending on which microcontroller you chose.

This is not difficult to do in theory :rolleyes: ... assuming you're comfortable with microcontrollers and such.


Luke

[tve]

Check out the ads1100 if you can support i2c (2 wire serial) It is a 16 bit converter in a nice small sop-6 package. It has programmable amplification and it is cheap. Pretty hard to beat for a lot of things...

http://www-s.ti.com/sc/ds/ads1100.pdf