1
Feature Requests / Re: Disable Audio Stream Menu Option for Digital Modes
« on: 2023-04-08, 21:07:55 »
Upvote....
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
General discussion forum / Re: Constant Buzzing Sound in my Transmit Audio
« on: 2020-05-28, 23:36:48 »
You might record the audio using your phone, etc. and post it here.
3
Hardware, Cabling, Installations / Re: Com Port Slowly Becomes intermittent and Totally Unusable
« on: 2020-03-09, 20:19:25 »
Just to add to the discussion - while my connection is 100%, the apparent speed my serial connections seem to vary significantly during the day (can be 2:1 or 3:1 difference at various times).
I am using COM1 and COM2 this way:
W7 Hardware Serial Port <> Passive Serial Cable <> RRC Control <> Internet <> RRC Radio <> Passive Serial Cable <> Zetron Repeater Controller Serial Port
Connection is 100% except for the extreme speed variation. Of course, this could be internet variations as well.
I am using COM1 and COM2 this way:
W7 Hardware Serial Port <> Passive Serial Cable <> RRC Control <> Internet <> RRC Radio <> Passive Serial Cable <> Zetron Repeater Controller Serial Port
Connection is 100% except for the extreme speed variation. Of course, this could be internet variations as well.
4
General discussion forum / SIP unable to connect; "Other Party" shows unfamiliar IP addr. (solved)
« on: 2019-11-27, 21:27:09 »
This is for information only.
I had a completely reliable connection that would consistently auto-connect following outages, etc. for about four months. Used public routable IPs on both ends, no firewalls. Not one connection problem (other than a ISP outage) in 4 months, and we maintain a 24/7 nailed-up connection.**
I dropped the connection for about one hour to rearrange some DC wiring and could not reconnect. Sip error, and a UDP error. Rebooted in various sequences many times. But nothing had changed. I then noticed that the Radio RRC showed an ip address of 172.83.45.42 (actual) in the "Other Party" field. That is not one of mine, as it should be from the Control RRC when connected. I have a managed switch at the site so I disabled the switch port supporting the Radio RRC overnight, then was able to re-connect in the morning.
I found a message here indicating that this condition might be Carrier Grade NAT (CGN), but the radio end is supplied by a small ISP so that is unlikely.
I then sniffed the traffic coming into the Radio RRC and noted that the IP above was coming in with a destination UDP port that matched the default SIP port, every few seconds. My guess is that these were possibly SIP connection attempts, but they did not know the password as it never showed connected. It remains unclear why I could not connect between their attempts as there was not a flood of these. Maybe the RRC locks out/delays repeated attempts, and the access attempt was regular enough to prevent me from connecting.
I just changed all of the default ports on the devices, including the Web server port, which might resolve this issue for a while. This is becoming mroe important over the last few years.
** Unrelated, we had the radio end running through a firewall and nat'ed before this current arrangement. This arrangement was extremely unreliable from a auto-reconnect perspective. Maybe I had the ports setup wrong, but sniffing showed that that the Control RRC's auto-reconnection attempts would often use the default destination port numbers to reach the Radio RRC, instead of the ones I set for for it. As a result, it would get stopped by the firewall and not re-connect. We had two Radio RRCs on the same site router so one had to use non-default ports. I believe this problem remains in V2.95. FYI.
I had a completely reliable connection that would consistently auto-connect following outages, etc. for about four months. Used public routable IPs on both ends, no firewalls. Not one connection problem (other than a ISP outage) in 4 months, and we maintain a 24/7 nailed-up connection.**
I dropped the connection for about one hour to rearrange some DC wiring and could not reconnect. Sip error, and a UDP error. Rebooted in various sequences many times. But nothing had changed. I then noticed that the Radio RRC showed an ip address of 172.83.45.42 (actual) in the "Other Party" field. That is not one of mine, as it should be from the Control RRC when connected. I have a managed switch at the site so I disabled the switch port supporting the Radio RRC overnight, then was able to re-connect in the morning.
I found a message here indicating that this condition might be Carrier Grade NAT (CGN), but the radio end is supplied by a small ISP so that is unlikely.
I then sniffed the traffic coming into the Radio RRC and noted that the IP above was coming in with a destination UDP port that matched the default SIP port, every few seconds. My guess is that these were possibly SIP connection attempts, but they did not know the password as it never showed connected. It remains unclear why I could not connect between their attempts as there was not a flood of these. Maybe the RRC locks out/delays repeated attempts, and the access attempt was regular enough to prevent me from connecting.
I just changed all of the default ports on the devices, including the Web server port, which might resolve this issue for a while. This is becoming mroe important over the last few years.
** Unrelated, we had the radio end running through a firewall and nat'ed before this current arrangement. This arrangement was extremely unreliable from a auto-reconnect perspective. Maybe I had the ports setup wrong, but sniffing showed that that the Control RRC's auto-reconnection attempts would often use the default destination port numbers to reach the Radio RRC, instead of the ones I set for for it. As a result, it would get stopped by the firewall and not re-connect. We had two Radio RRCs on the same site router so one had to use non-default ports. I believe this problem remains in V2.95. FYI.
5
General discussion forum / Re: Control end occasionally uses wrong destination ports (defaulting to 1300X)
« on: 2019-01-26, 23:28:55 »
Seeing same problem I originally described again today. Units would not connect. Rebooted both ends, still no connection. Two issues were noted while packet sniffing at the Firewall on the Remote (Control on public static IP):
- Control was configured to use 15000-15002 towards Remote, but it was likely using 13000-13002 towards the Remote; firewall would not pass as its expecting 15000-15002 (with NAT to 13000-13002).
- Remote was transmitting towards Control using a LAN source port of 13001 and Destination port of 15000 (should this be 15001???)...this may be unrelated and normal; its not clear.
Rebooted Remote end and they finally connected. The Remote is now transmitting a LAN source port of 13001 and Destination port of 15001 (same for 13000>15000 and 13002>15002).
Does the order in which the remote and control are rebooted matter, when some firewall NAT is being used? I am guessing there is a condition that creates this, but its difficult to reproduce.
- Control was configured to use 15000-15002 towards Remote, but it was likely using 13000-13002 towards the Remote; firewall would not pass as its expecting 15000-15002 (with NAT to 13000-13002).
- Remote was transmitting towards Control using a LAN source port of 13001 and Destination port of 15000 (should this be 15001???)...this may be unrelated and normal; its not clear.
Rebooted Remote end and they finally connected. The Remote is now transmitting a LAN source port of 13001 and Destination port of 15001 (same for 13000>15000 and 13002>15002).
Does the order in which the remote and control are rebooted matter, when some firewall NAT is being used? I am guessing there is a condition that creates this, but its difficult to reproduce.
6
General discussion forum / Re: Control end occasionally uses wrong destination ports (defaulting to 1300X)
« on: 2018-12-18, 00:59:44 »
There is no router on the Control end - so there is no way for the ports to be translated. The pic of the router screen was from the radio side, on the WAN side of router. This shows the Control settings (left), versus what the remote site was seeing.
Besides, once I rebooted the Control RRC, the radio side showed 15000, which is the correct port.
I edited my earlier comments above to clarify that the router pic was what was received at the radio site router.
Greg
Besides, once I rebooted the Control RRC, the radio side showed 15000, which is the correct port.
I edited my earlier comments above to clarify that the router pic was what was received at the radio site router.
Greg
7
General discussion forum / Re: Internet Data Usage of RemoteRig
« on: 2018-12-18, 00:18:45 »
I use mine to connect two remote two serial and two audio connections 24/7/365. 300-600 kbps. I wish we had a Carrier Operated Switch (COS) input to keep reduce the usage (not VOX).
8
General discussion forum / Control end occasionally uses wrong destination ports (defaulting to 1300X)
« on: 2018-12-17, 22:13:30 »
Control unit occasionally uses default port numbers (1300X), not the ones I have set (1500X) under Advanced Settings / Ports. However, the port numbers *displayed* using the web interface for the Control side remain the ones I have set; these never change. When this problem occurs, the Control unit hangs and will not reconnect (even if I manually hit the Connect button). The Control end must be rebooted/restarted. Proved this yesterday while sniffing IP traffic. The Control was using 1300X towards the remote site (as the destination port) even though it has always been set for 1500X.
The attached snip was from the control (left side) while the right shows what was coming into the remote router at the radio side.
The radio end uses NAT (WAN incoming Port 1500X> NAT > LAN Port 1300X) since we have another Radio RCC there using the 1300X series ports. Control end is a public IP, no NATTing, firewall, etc.
Not yet sure what creates this condition. I had cycled power at the Radio end when it occurred. But I cannot reproduce this. Yet, this continues to occur every few weeks or months.
Using V2.91. The Source (173.) and Destination (208.) are from the Control end (208. is the remote site). Remote site router is only listening for 1500X. Packets are dropped at the remote Radio site.
The attached snip was from the control (left side) while the right shows what was coming into the remote router at the radio side.
The radio end uses NAT (WAN incoming Port 1500X> NAT > LAN Port 1300X) since we have another Radio RCC there using the 1300X series ports. Control end is a public IP, no NATTing, firewall, etc.
Not yet sure what creates this condition. I had cycled power at the Radio end when it occurred. But I cannot reproduce this. Yet, this continues to occur every few weeks or months.
Using V2.91. The Source (173.) and Destination (208.) are from the Control end (208. is the remote site). Remote site router is only listening for 1500X. Packets are dropped at the remote Radio site.
9
Configuration, RRC 1258 / Re: Advanced Settings / Ports (Control Side)
« on: 2018-12-17, 19:57:09 »
Thanks Mitch - that is exactly how I have used them since we have two radio RRC's at the remote site; this path to the site uses different ports.
I will post the issue I am seeing separately. Basically, the Control unit occasionally uses its default port numbers (1300X), not the ones I have set. However, the port numbers shown using the web interface remain the correct ones. When this occurs, the control unit hangs and will not reconnect (even if I manually hit the Connect button). The Control end must be rebooted/restarted. Proved this yesterday while sniffing IP traffic. It was using 1300X towards the remote site even though it has always been set for 1500X.
It is NATed at the radio end (Port 1500X> NAT > Port 1300X). Control end is a public IP, no NATTing, firewall, etc.
Note sure what creates this condition yet. I had cycled power at the Radio end. But I cannot reproduce yet. Yet, this continues to occur every few weeks or months.
I will post the issue I am seeing separately. Basically, the Control unit occasionally uses its default port numbers (1300X), not the ones I have set. However, the port numbers shown using the web interface remain the correct ones. When this occurs, the control unit hangs and will not reconnect (even if I manually hit the Connect button). The Control end must be rebooted/restarted. Proved this yesterday while sniffing IP traffic. It was using 1300X towards the remote site even though it has always been set for 1500X.
It is NATed at the radio end (Port 1500X> NAT > Port 1300X). Control end is a public IP, no NATTing, firewall, etc.
Note sure what creates this condition yet. I had cycled power at the Radio end. But I cannot reproduce yet. Yet, this continues to occur every few weeks or months.
10
Configuration, RRC 1258 / Advanced Settings / Ports (Control Side)
« on: 2018-12-17, 05:43:53 »
Are the ports listed here (see attached) outgoing (destination) ports or incoming (source) ports, from the perspective of the Control Side?
By outgoing, I mean the packets leaving the control side , towards the Radio side. Incoming would be from the Radio side, towards the control.
I am noticing some strange port assignment issues, once I find the Control Unit in "disconnected" mode, when it has Auto Reconnect set for "Yes".
Greg
By outgoing, I mean the packets leaving the control side , towards the Radio side. Incoming would be from the Radio side, towards the control.
I am noticing some strange port assignment issues, once I find the Control Unit in "disconnected" mode, when it has Auto Reconnect set for "Yes".
Greg
11
General discussion forum / Re: RRC Just Unusable Over Wireless ISP at Radio Side
« on: 2018-12-07, 03:31:20 »
I will echo the Ubiquity product comment above. We originally had a very poor WISP connection (it was free, but signal was off the side of this ISP's distribution antenna; packet loss due to poor margin). We then purchased internet from a different WISP, located at a different site, about 22 miles from our desired (radio RRC) site. This new ISP obtained his internet from a large data center, one (licensed) microwave hop away, so he was solid.
We then installed a Ubiquity 3.5 GHz Rocket product between his site and our radio RRC site. 38 dB margin (using 26" dishes) and it has only dropped for about 3 minutes in three years (better than 99.999% availability). 10-30 Mbps, TDD. $850 total. Just works.
There are no open 2.4 or 5.6 GHz channels in the San Fransicko Bay Area region, so we used the clear 3.5 GHz band and worked hard to get 3.5 GHz international radio models.
Do you have a place you could connect to, line-of-sight, within about 22 miles? We were lucky as the ISP site was 1450' AMSL, and our radio RCC sites was 2200' AMSL, no obstructions.
We then installed a Ubiquity 3.5 GHz Rocket product between his site and our radio RRC site. 38 dB margin (using 26" dishes) and it has only dropped for about 3 minutes in three years (better than 99.999% availability). 10-30 Mbps, TDD. $850 total. Just works.
There are no open 2.4 or 5.6 GHz channels in the San Fransicko Bay Area region, so we used the clear 3.5 GHz band and worked hard to get 3.5 GHz international radio models.
Do you have a place you could connect to, line-of-sight, within about 22 miles? We were lucky as the ISP site was 1450' AMSL, and our radio RCC sites was 2200' AMSL, no obstructions.
12
Feature Requests / Re: Consider Google DNS for Dynamic DNS Provider
« on: 2018-12-05, 01:59:11 »
I am paying for Google Domain anyways so no effective cost to me. Routers are all Mikrotik with nothing built-in without add-in scripts. But since they were supporting a commercial service like Dyn, I figured Google might a be a good replacement given their current market dominance.
13
Feature Requests / Re: Consider Google DNS for Dynamic DNS Provider
« on: 2018-12-04, 02:17:23 »
That remains an option. But I will take a guess that their server is not in North America, so this may not be as reliable. Also, remote radio sites are hours away; if we lose access, its a good part of the day to get there and back.
G
G
14
Feature Requests / Consider Google DNS for Dynamic DNS Provider
« on: 2018-12-03, 19:12:00 »
I used Dyndns for years; it was free when I started but was astonished to find that they wanted $55 annually now. Shame on me for using auto-pay and ignoring their price increases. We are done.
Microbit might consider adding Google DNS - looks to be a straightforward protocol.
https://support.google.com/domains/answer/6147083?hl=en#
I already had a domain URL for my email through Google (only $10/yr.) - they allow you to use your own domain instead if having to use one of theirs. Really simple to setup, and allows you to enter your own static IP for address and associate it with a domain URL. Simply add and "A record".
Microbit might consider adding Google DNS - looks to be a straightforward protocol.
https://support.google.com/domains/answer/6147083?hl=en#
I already had a domain URL for my email through Google (only $10/yr.) - they allow you to use your own domain instead if having to use one of theirs. Really simple to setup, and allows you to enter your own static IP for address and associate it with a domain URL. Simply add and "A record".
15
General discussion forum / Re: Audio Hiss Solved
« on: 2018-10-09, 20:38:43 »
Thanks. 16-bit worked here as well. I was using Quality-0, "A-Law 8 kHz" and we had hiss. It came from the radio end, and I thought it was the radio generating this (one channel was speaker audio that might have had audio PA hiss, but the second audio channel was low-level [300 mV] discriminator audio from a Motorola XPR4550 mobile radio). Both channels had equal hiss before the fix. Both are now fixed.
I modified the second audio channel input (ring, not tip) on the radio end to make it high-impedance (>100k ohm) so it would not load down the discriminator line. This channel still has a bit more hiss, but its more than tolerable.
N6LDJ
I modified the second audio channel input (ring, not tip) on the radio end to make it high-impedance (>100k ohm) so it would not load down the discriminator line. This channel still has a bit more hiss, but its more than tolerable.
N6LDJ
Pages: [1]