Small Linux HW to be carried in a model airplane

> >That's likely for programming, configuration and upload
> >download of data files.
>
> In other words, he is over-specifying.  There is no need for
> ethernet for those purposes.  He can do it all through one
> of the RS232 ports.  He shouldn't add weight to his airplane
> for functions that he can do without.
>

8 MB @ 10 kB/s = 800 seconds = 13 minutes.
Maybe he has other things to do than waiting for serial file transfers...

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Ulf Samuelsson wrote:
>
>> >That's likely for programming, configuration and upload
>> >download of data files.
>>
>> In other words, he is over-specifying.  There is no need for
>> ethernet for those purposes.  He can do it all through one
>> of the RS232 ports.  He shouldn't add weight to his airplane
>> for functions that he can do without.
>
>8 MB @ 10 kB/s = 800 seconds = 13 minutes.
>Maybe he has other things to do than waiting for serial file 
>transfers...

Why would he have to move 8MB even once?  An embedded system to 
control a model airplane shouldn't need to move that much data.
A good, fast linux system can fit on a single floppy, and there
is no good reason to collect data at more than 10 channels at
5 16-bit samples/sec each,  that's 200 bytes/s - 360K/hour.

 
 

On Mon, 7 Feb 2005 03:38:30 +1100, <Dussrviok> wrote:

>I am searching for a Linux hardware (which will be used in a model airplane)
>with the following specs;
>    * Small
>    * Battery operated (single power input 5v, or 9v or 12v)
>    * Light weight
>    * Supports min 4 RS232 ports
>    * Parallel printer port (for digital I/O) (or 8-16 digital I/O)
>    * Optional USB port
>    * 10/100 Ethernet port
>    * Capable booting either from a USB memory and/or a Compact Flash disk
>
>Any recommendation? 
>

Have a look at this site for some ideas.
http://members.shaw.ca/sonde/index.htm

> Why would he have to move 8MB even once?  An embedded system to
> control a model airplane shouldn't need to move that much data.
> A good, fast linux system can fit on a single floppy, and there
> is no good reason to collect data at more than 10 channels at
> 5 16-bit samples/sec each,  that's 200 bytes/s - 360K/hour.
>


It is normally there to load the operating system and a flash disk
Linux fit compressed into 700 kB, but if you for
some reason like to program in PERL,  then it
quickly adds up.
You will obviously not fly with an Ethernet cable attached,
but you could have a digital camera which takes pictures,
which you want to download once its landed.
If that is the case, then maybe he would want to download 256 MB.
Another alternative is for debugging purposes.
Some systems run considerably better if Ethernet is attached.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com

On Monday, in article <110e5gdnvtrg166@corp.supernews.com>
     _see.web.page_@_www.guymacon.com_ "Guy Macon" wrote:

>Ulf Samuelsson wrote:
>>
>>> >That's likely for programming, configuration and upload
>>> >download of data files.
>>>
>>> In other words, he is over-specifying.  There is no need for
>>> ethernet for those purposes.  He can do it all through one
>>> of the RS232 ports.  He shouldn't add weight to his airplane
>>> for functions that he can do without.
>>
>>8 MB @ 10 kB/s = 800 seconds = 13 minutes.
>>Maybe he has other things to do than waiting for serial file 
>>transfers...
>
>Why would he have to move 8MB even once?  An embedded system to 
>control a model airplane shouldn't need to move that much data.
>A good, fast linux system can fit on a single floppy, and there
>is no good reason to collect data at more than 10 channels at
>5 16-bit samples/sec each,  that's 200 bytes/s - 360K/hour.

Firstly with 4 RS232 ports you don't know what he is collecting data
from. Secondly no A/D was specified. Thirdly the flight time is not
known. Fourthly if any camera is involved for image capture the
data size is exponentially bigger.

Personally I would if possible save to CF Flash and use that to
transfer data.

The cost and weight of an ethernet port is likely to be the same
or less than the CF card and mounting hardware.

Unless parts of the hardware can be put into very deep standby when not
in use (USB, Ethernet, CF Flash) his real problem is going to be
power consumption, as this will have more effect on weight wrt the
battery size to be carried.

Downloading data sets after landing again is a good idea as in most
countries model aircraft do not have wide bandwidth telemetry channels,
10Kb/s with modem chips is the highest you can get on allowed channels.
Saving to non-volatile memory whilst in flight is also a good idea
to avoid problems with power glitches/loss for whatever reason.

Some of the bits might be overspeced, most likely with use of optional USB
and Linux. Then again it is not stated whether this is a control or
monitoring application and how much.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On 2005-02-07, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

>>8 MB @ 10 kB/s = 800 seconds = 13 minutes.
>>Maybe he has other things to do than waiting for serial file 
>>transfers...
>
> Why would he have to move 8MB even once?

It doesn't take much video to fill up 8MB.

> An embedded system to
> control a model airplane shouldn't need to move that much data.
> A good, fast linux system can fit on a single floppy, and there
> is no good reason to collect data at more than 10 channels at
> 5 16-bit samples/sec each,  that's 200 bytes/s - 360K/hour.

What about data from cameras?

-- 
Grant Edwards                   grante             Yow!  I once decorated my
                                  at               apartment entirely in ten
                               visi.com            foot salad forks!!

Paul Carpenter wrote:

>Firstly with 4 RS232 ports you don't know what he is collecting data
>from.

Sure we do.  He is collecting data from a model airplane. 

>Secondly no A/D was specified.

I wrote "bits." I never specified that they were ADC bits.  Whatever
kind of data he aquires, it ends up as bits.

>Thirdly the flight time is not known.

Sure it is.  It is limited by the weight of fuel and the weight
of providing power for the board.  Assuming a special kind of 
model airplane ythat flies for many hours without asking is no 
way to do a preliminary spec of an onboard computer.  the default
assumption should be a normal model airplane. 

>Fourthly if any camera is involved for image capture the
>data size is exponentially bigger.

Now you are assuming a camera just to defend there being an ethernet
port.  Why not streaming video?  Why not assume an onboard hamster 
with life support in case the plane flies too high?

>Some of the bits might be overspeced,

Indeed.  Then again, maybe he does have an onboard camera and hampster...

Grant Edwards wrote:
>
>Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:
>
>>>8 MB @ 10 kB/s = 800 seconds = 13 minutes.
>>>Maybe he has other things to do than waiting for serial file 
>>>transfers...
>>
>> Why would he have to move 8MB even once?
>
>It doesn't take much video to fill up 8MB.
>
>> An embedded system to
>> control a model airplane shouldn't need to move that much data.
>> A good, fast linux system can fit on a single floppy, and there
>> is no good reason to collect data at more than 10 channels at
>> 5 16-bit samples/sec each,  that's 200 bytes/s - 360K/hour.
>
>What about data from cameras?

If you are going to add on things that he never said are on the 
airplane, why stop at a camera or two?  Why not just assume full
360 degree IMAX-format streaming video?

  

On 2005-02-07, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

>>Thirdly the flight time is not known.
>
> Sure it is.  It is limited by the weight of fuel and the weight
> of providing power for the board.  Assuming a special kind of 
> model airplane ythat flies for many hours without asking is no 
> way to do a preliminary spec of an onboard computer.  the default
> assumption should be a normal model airplane.

There are plenty of "normal model airplanes" that can fly for
quite a long time.  On a decent day, a glider can fly for
hours.  Eventually, the receiver/servo batteries run down, but
the energy density of LiPoly cells is getty pretty high.

>>Fourthly if any camera is involved for image capture the
>>data size is exponentially bigger.
>
> Now you are assuming a camera just to defend there being an ethernet
> port.

Putting cameras in model airplanes is a pretty popular thing to
do.

> Why not streaming video?

It's been done.  The model I'm thinking about was a glider
lifted to about 50,000 feet by a small weather baloon, and then
released.  It flew semi-autonomously for a couple hours and
then landed at the launch site.  It had both a web-cam and a
35mm still camera.  That plane had an RF modem link so the
ground station could get live telelmetry and video.

> Why not assume an onboard hamster with life support in case
> the plane flies too high?

That would be somethign new.

>>Some of the bits might be overspeced,
>
> Indeed.  Then again, maybe he does have an onboard camera and
> hampster...

I wouldn't be at all surprised if he's planning on putting a
camera in the plane.  The hampster would be a bit odd.

-- 
Grant Edwards                   grante             Yow!  Did an Italian CRANE
                                  at               OPERATOR just experience
                               visi.com            uninhibited sensations in
                                                   a MALIBU HOT TUB?

On 2005-02-07, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote:

>>> Why would he have to move 8MB even once?
>>
>>It doesn't take much video to fill up 8MB.
>>
>>> An embedded system to control a model airplane shouldn't need
>>> to move that much data. A good, fast linux system can fit on a
>>> single floppy, and there is no good reason to collect data at
>>> more than 10 channels at 5 16-bit samples/sec each, that's 200
>>> bytes/s - 360K/hour.
>>
>>What about data from cameras?
>
> If you are going to add on things that he never said are on the 
> airplane, why stop at a camera or two?  Why not just assume full
> 360 degree IMAX-format streaming video?

Because cameras in model planes aren't unusual.  360 degree
IMAX-format streaming video would be pretty unusual. Especially
since the "format" is 75mm prints.

-- 
Grant Edwards                   grante             Yow!  .. over in west
                                  at               Philadelphia a puppy is
                               visi.com            vomiting...