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.


Messages - VA2MM

Pages: [1] 2
1
Hello Mike and thanks for the reply. As unlikely as it may seem, there are indeed brief ptt blips whenever I spin the remote VFO and this is easily reproducible on my system. This only happens via remoteRig (never locally on radio). If you are interested, I could send you a video clip of the effect.

Since PTT is exerted by the RTP audio stream, it seems to me that the radio RRC must be occasionally  receiving  a spurious RTP segment when I turn the VFO (or when there is Com1 CAT traffic), either sent as such by the control RRC, or perhaps they are serial control packets that somehow get forwarded  to an RTP port. Maybe it's a port forwarding issue on my router, but it seems strange that that should be intermittent. .

I will be traveling to the radio site this weekend and I'll take me control setup with me so I can do some tests with both RRCs on the same network to try to isolate the cause. I might try to look at the RTP stream with wire shark as I reproduce the problem.

Regard and 73

Mark VA2MM

2
No replies? Does any else at least experience brief spurious radio PTTs when turning the VFO? My setup has always done that. Any feedback or ideas would be appreciated.

3
I have been using a K3 Twin setup for a few years now and it generally works well. Lately I've been doing more CW and a long-standing issue that I have put up with on SSB is harder to live with in CW mode.

When I connect my logging program (at the control site) to the remote ratio via Com1 (USB) of the control RRC, the radio occasionally sees very short (few ms) spurious PTT and/or CW keying every few seconds. It does occur in SSB mode but it is much less obtrusive and seems less frequent on SSB than on CW where there are short bursts of on/off PTT and keying (side-tone blips). If I turn off Radio CAT control on my logging program, the problem disappears.

I do not suspect my logging software itself as the cause because this problem does not occur when directly connected to the radio, nor when connected via the radio RRC local COM1 at the radio site (I use mode-7 for COM1). 

It may be bandwidth related because PTT and keying blips occur more often if I increase the the baud rate of COM1. It is tolerable at 4800 bps but quite annoying at 38400 bps. However, the VoIP bandwidth seems fine (no audio drop-outs, except obviously during spurious PTT). COM2 is 38400 bps, per recommended K3 Twin settings.

Another (probably related) issue is that the radio sees brief spurious PTTs when I spin the VFO knob on the control end. This occurs even when I'm not using CAT control and the PTT blips stop as soon as I stop turning the VFO knob).

Currently running RRC firmware 2.9

Any ideas?

4
I rebooted my computer and now it recognizes the RRC USB again.

Thanks,

Mark VA2MM

5
I just upgrade the firmware on my pair of RRC1225MKIIs. I have used them successfully for several years on my Mac with various MacOS version (currently MacOS 10.11). After the RRC firmware upgrade, the USB connection is no longer recognized by MacOS. I would like to downgrade the firmware version, but I unfortunately failed to note what the original firmware version was (it was about 2 years old).

What version would you suggest that I roll back to in order to restore USB recognition, or do you have another solution to suggest?

Thanks,

Mark VA2MM

6
I can shed some light on this. I use the RRC on the Bell network and it took me a while to get it working (they don't make it easy).

What the others say is true, there is double natting so the WAN side of your router has a private IP address. That is a problem, but not the only problem. Unfortunately, just using DDNS to map to a public address is not sufficient because Bell seems to block incoming connections to the public addresses.  The only way I was able to get it to work is to set up a VPN between my remote site and my control site. There are different ways of doing that, including routers at each end that have site-site VPN capability. Another way is use a computer at remote site that hosts the VPN session. I use LogmeIn Hamachi and some router software on a desktop computer at the remote site for this, but you should also be able to do it with a raspberry pi running free RemoteQTH server software to do the VPN.

I hope that helps, and that it doesn't completely discourage you.

73 Mark VA2MM


7
Just for reference, I found that the problem was related to the RRC USB port. Switching to an external USB-Serial adaptor solved the corrupted serial data problem. 

I am now using a K3 rig, and have not had any problems with the RRC's USB serial to CAT function.

Mark VA2MM

8
I think you definitely want to use the keyer in the RRC and only use straight CW keying from the RRC-Radio into the '706. If you were to use the '706's internal keyer, the latency would drive you nuts because there would be a delay between your paddle movements and whatever (if any) side-tone that you hear.

When you use the RRC keyer, the side-tone is generated locally and it sounds normal with no delay.

Good luck

Mark VA2MM

9
Configuration, RRC 1258 / K3 Utility over RRC CAT link
« on: 2014-09-27, 19:05:00 »
I have seen on previous posts that the K3 Utility program is supposed to work over the RRC CAT link radio K3 configuration, but not for firmware updates. I can live with that but in my case I can't get the K3 Utility to find the K3 at all, even though my logging software can connect and control the K3 just fine using COM1 to COM2 (Mode 7).

The 4 RRC USB virtual ports show up in the K3 Utility, but the K3 does not respond on any of them. When I use the logging program, the K3 responds fine on the the third RRC USB virtual port.

I use the Mac version of K3 Utility, but I have also tried this on a PC with the Windows version of K3 Utility (same result).

Here are my serial settings:

Control Serial settings

COM1 mode   Mode-7
COM1 baudrate   4800
COM1 data bits   8
COM1 stop bits   1
COM1 parity   0-Off
COM1 rts/cts   Yes
COM1 terminator (hex)   00
Use USB Com Port as COM1   Yes
    
COM2 mode   Logical parallel with COM0
COM2 baudrate   9600
COM2 data bits   8
COM2 stop bits   1
COM2 parity   0-Off
COM2 terminator (hex)   00
Use USB Com Port as COM2   No
    
COM3 mode (USB-COMFSK)   Mode-10, Baudot-RTTY

Remote Serial settings

COM1 mode   Mode-7
COM1 baudrate   4800
COM1 data bits   8
COM1 stop bits   1
COM1 parity   0-Off
COM1 rts/cts   Yes
COM1 terminator (hex)   00
    
COM2 mode   Logical parallel with COM0
COM2 baudrate   9600
COM2 data bits   8
COM2 stop bits   1
COM2 parity   0-Off
COM2 terminator (hex)   00

Any suggestions?

Regards

Mark VA2MM

10
Hardware, Cabling, Installations / Re: Haunted keyer
« on: 2014-09-27, 17:46:52 »
FYI, replacing D13 solved the problem. I'm sure it wasn't caused by a lightning though because it's at the control end and never left the protected well-environment of my apartment, so perhaps a defective component.

Regards

Mark VA2MM

11
Hardware, Cabling, Installations / Re: Haunted keyer
« on: 2014-09-18, 22:32:43 »
Excellent.

The component layout is very helpful. I'll try removing D13, and if that clears the problem, I'll replace it with a new one. It will probably be easier for me to get the diode array locally than you having to send it.

Thanks again,

Mark VA2MM

12
Hardware, Cabling, Installations / Re: Haunted keyer
« on: 2014-09-18, 01:19:03 »
Thanks for the comments, Mike.

I attempting a bit of humour about the keyer sending CW by itself but there does seem to be an intermittent problem with the keyer circuit in my RRC control box. There is nothing stuck in the paddle or IO connector.

I've done a bit more investigation and it seems to be a hardware issue in the RRC.  The open-circuit voltage is different between In1 and In2 (or Tip and Ring of paddle connector), which does not seem normal to me at all. In1 (Ring) sits (unkeyed) at 8V but In2 (Tip) drifts between 6.5V and 6.8V. When it's down near 6.5, In2 is very sensitive: just touching the voltmeter probe to it causes it to send dits (even though the voltage is still 6.5V).

So, perhaps a defective clamping diode (D13) is pulling the voltage down, or a problem with the transistor pair DT1. Unfortunately, there is no RefDes silkscreening on the board, so hard to find my way around.

I could probably fix the symptoms by putting a pull-up resistor to 8V, but that could be just masking the root cause problem. What's the warranty on these boxes?

Mark VA2MM
                                                                                                                                                     

13
Hardware, Cabling, Installations / Haunted keyer
« on: 2014-09-17, 00:24:47 »
I recently activated the keyer function on the RRC, and it seems to work well. However, it sometimes works by itself, sending random CW. A hands-free function?  At first I thought it was faulty wiring in my paddle, but no, it even does it when the paddle (and the IO connector) is unplugged from the RRC box.  If I power cycle the RRC, it shuts up for a while, but eventually it sending again.

Anyone else run into an RRC with a CW mind of its own?  If so, how do you fix it?

Mark VA2MM

14
@EA5WA:  A site-to-site VPN with hardware VPN routers would be a more elegant solution but I had problems getting the routers to connect. Since the Hamachi solution works well for me, I abandoned the Cisco VPN routers for now, but I might give that another go eventually.

15
Could you explain how can I use Hamachi with RRC's. I use Hamachi with computers, but I don't know if is posible to create a VPN to connect both RRCs when you have a double-nat 3g connection.


Oh, its because I have a computer at the remote location running the Hamachi application. I know most people use RRC to avoid having a computer there, but it's the way I got it to work. I set up the local computer's IP address as the default gateway for the RRC, then set up a static route in the computer to the VPN gateway to my control location. I admit it's a bit complicated but it works well form me. 

Hope that clarifies my previous comment. 

73 Mark VA2MM

Pages: [1] 2