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

ISS ground stations

Several threads of thought consolidated here.  Sorry if it's a bit hard to follow, but I didn't want to spam two message boards (SAREX & APRSSIG) any more than needed.

> Maybe we could use something like Phil Karn's Satellite Telemetry Protocol
> http://people.qualcomm.com/karn/papers/telem.txt
> And just put raw packet in as the telemetry.
> The good points of this:
> 1. It includes a timestamp of when the packet was received.  This would allow
> packets to be submitted later by stations that don't have a full time Internet
> connection.
> 2. It included the location of the receiving station.
> 3. It would allow all packets, not just aprs formated ones to be submitted.
> 4. You could tell which satellite it went through.
> The problem points:
> 1. It's format is not compatible with the existing APRS IGate system.  It would
> require setting up an parallel servers.  (Nothing says IGates can't submit to
> both)


Phil Karn's telemetry protocol looks really nice.  Incidently, Phil is KA9Q who wrote the DOS TCP/IP implementation I discusssed earlier.  This protocol would work really nice for a parallel telemetry passing system which could gateway over any APRS related traffic to APRS.net at a specified point.  For a system only intended for ISS and PCSAT traffic, it looks like a little bit of overkill (and this is coming from the king of overkill designs).  I do like the idea of dual porting data from a ground like station to both telemetry and APRS sites.  There is certainly nothing to keep traffic from going to multiple locations.

> A couple of questions did come to mind though:
> 1. Do the IGates put all packets on the net, or only the ones that look APRS?
> 2. How do you tell which ones are through the ISS?  Relay through N0CALL?

Chuck, I'm still wondering about these questions myself.  Perhaps Steve Dimse can spread some knowledge here.  For question 1, I did run across a SourceForge (www.sourceforge.net) project last night that might help.  It's called "aprsd" (http://sourceforge.net/projects/aprsd/) and looks to be the software these gateways are running.


> Is it possible that the IGates should act just like any NODE and put their
> ROUTING info in the packet header.  THus, the packet that starts as:
>    WB4APR>APRS,WIDE:stuff
> is UI digipeated by the satellite:
>    WB4APR>APRS,APRSAT*:stuff
> is picked up by KB2WQM's SATgate:
>    WB4APR>APRS,APRSAT*,KB2WQM-20:stuff
> Where the KB2WQM is the SATGATE and the SSID of 20 means it was heard on
> the xx downlink.  THis 20 violates the AX.25 spec for ON-AIR packets, but
> at this point, it is an INTERNET packet.  If this packet goes back to RF,
> however, if goes as a 3rd party packet in which the HEADER is part of the
> ASCII data.


That solution is so simple it hurts. :)  I don't even pretend to understand all the APRS specific information that can go in a packet.  This is an area I'm going to have to do some serious reading to fill a few knowledge gaps.  Still, it looks like this could be a simple yet elegant solution to picking up some ground station info.  Perhaps a future option for ARISS.net (and/or findu) would be a link to display receiving ground stations.  This could be useful for even terestrial users in figuring out which digipeaters they are reaching.


For those interested in my previous blathering about a minimal ground station,

On the receiving ground station topic, I've done some research over the last few evenings.  I can pretty much conclude that DOS is not the right platform for a minimalist station.  Almost no work on the packet drivers NIC interface or the DOS based TCP/IP solutions has been done in the last five years.  My feeling now is that Linux is certainly the way to go here.  Besides being free (as in beer) it opens up lots of future possibilities for enhanced functions that just wouldn't be practical under DOS.

Last night I managed to get Thomas Sailer's user mode (outside of the kernel) soundmodem driver (http://www.baycom.org/~tom/ham/soundmodem) working.  I ran a two wire audio patch cable from my radio (a TH-D7A) over to the computer sound card and like magic packets started decoding.  It should be a very straight forward exercise to write a small daemon to accept data from the soundmodem interface and pump it back out to TCP/IP.  Even better, according to the documentation, the soundmodem driver will run on a 486/66 platform.  These should be available for next to free at your average yard sale.

My efforts are now moving towards figuring out the absolute minimum amount of software needed to boot a Linux kernel to run soundmodem and a couple other daemon programs.  I believe this can be done in about 10MB-20MB of disk space.  Not the single floppy interface I had originally hoped for, but still pretty small.  My thinking right now is that this OS install can be sent on a zip file that is unpacked on a DOS FAT partition and then launched using a batch file to reboot the system into Linux.  A couple of dialogs to configure the sound card, network card, and call sign has you up and running.

This leaves the minimalist ground station with the following shopping list:

* 486/66 PC with 50MB IDE hard drive, 16 bit sound card, and Ethernet NIC
* 2M radio with speaker output patched to the sound card
* 1/4-wave ground plane antenna

With some yard sale and ham fest shopping, this should be doable for under $200.

Hopefully, I'll have something to offer on the minimal Linux install within the next couple of weeks.  I've found the information, now it's just a matter of putting all the pieces together on a machine at home.

Via the sarex mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe sarex" to Majordomo@amsat.org