All high-latency modes are unsuitable for ARQ.

A persistent misconception is that you would be using signals near the noise 
level.
As I have stated many times, noise is hardly ever the problem unless it is S8.
The problem is multi-path causing QSB (up to 80 dB on path we are using) and 
QRM from other 
stations firing up their gear on top of your QSO. 

PSkmail arq takes care of this very well by repeating the stuff that has been 
unreadable in the qsb.
QRN is taken care of by automatically shortening of the packets when the error 
rate goes up, which 
decreases the chance of a packet being hit.

Again, noise is seldom the problem, we pick a better path if necessary, 
depending on time of day.
Signal levels are normally around S5-S9 here in EU, depending on time/distance.

73,

Rein EA/PA0R/P on a campsite in Spain

(3 years experience with PSK63ARQ (2005), PSK125ARQ(2006) and 
PSK250ARQ(2007,2008).

> -----Ursprüngliche Nachricht-----
> Von: digitalradio@yahoogroups.com
> Gesendet: 02.03.08 18:52:31
> An: digitalradio@yahoogroups.com
> Betreff: Re: [digitalradio] Re: Keeping NBEMS in mind


>  
>  
>  
> 
> I can see that some digital modes would not work very well for ARQ that 
> is decoded in real time. MT-63 and MFSK16 both have latency due to their 
> design. I am surprised that MFSK16 was considered, but perhaps this was 
> due to being the most narrow mode that also can work very deep into the 
> noise?
> 
> Olivia is so very slow relative to the bandwidth, that I would not think 
> of it as a good candidate. The one mode that seems to be a ready made 
> mode for this kind of communication is FAE400 since it already is an ARQ 
> mode and is reasonably narrow for its throughput. This is the best mode 
> I have ever used for an ARQ sound card solution, especially considering 
> how narrow it is for the sensitivity and speed. Alternatively, couldn't 
> the ALE400 mode be incorporated into the NBEMS system since it would 
> then become an ARQ mode, although would work differently than FAE400 and 
> perhaps not as fast?
> 
> One thing I don't follow completely with Skip is the idea that you need 
> all these signals on one waterfall. I would never tune in a signal very 
> far off from my sweet spot on my rig (varies depending upon rig design) 
> and normally want digital modes to be centered on 1500 Hz in order to be 
> able to use the filtering available to me. It can make a big difference 
> in difficult conditions or when very strong signals or splattering 
> signals are close in.
> 
> If we had an emergency situation, it seems to me that you would not be 
> having multiple streams of different stations sending data. Especially 
> not for e-mail capability. It may be difficult to even find more than 
> one or two stations that you can connect to and who have a computer 
> interfaced with their rig with the NBEMS program suite installed and 
> know how to use it. Once you were able to find someone, you would likely 
> want to work with them (assuming a savvy operator, no different than 
> other modes), and route your traffic in that manner. They could 
> coordinate with others outside the disaster area and have them come up 
> on frequency as needed for relief.
> 
> One thing that has concerned me here in the U.S., is the near total lack 
> of interest in developing some method of using voice intermixed with 
> text data, the very thing we most need for emergency communications. 
> While we can legally do it under the Part 97 rules on 160 meters and on 
> 6 meters and up, the bandplans do not reflect that.
> 
> Why do so few support this capability? It is used everyday by the SSTV 
> and hams doing large data transfers of this type. Maybe we could at 
> least use it on VHF? But I have not found a common frequency in the 
> bandplans.
> 
> As far as the wide bandwidth and faster modes such as RFSM, this could 
> work under some conditions. Tremendously faster than the NBEMS system, 
> although it does not have the fall back to the weaker signals and 
> requires better signals than what is normally required for very weak 
> SSB. Has anyone done any further testing on VHF with RFSM? It is 
> completely legal to do so here in the U.S. on 6 meters and up.
> 
> As Andy points out, there are times when the ARQ text digital modes 
> don't work at all, but with FAE400 this seems like much less of a 
> problem considering that it may be able to perform better than PSK31 
> without ARQ.
> 
> 73,
> 
> Rick, KV9U
> 
> Andrew O'Brien wrote:
> >
> > NBEMS is the software package, not an actual mode. It includes PSK31,
> > PSK63, PSK 125, PSK250, MFSK16 and RTTY. MT63 and Olivia are not
> > offered. One primary goal for this software is "high" speed message
> > transfers on VHF and UHF where something like PSK250 can be used with
> > good outcome. On HF, the noise level does not usually support the
> > higher speed PSK operations but PSK31 and PSK63 do quite well on HF. 
> > The software uses ARQ ... the message is sent, the other stations
> > sends an acknowledgment from time to time. If there was a error (due
> > to no decode of a weak signal for example) the section of the message
> > would be repeated until the station acknowledges receipt. Thus the
> > transfer rate can be slow but the text/copy will be 100% if the files
> > xfer is successful.
> >
> > While Olivia and MT63 are vastly superior to PSK31 under most weak
> > signal situations, the ARQ aspects of NBEMS will make it more reliable
> > if accuracy is what you desire.
> >
> > ALE 400 and RFSM-8000 offer alternatives . ALE-400 is available in
> > Multipsk but is not widely used. RFSM is even less used and some baud
> > rates are not legal for USA amateurs to use. I believe the authors of
> > NBEMS had a goal of facilitating the accurate transfer of messages via
> > methods widely used by hams in everyday application. Thus PSK and
> > RTTY, very commonly used. While they will not perform as "well" as
> > ALE 400, RSFM 8000, Winlink, Pactor II, III, in some circumstances, 
> > the expectation is that a PSK based NBEMS system will make up for it's
> > lack of sophisticated modulation schemes via its accuracy and
> > simplicity. 
> >
> > One observation to keep in mind...when I have used NBEMS and have been
> > receiving files via PSK31 ARQ , the received text in VBdigi (without
> > ARQ) is almost always as good as the ARQ PSK via FLARQ. Most of the
> > digital modes under average conditions will give you the ability to
> > send a highly accurate message. NBEMS, ALE 400 and RSFM offer the
> > "comfort" that it will be 100% accurate if the file transfer is
> > completed. Thus, in theory , if that emergency message you intercept
> > says "my latitude is 40.0446" and Olivia decodes it as 49.0046 , we
> > have a problem. The error correction in NBEMS and ALE400 will ensure
> > it is accurate. The dilemma: Under bad conditions you might get 
> > perhaps 70% of a message in Olivia with several errors, while under
> > the same bad conditions you may only get 30% using PSK, ALE 400 or
> > RSFM (hypothetical numbers) and not enough to complete the file transfer. 
> >
> >
> >
> > 
> 
>   
>  
> 

-- 
http://pa0r.blogspirit.com


Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/sked

Check our other Yahoo Groups....
http://groups.yahoo.com/group/dxlist/
http://groups.yahoo.com/group/contesting
http://groups.yahoo.com/group/themixwgroup
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/digitalradio/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[EMAIL PROTECTED] 
    mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

Reply via email to