[Namaste-dev] Todays challenge 6-3

Howie hdefelice at compuserve.com
Tue Jun 3 12:44:48 PDT 2008


 OK, maybe I'm dense but according to the description of the ACP transponder
I saw, the uplink was going to be multiple FDM channels using BPSK with
Viterbi/RS coding, (a design concept I completely agree with). In the
challenge for today, we are talking about GPS timing, TDMA and 8-ary FSK. As
someone who also does system engineering, I understand the comments made
about selling the concept before getting too involved in the details, but
this is a very fundamental disconnect. Did I miss a whole bunch of stuff
along the way here? 

-----Original Message-----
From: namaste-dev-bounces at amsat.org [mailto:namaste-dev-bounces at amsat.org]
On Behalf Of namaste-dev-request at amsat.org
Sent: Tuesday, June 03, 2008 3:00 PM
To: namaste-dev at amsat.org
Subject: Namaste-dev Digest, Vol 3, Issue 2

 
Send Namaste-dev mailing list submissions to
	namaste-dev at amsat.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://amsat.org/mailman/listinfo/namaste-dev
or, via email, send a message with subject or body 'help' to
	namaste-dev-request at amsat.org

You can reach the person managing the list at
	namaste-dev-owner at amsat.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Namaste-dev digest..."


Today's Topics:

   1. Re: Weekly Plan June 2 - June 6 (Frank Brickle)
   2. Re: Weekly Plan June 2 - June 6 (Bdale Garbee)
   3.   Re: Weekly Plan June 2 - June 6 (Paul Williamson)
   4. Re: Weekly Plan June 2 - June 6 (APCO-25 InterOp) (JoAnne Maenpaa)
   5. Re: Weekly Plan June 2 - June 6 (Bruce Perens)
   6. Re: Weekly Plan June 2 - June 6 (Frank Brickle)
   7. Re: Weekly Plan June 2 - June 6 (Paul Williamson)
   8.  Tuesday Challenge For June 3, 2008 (Michelle)


----------------------------------------------------------------------

Message: 1
Date: Tue, 3 Jun 2008 00:13:03 -0400
From: "Frank Brickle" <brickle at pobox.com>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6
To: Michelle <w5nyv at yahoo.com>
Cc: namaste-dev <namaste-dev at amsat.org>, Bruce Perens
	<bruce at perens.com>
Message-ID:
	<fc22d18f0806022113g688d9303ie66830b5d8b8f83c at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Mon, Jun 2, 2008 at 12:46 PM, Michelle <w5nyv at yahoo.com> wrote:

...
> 8. Policy development concerning openness, open source, transparency, etc.
> begins this week.
> Some of the feedback about the project concerned the definition and 
> explanation of what we mean when we say open source.


http://opensource.org/docs/osd
http://opensource.org/osr

My apologies if this comes across as a harsh response, but: what about this
is hard to understand? The guidelines and the motivation are awfully clear.
Is there some hitherto undiscovered problem with these definitions or
requirements that we're proposing to fix as part of this project?

It makes me slightly uneasy that Open Source and Open Standards keep coming
up as issues about which there's some question. There are too many recent
high-profile examples where exactly what has happened has been a continual
reinsertion into standards processes of specious questions about Openness,
when the actual intent was to subvert the process itself. ISO is currently
being torn apart over precisely this issue. Debate and discussion are always
to be encouraged, but it's not at all obvious to me what there is for us to
debate and discuss in this arena.

Speaking only for myself, I can say without reservation that these
principles are not up for negotiation as conspicuous foundations and ground
rules for participation in the project.

Yours in bewilderment,
73
Frank
AB2KT

-- 
The only thing we have to fear is whatever comes along next. -- Austin Cline
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://amsat.org/pipermail/namaste-dev/attachments/20080602/acfdcb75/attachm
ent-0001.html

------------------------------

Message: 2
Date: Mon, 02 Jun 2008 22:54:49 -0600
From: Bdale Garbee <bdale at gag.com>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6
To: Frank Brickle <brickle at pobox.com>
Cc: namaste-dev <namaste-dev at amsat.org>, Bruce Perens
	<bruce at perens.com>
Message-ID: <1212468889.5318.203.camel at rover.gag.com>
Content-Type: text/plain

On Tue, 2008-06-03 at 00:13 -0400, Frank Brickle wrote:
> On Mon, Jun 2, 2008 at 12:46 PM, Michelle <w5nyv at yahoo.com> wrote:
> 
>         ...
>         8. Policy development concerning openness, open source,
>         transparency, etc. begins this week.
>         Some of the feedback about the project concerned the
>         definition and explanation of what we
>         mean when we say open source.
>  
> http://opensource.org/docs/osd
> http://opensource.org/osr

Amen.

Since it's less well known than the set of OSI-approved software
licenses, I'd also like to remind people of the open hardware license
developed by TAPR, et al.  I'm using it for all of my hobby electronics
projects these days.

	http://tapr.org/ohl

73 - Bdale, KB0G





------------------------------

Message: 3
Date: Mon, 2 Jun 2008 21:52:27 -0700
From: Paul Williamson <kb5mu at amsat.org>
Subject: [Namaste-dev]   Re: Weekly Plan June 2 - June 6
To: "Frank Brickle" <brickle at pobox.com>
Cc: namaste-dev <namaste-dev at amsat.org>, Bruce Perens
	<bruce at perens.com>
Message-ID: <a06240809c46a768bfefc@[192.168.0.16]>
Content-Type: text/plain; charset="us-ascii"

At 12:13 AM -0400 6/3/08, Frank Brickle wrote:
>http://opensource.org/docs/osd
>http://opensource.org/osr
>
>My apologies if this comes across as a harsh response, but: what about this
is hard to understand? The guidelines and the motivation are awfully clear.
Is there some hitherto undiscovered problem with these definitions or
requirements that we're proposing to fix as part of this project?

Speaking for myself only ...

The definitions given there are NOT OPEN ENOUGH for this project. They don't
say anything about development procedures. They only address the
distribution and licensing of a finished product, where the individual
worker is free to define "finished". Well, we don't have a finished product,
and we won't have for quite a while. We have a *project*. We need guidelines
that tell us how to work on that project (to develop our products) out in
the open. It's not just the work products that need to be freely available,
but the work itself in all its intermediate stages. Requirements analysis,
etc., should all be reasoned out and documented. This is, in a sense, far
beyond "open source". In another sense, it's just an attempt to capture the
"best practices" of the open-source community.

Do you have a draft of code that's ahead of what's on the server? Not very
open. Do you have a design document that's "not finished" and thus
unpublished? Not open. Do you have a post-it note with a To Do list that you
haven't published? Not open. Issues about which you want to call up a
co-worker and discuss off-line instead of posting to the mailing list? Etc.,
etc.

Private ==> unreviewed ==> unreliable ==> unacceptable.

The open source and free software folks have rightfully concentrated on open
PRODUCTS and their legal consequences. We [should] accept that, but it's not
enough. We [should] want to have an open PROJECT.

Put another way, the OSD has too modest a definition of "source code". For
our purposes it includes not just the preferred form [of the final
implementation] for modification of the product [at the implementation
level]. It includes the thought processes leading up to the creation of that
form. Without access to those thought processes (via design documents) a
would-be designer or reviewer cannot really join the project and participate
fully. And we want them to.

73  -Paul
kb5mu at amsat.org


------------------------------

Message: 4
Date: Tue, 3 Jun 2008 09:12:29 -0500
From: "JoAnne Maenpaa" <k9jkm at comcast.net>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6 (APCO-25
	InterOp)
To: "'namaste-dev'" <namaste-dev at amsat.org>
Message-ID: <000901c8c583$dd157de0$974079a0$@net>
Content-Type: text/plain;	charset="utf-8"

Hi everyone,

I'm the person who volunteered to examine the InterOperability opportunity
for our ACP Ground Segment.

> 5. Requirements analysis (technical) and Position Paper (policy) work 
>    on the optional APCO-25 terrestrial interface module continues. I 
>    have one volunteer for this effort, and am looking for more. A re-
>    quest for a copy of the series 102 spec from TIA has been made to 
>    AMSAT. The spec is free under certain circumstances, and I think 
>    we may qualify. If not, and if AMSAT agrees it?s worth buying, 
>    it will be purchased.

I'm retired from the communication systems engineering business (20 years at
Motorola) but during that part of my career I had the opportunity to drive
requirements definition and customer cost quoting for large systems.  Some
of the interoperability features I had been a part of include cellular
nationwide/automatic roaming, cellular E911, CDMA-to-AMPS handoff, cellular
location service (GPS), cellular caller ID, etc.

The one thing these cellular interoperability designs had in common is that
they were driven by either a standards document mandate or by considerable
customer interest and investment in the system design.  Sometimes the
customer knew what he wanted and was able to specify what Motorola was going
to build for him.  Other times Motorola would sense an opportunity to dangle
a technical proposal in front of the customer and sell him on the idea.

At this phase of our InterOperability investigation I have a feeling we're
at a point where we sense potential customer interest translating into
launch funding and the opportunity to dangle a technical proposal in front
of launch funding sources.  (Likely DHS or DoD?)

Effective project proposal and requirements definition should define WHAT
you are going to do before you define HOW you are going to do it.  

This is just my opinion only - but jumping in with 30 volumes of APCO
specifications seems to be jumping right into that "how you are going to do
it" phase.  We can imagine a scenario where you would tell 50 hardware and
software designers to go "write some code and make a CPU board" and we'll
get back to you about what it should do! :-)

Here is what I am dangling out for our Namaste team to consider and discuss:

a. AMSAT uses the Incident Command System as the basis of our
InterOperability
   model.

b. This is WHAT we propose to do: The Namaste InterOperability feature set 
   should include the ability for customer specified layers and sectors of 
   the Incident Command System to communicate with each other.  ICS Command 
   Posts will likely have more need for a satellite earth station than an 
   individual firefighter on standby at a levee.  The types of messaging 
   traffic at this different levels varies considerably.

c. Perhaps not call it APCO-25 during our initial technical proposal phase?
   When DHS tells AMSAT we are on the right track by allowing Incident Com-
   manders access to other services, and, "Oh by the way, 90% of our radios
   are APCO-25" then we will be on track to worry about all the octets of
   radio packet traffic.

Quoting from http://en.wikipedia.org/wiki/Unity_of_command#Unity_of_Command
:
The Incident Command System (ICS) is a standardized, on-scene, all-hazard 
incident management concept in the United States. It is a management 
protocol originally designed for emergency management agencies and 
later federalized. ICS is based upon a flexible, scalable response 
organization providing a common framework within which people can 
work together effectively. These people may be drawn from multiple 
agencies that do not routinely work together, and ICS is designed 
to give standard response and operation procedures to reduce the 
problems and potential for miscommunication on such incidents.

In the next week or two, I plan to put together a more detailed graphical
proposal of how Namaste can help facilitate a wide-area implementation of
ICS.  Just thought I'd dangle my thought process out here.  The APCO bytes
and protocols are well defined and are the least of our problems.  I thought
perhaps we need to start with a proposal using the language of likely
funding managers.

--
73 de JoAnne K9JKM
k9jkm at amsat.org 





------------------------------

Message: 5
Date: Tue, 03 Jun 2008 01:53:05 -0700
From: Bruce Perens <bruce at perens.com>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6
To: Bdale Garbee <bdale at gag.com>
Cc: namaste-dev <namaste-dev at amsat.org>
Message-ID: <48450671.90405 at perens.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I apologize for coming into the middle of an ongoing discussion. I was 
copied on two messages today because I have recently "carried the flag" 
for Open Standards and Open Source within AMSAT and TAPR. I've promoted 
these things outside of AMSAT for more than a decade.

I know several of the members listed on the Namaste web site. I believe 
many of them, perhaps most, would expect the set of rights defined by 
the OSD as a _minimum_ requirement for the investment of their 
participation.

We have seen a number of projects fail because they were held too close 
- as valuable intellectual property - to encourage the participation of 
all of the individuals, organizations, and companies that could have 
kept those projects afloat. At the same time, developers have a 
well-justified fear of commercial entities running away with the 
project, without any consideration of the developer's investment into 
that project. The existing Open Source licenses and the OHL try to 
strike a balance between those two perspectives.

Paul makes a good point about openness of process. This is so well 
accepted as an obviously good thing that it is taken for granted among 
open standards organizations and open source projects today.

I haven't heard any "argument against" yet. Is there any such argument, 
or was it always the fact that the obvious result of this discussion was 
going to be "Of course, we'll be wide open".

    Thanks

    Bruce K6BP


------------------------------

Message: 6
Date: Tue, 3 Jun 2008 11:05:40 -0400
From: "Frank Brickle" <brickle at pobox.com>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6
To: "Paul Williamson" <kb5mu at AMSAT.Org>
Cc: namaste-dev <namaste-dev at AMSAT.Org>
Message-ID:
	<fc22d18f0806030805r5021d86id98e820d43c24803 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Jun 3, 2008 at 12:52 AM, Paul Williamson <kb5mu at amsat.org> wrote:

Fair enough, and your clear statement is very much on point. It makes
explicit a number of important principles which, as Bruce says, are wholly
embedded in the Open philosophy, but which most of the time are left
unarticulated. Making them explicit is, from every point of view, a
thoroughly good thing.

It does leave me with one lingering concern, however.


> Put another way, the OSD has too modest a definition of "source code". For
> our purposes it includes not just the preferred form [of the final
> implementation] for modification of the product [at the implementation
> level]. It includes the thought processes leading up to the creation of
that
> form. Without access to those thought processes (via design documents) a
> would-be designer or reviewer cannot really join the project and
participate
> fully. And we want them to.


Just to be clear, I don't think you're advocating the such an idea at all,
but it's possible to interpret the intention stated here as mandating one
particular design and development process. For some of us, progressive
sketches of program code effectively *are* the design documents. This is
often the case with thoroughly innovative projects -- you can read that as
"crazy ideas" -- being worked on by small teams, where the developers and
the designers are probably the same individuals. To a large degree this is
how Linux came about. It's aptly described by Linus as evolution and not
intelligent design.

A number of us involved in Eagle and Namaste have long and sordid histories
at that sort of thing. The ones that come immediately to mind are GnuRadio
and the USRPs, PowerSDR, and DttSP, thinking only of the SDR side. I believe
what's served us well is a fundamental commitment to the "publish early,
publish often" rule. (Other users and developers have shown remarkable
forbearance when confronted with early and frequent pieces of my code that
don't actually work and need to be scrapped hastily.)

As I said, I don't believe for a second what you're advocating is anything
other than an agreement on all sides to let everybody know and see what
we're up to in a timely and convenient way. In this regard I think you're
merely entirely correct and on the mark. I do think, though, that to some
observers, the absence of a detailed, uniform development methodology would
be a defect in the project, and your statement could be construed as an
attempt to address that defect, rather than the declaration of a larger
principle to which none of us would take exception.

73 and thanks
Frank
AB2KT


-- 
The only thing we have to fear is whatever comes along next. -- Austin Cline
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://amsat.org/pipermail/namaste-dev/attachments/20080603/d7729e06/attachm
ent-0001.html

------------------------------

Message: 7
Date: Tue, 3 Jun 2008 10:25:49 -0700
From: Paul Williamson <kb5mu at amsat.org>
Subject: [Namaste-dev] Re: Weekly Plan June 2 - June 6
To: "Frank Brickle" <brickle at pobox.com>
Cc: namaste-dev <namaste-dev at amsat.org>
Message-ID: <a0624080ac46b0f25c344@[192.168.0.16]>
Content-Type: text/plain; charset="us-ascii"

At 11:05 AM -0400 6/3/08, Frank Brickle wrote:
>Just to be clear, I don't think you're advocating the such an idea at all,
but it's possible to interpret the intention stated here as mandating one
particular design and development process.

Well ... maybe we don't agree so completely as all that. I AM sorely tempted
to say that I do advocate mandating some aspects of the development process.
If I were in a rabble-rousing mood, I would say that I want to mandate
"engineering" and prohibit "hacking". This is a production development
project we have here, or so we hope, not an experimental R&D project, to
whatever extent it's meaningful to say that about an amateur radio project.

Now we're into the meat of some of the questions I hoped would be addressed
by a project statement about openness. Excellent! I hope some more team
members (especially the non-zealots) will chime in.

> For some of us, progressive sketches of program code effectively *are* the
design documents.

That kind of design often works well for *implementation*, especially of a
fairly localized item like a computer program. But before you start that
procedure, you'd better have a clear idea in mind about what the
requirements are. Often on a pure software project, the requirements can't
usefully be set out in advance. This is because the basic requirements are
too obvious to bother with, and the detailed requirements are too fluid to
be specified in detail in advance. However, it's a mistake to assume that's
going to be true in all cases. In a project with specified goals, you'd
better spend some time trying to identify the requirements up front.

I'm not a big fan of documents that try to specify the detailed
implementation in advance. Those are the kind of documents that can usefully
be replaced by the progressive-sketches approach, and that's great. It's the
*other* kinds of design documents which I believe are especially useful in
an engineering project. These include requirements documents and high-level
architecture documents. These set a framework for the implementation and
make it possible to talk concretely about whether we are all building the
same thing, and whether it's the right thing to be building.

Interface documents lie in the gray zone. It's important to finalize them
early, but they are often dependent on implementation details that can't be
optimized in advance. I'd like to see interface documents treated like
requirements documents, but with a greater freedom to make changes late in
the development.

I realize that asking for documents may seem bureaucratic to some people. I
hope we can agree that it's a necessary part of the process of collaborative
development.

73  -Paul
kb5mu at amsat.org


------------------------------

Message: 8
Date: Tue, 3 Jun 2008 10:54:05 -0700 (PDT)
From: Michelle <w5nyv at yahoo.com>
Subject: [Namaste-dev]  Tuesday Challenge For June 3, 2008
To: namaste-dev <namaste-dev at amsat.org>
Message-ID: <961220.66189.qm at web52011.mail.re2.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Today's challenge involves the question of a potential requirement.

We've been asked to consider requiring a GPS receiver on every Namaste
ground station.

Driving the proposed requirement is a desire to simplify the demodulator on
the spacecraft. 

Here's the reasoning. By synchronizing frame and perhaps symbol timing to
GPS, the searching at the spacecraft is easier because if you know where you
are, and you know where the satellite is, then you know the time delay, so
that you can make everyone's frames arrive at the same time. 

The demodulator's job is easier because the search space is reduced. Once it
gets locked to frame timing, it only needs to search a small window for all
the other users. If the symbol timing is low enough you could also
synchronize symbols across users.

My thoughts on this were that what is really being explored is a timing
requirement; not necessarily a GPS hardware requirement. This means
qualifying the desired timing uncertainty in something like a timing
uncertainty budget (like a link budget, except with respect to timing
instead of gain). 

There is a balance between power efficiency and receiver effort. The more
efficient scheme requires more processing from the receiver. What is the
most capable receiver currently under consideration in terms of processing
capability? To me, that limit is a constraint on allowable uncontrolled
timing uncertainty, whatever that happens to be. 

At what point does the receiver start to run out of time and blow chunks?
Are current space-qualified options good enough to not have to worry about
this, or are current space-qualified options not capable enough? For an
uplink data rate of 15kbps, the 8-ary FSK symbol rate is 5kHz. What's the
maximum data rate we could send with uncontrolled timing requirements?

While the timing requirement may be met with GPS, I'd like to avoid
requiring extra hardware in the ground station whenever possible, especially
when it can be replaced with existing hardware and software.

For example, a ranging function can provide slant range and therefore delay
and therefore remove the timing uncertainty. There is an associated cost to
doing that which needs some analysis, but the cost in this case is
processing and capacity, instead of dollars for hardware plus some amount of
processing to manage the data from something like a GPS. 

If the spacecraft was the timepiece, and the stations synchronized
themselves to that via information in the downlink, then we could quite
possibly save a considerable amount of money in terms of not including a GPS
module in every ground station.

The Tuesday Challenge is to wade in to this discussion, pick up whatever
seems most interesting or whatever is in most egregious need of correction -
and participate!

There are several link documents in the Requirements Analysis section of the
website www.amsat.org/namaste, and this discussion will result in additions
and expansions to those documents. 

more soon,

-Michelle W5NYV


------------------------------

_______________________________________________
Namaste-dev mailing list
Namaste-dev at amsat.org
http://amsat.org/mailman/listinfo/namaste-dev


End of Namaste-dev Digest, Vol 3, Issue 2
*****************************************




More information about the Namaste-dev mailing list