|
Re: Question on TX/RX antenna ports
Jim Kusznir <jkusznir@...>
Sorry, my diagram did not indicate that I do also have a band pass filter on the output of the isolator before the RF goes back to the radio. In my current setup, I have 2 3-port TX/RX isolators going through a TX/RX "spur reducer" (rare item, couldn't find any details, not adjustable), and then into a standard Motorola square UHF cavity configured for band pass, before returning to the radio and going to the internal TX/RX switch.
--Jim
On Mon, Feb 10, 2014 at 3:43 PM, John Lloyd <lloyd@...> wrote: Hi Jim,
|
|
|
|
Re: Question on TX/RX antenna ports [1 Attachment]
John Lloyd <lloyd@...>
Hi Jim,
toggle quoted messageShow quoted text
Remember that you should also install a low pass filter or band pass cavity after the isolator to keep it off the antenna for IM reasons. John Lloyd, K7JL Jim Kusznir wrote:
Ack, this message got mis-filed by my mail client, sorry for the delay!
|
|
|
|
Re: Question on TX/RX antenna ports
Jim Kusznir <jkusznir@...>
Ack, this message got mis-filed by my mail client, sorry for the delay! Here's my attempt at a block diagram...I'm pretty poor at diagramming... This is what my current Mitrek on the hill is configured as. Simple intercept of the TX line to the TX/RX switch. It breaks that out externally for isolator support, then brings it back into the box and uses the stock TX/RX relay for switching.
For my purposes, it would be great if I could get a "standard" UDR, except there are two additional connectors on it (SMA is fine :) ), that breaks out the TX path (and if desired, the radio can ship with a jumper across these two ports such that it functions identically to a stock UDR). For those users who want to use seperate TX and RX antennas, I think they could just use the TX out and not send it back into the radio for their TX output, and use the "normal" antenna port for RX. That way the receiver is still protected against too much RF on transmit.
Anyway, thanks for your response! My Mitrek on the hill isn't doing so well now, so I'm leaning more and more toward replacing it with a UDR as soon as I can get one (originally I was just going to get one for personal use).
On Tue, Jan 28, 2014 at 1:31 PM, <bhhoyer@...> wrote:
|
|
|
|
Re: Question on TX/RX antenna ports
bhhoyer@...
Jim, I reviewed our setup and it requires an external switch to protect the receive port and yes the Tx/Rx signal is available to drive it. Please send me a block diagram of the application. I may be able to make a slight change and use the internal switch. Bryan
|
|
|
|
Re: Question on TX/RX antenna ports
Keith Goobie <keith@...>
Sent from my iPhone
On Jan 23, 2014, at 1:46 PM, Bryan Hoyer <bhhoyer@...> wrote:
|
|
|
|
Re: Question on TX/RX antenna ports
Bryan Hoyer <bhhoyer@...>
Jim,
toggle quoted messageShow quoted text
I'm just wrapping up some time critical engineering work. First of next week, I'll publish the block diagram of our antenna switch with both options and then I can address your question better. Thanks, Bryan
On Jan 23, 2014, at 10:20 AM, Jim Kusznir <jkusznir@...> wrote: Hi all: I have a quick question on the implementation of the separate TX and RX ports on the UDRX: I realize its half-duplex, so will there still be T/R switching internally to protect against tx rf coming back on the rx port? My application is for a mountain application where a circulator is required on the tx output. Typically for these radios, I mod them to intercept the TX path prior to the T/R switch and break them out to the circulator/bandpass cavity, then back in. I then use the T/R switch and its single antenna connector to connect to the input antenna (which is used both for RX and TX). So, in the case of the UDR with separate TX/RX ports, would I be able to simply split the incoming antenna and run it into the RX port directly, and take the other side and run it through the circulator/band pass filter? Or will there be an output to drive an external T/R switch? How would you recommend me using it in that configuration? Thanks! --Jim
|
|
|
|
Question on TX/RX antenna ports
Jim Kusznir <jkusznir@...>
Hi all: I have a quick question on the implementation of the separate TX and RX ports on the UDRX: I realize its half-duplex, so will there still be T/R switching internally to protect against tx rf coming back on the rx port?
My application is for a mountain application where a circulator is required on the tx output. Typically for these radios, I mod them to intercept the TX path prior to the T/R switch and break them out to the circulator/bandpass cavity, then back in. I then use the T/R switch and its single antenna connector to connect to the input antenna (which is used both for RX and TX).
So, in the case of the UDR with separate TX/RX ports, would I be able to simply split the incoming antenna and run it into the RX port directly, and take the other side and run it through the circulator/band pass filter? Or will there be an output to drive an external T/R switch? How would you recommend me using it in that configuration?
Thanks! --Jim
|
|
|
|
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.
toggle quoted messageShow quoted text
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
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
New Updates on Site
John Hays <john@...>
|
|
|
|
Re: Feature Creep
Steve Stroh N8GNJ <steve.n8gnj@...>
Many fans now have an output so the system can monitor if they die /
toggle quoted messageShow quoted text
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.
|
|
|
|
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).
toggle quoted messageShow quoted text
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.
|
|
|
|
Re: Feature Creep
Bryan Hoyer <bhhoyer@...>
Tom,
COR... DOH! and done, Santa
|
|
|
