When a regulation is based on a vague phrase like "using bandwidth-expansion
modulation emissions", the FCC should *expect* to hear from amateurs trying
to determine whether or not a mode is legal. There are certainly many
situations where amateurs can indeed be expected to "sort it out
themselves"; this isn't one of them.
73,
Dave, AA6YQ
-----Original Message-----
From: [email protected] [mailto:[email protected]]on
Behalf Of W2XJ
Sent: Tuesday, July 13, 2010 4:35 PM
To: [email protected]
Subject: [digitalradio] Re: [digital radio] Re: Random data vs Spread
Spectrum
The creator of ROS does not present himself as a very nice or honest person
but I also believe there are cultural and language issues that add to the
problem. Before all this started several months ago, I did not believe the
initial presentation that it was really spread spectrum but rather something
written by someone with a bad grasp of the English language.
That being said, Skip, you are also misrepresenting the situation by stating
the FCC made an analysis. Read the documentation and it is clear they made a
fairly non committal statement based on the published material. The FCC
does not like being involved in such matters. This is like the Dstar
controversy a few years back when an FCC official publicly told hams at
Dayton that if they were qualified to hold a license they should be able to
sort it out themselves. The commission will not do the thinking that hams
themselves should be doing for them selves. Please keep the sandbox fights
away from the FCC it will ultimately destroy the hobby. With the hunt for
more spectrum to sell be careful or there may not be any frequencies above
222 MHZ to even worry about spread spectrum.
On 7/13/10 3:23 PM, "KH6TY" <[email protected]> wrote:
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, [email protected] 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 <[email protected] <mailto:ml9003%40pinztrek.com> >
>Sent: Jul 13, 2010 1:22 PM
>To: [email protected]
<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
>
>
>
