rein...@ix.netcom.com wrote: > Hi Alan, > > Why did you wait so long with contributing here? > Please explain.
Hello Rein, I've posted on this subject several times in the past with ITU & IEEE references as well. It does seem to get lost in the noise at times. It does not help at all that the ROS author was doing much to incite hatred toward the mode, which unfortunately flows over to anything that looks/smells like ROS. (Specifically SS'ish type modes) The most problematic aspects are the way the whole dialog about ROS as handled are: - Overly simplistic tests/definitions on an already poorly defined (from FCC reg perspective) mode - Simplistic bandwidth comparisons that do not factor in total throughput. (IE: The effect of processor gain, FEC, etc). I don't think ROS was stellar here, but the idea that a wider mode for X data rate is worse than a narrower mode is flawed. Otherwise we'd all be using RTTY. FEC increases bandwidth for the same data rate, but the trade off surfaces over sustained measurement in real (difficult) HF conditions. Skip's work did show there was not a big win for ROS, so we arrived at the right spot. But many were banning just because it was wider than their favorite mode! - Lack of consideration that multiple SS signals could occupy the same spectrum, effectively decreasing the total required bandwidth. There is a point of diminishing returns, and ROS may not fare well. But if I could stack a dozen or more data signals simultaneously in a single SSB width slot, would that be a bad thing? Or what if a AF type SS (AFSS?) mode could live on a non-interference basis, should it be banned just because it was technically SS? No testing was done that I'm aware of that would have allowed real world throughput to be measured with multiple signals on the same channel. This is one of the big wins of DSSS! - Assumption that the current FCC reg is the end all. It was accurate for state of the art when added. But no one foresaw that DSP's would allow an audio based SS implementation inside a SSB bandwidth. The FCC reg was written to address the then current DSSS modems which used spreading factors of 100x with direct IF injection, etc. And are totally inappropriate for HF usage. Put another way, most professional RF engineers would consider any audio based scheme to not be DSSS as it's just not how it's done. Pretty much all real world DSSS systems use IF level modulation to the point that it's one of the main identifying characteristics. - Very inappropriate involvement of the FCC. This is absolutely not the way to approach a new mode, the answer is nearly always "check the regs". One thing we can probably all agree on is that ROS is pretty much dead for consideration in the US. The waters are too muddied at this point. I'm more concerned about impact to the next innovation. And the fact that all the noise & behavior set aside, the author did implement something new that should have been evaluated on it's merits before declared illegal via trial by yahoogroup. (Before he hastened it's demise due to his own unprofessional behavior). Personally, this episode just cements my believe that the US will be trapped using legacy modes & arcane restrictions for the most part until some form of bandwidth based bandplan approach is implemented like much of the civilized world. Lest we crow about some of the more recent innovations, we have to factor in that rtty still rules the airwaves from a number of users and usage perspective. And it's about as inefficient a mode we could come up with when impact to the spectrum is factored in. (medium power, wide sidebands, single user per channel, etc). Call me when there is a weekend with as many PSK signals on the air as one of the (too frequent) RTTY contests. I'm not opposed to RTTY, exactly the opposite. But it's the RTTY centric regs that hamper our development. Even things like P3 & winmor are having to go the long way around to maximize performance while not running afoul of the arcane RTTY based regs. (Much less use of tech like the FS-1052 modems, etc) Have fun, Alan km4ba
