<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:283928196;
        mso-list-template-ids:1381772316;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Okay I understand that more than one person is thinking alike
here.&nbsp; Either we are all fooling ourselves or there might be something to
this.&nbsp; If we can get an interface that does encapsulation, we can pass any data
at all over the link.&nbsp; There still remains the &#8220;is it good enough&#8221; parts of the
requirements that will be imposed on us as in meeting specifications should
there actually be any that are followed.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>;-)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Bob<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>ARRL SDR Working Group Chair<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>NJQRP, QRP ARCI, QCWA, FRC.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&#8220;Trample the slow ....&nbsp; Hurdle the dead&quot;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> frank.brickle@gmail.com
[mailto:frank.brickle@gmail.com] <b>On Behalf Of </b>Frank Brickle<br>
<b>Sent:</b> Sunday, July 13, 2008 8:38 PM<br>
<b>To:</b> Bob McGwier<br>
<b>Cc:</b> Rick Hambly (W2GPS); namaste-dev<br>
<b>Subject:</b> Re: [Namaste-dev] Re: Thoughts on ACP Interoperability<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>On Sun, Jul 13, 2008 at 2:11 PM, Bob McGwier &lt;<a
href="mailto:rwmcgwier@gmail.com">rwmcgwier@gmail.com</a>&gt; wrote:<o:p></o:p></p>

<div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<div>

<div>

<p><span style='font-size:11.0pt;color:#1F497D'>Is there no middle ground? That
is,&nbsp; what is to prevent us from implementing the CAI sans the vocoder and
passing the digital streams encapsulated in &quot;AMSAT-MAC&quot;?&nbsp; Is
there something that prevents this?</span><o:p></o:p></p>

</div>

</div>

</blockquote>

<div>

<p class=MsoNormal><br>
Nothing prevents. I believe this is exactly what we *should* do. What's
required, however, is...a port and a socket. <br>
<br>
Or maybe just a little more, in the form of a tunnel through which alien EMCOMM
packets can move over AMSAT links. If we were to adopt something sensible like
Jingle or SIP for signalling, then the tunneling would be off-the-shelf anyway.<br>
<br>
Whatever the exact transport mechanism, though, there's essentially nothing to
*do* at the AMSAT end, in this scenario.<br>
<br>
73<br>
Frank<br>
AB2KT<o:p></o:p></p>

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<div>

<div>

<p><span style='font-size:11.0pt;color:#1F497D'>It would clearly require
control operators sitting at either end of the big pipe who can hear the
synthesized speech or see the content of file transfer to be legal, as in
sitting on a kill switch I think, without waivers.&nbsp; But is this not even
theoretically possible is my question?</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>Anyway the team goes it seems
to me that passing digital data according to some agreed upon standard that
would allow some ease of use by the first responders even if it is as dumb as
synthesize- reencode and then decode-analyze.&nbsp; We only need to walk right
up the boundary of what Part 97 will allow in time of emergency and use a
&quot;waterfilling algorithm&quot; to push at the legal limit it seems to me.</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>Bob</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>ARRL SDR Working Group Chair</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>Member: ARRL, AMSAT, AMSAT-DL,
TAPR, Packrats,</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>NJQRP, QRP ARCI, QCWA, FRC.</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&quot;Trample the slow
....&nbsp; Hurdle the dead&quot;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;
border-color:-moz-use-text-color -moz-use-text-color'>

<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> namaste-dev-bounces@AMSAT.Org [mailto:<a
href="mailto:namaste-dev-bounces@AMSAT.Org" target="_blank">namaste-dev-bounces@AMSAT.Org</a>]
<b>On Behalf Of </b>Frank Brickle<br>
<b>Sent:</b> Sunday, July 13, 2008 11:54 AM<br>
<b>To:</b> Rick Hambly (W2GPS)<br>
<b>Cc:</b> namaste-dev<br>
<b>Subject:</b> [Namaste-dev] Re: Thoughts on ACP Interoperability</span><o:p></o:p></p>

</div>

<div>

<div>

<p>&nbsp;<o:p></o:p></p>

<p style='margin-bottom:12.0pt'>&gt;From the Project 25website:<o:p></o:p></p>

<p align=center style='text-align:center'><b><span style='font-size:13.5pt'>What
is Required for P25 Compliance? </span></b><o:p></o:p></p>

<p><br>
At a minimum, a P25 radio system must provide interoperability with these
mandatory P25 Standard components: <o:p></o:p></p>

<ul type=disc>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><i>The Common Air Interface (CAI) specifies how
     information is coded, transmitted and received over the air. </i><br>
     <br>
     It enables users to interoperate and communicate digitally across
     networks, agencies, and vendors. <o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo1'><i>The Improved Multi-Band Excitation (IMBE)
     vocoder converts speech into a digital bit stream. </i><br>
     <br>
     Test panels judged IMBE as the coding scheme most successful at making
     male and female voices audible against background noises such as moving
     vehicles, sirens, gunshots, and traffic noise &#8211; the conditions of public
     safety use.<o:p></o:p></li>
</ul>

<p style='margin-bottom:12.0pt'><br>
P25 has also defined standard modes of operation to enable multi-vendor
interoperability for additional system functions: trunking, encryption,
over-the-air rekeying, to name a few. <br>
<br>
A set of defined system interfaces allow the P25 system elements to communicate
with host computers, data terminals and the public switched telephone network
(PSTN).<br>
<br>
---<br>
<br>
My reading of the situation is that any AMSAT system can be provided
*additional* capabilities for using the CAI and some other interfaces. These
interfaces are nominally open, although conspicuously lacking reference
implementations.<br>
<br>
However, thanks to the use of IMBE, having an AMSAT system that implements any
function where the codec is applied is completely out of bounds until such time
as the intellectual property issues surrounding it are resolved.<br>
<br>
For the sake of completeness, I would point interested readers to other areas
of the website where P25 vendors are criticized (by GAO and others) for failing
to provide complete implementations of the standard. It would appear that
vendors have been lagging grievously in providing precisely the interoperability
parts of the standard, while they've shown remarkable alacrity at fielding
systems employing the proprietary codec technology.<br>
<br>
In short, the vendors seem largely to have blown off interop, but have
demonstrated great motivation at shouldering out competition. My private
impression is that AMSAT could implement the full buffet of CAI specs and wind
up with systems that have nobody to talk to at the P25 end. A person more
cynical than myself might infer that P25 is nothing more than yet another scam
to ensure virtual monopolies for large vendors.<br>
<br>
None of this is a surprise -- in fact, it's business as usual -- where
proprietary specs are concerned. Again, my private conviction is that AMSAT
would be flat-out loony to devote any effort whatsoever at realizing anything
but a certifiably Open standard.<br>
<br>
73<br>
Frank<br>
AB2KT<br>
<br>
<o:p></o:p></p>

<div>

<p>On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) &lt;<a
href="mailto:w2gps@cnssys.com" target="_blank">w2gps@cnssys.com</a>&gt; wrote:<o:p></o:p></p>

<p>Timothy,<br>
<br>
Thank you for your input. I strongly agree that any external interface with<br>
the ground station should be IP based. That opens up a number of Ham-centric<br>
and emergency communications application interfaces that can easily be built<br>
on top of IP.<br>
<br>
The average satellite user of this ground station will be an individual in<br>
his or her home. Even then, the IP interface will allow that user to connect<br>
the ground station to their computer and exchange IP voice, pictures, video,<br>
files, etc. with the users on the communications channel.<br>
<br>
Could we put applications like a P25/IP interface in our PC or laptop,<br>
thereby separating this applications issue from the immediate need to get an<br>
affordable ACP ground station built soon? I don't really know enough about<br>
P25 or its implications (technical, legal) to know.<br>
<br>
Rick<br>
W2GPS<br>
AMSAT LM2232<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:namaste-dev-bounces@amsat.org" target="_blank">namaste-dev-bounces@amsat.org</a>
[mailto:<a href="mailto:namaste-dev-bounces@amsat.org" target="_blank">namaste-dev-bounces@amsat.org</a>]<br>
On Behalf Of Timothy J. Salo<br>
Sent: Saturday, July 12, 2008 7:05 PM<br>
To: 'namaste-dev'<br>
Subject: [Namaste-dev] Thoughts on ACP Interoperability<br>
<br>
A few quick thoughts on ACP interoperability objectives<br>
follow. &nbsp;This note is motivated, in part, by &quot;An Overview<br>
of AMSAT Opportunities for Communications Interoperability&quot;,<br>
available at:<br>
<br>
&lt;<a
href="http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Interoperability_Ver1.pdf"
target="_blank">http://www.delmarnorth.com/namaste/requirements/AMSAT_Communications_Intero<br>
perability_Ver1.pdf</a>&gt;<br>
<br>
(Note that these comments are based on my recollection<br>
of how Project 25 (P25) systems work, rather than<br>
recent investigations.)<br>
<br>
The ACP Interoperability document seems to me to<br>
suggest that there is an opportunity for ACP to<br>
provide connectivity between amateur radio systems<br>
and public safety systems. &nbsp;That is, ACP should<br>
(arguably) enable an amateur radio device to<br>
communicate with a public safety system.<br>
<br>
The public safety community is moving towards P25<br>
systems. &nbsp;As such, P25 seems to be the best system<br>
for the ACP to target. &nbsp;(In other words, the ACP<br>
should target the system towards which the public<br>
safety community is migrating, rather than some<br>
system that the public safety community is migrating<br>
away from.)<br>
<br>
So, the refined requirement might be that the ACP<br>
should enable connectivity between amateur radio<br>
devices [or systems] and P25 systems.<br>
<br>
I know of two ways for a device to connect to a<br>
P25 system:<br>
1) Look like (appear to the P25 system to be)<br>
&nbsp; &nbsp;an end device (e.g., a handheld, mobile or<br>
&nbsp; &nbsp;basestation radio), or<br>
2) Look like a repeater.<br>
<br>
It turns out that P25 repeaters can be<br>
interconnected with IP, or more precisely,<br>
with a P25 protocol that runs over IP.<br>
<br>
So, if the ACP could provide connectivity<br>
between two IP devices, it would become a<br>
simple, powerful, general solution. &nbsp;It<br>
could provide amateur/P25 interoperabil9ty,<br>
as well as a bunch of other useful services.<br>
<br>
An IP-capable ACP becomes simple, because a<br>
large number of very useful interoperability<br>
issues get moved outside of the ACP system.<br>
In this architecture, amateur/P25 interoperability<br>
would be provided by an external (to the ACP)<br>
device that converts an amateur radio conversation<br>
to the P25 protocols.<br>
<br>
(Actually, a better solution would be to build an<br>
IP/P25 device that is integrated into an amateur<br>
repeater. &nbsp;That is, the amateur repeater would<br>
appear to the P25 repeater to be just another<br>
P25 repeater. &nbsp;This device could use the ACP, or<br>
it could use any other IP-enabled path. &nbsp;By the<br>
way, another important theme here is that the<br>
ACP is much more useful if it connects systems,<br>
such as repeaters, rather than individual devices.)<br>
<br>
An IP-capable ACP becomes much more powerful and<br>
general because users, rather than system designers,<br>
are now able to develop new uses for the ACP.<br>
<br>
A few more random thoughts.<br>
<br>
o In my opinion, system-level architecture discussions,<br>
&nbsp; such as those hinted at by the &quot;Namaste Layers&quot; document,<br>
&nbsp; should probably occur sooner rather later. &nbsp;Specifically,<br>
&nbsp; it is important to understand how the ACP should fit<br>
&nbsp; architecturally with other systems. &nbsp;Is it a network<br>
&nbsp; device? &nbsp;What sorts of systems will it (meaning the<br>
&nbsp; whole ACP system, not just the satellite segment)<br>
&nbsp; connect with? The right answers will make the ACP a<br>
&nbsp; very useful, general device, while a wrong answer<br>
&nbsp; might make it difficult to get the ACP to work well.<br>
&nbsp; (And, I don't like the protocol layer summery in the<br>
&nbsp; document...)<br>
<br>
o It looks like the ACP ground station may be two<br>
&nbsp; subsystems connected by an Ethernet. &nbsp;Now, if this<br>
&nbsp; is IP running over Ethernet, then the ACP system might<br>
&nbsp; become really useful, really easily, for a wide<br>
&nbsp; variety of useful applications. &nbsp;I hope this concept<br>
&nbsp; does not get lost with the changing (or unchanging) of<br>
&nbsp; the guard.<br>
<br>
o Note that P25 has a data channel. &nbsp;I assume that<br>
&nbsp; the ACP ought to also interconnect this data channel<br>
&nbsp; with amateur data systems (no, not AX.25 systems...).<br>
<br>
More free advice from,<br>
<br>
-tjs<br>
<br>
<br>
_______________________________________________<br>
Namaste-dev mailing list<br>
<a href="mailto:Namaste-dev@amsat.org" target="_blank">Namaste-dev@amsat.org</a><br>
<a href="http://amsat.org/mailman/listinfo/namaste-dev" target="_blank">http://amsat.org/mailman/listinfo/namaste-dev</a><br>
<br>
_______________________________________________<br>
Namaste-dev mailing list<br>
<a href="mailto:Namaste-dev@amsat.org" target="_blank">Namaste-dev@amsat.org</a><br>
<a href="http://amsat.org/mailman/listinfo/namaste-dev" target="_blank">http://amsat.org/mailman/listinfo/namaste-dev</a><o:p></o:p></p>

</div>

<p><br>
<br clear=all>
<br>
-- <br>
What else may hap to time I will commit... -- Twelfth Night <o:p></o:p></p>

</div>

</div>

</div>

</div>

</blockquote>

</div>

<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
We may yet reach a point where the only sector of scientific inquiry that is
safe from the anti-science mobs on the Right is weapons research. -- Arianna
Huffington <o:p></o:p></p>

</div>

</body>

</html>