Re: PHY Layer Protocols

Marshall Denny <MarshallDenny@...>

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 modes could start with strong FEC and then switch to low FEC or no FEC based on conditions of the specific link.

In general, consider using "and" rather than "or" in these types of situations, we have the potential of a lot more flexibility today than in the past.  

The memory available in a  raspberry pi compared to a TNC of the past is the difference between night and day.

Marshall Denny
Technical Architect, Contractor
425 288 6443 office
206 842 9305 home
206 734 9242 cell

Politicians and diapers should be changed frequently and for the same reason.
-- unknown

On Tue, Mar 3, 2015 at 7:56 AM, myyahoo@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

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 talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...

You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!

As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.

- Richard, VE7CVS

Join to automatically receive all group messages.