> Have had the opportunity to use NBEMS on 30m and would offer the following
> observations:
> . I like how Vbdigi , flarq, and the email software sylpheed work
> together. I set up sylpheed to one of my email addresses and it looks like
> I
> can receive mail via Vbdigi, and easily bounce it over to the internet.
> Haven't tried writing any "mail rules" with sylpheed to do that semi
> automatically yet.
You can do the same thing with Outlook Express as outlined in the VBdigi
"Messaging and Radio Email" help. If you click on "Reply to All", with
almost any email client, the address for forwarding will already be filled
in. The it is simply a matter of pressing "Send" to forward over the
Internt.
For emcomm, we recommend forwarding emails, but also contacting the
recipient to tell a written message is waiting. Otherwise, it might lie
unnoticed for hours before someone thinks to check his inbox. This is one
reason we do not use email robots for NBEMS, in addition to eliminating the
problem of an unattended station transmitting over traffic local to itself,
that is undetectable by the remote client.
>
> . Vbdigi works well as a small, simple stand-alone piece to use
> for
> PSK MFSK and RTTY. Menu is intuitive and easy to use.
> . Not crazy over the flarq file and mail transfer system. While
> ARQ,
> the packet size is huge and would result in endless repeats under anything
> other than ideal conditions. Sending mail , the software would break down
> a
> 1K test message into 2 , or 3 packets at the most. Using HF, the time
> taken
> to send one packet would be very subject to the usual QSB/QRM/QRN etc
> which
> on a large packet would likely result in a repeat. Smaller packet sizes
> would improve the software very much .
You can configure the packet sizes in the flarq Config menu by varying the
Exponent value to suit conditions. Rein has offered some experience with the
optimum packet size.
NBEMS was developed specifically for emcomm communications using small, very
portable, antennas on 2m VHF, where QSB is negligible on paths up to 100
miles in length. As a result, the incidence of repeats is very small, unless
you are just at the background noise level. Most repeats will be caused by
packets ruined by multipath reflections, such as when an airplane flies
overhead.
The additional overhead by sending a long text message as email instead of
as text is about 30 seconds. For most messages, it is worth the extra time
to simplify the message composition and use the email client for composing,
but that overhead can be eliminated by composing and saving as a text file
and dragging it into the ARQsend folder instead of the ARQout folder that
Flarq establishes the first time it is run.
>
> . File transfer using Flarq was slower than Multipsk ALE400, using
> PSK31. Would be much slower with any repeats.
Slower transfer speed is the price you pay for using a narrow bandwidth. On
VHF, where NBEMS is intended to be used most of the time, PSK250 in less
than a 500 Hz bandwidth approaches the average Pactor-III speed when
Pactor-III is used daily by Winlink on long-haul paths. The idea is that in
a real emergency, a multitude of stations can fit into the space of the IF
passband and all be passing traffic simultaneously, with all visible on the
waterfall where everyone knows where to look. This is important so that
there are opportunites for many hams to help with message forwarding.
>
> Am interested in further experiments and look forward to meeting anyone
> interested on 80-20M
These days, I will be monitoring 30m off and on in the daytime, and 80m at
night. Last night, we found the QSB on 80m, using antennas with a low
takeoff angle, to be quite a problem and causing excessive repeats compared
to 30m during the day. If NVIS antennas are used, the QSB should be much
less, and NVIS is the alternative antenna for NBEMS if VHF is not practical
due to the terrain.
If it is possible to try NBEMS on 2m, it would be a more relevant test of
the system design.
> John
> VE5MU
Thanks for the interest John! We are right now working to improve the user
feedback for message transfers and will posting an update soon, which will
also fix a few isolated bugs that have been reported.
73, Skip KH6TY