1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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?"
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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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?"***
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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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/#!/john_hays> <http://www.facebook.com/john.d.hays> On Tue, May 27, 2014 at 4:28 PM, Bart Kus <me@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 listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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@bartk.us <mailto:me@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@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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@bartk.us <mailto:me@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?"*
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@bartk.us <mailto:me@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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@bartk.us <mailto:me@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
http://www.jarl.com/d-star/shogen.pdf Section 2.1.1 ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Wed, May 28, 2014 at 5:12 PM, Bart Kus <me@bartk.us> 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@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 listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Dean, Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue. 1. There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss. 2. We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned. 3. At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned. 4. John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength. 5. I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path. About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS. Bob - KE7JL From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Saturday, May 24, 2014 10:20 AM To: Puget Sound Data Ring Subject: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] 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?"
When you attempt to ping using the K7LWH/DD module, what IP address do you specify? On 2014-05-24 14:36, Bob wrote:
Dean,
Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue.
1.There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss.
2.We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned.
3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned.
4.John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength.
5.I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path.
About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS.
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 10:20 AM *To:* Puget Sound Data Ring *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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?"*
The router is setup as follows: IP: 10.136.19.168 Sub Mask: 255.0.0.0 Gateway: 10.0.0.1 DNS: 10.0.0.2 Alt: 10.0.0.1 Bob From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Saturday, May 24, 2014 9:33 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] When you attempt to ping using the K7LWH/DD module, what IP address do you specify? On 2014-05-24 14:36, Bob wrote: Dean, Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue. 1. There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss. 2. We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned. 3. At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned. 4. John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength. 5. I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path. About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS. Bob - KE7JL From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Saturday, May 24, 2014 10:20 AM To: Puget Sound Data Ring Subject: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] 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?"
Ah, I'd like the IP address you are PINGing. What do you type after the command "ping"? On 2014-05-25 10:22, Bob wrote:
The router is setup as follows:
IP: 10.136.19.168
Sub Mask: 255.0.0.0
Gateway: 10.0.0.1
DNS: 10.0.0.2
Alt: 10.0.0.1
Bob
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 9:33 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
When you attempt to ping using the K7LWH/DD module, what IP address do you specify?
On 2014-05-24 14:36, Bob wrote:
Dean,
Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue.
1.There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss.
2.We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned.
3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned.
4.John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength.
5.I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path.
About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS.
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 10:20 AM *To:* Puget Sound Data Ring *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I'm presuming that you are PINGing the gateway (10.0.0.1), which in normal circumstances will respond to PINGs, but I thought I'd ask ... On 2014-05-26 09:01, Dean Gibson AE7Q wrote:
Ah, I'd like the IP address you are PINGing. What do you type after the command "ping"?
On 2014-05-25 10:22, Bob wrote:
The router is setup as follows:
IP: 10.136.19.168
Sub Mask: 255.0.0.0
Gateway: 10.0.0.1
DNS: 10.0.0.2
Alt: 10.0.0.1
Bob
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 9:33 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
When you attempt to ping using the K7LWH/DD module, what IP address do you specify?
On 2014-05-24 14:36, Bob wrote:
Dean,
Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue.
1.There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss.
2.We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned.
3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned.
4.John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength.
5.I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path.
About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS.
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 10:20 AM *To:* Puget Sound Data Ring *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
It was over four years ago that I started this project. At the time my knowledge of networking was 2 of a scale of 10. Today I might be a 3.5; still have a lot to learn. Initially I had a XP lap top connected directly to the ID-1. It was configured the same as the router below. I started by pinging the gateway. LWHC has a number of IP addresses assigned, not all will reply to a pings. I use "ping 10.0.0.1" (basic garden verity ping) to determine if I had a usable path. I then "ping Comcast.net" and got an average reply time of 243ms through the ID-1 and K7LWH-DD. This compares to a Concast.net ping using my commercial (Comcast) account of 98ms. I then connected to Bing.com, Google.com and ARRL.org through K7LWH-DD using Internet Explorer. The performance, subjectively, was a little better than a dial up connection. I stopped most work on our high speed data project in early 2012. I reactivated it as a feasibility study rather than an implication project. I now have the ID-1 connected to a router. With a Windows7 computer connected to the router, I can "ping 10.0.0.1" with average times between 110 and 120 ms. Internet Explore does not connect to Bing, Google, nor ARRL.org and Packlink indicates that it cannot fine a path to a Winlink CMS but somehow messages get to the CMS via telnet connection. Anyhow, at least for now, we have an alternate path to get emails out of Kirkland if we lose internet at the City Hall. I am changing the focus of high speed data transfer away from the ID-1 to HamWAN and NW-MESH. Regards Bob - KE7JL From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Monday, May 26, 2014 9:01 AM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] Ah, I'd like the IP address you are PINGing. What do you type after the command "ping"? On 2014-05-25 10:22, Bob wrote: The router is setup as follows: IP: 10.136.19.168 Sub Mask: 255.0.0.0 Gateway: 10.0.0.1 DNS: 10.0.0.2 Alt: 10.0.0.1 Bob From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Saturday, May 24, 2014 9:33 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] When you attempt to ping using the K7LWH/DD module, what IP address do you specify? On 2014-05-24 14:36, Bob wrote: Dean, Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue. 1. There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss. 2. We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned. 3. At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned. 4. John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength. 5. I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path. About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS. Bob - KE7JL From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Dean Gibson AE7Q Sent: Saturday, May 24, 2014 10:20 AM To: Puget Sound Data Ring Subject: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine] 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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
If you want to try to PING the ID-1 at Snohomish County DEM, try the following settings: In your ID-1: * Mode: DD * Frequency: 1297.750 In your router: * IP address: 172.20.10.2 (this is unique for you) * Netmask: 255.255.0.0 * Gateway: 172.20.20.254 * DNS servers: (doesn't matter at this point) Let me know how it goes ... -- Dean On 2014-05-26 11:14, Bob wrote:
It was over four years ago that I started this project. At the time my knowledge of networking was 2 of a scale of 10. Today I might be a 3.5; still have a lot to learn.
Initially I had a XP lap top connected directly to the ID-1. It was configured the same as the router below.
I started by pinging the gateway. LWHC has a number of IP addresses assigned, not all will reply to a pings.
I use "ping 10.0.0.1" (basic garden variety ping) to determine if I had a usable path.
I then "ping Comcast.net" and got an average reply time of 243ms through the ID-1 and K7LWH-DD. This compares to a Concast.net ping using my commercial (Comcast) account of 98ms.
I then connected to Bing.com, Google.com and ARRL.org through K7LWH-DD using Internet Explorer. The performance, subjectively, was a little better than a dial up connection.
I stopped most work on our high speed data project in early 2012. I reactivated it as a feasibility study rather than an implementation project.
I now have the ID-1 connected to a router. With a Windows7 computer connected to the router, I can "ping 10.0.0.1" with average times between 110 and 120 ms. Internet Explore does not connect to Bing, Google, nor ARRL.org and Packlink indicates that it cannot find a path to a Winlink CMS but somehow messages get to the CMS via telnet connection.
Anyhow, at least for now, we have an alternate path to get emails out of Kirkland if we lose Internet at the City Hall. I am changing the focus of high speed data transfer away from the ID-1 to HamWAN and NW-MESH.
Regards
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Monday, May 26, 2014 9:01 AM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
Ah, I'd like the IP address you are PINGing. What do you type after the command "ping"?
On 2014-05-25 10:22, Bob wrote:
The router is setup as follows:
IP: 10.136.19.168
Sub Mask: 255.0.0.0
Gateway: 10.0.0.1
DNS: 10.0.0.2
Alt: 10.0.0.1
Bob
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 9:33 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
When you attempt to ping using the K7LWH/DD module, what IP address do you specify?
On 2014-05-24 14:36, Bob wrote:
Dean,
Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue.
1.There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss.
2.We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned.
3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned.
4.John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength.
5.I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path.
About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS.
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 10:20 AM *To:* Puget Sound Data Ring *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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?"*
I hasten to add, the IP address you want to PING, is (currently) 10.0.0.1. For lurkers: Yes, DHCP is enabled on the RF side of the router at the DEM, but if you are having trouble connecting with PINGs, the probability of a successful DHCP IP assignment will be low. On 2014-05-26 15:15, Dean Gibson AE7Q wrote:
If you want to try to PING the ID-1 at Snohomish County DEM, try the following settings:
In your ID-1:
* Mode: DD * Frequency: 1297.750
In your router:
* IP address: 172.20.10.2 (this is unique for you) * Netmask: 255.255.0.0 * Gateway: 172.20.20.254 * DNS servers: (doesn't matter at this point)
Let me know how it goes ...
-- Dean
On 2014-05-26 11:14, Bob wrote:
It was over four years ago that I started this project. At the time my knowledge of networking was 2 of a scale of 10. Today I might be a 3.5; still have a lot to learn.
Initially I had a XP lap top connected directly to the ID-1. It was configured the same as the router below.
I started by pinging the gateway. LWHC has a number of IP addresses assigned, not all will reply to a pings.
I use "ping 10.0.0.1" (basic garden variety ping) to determine if I had a usable path.
I then "ping Comcast.net" and got an average reply time of 243ms through the ID-1 and K7LWH-DD. This compares to a Concast.net ping using my commercial (Comcast) account of 98ms.
I then connected to Bing.com, Google.com and ARRL.org through K7LWH-DD using Internet Explorer. The performance, subjectively, was a little better than a dial up connection.
I stopped most work on our high speed data project in early 2012. I reactivated it as a feasibility study rather than an implementation project.
I now have the ID-1 connected to a router. With a Windows7 computer connected to the router, I can "ping 10.0.0.1" with average times between 110 and 120 ms. Internet Explore does not connect to Bing, Google, nor ARRL.org and Packlink indicates that it cannot find a path to a Winlink CMS but somehow messages get to the CMS via telnet connection.
Anyhow, at least for now, we have an alternate path to get emails out of Kirkland if we lose Internet at the City Hall. I am changing the focus of high speed data transfer away from the ID-1 to HamWAN and NW-MESH.
Regards
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Monday, May 26, 2014 9:01 AM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
Ah, I'd like the IP address you are PINGing. What do you type after the command "ping"?
On 2014-05-25 10:22, Bob wrote:
The router is setup as follows:
IP: 10.136.19.168
Sub Mask: 255.0.0.0
Gateway: 10.0.0.1
DNS: 10.0.0.2
Alt: 10.0.0.1
Bob
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 9:33 PM *To:* Puget Sound Data Ring *Subject:* Re: [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
When you attempt to ping using the K7LWH/DD module, what IP address do you specify?
On 2014-05-24 14:36, Bob wrote:
Dean,
Here are some observations and conclusion that I have come up with in adding the ID-1 to the Kirkland Emergency Communications Team's tool box. I have done a number of tests of the ID-1 from various locations in Kirkland in both the Digital Data (DD) mode and the Digital Voice (DV) mode. I tested simplex paths (ID-1 to ID-1) and paths to the Lake Washington Ham Club (LWHC) DSTAR DV repeater and DD gateway nodes in Bellevue.
1.There are a few locations in Kirkland that have direct visual line of site to LWHC Gateway in Belleview. From those locations, pings are consistently returned in 100 to 200ms with an occasional loss.
2.We have two location (Stations 22 and 25) are not visual but according to Radio Mobile modeling skim the terrain. At these sights no ping are returned.
3.At my home QTH (Lat: 47.694 Lon: -122.2161) I do not have a visual of the LWHC Gateway, but I get occasional pings returned.
4.John Hays loan me a 1.23 GHz directional antenna. With the directional antenna I detected two paths to the gateway. One was off a condo about 180 degrees from the gateway about a mile away; the other was off the NOAA building four miles awat at Sand Point about 15 degrees clockwise from the gateway. This indicates the presents of multi-paths that could be interfering with the data even with good signal strength.
5.I will also confirm the DV mode is more robust than the DD mode, but it too is affect by multi-path.
About 2 weeks ago I brought the ID-1 on line to serve as an alternate path to the Winlink CMS.
Bob -- KE7JL
*From:*PSDR [mailto:psdr-bounces@hamwan.org] *On Behalf Of *Dean Gibson AE7Q *Sent:* Saturday, May 24, 2014 10:20 AM *To:* Puget Sound Data Ring *Subject:* [HamWAN PSDR] 1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
participants (4)
-
Bart Kus -
Bob -
Dean Gibson AE7Q -
John D. Hays