[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Solving the need for ISA or USB slots and Serial Ports

> Date: Wed, 2 Jul 2003 11:14:51 -0400
> Subject: Re: [amsat-bb] Solving the need for ISA or USB slots and Serial Ports
> From: David Beach 
> How much effort/cost is required for an Ethernet interface on the 
> rotator controller, rather than USB/serial/parallel/etc? As more people 
> end up with Ethernet on their home/ham computers, the idea of having 
> the rotator on the network seems appealing - 'just' connect it to the 
> hub/router/switch and any machine could operate it. Anybody have 
> experience with this? Or thoughts in general?

If you are going to use Ethernet, you probably want to think about
what protocols you want to run within the Ethernet frames.  With
enough effort, you could encapsulate your rotor control protocol directly
within Ethernet frames.  However, an easier solution is to run
IP over the Ethernet frames, and then run your rotor control protocol
on top of IP (e.g., using TCP or UDP).  The advantages of IP include:

o	Many devices already support an IP stack, so your development
	would be limited to writing the rotor control application,
	rather than mucking around trying to implement network
	protocols directly on top of Ethernet.

o	IP potentially eliminates any distance limitations.  You
	could control your rotor from work, or from around the world.
	Of course, if you don't secure your Internet-attached
	rotor, then potentially anyone else on the Internet could
	control it as well.

My favorite embedded Ethernet single board computer (SBC)
is the Dallas Semiconductor TINI board.  This SBC has a
reasonably good Java implementation.  Some time ago, I
wrote some Java software that beaconed APRS frames.  Since
my balloon project hasn't yet gotten off the ground, the
software also simulated the output from a GPS receiver.
Of course, not having the patience for a (simulated)
three-hour balloon flight, I transmitted beacons fairly
quickly.  Unfortunately, the APRS Internet backbone
filtered most of the packets, but I still got a nice
track on FINDU.

The same software ran on my PC and on my TINI board with
only two changes:

-	I had to remove one "include" statement
-	The names of the serial ports are different on
	the PC and the TINI

Obviously, my next suggestion is that you write your
software in Java, rather than a platform-specific
language.  Using Java offers the prospect of running
the same software on a variety of software platforms,
including Windows PCs, Linux PCs, Linux non-PCs, etc.
By the way, you might even be able to run your software
on your Palm, although the GUI code will be radically
different between the PC platforms and the Palm.

(Every time I write this, several people send me e-mail
saying that they don't know Java, and have no interest
in learning it.  I don't remember if it is the same
people every time.  You may find that learning Java
is a lot more useful than, say, 20 WPM code.)

There are numerous non-Java embedded SBCs that come with
an IP stack.  They could also be used, although you would
be more likely to program them in a legacy, and largely
non-portable, language such C.

By the way, the TINI processor is $50 - $67 (for 0.5 or 1.0 MB,
respectively), and you probably want the $35 "socket" that
provides power regulation and connectors.

Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org