Date
1 - 4 of 4
[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:
|
|
|
|
"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:
|
|
|
|
"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 toeach 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:
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):
(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.
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 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
|
|
|