RE: [amsat-bb] RUDAK testing - help please

["Assi Friedman" <4x1kx@xxxxxxxx>]

Gentlemen,
We do have a design for a RUDAK emulator board which will enable anyone to
code, and test applications before they go on AO-40. The board is currently
pending review, and has not been approved by the BOD. Once we have a
decision, we will inform everyone how this will happen.
Assi



-----Original Message-----
From: bdale@rover.gag.com [mailto:bdale@rover.gag.com]On Behalf Of Bdale
Garbee
Sent: Sunday, July 14, 2002 4:18 PM
To: CDixon6901@aol.com; peter.guelzow@kourou.de; bdale@gag.com;
4x1kx@iarc.org; wd0e@amsat.org
Subject: Re: [amsat-bb] RUDAK testing - help please


CDixon6901@aol.com writes:

Hello Peter, et al.

Good questions.  Some misconceptions.  Let's see what I can do to help fill
in some gaps.

> is there no development board for the RUDAK DSP that will save porting?

The proposed development board for RUDAK DSP work was never completed.  We
would have to ask Lyle how much got done, I honestly don't know.

> > you are absolutely right..   this is a common problem, because
> > these software guys underestimate the necessary workload..
> > "It's only software" - you have heard that probably often enough.

I don't think that's entirely fair.

> > Not so RUDAK..  they haven't used the launch delays etc. to
> > improve there software. I guess they have a lack of manpower.

The necessary operational software for RUDAK and interaction with the
onboard
experiments was completed and tested before launch.

Volunteers to work on DSP software (all experimental, of course, since RUDAK
launched with hardware modems that were expected to meet all basic
operational
needs) were solicited several times in several forums before launch.  In
virtually every case, we got answers like "Yeah, that looks like fun.  If
the
satellite makes orbit I'll look forward to working on some things".  The
sequence of events after launch has kept most of those folks from ever
getting
very motivated, I fear.

The only other open issue is that the SCOPE team has generated new software
for their cameras since launch.  Unfortunately, it uses features in the
CAN-SU protocol that are not implemented in our CAN server on RUDAK... and I
haven't had enough time in one chunk to get my head properly wrapped around
the problem to fill that gap recently.  That's disappointing, to be sure,
but
CEDEX and GPS data collection has taken operational priority recently
anyway.

> > one reason might the operating system running on RUDAK, which
> > is not open.

I don't think the choice of OS on RUDAK has anything to do with why DSP code
does or does not exist for RUDAK.  The use of SCOS definitely limits the
number of people who can work on tasks that run on RUDAK itself, but that
has
not been a limiting factor so far that I can see.  The DSP loader works
fine,
there just isn't much interesting code to load with it yet...

My personal opinions about Open vs Secret Source are well known... and I
won't
bother getting wound up about that again here since it won't help here.

> > I think without Assi taking the job, not much would have happened ;(

Agreed.

You know, if AO-40 had achieved our pre-launch operational expectations, I
think more people would have become excited about working on additional
software for things like neat DSP tricks on RUDAK.  As it is, RUDAK is
barely
accessible enough to meet our basic requirements for interaction with the
onboard experiments... much less to "play with it".

When you combine:

        - the unexpected interference between RUDAK and analog passband
          operations when sharing a transmitter
        - an insufficient number of downlink transmitters working to give
          RUDAK its own downlink without turning off the passband, and
          the resulting scheduling issues for access to RUDAK
        - the need for much more power to get into RUDAK on the uplink than
          originally anticipated
        - the squint angle and DC power situations since we're still a
spinner
        - ... etc ...

I just don't think it's surprising that the general interest level of
capable
people in writing software for the RUDAK DSP's has been low.  If Assi's work
gets us a more reliable interaction with RUDAK, there are many things that
*may* become possible that would make hacking on code for RUDAK more
attractive.  We'll just have to wait and see.

> > > Why do people that launch satellites write most of their OBC software
> > > after it is in space?

That was definitely true for the original set of Microsat launches, but I
don't think it has been true for any AMSAT-NA or AMSAT-DL projects since
then.

> > > I have noticed that software like DSP seems to be wrote after the
> > > satellite is in space and never seems to be tested before you get it
is
> > > orbit, what is the reason or ideas behind that?

For RUDAK, the DSP's are purely experimental.  Sufficient hardware modems
were
included to meet all initial operational requirements after launch, and as
indicated above, DSP folk just didn't want to spend time coding for the
relatively unique RUDAK environment until they knew the platform was going
to have a successful launch and operational lifetime worth their effort.

I can't speak for any other platforms.

> > > Other question I have Peter, how much are DSP modems that are
installed
> > > on AO-40, is there a working model or prototype that AMSAT members can
> > > purchase to experiment on the ground.

Assi can probably tell us what he's using more easily than I can invent an
answer here.

> > >     1200 Bit/s BPSK should be "easy" and if it works, we
> > >     can look further ahead..

I'd like to point out that there is *no evidence* that 1k2 BPSK is likely to
interfere with the analog passband any less than the 9k6 FSK modems
implemented
in hardware.  We're all hopeful, of course, but this should be thought of as
*very* experimental...

Keep your fingers crossed!  :-)

73 - Bdale, KB0G

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