<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:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
span.EmailStyle17
        {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:288558727;
        mso-list-template-ids:-464192058;}
@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'>I understand your feelings about P25 insofar as it uses closed,
protected, and/or patented vocoders. I will not pretend to have read the
spec in depth but will pose the question all of this begs since the rest of the
thing seems at a glance to be an open standard. Is there no middle
ground? That is, what is to prevent us from implementing the CAI sans the
vocoder and passing the digital streams encapsulated in “AMSAT-MAC”?
Is there something that prevents this? 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. But is this not even theoretically
possible is my question?<o:p></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'>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.
We only need to walk right up the boundary of what Part 97 will allow in time
of emergency and use a “waterfilling algorithm” to push at the
legal limit it seems to me.<o:p></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> </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> </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'>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'>“Trample the slow .... Hurdle the dead"<o:p></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>
<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"'> namaste-dev-bounces@AMSAT.Org
[mailto:namaste-dev-bounces@AMSAT.Org] <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<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>>From the Project 25website:<o:p></o:p></p>
<p class=MsoNormal 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 class=MsoNormal><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 – the conditions of
public safety use.<o:p></o:p></li>
</ul>
<p class=MsoNormal 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>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>On Sun, Jul 13, 2008 at 8:17 AM, Rick Hambly (W2GPS) <<a
href="mailto:w2gps@cnssys.com">w2gps@cnssys.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>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">namaste-dev-bounces@amsat.org</a>
[mailto:<a href="mailto:namaste-dev-bounces@amsat.org">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. This note is motivated, in part, by "An Overview<br>
of AMSAT Opportunities for Communications Interoperability",<br>
available at:<br>
<br>
<<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>><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. 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. As such, P25 seems to be the best system<br>
for the ACP to target. (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>
an end device (e.g., a handheld, mobile or<br>
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. 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. That is, the amateur repeater would<br>
appear to the P25 repeater to be just another<br>
P25 repeater. This device could use the ACP, or<br>
it could use any other IP-enabled path. 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>
such as those hinted at by the "Namaste Layers" document,<br>
should probably occur sooner rather later. Specifically,<br>
it is important to understand how the ACP should fit<br>
architecturally with other systems. Is it a network<br>
device? What sorts of systems will it (meaning the<br>
whole ACP system, not just the satellite segment)<br>
connect with? The right answers will make the ACP a<br>
very useful, general device, while a wrong answer<br>
might make it difficult to get the ACP to work well.<br>
(And, I don't like the protocol layer summery in the<br>
document...)<br>
<br>
o It looks like the ACP ground station may be two<br>
subsystems connected by an Ethernet. Now, if this<br>
is IP running over Ethernet, then the ACP system might<br>
become really useful, really easily, for a wide<br>
variety of useful applications. I hope this concept<br>
does not get lost with the changing (or unchanging) of<br>
the guard.<br>
<br>
o Note that P25 has a data channel. I assume that<br>
the ACP ought to also interconnect this data channel<br>
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">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">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 class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
What else may hap to time I will commit... -- Twelfth Night <o:p></o:p></p>
</div>
</body>
</html>