Date   

Re: UDR56k-4 Sensitivity & BER

Bryan Hoyer <bhhoyer@...>
 

On the topic of Modulation

The data-sheet lists the modulation types implemented in the first release. These types support existing digital standards for compatibility.

The UDR uses an IQ XCVR and as such is capable of doing other modulation types, limited by the regs and the linearity of the PA. The modem is implemented in software and can be updated in the field.

We will release a full briefing on our software architecture at DCC.

Cheers,
Bryan K7UDR

On Aug 7, 2013, at 9:23 AM, "Michael E. Fox - N6MEF" <n6mef@...> wrote:

 


Around here in order to test anything I have to buy more radios and computers, there's no-one else to talk to.  That said, I'm interested in getting more radios :)

Absolutely!  I’m all for that!

Interesting, thanks for the info.  This was using Connected Mode AX.25 or TCP/IP over Disconnected Mode?

We tried both.  It doesn’t matter.  The errored packet still needs to be retransmitted, regardless of whether it is AX.25 or TCP/IP that makes the decision.




Sure.   This is why i thought quoting the sensitivity for a BER of 10^-3 was a bit odd.  I assume that post-correction residual BER figures for modems with FEC would be used in the sensitivity figures when presented in the specs.

I believe that’s the case.  BER is certainly important and one needs to know where that break point is.  But it’s also important to understand that you can’t design a system to operate at the worst case 0% BER point.  The reason is that, with FEC, BER stays at 0% until the signal is so dirty that error correction can’t help it any more.  At that point, BER jumps up very quickly from 0% to 5% or more with just a dB or two of reduced C/I (Carrier to Interference ratio).  In other words, a 0% BER signal and a total unusable signal can be very, very close in C/I.  So, at the point where 0% BER is lost, you have little to no fade margin and your system will not be reliable.  In practice, the modulation fidelity value is monitored during such things as drive tests because it changes gradually as the signal quality gets worse.  That can help you determine the type of fade margin you need to build into your link budget.  Then, depending on the fade margin you need for your environment, you can then determine how much signal you need to stay away from the danger point.

 

On another point, I note that the UDR56K datasheet says the modulation types are FSK and GMSK.  I also know that the digital radio community is moving to PSK as a more reliable way to transmit higher bandwidths within the same spectrum.  I’m not a modulation engineer, but as I understand it, it’s evidently possible to switch more quickly and accurately between phases than it is to switch between frequencies, making for less bit/symbol errors.  I wonder if PSK, QPSK, etc. emission types are even allowed by our FCC Part 97 rules which govern ham radio.  Hmm… something to check.

 

Michael

N6MEF




Re: UDR56k-4 Sensitivity & BER

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


Around here in order to test anything I have to buy more radios and computers, there's no-one else to talk to.  That said, I'm interested in getting more radios :)

Absolutely!  I’m all for that!

Interesting, thanks for the info.  This was using Connected Mode AX.25 or TCP/IP over Disconnected Mode?

We tried both.  It doesn’t matter.  The errored packet still needs to be retransmitted, regardless of whether it is AX.25 or TCP/IP that makes the decision.




Sure.   This is why i thought quoting the sensitivity for a BER of 10^-3 was a bit odd.  I assume that post-correction residual BER figures for modems with FEC would be used in the sensitivity figures when presented in the specs.

I believe that’s the case.  BER is certainly important and one needs to know where that break point is.  But it’s also important to understand that you can’t design a system to operate at the worst case 0% BER point.  The reason is that, with FEC, BER stays at 0% until the signal is so dirty that error correction can’t help it any more.  At that point, BER jumps up very quickly from 0% to 5% or more with just a dB or two of reduced C/I (Carrier to Interference ratio).  In other words, a 0% BER signal and a total unusable signal can be very, very close in C/I.  So, at the point where 0% BER is lost, you have little to no fade margin and your system will not be reliable.  In practice, the modulation fidelity value is monitored during such things as drive tests because it changes gradually as the signal quality gets worse.  That can help you determine the type of fade margin you need to build into your link budget.  Then, depending on the fade margin you need for your environment, you can then determine how much signal you need to stay away from the danger point.

 

On another point, I note that the UDR56K datasheet says the modulation types are FSK and GMSK.  I also know that the digital radio community is moving to PSK as a more reliable way to transmit higher bandwidths within the same spectrum.  I’m not a modulation engineer, but as I understand it, it’s evidently possible to switch more quickly and accurately between phases than it is to switch between frequencies, making for less bit/symbol errors.  I wonder if PSK, QPSK, etc. emission types are even allowed by our FCC Part 97 rules which govern ham radio.  Hmm… something to check.

 

Michael

N6MEF


Re: UDR56k-4 Sensitivity & BER

Darren Long <darren.long@...>
 

On 06/08/13 17:12, Michael E. Fox - N6MEF wrote:
 
It’s even worse than that, especially in the real world.  A 20% loss rate will cause enough retransmits that a cascade failure will occur.  In other words, for those 20% that must be retransmitted, 20% of those will need to be retransmitted again, and so on.  If the link is more than a single user occasionally checking his BBS for short messages, the link becomes worthless pretty quickly.  For example, if there are a 3-4 systems on the frequency, even at only 128 byte packets, the channel becomes hopelessly clogged in very short order.

 

Even your 10^-4 example shows 10% loss of just 128 byte packets.  Again, way too high for anything more than a single user talking to a single station.  So, 20% loss is NOT manageable for AX.25.  Not even 10%.


Around here in order to test anything I have to buy more radios and computers, there's no-one else to talk to.  That said, I'm interested in getting more radios :)

When we first deployed our BBS network, we performed real testing with 9600 baud TNCs (no FEC).  We were getting somewhere in the range of 5% to 10% packet loss at 9600 baud and 0% packet loss at 1200 baud.  (This was not a lab test.  This was between real sites using real antennas.)  Two different TNC brands were used and, yes, deviation was verified to be per manufacturer’s specs.  As a result, even with the higher baud rate, the effective throughput was lower on 9600 than on 1200 baud. 

Interesting, thanks for the info.  This was using Connected Mode AX.25 or TCP/IP over Disconnected Mode?

 

To think that one could go higher in speed and not make things even worse, is just not facing reality.  In *real* environments, with more than just one user talking to one other station at a time, the BER must be much higher (10^-5 to 10^-6) in order for the channel to not rapidly degrade due to cascading retransmits.  For any *real* environment, FEC is going to be essential. 


Agreed.  John Ronan, EI7IG, and I have been experimenting with Delay Tolerant Networks over ham radio links.  There is convergence layer support for Connected Mode AX.25 (implemented by yours truly) in the DTN2 reference implementation and a Nack Oriented Reliable Multicast (NORM) protocol convergence layer too, both of which seem useful.  We've never tried NORM over UDP/IP/UI-Frames on AX.25 yet, but John's been dabbling with it on D-STAR DD.  NORM's packet level erasure codes work well, but with some modest link layer FEC too I should think it would work very well.

The standard level for measuring receiver sensitivity in digital radios is 10^-5 BER.  Anyone who is familiar with P25 or DMR testing will be familiar with modulation fidelity vs. BER.  Those systems have error correction.  The modulation fidelity (measure of how accurately the symbols are being received) can degrade quite severely while still maintaining a 0% BER.  Without forward error correction, these systems would be unusable in any real environment. 


Sure.   This is why i thought quoting the sensitivity for a BER of 10^-3 was a bit odd.  I assume that post-correction residual BER figures for modems with FEC would be used in the sensitivity figures when presented in the specs.

I’d love to deploy the UDR56 on our BBSs that share a common forwarding frequency.  But without FEC, there’s just no way.  The result would be predictably terrible.

I hope that any new modems developed for the UDR56k are prototyped in gnuradio and/or implemented in a userspace soundmodem so that I can experiment with them.  I don't currently have a car and I'm not too tempted to buy 2 UDR56k  units to run at home, but I was thinking of getting one in the hope that all my old AX.25 kit would interoperate with it and that I could use my USRP or a soundmodem to try out any fancy new waveforms. 

I wonder what the minimum tx power level achievable with the UDR56k is?


Cheers,

Darren, G0HWW




Re: UDR56k-4 Sensitivity & BER

Darren Long <darren.long@...>
 

On 06/08/13 16:30, Bryan Hoyer wrote:
�

Hi Darren,


You are quite right. 10-3 is basically where AX25 falls apart as 1 error in 1000 prevents a 128 byte packet from ever getting through. So in a sense it is the limit of a usable channel for AX.25.

Those numbers are both preliminary and conservative. We will publish Eb/No curves after final characterization.

Jolly good.

On the other hand �even a little FEC would make this a usable channel.
Indeed.


We will be releasing our plans for future protocols at DCC in September.

I'll make sure to keep an eye on the proceedings.

Cheers,

Darren, G0HWW


Re: UDR56k-4 Sensitivity & BER

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

Darren,

 

It’s even worse than that, especially in the real world.  A 20% loss rate will cause enough retransmits that a cascade failure will occur.  In other words, for those 20% that must be retransmitted, 20% of those will need to be retransmitted again, and so on.  If the link is more than a single user occasionally checking his BBS for short messages, the link becomes worthless pretty quickly.  For example, if there are a 3-4 systems on the frequency, even at only 128 byte packets, the channel becomes hopelessly clogged in very short order.

 

Even your 10^-4 example shows 10% loss of just 128 byte packets.  Again, way too high for anything more than a single user talking to a single station.  So, 20% loss is NOT manageable for AX.25.  Not even 10%.

 

When we first deployed our BBS network, we performed real testing with 9600 baud TNCs (no FEC).  We were getting somewhere in the range of 5% to 10% packet loss at 9600 baud and 0% packet loss at 1200 baud.  (This was not a lab test.  This was between real sites using real antennas.)  Two different TNC brands were used and, yes, deviation was verified to be per manufacturer’s specs.  As a result, even with the higher baud rate, the effective throughput was lower on 9600 than on 1200 baud. 

 

To think that one could go higher in speed and not make things even worse, is just not facing reality.  In *real* environments, with more than just one user talking to one other station at a time, the BER must be much higher (10^-5 to 10^-6) in order for the channel to not rapidly degrade due to cascading retransmits.  For any *real* environment, FEC is going to be essential. 

 

The standard level for measuring receiver sensitivity in digital radios is 10^-5 BER.  Anyone who is familiar with P25 or DMR testing will be familiar with modulation fidelity vs. BER.  Those systems have error correction.  The modulation fidelity (measure of how accurately the symbols are being received) can degrade quite severely while still maintaining a 0% BER.  Without forward error correction, these systems would be unusable in any real environment. 

 

I’d love to deploy the UDR56 on our BBSs that share a common forwarding frequency.  But without FEC, there’s just no way.  The result would be predictably terrible.

 

Michael

N6MEF

 

 

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Darren Long
Sent: Tuesday, August 06, 2013 6:12 AM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] UDR56k-4 Sensitivity & BER

 

 

Hi all.

I was just reading the datasheet for the UDR56k-4 and noticed the receiver sensitivity figures:

Receiver Sensitivity, BER 10-3

•    4k8 -113 dBm

•    9k6 -110 dBm

•    56k -100 dBm


That BER of 10^-3 is pretty severe. According to my calcs in octave:

octave:10> ber = 10^-3
ber =  0.0010000
octave:11> ploss = (1-(1-ber)^(128*8))
ploss =  0.64103
octave:12> ploss = (1-(1-ber)^(256*8))
ploss =  0.87114
octave:13> ploss = (1-(1-ber)^(1500*8))
ploss =  0.99999

That's a 64% packet loss rate for 128 byte frames, 87% for 256 byte frames and almost 100% for a typical TCP/IP MTU.   Not a particularly good reference for planning link budgets, I wouldn't have thought.

A BER of 10^-4 looks to be a more useful baseline for a sensitivity figure:

octave:19> ber =  0.00010000
ber =  1.0000e-04
octave:20> ploss = (1-(1-ber)^(128*8))
ploss =  0.097336
octave:21> ploss = (1-(1-ber)^(256*8))
ploss =  0.18520
octave:22> ploss = (1-(1-ber)^(1500*8))
ploss =  0.69882

A ~20% loss rate would be manageable for say a reliable AX.25 connection mode link, but would kill TCP performance over an unreliable link.  NORM would cope OK, I've regularly seen it do well with >50% loss rates. 

I suppose the BER/(Eb/N0) curves for the modems in question would show how much margin one needed to get up to a BER of 10^e-4.  Would it be more useful to have the sensitivity figures quoted for a better BER?

What do you think?

Cheers,

Darren Long, G0HWW


Re: UDR56k-4 Sensitivity & BER

Bryan Hoyer <bhhoyer@...>
 

Hi Darren,

You are quite right. 10-3 is basically where AX25 falls apart as 1 error in 1000 prevents a 128 byte packet from ever getting through. So in a sense it is the limit of a usable channel for AX.25.

Those numbers are both preliminary and conservative. We will publish Eb/No curves after final characterization.

On the other hand  even a little FEC would make this a usable channel.

We will be releasing our plans for future protocols at DCC in September.

Cheers,
Bryan K7UDR

On Aug 6, 2013, at 6:12 AM, Darren Long <darren.long@...> wrote:

 

Hi all.

I was just reading the datasheet for the UDR56k-4 and noticed the receiver sensitivity figures:

Receiver Sensitivity, BER 10-3
•    4k8 -113 dBm
•    9k6 -110 dBm
•    56k -100 dBm

That BER of 10^-3 is pretty severe. According to my calcs in octave:

octave:10> ber = 10^-3
ber =  0.0010000
octave:11> ploss = (1-(1-ber)^(128*8))
ploss =  0.64103
octave:12> ploss = (1-(1-ber)^(256*8))
ploss =  0.87114
octave:13> ploss = (1-(1-ber)^(1500*8))
ploss =  0.99999

That's a 64% packet loss rate for 128 byte frames, 87% for 256 byte frames and almost 100% for a typical TCP/IP MTU.   Not a particularly good reference for planning link budgets, I wouldn't have thought.

A BER of 10^-4 looks to be a more useful baseline for a sensitivity figure:

octave:19> ber =  0.00010000
ber =  1.0000e-04
octave:20> ploss = (1-(1-ber)^(128*8))
ploss =  0.097336
octave:21> ploss = (1-(1-ber)^(256*8))
ploss =  0.18520
octave:22> ploss = (1-(1-ber)^(1500*8))
ploss =  0.69882

A ~20% loss rate would be manageable for say a reliable AX.25 connection mode link, but would kill TCP performance over an unreliable link.  NORM would cope OK, I've regularly seen it do well with >50% loss rates. 

I suppose the BER/(Eb/N0) curves for the modems in question would show how much margin one needed to get up to a BER of 10^e-4.  Would it be more useful to have the sensitivity figures quoted for a better BER?

What do you think?

Cheers,

Darren Long, G0HWW



UDR56k-4 Sensitivity & BER

Darren Long <darren.long@...>
 

Hi all.

I was just reading the datasheet for the UDR56k-4 and noticed the receiver sensitivity figures:

Receiver Sensitivity, BER 10-3
•    4k8 -113 dBm
•    9k6 -110 dBm
•    56k -100 dBm

That BER of 10^-3 is pretty severe. According to my calcs in octave:

octave:10> ber = 10^-3
ber =  0.0010000
octave:11> ploss = (1-(1-ber)^(128*8))
ploss =  0.64103
octave:12> ploss = (1-(1-ber)^(256*8))
ploss =  0.87114
octave:13> ploss = (1-(1-ber)^(1500*8))
ploss =  0.99999

That's a 64% packet loss rate for 128 byte frames, 87% for 256 byte frames and almost 100% for a typical TCP/IP MTU.   Not a particularly good reference for planning link budgets, I wouldn't have thought.

A BER of 10^-4 looks to be a more useful baseline for a sensitivity figure:

octave:19> ber =  0.00010000
ber =  1.0000e-04
octave:20> ploss = (1-(1-ber)^(128*8))
ploss =  0.097336
octave:21> ploss = (1-(1-ber)^(256*8))
ploss =  0.18520
octave:22> ploss = (1-(1-ber)^(1500*8))
ploss =  0.69882

A ~20% loss rate would be manageable for say a reliable AX.25 connection mode link, but would kill TCP performance over an unreliable link.  NORM would cope OK, I've regularly seen it do well with >50% loss rates. 

I suppose the BER/(Eb/N0) curves for the modems in question would show how much margin one needed to get up to a BER of 10^e-4.  Would it be more useful to have the sensitivity figures quoted for a better BER?

What do you think?

Cheers,

Darren Long, G0HWW


Serval "Mesh Extender" (WiFi to UHF packet)

"kb1tce" <shansen@...>
 

I'm a bit of a fan of mesh networking devices and we are now introducing the Village Telco "Mesh Potato" wireless telephony/data device to our county EMA.

That said, I ran across this on the FreedomBox mailing list. The Serval Project is a cousin to the Mesh Potato and uses open software to connect Android devices without the commercial infrastructure. The note below relates to the addition of 900 MHz UHF devices as range extenders for the 2.4 GHz mesh network. This is all Part 15 but I found the mix of 2.4 GHz WiFi and UHF to be interesting and something that might be relevant to this group. The bottom line of the note is an appeal for funding but there's enough meat to make it interesting.

FreedomBox, FYI, is a personal server development project intended to provide privacy.

Steve KB1TCE

Message: 3
Date: Tue, 9 Jul 2013 04:37:04 +0930
From: Paul Gardner-Stephen <paul@...>
To: freedombox-discuss <freedombox-discuss@...>
Subject: [Freedombox-discuss] Crowd-funding the Serval Mesh Extender
Message-ID:
<CA+_T8-AWOSZ1cUoFk1Vg+pVr9G1=Gjm87L5dgBD-jytV0hph_w@...>
Content-Type: text/plain; charset="iso-8859-1"

Hi All,

As some of you may already be aware we have been working on what we call the Mesh Extender at the Serval Project.

The Mesh Extender is a combined battery powered embedded Linux router and UHF packet radio running the Serval Mesh software (which is all GPL, see github.com/servalproject for the source).

It is intended for mobile and truly ad-hoc deployment where the end user just turns it on and uses it.

The idea is that it uses the UHF packet radio to mesh over greater
distances than is possible with Wi-Fi, the trade-off being lower bandwidth.

In general, we find that the UHF packet radio has a range of about 10x that of Wi-Fi when deployed indoors with omni-directional antennae. This means it has a range of about a block in a suburban or urban setting compared with Wi-Fi's range of about one house or apartment.

For example testing it in Boston recently we had coverage over much of the MIT campus from a single Mesh Extender in my room at a nearby hotel:

http://servalpaul.blogspot.com/2013/05/range-testing-mesh-extenders-in-boston.html
http://servalpaul.blogspot.com/2013/05/range-testing-serval-mesh-extender-on.html
http://servalpaul.blogspot.com/2013/05/crossing-charles-river-by-mesh-extender.html

Extending the range in this way is a critical enabler for the adoption of mesh communications because it removes the need for skilled installation and lowers the required penetration rate from near 100% in a local area if using un-aimed Wi-Fi to below 1%:

http://servalpaul.blogspot.com/2013/05/urban-testing-of-mesh-extender-part-1.html
http://servalpaul.blogspot.com/2013/05/urban-testing-of-mesh-extender-part-2.html

Combined with the always-on end-to-end encryption of voice calls and text messages of the Serval Mesh we think that this device has the potential to play a significant role in enabling distributed, resilient and private communications for people in a wide variety of situations.

We also see that the close alignment of what the Freedom Box and Serval Project are trying to achieve means that any device like this that we create could easily be adapted to being both a Mesh Extender and Freedom Box by adapting the included software inventory.

The necessity of a portable and trivial to deploy enabler of mesh
communications, and the need for this to be completely open, has led us to the current point where we have setup a crowd funding campaign to develop this technology, taking it from the prototype stage and to develop an actual manufacturable product, and do further testing with our humanitarian partners.

This is the point that our campaign at igg.me/at/speakfreely will take us to if fully funded.

But to realise the full potential of this we not only need to make an
attractive manufacturable device, but also to improve the open-source
firmware of the packet radios we are using to support true "ad-hoc packet radio" within the complex regulatory requirements of the ISM 915MHz band, in particular the need to frequency hop which presents interesting technical challenges for a fully distributed mesh that does not rely on GPS timing for synchronisation.

Achieving "ad-hoc packet radio" will require us to not only meet our
current funding goal, but stretch it by a factor of two.

We are conscious that achieving this will require promoting the campaign far and wide, possibly wider than the Serval team can achieve alone.

Therefore it would be tremendously helpful if as many of you as are willing and able would assist us in spreading the word as far and wide as possible. We would love to get slash-dotted and reddited off the net. Repeatedly.

So please take a look at our campaign, use the words below if they are
helpful, and help us to get the word out, and ultimately let's make
effective and private long-range mesh communications not only possible, but practical and easy for the general public so that they can enjoy the resilient backup communications capability that they need to keep connected, no matter what disaster may befall them.

Thanks in advance,

Dr. Paul Gardner-Stephen
Founder, Serval Project.

---

Serval crowd-funding Mesh Extenders to make mesh & disaster telephony go the next mile http://igg.me/at/speakfreely

Serval Project has been working for three years with New Zealand Red Cross on free and open technology, called the Serval Mesh, which can keep mobile phones operating when mobile networks fail, such as during disasters. We now want to take this technology out of the lab and get it into peoples hands. Find out more at http://igg.me/at/speakfreely

Twitter: @ServalProject


Re: [44net] hardware vs. software

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

 

56kbps (and above) AX.25 can operate without FEC.  

Not in the real world.  The required S/N and phase error levels required to achieve BER in the 10^-8 range at those speeds is simply not present at many/most sites. 

 

It is a matter of path loss and modem BER.  

 

Of course.  But what’s needed is not achievable to any practical degree at real world sites – at least not around here (Silicon Valley).  We did a lot of testing of AX.25 at 9600.   We tried several radios, several TNCs, measured BER, phase noise, deviation, etc.  In ideal locations, it worked fine.  But in real-world, everyday locations, we found that the increased number of retransmits caused by single bit errors in a packet size of 128 bytes to 256 bytes far, far outweighed the increase in baud rate from 1200 to 9600.  And yes, we set deviation carefully with calibrated service monitors.  Even the Kenwood D710 manual tells you that the received signal needs to be full scale on the meter or else 9600 isn’t going to work well.  And even with a strong enough signal, we have to worry about multi-path issues, particularly in urban environments. 

 

Our modems are designed to minimize BER and one may find that FEC is not required for a given network.

On the other hand, adding a protocol agnostic FEC in the modem is a possibility, exchanging raw bit rate for data correction.  We are interested in this capability and will be looking at use cases for it.

 

Well, if you consider the overall goal of getting as much throughput as possible between two sites, then even if the trade-off was 25%  reduction of the 56Kbps bandwidth in order to get 10^-8 BER, that’s still an enormous improvement over 9600 with no correction.  Seems like a no-brainer.   Add FEC:  I’ll take 8 please.  (Oh, right, pre-orders are closed.)  ;-)

 

Michael

N6MEF

 


Re: [44net] hardware vs. software

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

Michael,

I apologize if my reply wasn't what you expected.  The team has many tasks to complete before release of the UDR56k-4.  I answered with one, efficient, approach -- but it is not the only one.

You wrote:
"For example, assume I have four JNOS systems that are currently connected to
each other on a single subnet using a single 440 frequency.  They talk to
each other using IP over AX.25. I would definitely like to increase the
speed.  But it's not clear to me how I would deploy the UDR56K-4 to replace
the existing 440 radios/TNCs.  What protocol would it run, at what speed?
What would the IP network diagram look like?"

You could continue to do that using the UDR56k-4.  My supposition was that the equipment you currently use is not capable of the speeds available to the UDR56k-4.  If you are going to be replacing the TNCs and 440 radios with a UDR56k-4, then its possible to consider moving the JNOS service right into the radio, saving power and space, which is what I was describing -- however, you don't have to use it in that manner.  (See below)

On Sun, Jul 7, 2013 at 10:20 PM, Michael E. Fox - N6MEF <n6mef@...> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Thanks John,

But that wasn't my question.  If you re-read my question, you'll see that
the JNOS machines, network, radios, TNCs, etc. already exist.

The question was how to deploy the UDR56K-4 in a 56K bridge configuration on
a shared subnet to replace the existing 440 radios and TNCs.  For example,
some other technologies, like Icom's ID-1, only operate in a point-to-point
configuration (as far as I know).  That's why I asked about the shared
subnet.  Also, merely speeding up AX.25 to 56kbps isn't going to work unless
forward error correction is added.  Hence, part of my question was about
what protocol would be used.

While it was not mentioned in your earlier question, if you wish to run in an bridge manner, you have two options (and possibly a third):
  • Use IP over AX.25
  • Use Ethernet over D-STAR DD Mode 
(in the future there may be a lower overhead protocol).

56kbps (and above) AX.25 can operate without FEC.  It is a matter of path loss and modem BER.  Our modems are designed to minimize BER and one may find that FEC is not required for a given network.
On the other hand, adding a protocol agnostic FEC in the modem is a possibility, exchanging raw bit rate for data correction.  We are interested in this capability and will be looking at use cases for it.

At initial release, we will be delivering those capabilities listed on our information sheet at http://groups.yahoo.com/group/UniversalDigitalRadio/files/insert.pdf 

Since this device is flexible by design, new capabilities can be added at any time, either by us or other developers.  We believe this is a good investment value for our prospective customers.


Everything I've read so far, including your answer below, indicates to me
that the UDR56K-4 is really an experimenter's platform, and the end solution
is left to the user to figure out.  In other words, you're providing a linux
hardware platform with an integrated 440 radio.  That's cool.  But if the
solution I need is a 56K bridge, it sounds like it's up to me to find a
protocol with FEC that is allowed by the FCC, then find the source code,
compile it, test it, then somehow connect that to an IP routing or bridging
configuration in linux.  Am I interpreting the situation correctly?


We will be providing pre-provisioned applications for the UDR56k-4, some of those will be focused on EmComm data users, some on positional awareness users (e.g. APRS), and some on Digital Voice users.  For those applications, its configure and run.

We will also be providing application notes, e.g. "solution 'oriented' documentation" as the product is released.  This will include "bridging" solutions.

Unfortunately, we cannot engineer each user's unique application or solution.  We will provide information that will help various teams and individuals to engineer their own solution.

The intent of this mailing list "UniversalDigitalRadio" is a place to exchange that type of information between users with input from our team.

Right now our team is most focused on delivering a quality product with multiple capabilities.

 
Thanks,
Michael
N6MEF


-----Original Message-----
From: 44net-bounces+n6mef=mefox.org@...
[mailto:44net-bounces+n6mef=mefox.org@...] On Behalf
MIchael,

I don't have time right now to test, but JNOS2 compiles from source on the
UDR56k-4 as does jnosinstaller.  The installer configures the program just
fine.

Barring any unforeseen issues, you should be able to run JNOS directly on
the radio.  If you have TNCs servicing local LANs (e.g. 2 meters, 220, ...),
you can put USB-to-Serial interfaces on the UDR56k-4 and attach the TNCs
with their current radios. No other computer would be required.  We have
tested TNCs attached in this manner on other applications for over a year
(daily).  The four UDR56k-4s would form your backbone radios.  AX.25 drivers
are already in place to drive the UDR56k-4 at any supported speed including
9600-baud to over 56k baud (with some steps in between).  You would use a
CIDR of /29 if these were the only radios on your backbone LAN.

This is an open architure/system so bring your favorite applications (Linux
source or Linux ARMEL binaries) to the radio.  If your application is more
appropriate to run on another computer, use the UDR56k-4 as a relay device,
using an IP interface (wired or wireless).

Further discussion on the UniversalDigitalRadio forum on Yahoo! Groups.


Re: [44net] hardware vs. software

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

MIchael,

I don't have time right now to test, but JNOS2 compiles from source on the UDR56k-4 as does jnosinstaller.  The installer configures the program just fine.

Barring any unforeseen issues, you should be able to run JNOS directly on the radio.  If you have TNCs servicing local LANs (e.g. 2 meters, 220, ...), you can put USB-to-Serial interfaces on the UDR56k-4 and attach the TNCs with their current radios. No other computer would be required.  We have tested TNCs attached in this manner on other applications for over a year (daily).  The four UDR56k-4s would form your backbone radios.  AX.25 drivers are already in place to drive the UDR56k-4 at any supported speed including 9600-baud to over 56k baud (with some steps in between).  You would use a CIDR of /29 if these were the only radios on your backbone LAN.

This is an open architure/system so bring your favorite applications (Linux source or Linux ARMEL binaries) to the radio.  If your application is more appropriate to run on another computer, use the UDR56k-4 as a relay device, using an IP interface (wired or wireless).

Further discussion on the UniversalDigitalRadio forum on Yahoo! Groups.



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


On Sat, Jul 6, 2013 at 9:15 AM, Michael E. Fox - N6MEF <n6mef@...> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
John,

I'm glad you're on this list.  Didn't realize that.

I've look and found no "solution" oriented documentation -- i.e. how can I
use the device?  All of the information about the internals, like "socket
interfaces" may have meaning for some.  But, since I don't write protocol
internals, it doesn't help me understand the deployment scenarios.

For example, assume I have four JNOS systems that are currently connected to
each other on a single subnet using a single 440 frequency.  They talk to
each other using IP over AX.25.  I would definitely like to increase the
speed.  But it's not clear to me how I would deploy the UDR56K-4 to replace
the existing 440 radios/TNCs.  What protocol would it run, at what speed?
What would the IP network diagram look like?

If this question is not appropriate for the 44-list, we can move it to your
yahoo group.

Thanks much,
Michael
N6MEF

-----Original Message-----
From: 44net-bounces+n6mef=mefox.org@...
[mailto:44net-bounces+n6mef=mefox.org@...] On Behalf Of K7VE -
John
Sent: Friday, July 05, 2013 11:02 PM
To: AMPRNet working group
Subject: Re: [44net] hardware vs. software

(Please trim inclusions from previous messages)
_______________________________________________
BTW -- the modems in the UDR56k-4 are DSP to I/Q modulation/demodulation and
run on the included Linux card.  The intent is to have flexibility in
modems, protocols, and applications and provide an open source environment
for the experimenters in the user community.

The modems, and protocol stacks, will be available on socket interfaces, so
protocols and applications may run either on the radio's embedded system or
via interconnection to another host.

By having on-board processing we also are looking at very low tx/rx
turnaround time,  well below what could be done on a USB or serial port.

One application is using the device as an 'Ethernet Bridge' within a given
protocol, modem, and data rate.

Oh, and the price is a 3rd less than Bill posted :)



Re: [44net] hardware vs. software

K7VE - John <john@...>
 

MIchael,

I don't have time right now to test, but JNOS2 compiles from source on the UDR56k-4 as does jnosinstaller.  The installer configures the program just fine.

Barring any unforeseen issues, you should be able to run JNOS directly on the radio.  If you have TNCs servicing local LANs (e.g. 2 meters, 220, ...), you can put USB-to-Serial interfaces on the UDR56k-4 and attach the TNCs with their current radios. No other computer would be required.  We have tested TNCs attached in this manner on other applications for over a year (daily).  The four UDR56k-4s would form your backbone radios.  AX.25 drivers are already in place to drive the UDR56k-4 at any supported speed including 9600-baud to over 56k baud (with some steps in between).  You would use a CIDR of /29 if these were the only radios on your backbone LAN.

This is an open architure/system so bring your favorite applications (Linux source or Linux ARMEL binaries) to the radio.  If your application is more appropriate to run on another computer, use the UDR56k-4 as a relay device, using an IP interface (wired or wireless).

Further discussion on the UniversalDigitalRadio forum on Yahoo! Groups.



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


On Sat, Jul 6, 2013 at 9:15 AM, Michael E. Fox - N6MEF <n6mef@...> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
John,

I'm glad you're on this list.  Didn't realize that.

I've look and found no "solution" oriented documentation -- i.e. how can I
use the device?  All of the information about the internals, like "socket
interfaces" may have meaning for some.  But, since I don't write protocol
internals, it doesn't help me understand the deployment scenarios.

For example, assume I have four JNOS systems that are currently connected to
each other on a single subnet using a single 440 frequency.  They talk to
each other using IP over AX.25.  I would definitely like to increase the
speed.  But it's not clear to me how I would deploy the UDR56K-4 to replace
the existing 440 radios/TNCs.  What protocol would it run, at what speed?
What would the IP network diagram look like?

If this question is not appropriate for the 44-list, we can move it to your
yahoo group.

Thanks much,
Michael
N6MEF

-----Original Message-----
From: 44net-bounces+n6mef=mefox.org@...
[mailto:44net-bounces+n6mef=mefox.org@...] On Behalf Of K7VE -
John
Sent: Friday, July 05, 2013 11:02 PM
To: AMPRNet working group
Subject: Re: [44net] hardware vs. software

(Please trim inclusions from previous messages)
_______________________________________________
BTW -- the modems in the UDR56k-4 are DSP to I/Q modulation/demodulation and
run on the included Linux card.  The intent is to have flexibility in
modems, protocols, and applications and provide an open source environment
for the experimenters in the user community.

The modems, and protocol stacks, will be available on socket interfaces, so
protocols and applications may run either on the radio's embedded system or
via interconnection to another host.

By having on-board processing we also are looking at very low tx/rx
turnaround time,  well below what could be done on a USB or serial port.

One application is using the device as an 'Ethernet Bridge' within a given
protocol, modem, and data rate.

Oh, and the price is a 3rd less than Bill posted :)


_________________________________________
44Net mailing list
44Net@....edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html


Re: WL2K Client

Mark L Friedlander <marklfriedlander@...>
 

Thanks Bryan.

73 Mark KV4I



On Sat, Jun 29, 2013 at 10:12 AM, k7udr <bhhoyer@...> wrote:
 



Hi Mark



--- In UniversalDigitalRadio@..., "marklfriedlander" wrote:
>
> I have some questions about Winlink on the UDR56K.
>
> 1) Is the UDR56K capable of performing as a Winlink 2000 UHF client without the need to add a soundcard or TNC?

Yes;

The UDR has Paclink-UNIX installed, which allows for Client connectivity to RMS Gateways and Peer to Peer.

Paclink-UNIX supports IMAP, so you can use any email Client such as Outlook, Thunderbird, Applemail etc. to compose or read your mail.


> 2) Does the Linux implementation of the WL2K software on the UDR56K include WINMOR? If so, can the UDR56K be interfaced via a USB port to an external sound device (such as a Signalink) connected to an HF radio?

No;

Although I have heard rumors of a Linux version of Winmor being developed, I beleive it requires a FPU which we do not have.

Cheers,
Bryan

> Thanks,
> Mark KV4I
>



Re: WL2K Client

"k7udr" <bhhoyer@...>
 

Hi Mark

--- In UniversalDigitalRadio@..., "marklfriedlander" <marklfriedlander@...> wrote:

I have some questions about Winlink on the UDR56K.

1) Is the UDR56K capable of performing as a Winlink 2000 UHF client without the need to add a soundcard or TNC?
Yes;

The UDR has Paclink-UNIX installed, which allows for Client connectivity to RMS Gateways and Peer to Peer.

Paclink-UNIX supports IMAP, so you can use any email Client such as Outlook, Thunderbird, Applemail etc. to compose or read your mail.

2) Does the Linux implementation of the WL2K software on the UDR56K include WINMOR? If so, can the UDR56K be interfaced via a USB port to an external sound device (such as a Signalink) connected to an HF radio?
No;

Although I have heard rumors of a Linux version of Winmor being developed, I beleive it requires a FPU which we do not have.

Cheers,
Bryan

Thanks,
Mark KV4I


WL2K Client

"marklfriedlander" <marklfriedlander@...>
 

I have some questions about Winlink on the UDR56K.

1) Is the UDR56K capable of performing as a Winlink 2000 UHF client without the need to add a soundcard or TNC?

2) Does the Linux implementation of the WL2K software on the UDR56K include WINMOR? If so, can the UDR56K be interfaced via a USB port to an external sound device (such as a Signalink) connected to an HF radio?

Thanks,
Mark KV4I


Re: Hailing channel and intermodulation suppression

John Lloyd <lloyd@...>
 

Tom,

Use a couple of good UHF bandpass cavities, at least 4" diameter in series with the UDR56K to the antenna. Tune them to the simplex frequency that you will be using. This will protect most problems for both your receive as well as transmit and others on the site.

John Lloyd, K7JL



Tom Hayward wrote:

Another thought... Maybe the power density is low enough that we won't
bother anyone with intermodulation interference. Would still need to
convince the site manager of this.

Tom KD7LXL

On Mon, Jun 24, 2013 at 9:24 AM, Tom Hayward <esarfl@...
<mailto:esarfl%40gmail.com>> wrote:
> On Sat, Jun 22, 2013 at 10:42 AM, siegfried jackstien
> <siegfried.jackstien@...
<mailto:siegfried.jackstien%40freenet.de>> wrote:
>>
>> Repeater builders use a highpass lowpass combination (procom 70/6 or
>> similar) to transmit and receive on the same antenna ... now my
rough guess
>> is that you could add such a filter to your antenna input and can
transmit
>> on one frequency without desensing on the other frequency
>
> Sorry for the delayed response. I was away from Internet all weekend.
>
> The problem is not desense. The UDR56K is half-duplex so I don't need
> to worry about desensing the receiver during transmit. And all the
> other receivers on the site have bandpass filters so that is not an
> issue. The problem I am trying to prevent is signals from nearby
> transmitters mixing in the final amplifier of the UDR56K and causing
> intermodulation interference. This is accomplished by using an
> isolator/circulator to send any signal coming down the antenna into a
> dummy load before it reaches the UDR's amplifier. Every
> isolator/circulator I am familiar with has a very narrow bandwidth, so
> by implementing this technique I would sacrifice the frequency agility
> of the UDR56K, the integral feature of "A Hailing Channel for Packet
> Radio".
>
> Tom KD7LXL


Re: Hailing channel and intermodulation suppression

Tom Hayward <esarfl@...>
 

Another thought... Maybe the power density is low enough that we won't
bother anyone with intermodulation interference. Would still need to
convince the site manager of this.

Tom KD7LXL

On Mon, Jun 24, 2013 at 9:24 AM, Tom Hayward <esarfl@...> wrote:
On Sat, Jun 22, 2013 at 10:42 AM, siegfried jackstien
<siegfried.jackstien@...> wrote:

Repeater builders use a highpass lowpass combination (procom 70/6 or
similar) to transmit and receive on the same antenna ... now my rough guess
is that you could add such a filter to your antenna input and can transmit
on one frequency without desensing on the other frequency
Sorry for the delayed response. I was away from Internet all weekend.

The problem is not desense. The UDR56K is half-duplex so I don't need
to worry about desensing the receiver during transmit. And all the
other receivers on the site have bandpass filters so that is not an
issue. The problem I am trying to prevent is signals from nearby
transmitters mixing in the final amplifier of the UDR56K and causing
intermodulation interference. This is accomplished by using an
isolator/circulator to send any signal coming down the antenna into a
dummy load before it reaches the UDR's amplifier. Every
isolator/circulator I am familiar with has a very narrow bandwidth, so
by implementing this technique I would sacrifice the frequency agility
of the UDR56K, the integral feature of "A Hailing Channel for Packet
Radio".

Tom KD7LXL


AW: Hailing channel and intermodulation suppression

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

These filters are also available as a single bandpass (with several cavities
in a row) ... so ... would that prevent other transmitter signals from
coming down back in the pa??? (isolator would help ... just asking if such a
bandpass would also help??)

Dg9bfc

Sigi

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...] Im Auftrag von Tom Hayward
Gesendet: Montag, 24. Juni 2013 16:24
An: UniversalDigitalRadio@...
Betreff: Re: [UniversalDigitalRadio] Hailing channel and intermodulation
suppression



On Sat, Jun 22, 2013 at 10:42 AM, siegfried jackstien
<siegfried.jackstien@... <mailto:siegfried.jackstien%40freenet.de>
wrote:

Repeater builders use a highpass lowpass combination (procom 70/6 or
similar) to transmit and receive on the same antenna ... now my rough
guess
is that you could add such a filter to your antenna input and can
transmit
on one frequency without desensing on the other frequency
Sorry for the delayed response. I was away from Internet all weekend.

The problem is not desense. The UDR56K is half-duplex so I don't need
to worry about desensing the receiver during transmit. And all the
other receivers on the site have bandpass filters so that is not an
issue. The problem I am trying to prevent is signals from nearby
transmitters mixing in the final amplifier of the UDR56K and causing
intermodulation interference. This is accomplished by using an
isolator/circulator to send any signal coming down the antenna into a
dummy load before it reaches the UDR's amplifier. Every
isolator/circulator I am familiar with has a very narrow bandwidth, so
by implementing this technique I would sacrifice the frequency agility
of the UDR56K, the integral feature of "A Hailing Channel for Packet
Radio".

Tom KD7LXL



Re: Hailing channel and intermodulation suppression

Tom Hayward <esarfl@...>
 

On Sat, Jun 22, 2013 at 10:42 AM, siegfried jackstien
<siegfried.jackstien@...> wrote:

Repeater builders use a highpass lowpass combination (procom 70/6 or
similar) to transmit and receive on the same antenna ... now my rough guess
is that you could add such a filter to your antenna input and can transmit
on one frequency without desensing on the other frequency
Sorry for the delayed response. I was away from Internet all weekend.

The problem is not desense. The UDR56K is half-duplex so I don't need
to worry about desensing the receiver during transmit. And all the
other receivers on the site have bandpass filters so that is not an
issue. The problem I am trying to prevent is signals from nearby
transmitters mixing in the final amplifier of the UDR56K and causing
intermodulation interference. This is accomplished by using an
isolator/circulator to send any signal coming down the antenna into a
dummy load before it reaches the UDR's amplifier. Every
isolator/circulator I am familiar with has a very narrow bandwidth, so
by implementing this technique I would sacrifice the frequency agility
of the UDR56K, the integral feature of "A Hailing Channel for Packet
Radio".

Tom KD7LXL


AW: Hailing channel and intermodulation suppression

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

Repeater builders use a highpass lowpass combination (procom 70/6 or
similar) to transmit and receive on the same antenna ... now my rough guess
is that you could add such a filter to your antenna input and can transmit
on one frequency without desensing on the other frequency

Dg9bfc

Sigi

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...] Im Auftrag von Tom Hayward
Gesendet: Samstag, 22. Juni 2013 03:34
An: UniversalDigitalRadio@...
Betreff: [UniversalDigitalRadio] Hailing channel and intermodulation
suppression



I'm trying to embrace the concept of A Hailing Channel for Packet
Radio, but I've run into an engineering roadblock. I am assuming the
"hailing channel" will be something like 440.800 MHz APRS, and the 56k
data transfer channel will be 430.9 MHz. These are 10 MHz apart. How
can I support this on a crowded site that requires a [normally low
bandwidth] intermodulation suppression panel (isolator / low pass
filter)?

With the independent TX/RX connector option, is the internal TX/RX
relay preserved? I'd hate to try to implement an external TX/RX relay
with <10ms turnaround time.

Tom KD7LXL