> 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
