1. main@nw-digital-radio.groups.io
   Date   
Re: Newbie question

"John D. Hays" <john@...>
 

Hi Hutch,

Short answer "no" ...

Longer answer.  

You can use the UDR56K-4 in a few configurations to get on the D-STAR network.

There will be an application that turns the UDR56K-4 into a 70cm D-STAR radio that you can use to talk D-STAR on simplex or through repeaters and half-duplex gateways (hotspots).

There is an application in the G4KLX suite that will need to be adapted to use the AMBE daughter card, but allows you to appear as a user on a virtual repeater talking into the D-STAR network.  (This application already works on the UDR56K-4 using a DVDongle for the AMBE chip).

If you have a D-STAR radio, the UDR56K-4 can act as a half-duplex gateway into the D-STAR network.  A workbench version using an external radio and modem has been running for a couple of months, but will become an application to use the UDR56K-4 built-in radio and modem.

There is no application that puts an analog HT on D-STAR.   Fundamental to D-STAR's digital voice is the need for an AMBE  vocoder to be in the path.  This is contained in the D-STAR HTs and Mobiles from Icom.  The conversion of audio to digital and back happens in this chip.  What goes over the air is the digital signal.  It is possible to adapt some analog FM radios with external hardware and software to use D-STAR DV.  There is also a provision in the protocol to have a special hybrid device at a D-STAR gateway to provide the AMBE encode/decode and interact with analog radios, but it has not been implemented.  I could sketch out how that might be accomplished with a second analog radio and a UDR56K-4, but will leave that for another time.

BTW, I was introduced to Zydeco only about 20 years ago. Love it, and occasionally run across a station on my Internet radio, hoo-wee!!!

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Wed, May 30, 2012 at 7:50 AM, carter_hutchinson <zydecos@...> wrote:
 

I missed this at Dayton. Can I use this with my analog HT and connect to the dstar network, or do I need an Icom dstar HT?
73
K9kjn
Re: Newbie question

"neil_g7eby" <g7eby.neil@...>
 

It may be possible, but it is frowned upon to do so, except on a few dedicated reflectors which have Echolink (analog) connectivity.

Some XRF reflectors do indeed have this and use an 'Analog Bridge' to go from an analog port number to a D-Star reflector.

If you want to do this on a permanent basis, I suggest you ask the FreeStar team or Barry, G8SAU, as they have live reflectors doing this.

However, for a more practical analog to echolink bridge/gateway, I'm sure this radio could be adopted by those interested, when the AMBE board is available.

Neil G7EBY.

--- In UniversalDigitalRadio@yahoogroups.com, "carter_hutchinson" <zydecos@...> wrote:

I missed this at Dayton. Can I use this with my analog HT and connect to the dstar network, or do I need an Icom dstar HT?
73
K9kjn
Newbie question

"carter_hutchinson" <zydecos@...>
 

I missed this at Dayton. Can I use this with my analog HT and connect to the dstar network, or do I need an Icom dstar HT?
73
K9kjn
Re: Screen shots

"John D. Hays" <john@...>
 

Hi John,

We've been thinking about some of these ideas as well.  In the design of the UDR56K-4 we really are shooting for the "sweet spot" between data rate, bandwidth, propagation, and utility.

70cm was chosen as the band because we can run at 56 K bauds and up to 100 Khz of bandwidth (Part 97.307) which is sufficient for many data transfer applications like text email. The band has decent propagation (compared to 33/23 cm) and is less crowded than 2 meters in most areas (especially in the 420-440 segment).  Lower loss cable, connectors, etc. and reasonable gain antennas are easier to work with than at higher frequencies.   A lot of people have said why don't you put it on 2 meters?  Well, we would have to cut back to 19.2 K bauds and the band is too popular with little room for additional modes.

So the main difference between DV and  DD, as far as the bits go, is 1 bit flag in the header and the payload.  So theoretically one could do a 4800 bps DD signal through a DV repeater.  Where it gets tricky is we don't know where in the Icom chain things might fall apart:
  1. Do  the DV radios honor the header flag bit and not try to decode the payload of a DD packet?  If so, then you wouldn't hear anything on a Voice channel when the bit was set.  Also Icom uses its digital coded squelch, which everyone leaves at 00, so would that also help filter out DD?  We'll know more about that when we start generating some 4800 bps DD on a channel.
  2. Does the Icom repeater look for the bit when repeating DV?  If not then local repeater use should be possible on current Icom repeaters.
  3. Does the RP2C require the bit to be set or unset when a port is designated for DV or DD in setup?
  4. Does the RP2C send to different ports on the gateway for DV vs DD data.  We know different ports (UDP 40000,40001) are used for DV and DD going to and from the gateway over the Internet.
  5. What exactly would the Icom G2 gateway do with a signal where the header bit is set opposite of what the module was designated for, e.g. DD on a DV module or DV on a DD module?
So much of this is just a black box on a platform like Icom G2.

Clearly on open source gateway and repeater controller software we could adapt to multiplex DD and DV on the same repeater or half-duplex channel, but we won't know on the Icom stuff until we're able to test. (We do have access to some RP2C / G2 gateway systems for testing.)

One thing about DD is it is callsign addressed, so if the reflector code would only pass DV traffic with CQCQCQ (or the reflector designator) in the UR field, one could multiplex without affecting links or reflectors.

The other concern with very low rate DD is buffering traffic from higher speed systems, e.g. trying to squirt a 56 or 128 K DD packet through a 4800 bps channel should work, but timings for TCP ACK packets, etc. would get a little crazy.

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Sun, May 27, 2012 at 9:27 AM, john_ke5c <ke5c@...> wrote:
 

> In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it.

I too have been wondering about 9600 (or thereabouts) data. We might be able to take advantage of the gateway/internet infrastructure if a "Dd" DStar packet could be defined that would use all bits for just data, no voice. I'm guessing (hoping actually), the band modules and gateways would pass those so long as the headers were okay. Of course, it would sound like garbage to DV radios, but you could commit band modules to data only. dplus might burp, but you would probably callsign route such "data" packets anyway. Just brainstorming,

73--john
Re: API's & Documentation Underway?

"John D. Hays" <john@...>
 

Hi Brian,

There will be APIs.  We are busy in development right now, and will be focusing on getting the radio ready for market.

We encourage development for this device, hence the high use of FOSS (Free Open Source Software) by NorthWest Digital Radio.

Development is pretty straight forward.  The device is running a Debian Squeeze distribution, so the baseline is familiarity with development under Linux.  In house development is done running a cross compilation tool chain on desktop Debian systems (to take advantage of multi-core processors and high memory), either native or as a VM, and the completed builds are transferred to the CPU board for the radio.

What we will provide are APIs to control the radio; frequency, shift, modulation choice, power, and any other similar controls.  We will also provide drivers to send and receive data between the CPU board and radio board,  and between the CPU board and the Vocoder board.

Since the integration is at buss levels, programs will be able to talk to the radio directly over the buss, eliminating some of the bottlenecks of previous implementations.

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Sun, May 27, 2012 at 5:02 PM, Brian Duck <bkduck@...> wrote:
 

So, I'm interested in custom application development for the UDR56K-4.

Are there API's under development or documentation to review?

Thanks for your efforts on what looks to be a great platform.

Brian Duck
W1DUC
bkduck@...
API's & Documentation Underway?

"Brian Duck" <bkduck@...>
 

So, I'm interested in custom application development for the UDR56K-4.

Are there API's under development or documentation to review?

Thanks for your efforts on what looks to be a great platform.

Brian Duck
W1DUC
bkduck@gmail.com
Re: Screen shots

"john_ke5c" <ke5c@...>
 

In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it.
I too have been wondering about 9600 (or thereabouts) data. We might be able to take advantage of the gateway/internet infrastructure if a "Dd" DStar packet could be defined that would use all bits for just data, no voice. I'm guessing (hoping actually), the band modules and gateways would pass those so long as the headers were okay. Of course, it would sound like garbage to DV radios, but you could commit band modules to data only. dplus might burp, but you would probably callsign route such "data" packets anyway. Just brainstorming,

73--john
Re: Screen shots

"ke7kro" <basil@...>
 

--- In UniversalDigitalRadio@yahoogroups.com, "c0j" <jpronans@...> wrote:

--- In UniversalDigitalRadio@yahoogroups.com, "k7udr" <bhhoyer@> wrote:

I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.

Bryan
Hi Bryan, all,

Are you using paclink-unix/LinuxRMS or something else?
Hi John,
Hope you remember me from our posts on paclink-unix.
Thanks for the postfix howto.
This project is an out growth of our work with the SheevaPlug and uses paclink-unix & Linux RMS.
Look forward to you getting a hold of some of our units for fun & testing.
/Basil KE7KRO
Re: Screen shots

Bryan Hoyer <bhhoyer@...>
 

Yes we are using Paclink Unix and Linux RMS.

We have had interest from European distributors but will not have them set-up for first delivery.

Best regards to your sister,
Bryan

On May 26, 2012, at 2:02 PM, c0j wrote:

 



--- In UniversalDigitalRadio@..., "k7udr" <bhhoyer@...> wrote:
>
> I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.
>
> Bryan
Hi Bryan, all,

Are you using paclink-unix/LinuxRMS or something else?

In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it.

Will you be shipping to Europe do you think or will my sister in New Jersey be getting a delivery later in the year ;)?

Regards
John
EI7IG
Re: Screen shots

"c0j" <jpronans@...>
 

--- In UniversalDigitalRadio@yahoogroups.com, "k7udr" <bhhoyer@...> wrote:

I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.

Bryan
Hi Bryan, all,

Are you using paclink-unix/LinuxRMS or something else?

In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it.

Will you be shipping to Europe do you think or will my sister in New Jersey be getting a delivery later in the year ;)?

Regards
John
EI7IG
Re: compatible with DD-WRT?

steve <stevewa206@...>
 

Hummm.... Connecting the DD-WRT to the Ethernet port would work fine...I'm wondering if you used the Open-WRT with the mesh routing, if then you could mesh all the other UDR56K's on the network? If your just using the UDR56K's as layer 2 ( TCP/IP over AX.25 ) and meshing at the WRT level, that would be pretty cool. So you use the UDR56K's as a long range mesh layer and have the WRT at 2.4 Ghz for local mesh. Hummm...that would be nice because then other hams in the area could be seen.

Then again, you can run the MESH protocol on the UDR56K too, on the unit itself. But if the WRT has it all there, that would be cool.


Steve N0FPF

On 5/26/2012 10:04 AM, John D. Hays wrote:

David,


I'm wondering what you are looking for in "compatibility"?

The UDR56K certainly should work through a router running DD-WRT or OpenWRT.

One could port DD-WRT to the UDR56K, but to what purpose?

In development we are using a full Linux distribution, specifically Debian Squeeze and can run various routing protocols and applications that run on Linux.

------------------------------------------------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#%21/john_hays> <http://www.facebook.com/john.d.hays>



On Sat, May 26, 2012 at 7:03 AM, w2lnx <david.bern@... <mailto:david.bern@...>> wrote:

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX
Re: compatible with DD-WRT?

"John D. Hays" <john@...>
 

David,

I'm wondering what you are looking for in "compatibility"?

The UDR56K certainly should work through a router running DD-WRT or OpenWRT.

One could port DD-WRT to the UDR56K, but to what purpose?  

In development we are using a full Linux distribution, specifically Debian Squeeze and can run various routing protocols and applications that run on Linux.

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  



On Sat, May 26, 2012 at 7:03 AM, w2lnx <david.bern@...> wrote:
 

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX
compatible with DD-WRT?

"w2lnx" <david.bern@...>
 

Do you have any plans to be compatible with DD-WRT?

Thank you,
David, W2LNX
Re: Screen shots

"k7udr" <bhhoyer@...>
 

I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.

Bryan

--- In UniversalDigitalRadio@yahoogroups.com, "kgregc" <kgregc@...> wrote:

Are there any screen shots of the Universal Radio software?

Greg
Screen shots

"kgregc" <kgregc@...>
 

Are there any screen shots of the Universal Radio software?

Greg
Re: Cross linking (Was: Codec2)

Jonathan Naylor <naylorjs@...>
 

The specification for the preamble is pretty simple, and I reckon could be implemented easily by an experienced software developer, you'd only need an NCO I reckon. If someone were to implement such a thing then I'd happily add it to my software, but until then....

Jonathan  G4KLX


From: John
To: UniversalDigitalRadio@...
Sent: Thursday, 24 May 2012, 20:50
Subject: [UniversalDigitalRadio] Re: Cross linking (Was: Codec2)

 
The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions.

http://www.d-star.asia/misc/shogen_4_2_8.pdf

It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well).   

For linking, this is all that is really needed.  An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. 

It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.


--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote:
>
> What we would need in the echolink system ist hat you can announce yourself
> to the system with a dtmf number ...
>



Re: Cross linking (Was: Codec2)

"John" <john@...>
 

The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions.

http://www.d-star.asia/misc/shogen_4_2_8.pdf

It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well).   

For linking, this is all that is really needed.  An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. 

It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.


--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote:
>
> What we would need in the echolink system ist hat you can announce yourself
> to the system with a dtmf number ...
>

AW: Cross linking (Was: Codec2)

"siegfried jackstien" <siegfried.jackstien@...>
 

What we would need in the echolink system ist hat you can announce yourself
to the system with a dtmf number ...

Example you are not at home but mobile in the range of any echolink node

Give that node your node number (with a command before) that the system
knows that you are not at home (reachable on your pc with your nodenumber)
but that you are "in the system" known to be reachable via repeater xyz

Now if any other wants to connect you then the system could answer with
"your xall will be forwarded to repeater xyz" ...

All echolink hams have a unique node number (that is your home pc) ...
But all hams also can be called with their callsign number (there is a code
for converting calls to dtmf numbers in echolink)

So ... all the routing and callsign forwarding is there already in the
echolink soft .... now what only is missing is that self-announce to the
system while mobile and not connected with your home pc

Ok ... no automatic routing like in a gsm net ... but something like
"my-bbs" in the packet net ....

Then integrating of some echolink nodes in the d-star (and maybe other) nets
would be a lot easier

Dg9bfc

Sigi

Ps we made some tests with short timings (set to min) and with all spoken
things off (and no beeps etc.) with echolink .... nobody that did not know
it would hear any difference in the audio quality!!

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@yahoogroups.com
[mailto:UniversalDigitalRadio@yahoogroups.com] Im Auftrag von Matthew
Pitts
Gesendet: Donnerstag, 24. Mai 2012 01:24
An: universaldigitalradio@yahoogroups.com
Betreff: Re: [UniversalDigitalRadio] Cross linking (Was: Codec2)





John,

I think as long as the proper display is there, someone using the 1.2k
gmsk modem with analog audio (or echolink with callsign pass-through)
won't really be noticed. It will probably require some special tricks
somewhere along the line to properly work with the Icom gateway software
and such, but that's already taken care of in Jomathan's software.

Matthew Pitts
N8OHU

------------------------------
On Wed, May 23, 2012 7:02 PM EDT John D. Hays wrote:

The argument that analog should never be linked to digital because of
white
noise and other artifacts forgets that Vocoders (as opposed to Codecs)
like
AMBE and Codec-2 are specifically looking for speech and work hard to
remove background noise. All audio starts and ends as analog and
transitioning from an analog FM to digital voice system using a vocoder
applies the same filtering to the audio. I think the folks the argument
haven't tested their theory. Some who have tested it, can probably show
some issues like drop out, overdrive on CTCSS, etc. that will degrade the
system, however, well conditioned audio from an analog FM source should
encode much like analog voice from a microphone.

The second argument is often that the callsign information isn't there in
an analog signal or incompatible digital voice signal. Rules may vary
around the world, but here in the US the ID is for the transmitter where
the signal originates. It doesn't need to be passed through the network
for
identification purposes (other than courtesy or vanity) when it comes to
the regulations. In D-STAR, the callsign is also used as an address for
directed transmissions. In a linked system the only address needed is the
one that identifies the repeater(s) and conference channels, so that the
traffic is properly routed.

Any linking protocol that mixes systems should contain an ability to
identify the type of traffic source (Analog, Digital) and encoding (AMBE,
Codec-2, etc.) and allow the administrator of a repeater to determine
which
traffic to accept.

Given these two "non-issues", the rest is just politics. :)

------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
Re: Cross linking (Was: Codec2)

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 12:35 PM 5/24/2012, you wrote:
The entire “MY� call is unenforceable. It
is sent in clear text, is programmed by the user
and therefore is suspicious. By default, my code
does not check D-Star MY calls for one simple
reason ­ it could lland me in gaol. In most of
the EU, it would be illegal for me acting as a
citizen to deny another citizen access to
systems designed for the whole community based
on my perception of their licensed status. If
it turned out that the other party WAS licensed
and I had denied them access, then I would have
committed a very serious offence in both
anti-discrimination and Human Rights
terms. That is a custodial sentence. The only
people with the power to investigate illegal
transmissions are the police (or Ofcom working
with the police) and the public is advised to
stay out of police business. As any form of
closed system is also not allowed, that means
that irrespective of what someone TELLS me
either verbally or by electronic ID, I cannot
afford to block them for fear of acting illegally. If they break the

I'm not sure where Australia stands on
this. What I do know is that repeaters here are
all considered "open", in that they must be
available to all amateurs whose licence allows
them access to the repeater. The reasoning is
that because the repeater owner effectively has a
frequency "reserved" for the repeater's operation
(by licensing/coordination), then that resource
must be available to all. Limiting access to a
repeater by callsign would seem to fall foul of this principle as well.

However, access to "additional features", such as
IRLP, Echolink or other network access is not
covered by these rules. Precedence was
established by the ACMA fairly early on in the
IRLP days, so it is legal for gateway owners to
allow or block network access on a callsign or
other basis as they see fit. Personally, I've
always believed in open access and have run my
systems as open access to all user functions
(local and network). Seems as is common,
Australia is somewhere between the US and Europe on this.


73 de VK3JED / VK3IRL
http://vkradio.com
Re: Cross linking (Was: Codec2)

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 11:18 AM 5/24/2012, you wrote:

All the time we have the entrenched view of
“this is my system and it won’t connect to
your system� we risk siloing and isolating
users. The net effect is less usage on amateur
bands and less amateurs – exactly the effect
that is being seen in many countries.
At the end of the day, all that the majority of
people want to be able to do is talk to their
friends around the world, and not have to jump
through political hoops to do so.


On the callsign ID, that is an interesting
point. Rules do vary from country to country,
but what I’ve found is that Amateurs naturally
ID every few minutes anyway. In the UK, rules
were relaxed on D-Star so that no voice ID is
required, but you will still typically here an
over start with “G6TBA from G4ULF� and end
with “from G4ULF.� Old habits die hard,
and I certainly ID on every over still.
Similar observations in Australia. However, for
us, this was always a non-issue, because
transmitter ID, not origin ID is the critical factor.


So, again, like you, I think these are both non-issues.

To me, the benefits in terms of increase usage
and more linking possibilities far outweigh these issues.Â

BTW, EchoIRLP does NOT allow interworking IRLP
and Echolink as the IRLP crowd insist on the
end-point being a repeater.   EchoIRLP
allows a repeater to act as an IRLP node and and
Echolink node, but it does not bridge the audio together.
This was one of the original design decisions,
though strictly speaking, there is a bridge
between the two at the protocol level, but it
takes place in the EchoIRLP node when running
Echolink. A copy of thebridge does act as a
local protocol translator between Echolink and
IRLP/Speak Freely (some control functions and
audio transport layer), so the IRLP software can
remain in control of the audio path, as well as
provide sensible status reports to both networks as needed.

73 de VK3JED / VK3IRL
http://vkradio.com
2481 - 2500 of 2579