----- Original Message ----- From: "Rick" <[EMAIL PROTECTED]> To: <digitalradio@yahoogroups.com> Sent: Sunday, March 02, 2008 12:52 PM Subject: 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? Rick, we already had MFSK16 in VBdigi and originally could not use it with ARQ because of the latency you correctly identify. We made it work by adding 10 <SOH> control characters (allowed by the ARQ specification) to give time for the MFSK16 syncronization to lock in. It is a poor solution, as that additiona slows down the mode even more, but better than nothing when conditions are very poor and it is important to get messages out, even if it takes extra time. > > 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. NBEMS does not use an orgarnized army of robots like Winlink does, but depends upon individual hams and emcomm groups to provide forwarding stations. Consider the difficulty of trying to achieve a connect on Winlink. As we discussed, and I pointed out, that sometimes takes as long as 20 minutes. In the recenty MARS Winlink test, as related by Stuart Carter, propagation did not allow connecting locally, and it was necessary to use a PMBO in Utah, so it is easy to realize that one limitation of using approved PMBO robots is the number of robots not currently busy or in range. Assume you have a major hurricane and there are 25 shelters full of people wishing to send health and welfare messages to their friends and family. The existing Winlink network only has about 25 PMBO's in the US, and many of those will not be in range at any given time, or if they are, are busy handling traffic on their primary frequency or on their alternate scanned frequency. The result is that in a real emergency, not just a test, hams that have set up at a shelter for communications will often have to queue up and wait in line to get their messages out. Now, compare that to the NBEMS system, using narrowband modes. As I mentioned previously, as many as 25 separate signals can share the passband of a radio with a SSB filter, meaning that there can be as many as 25 stations at shelters passing traffic at the same time, as long as there are forwarding stations in range to accept the traffic. The NBEMS software is free, and will always be free, and the cost to use the software is no more than the cost of in interface, if you do not already have one. The idea is that this low cost of entry will make it possible for many, many, hams to be prepared to assist in emcomm when called upon. Perhaps, and most likely, the ham locally will be the one who can get to a shelter to help out, and in a widespread emergency, hams outside the disaster area that would like to help simply have to beam toward the disaster area (if on 2m VHF) or monitor the PSK63 watering holes for CQ's to pass traffic with NBEMS software. If this concept, which returns emergency communications back to the hams instead of controlled by an army of robots, is to be successful, the NBEMS software must be as basic and simple as possible just to accomplish the basic NBEMS emcomm task. We have intentionally kept the software that way for the Windows version. If you want more complication, and can handle Linux, fldigi has almost all the popular digital modes, and also works with flarq. It has taken us two man-years to develop the VBdigi/flarq combination just to include the modes we now offer. Sure it would be nice to add even more modes so there are more choices to use on HF, but for the 100 mile range needed for emcomm, the PSK modes on 2m VHF do the job very well, and all the stations calling CQ Emergency Traffic will be found on a single frequency, somewhere within the passband on the waterfall. I cannot emphasize enough the importance of simplicity in the design of a system intended to be used by operators with little or no experience. Under the enormous pressures of trying to move volumes of emcomm traffic, simplicity reduces the chances for error, or even perhaps failure. A lot of our compromises for NBEMS have been made in this light, and I assure you we have made many, many, compromises to achieve simplicity. > > 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. There will be both organized emcomm operations and individual emcomm operators during a widescale emergency. The idea is to get traffic out, no matter what it takes, or who has to get it done. As more people try NBEMS, and we improve the system with the feedback we get, we will get closer and closer to the goal of intuitive operation of the software where it is obvious how to do something without RTFM. > 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. I will emphasize again that by using 2m VHF SSB for PSK63 and PSK125, we already can equal the average Winlink system transfer times on HF for Pactor-3 with PSK125, in one tenth the bandwidth, because we do not have to deal with QSB, so we feel it is better to use as narrow a mode as possible instead of using a wider mode that is a little faster and can handle QSB that 2m does not have within the necessary 100 mile range. Considering that the NBEMS software is free, open source, and that there is no cost to purchase a proprietary modem just for occasional emcomm email use, I think that NBEMS fills the need for an additional emcomm tool that every ham can afford, if so inclined to be ready to assist in disaster communications. There is nothing to stop emcomm groups from experimenting and promoting adoption of wider modes like FAE400 or ALE400 if they wish, but I am not sure that acceptance will as widespread as NBEMS, which includes PSK31, which appears to still be growing in usage and popularity every day, and PSK63, which is slowly gaining acceptance for contesting. It is a short jump from using PSK31 or PSK63 for casual QSO's or contesting to adding flarq to handle emergency communications when asked to do so. Even going from PSK31 (which tens of thousands now use) to PSK63 is a no-brainer, which is one of the reasons we chose to use PSK63 as the base mode for NBEMS. 73, Skip KH6TY NBEMS Development Team
