Since we have the source, it should be possible to add the bad-bit correction that's been successfully implemented in both UZ7HO and DIRE WOLF software modems. Also there's the FX25 project adding

True. But the problem is, many (most?) “real world” channels in a metro area (<25 miles) are NOT “nearly loss-less”. On many (most?) real-world channels, you will get single bit errors,

I am just lurking in this group, but consider

Consider that we could have multiple levels of FEC including none with the receiver being able to decode any of the available options. 1. UI/UDP broadcast could use strong FEC 2. Initial connection

D-STAR does use FEC in the AMBE sub-frames, but it was not specified for the entire packet or payload. The D-STAR Data (DD) implementation simply wraps Ethernet frames and does not have FEC. --

>Otherwise, I must assume that you have a Raspberry Pi situation. What's wrong with the Raspberry Pi? The best I can tell, this sums it up well, and I don't see a real problem:

This is a good topic and deserves it's own thread. First off NW Digital Radio is a for profit corporation. We design and manufacture HW and sell it with adequate margins to keep us doing it in the

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were

[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote: Allowing us to see the source isn't terribly useful. To do great things, we need the code to come with a license that allows

--- John Hays K7VE wrote: > Some components, e.g. the AMBE-3000 chip, > are protected intellectual property ... I understand, and I really don't care. I won't use it. I can use Codec2 instead. By the

--- John Hays K7VE wrote: >Raw TCP/IP packets will need some kind > of synchronization training sequence at > the beginning. Right. Each lower layer wraps the previous upper layer in its own header

Different people have different definitions of these terms. Here is our vision. NW Digital Radio builds hardware. We depend on many outside software developers, mostly open source, to support our

Ken, Raw TCP/IP packets will need some kind of synchronization training sequence at the beginning. Right now we have two Amateur protocols that provide framing around TCP/IP and handle the

How open/free will the platform be? Will I be able to port OpenBSD, compile all of the device drivers, and have the computer/radio run on OpenBSD instead of Linux? (Requiring GPL for some software is

--- Michael E Fox - N6MEF wrote: > The UDRX-440 functions as either a layer 2 bridge or a layer 3 router. I'm interested only in TCP/IP, not AX.25 or D-Star. So I have the same question. If the radio

That was fun... Just rediscovered the "NW DIgital Radio" Facebook group and invited a hundred or so of my closest ham friends.. That's one little step toward moving beyond the 20th

I had a similar experience when, several years ago, we had a nasty windstorm that nailed the power grid and it was lights out for 5 days. That's when I realized that Ham Radio with APRS was THE

1.5 billion earthlings find social networks a bit more interesting.. Compare that to the 15 or so folks still on packet radio.. The multi-media multi-mode communications web application (Facebook

A few years ago, there was a crash at the National Championship Air Races in Reno, NV, injured dozens, killed a few. I wasn't there... I was 10 miles away at the time; Yet, the cell network was down,

Amateur radio was/is portable/mobile/base station radios giving those who can pass an exam the capability to talk across town or around the world using voice and data. No infrastructure required.