Date   

Re: NBEM Presentation Materals

"woodtownuk" <G3TXL@...>
 

--- In NBEMSham@yahoogroups.com, "radioguy340" <kb9ymd@...> wrote:
Does anyone have a PowerPoint
presentation developed?
Hah! That's the easy bit! What I want to know (and please see my
earlier posts - which no-one seems to have bothered to reply to!) is
does this - apart from using a _really_ good VHF/UHF circuit - really
work?

Guys I know (who know a thing - or two, about PSK & ARQ) say it's a
absolute non-starter on HF!

So?!

Angus Graham


NBEM Presentation Materals

"radioguy340" <kb9ymd@...>
 

I am new to the group and have just started reading the available
materials on the Host WEB site and this group site. I would like to
put together a presentation on the Narrow Band Emergency Messaging
System for the McHenry County IL RACES/ARES members along with a simple
demonstration using two HT's. . Does anyone have a PowerPoint
presentation developed?

Thanks AL


Re: ARQ PSK-xxx

"woodtownuk" <G3TXL@...>
 


ARQ PSK-xxx

"woodtownuk" <G3TXL@...>
 

Hi all,

I only wanted to play radio, but after a recent abortive post here to
find an _active_ 'radiomate' here in the UK, I posted on the UK 5 MHz
NVIS 'Experiment' reflector. Good idea I thought at the time...

However, looks very much like the beginning of the 'Night of the Long
Anoraks' to me, but - with the greatest respect - please would the
software authors (and members) look at the replies to my original
frivolous(??) posting?


*****My original posting*****

Looking for new horizons? :o))

I would like to have a mini-trial (definitely non-scientific -
strictly no SINPOs) using ARQ PSK-31/63/125/250 (be warned - Peter M
thinks it 'fuzzy' ARQ) before I suggest to others (in our group) to
have a play with it.

See: http://www.w1hkj.com/NBEMS/

Ideally, you will have a telephone, be NVIS-savvy, have a GSOH and be
within a few hundred km of Plymouth :o))

...and I'm waiting to hear from you!

Angus Graham


*****First reply*****

From G3PLX:

I have to correct Angus. I did not use the term 'fuzzy' when
describing ARQ
PSK. The term 'fuzzy', in this context usually refers to the type of logic
used (i.e. majority logic). The ARQ system that Angus wants to trial
doesn't
use 'fuzzy' logic.

The 'ARQ' system in question works by using any existing method of
transmitting ASCII over a noisy channel, with checksums to detect and
repeat
faulty blocks. Angus proposes using PSK31 (and higher speed versions
of this
mode) on 5MHz channels.

My comments to Angus were that the variable-length alphabet used within
PSK31 is not suitable for ARQ implemented in this way. For example, if the
raw datastream over the air suffers a single-bit error in the gap between
two characters, two good characters are replaced by one bad one.
Similarly,
an error in the middle of a character can split it into two bad ones. This
is no big deal in human-readable text, but will screw up any automated
process. To do ARQ properly, a constant-length coding scheme would be
needed. The proposed ARQ system would probably work better if the raw
ASCII
was transmitted over the air!

I therefore suggested to Angus that this scheme may not work as well as
expected. It was Angus, not me, that used the term 'fuzzy' to describe
this
prognosis.

73
Peter M


*****2nd Reply*****

Peter

The 'ARQ' system in question works by using any existing method of
transmitting ASCII over a noisy channel, with checksums to detect
and repeat
faulty blocks. Angus proposes using PSK31 (and higher speed versions
of this
mode) on 5MHz channels.

My comments to Angus were that the variable-length alphabet used within
PSK31 is not suitable for ARQ implemented in this way. For example,
if the
raw datastream over the air suffers a single-bit error in the gap
between
two characters, two good characters are replaced by one bad one.
Similarly,
an error in the middle of a character can split it into two bad
ones. This
is no big deal in human-readable text, but will screw up any automated
process. To do ARQ properly, a constant-length coding scheme would be
needed. The proposed ARQ system would probably work better if the
raw ASCII
was transmitted over the air!

I therefore suggested to Angus that this scheme may not work as well as
expected. It was Angus, not me, that used the term 'fuzzy' to
describe this
prognosis.

I am not sure a constant length coding scheme is needed. The variable
length coding is simply compression, making the packet contain binary
data rather than ascii data.

To make such a scheme work you need three components -

- Compression method

- Length field (which must be protected by the checksum)

- Suitably robust checksum (with a burst error protection larger that
the expected burst length.

A good checksum to look at for this would be the Fletcher Checksum used
to protect the OSI CLNS transport protocol TP4.

The simplest way to encode the length (one byte) and checksum (2 bytes)
is probably as a six byte ASCII string, by convention added to the
beginning of the packet. The resultant packet can then be given to the
PSK subsystem for standard PSK compression and transmission.

The only problem that I can see with this is whether the checksum is
good enough and I would suggest that the standard one of simply
adding up the bytes is far from adequate. However, as I note above,
much better checksums do exist.

- Stewart/G3YSX


*****3rd reply*****

From G3PLX:

Stewart's brilliant idea, to put the checksum at the START of the block,
would make quite a difference, since the chances of this data being
corrupted by extra or missing (earlier) characters would be much reduced.
The ARQ-PSK system that Angus wants to use has the checksum at the END of
the block - the worst possible place to put it in this respect.

Perhaps Angus can suggest this idea* to the author of ARQ-PSK and try both
schemes on the air.

73
Peter


* Which I now have!


Re: Minimum Operating system for NBEMS

"Rich Newsom" <richwa4sxz@...>
 

I have run the Windows version with no problems at all with Win98SE,
SB16 ISA, 1997 built P200mmx with 133meg 70ns fpm ram. I have run it
with as little as 64 meg EDO ram on a similar P200mmx computer (1993
SCSI drives) but the boot up seems to take forever.

No real advantage to running the Puppy Linux version with such low
resources, the GUI is just more than a P200mmx can handle rapidly,
even with the swapfile on a faster drive.

I've run everything without any problems at all with Puppy Linux,
Ubuntu 7.10, and Windows 2000 & Windows XP on a Dell Celeron 533 with
320 Meg of ram in a desktop and also a old Dell P4/897MHz Laptop with
256 meg ram and XP/Ubuntu/Puppy Linux installed in multi-boot.

Rich
WA4SXZ

at home with trailing edge tech...

--- In NBEMSham@yahoogroups.com, "mffrhorne" <hornetd@...> wrote:

Can anyone advise the minimum operating system and computer resources
under which the NBEMS software can be run with reliability and system
stability. I have an older laptop that I am considering using for
site communications support. I'm trying to figure out if it will run
any of the common EMCOMM software now in use.
--
Tom Horne, W3TDH


Minimum Operating system for NBEMS

"mffrhorne" <hornetd@...>
 

Can anyone advise the minimum operating system and computer resources
under which the NBEMS software can be run with reliability and system
stability. I have an older laptop that I am considering using for
site communications support. I'm trying to figure out if it will run
any of the common EMCOMM software now in use.
--
Tom Horne, W3TDH


Playmate wanted!

"woodtownuk" <G3TXL@...>
 

I want to trial this.
Is there anyone out there in the UK - within a couple of hundred km of
Plymouth - ready/able to give it a go, please?

Must have a 5 MHz NoV and GSOH :o))

Angus Graham


Re: found @ http://www.marsregionone.org/00Scroller.html **

Dave AFA1HV <afa1hv@...>
 

I think that might have been tried already. Here is a page to start with.
http://www.arrl.org/news/stories/2007/04/27/101/?nc=1
It concerns withdrawing the bandwidth regulation petition.
73
Dave WB2HVF


Rick wrote:


Tim,

Could you ask Riley about this? I have submitted many questions to him
late last year but have received no response yet.I know that some are
afraid to ask in such cases, because they say you might not like the
answer. But even an answer you don't like means you can always petition
the FCC for a change in the rules. And sometimes they "reinterpret" the
rules. Look what happened with allowing very wide bandwidth modes in
what was previously called the narrow band area in the text data
portions of the bands!

We can theoretically operate mixed modes in the 160 meter band. I know
it is not technically HF, but most of us sort of lump it in with HF. The
FCC permits text data throughout 160 meters, but the catch is that the
band plans do not.

I would like to see a mixed mode area in the 160 meter band. I would
actually like to see the band plan changed to reflect CW on the bottom
portion and wider digital modes higher up and mixed modes somewhere in
between there and the phone area. We should always have this on every HF
band, but we do not. It is very difficult because Extra hams typically
have the area just above the text data areas which they can use for
phone/image. So having mixed modes there would mean you would need an
Extra class license. Not very practical for emergency communication.

You actually can use MT-63, and other modes that we normally use for
text data, in the voice/image portions of the bands, but you must use it
for sending ... image or even phone if it could do that too. It is the
type of information that defines what you can do in various parts of the
ham bands.

73,

Rick, KV9U

Tim Cotton, N4UM wrote:
Rick:

It sounds like you're saying with your remark about "one exception"
that
2000Hz wide MT-63 would be legal in the amateur phone bands so long
as some
SSB use of the frequency was going on simultaneously... and
presumably would
be illegal if no SSB use was being made of the same frequency(?) I
understand the technical issue of MT-63 and SSB sharing a similar
band of
frequencies but wonder about the legal aspects on the amateur bands.


Re: found @ http://www.marsregionone.org/00Scroller.html **

Rick <mrfarm@...>
 

Tim,

Could you ask Riley about this? I have submitted many questions to him late last year but have received no response yet.I know that some are afraid to ask in such cases, because they say you might not like the answer. But even an answer you don't like means you can always petition the FCC for a change in the rules. And sometimes they "reinterpret" the rules. Look what happened with allowing very wide bandwidth modes in what was previously called the narrow band area in the text data portions of the bands!

We can theoretically operate mixed modes in the 160 meter band. I know it is not technically HF, but most of us sort of lump it in with HF. The FCC permits text data throughout 160 meters, but the catch is that the band plans do not.

I would like to see a mixed mode area in the 160 meter band. I would actually like to see the band plan changed to reflect CW on the bottom portion and wider digital modes higher up and mixed modes somewhere in between there and the phone area. We should always have this on every HF band, but we do not. It is very difficult because Extra hams typically have the area just above the text data areas which they can use for phone/image. So having mixed modes there would mean you would need an Extra class license. Not very practical for emergency communication.

You actually can use MT-63, and other modes that we normally use for text data, in the voice/image portions of the bands, but you must use it for sending ... image or even phone if it could do that too. It is the type of information that defines what you can do in various parts of the ham bands.

73,

Rick, KV9U


Tim Cotton, N4UM wrote:

Rick:

It sounds like you're saying with your remark about "one exception" that 2000Hz wide MT-63 would be legal in the amateur phone bands so long as some SSB use of the frequency was going on simultaneously... and presumably would be illegal if no SSB use was being made of the same frequency(?) I understand the technical issue of MT-63 and SSB sharing a similar band of frequencies but wonder about the legal aspects on the amateur bands.


How can I run NBEMS on the tiny EeePC ??

"David Harvey" <gedanate@...>
 

Hi folks, I'm brand-new in here, in fact I just joined today and only
discovered NBEMS a few hours ago. I now have it running on my desktop
at home with Windoze XP.

However, I have an EeePC with Linux on it... a variant of Debian, so
I'm told. However the tiny EeePC does not have a serial port, only two
USB ports.

Is there any chance of being able to use it for NBEMS?

My Linux skills are very, very basic.

Thanks,

David VK2DMH


Re: found @ http://www.marsregionone.org/00Scroller.html **

"Tim Cotton, N4UM" <N4UM@...>
 

Rick:

It sounds like you're saying with your remark about "one exception" that 2000Hz wide MT-63 would be legal in the amateur phone bands so long as some SSB use of the frequency was going on simultaneously... and presumably would be illegal if no SSB use was being made of the same frequency(?) I understand the technical issue of MT-63 and SSB sharing a similar band of frequencies but wonder about the legal aspects on the amateur bands.

----- Original Message -----
From: "Rick" <mrfarm@...>
To: <NBEMSham@yahoogroups.com>
Sent: Tuesday, April 01, 2008 2:09 PM
Subject: Re: [NBEMSham] found @ http://www.marsregionone.org/00Scroller.html **


Hi Jim,

This has been done mostly on MARS circuits because they have a
channelized system of operation and they can legally do it on HF
channels. FCC rules do not permit using text data in the voice/image
areas. One exception The bandwidth of wide 2000 Hz MT-63 is close to the
typical SSB voice bandwidth, so running both at the same time can make
for double use of the channel.

MT-63 has 64 tones running at low baud rates, and it has a sort of
rushing sound which is less distracting than most other digital modes.
Because there are so many tones (similar to DRM), each tone has a very
small amount of energy and operators have been able to talk with the
sound in the "background." The MT-63 modulation is also minimally
affected by the SSB signals since SSB is a sort of wide band variable
noise with varying degrees of power across several kHz and MT-63 is
designed to handle this kind of "interference."

73,

Rick, KV9U



Jim wrote:
Rick,
Could you explain this claim better? From my view, it does not seem
a possibility...!!

............one advantage of MT-63 for dedicated channel operation, such as
MARS, is that it is possible to tolerate having a background
transmission of MT-63 going on at the same time as SSB voice...............



------------------------------------

Yahoo! Groups Links




Re: found @ http://www.marsregionone.org/00Scroller.html **

Rick <mrfarm@...>
 

Hi Jim,

This has been done mostly on MARS circuits because they have a channelized system of operation and they can legally do it on HF channels. FCC rules do not permit using text data in the voice/image areas. One exception The bandwidth of wide 2000 Hz MT-63 is close to the typical SSB voice bandwidth, so running both at the same time can make for double use of the channel.

MT-63 has 64 tones running at low baud rates, and it has a sort of rushing sound which is less distracting than most other digital modes. Because there are so many tones (similar to DRM), each tone has a very small amount of energy and operators have been able to talk with the sound in the "background." The MT-63 modulation is also minimally affected by the SSB signals since SSB is a sort of wide band variable noise with varying degrees of power across several kHz and MT-63 is designed to handle this kind of "interference."

73,

Rick, KV9U



Jim wrote:

Rick,
Could you explain this claim better? From my view, it does not seem a possibility...!!

............one advantage of MT-63 for dedicated channel operation, such as
MARS, is that it is possible to tolerate having a background
transmission of MT-63 going on at the same time as SSB voice...............



Re: found @ http://www.marsregionone.org/00Scroller.html **

Jim <M1-Radio@...>
 

Rick,
Could you explain this claim better? From my view, it does not seem a possibility...!!

............one advantage of MT-63 for dedicated channel operation, such as
MARS, is that it is possible to tolerate having a background
transmission of MT-63 going on at the same time as SSB voice...............


Jim M
.
At 09:22 AM 3/30/2008, you wrote:

Hi Craig,

MT-63 is an earlier digital mode [c. 1998], developed by Pawel, SP9VRC,
that has 64 tones using very low baud rates with moderate throughput for
the bandwidth footprint. (PSK10 for the 1000 Hz wide mode with 100 wpm
throughput). It was popular for a while for amateur text digital, but
has been replaced by other modes that are not as wide, or may not be as
affected by Doppler, less latency, etc.

The one advantage of MT-63 for dedicated channel operation, such as
MARS, is that it is possible to tolerate having a background
transmission of MT-63 going on at the same time as SSB voice. Combined
phone and text digital is generally not legal on most HF amateur
frequencies (possible exception of 160 meters).

Because of MT-63's long latencies, depending upon the amount of
interleaving, it may not be a good candidate for an ARQ mode with the
simple form of ARQ being used on NBEMS. It could theoretically be used
on a pipelined ARQ design, but even then the weak signal performance may
not be as competitive as some other modes.

If you look at all the modes available, PSK can do well with certain
designs. Pactor 2 uses varying PSK modulation with 2 tones at 100 baud
and spaced 200 Hz with FEC and compression. Pactor 3 has up to 18 tones
for speed, but is highly adaptive and drops off tones as conditions
require more robustness.

For sound card modes, the more robust modes seem to use MFSK, e.g.,
MFSK16, Olivia, and ALE/FAE. Currently, FAE seems like one of the best
candidates for inclusion into NBEMS since it has moderate throughput
approaching 100 wpm. As an alternative system, FAE can be used by itself
with the Multipsk program.

73,

Rick, KV9U


Re: NBEMS ON Linux or Mac?

Ed <autek@...>
 

n1ep wrote:
I recently loaded the NBEMS programs on my Windows XP machine and really having fun and learning how to use the Flarq, etc. Was wondering if there are any plans on developing a Linux or Mac version?
73, Phil N1EP
Phil, I use the fldigi/flarq combination on Ubuntu 7.04. It works like a charm, Dave's prebuilt binaries are the suggested install method. You will however need to spend some time in both help files. In my testing the biggest problem I found where ops that hadn't bothered to read or read the help files in their entirety.

If you decide to try the Linux version and run into problems, just post them here. There is plenty of trouble shooting help on the list.

Ed W3NR


Re: NBEMS ON Linux or Mac?

w1hkj <w1hkj@...>
 

The Linux version already exists. Visit www.w1hkj.com

The OS-X version is being worked on.

Dave


NBEMS ON Linux or Mac?

"n1ep" <n1ep@...>
 

I recently loaded the NBEMS programs on my Windows XP machine and
really having fun and learning how to use the Flarq, etc. Was
wondering if there are any plans on developing a Linux or Mac version?
73, Phil N1EP


Great program

"nod468" <nod468@...>
 

To all..Love the way the program latches onto either bpsk or mfsk...One
of the best in that regard...Like the notch filters also and the
spectrum as well as the waterfall..Probably in the near future you
might add OLIVIA and FEC31 to it..Very neat design throughout..
Don W1OER...


Re: found @ http://www.marsregionone.org/00Scroller.html **

Rick <mrfarm@...>
 

I have a more recent comparison (Nov 2007) that I did in my article "Comparing Document Size with File Types" in the Files Section of the HFDEC yahoogroup (Hams for Disaster and Emergency Communication). This article compares the size of a basic text file with QForms, xml, pdf, odt and doc formats (they get huge of course).

The article also compared the bandwidth, baud rates, Signal to Noise ratio, and cps throughput of several digital modes. I also compared the estimated transfer time of these modes providing that the throughput would not fall below 600 characters of the base text form (The Gettysburgh Address with 1419 characters). Most formats are impractical from my perspective. Of course only a few of the modes (FAE400 FAE141A and Packet) are full ARQ. WinDRM can be used with an after the fact repair of data. Since I did not test RFSM until later, it was not included.

If you are interested in amateur radio emergency communications, you might consider joining the HFDEC yahoogroup.

73,

Rick, KV9U


larrytkc@... wrote:

Craig,
Some years back I did a comparision of a 'test file' - the results can be veiwed at http://www.qsl.net/kb0emb/2mfm.htm Scroll down the page to 'Data Transfer speed' the table shows my results for different modes using the "standard" test file. The RX/TX setup was from my basement to upstairs via dummy load and 5 watts power.
Just remember the last update I did to that page was Oct 2003, many of the URLs are not valid. I left the info in place for Reference and haven't gotten around to removal.
Skip is correct in his assesment of NBEMS vs MT63 - ARQ insures the message is received with no errors vs minimal errors (FEC) Each mode has pros/cons, while doing on the air testing I was able to transfer data to another station ~ 160 air miles away using my FT817 at 1/2 watt via MFSK, but it is an FEC (and slower) mode.
Larry kb0emb
KC metro



------------------------------------------------------------------------
Create a Home Theater Like the Pros. Watch the video on AOL Home <http://home.aol.com/diy/home-improvement-eric-stromer?video=15&;ncid=aolhom00030000000001>.
------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.1/1348 - Release Date: 3/28/2008 10:58 AM


Re: found @ http://www.marsregionone.org/00Scroller.html **

Rick <mrfarm@...>
 

Hi Craig,

MT-63 is an earlier digital mode [c. 1998], developed by Pawel, SP9VRC, that has 64 tones using very low baud rates with moderate throughput for the bandwidth footprint. (PSK10 for the 1000 Hz wide mode with 100 wpm throughput). It was popular for a while for amateur text digital, but has been replaced by other modes that are not as wide, or may not be as affected by Doppler, less latency, etc.

The one advantage of MT-63 for dedicated channel operation, such as MARS, is that it is possible to tolerate having a background transmission of MT-63 going on at the same time as SSB voice. Combined phone and text digital is generally not legal on most HF amateur frequencies (possible exception of 160 meters).

Because of MT-63's long latencies, depending upon the amount of interleaving, it may not be a good candidate for an ARQ mode with the simple form of ARQ being used on NBEMS. It could theoretically be used on a pipelined ARQ design, but even then the weak signal performance may not be as competitive as some other modes.

If you look at all the modes available, PSK can do well with certain designs. Pactor 2 uses varying PSK modulation with 2 tones at 100 baud and spaced 200 Hz with FEC and compression. Pactor 3 has up to 18 tones for speed, but is highly adaptive and drops off tones as conditions require more robustness.

For sound card modes, the more robust modes seem to use MFSK, e.g., MFSK16, Olivia, and ALE/FAE. Currently, FAE seems like one of the best candidates for inclusion into NBEMS since it has moderate throughput approaching 100 wpm. As an alternative system, FAE can be used by itself with the Multipsk program.

73,

Rick, KV9U

kq6i@... wrote:

Read the article in QST caused me to be curious enough to learn more of NBEMS. Searching and reading I
came up this comment.

**[01-11-08-New EmComm Software for Windows Now Available for Beta Testing There is a new beta digital
available for those interested. It's titled NarrowBand Emergency Messaging System and appears to be
robust with only one drawback, it doesn't do MT63 - yet.] What is MT36?

Has anyone done any comparing?


Re: found @ http://www.marsregionone.org/00Scroller.html **

larrytkc@...
 

Craig,
 
Some years back I did a comparision of a 'test file' - the results can be veiwed at http://www.qsl.net/kb0emb/2mfm.htm  Scroll down the page to 'Data Transfer speed' the table shows my results for different modes using the "standard" test file. The RX/TX setup was from my basement to upstairs via dummy load and 5 watts power.
Just remember the last update I did to that page was Oct 2003, many of the URLs are not valid. I left the info in place for Reference and haven't gotten around to removal.
 
Skip is correct in his assesment of NBEMS vs MT63 - ARQ insures the message is received with no errors vs minimal errors (FEC) Each mode has pros/cons, while doing on the air testing I was able to transfer data to another station ~ 160 air miles away using my FT817 at 1/2 watt via MFSK, but it is an FEC (and slower) mode.
 
Larry kb0emb
KC metro




Create a Home Theater Like the Pros. Watch the video on AOL Home.

16621 - 16640 of 16972