Several of us were around the 10137 frequency earlier today and tried various combinations of modes, including NBEMS. We had at least KH6TY, K3UK, VE5MU, KC7GNM, and WD4KPD. Some attempts at making transfers was done. I sent Skip one of my standard messages which is the Gettysburgh Address. It took about 6 minutes or so to send with its 1419 character length.using the PSK63 speed. I unfortunately did not record this exactly. Not really fast, but we had quite a few repeats due to conditions being marginal. Again, this mode is intended more for VHF, but it does work on HF, even with fairly modest signals. The main thing is that the message was completely accurate at the receiving station, something nearly impossible to do with most of the sound card modes.
What we probably should have done is try the same message with FAE 400 mode and compare the throughput under similar conditions. Eventually it sounds like NBEMS may have a chat mode, which I think would be a good thing, but you can easily switch back and forth between the flarq ARQ add-on and the basic VBdigi program. I wonder if it might be possible to eventually add the FAE 400 mode? In fact, later on I was tuning around and VE5MU was down the band calling on FAE 400 and I just sort of set my cursor on the waterfall and I was connected. We had a lengthy chat and if you have used this mode, you know that it is hard to keep up with the throughput with less than 40 wpm keyboard speed:) And that is when conditions are not the best. I am wondering if it might be possible to have this mode eventually available on VBdigi as it clearly is the superior ARQ HF sound card mode at this time. You can use wide FAE for more speed, but it is no where near as sensitive as the 400 Hz narrower mode. And for those of us who really do not want to operate with moderate width modes (under 500 Hz), the 400 Hz wide mode is ideal. The 10130 to 10140 sub bands under the new Region 2 Band Plan recommends no more than 500 Hz bandwidth. Questions about NBEMS: 1. I think I asked something like this before, but bear with me. It seems to be sending several blocks of data because you see the inserted characters that must be a checksum and if the receiving station decodes all correctly it knows that. Is this a CRC kind of check or something similar? 2. Am I correct that it only requests the parts that it can not decode properly? And it does this even though in between blocks are OK and so don't need ARQ? So you can send maybe three or more "blocks" with the check and if only one is bad it only resends that one? 3. If it needs to repeat one or more blocks, the transmitting station does the repeat, but then continues to send new data as well? Probably to fill a maximum number of bytes per transmission? 4. If you see someone sending the flarq beacon in VBdigit, and their callsign, is that just a general call to anyone? Or is there some way to differentiate who is to get the message? 5. And then when their callsign appears automatically in the flarq program, does that mean they are trying to connect specifically to your callsign, or is your flarq program just responding to any flarq beacon? 6. If it is a general call, how do we know when you receive a message or who it is supposed to go to? 73, Rick, KV9U
