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

RE: Satelite Prediction .NET Web Service

On 13-Mar-03 Dave Johnson wrote:
> Hi,
> I've just started playing with Microsoft .NET and c#, after many years
> doing Java tiered architectures. I'm not going to debate the pro's and
> cons :-)
> What I should like to propose, if anyone is interested, is web service
> for satellite prediction program with similar functionality to the
> Predict program by John Magliacane, KD2BD.
> The system would be a .NET web service using XML for queries to the
> service and responses from it. There would be a corresponding web form
> to display the information, and a published schema for those wanting to
> integrate with it. I've now got my dynamic DNS going on my 1Mb cable
> link so I'll probably be hosting it for now :-)

Sounds interesting.  I've been working on my own tracking software parts of
which are predict compatible, parts of which are using my own format (not
currently XML but I may switch).  Now I haven't been using c# or things like
that because I've been doing the development on linux (but trying to make it

It does have a few nice features:

1. It does provide a nice break between the calculation engine and the user
   interface.   When I started, I really just wanted a different user interface
   and such but I've ended up working on alot of orbit calculation code to go
   with it.  Now this could be fix with Phil Karn's idea of a tracking library.

2. Multiple client programs can share the data.  Your GUI interface,
   automatic control programs can all share the same data.

3. I've run across some limitations to the predict protocol.  Some data I've
   wanted was not available (he has added some of it), no way to deal with
   different locations, odd future prediction interface and such.

A few thoughts about this:

1. Try to make sure the network protocol is machine independent.
   a. People can mix and match clients and servers.
   b. People can run multiple platforms.
   c. It's a pain when I go over to a friends house to test some of the
      features of my software and I have my linux notebook controlling the
      doppler and his windows box controlling the rotator and they don't talk
      because he has a KCT card in his computer.

2. In some ways the communication delays can cause problems if your trying to
   do anything time sensitive.  The gpredict people had this problem and I've
   seen it some myself.

Now if someone wants to set up an XML server (or some other easily parsable
format) I've had some other ideas:

1. AO-40 schedule, alon, alat
   AO-27's tepr numbers are available, but the sun messed that up before I had
   a chance to add it to my software. :)

2. Satellite data:
   beacon frequencies, types
   call signs
   status (dead transponders, works only in sunlight, ...)
   weekly satellite report in XML? :)
   I have a bunch of this in my own format for my own program, but it would
   be nice to share.

3. Most keps seem fine in their current format, but what about something for
   keps with valid time ranges.  For example the keps from:

> A name, well how about YATS (Yet Another Tracking System).

I knew I needed to release my software sooner.  I have been calling it YaTrk,
but now I have to come up with a new name. :)

> If anyone is interested and would like to discuss it, please let me
> know.
> A few of the ideas will start appearing on http://g4dpz.homeip.net in
> the next few days.

I tried connecting to this, but the connection timed out.
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