Re: [digitalradio] Re: Random data vs Spread Spectrum

[KH6TY]

Rein,

I said I would not comment further on ROS, but look at it in 
perspective. The author defined ROS as spread spectrum and produced a 
two page document to that effect. He is the only one who knows for sure 
if it is spread spectrum or not.

When it was posted that spread spectrum was not legal below 222 Mhz, he 
conveniently (for his benefit) tried to redefine ROS as FSK, in an 
apparent attempt to change the FCC opinion, which originally was based 
on his own two-page declaration, which he wanted us to believe.

The FCC then made their own analysis and concluded it was not FSK but 
truly spread spectrum. This was communicated to us by the ARRL as is 
usually the case.

The author, if he would have disclosed his code, could have  proven 
whether or not  the  randomization is for spread spectrum purposes or 
for some other reason, but he steadfastly refused to disclose the code, 
which would either have resulted in it being OK for us to use, or prove 
it was truly FHSS. Perhaps he decided to try and bluff the FCC because 
it would be determined, on the basis of his code, to really be FHSS, in 
agreement with his first description, and in disagreement with the 
second description he wrote, obviously just to try to get approval.

It is just not reasonable to think that a person of his ability, as the 
author of the software, could make such a huge mistake in his first 
characterization of
ROS as spread spectrum and then completely revise the characterization 
as something else which he knew would be usable by US hams.

You can imagine how the FCC feels about that attempted deception, and to 
top it off, he posts a phoney statement of FCC approval besides! I 
seriously doubt that the FCC is going to want to revisit the question, 
since the author simply cannot be believed. I met Dan Henderson at a 
hamfest right after all this happened and he had been in contact the 
FCC, and opined that it was highly doubtful that any further 
reconsideration would be done.

The ONLY way for us to ever use ROS on HF is to petition the FCC to 
amend the rules to allow limited spread spectrum below 222 Mhz, citing 
enough good reasons why it will not harm existing operations of lesser 
bandwidth.

Instead of constantly arguing that the FCC made a mistake, or we should 
interpret the rules as we wish they were, I suggest that either a 
petition be filed, or the code released to prove the author's contention 
that it is not spread spectrum. Of course the submitted code would have 
to be recompiled and tested to prove it is really the original code, and 
another attempted deception by the author.

Understand that I am NOT "against" ROS, and never have been, even though 
I strongly dislike the author's behavior and suspect his motives. I 
would keep using it on HF if it were legal for me to do so. I do respect 
the FCC regulations, even those that I do not like, and follow them as 
best I can, because in the overall picture, they protect the weak from 
the strong for the benefit of everyone, until revised in a non-harmful way.

This will be my (final) final word on this subject, so please do not ask 
me to comment any further.

If you want to use ROS on HF, then enter a petition to get the 
regulations changed so you can, or work with someone else who will do 
that for you, and end this endless denigrating of the FCC, ARRL, and 
others who follow the regulations and depend upon ARRL interpretations 
of the FCC regulations for us all.

Signing off on ROS now -

73,  Skip KH6TY

On 7/13/2010 2:23 PM, rein...@ix.netcom.com wrote:

Hi Alan,

Why did you wait so long with contributing here?
Please explain.

++ In Feb of this year I quoted from the ARRL's Spread Spectrum Source 
book page 5-2 ++

" Spread Spectrum Fundamentals "

SS systems employ radio frequency bandwidths that greatly exceed the 
bandwidth necessary
to convey the intelligence.

Bandwidths for SS systems generally run from 10 to 100 times the 
information rate.

etc etc.

I got shouted out of the Group by addressing the use of ROS in the US 
by the experts on
SS.

73 Rein W6SZ

-----Original Message-----
>From: Alan Barrow <ml9...@pinztrek.com <mailto:ml9003%40pinztrek.com>>
>Sent: Jul 13, 2010 1:22 PM
>To: digitalradio@yahoogroups.com <mailto:digitalradio%40yahoogroups.com>
>Subject: Re: [digitalradio] Re: Random data vs Spread Spectrum
>
>graham787 wrote:
>> So, if bits are added to the transmit waveform that are not 
performing a function of helping to re-create an error free 
replication of the input data, it meets my test as spread spectrum. If 
the symbols in the transmit waveform cannot be predicted by the 
previous sequence of bits over time at the input, it also would meet 
my test as spread spectrum. To reiterate on this point, just because 
the symbols of the transmit waveform are changing during an unchanging 
input, does not imply spread spectrum.
>>
>> Instead, they may well be the result of a defined randomizer 
process followed by multiple layers of FEC and modulation coding.
>>
>
>While I do not support ROS in any form, I think the group is on a very
>slippery slope here with well intentioned but misinformed definitions &
>tests that may haunt us in the future!
>
>Just the fact that data is randomized does not define SS. There has to
>be a spreading factor, which has some rough definitions based on
>practical applications, but is not addressed in any FCC definitions.
>
>Skip's well intentioned but overly simplistic test of looking at the bit
>stream is not enough to define SS. There are many legitimate reasons to
>code data resulting in a pseudo-random fashion that have nothing to do
>with SS!
>
>The most common is coding so the transitions between bit's can easily be
>detected even in noise. It's a problem when sequential bits look the 
same.
>
>You can also factor in FEC. There are many, many writeups on
>convolutional encoding that go into this. (Viterbi & reed-solomon are in
>wide usage)
>
>But it's also useful to spread the energy out in the bandwidth and avoid
>sidebands created by single tones of long duration. There are multiple
>modem/modes which do this, some in very wide usage.
>
>So yes, SS (really DSSS) is pseudo-random. But not all pseudo-random
>coding is SS, and we should not be proposing that as a litmus test!
>
>The real test should be:
>- direct or BPSK modulation via a pseudo-random code in addition to any
>coding for FEC (convolutional, etc)
>- A spreading factor significantly higher than the original data rate
>
>The 2nd item is the key part, and it's listed but virtually never quoted
>in this group, but is listed in nearly all the SS definitions. Nor is it
>addressed in the FCC part 97 rules.
>
>It's not enough that the bandwidth is higher than the data rate would
>imply, as nearly all modes with FEC would fail that by definition.
>
>The key is the "significantly wider" aspect, also referred to in
>ITU/IEEE definitions as "typically orders of magnitude greater than the
>data rate". And this is why many engineers question whether any SSB
>generated mode could be "real" SS. ROS only did it by having the
>original data rate lower than the SSB bandwidth.
>
>About the lowest commercial DSSS implementations use a spreading factor
>of 16:1, and that's for consumer grade without noise performance 
concerns.
>
>Most DSSS implementations in the real world use spreading factors of 100
>or greater, as that's when you start seeing significant noise recovery
>improvements.
>
>In DSSS, the "processor gain" which improves noise resilience is
>directly related to the spreading factor.
>
>I've posted multiple definitions from the ITU & IEEE in the past for
>DSSS. Wikipedia, which has some good information, does not constitute a
>formal definition like the ITU & IEEE references do. (Part of the reason
>that wikipedia is not admissible as sources for college & research 
papers).
>
>There is no shortage of formal definitions, we should not have to invent
>our own. There are also some very readable definitions from mfg's for
>their DSSS components. Like this one:
>< http://www.maxim-ic.com/app-notes/index.mvp/id/1890 >
>
>
>So ROS (RIP) is very odd in this aspect, as it's nowhere near
>conventional DSSS implementations in it's spreading factor, yet is
>higher than the spreading seen by FEC & convolutional encoding. This is
>a constraint of the AFSK/SSB encoding, but does pose some questions as
>to how it should be treated.
>
>In all the discussion of SS, bandwidth, etc, everyone is missing the
>point that DSSS wider bandwidth usage is offset by use of CDMA.
>(collision detection multiple access). DSSS is nearly always used with
>many stations on the same "channel" with the same key. It's no accident
>that cellular went from analog techniques to DSSS..... it maximizes use
>of their spectrum!
>
>So the idea of ROS having multiple net frequencies is just silly, all
>ROS stations should be using the same frequency! For that matter, so
>should most of our advanced modes including winmor, ALE, etc. And we
>have to factor in the fact that multiple stations could/should be using
>the same spectrum when you examine bandwidth of DSSS.
>
>Set aside all the unprofessional behavior by the pro & anti ROS
>contingents...
>
>I believe ROS as implemented did not offer enough processing gain to
>justify usage on crowded bands like 40m. But I think we hams lost an
>opportunity to experiment with new modes that had promise in the way the
>ARRL/FCC interactions took place.
>
>But with a higher spreading factor used on a dedicated frequency
>allocation, or in a section of large signal higher band (10, 12, 15?) it
>might have shown some promise. Due to the nature of HF and FM, you could
>have run weak signal ROS with a higher spreading factor in the FM
>section of 10m with no impact to FM operations. (just an example of how
>we could have experimented).
>
>And certainly I'm opposed to some of the well intentioned but
>significantly mis-informed "tests" and definitions being proposed. We
>may be locking US hams out of the next great mode.
>
>As far as I'm concerned, this whole ROS episode is an embarrassment to
>ham radio, and is a textbook case of how not to introduce a new mode,
>interact with the FCC, etc.
>
>As I've had visibility to getting FCC approval for new modes in two
>different cases, I can guarantee this episode set us back in the eyes of
>the FCC. This is the fault of the author, as well as well intentioned
>individuals out on a crusade.
>
>Have fun:
>
>Alan
>km4ba
>
>
>
>------------------------------------
>
>http://www.obriensweb.com/digispotter.html
>Chat, Skeds, and "Spots" all in one (resize to suit)
>
>Facebook= http://www.facebook.com/pages/digitalradio/123270301037522
>
>Yahoo! Groups Links
>
>
>