Re: [44net] a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
6 Jul
2013
6 Jul
'13
1:43 p.m.
I was thinking the same thing.
If it's a data transmission then yes obviously the bandwidth rules apply.
If it's an image transmission then a different set of rules apply.
If its a spread spectrum transmission then 97.311 applies.
The problem is defining what you are transmitting.
http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html
As for chewing the the band. You really have to look at it on a case
by case basis, geographically.
Where I live, 70cm is pretty dead, so a 5 MHz wide signal isn't a big
deal. 15 years ago a guy was playing with analog ATV and that really
did rip up the band, as it had no real filtering, and at the time the
band was active.
97.307 doesn't apply to FHSS or DSSS. The
applicable section is
97.311.
Anyway this isn't the place to discuss rules in my opinion.
However if we keep connecting slow speed conventional radios to the
amprnet, then it will continue to be what is has for the last 20+
years. I am glad to see some people thinking out of the box, and
exploring different technologies.
Getting back on topic, I read there was a recent presentation titled
"Providing authenticated amateur radio services on the Internet", is
there a paper or video available for those of us who didn't attend?
6 Jul
6 Jul
5:22 p.m.
New subject: a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
On Sat, 6 Jul 2013 13:43:29 -0500, kb9mwr(a)gmail.com wrote:
I disagree. Since the rules restrict what we can do on the air and the
bandwidth characteristics of the emissions involved I think it's very
important for hams to understand digital communications in the context
of the rules, especially since hams in the U.S. may actually be under
more strictures than those in other countries.
I don't mean we should start talking about rules and what needs to
change on this list but when someone raises a rule stating 100kHz is
the maximum bandwidth allowed, it's important to point out that spread
spectrum communications, and the applicable rules that allow it,
specifically depends on bandwidths greater than that by at least three
orders of magnitude.
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
geoff(a)windomeister.com
97.307
doesn't apply to FHSS or DSSS. The applicable section is
97.311.
Anyway this isn't the place to discuss rules in my opinion. 
7 Jul
7 Jul
10:13 a.m.
New subject: a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
On Sat, Jul 6, 2013 at 11:43 AM, <kb9mwr(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
I was thinking the same thing.
If it's a data transmission then yes obviously the bandwidth rules apply.
If it's an image transmission then a different set of rules apply.
If its a spread spectrum transmission then 97.311 applies.
The problem is defining what you are transmitting.
This really is an issue but I do wonder to what extent and some
clarification would indeed be helpful here. Take a couple examples:
transmitting music is completely disallowed... or is it? If I encode
music as MIDI or MP3 is it music or data? Does it change it's character if
I then packetize that bitstream and route it over an IP network?
If I encode video as mp4 or mpeg and transmit that is it video or data?
Does it change it's character if I then packetize that bitstream and route
it over an IP network?
If I encode a multiplexed multimedia stream that contains MP3 music, MPEG2
or MPEG 4 VIDEO, teletext data, and closed captions what is it and what
rules apply? is it video, or data, or music, or any number of other
things? Does it change it's character if I then packetize that bitstream
and route it over an IP network?
When is an emission spread spectrum and when is it really just a really
good super redundant error correcting unspecified code? Spread Spectrum
(SS) is defined in the US as:
emissions using bandwidth-expansion modulation emissions having designators A,
C, D, F, G, H, J or R as the first symbol; X as the second symbol; X as the
third symbol.
X as a symbol indicates not otherwise defined. If you look at the
definitions in place for the second symbol (nature of the signals
modulating the main carier) I can't really see how this would not always be
a 1 for our use and if you look at the third symbol (type of information to
be transmitted) W would seem to cover it as it's going to be audio, video,
and data in combination moving across the links.
So by a quirky set of definitions it would seem that SS does not exist as
we have a designator of ?1W covering our transmissions used in digital
networking thus the second and third designators not being undefined but
defined and thus can not possibly be spread spectrum even if we insert
enough additional redundant error correcting coding to grow the required
baud/symbol rate for a given bit rate of say 300 bits per second to where
it occupies several hundred Mhz of spectrum (yes I am demonstrating
absurdity by being absurd....). From a perspective of coding theory
however that is exactly what spread spectrum does, it transmits bunches of
extra information that can be used at the reciever to help figure out and
correc tthe missing or incorrect information. The conclusion here is
however admittedly absurd as for instance 802.11 is generally considered to
be spread spectrum emission and spread spectrum exists by the fact of it
being defined. This illustrates though that we really could use some
clarification as to the intent and meaning of some of the rules we live
under as radio amateurs.
Thinking that it could be helpful for maybe the ARRL, TAPR, or even the FCC
to grant some guidance here. Seems to me that everything we operate within
a data network would be emission ?1W
Eric
AF6EP
2:52 p.m.
New subject: a common vendor neutral hardware/software stack for 44net. - was Re: hardware vs. software
SS isn't redundant error correcting code. SS is accomplished by using
a pseudo-random bit sequence to chip the data stream into many smaller
bits, making the resulting channel stream look like Gaussian noise.
It's then de-spread at the receiving end and the baseband data is
recovered.
I think your best bet might be using COTS 802.11b (DSSS) hardware at
11Mbps on 3.4 GHz. Then there is the possibility of using 802.11a
hardware on that band. This would be a "simple" ;) matter of getting
hands on 802.11y hardware and tuning it down from 3.7 GHz. I don't
know what FCC would have to say about using 802.11a protocol on that
band. There used to be a prohibition in the rules about multiple
carrier signals in the same transmitter but I see no mention of it in
Part 97. I also see no mention of LFSR taps or length so it looks like
anything goes now. This sent me looking for my old Part 97 books but
it looks like I tossed them out.
FCC has already "clarified" their stand, "if it isn't specifically
prohibited, it's permitted", unless we tell you to stop. As for
clarification from ARRL or FCC, you don't even want to go there. FCC
has amended Part 97 to make it as broadly enabling as possible such
that if they don't want you to do something it's specifically
prohibited in Part 97 and if it's not prohibited it's permitted.
Unless they send you a cessation order after the fact the guiding
principle is to "just do it".
I see you doing a lot of complaining about what's NOT being done but
you don't seem to be doing something yourself. Grab that block of IP's
I allocated to you and start building. Then publish your results.
That's the basis and purpose of ham radio.
4157
days inactive
4158
days old
3 comments
3 participants
participants (3)
-
Eric Fort -
Geoff Joy -
kb9mwr＠gmail.com