[HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
Dean Gibson AE7Q
hamwan at ae7q.com
Fri May 30 21:33:17 PDT 2014
The ID-1 has one of those cell-phone-like "3 bars" scales for signal
strength. When I set my home to ping the DEM (via the ID-1 radios), the
DEM ID-1 would sometimes show one bar (with no response), and then on
the next ping (one second later) show three bars, with a reply being
transmitted. At the time, there was no rain or appreciable wind, but
obviously something on the path was varying the signal strength. When
we tried FM voice a couple months ago (to evaluate the path for the
5SHPn), it was virtually free of noise; I don't recall if we tried DV
voice.
On 2014-05-28 20:27, Bart Kus wrote:
> Well yeah, you can't have ping without arp first, unless you configure
> static arp entries. :)
>
> So it looks like the protocol does support 1/2 FEC, and also enforces
> an FCS (CRC). The FEC starts after clock recovery and frame synch,
> which is optimal.
>
> Forget the FM receive thing, all I really wanted to know is what the
> SNR of the 1.2GHz signal you get from Paine? If the ID-1 doesn't tell
> you this, an RTL-SDR should. Does the link work in 4.8kbit mode? I'm
> assuming you have both sides set for 128kbit right now.
>
> --Bart
>
> On 5/28/2014 7:20 PM, Dean Gibson AE7Q wrote:
>> See http://www.arrl.org/files/file/D-STAR.pdf - pages 3-5 describe
>> the DD-mode (data) packet.
>>
>> The ID-1 apparently doesn't know whether or not the Ethernet frame is
>> corrupt. From the TX/RX lights for both the radio and the Ethernet
>> connection, it appears that every received packet from one end, goes
>> out the other.
>>
>> When conditions are right and I receive about 10% of the packets from
>> a PING (like last Monday), it seems clear from observed behavior that
>> once an ARP response is received, then quite a few PINGs get
>> through. I haven't tried listening on FM to a DD packet, but I can
>> try that on Thursday, when I am at the DEM. I'm not sure what the
>> point of that would be, though.
>>
>> On 2014-05-28 17:12, Bart Kus wrote:
>>> This is some really broad strokes. Are there specifics on ID-1
>>> protocol / framing somewhere?
>>>
>>> --Bart
>>>
>>> On 5/27/2014 4:59 PM, John D. Hays wrote:
>>>> ID-1 simply encapsulates an Ethernet frame behind a D-STAR header.
>>>> The header has some correction, but the Ethernet frame is not
>>>> corrected by D-STAR.
>>>>
>>>> ------------------------------------------------------------------------
>>>> John D. Hays
>>>> K7VE
>>>> PO Box 1223, Edmonds, WA 98020-1223
>>>> <http://k7ve.org/blog> <http://twitter.com/#%21/john_hays>
>>>> <http://www.facebook.com/john.d.hays>
>>>>
>>>>
>>>> On Tue, May 27, 2014 at 4:28 PM, Bart Kus <me at bartk.us
>>>> <mailto:me at bartk.us>> wrote:
>>>>
>>>> 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
>
>
>
> _______________________________________________
> 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/20140530/f6f25bd4/attachment.html>
More information about the PSDR
mailing list