RE: [DSTAR_DIGITAL]

2009-05-19 Thread Adam Karsin
Hi Tom, 

 Thanks for the reply. I have looked at the webpage, and it seems pretty
straight forward. Can you (or anyone on the list) walk me through the menu
settings to make sure that I have them correct? I am not quite sure where to
locate the C1 message on the 91ad. 

 

Also you state I need to set me GPS to transmit, is that a radio setting or
a GPS setting? 

 

Thanks again and 73,

 

Adam

KG4WWH

 

  _  

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com]
On Behalf Of Tom Carpenter
Sent: Monday, May 18, 2009 18:21
To: dstar_digital@yahoogroups.com
Subject: Re: [DSTAR_DIGITAL]

 






Adam

If you set your gps to transmit and put a string in your transmit msg for
gps it will go onto the net through your local gateway and you can see it on
any aprs web site such as aprs.fi.

Here is a link to the page that calculates your string to put into the msg
line.

http://www.aprs- http://www.aprs-is.net/DPRSCalc.aspx is.net/DPRSCalc.aspx

Tom
KI8AS

- Original Message - 
From: Adam Karsin 
To: dstar_digital@ mailto:dstar_digital%40yahoogroups.com yahoogroups.com
Sent: Monday, May 18, 2009 1:37 PM
Subject: [DSTAR_DIGITAL] 

Hi everyone, 

Ok , I have SLOWLY moved forward with DSTAR, hewre is where I am so
far.

Still on IC-91AD.

I have added an external antenna for mobile use.

I have started the integration of an older GPS (Garmin GPS45) for use in the
jeep with DSTAR.

I am able to see on the radio that I am connected, as it gives me
coordinates in the position screen.

So here are the questions, 

1) how do I know that I am actually transmitting the GPS data?

2) Is there a map (similar to APRS) where I can see in real time my
position?

3) Are there other items that I need to make this all work?

Thanks!!

Adam Karsin

KG4WWH

[Non-text portions of this message have been removed]

--

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.329 / Virus Database: 270.12.34/2121 - Release Date: 05/18/09
17:55:00

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]



Re: [DSTAR_DIGITAL] Using reflectors

2009-05-19 Thread Tony Langdon
At 10:32 PM 5/19/2009, you wrote:
While trying to gain information on how to operate beyond my local 
repeater I saw instructions on how to link to another repeater and 
how unlink.  I saw instruction on how to connect to a 
reflector.  There was no mention of disconnecting.  After I am done 
using the reflector do I need to disconnect?  If so how do I disconnect?

To disconnect from a reflector, or a DPlus linked gateway, you need 
to  set UR to 7 spaces, with a U in the 8th character position, then 
hit the PTT.


73 de VK3JED / VK3IRL
http://vkradio.com



RE: Native D-STAR vs. DPLUS linking (was: Re: [DSTAR_DIGITAL] Signal Distance)

2009-05-19 Thread Barry A. Wilson
AEDs  Call Sign Routing,

 

I think it was a wise choice to require AED’s on commercial air craft.
If it is never needed then all the better, but if an emergency occurs it may
just be the one tool that saves a life when access to rapid emergency care
is unavailable. For such a small investment in overall costs it’s a no
brainer. Here in the US there has been strides to get rapid emergency
response and transport to most major communities within 6 minutes.  I know
it can far exceed that time… but if you’re in a commercial aircraft that
time may be closer to 30 minutes. WAY too long to get back on the ground and
before getting a patient into the medical care system.   

 

   In the early days of aviation flight attendants were often nurses. As
long as I can remember there has always been oxygen on aircraft. AED’s are
just one more tool in the tool box to assist in emergency care and I’m glad
they are there.

 

   So when used Call Sign Routing works well. If I were traveling like I use
to… it would be ideal to have. In another 5-10 years it may be so common
place that where ever you operate may have access to a gateway connected
system. Just like having an AED accessible on aircraft, shopping malls,
schools, job sites… if it’s available it can be used when needed.  

 

73

 

Barry A. Wilson KAØBBQ

D-STAR  UR=/WØCDS  B

 

 

   DD A 1299.9000 RPS

DV A 1283.9625 -12.000

DV B 446.9625 -5.

DV C 145.2500 +0.6000

 

 

 

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com]
On Behalf Of john_ke5c
Sent: Monday, May 18, 2009 8:35 PM
To: dstar_digital@yahoogroups.com
Subject: Native D-STAR vs. DPLUS linking (was: Re: [DSTAR_DIGITAL] Signal
Distance)

 






 But to those of us who truly do wish to communicate with an individual 
 (as with those of us who are trained on AEDs), it is nice to have the 
 capability when wanted/needed.

Oh I generally agree. I was just emphasizing how non sequltur the attempted
analogy with debfibrillators on airplanes was.

73 -- John



[Non-text portions of this message have been removed]



Re: [DSTAR_DIGITAL] Using reflectors

2009-05-19 Thread Nate Duehr

On Tue, 19 May 2009 22:51:54 +1000, Tony Langdon vk3...@gmail.com
said:
 At 10:32 PM 5/19/2009, you wrote:
 While trying to gain information on how to operate beyond my local 
 repeater I saw instructions on how to link to another repeater and 
 how unlink.  I saw instruction on how to connect to a 
 reflector.  There was no mention of disconnecting.  After I am done 
 using the reflector do I need to disconnect?  If so how do I disconnect?
 
 To disconnect from a reflector, or a DPlus linked gateway, you need 
 to  set UR to 7 spaces, with a U in the 8th character position, then 
 hit the PTT.

I keep one call-sign memory on every radio dedicated to the Unlink
command.  On the ID-800H, it's the #1 call-sign memory, making it much
easier to access while driving.  Having it available in a callsign
memory makes it easier to disconnect something in a hurry if you need
to.

Something to keep in mind when programming your rigs.  I highly
recommend the programming software or if you're more adventurous, a copy
of CHIRP.

Nate WY0X
--
  Nate Duehr
  n...@natetech.com



RE: [DSTAR_DIGITAL] Tactical Call indication

2009-05-19 Thread Nate Duehr

On Tue, 19 May 2009 08:30:36 -0600, Barry A. Wilson
ka0...@worldnet.att.net said:

  (NOTE:  I know how we identify MYCALL has been left open to local
 interpretation because there are a few operators here in Denver that like
 to
 play with  erroneous MYCALL callsigns like RG8U or COAX  because they
 think
 it is cute and as long as they ID in voice they feel using unassigned
 calls
 in digital is OK.  It’s not their concern what gets routed and
 retransmitted
 by someone else remotely if on the Gateway.  BAD PRACTICE? Some would say
 yes.  I personally will always interpret the rules along with good
 amateur
 practice to operate with the intent of the law and not necessarily how to
 get around the rules so as to be cute.) 

[Sorry folks, going to go into a couple of local-only topics for a
minute here, but Barry is always complaining about RG8U incessantly on
the NATIONAL list, and he doesn't talk about it at all on the LOCAL list
or even ask me or any of the other leadership team members who is doing
it... so...]

Barry, 

Watching you get all riled up about that fake callsign over and over
again is quite entertaining.  I know EXACTLY who set up a rig with RG8U
back during system testing, and it's still floating around in the memory
of that rig, and I think I know EXACTLY why they keep doing it... 

Hint: By now, it's just to annoy you.  No one else cares.  Get a clue.  

They happen to have donated over $2000 worth of gear and were
instrumental in getting a repeater site -- without them, Colorado D-STAR
wouldn't have won the RFP process from HRO or even been viable.

You MIGHT want to ask locally before you rant for months about someone
on the national list.  Just seems like a good idea to me... but do what
you like.

To your point where you think they don't care about where they route
to... you're forgetting that callsign can't route ANYWHERE because it's
NOT REGISTERED.  

The dstarusers.org folks publicize non-registered transmissions without
vetting them as even being valid Gateway users -- but that isn't my
problem.  I've already been shouted down by the mob here for wanting a
way to ensure privacy at the Gateway (feed) end of that data, but the
anti-privacy mob says that the whole world needs to know when we all key
up, here in the U.S.

Thus, a very strange U.S. Only requirement... I don't see any
dstarusersjapan.org publication of all of their transmissions? 
Whatever.  

Publicizing every key-up without stripping the non-registered users is
silly if the point is to foster activity -- since no one can call that
callsign, and that callsign can't callsign route, command the Gateway
D-Plus, etc.

(I don't allow non-registered callsigns to command the links, ever since
Robin added that feature... for example.)

The only three places RG8U shows up:  1) On your rig locally.  If you
see it, you'll recognize the voice.  2) In the Gateway logs.  I see
those, and know who it is already.  3) Dstarusers.org because they
insist on publishing it, even though it's not registered and couldn't
route anywhere. 

You might want to stop attacking one of the group's benefactors on a
national mailing list before you've even asked about it on the local
list.  (And at this point, it's so funny that you don't know who it is,
we'll probably keep you in suspense!  Hahaha!)

Now back to something actually useful, hopefully... since this
particular issue is a non-issue, other than it very CLEARLY proves that
the so-called callsign field in D-STAR... isn't.  It's just a network
address, set by the user and utterly changeable.  Only an operator's
good-will keeps it set to a callsign, really.

Relying on having a CALLSIGN in that field is silly in the extreme. 
It's nice if everyone does it, but the field itself and the technology
really don't care what's in the rigs at all.  It's just an
alphanumeric field.  No amount of wishful thinking will stop someone
from copy-catting a callsign to gain access to routing... eventually.

Nate WY0X
--
  Nate Duehr
  n...@natetech.com



Re: [DSTAR_DIGITAL] Tactical Call indication - U.S. ONLY

2009-05-19 Thread John Hays
Yes, its legal (in the US):

FCC Part 97.119c One or more indicators may be included with the call  
sign. Each indicator must be separated from the call sign by the slant  
mark (/) or by any suitable word that denotes the slant mark. If an  
indicator is self-assigned, it must be included before, after, or both  
before and after, the call sign. No self-assigned indicator may  
conflict with any other indicator specified by the FCC Rules or with  
any prefix assigned to another country.

 From a protocol point of view, it is not part of the address/callsign  
- it is a separate field.  Actually the 8th position designator  
(module, etc.) is more problematic from a very strict reading of the  
above rule, but I think most regulators would permit some leeway  
here.  There is no intent to mislead and there is usually a space  
separating the callsign from the designator.

One must also be cognizant of 97.113a4 which prohibits false or  
decptive messages, signals or identification


On May 19, 2009, at 7:30 AM, Barry A. Wilson wrote:



 Ray  John,

 It was originally stated to use the MYCALL short message field which  
 is
 only 4 characters and I think it has merit but is it legal?


 

John Hays
Amateur Radio: K7VE
j...@hays.org



[Non-text portions of this message have been removed]



[DSTAR_DIGITAL] Programming 2820

2009-05-19 Thread Jim Ujcik
I'm trying to program my brand new 2820 and having all kinds of 
frustration. I've got the software from Icom, but it's essentially 
useless as you can't import repeater data. I've got RT's software, but 
it won't work (unfortunately, not the first time this has happened to 
me) with either an OPC478 or OPC1529. I've tried Chirp, but it also 
doesn't work (works with my 92AD, but not the 2820).

I've had programming software to build lists since 1996 when I got the 
first repeater directory with an FT-8500. I can't imagine programming a 
few hundred memories by hand. I checked the firmware on the 2820 and 
it's v1.07, so I think I'm up to date.

Any suggestions? I was really looking forward to using the 2820 in my 
car to replace my 8900, but I'm not a happy Icom camper at this time. Oh 
yes, I did send an email to Icom and got a reply that had nothing to do 
with this issue. I'm not surprised, they couldn't help diagnose a 
problem with my GPS mike for the 92AD last year either.

Thanks for any help!

Jim, WD9HBC




[DSTAR_DIGITAL] Icom V82: Connectivity and Control for D-Star

2009-05-19 Thread mungewell
Hi,
I'm getting closer to getting a D-Star capable rig, most likely the V82 (mainly 
for the low entry price).

I just wanted to check a few things...

1) It looks like the serial port is wired direct to the UT-118 module and 
connected with a 2.5mm stereo jack to D9 (or D25). Does this need a level 
shifter?

2) Does the V82 support remote control via the 'clone' port, or is operation of 
this port limited to when a special 'clone mode' is entered?

2a) If control is an option, is there Free (/OpenSource) software for 
controlling this radio?

Cheers,
Simon
VA6SDW.

PS. I found mention that the connector on/for the UT-118 is a AXN430C300, 
available via special order on Digikey. Thought I would mention as it was hard 
to find out. 



Re: [DSTAR_DIGITAL] Icom V82: Connectivity and Control for D-Star

2009-05-19 Thread John Hays
IC-V82 (with rebate) $130 + $200 to add D-STAR = $330
IC-91AD = $390

(Prices US$ from Universal Radio)

An extra US$60 gets you a true dual band (simultaneous VHF/UHF for FM,  
D-STAR on one side only at a time)
Much better user interface and you can control the radio from its  
software (may be extra).


On May 19, 2009, at 10:47 AM, mungewell wrote:



 Hi,
 I'm getting closer to getting a D-Star capable rig, most likely the  
 V82 (mainly for the low entry price).









John Hays
Amateur Radio: K7VE
j...@hays.org



[Non-text portions of this message have been removed]



Re: [DSTAR_DIGITAL] Programming 2820

2009-05-19 Thread Jack
Jim,  I have Both the 92ad and the 2820 and I program them both with RT 
software using the same RDF file I have an OPC cable and will look to see 
what number it is (it fits the front programming / control jack and I have 
found that using the RT ct-29 cable (there basic cable) that you can plug 
into speaker port one to also program the 2820.

please more detail on what you are doing to set up and what errors you are 
seeing.


Jack  N6UYB/4
- Original Message - 
From: Jim Ujcik wd9...@flightbrothers.com
To: dstar_digital@yahoogroups.com
Sent: Tuesday, May 19, 2009 1:45 PM
Subject: [DSTAR_DIGITAL] Programming 2820


 I'm trying to program my brand new 2820 and having all kinds of
 frustration. I've got the software from Icom, but it's essentially
 useless as you can't import repeater data. I've got RT's software, but
 it won't work (unfortunately, not the first time this has happened to
 me) with either an OPC478 or OPC1529. I've tried Chirp, but it also
 doesn't work (works with my 92AD, but not the 2820).

 I've had programming software to build lists since 1996 when I got the
 first repeater directory with an FT-8500. I can't imagine programming a
 few hundred memories by hand. I checked the firmware on the 2820 and
 it's v1.07, so I think I'm up to date.

 Any suggestions? I was really looking forward to using the 2820 in my
 car to replace my 8900, but I'm not a happy Icom camper at this time. Oh
 yes, I did send an email to Icom and got a reply that had nothing to do
 with this issue. I'm not surprised, they couldn't help diagnose a
 problem with my GPS mike for the 92AD last year either.

 Thanks for any help!

 Jim, WD9HBC




 

 Please TRIM your replies or set your email program not to include the 
 original  message in reply unless needed for clarity.  ThanksYahoo! Groups 
 Links






RE: [DSTAR_DIGITAL] Tactical Call indication

2009-05-19 Thread Woodrick, Ed
It is definitely not silly, because it legally viable solution to station 
identification.

Your statement is silly because it's just as easy for me to do the same thing 
on voice. Callsigns are hijacked on voice all the time.

Just because it can be done some other way doesn't mean that standard and 
practices shouldn't be developed to support a feature. For D-STAR, the 
standard, as specified in the protocol is for the field to contain your 
callsign.
If you stick to the specifics of the protocol, then if you put something 
besides your callsign in the field, then it wouldn't be in accordance with the 
protocol. If it isn't in accordance with the protocol, then you will need to 
follow the requirements of utilization of a non-published protocol. This would 
require, among other things, that the station identification be done in a 
standard protocol such as FM or CW. (For US rules)

So I guess if you want to get down to nitpicking, if the callsign is not in the 
field then you need to make sure to switch your radio to FM and identify 
appropriately.

Ed WA4YIH


From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of Nate Duehr
Sent: Tuesday, May 19, 2009 12:17 PM
To: dstar_digital@yahoogroups.com
Subject: RE: [DSTAR_DIGITAL] Tactical Call indication





Relying on having a CALLSIGN in that field is silly in the extreme.
It's nice if everyone does it, but the field itself and the technology
really don't care what's in the rigs at all. It's just an
alphanumeric field. No amount of wishful thinking will stop someone
from copy-catting a callsign to gain access to routing... eventually.

Nate WY0X
--
Nate Duehr
n...@natetech.commailto:nate%40natetech.com


[Non-text portions of this message have been removed]



[DSTAR_DIGITAL] U.S. Only - Re: Tactical Call indication

2009-05-19 Thread k7ve
--- In dstar_digital@yahoogroups.com, Woodrick, Ed ewoodr...@... wrote:

 If you stick to the specifics of the protocol, then if you put something 
 besides your callsign in the field, then it wouldn't be in accordance with 
 the protocol. If it isn't in accordance with the protocol, then you will need 
 to follow the requirements of utilization of a non-published protocol. This 
 would require, among other things, that the station identification be done in 
 a standard protocol such as FM or CW. (For US rules)
 
 So I guess if you want to get down to nitpicking, if the callsign is not in 
 the field then you need to make sure to switch your radio to FM and identify 
 appropriately.
 
 Ed WA4YIH

Though I am of the school that the MY field should contain one's own 
callsign, I don't think your argument about having to ID using FM or CW is 
correct. The standard protocol includes AMBE encoded voice, which can be 
readily deciphered by anyone with a D-STAR radio and giving a voice ID over 
AMBE, I believe, would constitute a legal identification within the US rules.

-- John, K7VE



RE: [DSTAR_DIGITAL] Tactical Call indication

2009-05-19 Thread Nate Duehr

On Tue, 19 May 2009 18:45:53 -0400, Woodrick, Ed

 So I guess if you want to get down to nitpicking, if the callsign is not
 in the field then you need to make sure to switch your radio to FM and
 identify appropriately.

Actually the opposite is true... 

Recent FCC cases have affirmed that, for example, digital HF voice needs
to remain in the VOICE portion of the band... they consider it voice,
even though it's clearly a digital mode.

They've been slowly making this move for a while now.

I found it kinda funny... if I were to say take an mp3 file with musical
content, and send that over to a friend via Packet, D-STAR, whatever...
what's heard on the air isn't music by any means, but if you go by
their view on HF digital voice, you would have to say that was an
illegal music transmission.

Then you go look at HF digital data, and see Pactor III an unpublished,
non-reproducible format, but loved by Emergency Services volunteers
for its ability to jam a frequency without listening for other
modes/traffic... er, I mean... get the messages through... (sorry, my
brainwashing isn't quite finished yet)... 

But that's okay to the FCC.  The ONLY way to copy it is to own a $1000
product, that's not based on a published, reproducible specification...
unlike D-STAR, I might add.

I only share the above to point out that you *might* be wrong about what
the FCC here in the States thinks about legal ID's on D-STAR.  No
one's asked them yet, and gotten anything in writing.  

The regs are so far behind technology at this point, they'll probably
never be fixed.  The last time someone asked a D-STAR question of an FCC
representative, it turned into California going off and doing their own
thing and the FCC making the relatively recent announcement that yes, a
D-STAR repaeter *is* a repeater, and must therefore remain in the
defined repeater sub-band in Part 97... that's only taken what... four
years to sort out?

Good luck getting an answer on legal digital/D-STAR ID's before the turn
of the next decade.  Everyone's OPINION is that both the callsign field
and the packetized voice are legal.  If you take the first away, the
repeater's aren't legally ID'ing.  If you take the second away, anyone
with anything OTHER than their callsign in the field including those
suffix characters someone else mentioned -- is hosed.

It's a can't win situation for all.

Meanwhile, I could put NATE both in my rigs and in my Gateway, and
who'd stop me?  And I could put KAREN in my wife's rig and in the
Gateway too.  If I were using it FIRST and another Nate came along...
that'd be a bummer for me, but I could be NATE1 and he could be NATE2.

Seriously -- you can keep arguing this from the perspective of
standards all day.  My POINT is and always has been, there's NOTHING
to ENFORCE those policies other than peer pressure and probably some
folks who'd take it upon themselves to police things with no charter
or right to do so.  I buy a rig, I can put whatever I want in that
field.  If I buy a Gateway, I didn't sign anything that said I couldn't
put it in the database, either.

Am I really going to DO any of it?  NO.  It's a hypothetical example. 
But a strong one.  As a Gateway operator I might say no to some guy
who wants to register JOE, but you know out of hundreds of Gateways,
some misfit group would eventually allow it.

Think that one out to its logical conclusion... some guy now PAYS for
his Gateway software, since it's a pay to play product, doesn't have to
sign anything saying he'll follow ANY rules... and sues the snot out of
Icom if the Trust Server team says You can't register 'JOE'... it
*could* happen.

And that again has been and will continue to be my point... in a
source-routed system, using the callsign field as anything other than a
routing address, will eventually be broken by someone, who'll gain
followers, and then there will eventually be chaos... 

If we're taking vanity orders, I want C182 for the plane I'm going
to go fly this summer and forget all about ham radio and our utterly
backward networks... that can't even encrypt real command and control
functions so you can fix/maintain your infrastructure system from
over-the-air.

Even that's been broken though really... I don't think the DD module
setup by default blocks port 443 or does any inspection to see if a
payload is encrypted.  I bet I can SSH from a laptop on an ID-1 to a
machine halfway around the globe, making both my transmissions and the
transmissions of the DD module, illegal here in the States.  

Just one more example of the regs being so far behind modern times, it's
not even funny.  The sidebar I was asked to write for the ARRL VHF/UHF
Digital Communications Handbook about the use of encryption in Ham
Radio, was just the regulatory tip of the iceberg.  Callsigns in the
right place in a packet, isn't even important enough to be on my radar. 
That's how much I don't care.  Send me BOB for all I care... just sign
in voice... doesn't bother me a bit.  

RE: [DSTAR_DIGITAL] U.S. Only - Re: Tactical Call indication

2009-05-19 Thread Woodrick, Ed
The issue is not that it  is readily decodable, it is more along the line of 
having a publicly documented protocol.
One might wonder why the DSTAR protocol is published at the ARRL 
site(http://www.arrl.org/FandES/field/regulations/techchar/ ). It is my 
understanding that the protocol is published to make sure that it fits FCC 
97.309(a)(4).



Ed WA4YIH

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of k7ve
Sent: Tuesday, May 19, 2009 6:56 PM
To: dstar_digital@yahoogroups.com
Subject: [DSTAR_DIGITAL] U.S. Only - Re: Tactical Call indication





--- In dstar_digital@yahoogroups.commailto:dstar_digital%40yahoogroups.com, 
Woodrick, Ed ewoodr...@... wrote:

 If you stick to the specifics of the protocol, then if you put something 
 besides your callsign in the field, then it wouldn't be in accordance with 
 the protocol. If it isn't in accordance with the protocol, then you will need 
 to follow the requirements of utilization of a non-published protocol. This 
 would require, among other things, that the station identification be done in 
 a standard protocol such as FM or CW. (For US rules)

 So I guess if you want to get down to nitpicking, if the callsign is not in 
 the field then you need to make sure to switch your radio to FM and identify 
 appropriately.

 Ed WA4YIH

Though I am of the school that the MY field should contain one's own 
callsign, I don't think your argument about having to ID using FM or CW is 
correct. The standard protocol includes AMBE encoded voice, which can be 
readily deciphered by anyone with a D-STAR radio and giving a voice ID over 
AMBE, I believe, would constitute a legal identification within the US rules.

-- John, K7VE



[Non-text portions of this message have been removed]



[DSTAR_DIGITAL] Aeroflex / Icom DSTAR Test Set

2009-05-19 Thread Steve Bosshard
James N0XIA mentioned on the Texas DSTAR Net tonight that Aeroflex offers a 
Private Mobile Radio test set that includes DSTAR testing.

http://www.aeroflex.com/ats/products/prodfiles/news/031820092.pdf

Not for the everyday ham, but I believe this is the first test unit that works 
with DSTAR.

73, Steve NU5D



[DSTAR_DIGITAL] Re: Icom V82: Connectivity and Control for D-Star

2009-05-19 Thread mungewell
 1) It looks like the serial port is wired direct to the UT-118 module and 
 connected with a 2.5mm stereo jack to D9 (or D25). Does this need a level 
 shifter?

I found the service manual which shows the circuit for the UT-118 contains a 
MAX232, so input to radio is RS232 levels.

 
 2) Does the V82 support remote control via the 'clone' port, or is operation 
 of this port limited to when a special 'clone mode' is entered?

I also found some programming software. By default it does not enable the DStar 
settings/options, but one would assume that its controlled by a bit set in the 
'.icf'. 

Can anyone forward me an example '.icf' from a unit with DStar fitted?

Thanks,
Simon.





Re: [DSTAR_DIGITAL] Aeroflex / Icom DSTAR Test Set

2009-05-19 Thread Nate Duehr
That's cool.

Expected June 2009.

Nate WY0X

On Wed, 20 May 2009 02:00:02 -, Steve Bosshard
bossh...@gmail.com said:
 James N0XIA mentioned on the Texas DSTAR Net tonight that Aeroflex offers
 a Private Mobile Radio test set that includes DSTAR testing.
 
 http://www.aeroflex.com/ats/products/prodfiles/news/031820092.pdf
 
 Not for the everyday ham, but I believe this is the first test unit that
 works with DSTAR.
 
 73, Steve NU5D
 
--
  Nate Duehr
  n...@natetech.com



RE: [DSTAR_DIGITAL] Tactical Call indication

2009-05-19 Thread Nate Duehr

On Tue, 19 May 2009 21:36:36 -0400, Woodrick, Ed
ewoodr...@ed-com.com said:
 Interesting, I see that Pactor III protocol is published at
 http://www.arrl.org/FandES/field/regulations/techchar/PACTOR-III.html

Ahh they finally gave in and realized it was illegal to keep it
proprietary, I see.  Sorry, I became disinterested late last year or
before.  I guess they finally did the right thing.

 I believe that as with D-STAR, portions of the signal might be
 proprietary, but the envelope protocol is published and specifically the
 station identification is documented. The encoding portion of Pactor III
 could be considered similar to that of the AMBE vocoder.

Is there any practical difference between a vocoder and a proprietary
encryption algorithm to the receiving station?

 As to SSL encryption, I believe that the response may be similar to that
 of the High Speed Data Committee on the 802.11abc protocols. The word
 encryption does not appear in Part 97, but the word obscure does. Part
 97.309(b) specifies what is permitted and it can be indeed interpreted in
 a number of ways. Probably the most interesting is 97.309(b)(3) that
 indicates that if asked, the original information must be provided. This
 would indicate to some that encryption is actually expected.

That was my conclusion in the sidebar also.  If you could provide anyone
listening with a way to decrypt the data -- you stood a fighting
chance, but it's not black and white in the U.S. regulations.

Now apply that tidbit to the above CODEC.  We can't decrypt D-STAR
signals without a proprietary chip from a manufacturer.  While I'm the
first to defend the manufacturer in this regard (PhD's in math aren't
cheap, and the people who earned them also have to feed their families),
it's just an interesting corrolary when you look at it this way, isn't
it?

Go the other direction -- someone bent on encrypting something could
call it their proprietary encoding and sell a chip to do it marketed
as a CODEC and get away with obscuring their transmissions... they
could have order delays, problems with upstream vendors, out of
stock and all sorts of made-up problems for ... who knows?  I think at
least a year or two, where they and their buddies could be the only
folks who could copy what they were transmitting.  (Well, NSA and other
uber-smart folks might listen in and figure out a simple scheme, but
we'll leave them out of this discussion.  Someone's ALWAYS listening...
no doubt about that.)

So... then they come out with a beta test of Version 2... start
shipping Version 1 to everyone, and limit the beta test to the original
group... and that lasts a year, or they announce setbacks and it
becomes two... then they release it again with delays, problems.  If the
first one really wasn't all that useful to anyone, by now they've fallen
off of all but the zealouts radar... so to speak.  

Anyway, it's a completely fictitious story made up to show how
encryption of Amateur transmissions could be done.  Frankly, so few
people monitor odd-ball simplex channels, or even less listened to...
UHF or higher SSB... that it's really not that hard to have a
semi-private conversation on the ham bands... heck, if you can get
between or behind me and the guys across town I'm talking on 10 GHz to
(yes, I do that for contests, but it's generally a pain any other
time)... we'd probably be happy to hear you and have you join in.  (And
yes, I've had round-table ragchews on 10 GHz... if everyone's in the
right place and the dishes are pointed right!)

The discussion, of course, is all in good fun.  But I ask:  What's the
EFFECTIVE difference between something we call a CODEC, and something
that does encryption of a data stream.  I contend:  Not much.  And the
regulations are WAY behind on this one... maybe rightly so... how would
they ever define it.  How would you prove the intent was to obscure? 
(Unless they're dumb enough to talk about their intent on-air or off, I
suppose.)

It's interesting, isn't it?   Pretty deep topic for a hobby to deal
with.  In my professional work, we see trade secrets for CODEC operation
all the time.  As it spills over into the Amateur airwaves, it's quite
entertaining to see how we're going to deal with all of it.

Nate WY0X

p.s. I'm NOT saying the Pactor III folks were trying to encrypt, by
the way.  But it's highly convenient that it took quite a while for a
fully-developed specification to hit the web/public eye when the
original modems were over $1000.  Quite a lot of motivation as this
technology gets more complex for the manufacturer to hold on to
secrets about the operation of any said particular digital system
until their development costs and a little profit can be gained.  Again,
not accusing them of doing that... just saying it'd be real easy to make
that logical jump mentally.

p.p.s. I'm also NOT saying D-STAR is encrypted.  There are examples of
decoding the audio from any radio already... but none that don't
require the AMBE chipset