[HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
Bart Kus
me at bartk.us
Tue May 27 16:28:14 PDT 2014
There's no protocol I'm aware of that implements these features on top
of ID-1. You'd need the ability to receive corrupt frames from the ID1
to allow the use of FEC. How does the ID1 handle corrupt frames? Is
there a CRC or something in the framing? For ARQ, you could keep the TX
retrying until it hears an ACK or times out. Custom software would be
needed, or perhaps pppd can do such tricks, I dunno.
Did you hear any signal when you listened with an FM receiver? Can you
use an RTL-SDR or equivalent to see if there's any signal present?
--Bart
On 5/24/2014 8:36 PM, Dean Gibson AE7Q wrote:
> That's what I figured ("features [that] are common to all WiFi
> systems"); it just made sense (although that is not always
> determinative!).
>
> So, my next question: Is there an available tunneling protocol that
> employs those features?
>
> Note that with the ID-1 in the *one watt* setting (same omni antenna),
> I can use the 1.2GHz KB7CNN repeater 35 miles away on East Tiger
> mountain, with no noise in the FM signal. The link to Paine (5 miles
> away) was tried at max power (ten watts) on both radios. I tried two
> different frequencies (that's the beauty of being able to control both
> radios from one location!): 1.250GHz and 1.249GHz (I listened on both
> in FM mode), with no significant difference. So, in my opinion, it's
> a path problem.
>
> On 2014-05-24 13:13, Bart Kus wrote:
>> Wow that sucks. :( Is the signal level just too low? Is it a
>> matter of interference?
>>
>> And yeah, I can confirm that the microwave stuff we use includes both
>> FEC (at up to 1/2 rate) and an ARQ system (look at "hw-retries"
>> setting). These features are common to all WiFi systems too, and
>> they're just carried over into our NV2 TDMA system.
>>
>> --Bart
>>
>> On 5/24/2014 10:19 AM, Dean Gibson AE7Q wrote:
>>> Scott Honaker and I have moved forward on this project:
>>>
>>> 1. We have installed a gateway (Linksys BEFSR41) between the ID-1
>>> and the internal ARES/RACES subnet (not 44.x.x.x) of the DEM.
>>> 2. We have installed a Digi "AnywhereUSB" box to give us remote
>>> access to the ID-1's USB port, and thus remote control of the
>>> ID-1 radio. This not only allows multiple use of the ID-1
>>> (which has useful 1.2GHz FM and digital voice modes as well as
>>> Ethernet data), but provides for remote frequency agility and a
>>> diagnostic capability. This works beautifully (eg, to search for
>>> and use a low-noise frequency)!
>>>
>>> Unfortunately, what does not work very well, is the RF portion of
>>> the connection. PINGs failed at a rate of over 99% when using the
>>> 1.2GHz antenna at the 70 ft level on the tower, so we swapped the
>>> antenna with the one used for the Icom 1.2GHz repeater (which wasn't
>>> seeing any action anyway) at 100 ft. That made a "dramatic"
>>> improvement, as PINGs now only fail at a 98% rate (depends upon the
>>> time of day, etc)!
>>>
>>> Antenna comparison between 1.2GHz and 5.9 GHz for the two sites:
>>>
>>> 1. On 1.2GHz, both antennas are omni-directional.
>>> 2. At the DEM, the 1.2GHz antenna is now at the 100' level, whereas
>>> the 5.9GHz antenna is at 150'.
>>> 3. At my home, the 1.2GHz antenna is about 10' above the 5.9GHz
>>> antenna, and it's on the same line-of-sight path.
>>>
>>> Note that voice communication between the two sites using the two
>>> ID-1 radios, is fine (there is a slight bit of noise on FM).
>>>
>>> The big difference, in my opinion? I'll bet that the wireless
>>> protocol used by the MikroTik radios includes an aggressive error
>>> correction and retry protocol, whereas the ID-1 is like a piece of
>>> Ethernet cable, and thus relies on the standard TCP/IP retry
>>> mechanism. The TCP/IP protocols, while "unreliable" in the
>>> technical sense of the term, require a higher overall reliability
>>> than a typical raw wireless connection.
>>>
>>> What this says (and I'm a bit surprised to note this), is that sites
>>> considering using ID-1 radios for data communications, may find that
>>> even with the tighter siting requirements of 5.9GHz, that the latter
>>> may be more successful (whether or not part of HamWAN). In addition
>>> to being a lower-cost radio with a much higher data rate, the
>>> MikroTik radios offer a built-in router, which can obviate the need
>>> for a separate router.
>>>
>>> -- Dean
>>>
>>> ps: The callsign and digital code filtering features of D-Star that
>>> we previously discussed, are not available (greyed out in the
>>> software) for digital *data* mode. Huh? Another fine example of
>>> software of the "seven last words" of poor program design: *"Why
>>> would you want to do that?"*
>>>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140527/f6890a88/attachment.html>
More information about the PSDR
mailing list