mgsn-development — MGSN development discussions

[MGSN-Dev] GSML Docs (finally)

[James C. <jw...@st...>]

MGSN Dev:

I've released some initial documentation on GSML, the Ground Station
Markup Language, which is the command and control protocol used by
Mercury.  They are online at:  http://mgsn.sourceforge.net/gsml/index.php.

We've recently moved from our home brewed specification file to defining
GSML in XML schema.  This allows us more diverse message structures.  We
also take advantage of the data binding softare, Castor.  We are
generating about 40K lines of code from about 2K lines.  Any changes to
the spec can be immediately updated in the Java source code used to
manipulate GSML messages.

Work is still underway on the 0.2.0 specification.  Any feedback would be
greatly appreciated.

--Jamie
jw...@st...

[MGSN-Dev] Mercury 1.2.0 prerelease 1

[James C. <jw...@st...>]

We've recently tagged the Mercury CVS repository to indicate our first pre
release of Mercury 1.2.0.  The tag is MERCURY_1_2_0_pre1.  Future tag
information will be online at:  http://mgsn.sourceforge.net/cvs.php.

We're about to make major GSML upgrades and tagged the system as a
reference point.  More information on 1.2.0 upgrades and status are at:
http://mgsn.sourceforge.net/docs/arch1.2.php.  There is still quite abit
of work underway.

Our first GSML docs will be released shortly.  We've recently migrated
over to the XML schema specification for describing GSML.  It's been great
so far, plenty of off the shelf tools to help us out.  We've generating
about 50,000 lines of code from about 1000 to do all our communication
modules.

Thanks.

--Jamie
Mercury Developer

Re: [MGSN-Dev] MGSN system diagram

[James C. <jw...@st...>]

Andrei,

Thanks for the diagram.  It's a good reference point to work from.  Here
are some thoughts.

- Label the diagram with a revision number so we can refer to a specific
copy.
- It would be beneficial to have a separate purpose/functionality
description of the system as a whole, not just the components.  What is
the goal of this system?  This will boil down a set of specific
functionalities that we will define in GSML.
- We need to place this in the context of other work.
  What needs to be done with Mercury to enable this?
  What have others done?  Specifically, we need to summarize Andreas' and
  Bartosz's work.  Does your diagram overlap at all?  Any redundant
  systems?

Let's come up with a working system diagram, building off what you have,
along with a description of the MGSN.  Focus more on what the system does
rather than the components (since there are an infinite number of ways to
implement the functionality with the components).

It would be good to come up with some scenarios to show how it operates.
How does a user register?  How does a user schedule a station(s)?  How
does a station register itself?

So far, here at Stanford,  we have been working from the bottom up.
First, enabling low level control via GSML of station resources.  We have
session level control.  Next, the network.  So, what are the functions of
this network?  Once we know these (and we have some identified already) we
can begin to lay out an architecture and build it.

For example, from a bottom/up perspective, we have stations, now we need
to network them.  How do we find them?  First step, a registration service
that allows ground station operators (or their software agents) to
register their capabilities in the MGSN.  ONce we have that, we can begin
discussing scheduling and VGS capabilities.

--Jamie



On Thu, 6 May 2004, Andrei Aron wrote:

> I'm attaching the diagram in pdf and doc formats.
> I am in the process of creating a tentative attack plan as well.
> Jamie and Mike, please send me any input you have.
>
> Thanks,
> Andrei

Re: [MGSN-Dev] MGSN system diagram

[James C. <jw...@st...>]

Too old?!  Just because we have degrees (or close), and kids doesn't make
us old?  Or does it?  Better than the alternative!

That's good news on your prototype.  Does your thesis describe the
prototype?  We have a copy of it.  Or is there additional documentation?

Mercury is ready for initial MGSN deployment and we hope to get that going
over the next quarter or two.  Hopefully, there will be some good
discussion here to get some working/prototype architectures laid out and
built.

Thanks for your input!

--Jamie

On Fri, 7 May 2004, Andreas Lenz wrote:

> Hi,
> I've seen your diagramm. At W=FCrzburg University we have written
> a software that could simplify implementation of Machines 1-4.
> Actually we have already prototypes for all of them except the
> ground station connections. These are really prototypes and more
> work is needed, but if you are interessted, there is documentation.
> P.S. Jamie: no SpaceOps, we are to old :-(
> Greets, Andi
>
> --
> NEU : GMX Internet.FreeDSL
> Ab sofort DSL-Tarif ohne Grundgeb=FChr: http://www.gmx.net/dsl
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> _______________________________________________
> MGSN-Development mailing list
> MGS...@li...
> https://lists.sourceforge.net/lists/listinfo/mgsn-development
>

Re: [MGSN-Dev] MGSN system diagram

[Andreas L. <and...@gm...>]

Hi,
I've seen your diagramm. At Würzburg University we have written
a software that could simplify implementation of Machines 1-4.
Actually we have already prototypes for all of them except the
ground station connections. These are really prototypes and more
work is needed, but if you are interessted, there is documentation.
P.S. Jamie: no SpaceOps, we are to old :-(
Greets, Andi

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl

[MGSN-Dev] Patched version of Predict

[James C. <jw...@st...>]

Hello,

I've released a patched version of the latest Predict release, 2.2.1.  
Mercury uses Predict to calculate antenna pointing angles and doppler 
effects for radio tuning.

The current version of Predict, 2.2.1, has a bug in the way it reads data 
from the socket.  This causes Predict to fail when using the "GET_DOPPLER" 
and "GET_SAT" commands via the socket interface to predict.

I've made the patched version of Predict available on Mercury's 
Sourceforge account at:

http://prdownloads.sourceforge.net/mgsn/predict-2.2.1p0.tar.gz?download

I've also notified the developers of Predict and they will be releasing it 
with the next version.

Thanks.

--James
jw...@st...

PS...We will be releasing mercury-1.1.2 by the end of next week with major 
bug fixes and updates.  Hopefully the documentation will be improved as 
well!