Date   

Universal Digital Radio Name Change to UDRX-440

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

Press Release

30 December 2013

Friday Harbor, WA


NW Digital Radio

Universal Digital Radio Name Change to UDRX-440


NW Digital Radio has renamed it's forthcoming digital radio platform. Since its inception, the Universal Digital Radio was designed to be a multi-application, multi-protocol, and multi-mode digital radio platform.


When announced at Hamvention® 2012 , the radio design focused around a high integration “radio on a chip” platform that provided both the RF section as well as integrated modems. The selected device proved to be somewhat limited and did not meet the high expectations of the design team and was later abandoned in favor of a modular design that separates the RF and modem stages.


The new design provides an I/Q interface for detection and modulation of the RF signal. This affords maximum flexibility for a software defined modem system, providing a variety of modulation choices at varying data rates, thus freeing the radio from the fixed modulation and data rate choices of the earlier design.


When the radio was first announced it was targeted to a maximum data rate of 56 kilobits per second, based on available modulation choice and the limitations of the US regulations for amateur radio on the 70 cm band. The model name of UDR56k-4 was chosen to reflect this set of specifications. Now that the design allows for additional modulation choices, higher data rates are available within the specified bandwidth and, along with proposed rule changes before the US Federal Communications Commission, has prompted NW Digital Radio to increase the data rates available on the Universal Digital Radio platform.


The company re-opened the naming of the product, seeking input from its growing user interest group, and has adopted a new naming convention. The first radio design is now designated the UDRX-440. This model is a 430-450 mHz digital radio with integrated software defined modems, protocol engine, and Linux application platform.


NW Digital Radio is currently accepting order commitments from individuals who participated in the Q2-2013 pre-order process. Ordering will be opened to the general amateur community in late Q1 or early Q2-2014 with delivery anticipated in mid to late Q2.


For more information visit http://nwdigitalradio.com


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


Re: New Updates on Site

bhhoyer@...
 

Hi Michael, thanks for your input. Here's a point by point response.


# It seems like the target keeps changing.


Quoting from the Press Release at Hamvention 2012:


"The radio will support data rates from 4800-56K+ bps with selectable modulation methods including GMSK, FSK, and 4FSK. The UDR56K will operate in the 70cm band (420-450 mHz.) at up to 25 watts."


As of today we have reduced the band to 430-450, due to availability of SAW filters and increased the upper limit to in excess of 100k.


As far as dropping legacy 56k support. We would rather spend engineering effort on a modern FEC modem.


We are still on target.


# Even if a higher speed is possible, it may not be deployable in many locations due to path issues. 


We are releasing 9600 packet and 4800 D-STAR for full compatibility with the installed base.


Past that, you are absolutely right about the difficulties at higher speeds, so let me clarify our position.


Although lab work is required for verification prior to deployment, the real world is all that matters. We are working with some distinguished modem designers who have decades of experience in this area.


As we announced at DCC in November:


The UDRX will ship with a "Channel Sounder" which will allow all of our users to explore the field performance of candidate modems after they are released (all modems are open-source software plug-ins). I expect many hams will provide the data from mobile stations reporting back to an Internet-connected station where the data will be available on our website.


This data collection and optimization period will last for the better part of the year and result in a short list of modems/rates for different conditions. A negotiation protocol can be added later to establish the fastest reliable connection for a given situation including fall-back as you suggest.


# Also, I hope whatever you do includes an analyzer that shows …


RSSI and BER are built-in as are forward/reflected power. In the process of testing our receiver, it became necessary to inspect the data at various points and display the results graphically. We currently have a crude file based tool that allows us to collect a sample and post-process it using open source tools for things like constellation


The next step will be to connect to the receiver over a socket and display the results using something like WebGL. We will provide the socket but the rest is a substantial software task and we expect some talented Ham will pick this up. I have spoken to a couple of candidates already, but this is not a deliverable item for NW Digital Radio at this time.


All of our software is open-source so anyone may take our internal tools and build on them. If you have a strong math background and the requisite lab equipment, you can design your own modem using our base 9600 FSK/4800 GMSK as a reference.


# I really, REALLY want this to work


Nobody wants this to work more than I do. Except maybe my wife and my increasingly nervous banker.


Onward,

Bryan K7UDR


Re: Pre-Order confirmation

Bryan Hoyer <bhhoyer@...>
 

It's a commitment to buy, but you may still cancel, as we are not taking deposits.

Bryan


On Dec 28, 2013, at 7:37 PM, Dean Gibson AE7Q <yahoo@...> wrote:

Is the "Pre-Order Confirmation" a commitment to buy, or just a 
confirmation of intent?



Re: Pre-Order confirmation

Dean Gibson AE7Q <yahoo@...>
 

Is the "Pre-Order Confirmation" a commitment to buy, or just a confirmation of intent?


Re: New Updates on Site

bhhoyer@...
 

Hi Michael,


Some good points. I will post a full reply after the Holidays


Bryan


Re: New Updates on Site

"Michael E. Fox - N6MEF" <n6mef@...>
 

It seems like the target keeps changing.  “If you don’t know where you’re going, any road will take you there.”

 

Even if a higher speed is possible, it may not be deployable in many locations due to path issues.  Those familiar with deployment of WiFi or digital LMR technologies like P25, DMR, etc. know that the individual circumstances of each path dictate which encoding schemes work and which are just too iffy to be used beyond a certain bit rate.  The denser the constellation, the more perfect the signal needs to be.  Otherwise, what would not be a decoding error at a lower rate becomes an unbearable error level (beyond the ability of FEC to correct) at higher levels.  You can see this on protocol-specific analyzers as the error rate gets higher until FEC breaks down.  To be deployable in multiple environments, a variety of encodings/speeds and channel widths is needed.

 

So, if you start out at only higher speeds, you may end up with something fast in the lab that is not deployable except in limited situations, like path-perfect, mountain-top to mountain-top situations.  And even with mountain-top to mountain-top, if the link is long, you may need to drop back on the speed to lower the error rate Or, maybe you don’t have the right size channel available so you may need to drop back.  (Mountain-top to mountain-top means you’re taking up that channel over a much wider geography and you need to make room for everyone.)  For the price, the thing needs to be able to be deployed in a variety of different scenarios.  At least make sure that we can select various rates/encoding schemes and channel widths.

 

Also, I hope whatever you do includes an analyzer that shows the constellation, decoding error rate, modulation quality, etc.  This will be important for determining the link quality at install time or when diagnosing problems.  Otherwise, even if it works, we’re just sitting there with our fingers crossed, not knowing how close we are to it not working.  Examples of the functionality would be something like the analyzer for P25, DMR, etc. in the Anritsu LMR Master or the Aeroflex analyzer line (several models).  They all pretty much show the same information.

 

I really, REALLY want this product to work.  Hopefully I’m not mentioning anything that the designers/developers don’t already know and are working on.  But I don’t see these real-world issues addressed in the discussion.  So it leads me to wonder…. 

 

Michael

N6MEF

  


Re: New Updates on Site

Mark L Friedlander <marklfriedlander@...>
 

Thank you, John. I understand and agree with the idea that 56kbps speed could be supported, but due to the lack of a significant installed base, you are dedicating engineering resources to leap-frogging that particular rate, in favor of a higher delivered speed. I think  faster modems rolling out as software selectable updates is particularly slick. I like that. In the meantime, I can use the UDRX440 for a 9600 packet node for less than the cost of a 440 radio and TNC.

73 Mark KV4I




On Mon, Dec 23, 2013 at 6:02 PM, John D. Hays <john@...> wrote:
 

Hi Mark,

The in-built modem capability allows different speeds and modulation under software definition.

9600-bps packet, without the need for an external TNC, will be supported right out of the box.  

The name change reflects that the top speed is yet TBD, but will be greater than 56kbps.  

The faster modems will roll out as software selectable updates as we prove them out in the lab.  

The 56kbps speed could be supported, but due to the lack of a significant installed base, we are dedicating engineering resources to leap-frogging that particular rate, in favor of a higher delivered speed.

By design, the UDRX-440 will support modems and protocols (e.g. soft TNC) within the radio itself and should not require an external modem for any supported speed and protocol of the radio itself.  (One might attach an additional TNC or Node Adapter and radio to provide bridging capability to another band or mode [e.g. a 1200 baud 2m port], but this is not required for general operation.)



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




On Mon, Dec 23, 2013 at 2:18 PM, Mark L Friedlander <marklfriedlander@...m> wrote:
 

I understand there have been some changes to the specs since we preordered so I'd like to clarify the details on what I'm buying.

I understood that originally, I would have been able to use the UDR56K for 9600 and 56k packet without adding a TNC. As indicated by the name change and earlier posts, it appears that 56k packet is no longer included. Is that correct? What about 9600 packet. Will the new version UDRX-440 be capable of 9600 packet without an additional TNC?

Thanks,
Mark KV4I



Re: New Updates on Site

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

Hi Mark,

The in-built modem capability allows different speeds and modulation under software definition.

9600-bps packet, without the need for an external TNC, will be supported right out of the box.  

The name change reflects that the top speed is yet TBD, but will be greater than 56kbps.  

The faster modems will roll out as software selectable updates as we prove them out in the lab.  

The 56kbps speed could be supported, but due to the lack of a significant installed base, we are dedicating engineering resources to leap-frogging that particular rate, in favor of a higher delivered speed.

By design, the UDRX-440 will support modems and protocols (e.g. soft TNC) within the radio itself and should not require an external modem for any supported speed and protocol of the radio itself.  (One might attach an additional TNC or Node Adapter and radio to provide bridging capability to another band or mode [e.g. a 1200 baud 2m port], but this is not required for general operation.)



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




On Mon, Dec 23, 2013 at 2:18 PM, Mark L Friedlander <marklfriedlander@...m> wrote:
 

I understand there have been some changes to the specs since we preordered so I'd like to clarify the details on what I'm buying.

I understood that originally, I would have been able to use the UDR56K for 9600 and 56k packet without adding a TNC. As indicated by the name change and earlier posts, it appears that 56k packet is no longer included. Is that correct? What about 9600 packet. Will the new version UDRX-440 be capable of 9600 packet without an additional TNC?

Thanks,
Mark KV4I


Re: New Updates on Site

Mark L Friedlander <marklfriedlander@...>
 

I understand there have been some changes to the specs since we preordered so I'd like to clarify the details on what I'm buying.

I understood that originally, I would have been able to use the UDR56K for 9600 and 56k packet without adding a TNC. As indicated by the name change and earlier posts, it appears that 56k packet is no longer included. Is that correct? What about 9600 packet. Will the new version UDRX-440 be capable of 9600 packet without an additional TNC?

Thanks,
Mark KV4I



On Mon, Dec 23, 2013 at 4:50 PM, John Hays <john@...> wrote:
 

See new information on http://nwdigitalradio.com

Sent from my iPhone



New Updates on Site

John Hays <john@...>
 

See new information on http://nwdigitalradio.com

Sent from my iPhone


Re: Feature Creep

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Many fans now have an output so the system can monitor if they die /
clog / jam. How about an input for such a feature on the fan. Hey,
wait, I thought there wasn't going to be a fan (the massive heat
sink)?


Thanks,

Steve

On Tue, Dec 3, 2013 at 8:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
Transmit testing is well underway and I have begun the board spin to prototype II, in parallel with receiver characterization.

In the process I have added a small housekeeping processor to the radio card, because a PIC with A/D and PWM was cheaper than using discrete ICs.

We have planned the following capabilities but I'm open to other functions provided they meet cost goals.

Please be specific as to what function you would like to see rather than just asking for a bunch of inputs/outputs.
Telemetry applications can be met with USB I/O so let's focus on core radio functionality.

You have Santa's ear,
Bryan

Planned Functionality:

ADC
Forward RF PWR
Reflected RF PWR
PS Voltage
PA Temp

PWM
PA Gate Voltage

Digital IO
12V Fan Output
TX inhibit Input Open Collector
Synthesizer Lock Input
Red/Green TX/RX LED

Serial Interface to Main CPU Set Monitor All Values

EEPROM for Calibration Values

SW Control Functions:

PA Temp
* Fan on at PA>60C
* PA rollback at PA>80C

TX inhibit
* This will allow colocation of the UDR at a site with a 440 Voice Repeater

TX Faults RED Blinking LED
* Hi Reflected Power
* Loss of Lock

PS Low Voltage


Re: Feature Creep

Brian D Heaton <ky9k-lists@...>
 

- Ability to lock at least the RF board to a 10MHz external reference (that may be the "synthesizer lock input" mentioned below).

73-KY9K/Brian

On 12/3/2013 8:05 AM, Bryan Hoyer wrote:
Transmit testing is well underway and I have begun the board spin to prototype II, in parallel with receiver characterization.

In the process I have added a small housekeeping processor to the radio card, because a PIC with A/D and PWM was cheaper than using discrete ICs.

We have planned the following capabilities but I'm open to other functions provided they meet cost goals.

Please be specific as to what function you would like to see rather than just asking for a bunch of inputs/outputs.
Telemetry applications can be met with USB I/O so let's focus on core radio functionality.

You have Santa's ear,
Bryan

Planned Functionality:

ADC
Forward RF PWR
Reflected RF PWR
PS Voltage
PA Temp

PWM
PA Gate Voltage

Digital IO
12V Fan Output
TX inhibit Input Open Collector
Synthesizer Lock Input
Red/Green TX/RX LED

Serial Interface to Main CPU Set Monitor All Values

EEPROM for Calibration Values

SW Control Functions:

PA Temp
* Fan on at PA>60C
* PA rollback at PA>80C

TX inhibit
* This will allow colocation of the UDR at a site with a 440 Voice Repeater

TX Faults RED Blinking LED
* Hi Reflected Power
* Loss of Lock

PS Low Voltage


Re: Feature Creep

Bryan Hoyer <bhhoyer@...>
 

Tom,

COR... DOH!

and done,
Santa


Re: Feature Creep

Bryan Hoyer <bhhoyer@...>
 

Philip,

I'm going to add External Clock as an unstuffed, untested, unsupported and consequently no-cost option.

I think it has merit and the elves seem to like it,
Santa


Re: Feature Creep

Phillip Frost <indigo@...>
 

On Dec 3, 2013, at 4:01 PM, <bhhoyer@...> wrote:

the UDR has a 25MHz Master TCXO Clock

Are you asking for an external clock option to drive multiple UDRs from a common Clock?
Yes, precisely. If you can synchronize the phase of all the mixers and DACs and ADCs of a number of UDRs, each connected to a separate antenna, then you can do all sorts of neat spatial processing in software. What you have is an antenna array, but the phasing of the antennas is software controllable. You might call it MIMO, or beam forming, or spatial filtering, or field recording, depending on precisely what processing you are doing, and in what industry you are.

I'm not normally a fan of feature creep, but since this is something that requires hardware support, I thought it might be worth mentioning now. I imagine all the software that does the neat stuff can be implemented later, as long as the hardware has the necessary bolts, which is just phase coherence among multiple antennas.


Re: Feature Creep

bhhoyer@...
 

Philip,


the UDR has a 25MHz Master TCXO Clock


Are you asking for an external clock option to drive multiple UDRs from a common Clock?


Bryan


Re: Feature Creep

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

Providing BER and RSSI are already in the plan, as well as socket access I/Q, modems, etc. -- The rest appears to be an application?

This is an open design radio, developers are free to experiment with various applications.  NW Digital Radio will provide the platform and a few applications, other applications will come from the community.


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




On Tue, Dec 3, 2013 at 12:08 PM, Mathison Ott <mathisono@...> wrote:
 

I second the software-defined goniometer.  


73 Mathison


On Tue, Dec 3, 2013 at 9:48 AM, Marshall Denny <MarshallDenny@...> wrote:
 

Receive signal strength.
As part of a Signal Quality that includes BER and any other measurement of signal quality available based on demodulation.


--
Respectfully,
W. Marshall Denny II
Software Development Engineer
206 734 9242 cell

Far and away the best prize that life has to offer
 is the chance to work hard at work worth doing.
Theodore Roosevelt



Re: Feature Creep

Mathison Ott <mathisono@...>
 

I second the software-defined goniometer.  


73 Mathison


On Tue, Dec 3, 2013 at 9:48 AM, Marshall Denny <MarshallDenny@...> wrote:
 

Receive signal strength.
As part of a Signal Quality that includes BER and any other measurement of signal quality available based on demodulation.


--
Respectfully,
W. Marshall Denny II
Software Development Engineer
206 734 9242 cell

Far and away the best prize that life has to offer
 is the chance to work hard at work worth doing.
Theodore Roosevelt



Re: Feature Creep

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

These type of signals are what Bryan is looking for -- I would just add that the UDR also runs in the 430 band, so they can have significant separation (in frequency domain) from repeater receivers (and transmitters).

E.g. if it is colocated on a site with a 444.9+ repeater [receiver at 449.9] and runs at 433.9, that is 16 mHz from the receiver and 11 mHz from the transmitter of the repeater.  2-3X the separation of the typical duplex pair.

[Please don't jump all over the use of particular frequencies, they are simply for illustration purposes.]



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




On Tue, Dec 3, 2013 at 9:31 AM, Tom Hayward <esarfl@...> wrote:
 

On Tue, Dec 3, 2013 at 8:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
> TX inhibit
> * This will allow colocation of the UDR at a site with a 440 Voice Repeater

I see the TX inhibit input, but not the TX active output. Say I put
two of these at a site. How do I keep them from TXing at the same
time?

You use the colocated voice repeater example... maybe I want to
disable my repeater while the data radio is transmitting, not the
other way around :-)

What really excites me about a data radio like this is sampling the
receiver directly. I don't care if you implement any protocols before
selling it to me; I just want the SDR. I'm one of the guys who checked
the "Linux experimenter" box.

Will you add the receiver sampling specs to the datasheet?

Tom KD7LXL

__._,_.__.



Re: Feature Creep

Marshall Denny <MarshallDenny@...>
 

Receive signal strength.
As part of a Signal Quality that includes BER and any other measurement of signal quality available based on demodulation.


--
Respectfully,
W. Marshall Denny II
Software Development Engineer
206 734 9242 cell

Far and away the best prize that life has to offer
 is the chance to work hard at work worth doing.
Theodore Roosevelt