1. main@nw-digital-radio.groups.io
   Date   
N connector Male or Female?

"marklfriedlander" <marklfriedlander@...>
 

I see the specs for the UDR56K specify "RF Connector: Type N" but is it male or is it female?

Thanks,
Mark KV4I
Re: Frequencies, Band Plans and other annoyances

"brad_ka3yan" <bradm75@...>
 

Bryan,

I'm in the Charleston, SC area. While I haven't had any issues personally with channelization in the 70cm band, I would have to consult with the governing body before I open my mouth and say something wrong. The South Eastern Repeater Association (SERA) handles frequency coordination in my area.

Their website states:

439.6000 - 440.4750 FM Digital/Packet Operation
440.5125 - 440.7250 NB Digital Repeater Outputs/Duplex Backbones/Link
440.9125 - 441.1750 Simplex Digital
445.0250 - 445.4750 Digital
445.5125 - 445.7250 Digital Repeater Inputs
446.5000 Simplex Digital

Narrow Band FM Digital/Packet Repeater or Digital/Packet
Duplex Backbone
18 Duplex Channels, 12.5 KHz split, 5 MHz split, High input - Low output
445.5125 - 440.5125 445.5250 - 440.5250 445.5375 - 440.5375
445.5500 - 440.5500 445.5625 - 440.5625 445.5750 - 440.5750
445.5875 - 440.5875 445.6000 - 440.6000 445.6125 - 440.6125
445.6250 - 440.6250 445.6375 - 440.6375 445.6500 - 440.6500
445.6625 - 440.6625 445.6750 - 440.6750 445.6875 - 440.6875
445.7000 - 440.7000 445.7125 - 440.7125 445.7250 - 440.7250

Wide Band Digital/Packet Duplex Backbones/Links
19 Duplex, Mixed 50/100 KHz, 5 MHz split, High input, Low output,
horizontal or vertical polarization optional
445.0250 - 440.0250 445.0500 - 440.0500 445.0750 - 440.0750
445.1000 - 440.1000 445.1250 - 440.1250 445.1500 - 440.1500
445.1750 - 440.1750 445.2000 - 440.2000 445.2250 - 440.2250
445.2500 - 440.2500 445.2750 - 440.2750 445.3000 - 440.3000
445.3250 - 440.3250 445.3500 - 440.3500 445.3750 - 440.3750
445.4000 - 440.4000 445.4250 - 440.4250 445.4500 - 440.4500
445.4750 - 440.4750

Narrow Band FM Digital/Packet Simplex
440.9125 440.9250 440.9375 440.9500 440.9625 440.9750
440.9875 441.0000 441.0125 441.0250 441.0375 441.0500
441.0625 441.0750 441.0875 441.1000 441.1125 441.1250
441.1375 441.1500 441.1625 441.1750

Let me just say, the band is not crowded here. I'm actually operating my Winlink 9600bps Packet RMS out of the band plan in 441.050, but its because my radio is crystalled for that freq. I haven't gotten any complaints and I seriously doubt I will. Like I said, this area is not heavily trafficed in the 70cm band.

73,
Brad, KA3YAN

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

As we move forward to deployment, it occurs to me that the landscape for operating frequencies is anything but stable.

Here in Western Washington we have 19 - 25kHz simplex channels designated as packet, of which only 3 are contiguous, such that we could use them as a 100kHz high speed channel.

We also have 3 pairs designated as packet repeaters.

What are your thoughts on how to deploy the UDR in your area, particularly once we move past the current 4800 NB and 9600 baud rate limitations.

Bryan - K7UDR
Re: Frequencies, Band Plans and other annoyances

M5AKA <m5aka@...>
 

--- On Sat, 8/6/13, avignonmimi@... <avignonmimi@...> wrote:
It would be nice if someone made a circular polarized antenna with
a left or a right pattern, so they could be used terrestrially.
The only problem might be whether to use Left or Right circular as there's 30 dB's attenuation between the two.

The IARU recommends using Right-hand Circular, see 8.8.7 of the VHF Handboook at
http://www.iaru-r1.org/index.php?option=com_remository&Itemid=173&func=fileinfo&id=178

Circular antennas are available from Wimo
http://www.wimo.de/helix-antennas_e.html

73 Trevor M5AKA
Re: Frequencies, Band Plans and other annoyances

"avignonmimi@..." <avignonmimi@...>
 

East and West coasts could be a problem with Navy/USAF radars. The USAF created a UHF ham-free zone around the west coast Pave Paw radar.

Kantronics built their data radio for the 430 band back in the 90's, to keep it out of narrow band repeater space. Most common catalog ham antennas are cut for 440 though, so you had to buy more expensive satellite antennas, or build your own.

It would be nice if someone made a circular polarized antenna with a left or a right pattern, so they could be used terrestrially.

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

As we move forward to deployment, it occurs to me that the landscape for operating frequencies is anything but stable.
Re: TCP/IP Over Packet

"avignonmimi@..." <avignonmimi@...>
 

I'm scratching my head for memory, but I seem to recall setting the MTU to 4 times the PACLEN so that only one TCP and one AX.25 overhead packet was sent, and the other 3 packets were just data. This was for JNOS to JNOS. That was a real advantage of VC (connected mode on JNOS).

Course that feature would gag a netrom or rose switch, ha.

--- In UniversalDigitalRadio@..., "Curt, WE7U" <curt.we7u@...> wrote:

I seem to remember that we were using 1024-byte packets over 9600 baud in the Seattle area on TCP/IP back in the early 90's, and UI frames.

As soon as I get a box in my hand I'll be trying to do the same or better on 56k.
Re: Frequencies, Band Plans and other annoyances

PE1RDW <pe1rdw@...>
 

On Wed, 05 Jun 2013 21:46:23 +0200, k7udr <bhhoyer@...> wrote:

As we move forward to deployment, it occurs to me that the landscape for operating frequencies is anything but stable.

Here in Western Washington we have 19 - 25kHz simplex channels designated as packet, of which only 3 are contiguous, such that we could use them as a 100kHz high speed channel.

We also have 3 pairs designated as packet repeaters.

What are your thoughts on how to deploy the UDR in your area, particularly once we move past the current 4800 NB and 9600 baud rate limitations.

Bryan - K7UDR
In europe it should be no problem, region one has about 200 khz for duplex/relais packet, 400 khz simplex packet, and 3 all mode sections, one 500 khz, one 400 khz and one 600 khz, offcourse the all mode section are also used for wide band fm communication so might not always be available but are still often the best suited because in the simpelx and duplex packet sections are still a lot of laps active at 9k6

--
73 Andre PE1RDW
Frequencies, Band Plans and other annoyances

"k7udr" <bhhoyer@...>
 

As we move forward to deployment, it occurs to me that the landscape for operating frequencies is anything but stable.

Here in Western Washington we have 19 - 25kHz simplex channels designated as packet, of which only 3 are contiguous, such that we could use them as a 100kHz high speed channel.

We also have 3 pairs designated as packet repeaters.

What are your thoughts on how to deploy the UDR in your area, particularly once we move past the current 4800 NB and 9600 baud rate limitations.

Bryan - K7UDR
Re: TCP/IP Over Packet

"Curt, WE7U" <curt.we7u@...>
 

On Thu, 2 May 2013, avignonmimi@... wrote:

Back in the late 90's we had a pretty good TCP/IP link from OKC to North Texas.

Actually, we used a TheNet IP node to bang the connected mode packets against to get an ACK, and then the rest of the link was ROSE. ROSE worked 100% better than pure IP nodes.

Here locally we also experimented with larger packet lengths between PC's where we were running JNOS. You definitely want to go with larger packets at speeds 9600 and up.

The obsolete AX.25 was designed for Z-80 boxes with little memory. PC's have plenty of memory for buffers. It was also designed for only 6-char callsigns, and I think some countries are issuing more letters than that. The repeater feature of AX.25 is also highly deprecated.
I seem to remember that we were using 1024-byte packets over 9600 baud in the Seattle area on TCP/IP back in the early 90's, and UI frames.

As soon as I get a box in my hand I'll be trying to do the same or better on 56k.

--
Curt, WE7U. http://wetnet.net/~we7u
Windows ate my homework!
Re: TCP/IP Over Packet

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

You will be able to use DD on the UDR either as an Ethernet bridge (with TCP/IP as the encapsulated protocol) or setup each UDR as a router with the DD bridge between them. 

The router approach is better if you need to manage traffic due to link speed.

We'll have application notes for this at release, but yes you can bridge networks over DD.  

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





On Thu, May 30, 2013 at 10:18 AM, Steve <ve7cbh@...> wrote:
 

Your comment about D-star DD for TCP/IP interests me. Being a D-star newby, how difficult will it be to setup a TCP/IP bridge between two network segments (on the same subnet)using the UDR?

Steve
VE7CBH
Re: TCP/IP Over Packet

"Steve" <ve7cbh@...>
 

Your comment about D-star DD for TCP/IP interests me. Being a D-star newby, how difficult will it be to setup a TCP/IP bridge between two network segments (on the same subnet)using the UDR?

Steve
VE7CBH

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

Questions that came in via email. Thanks to John for responding

Is it possible to use TCP-IP over ax25 with large MTU ?

The UDR56K implements the Linux AX.25 stack using a socket interface. Each AX.25 frame may carry a payload of up to 256 octets. (http://www.tapr.org/pub_ax25.html 2.5.5) This comes with an overhead of up to 76 octets, and is exclusive of bit-stuffing (2.2.6) which translates to about 21 frames per second in continuous, unconnected mode under perfect conditions, e.g. no packet loss.

Sometimes when describing TCP/IP or UDP/IP circuits, the MSS (Maximum Segment Size - http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Maximum_segment_size) is mislabeled MTU. The MTU is governed by the transport, in this case AX.25, or 256 octets per frame. However, the Linux protocol stack will allow a larger MSS, which is fragmented over multiple AX.25 frames. (Source code http://www.cs.albany.edu/~sdc/Linux/linux/net/ax25/ax25_out.c). TCP/IP allows a MSS of 65000+ octets, but this number is impractical for any reasonable network. An MSS of 65000 over AX.25 would fragment into 256 frames or more than 10 seconds transmission under ideal 56 kbps conditions and could require a retry on a single bit error. An IP MTU is the MSS + Header (>=20 Octets) and in most AX.25 circuits the IP MTU is kept to a modest 512 octets or 2 AX.25 frames. The optimum IP MTU on the UDR56K-4 may or may not be a higher number and will require experimentation by the amateur community to come up with a specific recommendation.

What is the net throughput in tcp/ip ?

At 1:1 IP to AX.25 MTU (no fragmentation) one would see speeds approaching 31 kbps using UDP over AX.25, this would vary +/- depending on fragmentation (to lower header count under IP) and packet loss, and acknowledgement time for TCP. The radio is specified with a tx/rx turnaround at < 1.5 ms.

If your interest is truly TCP/IP you may also want to consider using the D-STAR Data Mode. It encapsulates Ethernet frames in a D-STAR packet. http://www.jarl.com/d-star/shogen.pdf 2.1 - This would provide 4.3 1430 (MSS) data per second (UDP) or approximately 49 kbps. (58% improvement).

We also believe there is room for a yet to be determined protocol that might have up to a 7000 octet MTU, basically raw IP with a few sync bits, which would approach 56 kbps of UDP on a loss less circuit.
TCP/IP Over Packet

"k7udr" <bhhoyer@...>
 

Questions that came in via email. Thanks to John for responding

Is it possible to use TCP-IP over ax25 with large MTU ?

The UDR56K implements the Linux AX.25 stack using a socket interface. Each AX.25 frame may carry a payload of up to 256 octets. (http://www.tapr.org/pub_ax25.html 2.5.5) This comes with an overhead of up to 76 octets, and is exclusive of bit-stuffing (2.2.6) which translates to about 21 frames per second in continuous, unconnected mode under perfect conditions, e.g. no packet loss.

Sometimes when describing TCP/IP or UDP/IP circuits, the MSS (Maximum Segment Size - http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Maximum_segment_size) is mislabeled MTU. The MTU is governed by the transport, in this case AX.25, or 256 octets per frame. However, the Linux protocol stack will allow a larger MSS, which is fragmented over multiple AX.25 frames. (Source code http://www.cs.albany.edu/~sdc/Linux/linux/net/ax25/ax25_out.c). TCP/IP allows a MSS of 65000+ octets, but this number is impractical for any reasonable network. An MSS of 65000 over AX.25 would fragment into 256 frames or more than 10 seconds transmission under ideal 56 kbps conditions and could require a retry on a single bit error. An IP MTU is the MSS + Header (>=20 Octets) and in most AX.25 circuits the IP MTU is kept to a modest 512 octets or 2 AX.25 frames. The optimum IP MTU on the UDR56K-4 may or may not be a higher number and will require experimentation by the amateur community to come up with a specific recommendation.

What is the net throughput in tcp/ip ?

At 1:1 IP to AX.25 MTU (no fragmentation) one would see speeds approaching 31 kbps using UDP over AX.25, this would vary +/- depending on fragmentation (to lower header count under IP) and packet loss, and acknowledgement time for TCP. The radio is specified with a tx/rx turnaround at < 1.5 ms.

If your interest is truly TCP/IP you may also want to consider using the D-STAR Data Mode. It encapsulates Ethernet frames in a D-STAR packet. http://www.jarl.com/d-star/shogen.pdf 2.1 - This would provide 4.3 1430 (MSS) data per second (UDP) or approximately 49 kbps. (58% improvement).

We also believe there is room for a yet to be determined protocol that might have up to a 7000 octet MTU, basically raw IP with a few sync bits, which would approach 56 kbps of UDP on a loss less circuit.
Re: Software interface to UDR56K

Marshall Denny <MarshallDenny@...>
 

Hello,
I am interested in several project using the udr56k.

The first is testing several types of forward error correction at the higher speeds.

I what to find what works best so that we can use 56k bps under a wider range of rf conditions.  When we used 56k packet back east years ago, it was to temperamental for    general use.  I hope that a little or a lot of FEC will solve this problem.

For starters I would like to try a combination of LDPC and reed -solomon if the processor board has the throughput to do these in realtime.

Using a basic amount of FEC at lower speeds for packet could give us a guess if a higher speed is likely to work.  

Respectfully,
Marshall
AI4CM


On Mon, Apr 29, 2013 at 4:13 PM, John <john@...> wrote:
 

Hi Marshall,

Everyone is heads down leading up to Dayton.

What type of software are you planning.  It may help us understand what priorities our customers have for writing software?


--- In UniversalDigitalRadio@..., "marshalldennyai4cm" wrote:
>
> I don't want to rush NW Digital.
>
> But, I would like to get API's to the radio as they become finalized.
>
> This will allow me to start building some software before I get the radio.
>
> Respectfully,
> Marshall
> AI4CM
>




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

For if you altogether hold your peace at this time,
then shall relief and deliverance arise to the Jews from another place;
but you and your father's house shall be destroyed:
and who knows whether you are come to the kingdom for such a time as this?  Esther 4:14 KJV

Re: Software interface to UDR56K

"John" <john@...>
 

Hi Marshall,

Everyone is heads down leading up to Dayton.

What type of software are you planning.  It may help us understand what priorities our customers have for writing software?


--- In UniversalDigitalRadio@..., "marshalldennyai4cm" wrote:
>
> I don't want to rush NW Digital.
>
> But, I would like to get API's to the radio as they become finalized.
>
> This will allow me to start building some software before I get the radio.
>
> Respectfully,
> Marshall
> AI4CM
>
Software interface to UDR56K

"marshalldennyai4cm" <MarshallDenny@...>
 

I don't want to rush NW Digital.

But, I would like to get API's to the radio as they become finalized.

This will allow me to start building some software before I get the radio.

Respectfully,
Marshall
AI4CM
Re: USB Radio Interface (URI) ?

"John" <john@...>
 


--- In UniversalDigitalRadio@..., "Douglas" wrote:
>
> All,
>
> Can the URI (from DMK Engineering Inc.) work with the UDR56K-4 to provide an additional radio interface?
>
> http://www.dmkeng.com/Products.htm
>
> v/r
> Doug (N1OBU)
>

Doug,

The Linux OS recognizes it when plugged in, but I haven't had any time to test it.  It may require some software development for any particular use.

[929191.235130] usb 1-1.1: new full-speed USB device number 11 using pxa168-ehci
[929191.367365] usb 1-1.1: New USB device found, idVendor=0d8c, idProduct=013a
[929191.367387] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[929191.382482] usb 1-1.1: Product: USB PnP Sound Device
[929191.387984] usb 1-1.1: Manufacturer: C-Media Electronics Inc.
[929191.401778] ALSA sound/usb/stream.c:438 11:1:1: add audio endpoint 0x1
[929191.409606] ALSA sound/usb/stream.c:438 11:2:1: add audio endpoint 0x82
[929191.417613] ALSA sound/usb/mixer.c:1192 [13] FU [Mic Playback Switch] ch = 1, val = 0/1/1
[929191.429111] ALSA sound/usb/mixer.c:454 cannot set ctl value: req = 0x4, wValue = 0x200, wIndex = 0xd00, type = 4, data = 0x18/0x0
[929191.443736] ALSA sound/usb/mixer.c:1192 [13] FU [Mic Playback Volume] ch = 1, val = 0/6096/48
[929191.452890] ALSA sound/usb/mixer.c:1192 [9] FU [Speaker Playback Switch] ch = 1, val = 0/1/1
[929191.464862] ALSA sound/usb/mixer.c:454 cannot set ctl value: req = 0x4, wValue = 0x201, wIndex = 0x900, type = 4, data = 0x18/0x0
[929191.477739] ALSA sound/usb/mixer.c:1192 [9] FU [Speaker Playback Volume] ch = 2, val = -7264/-16/48
[929191.487297] ALSA sound/usb/mixer.c:1192 [10] FU [Mic Capture Switch] ch = 1, val = 0/1/1
[929191.498861] ALSA sound/usb/mixer.c:454 cannot set ctl value: req = 0x4, wValue = 0x200, wIndex = 0xa00, type = 4, data = 0x18/0x0
[929191.512607] ALSA sound/usb/mixer.c:1192 [10] FU [Mic Capture Volume] ch = 1, val = 0/6096/384
[929191.521737] ALSA sound/usb/mixer.c:1192 [10] FU [Auto Gain Control] ch = 1, val = 0/1/1



T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0d8c ProdID=013a Rev=01.00
S:  Manufacturer=C-Media Electronics Inc.
S:  Product=USB PnP Sound Device
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
I:  If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I:  If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I:  If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=(none)

ls -lR /dev/snd
/dev/snd:
total 0
drwxr-xr-x 2 root root       60 Apr 28 16:26 by-id
drwxr-xr-x 2 root root       60 Apr 28 16:26 by-path
crw-rw---- 1 root audio 116,  0 Apr 28 16:26 controlC0
crw-rw---- 1 root audio 116, 24 Apr 28 16:26 pcmC0D0c
crw-rw---- 1 root audio 116, 16 Apr 28 16:26 pcmC0D0p
crw-rw---- 1 root audio 116, 33 Dec 31  1969 timer

/dev/snd/by-id:
total 0
lrwxrwxrwx 1 root root 12 Apr 28 16:26 usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00 -> ../controlC0

/dev/snd/by-path:
total 0
lrwxrwxrwx 1 root root 12 Apr 28 16:26 platform-pxa168-ehci-usb-0:1.1:1.0 -> ../controlC0

ls -lR /proc/asound/
/proc/asound/:
total 0
dr-xr-xr-x 4 root root 0 Apr 28 16:30 card0
-r--r--r-- 1 root root 0 Apr 28 16:30 cards
lrwxrwxrwx 1 root root 5 Apr 28 16:30 Device -> card0
-r--r--r-- 1 root root 0 Apr 28 16:30 devices
-r--r--r-- 1 root root 0 Apr 28 16:30 hwdep
-r--r--r-- 1 root root 0 Apr 28 16:30 pcm
-r--r--r-- 1 root root 0 Apr 28 16:30 timers
-r--r--r-- 1 root root 0 Apr 28 16:30 version

/proc/asound/card0:
total 0
-r--r--r-- 1 root root 0 Apr 28 16:30 id
dr-xr-xr-x 3 root root 0 Apr 28 16:30 pcm0c
dr-xr-xr-x 3 root root 0 Apr 28 16:30 pcm0p
-r--r--r-- 1 root root 0 Apr 28 16:30 stream0
-r--r--r-- 1 root root 0 Apr 28 16:30 usbbus
-r--r--r-- 1 root root 0 Apr 28 16:30 usbid
-r--r--r-- 1 root root 0 Apr 28 16:30 usbmixer

/proc/asound/card0/pcm0c:
total 0
-r--r--r-- 1 root root 0 Apr 28 16:30 info
dr-xr-xr-x 2 root root 0 Apr 28 16:30 sub0
-rw-r--r-- 1 root root 0 Apr 28 16:30 xrun_debug

/proc/asound/card0/pcm0c/sub0:
total 0
-r--r--r-- 1 root root 0 Apr 28 16:30 hw_params
-r--r--r-- 1 root root 0 Apr 28 16:30 info
-r--r--r-- 1 root root 0 Apr 28 16:30 status
-r--r--r-- 1 root root 0 Apr 28 16:30 sw_params

/proc/asound/card0/pcm0p:
total 0
-r--r--r-- 1 root root 0 Apr 28 16:30 info
dr-xr-xr-x 2 root root 0 Apr 28 16:30 sub0
-rw-r--r-- 1 root root 0 Apr 28 16:30 xrun_debug

/proc/asound/card0/pcm0p/sub0:
total 0
-r--r--r-- 1 root root 0 Apr 28 16:30 hw_params
-r--r--r-- 1 root root 0 Apr 28 16:30 info
-r--r--r-- 1 root root 0 Apr 28 16:30 status
-r--r--r-- 1 root root 0 Apr 28 16:30 sw_params

DE K7VE
USB Radio Interface (URI) ?

"Douglas" <dperv27@...>
 

All,

Can the URI (from DMK Engineering Inc.) work with the UDR56K-4 to provide an additional radio interface?

http://www.dmkeng.com/Products.htm

v/r
Doug (N1OBU)
Re: Power output... is it adjustable?

"k7udr" <bhhoyer@...>
 

Power output is firmware adjustable via PWM, then filtered and switched to the PA for fast turnaround. This is a low bandwidth path and is not designed for modulation.

However, you can still do amplitude modulation via the IQ modem, which is the preferred method anyway, provided you reduce the power to a more linear range like 10W.

The UDR56k is not characterized for modulations other than FSK and GMSK.

Bryan

--- In UniversalDigitalRadio@..., "zl2wrw" <ross@...> wrote:



--- In UniversalDigitalRadio@..., Dean Gibson AE7Q <yahoo@> wrote:

From the PDF file on the web site: TX Output Power @ 13.8VDC: 25, 10, 5 W
Are these power steps fixed in hardware, or are they soft-adjustable by firmware (eg PWM output from MCU determines DC voltage delivered to TX RF amplifier chain)?

If the TX power is adjustable over a wide range by software (ie the above mentioned PWM output), then how much bandwidth does the TX power control circuit have? (how quickly can the TX power output be changed).

If it has sufficient bandwidth, and the radio had the right firmware, would it be feasible to modulate both the phase of the TX RF and it's amplitude in order to achieve polar modulation, which would enable the use of modes like n-PSK, n-QAM, narrowband OFDM, and even SSB...


73
ZL2WRW
Ross Whenmouth
Re: Power output... is it adjustable?

"zl2wrw" <ross@...>
 

--- In UniversalDigitalRadio@..., Dean Gibson AE7Q <yahoo@...> wrote:

From the PDF file on the web site: TX Output Power @ 13.8VDC: 25, 10, 5 W
Are these power steps fixed in hardware, or are they soft-adjustable by firmware (eg PWM output from MCU determines DC voltage delivered to TX RF amplifier chain)?

If the TX power is adjustable over a wide range by software (ie the above mentioned PWM output), then how much bandwidth does the TX power control circuit have? (how quickly can the TX power output be changed).

If it has sufficient bandwidth, and the radio had the right firmware, would it be feasible to modulate both the phase of the TX RF and it's amplitude in order to achieve polar modulation, which would enable the use of modes like n-PSK, n-QAM, narrowband OFDM, and even SSB...


73
ZL2WRW
Ross Whenmouth
Re: Power output... is it adjustable?

"k7udr" <bhhoyer@...>
 

From the Data Sheet:
Tx Output Power @ 13.8VDC
25, 10, 5 W

We may go lower but it becomes diminishing returns in RF Output Power vs DC Input Power.

Bryan

--- In UniversalDigitalRadio@..., Michael Carey <michaelcarey@...> wrote:

Hi Everybody,

We all know the UDR56K-4 is a 25 Watt radio... but can it be turned down?

There will be times when a power output of a few hundred milliwatts
would be perfectly fine.

Michael.
VK5ZEA
Re: Power output... is it adjustable?

Dean Gibson AE7Q <yahoo@...>
 

From the PDF file on the web site: TX Output Power @ 13.8VDC: 25, 10, 5 W

On 2013-04-18 22:10, Michael Carey wrote:
Hi Everybody,

We all know the UDR56K-4 is a 25 Watt radio... but can it be turned down?

There will be times when a power output of a few hundred milliwatts
would be perfectly fine.

Michael.
V