[dstar_digital] Re: UK dplus Reflector REF005, User Guide and Status Page

[john_ke5c]

> The UK now has a local reflector, "REF005", hosted by the UK
Interconnect
> Team (UK-IT) in Telehouse, London. This reflector will provide low
latency
> connections for UK and European D-Star users.

Since the internet has global coverage, this might more properly be
described as a "private UK/EU reflector" than "local reflector".  This
is more akin to a closed repeater than a coverage range limited repeater.

73 - - John

[dstar_digital] Re: D-STAR at Dayton Hamvention & Friday Night Event

[john_ke5c]

> Has anyone seen the K5DIT in the dongle pull down?

http://dsyncg2.dstarusers.org/index.php?gw_status=K5DIT

They are not running dplus.

73 - - John

[dstar_digital] But: D-STAR at Dayton Hamvention & Friday Night Event

[john_ke5c]

But now they are running dplus and dstarusers.org shows folks dongling
in.  

73 -- John
 
> > Has anyone seen the K5DIT in the dongle pull down?
> 
> They are not running dplus.

[dstar_digital] Re: GPS Receiver for ID-800H

[john_ke5c]

> What I would ideally like is just a plain-jane receiver with the RS-
232 output that I can mount in the trunk next to the radio. I have 
been looking on the Internet and the descriptions do not include 
whether they have RS-232 output in the proper format.

I believe these are 5V, not 12V, models but they still may give you 
some ideas:

http://www.byonics.com/tinytrak/gps.php

73 -- John

[dstar_digital] Re: Suggestion/idea

[john_ke5c]

> However, when I get no less than 15 emails and 3 phone calls in the 
> past week complaining, I must act.  I cannot imagine other cities 
> doing what we have been doing are not getting similar complaints.

Reflector etiquette is still evolving.  Fortunately folks on 1C are
getting in the habit of pausing five or more seconds before keying up
during a ragchew so others can get in, meet, etc.  A bigger problem is
what to do when you turn your radio on to find the gateway linked with
an ongoing reflector chat but you want to make a local call.  Or you
turn your radio on and don't know if the gateway is linked or not -
just because it's quiet at first doesn't mean you are unlinked.

Thus, for the past week and one-half we have enabled "open linking
control" on K5CTX and W5HAT (dplus.conf allowadminlinkingonly=0), and
we have encouraged folks to link and unlink as they wish rather than
leaving the gateways hard linked.  So far we have not had any problems
other than folks being afraid to try.  The new dplus feature where the
identifier function ("I" in callsign position 8) allows a user to
determine if the gateway is linked really helps when you turn your
radio on and don't know the link status because it's quiet.  Of
course, if you find out you are linked, you are not told to what, but
that doesn't matter.  We have told our users that when they turn their
radios on and hear no one else local on, they can do whatever they
want with the gateway - unlink it, link it, or leave it the way it is.

For more info:

http://www.kkn.net/pipermail/ctds/2008-June/10.html

http://www.kkn.net/pipermail/ctds/2008-May/06.html

http://www.kkn.net/pipermail/ctds/2008-May/07.html

73 -- John

[dstar_digital] Re: Suggestion/idea

[john_ke5c]

Why don't you try open linking per my post rather than button the
hatches down?  What have you got to lose?  If it doesn't work, then
you can go back.

73 -- John

--- In dstar_digital@yahoogroups.com, "Randy" <[EMAIL PROTECTED]> wrote:
>
> Thanks for all of the replies!  Unfortunately, with D-Star there are
> not a whole lot of choices for people to "spin the knob" to something
> else if they don't hear something that interests them.  Of course,
> having D-Star radios makes someone want to use them, not turn them
> off.  Right now, our 2m repeater is the only one that has decent
> citywide coverage.  Our mountaintop location misses a few parts of the
> city.  Our 440 machine is not as good as 2m right now.  That is why we
> are putting another full stack downtown Tucson in the near future to
> fill in the holes.  We may end up moving the reflector audio over to
> our "B" module or possible not link up at all.
> 
> Again, thanks for your comments.
> 
> 
>   
> 
> --- In dstar_digital@yahoogroups.com, Adrian  wrote:
> >
> > I say keep it going please? I often listen to it whilst doing stuff in
> >  the kitchen here.
> > 
> > Can�t the complainers �turn off� ? Like same if you don't
like a TV
> >  channel > don't watch it.
> > There is too much sooking in the world now already, hihi.
> > 
> > Great job Randy, and it would be sorely missed by the majority.
> > The fact, that it is REF001 connected, makes it a great success.
> > 
> > vk4tux
> > 
> > 
> > >
> >
>

[dstar_digital] Amplifiers for DStar repeater use

[john_ke5c]

> The system is BRILLIANTLY balanced for HT users with just the on-board 
> PA from our low test site.  We expect even better coverage 
> (approximately 5400 square miles) from the high site.

IMHO the reasons to run an amplifier on a stock ICOM DStar repeater
module are that your duplexer is poorly tuned or your (transmit) feed
line is wet, punctured, disconnected or RG-174.

73 -- John
sysop K5CTX, W5HAT, W5LM

[dstar_digital] Re: D-Star Doku in english

[john_ke5c]

> is there a complete translation somewhere, including the ethernet part?
> The english one you find on that side unfortunately ends at page 13 of
> 40...

I found this a while back, but it's only one chapter.  However, it's
an important chapter:

http://www.aprs-is.net/downloads/DStar/CHAPTER5.doc

73 -- John

[dstar_digital] Re: Japan Contact (corrected)

[john_ke5c]

> One touch on their calls does not work. I could not one touch calls 
> from Kansai. The area cq = ie; /xxp as we use for general 
> repeater push, is required.

Perhaps some day the details will be shared, but the usroot database
only has callsigns and public IP's for the JA gateways.  The band
module "terminals" have neither pcnames nor 10.0.0.0/24 internal
(usroot) addresses, but they are entered as terminals.  No terminals
exist for individual users.  The JA's may have their own 10.0.0.0/24
network and export only the public gateway IP's.  I wonder what usroot
exports back in return; probably the same.  Thus you have to use
"slash" or "area" routing as Adrian reports, and one touch callsign
capture won't work since no terminal information exists for individual
users in the database.  Persumably the JA's run neither dstarmon nor
dplus either.  So this is more of a limited bridge than a full
integration I guess.

73 -- John

[dstar_digital] Re: Japan Contact (corrected)

[john_ke5c]

> If calling CQ to Japan, be sure to tell them what repeater module you 
> are on ("This is AE5PL calling from W5NGU B").  Be clear and concise so 
> they know what to program into urcall.  When answering a CQ from Japan, 
> listen very closely for their repeater module callsign.  It is more 
> important than their station callsign for establishing the contact.  
> When you hear their repeater module callsign, program it into urcall to 
> respond.  It is an area call so you will need to program it with a / in 
> the first character position.  That would make JP3YHJ A become /JP3YHJA

Considering the language issues, it would also help to program your
transmit message to include your return gateway and band module, e.g.:

PETE AT /K5TIT A -or-
PETE AT /K5TIT-A -or-
SET UR=/K5TIT A -or-
PETE:UR=/K5TIT A -etc-

73 -- John




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

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/dstar_digital/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/dstar_digital/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[dstar_digital] Re: Factory programmed memories in IC-91AD?

[john_ke5c]

> My IC91AD has many frequencies programmed in the memories.  I think
this is part of the CPU initial setup and used for testing at the
manufacture.  It might have been setup by external programming such as
with a PC.

Page 118 of the IC-91AD manual says: "Reset the CPU before operating
the transceiver for the first time ..."  Having done that, I don't
have a clue what came in my memories.  If the radio works, I wouldn't
worry.

73 -- John

[dstar_digital] Re: CHIRP: An open-source programming tool for ICOM radios

[john_ke5c]

> If you're interested, check it out here:
> 
>   http://chirp.danplanet.com

Can you please give some hints on how to run on Linux for non-python
users?  

[EMAIL PROTECTED] chirp-0.1.2]# ./chirp.py 
Traceback (most recent call last):
  File "./chirp.py", line 19, in 
import serial
ImportError: No module named serial

[EMAIL PROTECTED] chirp-0.1.2]# ./csvdump.py 
Traceback (most recent call last):
  File "./csvdump.py", line 21, in 
from csvdump import csvapp
  File "/tmp/chirp-0.1.2/csvdump/csvapp.py", line 22, in 
import serial
ImportError: No module named serial

73 -- John

[dstar_digital] Re: CHIRP: An open-source programming tool for ICOM radios

[john_ke5c]

> > Perhaps it would make sense to start a new Yahoo group to focus on
> > discussing the issues of D-RATS & CHIRP.
>
> I would be more than happy to do that (although not on Yahoo), but
> people have expressed disinterest in that in the past. Personally, I
> filter mail so heavily that more targeted mailing lists allow me sort
> the massive amount of email I receive, but I understand that not
> everyone works that way.

I hope you keep it here.  Just because the prior poster had trouble
installing D-RATS:

http://groups.yahoo.com/group/dstar_digital/message/3582


does not mean the topic should be moved.  Thanks for your work!

73 -- John



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

[dstar_digital] Re: reflector guideline ??

[john_ke5c]

> We also have our port B connected 24x7 but we
> don't let our users link or unlink. 

Why?

BTW, ANYONE can unlink.

73 -- John

[dstar_digital] Re: reflector guideline ??

[john_ke5c]

> I don't believe every user can link or unlink. I think they need to 
be an
> admin. Also, using rtp2=not use only stops them from going out the 
gateway.
> If someone on another system were to come on the reflector they 
wouldn't
> know there is a local conversation happening on another connected 
system and
> their audio would still come through to the connected system.

allowadminlinkingonly=0

Allows everyone to link.

ANYONE can unlink - there is nothing you can do to stop this, well 
other than not run dplus.

73 -- John

[dstar_digital] Re: D-Star in Japan

[john_ke5c]

> if you want to have a talk to japan you can have a QSO with me:
> I am currently in Sapporo/Japan und stay near to the JP8YDZ repeater 
> (http://map.findu.com/jr2zei). I am often QRV in the evenings 
> between 11 UTC and 15 UTC.

JA gateways appear to be running javAPRSSrvr for D-PRS:

JR2ZEI>API92,DSTAR*,qAR,JH8JFI-
I:/071216h4303.29N/14121.27Eb332/002/DG8NGN

as Jann says, but they do not show up on dstarusers.org.  Do the JA's 
run dstarmon and report to a different database?

73 -- John

[dstar_digital] Re: Newbie Question

[john_ke5c]

> Is there a Google map or a Google Earth overlay for nodes?

In D-Star jargon, those are gateways rather than nodes. Left-click and
hold to pan, use the zoom control top left to change resolution:

http://www.jfindu.net/DSTARRepeaters.aspx

73 -- John

[dstar_digital] Re: Newbie Question

[john_ke5c]

> I chose the ID800H over the IC2820 for two reasons:
> 1) Price
> b) ID800H  $$859.95, D* included.

$859.95???  I've purchased two, both in the low $500's, but that was 
before the price increase a month or so ago.  Just for comparision, 
Gigaparts is asking $579.99 today.  Others may be a few bucks cheaper.

> Also, the 2820 only allows digital on one frequency at a time (ie, 
> you can't be digital on 2M and 440 at the same time).

Excellent point! I'd not thought of that because I could not swallow 
the price tag, but you would need two AMBE decoders to listen 
simultaneously to two digital bands (and it only comes with one), so 
it's really still a mono-band digital radio.

73 -- John

[dstar_digital] Re: Newbie Question

[john_ke5c]

> Price, priceless when it comes to saving lives. worthless if you 
bicker about it.

Hi-hi Evans!  (Laughing in Morse code, perhaps you've heard of Morse or 
his code?)  Just curious, but who was it that died because emcomm used 
an ID-800H instead of a IC-2820?

73 -- John

[dstar_digital] Re: how are you routing?

[john_ke5c]

> I think it was either in the README or somewhere else in the update 
> notes Brian NJ6N sent out to all about two weeks ago?

I don't see any reason why what the trust server ops posted on the
admin group should be any big secret.  After all, most of us are in
this to learn:

Gateway G2 Ver 2.1 Upgrade

The "dsipsvd" software changes
• Data synchronization was improved (This is the primary reason of
this "Rev.2.1"release). Possibility of time-out problem occurrence
was drastically reduced.
• The software was modified to detect if the user did not change the
default repeater call sign "XXX" in the configuration text file,
and will not allow operation until the user enters a valid call sign
for the repeater.
• Rare instances of memory leaking were fixed.

The "dsgwd" software changes
• If a terminal moved into another repeater area of the same zone,
the software
overwrites the headers in incoming packets to redirect the data to
the correct area
repeater even though the updated user data are not yet shared in the
entire network. (Jim's comment – this helps a LOT for those of us
who move between UHF and VHF during a commute!)
• When dsgwd software detects a terminal movement (changing zones),
it immediately updates the Own Database entry of the terminal
position. This enables instant position data update and communication
link establishment regardless of the synchronization information sent
from the Trust Server.

Changes in default software setting
• The PostgreSQL "autovacuum" function has been turned on as the
default.
• Health checking (between TrustServer and each Local GW) interval
was adjusted to every 1 hour (it used to be every 5 minutes).

73 -- John

[dstar_digital] Re: how are you routing?

[john_ke5c]

> • If a terminal moved into another repeater area of the same zone, 
the software overwrites the headers in incoming packets to redirect 
the data to the correct area repeater even though the updated user 
data are not yet shared in the entire network. (Jim's comment – this 
helps a LOT for those of us who move between UHF and VHF during a 
commute!)

> • When dsgwd software detects a terminal movement (changing zones), 
it immediately updates the Own Database entry of the terminal 
position. This enables instant position data update and communication 
link establishment regardless of the synchronization information sent 
from the Trust Server.
> -
> Switching from one Gateway to another would still be delayed a bit, 
though.

NU5D and I just tested this a bit, and I've been trying to find a 
concise way to explain what we saw, unfortunately without much 
success, but here goes.

The setup is:

1) I have pgadmin3 running on a Fedora box.  I am logged into the 
dstar_global databases on K5CTX and W5HAT, and I am watching the 
sync_mng table entry for NU5D on both machines, each in it's own x-
window.  I refresh one view, then the other, back and forth every few 
seconds, so I can see changes within a second or two on each gateway.

2) NU5D is within range of both K5CTX and W5HAT.  He always transmits 
on the B band, and he zone routes to the other machine.  When 
transmitting on W5HAT^^B, he routes to /K5CTX^B.  We believe the 
results below would be the same if he was callsign routing to a 
user "homed" to the other gateway instead -- just so long as his 
routing takes his header to the target.

3) Before we start, both sync_mng tables show him homed on K5CTX^^B.

4) He transmits on W5HAT^^B with UR=/K5CTX^B (to force a stream to be 
sent there).  As fast as I can click refresh, sync_mng on W5HAT now 
shows him homed to W5HAT^^B.  My next click updates the window with 
sync_mng on K5CTX which now shows him homed to W5HAT^^A -- and this 
is a huge change from G2 before the update which would have continued 
showing him homed to K5CTB^^B for 8 to 12 minutes based on our prior 
tests.  

But why does sync_mng on K5CTX show him homed to W5HAT^^A when he is 
really on W5HAT^^B?  First, although K5CTX knows from the header it 
just received that he is on W5HAT, the header does not tell K5CTX 
which module he is on.  K5CTX would normally find that from its own 
sync_mng, aka the routing table -- which won't be up to date for 8 to 
12 more minutes.  Second, it does not matter if K5CTX routes to the 
correct module on replies to NU5D via W5HAT because with the new 
scheme, W5HAT overwrites the return header with the correct band 
module that NU5D is really on if the header is wrong.

5) Finally, in 3 to 8 minutes, the sync_mng table on K5CTX updates 
from showing NU5D on W5HAT^^A to W5HAT^^B reflecting a sync from the 
trust server has occurred.

We think this solves half of the homed gateway update problem - the 8 
to 12 minute delay we see in the sync_mng table being updated by the 
trust server after a user changes gateways.  The half it solves is 
that a call originator can always be answered, even if the gateway 
he/she is really on is different from the gateway listed in the 
sync_mng table on the gateway he/she is calling to.  As above, the 
sync_mng table on that distant gateway will now be immediately 
updated as soon as it hears a header from him/her rather than waiting 
for the trust server to eventually deliver the update.  Plus, if you 
are in QSO and move from one gateway to another, that QSO should 
follow you with perhaps the loss of one round - just so long as the 
other participant does not simultaneously move too.

However, if you originate a call to some who is not really homed to 
the gateway your local sync_mng says, you will not be correctly 
routed until your local sync_mng is updated by the trust server.  So 
I guess okay if you move, but not okay if whom you call moves.

Right?

73 -- John

[dstar_digital] Re: FW: [aprssig] APRS on DSTAR

[john_ke5c]

> Thought you 2820 buffs would like to see this one!
> > Good news on getting APRS onto the 2820 DSTAR radio!
> > 
> > JefF, KB2M has been working on a plug-n-play solution where you
> > just plug the D710 APRS Display head into the external
> > audio/data jack of the Icom 2820 radio so that you can run DSTAR
> > on band B and run APRS with almost all the features of the D710
> > on the A side.

This is drifting seriously off-topic, but I would hate to leave
someone trying to decide which D-Star radio to purchase with the
erroneous impression that jury-rigging a Kenwoood D710 APRS DISPLAY
HEAD ($324 GigaParts current out-of-stock sale price) would provide
the IC-2820 a complete APRS setup in addition to a complete D-Star
setup.  You would also need to purchase a second GPS for the D710 to
be able to TRANSMIT your position to APRS.  The D710 does not contain
a GPS, and there is no way to feed the output of the IC-2820 internal
GPS to the D710 or any external accessory.

73 -- John

[dstar_digital] Re: FW: [aprssig] APRS on DSTAR

[john_ke5c]

> Also I'm now looking at  getting the GPS data out of the 2820 to be
shared by an external device.

Two possibilities.  First, although not clear from the manual and you
probably have to have the digital band in GPS rather than DATA mode
and thus might not be able to use the low speed data channel for
anything else, see:

http://www.icomamerica.com/en/support/forums/tm.asp?m=7954

Second, the IC-2820 uses the iTrax130 GPS Receiver which you can read
about here: 
 
http://tinyurl.com/5nz4u6 
 
According to the above, Port 0 output is NMEA 0183 version 3.0 by
default.  TXD from port 0 goes through an open drain buffer/driver
(SN74LVC1G07) with maximum output drain voltage 5.5 and then appears
on pin 16 of J1, the UT-123 connector.  From there it goes to the main
micro, so if you tap this line, be careful!  I'd sure not connect it
to anything RS-232 without a level shifter.  If ICOM is running this
module in its default state, there's a good chance that NMEA TTL level
data from the GPS is continually present on pin 16 of J1, probably at
4800 baud, no matter what mode the digital side is in.  Pins 13 and 18
are ground, btw.

If you experiment, let us know your results.

73 -- John

[dstar_digital] Re: Help with poor audio on Dstar System?

[john_ke5c]

> Our Internet is fine.

As others have said, you know ON THE AVERAGE it is superb, but you 
don't know about VOIP/UDP performance (jitter, etc.).

What else are you running on the gateway computer that could steal 
CPU cycles and/or add ethernet traffic?  (Several folks have wondered 
about this.)
 
> This problem does NOT occur when we are using the repeater for local
> traffic, this ONLY occurs when using the Gateway.

So it's not very likely an RF, band module or controller problem.  
Plus it's intermittent, so you are looking for some condition not 
always present.
 
KE5KAF spends a lot of time linked to reflectors.  You can experience 
strange results when area or callsign routing to a UR if you and the 
UR target are also linked to the same reflector: you will have two 
voice streams going to the same place intermingling (interferring) 
with each other.  This usually just causes drop-outs, but not always, 
and this would not be an issue with local QSO's, and it would be 
intermittent.

73 -- John

[dstar_digital] Re: Help with poor audio on Dstar System?

[john_ke5c]

> I really hope this is the problem.  I removed the "S" of the system.
 Lets see now if that was the problem all along.  

I just queried dstar_global: 154 systems have "S" terminals defined. 
If this is a problem, many others should experience this issue also.

position(' S' in target_cs) > 0 AND del_flg = FALSE

"AK4EG  S", "CQ0DFO S", "CQ0DLR S", "DB0ADB S", "DB0BOS S", "DB0BS 
S", "DB0COM S", "DB0DDE S", "DB0DDS S", "DB0DUR S", "DB0FEU S",
"DB0FHW S", "DB0HAA S", "DB0HRF S", "DB0HRM S", "DB0MYK S", "DB0NG 
S", "DB0RDH S", "DB0SAT S", "DB0SZS S", "DB0TVM S", "DB0VOX S",
"DB0WIM S", "DB0WZB S", "DB0WZ  S", "DB0XPO S", "DF0MHR S", "DM0MW 
S", "DM0XX  S", "EA3RCC S", "EA5A   S", "F1ZPL  S", "GB7AU  S", "GB7DE
 S", "GB7DG  S", "GB7DS  S", "GB7DV  S", "GB7DW  S", "GB7DX  S",
"GB7FK  S", "GB7GD  S", "GB7IC  S", "GB7NM  S", "GB7SF  S", "GB7SS 
S", "GB7WF  S", "GB7WP  S", "GB7WT  S", "GB7YD  S", "HB9AR  S", "HB9BO
 S", "HB9F   S", "HB9HD  S", "HB9IAC S", "IQ2GM  S", "IQ4GS  S",
"IR0UAC S", "IR2BD  S", "IR3CZ  S", "IR3DA  S", "IR3DB  S", "IR3UEF
S", "K0MDG  S", "K1HRO  S", "K2DIG  S", "K3PDR  S", "K5ZOE  S", "K6CHO
 S", "K6IFR  S", "K6SOA  S", "K6VO   S", "K6ZC   S", "K8LCD  S",
"KB2PCN S", "KC2SWE S", "KD0CGR S", "KD2STR S", "KD8DRG S", "KE5RCS
S", "KE5UKL S", "KF6BQK S", "KI4PPF S", "KI4SAZ S", "KI4TMJ S",
"KI4WXS S", "KI6JUL S", "KI6JUM S", "KI6KQU S", "KI6MGN S", "KJ4BDF
S", "KJ4BWK S", "KJ4BYI S", "KL7FF  S", "N4JOG  S", "N7ARR  S", "N7GOC
 S", "N7IH   S", "N7MK   S", "N7TUQ  S", "N7TWW  S", "NI4CE  S",
"NJ2DG  S", "NS9RC  S", "NT5RN  S", "OE1XDS S", "OE5XOL S", "OE6XDE
S", "ON0ULG S", "OZ2REA S", "SZ1SV  S", "VA3ODG S", "VA7ICM S",
"VE3WIK S", "VE6GHZ S", "VE6IPG S", "VE6WRN S", "VK4NUT S", "W0MAO 
S", "W0NWA  S", "W0YC   S", "W1IXU  S", "W3EXW  S", "W3OI   S", "W4BUG
 S", "W4WBC  S", "W5GAD  S", "W5HDR  S", "W5HDT  S", "W5NGU  S",
"W5SHV  S", "W5ZDN  S", "W6BGR  S", "W6HHD  S", "W6HRO  S", "W6UUU 
S", "W6YYY  S", "W7DIN  S", "W7KDS  S", "W7URG  S", "W8LIV  S", "W8RNL
 S", "W9ARP  S", "W9CEQ  S", "WA4PBS S", "WA9ORC S", "WB5MSB S",
"WD4STR S", "WD5AII S", "WD5STR S", "WD8MKG S", "WH6DHT S", "WH6DIG
S", "WW4EMC S", "WX8GRR S", 

[dstar_digital] Re: Help with poor audio on Dstar System?

[john_ke5c]

Is your webserver on the same machine as your gateway, or does it just 
share the IP address and router?

http://71.40.213.134/ & https://71.40.213.134/Dstar.do

73 -- John

[dstar_digital] Re: Repeater Linking (Help me see my errors please!)

[john_ke5c]

> MyCall: KD5EOC*E

This is not a valid (registered) call in the gateway database, so you
will not be able to access any gateway using it.  You heard them
because they were using valid calls.

73 -- John

[dstar_digital] Re: Repeater Linking (Help me see my errors please!)

[john_ke5c]

> port to port calling would be the stroke call sign port ( /WD5STRB )
> however, they have to do the same back to you.

You can't call port to port using an unregistered MY.

> Other wise, since they are on the Reflector, just connect to the
> reflector and call.

You can't connect to a reflector using an unregistered MY either.

The solution is to simply use a registered MY.

73 -- John

[dstar_digital] Re: Repeater Linking (Help me see my errors please!)

[john_ke5c]

> Also, the letter at the end is supposed to just be an SSID thus not
> requiring anything but the actual callsign to be programmed into the
> Gateway. Both, stations were set up exactly the same way except the
> differences in the callsigns.

D-Star callsigns are eight characters in length, not six.  KD5EOC^^
and KD5EOC^E (^ = space) are unique callsigns.  The first is
registered in the usroot gateway database and the second is not.  The
SSID concept does not apply to D-Star callsigns.  Hope this clarifies
your experience.

73 -- John

[dstar_digital] JOTA on reflector 4A and 2A - okay?

[john_ke5c]

Let's use REF004A and REF002A for JOTA next weekend - OKAY?  4A will
be primary and 2A will be overflow.  The logic to not use 1A or 1B is
that the whole world is connected to 1C and if you connect your
gateway or dongle to 1A or 1B you will also get the 1C DV stream (you
won't hear it, but it will load your internet connection).  That is
also why I would put the overflow on a different reflector plus that
gives some redunancy for a reflector failure, admittedly rare.

http://www.scout.org/jota

http://www.arrl.org/scouts/jota/

73 -- John

[dstar_digital] Re: 92AD cable to use DRats

[john_ke5c]

Be sure you have GPS Mode set to OFF.

73 -- John

> I have been using DRats on my ID-800H and it works well.  I am trying 
> to use DRats or DChat with the 92AD using the same cable that I use to 
> program the 92AD from the laptop.  It does not seem to work with DRats 
> or DChat.  Is there another cable that I should be using or am I doing 
> something wrong?

[dstar_digital] JOTA reflectors: 5C, 10A, 4A

[john_ke5c]

Thanks for all the responses on this and other groups.  The primary 
JOTA reflector will be 5C, the first backup/overflow will be 10A, and 
the second backup/overflow will be 4A.

M0TMX said about 5C: "Having had a word with other members of the UK 
Interconnect Team we are happy to offer REF005C for this weekends 
JOTA activity. Plenty of bandwidth, and we can also put up a 'Last 
Heard' page and a page highlighting what D-Star Repeaters are 
connected to REF005C which may be helpful to see what activity is 
about."

N1CNV said about 10A: "Reflector 10 A is also available as a 
Backup/Primary for the JOTA."

"JOTA is held the third weekend in October of each year. JOTA takes
place starting Saturday at  hours local time (12:00 AM) to Sunday,
23.59 hours local time (12:00 PM), though some activity continues over
from Friday to Monday to take advantage of long distance (DX) time
differences." We will probably connect from 6 AM local Saturday to 6
PM local Sunday, but that is not definite.

http://www.scout.org/jota

http://www.arrl.org/scouts/jota/

73 -- John

Re: [DSTAR_DIGITAL] what is a Reflector

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "nhorv" <[EMAIL PROTECTED]> wrote:
>
> I'm curious, what is a Reflector? 

A DStar gateway is a computer program, a computer, and an internet
connection that also connects (digitally) to a DStar repeater
(technically to a DStar controller which connects digitally to a
DSstar repeater).

A repeater-gateway is how one DStar user can talk to another DStar
user on another (usually distant) repeater-gateway using the original
DStar conceptualization of transmitting an addressed digital voice
stream with your radio controlling the addressing.

A reflector is a second way to let users on one repeater-gateway talk
to users on one (OR MORE) distant repeater-gateways via another piece
of software ("dplus") which is best viewed as a "gateway enhancement"
or "gateway extention".  Typically sysops use dplus to "link"
repeater-gateways to a reflector.  Every digital voice stream each
repeater-gateway sends to the reflector is sent back out (reflected)
to all other attached gateways.  It is a "party-line" or bridge for
repeater-gateways.  It is this one-to-many capability that really
distinguishes it's performance from the original DStar one-to-one concept.

A device called a dvdongle will also let individual (FCC licensed)
users communicate with a reflector (and all linked repeater-gateways)
from a computer as if they were using a DStar radio and accessing a
repeater-gateway.

I'm sure others will explain this differently, but this is one way.

73 -- John

[DSTAR_DIGITAL] Re: How much bandwidth?

[john_ke5c]

> We have recently set up a D-Star repeater. While the repeater is
working 
> very well, we don't have ready access to the internet at the
repeater site 
> and are considering various options to get internet service there
including 
> wireless. My newbie questions are just how much bandwidth is needed
to tie 
> the D-Star machine to the internet and what are others doing
successfully in 
> a similar situation.

This depends on how much you want to run and do.  W5HAT runs two band
modules and dplus on a commercial grade Clearwire wireless connection
which is specified to be 750 Kb up and down.

W5LM runs one band module and dplus on a home grade Clearwire wireless
connection which is specified to be 750 Kb down and 250 Kb up.

We limit dongle users to two maximum, and we do not user ICOM's
"multicast" have found it pretty unreliable and at times just
obnoxious (dropping DV streams onto gateways with QSO's in progress,
etc).  The only time we've had issues in the past was when
experimenting with multicast.

73 -- John

[DSTAR_DIGITAL] Re: IC-92AD Connector

[john_ke5c]

> Mark, KJ4VO at the HRO Atlanta store and I have been researching
this.No
> one has the proprietary connector, period.   I have not been able to
locate
> the custom waterproof connector vendor that Icom uses either.   

A proprietary implementation of an "open" protocol requires a
proprietary connector rather than an open connector: how symmetric is
that!

73 -- John

[DSTAR_DIGITAL] ARRL Technical Innovation Award (2009)

[john_ke5c]

Please consider nominations for this award (technical innovation) from
within the DStar community for this award.  Nominations close March
31.  Nominate online:

http://www.arrl.org/FandES/ead/edunom.html?aw_id=11

The ARRL Technical Innovation Award is granted annually to the
licensed radio amateur or to individuals who are licensed radio
amateurs whose accomplishments and contributions are of the most
exemplary nature within the framework of technical research,
development and application of new ideas and future systems in the
context of Amateur Radio activities, including but not limited to:
* Increasing use and development of higher-speed modems and improved
packet radio protocols;
* Expanded use of personal computers in Amateur Radio applications;
* Increased efficiency in use of spectrum;
* Alleviation of long-standing technical problems, e.g., antenna
restriction, competition for spectrum, EMC;
* Digital voice experimentation;
* Improved portable and mobile communications capability through
Amateur satellite development;
* Increased use of solar, natural and alternative power sources for
field applications;
* Development of practical compressed video transmission systems;
* Spread-spectrum technology and applications; and
* Development of assistive/adaptive technology for disabled amateurs.

73 -- John

[DSTAR_DIGITAL] Re: D-STAR Hot Spot v2.01 released

[john_ke5c]

> I'm curious what method you used to marshall yourself into a
downloadable
> file?
> 
> >I can be downloaded from the files section of the gmsk_dv_node
Yahoo
> > group.

Some type of encapsulation or perhaps virtualization? -:)

73 -- John

[DSTAR_DIGITAL] The big DStar breakthrough needs to be ...

[john_ke5c]

I've been meaning to clean this post up for a while, but since I don't
think I'll really do that soon, here's the rough hypothesis: the next
big breakthrough in DStar will be a user-friendly user interface.  The
current DStar radio interfaces were developed before DStar really was
used much and do not reflect how these radios really are and can be
used.  Many folks hear about DStar, buy a radio, try it for a few
weeks, then put it aside or sell it because they feel it is too
complicated.  

The current DStar radio UI's are as powerful and functional as DOS,
and they need to become like windows - note that's a small 'w' so I
mean the generic concept rather than a specific Windoze or X-windows,
etc.  How would this happen?  A new radio UI is implemented with:

1) a 'glass cockpit' style of interface - an LCD that is either itself
touch sensitive or is surrounded by softkeys, or both.  This is
against the trend of physicially smaller and smaller radios, but look
at some of the current smart phones.  HT's don't have to fit in a
shirt pocket;

2) a repeater/gateway database that is EASILY downloaded and updated 
via the internet - wifi too so you can do this in your driveway;

3) no additional 'programming' of the radio to use this downloaded
data.  The radio will present this data to the user via the UI in one
of several useable forms such as lookup by city, by geographic
distance from the radio which also has a GPS of course and by good old
callsign;

4) selecting a repeater from the database sets all necessary DStar
callsigns, frequency parameters, etc;

5) a builtin help system;

6) a logical presentation of the "one-touch call" to callsign route
back to a caller on a distant gateway.  The UI might popup the
caller's information and the matching database information for the
caller's gateway and ask if you wish to engage in a QSO now or save
for a few minutes later;

7) some limited last heard information accessible via the low-speed
(limited bandwidth) data subchannel;

8) reflector linking (via an in-range repeater/gateway - callsign
routing to the gateway?), perhaps using the low-speed data subchannel
to send a keep-alive request every 30 to 60 seconds to the selected
reflector to keep you linked;

9) multiple uses of the low-speed data subchannel so GPS data might be
alternated with a reflector keep alive request, etc.;

There's more, but this is enough to be food for thought.

73 -- John

[DSTAR_DIGITAL] Re: Thanks for the links:

[john_ke5c]

> This is a great resource. Thanks! Yes I registered or at least I
sent off the info to the sysop of 
> the local repeater that I am using. I did not receive a response
back yet that I am registered 
> though. I am guessing that he has done that since I worked thru
reflector 001 great.

Hi Steve,

I just checked the database, and you are not registered yet, or at
least not completely.  Registration is a two part process as explained
here for the W4DOC gateway:
 
http://www.dstargateway.org/D-Star_Registration.html

The sysop for another gateway may do it all for you, or as in the case
of W4DOC, you may have to do most of it.  Especially note step 7.  

Also note that if K6LRG is "dplus linked" to another gateway or
reflector, you will be able to hear and talk to folks "local" to the
linked gateway or reflector even if you are not registered so long as
you have R2 set to K6LRG^^G where ^ is a space.  It's confusing, but
"linking" is an extention to the DStar specification and behaves a
little differently.  Good luck!

73 -- John

[DSTAR_DIGITAL] Re: Texas DSTAR Net

[john_ke5c]

If any of you Dallas DStar'ers would like to join in, you could ask
the K5TIT sysops to link one of the band modules between 8 and 9 to
REF004B.  We have cron jobs on K5CTX, W5LM, W5HAT, and KE5RCS to do
this automatically each Tuesday night so we don't have to rely on a
sysop remembering.  Hope to hear you tonite.

73 -- John

--- In dstar_digital@yahoogroups.com, "Steve Bosshard" 
wrote:
>
> The Texas Tuesday Night 8PM Central 02:00Z Wednesday AM UTC, DSTAR NET
> has moved from Reflector 4A to Reflector 4B to be more in line with
> reflector recommended usage.  This is a directed net and if no NCS is
> available a round table.  Topics are about Texas DSTAR, DSTAR in
> General and whatever else arises.  Visitors Welcome - Texas Friendly.
>  KB2WF is the 'Spark Plug' and NCS duty varies.
> 
> 73, Steve NU5D
> 
> visit http://groups.yahoo.com/group/dstar_digital/database
> 
> for more net information.
>

[DSTAR_DIGITAL] Re: D-STAR to APRS MSG and visa-versa

[john_ke5c]

> If not then why not? Why go DIGITAL if you cant send a MSG? 

1) I'd much, much rather listen to a DStar transmission than an analog
transmission, especially if a repeater is involved.  The overall voice
quality is much better than the typical amateur analog repeater. 
There are exceptions, but I'm talking about on the average.

2) While you can route (or link) analog FM (echolink, etc.), you can't
do it with the general flexibility of DStar, and each link adds
additional signal degradation.

I would have never bought DStar to send a MSG.  What intrigued me was
the voice quality and DV stream routing possibilities.

73 -- John

Re: {Disarmed} [DSTAR_DIGITAL]

[john_ke5c]

> Why do people change the Subject to the message?  This wrecks
threads and
> makes following them very difficult because it becomes fragmented.

Most of the time I have seen it done the subject of the thread has
changed.  Yahoo has groups have messages, but Yahoo is not suited to
be thread-based forum, an excellent example of which, is
http://www.howardforums.com/ for cell phones.

BTW, why do people use mailers that add that distracting and
irritating "{Disarmed}" tag?  A direct post or reply on the groups
website would eliminate that.

73 -- John

[DSTAR_DIGITAL] Re: ICOM announced new hand-held and mobile D-STAR transceivers, ID-80 and ID-880

[john_ke5c]

> Here is the link
> http://www.icom.co.jp/release/20090128/index.html
> albeit it's Japanese.

I ran it through babelfish.  There are no details on specifications of 
interest such as number of memories, how many characters in the display 
(eight would be a lot better than six so you could see the entire 
callsign without scrolling), etc.

73 -- John

[DSTAR_DIGITAL] Re: ICOM announced new hand-held and mobile D-STAR transceivers, ID-80 and ID-880

[john_ke5c]

> for those of you who were able to read that page did the usability
enhancements go any way toward 
> accessibility?
> Ray T. Mahorney
> WA4WGA
> UK call sign M0WGA

Ray, but what is the size of the accessibility market for DStar
radios?  How many potential customers are there to offset the
development costs required?  Are there any government subsidies to
offset such costs?  Thanks in advance,

73 -- John

[DSTAR_DIGITAL] Re: Very Very Confused!

[john_ke5c]

> W8RNL allows users to control links. I know that for a fact, but 
> don't know if you have to be registered to control Dplus.

A dplus.conf option allows the sysop to determine if users have to be
registered to control dplus or not.  Almost all sysops set this to
require gateway system registration for dplus control.  Only gateways
that require registration to control dplus can link to the reflectors
- that is the major reason sysops require it.

73 -- John

[DSTAR_DIGITAL] Re: jFindu Abuse

[john_ke5c]

> Any use of IFrames without the prior consent of the web site owner 
is, 
> IMO, abuse.  It is also the opinion of most hosting companies.  
Yes, 
> the pages are copyrightable.  I never claimed that the information 
was 
> copyrighted, only the pages and use of them in any form on another 
web 
> site is a violation of the copyright.

Probably not a violation of the copyright...

"As it stands now, there appears to be a doctrine of implied public 
access on the Web. The Web was created on the basis of being able to 
attach hypertext links to any other location on the Web. 
Consequently, by putting yourself on the Web, you have given implied 
permission to others to link to your Web page, and everyone else on 
the Web is deemed to have given you implied permission to link to 
their Web pages." (http://www.benedict.com/Digital/Web/WebLinks.aspx)

"The Ninth Circuit later revisited the question of whether in-line 
linking infringes the public display right in Perfect 10 v. Google, a 
case involving Google's Image Search. EFF participated as amicus in 
that case on this issue, revisiting the arguments first made in Kelly 
v. Arriba Soft, and the court ultimately held that in-line linking to 
images does not violate the public display right." 
(http://www.eff.org/cases/kelly-v-arriba-soft)

"Fair use is a defense to an allegation of copyright infringement 
under section 107 of the Copyright Act. Courts use a four factor test 
to determine the validity of the fair use defense. The court will 
weigh each factor, and no factor is dispositive. The factors are: (1) 
the purpose and character of the use, (e.g., is the use commercial? 
Educational?); (2) the nature of the copyrighted work; (3) the amount 
and substantiality of the copied material in relation to the 
copyrighted work as a whole; and (4) the effect on the market." 
(http://en.wikipedia.org/wiki/Software_copyright)

What's the commercial value in (elegently) reporting when a bunch of 
hams talked on a radio?  BTW, thanks for jFindu and especially 
javAPRSSrvr - they have truly increased the enjoyment of my hobby.

73 -- John

[DSTAR_DIGITAL] Re: Icom Software and Windows Vista Home Premium Edition 64 Bit

[john_ke5c]

> If the device has an FTDI chip this is pretty easy to solve.

The Prolific PL-2303 USB to Serial Bridge is another device for which 
64 bit drivers exist and work.  A while ago I purchased an OPC-478U 
knockoff from ebay:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=360128731827

and the 64 bit USB driver is available from:

http://www.prolific.com.tw/eng/downloads.asp?ID=31

You can download, unzip and execute 
PL2303_Prolific_DriverInstaller_1025.zip or Vista can find this for 
you.  After plugging the cable in, Vista fails to find a driver but 
then asks you if you want it to look on the web for you, etc.

I also have a USB to DB-9 serial port adapter which uses this same 
Prolific chip, so those are also around.

73 -- John

[DSTAR_DIGITAL] Re: Icom Software and Windows Vista Home Premium Edition 64 Bit

[john_ke5c]

> ID-1 

Which USB chip is in the ID-1?

> ID-800 

Are you using the OPC-478U USB programming cable?  If so, which USB 
chip does it use?  I earlier posted about an ebay knockoff of the OPc-
478U which uses a Prolific USB to serial bridge, but I don't know which 
chip the Icom cable actually uses since I don't have one.

> IC-PCR1500-2500 (my receiver is the the IC-PCR2500) 

Same question, which USB chip?  You need to know which USB chip so you 
know which chip makers website you need to search for 64 bit drivers.

73 -- John

[DSTAR_DIGITAL] Re: Icom Software and Windows Vista Home Premium Edition 64 Bit

[john_ke5c]

> IC-PCR1500-2500 (my receiver is the the IC-PCR2500) 

The IC-PCR-2500 uses the Silcion Labs CP210x USB to UART Bridge.  Try
downloading and running the "VCP Driver Kit" from here:

https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx

The documentation suggests this has 64-bit support.  For the ID-1 and
the ID-800 you may need other drivers depending on the USB chips
involved as earlier posted.  Anyone know what's in an ID-1?

73 -- John

[DSTAR_DIGITAL] Re: Icom Software and Windows Vista Home Premium Edition 64 Bit

[john_ke5c]

> ID-1 

The ID-1 uses the FTDI FT8U232AM USB UART so the 64 bit FTDI USB 
drivers per an earlier post SHOULD work with the ID-1.

73 -- John

[DSTAR_DIGITAL] Re: Icom Software and Windows Vista Home Premium Edition 64 Bit

[john_ke5c]

> I have the IC2820, ID1 and IC91AD S/W running fine on Vista64; quad 
core 9550.   It likely installed as a 32 bit program.  So it 
works 

32 bit applications will run on 64 bit Vista, however, you still need 
64-bit drivers if those programs use devices:

http://tinyurl.com/8byqqx

If you are successfully talking to your radios, then you are using 64-
bit drivers.  The ID-1 requires the FTDI drivers which may ship with 
Vista or which Vista knows how to find.  My dongle uses the FTDI 64-bit 
drivers, and I don't remember the exact details, but Vista had no 
trouble finding them.

Are you talking to your IC2820 and IC91AD using a serial port (64 bit 
Vista comes with 64 bit Com port drivers) or a USB to serial 
programming adapter?  The later can use a number of USB to serial 
bridges or UARTs, and the 64-bit driver required would depend on the 
manufacturer.

73 -- John

[DSTAR_DIGITAL] Re: P25 Vs DSTAR

[john_ke5c]

> Does anyone know if a P25 Digital radio the same as a DSTAR radio? I have an 
> EF Johnson 5100 that has digital capibilities and was wonder if that is the 
> same thing as a DSTAR.

Fully non-interoperable.  The similarities end at both being digital modes 
transporting voice and/or data and both using a variant of FM modulation.73 -- 
John

[DSTAR_DIGITAL] Re: Gateway using Wireless access / WIFI

[john_ke5c]

> My question, with a notebook computer using Linux would I be able to 
> configure a wireless device to seek out a WIFI network and provide and 
> Internet gateway to the system?

You can do this but only if you have control of the access point your linux 
wireless client device accesses so that you can set up port forwarding.  From 
what you say, you imply that would not be the case.

73-  john

[DSTAR_DIGITAL] Re: D-Star to "listen" to reflectors or distant repeaters

[john_ke5c]

> Callsign routing also has the excellent additional benefit in that it  
> will "follow" anyone anywhere in the network, as long as they've keyed  
> down ONCE on the local repeater... wherever they may roam.   If you  
> put "WY0X" into your rig, and I go to California, Hawaii, or even just  
> switch modules on our local repeater stack... your call will find  
> me... as long as I've keyed once.

DStar callsign routing does not provide the nearly instanteous roaming that you 
may be used to with your cell phone or a trunked two-way radio system.  Folks 
have posted on this in the past, and when the gateway system software was 
working correctly, a four to ten minute delay was pretty common for the roaming 
database to catch up when a user keyed up on a different gateway.  So if you 
are driving along the highway and switch from one repeater-gateway to another, 
folks trying to callsign route a DV stream to you will be unsuccessful for 
about that length of time.  Lately the gateway database synchronization has 
been slower and sporadic, and some gateways were not updated for days at a 
time.  When this happens, callsign routing will fail to work for folks who have 
"roamed" to a different gateway.  Slash routing to a gateway band module 
(UR=/KE5RCSA)and dplus gateway linking still work so long as a gateway has not 
changed its IP address.

> The "fix" Icom put in for large groups of repeaters is the Multicast
route.
> This requires some pre-setup by the Gateway operators, but
also
> works well, from what I've heard.

Multicast must be statically set up in advance by each gateway sysop and works 
poorly when more than a just a few gateways are involved.  Each involved 
gateway has to send a DV stream to each other involved gateway.  That it is not 
used more is confirmation that it does not work well.  Oh, and you cannot call 
sign route to join in a multicast QSO.

73 -- John

[DSTAR_DIGITAL] Re: Please help in contact from Trust-Server-Admin

[john_ke5c]

Dear Piotr and Andy,

Hi! Thank you for DStar in Poland!

To join DStar trust server net now you must have only ICOM DStar equipment.  
DStar Hotspot can not yet join trust server net.

Good luck and very best 73, John

> Or someone can from group contact has with persons Trust-Server-Admin ?

[DSTAR_DIGITAL] Re: People Locator

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "Nate Duehr"  wrote:
>
> I'm surprised no one's asked DStarUsers.org to take that data down,
> honestly.  Someone who really values their privacy will eventually.
> 
> 2. People will ask that some web page they have no relationship with
> stop publishing when they're on the air to anyone who wants to see it.
> 

In the USA at least, amateur radio communications are not private:

ELECTRONIC COMMUNICATIONS PRIVACY ACT
UNITED STATES CODE
TITLE 18.  CRIMES AND CRIMINAL PROCEDURE
PART I--CRIMES
CHAPTER 119--WIRE AND ELECTRONIC COMMUNICATIONS INTERCEPTION AND
INTERCEPTION OF ORAL COMMUNICATIONS
(g) It shall not be unlawful under this chapter or chapter 121
of this title for any person - (...)
  (ii) to intercept any radio communication which is
transmitted - (...)
   (III) by a station operating on an authorized
frequency  within  the bands allocated to the  amateur,  citizens
band, or general mobile radio services;  or (...)

73 -- John

[DSTAR_DIGITAL] Re: People Locator

[john_ke5c]

> I agree totally, I opt out of the DGPS because my boss (or anyone) could 
> track me, if they knew how.
> 
> Maybe we should have a D-Star only users list, then only users can see other 
> users?  That way, only we can see our fellow users.  (Logged and therefore 
> traceable.)

Amateur radio is not private.  Records of your transmissions are not private.  
Folks who cannot accept this should not participate (or at least transmit) in 
the amateur radio service.  Note that word - service - the complete purpose of 
amateur radio is provide a service to the public, not to satisfy any personal 
wants.  Enough!

73 -- John

[DSTAR_DIGITAL] Re: Easy way to reply to CQ from Japanese station.

[john_ke5c]

I don't believe one touch could program your radio to talk back to a JA via the 
interconnect between the international and JA gateway (via his local 
repeater/gateway module).  Are you sure he wasn't on a reflecter 
(dstarusers.org showed he dongled into 1C I believe) to which your local 
repeater/gateway module was linked?  BTW, in that case you can just transmit 
with anything in the UR and he will hear you.

-:)

73 -- John

--- In dstar_digital@yahoogroups.com, "Steve Bosshard"  wrote:
>
> JF1TEU, Kawa called while I was mobile this afternoon - RX > CS worked just 
> fine.  I understand that Kawa and another JA station accidentally discovered 
> one touch would work on the US side, and not the reverse.  Works for me,  73, 
> Steve NU5D
> 
> --- In dstar_digital@yahoogroups.com, DALE   BLANCHARD 
>  wrote:
> >
> > Best solution I have seen yet. 
> >
>

[DSTAR_DIGITAL] Re: Easy way to reply to CQ from Japanese station.

[john_ke5c]

There's been some chatter about this, and many of us old-timers have posted 
that it shouldn't work but enough folks have posted it does that it makes me 
wonder.  

I don't remember for sure, but when the JA gateways first appeared in the 
database, I'm pretty sure individual JA users did not, but now they do, many 
with JA area and zone callsigns.  Thus one possibility is that this info has 
somehow been dumped into the international gateway db and thus provides 
one-touch callsign routing information to get dv streams from us to them.  

At least two of the j-landers claimed to have been worked with one-touch 
replying are currently homed to wb4hro.  A second possibility then is that the 
wb4hro gateway (custom?) software (or dplus on that machine) is somehow 
providing a "worm-hole" to j-land.  I can't think of why else they would be 
homed there.

73 -- John

--- In dstar_digital@yahoogroups.com, "n0so"  wrote:
>
> I had a nice QSO with JA7NJN (Yoh) while mobile one day last week. The 
> "One-Touch Reply" (R>CS) on my 2820 worked OK for me.  
> 
> Yoh has instructions on his QRZ web page for replying to Japan stations. They 
> include the "One-Touch"  method.
> 
> Give it a try!
> 
> 73,
> Mike, N0SO
> 
> --- In dstar_digital@yahoogroups.com, "Y.Kawabe"  wrote:
> >
> > We found out gBest and Easy Wayh to reply from U.S. and EU, when you 
> > received "CQ" Call from Japan via D-Star Gateway.
> > Just push "One-Touch Reply" button of your transceiver and capture the call 
> > sign
> > Ex.
> > 2820 push  [R>CS]
> > 91AD push [RX-CS]
> > However, this is an effective method only to the answer of the station in 
> > the U.S. and EU to Japan. Please try once.
> > 73 de JF1TEU
> >
>

[DSTAR_DIGITAL] Re: Server Req for ID-RP2C and ID-RP4000V?

[john_ke5c]

> Several options including the MikroTik routers 
> (http://www.roc-noc.com/home.php?cat=4)

MikroTip is huge overcapacity and overcomplexity for your needs.  See 
http://www.k5tit.org/forums/index.php?topic=47.15 and there some other threads 
I'll get to you later.  Ebay is good source for older Linksys routers that will 
work with dd-wrt firmware.  There are lots of posts in these forums if you just 
search for routers.

73 -- John

[DSTAR_DIGITAL] Re: Server Req for ID-RP2C and ID-RP4000V?

[john_ke5c]

> > I have a WRT52GS (Firmware Version: v4.71.1, 

I don't believe Linksys made a WRT52GS. You probably have a WRT54GS.

> As for the WRT52GS device:  will it allow you to 
> set the net mask on the trusted side to /8?
> That is: 255.0.0.0
> 
> A lot of the inexpensive home/consumer firewall
> routers don't (properly) support the 10.0.0.0/8
> network you need on the trusted ports.

I doubt Hyperwrt supports this, but it's possible.  However, the dd-wrt 
firmware does and that is what almost all of us using Linksys routers on our 
gateways have loaded.  Since you were familiar with Hyperwrt, you may already 
be familiar with dd-wrt.  How you load dd-wrt on a WRT54GS depends on the 
HARDWARE version (check the bottom label).  Click on WRT54GS in the list at the 
top of the http://www.dd-wrt.com/wiki/index.php/Supported_Devices page.  You 
only need the "mini" version to run the ICOM gateway, not the "full" or any 
other variants.

73 -- John

[DSTAR_DIGITAL] Re: Easy way to reply to CQ from Japanese station.

[john_ke5c]

> Today, 13:12 -, Steve Bosshard wrote:
> 
> >Toshi is registered in the GW system showing JP1YIQA as his area 
> >repeater.
> 
> Possibly in Japan, but not here:
> 
>[...@dstar_gw ~]$ /dstar/tools/dstarripls | grep JF1CXH
>[JF1CXH  ] [WB4HRO  ] [10.220.193.144]
>[...@dstar_gw ~]$ /dstar/tools/dstarmngls | grep JF1CXH
>[JF1CXH  ] [WB4HRO A] [10.220.193.144]

You are both correct - it depends on when you look at the database.  I deleted 
the earlier file because I changed my query to look at more J-land stations, 
but I've been taking a snapshot of their registration every five minutes trying 
to figure this out.  Here's a later glimpse of another J-lander showing this 
phenomena:

 JA7NJN| 2009-01-20 18:08:45 | 2009-04-09 14:13:46.691649 | 2009-04-09 
14:13:46.691649 | ja7njn  | JP1YJR A  | JP1YJR| JA7NJN   | WB4HRO   
| 10.64.208.200  | f

For about 35 minutes (7 snapshots five minutes apart) he was registered this 
morning on JP1YJR A in our database.  Before and after (and now) he was 
registered to WB4HRO A.  

73 -- John

[DSTAR_DIGITAL] Re: Easy way to reply to CQ from Japanese station.

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "Y.Kawabe"  wrote:
>
> We found out gBest and Easy Wayh to reply from U.S. and EU, when you 
> received "CQ" Call from Japan via D-Star Gateway.
> Just push "One-Touch Reply" button of your transceiver and capture the call 
> sign
> Ex.
> 2820 push  [R>CS]
> 91AD push [RX-CS]
> However, this is an effective method only to the answer of the station in the 
> U.S. and EU to Japan. Please try once.
> 73 de JF1TEU

This is a more detailed explanation of what Nate posted in a few lines.  We 
don't know what they are doing in J-land to get their DV streams pointed at our 
gateways since we know nothing about their gateway system, but Pierre 
Thibaudeau explains how NU5D's RF observations and my database observations fit 
together with G2 on this end.  I have been grabbing snapshots of the sync_mng 
table every five minutes.  Here's an example of what's happening:

 target_cs |last_mod_time|  mod_date  |  
reg_date  | pc_hostname | arearp_cs | zonerp_cs | user_cs  | 
regist_rp_cs |   pc_ipaddr| del_flg

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 22:27:29.602372 | 2009-04-09 
22:27:29.602372 | jf1cxh  | WB4HRO A  | WB4HRO| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 22:27:29.602372 | 2009-04-09 
22:27:29.602372 | jf1cxh  | JP1YJX A  | JP1YJX| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 22:27:29.602372 | 2009-04-09 
22:27:29.602372 | jf1cxh  | JP1YJX A  | JP1YJX| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 22:27:29.602372 | 2009-04-09 
22:27:29.602372 | jf1cxh  | JP1YJX A  | JP1YJX| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 22:27:29.602372 | 2009-04-09 
22:27:29.602372 | jf1cxh  | JP1YJX A  | JP1YJX| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

 JF1CXH| 2009-01-31 14:17:32 | 2009-04-09 23:07:51.048988 | 2009-04-09 
23:07:51.048988 | jf1cxh  | WB4HRO A  | WB4HRO| JF1CXH   | WB4HRO   
| 10.220.193.144 | f

Follow reg_date (date time) and arearp_cs.  Remember USROOT refreshes this 
table once or twice an hour.  In the five minutes between the first and second 
observations JF1CXH sent a DV stream to our gateway which immediately updated 
the sync_mng table based on the callsigns in his header - this is a feature of 
G2 - an immediate update to the gateway receiving a DV stream so that gateway 
will know how to route a reply back.  In the five minutes between the last two 
observations USROOT refreshed the table and put JF1CXH back to the WB4HRO A 
module because that's where USROOT has him at.  Here's Pierre's detailed 
explanation:

"When they call your repeater, your gateway's database gets updated on the 
spot. But unlike when you hit the PTT on your repeater, USROOT's database is 
not updated. Eventually, USROOT pushes back to all gateways (including your 
own) a fresh copy of the database in which JF1CXH is still known to be on 
WB4HRO A (the default for having registered on WB4HRO) because JP1YJX did not 
update to USROOT. Your gateway will update USROOT only for callsign heard 
locally, not for anything coming from another gateway (it is assumed that the 
other gateway will have done it already).

On the other hand, your gateway knows me on VE2RIO A. If I relocate to Quebec 
City and call you from there, your gateway will immediately get my new 
location, say VE2RMF C. But at the same time VE2RMF will inform USROOT of my 
now current location which will eventually be pushed to all gateways that are 
synchronizing there. From that point on all gateways will know I'm there, until 
I relocate again."

Thus, when a J-lander calls one of our G2 gateways, our gateway will know how 
to callsign (aka one-touch) route back to the J-lander until USROOT "updates" 
our database.  In the example above, this was between 20 and 25 minutes.

73 -- John (and Pierre and Steve)

 

[DSTAR_DIGITAL] Re: Easy way to reply to CQ from Japanese station.

[john_ke5c]

> -The  One-Touch reply works only for those JA stations who are populated
> in one of G2 gateways (this is his/her default gateway).  Most likely
> those JA stations got registered to use DVDongles.

Kay shares a key point - this only works for 20 or so of the J-Landers:

 target_cs | arearp_cs | zonerp_cs | user_cs  | regist_rp_cs 
---+---+---+--+--
 JA1ALE| WB4HRO A  | WB4HRO| JA1ALE   | WB4HRO  
 JA1DDF| WB4HRO A  | WB4HRO| JA1DDF   | WB4HRO  
 JA1QML| WB4HRO A  | WB4HRO| JA1QML   | WB4HRO  
 JA1YEM| WB4HRO A  | WB4HRO| JA1YEM   | WB4HRO  
 JA3PTR| WB4HRO A  | WB4HRO| JA3PTR   | WB4HRO  
 JA4NYY| WB4HRO A  | WB4HRO| JA4NYY   | WB4HRO  
 JA7NJN| WB4HRO A  | WB4HRO| JA7NJN   | WB4HRO  
 JF1CXH| WB4HRO A  | WB4HRO| JF1CXH   | WB4HRO  
 JF1TEU| WB4HRO A  | WB4HRO| JF1TEU   | WB4HRO  
 JH0MRP| WB4HRO A  | WB4HRO| JH0MRP   | WB4HRO  
 JI1BQW| W4AES  A  | W4AES | JI1BQW   | W4AES   
 JI1OBJ| WB4HRO A  | WB4HRO| JI1OBJ   | WB4HRO  
 JK1PBD| WB4HRO A  | WB4HRO| JK1PBD   | WB4HRO  
 JK1UVL| WB4HRO A  | WB4HRO| JK1UVL   | WB4HRO  
 JL1EEE| WB4HRO A  | WB4HRO| JL1EEE   | WB4HRO  
 JL7HHS| WB4HRO A  | WB4HRO| JL7HHS   | WB4HRO  
 JM3GWE| WB4HRO A  | WB4HRO| JM3GWE   | WB4HRO  
 JO3QJH| DB0WZ  C  | DB0WZ | JO3QJH   | DB0WZB  
 JO3QJI| DB0NG  B  | DB0NG | JO3QJI   | DB0WZB  
 JR1BFJ| WB4HRO A  | WB4HRO| JR1BFJ   | WB4HRO  
(20 rows)

73 -- John

[DSTAR_DIGITAL] Re: Dplus One Way Linking ?

[john_ke5c]

remote gateway 189.20.214.220:20001  call PY2KCA C status Linked to C

Works for me to link KE5RCS to his gateway (non-existant band module but still 
demonstrates all is well).  It's either how he has his radio set or his 
dplus.conf.  Ask him for both of those.

73 -- John 

-- In dstar_digital@yahoogroups.com, "Steve Bosshard"  wrote:
>
> I have been talking with Joao, PY2JF in Americana Brazil concerning PY2KCA 
> port C.  I am able to link to UR=PY2KCACL without any trouble.  Joao gets 
> "System is Currently Busy" when he tries to Dplus Link from Brazil to the 
> rest of the world.  Any ideas or suggestions ?
> 
> 73, Steve NU5D
>

[DSTAR_DIGITAL] Re: the I command

[john_ke5c]

--- In dstar_digital@yahoogroups.com, Nate Duehr  wrote:
>
> The gateway admin records it with a DVDongle and can make it audio or  
> not, and can also set a text message.  We don't have one here locally  
> because without a Dongle, I can't record one for W0CDS. I assume many  
> systems have a similar problem and the "I" command does nothing.

Record it off the air with the echo command and rename it.

73 -- John

RES: [DSTAR_DIGITAL] Re: Dplus One Way Linking ?

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "Joao Roberto S. G. Ferreira"  
wrote:
>
> I don't think so, I tried to link to K5TIT and I'm setting up like this:
> 
> UR: K5TIT CL
> RPT1: PY2KCA C
> RPT2: PY2KCA G
> MY: PY2JF

Looks correct.  I link KE5RCS to K5TIT (and to PY2KCA), so K5TIT is working. 
Try to link to KE5RCS C so I can see dplus log this end, please.

> remote gw/ref K5TIT  C link response timeout
> 
> Looks like I don't get answer from the remote gateway. 

Yes, but why?  Either your packets don't get to K5TIT, or K5TIT packets don't 
get back to you.  Check ports 20001 through 20005 UDP open.  Check you are not 
blocking them in iptables.  Then wait for Robin to help.

73 -- John

[DSTAR_DIGITAL] Re: Dplus One Way Linking ?

[john_ke5c]

> If operator error, what UR= , RPT1, RPT2, MY combination would or could cause 
> "System is currently busy" voice message ?

I think that is a generic error message, and MYCALL not in database would if 
dplus.conf set the default way to "allowreguserlinkingonly".

73 -- John

[DSTAR_DIGITAL] Re: Dplus One Way Linking ?

[john_ke5c]

> there is already a broken terminal entry without a module identifier. You 
> should delete this first, and then use it as mentioned in my last mail.

This is not a problem.  There is such an entry for K5CTX which I entered for 
testing, and everything still works fine.

> I think the problem is with the non existing terminals for PY2KCA.

That's a good pickup, and that will certainly affect G2 operations (callsign 
routing), but I don't think that will affect dplus linking.  So far as I know, 
and Robin can jump in here anytime, dplus is driven by sync_gip for linking IP 
addresses, not sync_mng.  I can link W5HAT^^A to W5LM^^^A and neither have A 
terminals defined.  But, we'll see.

73 -- John

[DSTAR_DIGITAL] Re: the I command

[john_ke5c]

> Ahh, I get it.  I thought "echo command" was going to be in reference to 
> something that had to be run at the command line.
> 
> You're saying to transmit a signal to the "E" command via RF, and then 
> use a sneaky way to get a file by copying out the temp file it uses to 
> do the echo, into the ID filename.

Why would that be a sneaky way?  It seems to me to be an easier way than using 
a dongle.  I have a dongle, but usually find it easier to use the dplus echo 
feature.  Using the dongle then requires FTP'ing the dvtool file up to the 
server.  If you use the dplus echo feature, all you need to do is rename it.

73 -- John

[DSTAR_DIGITAL] Re: Icom ID-1 Control Issue

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "David"  wrote:
>
> The ID-1 software will not presently run on Vista 64 (to my knowledge)due to 
> the 64 bit driver not being signed.  Does anyone know if it is possible to 
> control the ID-1 via the Ethernet port.  If so, how is that accomplished?


See

http://www.laptopvideo2go.com/forum/lofiversion/index.php/t18585.html

for a work-around to unsigned drivers.

73 -- John

[DSTAR_DIGITAL] Re: DPlus Dashboard Question

[john_ke5c]

The javAPRSSrvr part of dstarmon is not running.  If it were, you would see 
process numbers for APRS.  See two messages in the Gateway group that just 
covered this:

http://groups.yahoo.com/group/DStar-Gateway/message/2785

http://groups.yahoo.com/group/DStar-Gateway/message/2783

73 -- John

--- In dstar_digital@yahoogroups.com, "Jeff Thomas"  wrote:
>
> I installed a new D-Star Controller and UHF Module with Gateway. I am having 
> the following problems:
> 
> Users are not showing up in the DPlus Dashboard.
> 
> Gateway does not show up in DVTool for DVDongle users.
> 
> I followed the "Joining the Network" guide on dstarusers.org for installation.
> 
> Gateway is reporting the following status:
> 
> dsipsvd (root:23730) dsgwd (root:23699) 
> postgres (postgres:23613) httpd (root:23639) 
> java (root:2622) dplus (root:23433) 
> named (named:2269) 
> DSM ok (DSM= 2622 APRS=none running) 
> Mem: 915MB Free, 2019MB Total
> GW_VER=2.1 
> 
> Any help is appreciated.
> 
> Jeff, K7WIN
> D-Star Repeater: KF7BTZ
>

[DSTAR_DIGITAL] Re: UPDATE on Group Order buyings

[john_ke5c]

> All my stuff is sold as complete kits, indeed.  No more wild shopping.

Fred, have you published any ordering information?

73 -- John

880 vs 800 (was: Re: [DSTAR_DIGITAL] Signal Distance)

[john_ke5c]

> I don't like the idea of filtering "bogus" callsigns.  What might be
> "bogus" to you, might be my special event's tactical callsigns. 
> (There's nothing stopping anyone from registering "SAG1, SAG1, NET,
> EVENT", etc.)

I don't care if this is politically incorrect or insensitive, but if you want 
"tactical" this, that and the other, just join your local police force or the 
marines.  You can probably even get tactical underwear there.  If you want to 
operate on the amateur bands and modes, use an amateur callsign.  10-4?

73 -- John

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

[john_ke5c]

> Source routing to an individual callsign (native D-STAR) has its purpose 
> as well.  If the station (callsign) that I want to talk to is attached 
> to a traveler, say a long haul truck driver or a road warrior, then 
> simply calling the station using callsign routing makes more sense.  

Callsign routing to a long haul truck driver who is in range of a DStar 
repeater say 5% of the time, and whose whereabouts even then would be known 
only if he remembered to key up?  Without dplus and reflectors, DStar would be 
on its way to join HF digital.  I agree 100% with Ed.

73 -- John

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

[john_ke5c]

> > Callsign routing to a long haul truck driver who is in range of a DStar 
> > repeater say 5% of the time, and whose whereabouts even then would be known 
> > only if he remembered to key up? 
> 
> Well, that is like making the argument that there shouldn't be defibrillators 
> on airplanes because they only are useful 0.1% of the time when a 
> passenger has a heart attack.

I'm glad you agree: defibrillators are as useful to the average airline 
passenger as callsign routing is to the average DStar radio user.  

73 -- John

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

[john_ke5c]

> 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

[DSTAR_DIGITAL] Re: CROSSPOST: Response to call for FCC action. [United States]

[john_ke5c]

> Remember ... don't feed the trolls.

I would EMPASIZE this approach.

Although pre-DStar, QST had a nice article on VOIP and amateur radio including 
comments by the ARRL general counsel:

"Many callers to the ARRL's Regulatory Information Branch over the last few 
years have focused on the novelty of the Internet when asking questions about 
the legal uses of certain systems. Such focus is misdirected. Part 97 does not 
regulate systems; it regulates stations. The Commission doesn't care what a ham 
has feeding his or her station; it cares that the station—not the Internet, but 
the station— is properly operated. And all the rules that apply to any Amateur 
Radio station apply to one that retransmits audio fed to it by VoIP."

http://www.arrl.org/qst/2003/02/VoIP.pdf

73 -- John

[DSTAR_DIGITAL] Re: programming

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "woody"  wrote:
>
> I'm new at this programming of this radio..Kinda need some help. Will i
> got the local repeaters working just great. but when it comes to getting
> thought the gateway and talking to other people seem to be a problem.
> Not sure what i might be going wrong. Very much need some helpthanks

Woody, you are not "regisered" on the gateway system so far as I can tell.  In 
order to use callsign routing to talk to folks on other gateways, you need to 
be registered.  The easiest way is to go through your local users group for 
your local machine.  Sometimes gateways are "linked" with a piece of software 
which is an extension or add on to the ICOM gateway software, and you can talk 
to/on a second gateway or reflector if your local gateway is operating in that 
mode.  There are some guides on all this, and I'm sure someone will post one or 
two of those, but I've got to run for bit. Welcome and 73, John

[DSTAR_DIGITAL] Full Sync!

[john_ke5c]

On the way to work this morning, I listened to Craig, KV5E, report that his QSO 
mate's signal was "full sync".  That ought to be the DStar "full quieting" or 
"5 by 9" or "599".

73 -- John

[DSTAR_DIGITAL] Re: Using the DD

[john_ke5c]

> The best place to start is with your repeater owner/gateway 
> administrator.  The gateway may not be configured for general Internet 
> access.

We didn't have to do anything specific to allow general internet browsing via 
DD when we set up the gateway.  If named is broken on the gateway you might 
have a problem, and lately some folks have registered with terminal pcname's 
ending with a hyphen which breaks named.  I think those have been cleaned up 
though.  DV continues to work without named working properly, btw.

> > I have configured the PC to talk to the ID-1 and the ID-1 is "talking" 
> > to the repeater BUT I don't get to the Internet.
> > If I switch to the DV repeater all is well.
> > Where do I start?

Did you follow the instructions on pages 65-66 of your ID-1 manual EXACTLY?

73 -- John

[DSTAR_DIGITAL] Re: Using the DD

[john_ke5c]

> Some administrators may block Internet access.  Talking to the 
> administrator of the local system will provide the local system knowledge.

As an admin, I'm just curious how that could be done, block general internet 
browsing via DD but not block DD "QSO" gateway routing?

73 -- John

[DSTAR_DIGITAL] Re: more DV / FM questions

[john_ke5c]

> As far as I can see or know, Andy's repeater doesn't buffer or 'hold' any 
> data, it is purely passed directly and almost instantaneously into the TX 
> from the RX, after the comparator circuit that helps smooth off the 0's and 
> 1's.

Andy then is almost certainly transmitting "plain" FM, not GMSK-FM.  This will 
work RF-wise moderatly well and is what NU5D did before he had an ICOM stack.  
The bandwidth will be somewhat greater, and the S/N performance worse, but the 
FEC will overcome some of this.  Practically, I think the communciation range 
is nearly the same and the main difference will be bandwidth.  NU5D should have 
done a side-by-side spectral comparison of his "FM DStar repeater" and the ICOM 
stack, but I don't think he ever had both going at the same time since he used 
the same duplexer and antennas.  The ICOM stack may also not have the best 
designed GMSK modulation possible, so it may not be representative of GMSK 
performance per se.  I think NU5D's main problem was transmitter key-up delay - 
enough of the sync data had already gone by that the receiving DStar radio had 
trouble locking up.

73 -- John

[DSTAR_DIGITAL] The Future of USA Emcomm?

[john_ke5c]

http://www.thalesliberty.com/media/briefs/Thales_Multiband_Portable_SDR.pdf

http://www.networkworld.com/community/node/43196

Get your loaner: http://www.thalesliberty.com/demo_request.asp

Goodbye DStar Emcomm?  Goodbye hams?

73 -- John

[DSTAR_DIGITAL] Re: new to the group

[john_ke5c]

> Only you can really answer your question, but let me pose a question for 
> you to think about.  What if you deployed to a major incident (like 
> Katrina) in an area where D-STAR has been deployed heavily for Emergency 
> Communications, would you want your options for support limited by not 
> having D-STAR in your bag of tricks?

What's the DStar network backup plan for major incidents like Katrina when the 
internet (fiber, cable, microwave) lose power, get flooded, etc.?  What keeps 
the backbone going for your bag of tricks to keep working?

73 -- John

[DSTAR_DIGITAL] Re: new to the group

[john_ke5c]

> D-STAR works with or without Internet. The Internet enables gateways.

So does FM.
   
> During Katrina there was Internet connectivity available through a  
> couple of ISP NOCs (even though the building was flooded).  If  

I can't find any data or verification of that claim; am I searching 
incorrectly?  For all of New Orleans and surrounding parishes?  I did find a 
report on the general disruption of internet infrastructure by Renesys: 
"Recovery efforts continue, but obviously, with a significant portion of the 
city of New Orleans under water and without reliable power or transportation, 
many Louisiana-based outages will not be fixed for the foreseeable future. ... 
Many networks in the affected region, especially those in Louisiana, have been 
unreachable for a prolonged period of time. These networks may not see service 
restored for some time to come, unless they can be brought back online at 
disaster recovery sites outside of the region."

> Shoot, with that thinking I shouldn't bother having a car because  
> bridges will probably go out during a major earthquake in my area.  

Yes, I think it would be pretty dumb to expect your car to be of any use during 
a major earthquake in your area.  If your goal is to have some form of 
transportation in that emergency, get a bicycle.  I think it would be equally 
dumb to build an emergency communciation system that depended on the internet.  
If your goal is to have emergency communications in that emergency, get an FM 
(or better yet, HF) radio and a generator - I'm pretty sure that's what they 
used during Katrina...

> Hams can improvise under conditions that would bring public safety  
> radio folks to their knees.  You put a hotspot somewhere that has  
> Internet connectivity (these events rarely take out every possible  
> avenue to the Internet) et voila you are back on the D-STAR network.

There are a lot of claims and promises for DStar as an Emcomm solution but no 
real world success stories.  Time will tell, but I'd take an a mutli-mode 
HF/VHF rig like the FT-857D if I could have only one rig for an emergency...

73 -- John

[DSTAR_DIGITAL] Re: new to the group

[john_ke5c]

> scheme? If not, how hard would it be to change? It would seem that Satoshi's
> D-Star adapter could be fairly easily modified to work with these radios,
> with the control interface using the RS-232 connection.

There's a real mess over in that group with Satoshi having basically abandoning 
his prior project (and customers) and now apparantly planning to offer a new 
board where he will supply a proprietary software.  Upgrades will have a cost, 
etc.  Hopefully others will come up with a similar solution.  Some say they 
are, so we can hope.  Check it out - http://groups.yahoo.com/group/gmsk_dv_node/

73 -- John

[DSTAR_DIGITAL] Re: new to the group

[john_ke5c]

> > I can't find any data or verification of that claim; am I searching 
> > incorrectly?  For all of New Orleans and surrounding parishes?  
> 
> "In New Orleans, two major tech firms have managed to keep up and running 
> from the upper floors of a skyscraper though supplies of diesel fuel for 
> their generator are limited. Again as reported by Wired, New Orleans ISP and 
> web hosting firm Zipa and a related firm, DirectNIC remained online 
> throughout the hurricane and still continue to provide hosting services. 
> Their Internet connection, a fiber line buried ten stories below the city, 
> survived the disaster intact." 

Thanks, but I thought you meant DStar gateways kept working.  While a report of 
two (of how many?) ISP's that kept working until the diesel ran out is 
interesting, useful data would be statistics on how many internet end 
customers, such as DStar gateways, maintained a working route to a working ISP. 
 From the looks of the water and known power failures, I think that percentage 
very low.  However, if you were lucky enough to have your DStar repeater on top 
of the building where those two ISP's were housed, had power to any 
intermediate switches along your route, and had your own generator (since it's 
unlikely you would have been on their power), you would have been okay at least 
for a while.

73 -- John

[DSTAR_DIGITAL] Re: new to the group

[john_ke5c]

> >repeater would, PLUS. The PLUS is the ability to send slow speed data and
> >voice over the same links, even at the same time. So it actually combines

> both the low speed data services (for text, imaging, small file 

Other than occasional unidirectional (please don't beacon) GPS reports, DStar 
DV slow speed data at what, 900 baud or so, is about as useful as smoke and 
mirrors for any practical data transfer purpose, Emcomm or otherwise (DRats is 
interesting, not useful).  Moreover, you cannot transmit slow speed data and 
voice simultaneously (except for GPS and your 20 character pre-programmed text 
message).  DD data might be useful (are there any existing Emcomm software 
apps?), but how many of you have ID-1's?  Let's be objective here...

73 -- John

[DSTAR_DIGITAL] Re: RP2D

[john_ke5c]

> One more question then I will stop! Does anyone know if the RP2D can operate 
> on its own without the need for a controller? 

:(

Manual, page 1:

"The ID-RP2D never functions as a repeater without IDRP2C, due to no relay 
function is built-in."

73 -- John

[DSTAR_DIGITAL] Re: Technical Repeater Question

[john_ke5c]

> Hello from the WU5PIG DStar repeater system where we have a strange issue.  
> When attempting to link our system to a reflector using a radio we get an 
> error message, "DStar system currently busy."  

You will get that message if:

1) RF linking is not allowed
2) Admin only linking and your call is not in the admin list
3) Reflector is down
4) You have a (router) port forwarding problem
5) Dplus has gotten lost
6) Linux has gotten lost (the network/port manager)
7) and probably some other reasons

We have had this happen where only rebooting Centos fixes it, that is, where 
restarting dplus is not enough.

73 -- John

[DSTAR_DIGITAL] Re: more questions

[john_ke5c]

> You can talk to another station via the -gateway- as that system fully 
> buffers each Ethernet packet before determining routing.  While this can make 
> it appear that the RP2D is repeating, it is actually the gateway that is 
> routing the Ethernet packets back to the same RF channel.  Remember that this 
> is a very slow, half-duplex operation that becomes very susceptable to 
> collisions when used this way.

Ahhh, used this way to move data via the local RP2D/RP2C/G2, essentially a "DD 
digipeater" with the problems of 144.390 MHz, but probably without any 
collision reduction algorithm a la p-persistence?

73 -- John

[DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today.

[john_ke5c]

--- In dstar_digital@yahoogroups.com, "ham44865"  wrote:
> dstar_gwy_srv can be used on any DSTAR ICOM system,
> Europe,US, Japan,...
> 
> It is idependent of any "backbone",if there is such a word
> backbone when it comes to dstar.
> 
> I believe you mean dstar TRUST groups, not "backbone".

Is your software accepted by ICOM for use on their (and our) backbone?

But I have to agree with Aro, it wasn't the "first".

73 -- John

[DSTAR_DIGITAL] Re: D-STAR Contest Announcement

[john_ke5c]

> Below is the latest announcement. I am excited as WriteLog is the only 
> contesting software package that will support the D-STAR Contest as 
> outlined on the ICOM Japan website.

I don't know if I'll do anything in this contest - I am a contester but this is 
not what most of us would consider as a contest.  Anyway, you don't need to 
purchase WriteLog.  You can use any logging program with a "generic QSO" type 
of contest, generate a Cabrillo file from your log, edit the contest name in 
the Cabrillo log, then submit it.  That is the whole idea of Cabrillo - you 
just submit your log in that format and the contest manager dupes and verifies 
your log (log checking against other logs submitted), then calculates your 
score.

I'm starting to use http://www.n1mm.com/ more, and the VHFDX contest under 
General Contest Logging will work, just leave the GRID field blank in your log. 
 N1MM is FREE.  After the contest, generate a Cabrillo log, edit the header, 
and you are done.

The rules say nothing about (not) using "spotting nets", so looking for 
possible QSO's on www.dstarusers.org should be fine.   I haven't been there in 
a while - are the JA's running dstarmon yet?  That would really help in this 
event, to see which JA is on which gateway.  I think you will want to have the 
JA (and as many other) gateways as possible programmed in your radio so you can 
make slash routed calls quickly rather than having to constantly program 
gateways on the fly.  Again, what a shame that each DStar radio has a different 
computer interface so that you can't control them and program them on the fly 
with one program.  

More later perhaps, 73 -- John

[DSTAR_DIGITAL] Re: World Wide Dstar Contest Rules URL

[john_ke5c]

> http://www.icom.co.jp/world/d-contest/

Another aspect to consider is most contests are 4 hours to 48 hours and thus 
concentrate the contestants within a time frame where a number of other 
contestants are likely to be on.  This is a one week contest, and there may not 
be a whole lot of participants (at least outside of JA land), so it will be 
easy to get frustrated calling CQ - and you may annoy some folks a la other 
contests.  Hence, maybe we should try to pick some times within the week where 
interested folks would make an effort to call CQ or listen?

One thought would be to concentrate efforts starting on the hour.  Another 
thought would be to do the above but only on certain hours, especially during 
the week when activity will be lowest, perhaps even hours or odd hours or every 
third hour - , 0300, 0600, etc.

So for the sake of argument (we love to do that here), I propose that if we 
plan to work this contest for a while, we try to start calling CQ on every 
third hour - , 0300, 0600, etc.  Don't forget to spend some time listening 
too...

Too complicated? Not worth the planning?

73 -- John

[DSTAR_DIGITAL] DStar contest: calling Japan

[john_ke5c]

I found a use for G2 multicast groups!  Contest participation is a bit sparse, 
probably because DStar is still a bit sparse, but I tired of calling JA 
repeater modules one by one, so I defined eight multicast groups of five or six 
JA modules on K5CTX.  I used the list of repeaters (the checked ones - those 
with gateways) from "QSO with Japan via D-Star Gateway-1.pdf" here in the files 
section.  If you decide to do this, here are the groups. Once defined, set 
UR=/J1A to multicast to call on each of the gateways in that group, etc.

J1A = JP1YIQA, JP1YJQA, JP1YJVA, JP1YJRA, JP1YIKA
J1B = JP1YJQB, JP1YJVB, JP1YJXB, JP2YGIB, JP3YHHB, JP8YDZB
J2A = JP1YFYA, JP1YJXA, JP2YGIA, JP2YGEA, JP3YHHA
J2B = JP3YHJB, JR3VK B, JP4YDUB, JP5YCOB, JP6YHLB, JP7YELB
J3A = JP3YHJA, JP3YHNA, JP3YCVA, JR3VK A, JP3YHVA
J4A = JR3WZ A, JP4YDUA, JP5YCNA, JP5YCOA, JP6YHLA
J5A = JP6YHNA, JR6YZ A, JP7YELA, JP7YEMA, JP8YDZA
J6A = JP8YEAA, JP8YEBA, JP8YECA, JP9YEGA, JP0YDPA, JP0YDRA

I picked five or six in a group because multicast bogs down on our gateway with 
any more in a group, plus I didn't want to hit too many gateways at once.

When I talked with N5MIJ last night, he had made 18 contacts.  I got off to a 
slow start plagued by local "technical issues", but I've finally worked 18 now. 
 Eleven were JA's.  One op said this was his first international QSO as he had 
just learned how to program his radio!

CQ CONTEST!

73, John

[DSTAR_DIGITAL] ICOM next year clarify your contest rules

[john_ke5c]

Rule: "The use of the following technologies cannot be used for contest QSO.  
D-PLUS DV Dongle HotSpot Digital/Analog Gateways DV Adapters"

A station jumped me on a reflector asking me to one-touch him back for a 
contest QSO.  Was the reflector (i.e., dplus) used to make the QSO?  I would 
argue yes because there is no way otherwise that a contest QSO could have 
occured at that time on that frequency (it did not, btw).  An operator making 
QSO's this way rather than by random calling has a significant advantage.  
ICOM, next year please clarify if this rule means no use of those technologies 
in any way, or if it's okay to solicit a QSO just so long as callsign routing 
(one-touch reply) is then used to actually complete the QSO.

73 -- John

[DSTAR_DIGITAL] Re: ICOM next year clarify your contest rules

[john_ke5c]

> A lot of contests do allow QSOs to be arranged by repeaters or other 
> means that are invalid for actual contacts.  As long as the actual 
> QSO was conducted within the rules of the contest.  What if the 
> station called you on IRLP or Echolink and said "Do you have D-STAR?" 
> "yes I do"  "I'm chasing contacts in the D-STAR contest  Route to me 
> at...".  In any case, a bit of clarification would sort this one out.

ICOM's contest rules do not prohibit IRLP, Echolink, the use of dstarusers.org, 
etc., so those aids would seem allowed per the rules.  They do prohibit the use 
of "D-PLUS DV Dongle HotSpot Digital/Analog Gateways DV Adapters", however.  
Some stations are also logging into gateways using dongles and then soliciting 
one-touch QSO's, so this really does need clarification.

As you know, contests almost invariably state whether "assistance" is allowed 
or not, and if there are separate entry categories for assisted and unassisted. 
 Assisted means the use of any aid to facilitate QSO's, typically DX/spotting 
networks of which which dstarusers.org is a form.  Thus, the current ICOM DStar 
contest rules seem to prohibit some but not all forms of assistance.

> I'm a bit more concerned about the use of multicast to make CQ calls, 
> because multicast is an administrator configured feature, which means 
> gateway admins and those who are close to gateway admins have an 
> unfair advantage in this sort of contest.  Not what I would call a 
> level playing field.
> 
> Clever use of multicast?  Definitely!  Fair?  I don't think so, since 
> it's not equally available to all contestants.

I've read the rules several times and can't find the part prohibiting 
multicast.  Maybe ICOM will clarify that too.  It would be a shame for them to 
prohibit their own technology, but who knows.  

BTW, are you actually in the contest or just refereeing?

73 -- John

[DSTAR_DIGITAL] Re: ID1 Software Under Linux with Wine

[john_ke5c]

> I am hoping someone else has been down this or a similar road. I have already 
> checked out the Wine forums. I have an ID1 and I am trying to get the ICOM 
> ID1 control software under Linux. The gui looks great but I can not 
> communicate via the Ubuntu 9.04 X64 system.

When I briefly tried to get the band module programming software to work under 
wine, I found that USB support really does not exist in wine.  The wine Wiki 
basically says that - http://wiki.jswindle.com/index.php/Drivers and scroll 
about half-way down the page.  Please let us know if you find a way to get it 
working.

73 -- John

[DSTAR_DIGITAL] Re: ID1 Software Under Linux with Wine

[john_ke5c]

I stand educated; I didn't know the ID-1 software talked via com port 
interfaces rather than via usb port interfaces.  What I said is true, wine does 
not support usb interfaces, but linux sure does.  Thus Pierre, Antonio, Ed, and 
maybe others have pointed a way to the solution - the ID-1 software talks to 
wine via com port interfaces which are mapped to linux USB serial com ports 
where linux handles the interface.

Let me add that you need to define any com port you intend to use under wine in 
the ~/.wine/dosdevices directory.  If you have physical com ports on your 
computer, you will find existing entries in this directory for those.  To 
complete Pierre's example, you also need to create an entry for com4 in the 
~/.wine/dosdevices directory:

ln -s /dev/ttyS4 com4

This tells wine where to look for com4, /dev/ttyS4 in this case which Pierre 
redefined to be the first USB port, /dev/ttyUSB0.

*** I'm pretty sure I've done this in one step before, all in the dosdevices 
directory.  Try

ln -s /dev/ttyUSB0 com4 (some distros use /dev/usb/ttUSB0...)

Then tell the ID-1 software to use com4.  Don't forget to attend the 
permissions issue also described by Pierre.  I think if you run wine as root, 
you don't have to worry about this, but regular users do not have permission to 
use tty ports in linux for security reasons.

73 -- John

> The ID-1 control software, only knows about "COM:" devices which under 
> linux are the /dev/ttyS On the other hand, the FTDI chips seen by 
> linux as a /dev/ttyUSB... Assuming that you only have one such device 
> connected on your system, it will be /dev/ttyUSB0. What you have to do is 
> to link to some ttyS device. Say you
> 
>   ln -s /dev/ttyUSB0 /dev/ttyS4
> 
> The ID-1 control software will be able to connect to COM5.
> 
> You also need to make sure that you have read/write access to the device. 
> Under most recent distributions, those device will grant R/W access to 
> members of the group "uucp". If needed, you edit /etc/group to be included 
> in that group. Here's how it shows on my system where I have the ID-1 
> control software running on COM5:
> 
>[...@localhost]$ ls -la /dev/ttyUSB0 
>crw-rw 1 root uucp 188, 0 aoû  1 16:12 /dev/ttyUSB0
>[...@localhost]$ ls -la /dev/ttyS4
>lrwxrwxrwx 1 root root 12 jui 27 20:45 /dev/ttyS4 -> /dev/ttyUSB0
>[...@localhost]$ grep uucp /etc/group
>uucp:x:14:uucp,prt
> 
> (Note that under Windows it's exactly the same: USB serial devices are 
> turned into COM ports and it is the COM port number that you actually 
> configure in the ID-1 control software. The only difference is that 
> Windows automatically assign a COM port number for the USB serial 
> interfaces.)
> 
> '73 - Pierre
> __
> 
> Pierre Thibaudeau
> VA2RKA/VA2RKB/VE2RIO/VE2RVR/VE2RQF/VE2RTO/VE2LKL/VE2TXD sysadmin
>