Small low-cost embedded board for model airplane

I think your requirements below are very optimistic and your main requirement of low power and low weight will not be met by an off the shelf board.

Once all the wiring, sensors (and their boards), shielding (for A/D at least due to local transmitter), your weight and power problems will be back to bite you. Even the weight of the SD card and its socket have to be included in the calculations.

I think you have two choices

Reduce your requirements and sensors to start off

Design your own board for the specific task.

Simultaneous sample and hold is rare on off the shelf embedded boards and even rarer on low power and low weight. Considering that most of your sensors operate in Hz or 10's of range, your sampling rate is 76Hz per channel which seems over the top to me. Higher A/D sampling rate means more calculations per second, which means more power used by CPU etc.

I would have expected for these types of sensors a sampling rate of

10 to 20Hz per channel giving 130 to 260 samples per second. Considering the nature of the sensors being slow response and the application simultaneous sample and hold seems unnecessary.

Some microcontrolelrs have these built in (to varying degrees of useability), and this can be bit banged, external single chip controller or even PLD.

I can see a need for 3 UARTs, not the fourth. Adding the extra UART requirement, reduces your choices of boards/microcontrollers.

There are lots of microcontrollers that have ports for GNU compiler see

Except for the current sensors, the rest have response times, that mean the output changes if you are lucky at 10Hz. See comments above about A/D. I actually doubt that the current sensors (probably for measuring power supply load to this board and main radio control) actually need to be monitored more than 1Hz anyway.

Keeping your transmitter frequency out of the sensors and wiring will be interesting.

Unless your airplane is flying at exceptional altitudes (1000's of feet) or doing very high speed manoeuvres the signals coming out of the sensors are going to be a very small part of the sensor ranges and will need amplification before sampling.

Which means you have a timer/counter, counting pulses and reading the result every second at the fastest with range of 0-167 pulses per second, which you can moving average to gain the rpm.

Similar approach to rpm, but becomes a running total (or running subtraction)

Thats a lot of wiring as each sensor requires 4 wires, might not another a/d convertor reading thermistors be easier and lighter. Also how do you keep the transmitter out of the sensors and their wiring.

Have you totalled up the power consumption of all your sensors, GPS and secondary transmitter? Then seen what power budget (battery size) that will need for your expected time duration before adding any form of embedded board?

I think you will be surprised how much power they require and then how much the battery weight will be for them alone.

Then see what you can find for computer control.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

and accuracy of 1 in 65000 (16 bits)

You must have very good sensors to measures 0.00001V

10 bits (0.001V) is more than enough for most projects.

I would also question the need for 16bits of resolution. I doubt any of these sensors have more than 10 or at most 12 bits worth of signal. Actually I wouldn't be surprised if 8 bits was overkill.

Albert, you need to ask what is the resolution you need for acceptable results and also what resolution the sensors are capaple of.

Robert

The OP might also reconsider the need for sample and hold. A characteristic of successive approximation a-d converters built out of d-a conversion is that they always measure a value that existed somewhere withing the conversion period. A further advantage is that the multiplexing can be done entirely digitally, so that the cost of an added channel is that of a single comparator (and possibly a front end op-amp). D-a converters are generally much cheaper. The front end op-amp can easily implement anti-aliasing filtering, besides the gain and impedance matching.

--
 Some informative links:

You did not say if your signals are AC or DC. If you have AC signals you need to specify the bandwidth, mainly the low end of the frequency band. The sample rate sets the high end. I assume you need DC inputs. Are they single ended or differential?

The only hard part of this is the 4 UARTs. That may require a separate chip since most low size and low power MCUs only have 2 UARTs. A pair of UARTs can be added with a small CPLD or if the bit rate is low enough, you can bit bang it.

BTW, when you specify things like small, low power, light weight, you have not really specified anything. Adjectives like these are not useful in selecting boards or components. Numbers are very useful! Do you have a size limit, a weight limit, a power limit? I expect you will find that size and weight will be swamped by the size and weight of the battery unless your mission time is very short. So it is likely that the power spec is the most important. Can you provide info on the mission time you require and how much power your sensors will be using?

You don't provide any info below on what the UARTs and SPI interfaces will be doing. I guess the SPI might be for the SD card interface and the UARTs might be for controlling the sensors.

Not a problem for most MCUs as vendors can supply a code size limited tool or open source tools can be used.

Can you give the accuracy needed of each type of input? An input range of 0-5 volts is not an issue since it can be lowered using a divider. But the low voltage of the current sensor, 0.5 volts, will require an amp if you need the full resolution of the 16 bit converter. BTW, you also need to spec the accuracy of the ADC. Few 16 bit converters are

16 bits accurate. This is an area where the accuracy required will drive up the power consumption and thereby the weight of the battery.

What do you need to do with this sensor, count the pulses within a period of time or measure the time between the pulses? Most MCUs have a timer/counter input that can help with this, but again, the range and resolution of the signal is required. At the fastest end I believe this works out to 6 ms per pulse which means you can use the timer to measure the period and likely use software to catch the timer overflows on the slow end. What is the maximum period you need to measure?

I assume the flow rate is not very high and these pulses will be rather slow.

What is the update rate? Do the sensors have an event output to trigger a measurement or is it periodic?

I have recently worked with these and there are some very nice units available as well as some very much nicer units coming down the pike shortly. I believe there are any number of "single chip" solutions which means two chips, one RF and one digital. We settled on a very small module from Fastrax while another very small module from uBlox came in a very close second. If you really want small size, you can use the ARM MCU inside the GPS module to do your other functions and save the size and weight of the separate MCU. But the vendors charge a rather stiff amount for the tools. IIRC Fastrax wants $10 large! Please keep in mind that a GPS receiver requires an antenna and there are positional requirements to be able to get a clear view of the satellites.

In reality, your requirements are not all that hard to meet. It will be important to know how much processing you need to perform or if you just need to record the data. I expect you can do this all quite easily with an ARM MCU with the exception of the 16 bit ADC with 13 inputs. That will require an external chip and you are not likely to find this on a typical small board. This may have to be a custom board, but that can be much less expensive than you may think.

I won't reiterate what others have already said, but there are extra considerations at the A-D for starters:

What is the output impedance of the sensors? Most A-Ds require a low impedance source for a number of reasons, which would possibly mean adding buffers for each channel.

Then there's the current sensors. 0-500mV ? Is that the sense range at the sensor? If so, is the measurement floating? high side? low side? All these impact the choice of sensor and amp (high side amps are available but you have to be careful - sometimes it's better to roll your own with good instrumentation amps). A good amp such that you get a transfer function of 0 - 10mA -> 1 - 4V is easy to design (Note the offset).

As to GPS - I currently use a single BGA solution from Falcom (JP-13S) that has all the necessary options on board (runs a SirfStar 4 chipset), but it's not particularly cheap. Going down-market a little can save a bundle.

I *will* reiterate one thing a number of others have mentioned; the A-D resolution. At 5V, a 16 bit converter has a nominal resolution of

76.3uV per bit where one might think the nominal quantisation error would be about 31.15uV, but given system noise this is very hard to achieve (it's difficult to get true 10 bit performance!) apart from other issues common to such devices (DNL, gain error to name but two standard specs). Indeed, to get this low an error, you would need a very low source impedance indeed - you are starting to get close to the thermal noise floor even at 10k bandwidth, 1k source impedance. This is an area where you can really get burned - if you can get away with 10 bits, then do so. Most 16 bit converters have an ENOB of around 13.

So, as others have said; some real numbers would help. Low power can mean 100mW or 50W - it depends on context.

Cheers

PeteS

Actually 4 bits is probably adequate, most likely he is using the Analog Devices gyros and accelerometers, most of which have +/- 10% accuracy.

Typical newbie mistake, (buys a 16 bit A/D and assumes he will get 16 bits of accuracy from any sensor he hooks it up to)

He may actually get 10 to 12 bits of RESOLUTION in the data. Accuracy is such a nebulous thing with sensors like gyros and accelerometers. He may need to self-calibrate at known starting conditions and assume minimal temperature-related drift.

Been there, done that, pulled the computer out of the hole in the desert.

Mark Borgerson

I think the reason he wants the sample and hold circuits is to measure the values at the same time. I am sure he is going to merge the data to calculate his position and orientation. I expect this is easier if you have data that is updated at that same moment rather than data that is spread out in time.

Considered the response time of the sensors, along with all the other issues a 10Hz to 100Hz per channel sample BURST at 10 bits then averaged will be so close to same instant as to make no difference. I doubt he will see large changes on most of his signals anyway, without venturing in most countries into CONTROLLED AIRSPACE.. (usually above 1500 feet).

Most of his signals will need front end amps to amplify the region he is interested in, as well as deal with all the other issues.

Basically his initial requirements, have many issues not least to get all that in, with its batteries (even for very short flight time) will be a large weight, so without knowing the payload[1] capacity of the airplane and then flight time it is difficult to achieve any sensible answers. His other major issue is the position of three aerials (Radio control, data and GPS) to not interfere with each other and best position for normal use. E.G. GPS on top, others below and spaced away from each other, GPS and anything they could foul.

[1] Be interesting to see about how this is mounted to not affect the stability and performance of the airplane.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

You make a lot of assumptions. I don't know what he needs since we don't have the full requirements. But I can be fairly certain that you don't need an antenna to communicate with an SD card. He never said he was transmitting data, he said it would go onto an SD flash card. GPS does not require an external antenna. Have you ever seen many GPS receivers that required an external antenna? The one we are building has an internal antenna.

I am willing to give him the benefit of the doubt and not try to second guess what he needs and does not need. I think he asked for advice on available boards which I have not seen many repilies to.

Not really a few not many he said he wanted low power in an airplane that also suggests radio controlled not human controlled as power availabilty is LESS of an issue in human controlled. Low weight also suggests radio controlled (or autonomous flight path e.g. drones).

Human controlled aircraft already have various instrumentation and possibilities for feed of for pressure, altitude, attitude, etc.. Payload of a sensor system compared to weight of a human in human controlled aircraft.

That's true enough..

That is what I assumed the SPI was for and made no suggestion of that.

He did see below...

No all data was to SD card, SOME selected data transmitted see later.

Depends what else is around, with a transmitter on board I would want all other receivers and all sensor circuit shielded. Depending on airplane body material it may be better to have an external aerial, also to have a metal ground below to mount on depending on the effects of everything else loaded including things like servo motors. Positioning of aerials (even internal) would matter for what it will pick up from all the types of transmitters in a small space.

From his FIRST parargraph in the original post

Which clearly states 'send selected data to the ground', which to me rather heavily suggests a trasnmitter to send data. Hence his large UART requirement, which is probably

GPS (upto 2 ports depending on model used) Data transmission (one port probably TX only) Debug (one port)

Unless he has another use for the last serial port.

I personally think it was a newbie wishlist expecting somebody to have made the perfct system already, and that it was like building bricks to be plugged together without anything else.

I also note that the majority of these types of requests, airplane mounted, battery operated for years with no power source/battery life details, real time video via a PIC, complex system with disparate requirements on a pre-made board seem to be MAINLY from googlegroups posters. Who seem to think that lots of configurations exist like PCs preloaded with software specifically for their application.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

I have worked on a similar project. I think you should cut back to a more reasonable and practical subset. I also talked to someone who did this on a larger scale on a military project and had the funding and team to do what you are talking about.

New Micro's isopod stacks with gps on the top might be a good starting point for your hardware. But I think you should start with a more modest list.

A simple stall sensor, a switch held by wind on the leading edge of the wing instead of a full blown ;-) vario is the sort of thing you might be able to get away with. And using a simple rate gyro in the control circuit and monitoring it in software might be a replacement for the full acceleronmeter package etc.

Then shrink it all down into one state-of-the-art full-custom VLSI circuit and implement it on an aero-gel substrate so that it has about the same weight as air you have really great brain for flying robots!

But short of that you can get most of what you descibe with a few small boards and it can be reasonable small and fit on all but the smallest radio controlled aircraft.

that would help, the 10% accuracy I listed above was gain accuracy, so he would need a rate table to callibrate that out, it's a big project to calibrate INS sensors, but if you do you can get better then 10 times the published specs, the big errors tend to be repeatable.