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.

Topics - K3TN

Pages: [1] 2
We've been doing remote contesting for 4 years, using Remote Rig for controlling a K3 and VNC/RemAud/Wkremote to control remote shack PCs controlling FT5000s at two other positions. This started at K4VV back in 2014 or so and in 2017 transitioned to W4AAW after Jack's death.

There is no wired Internet connectivity available at W4AAW's Round Hill VA QTH and the RemoteRig connection becomes unusable quite often - lots of audio dropouts, loss of N1MM synch/connectivity, etc. The problem is short periods of high latency and essentially high level of jitter overall.

The VNC/RemAud approach works fine over these conditions. Have posted a number of times over the years to this forum and tried all the various settings and tweaks, make some progress but the dropouts never go away completely and overall improvement is minimal.  Usable for casual QSOs, but for contesting (or even trying to work a DX pileup) it is just not usable.

We finally gave up and have switched the K3 postion over the VNC/RemAud and PC remote control approach. Lose the ability to do the K3 Or K3/0 twin approach and remote paddle keying using Wkremote is far from as good as via the Remote Rig - but it works reliably.

I hate to give up completely - especially since free software solutions like VNC and RemAud seem to be able to work fine over the same Internet connection. Anything coming from Microbit in the future that might help?

73 John K3TN

The W4AAW remote operation has a K3 and RRC at the radio end. We use the N1MM contest logging software. The ISP is a wireless ISP and when jitter gets too high, we get audio problems - that can be a killer but that is not the only problem.

Frequently, even when the audio is flawless, we have N1MM lose contact with the K3 and pop up the "Radio Reset" message. If you notice, clicking on that (or right clicking on the band spread window and selecting Reset Radios) will cause it to recover.

If you don't notice, and QSY - obvious problems occur. It basically appears that the serial comms through the RRC to RRC audio+data channel gets disrupted and N1MM misses polling responses from the radio and says "Reset"

Is anyone else seeing this issue? There have been some code fixes played with in N1MM that limit the CAT functionality and eliminate the issue, but we need to see if others are having similar problems in order to convince the N1MM team that is more than just us!

Thanks and 73 John K3TN

We are on RRC firmware V2.90 at the W4AAW remote operation, using N1MM+ software. N1MM+ supports Winkey and controls the CW speed. It has three configurable options: (1) Ignore the speed pot on a Winkeyer; (2) Only use the speed pot; (3) Only use the speed pot for paddle and keyboard cw, use N1MM settings for canned CW messages.

V2.90 seems to have broken (1) - a paddle plugged into the RRC will always use the speed selected on the speed pot. I think this was fixed back in 2.85, I remember this was a problem before and had been fixed. I noticed 2.90 added a function to select configs using the speed pot - maybe that caused the breakage?

Is there currently a way to configure the RRC to allow software (like N1MM+) to fully control the CW speed, including speed sent when using a paddle plugged into the RRC? If not, is there a firmware update that could return that functionality?

Thanks and 73, John K3TN

The W4AAW remote operation has a remote K3/RRC position and two other remote positions that use Skype and VNC to remotely control PCs and FT2000s. The Internet connection is a broadband wireless service that is specified at 8Mbs down/2Mbs up.

We are having severe audio dropouts on the K3/RRC position while the other two positions Skype audio continues uninterrupted. We are also seeing frequent "Radio Reset" events with N1MM+ networking on the K3/RRC position, where N1MM says it has lost contact with the radio - does not happen on the other two positions that are running N1MM+ on PCs on the radio-side LAN.

The problem definitely seems Internet traffic related - if only the K3/RRC position is active *and* there is no local (non-shack) Internet use, the audio is fine. During a contest when the two positions running Skype (and N1MM network traffic) we start to see both the audio dropouts and increased N1MM radio resets. In that case, total network traffic as seen by the Internet router is generally under 100 Mbs.  Outside of a contest, if the non-shack use goes up above that level, we start to see the problem even when only the K3/RRC is active.

We are running RRC audio at the lowest bit rate. I've increased the jitter buffer/delay settings from the default of 4/3 to 8/6 and 12/8 without seeing improvement. I still have the packet size set at 20. That will be the next thing I will try.

Running a 100 ping test, the average latency is always below 25 ms but the max will usually show up as 250ms or as high as 500ms, but even longer ping tests come back with 0 percent packet loss.

Question:  What are typical jitter buffer/delay and packet size settings for dealing with this kind of scenario? Is increasing above 12/8, or increasing the packet size, likely to have any real impact? Or any other suggestions for how to solve audio and N1MM+ connectivity dropouts?

Thanks and 73, John K3TN

The N1MM+ logging software continually polls the radio for frequency/mode information and has a default threshold of 15 seconds - if after 15 seconds it hasn't gotten a response from the radio, it stops polling and requires the user to do a manual Radio Reset action.

At the W4AAW remote operation, we have a high incidence of this occurring. It seems worse for some users than others, but it happens to most. We are experimenting with lengthening the timeout parameter, but that does not address the cause - why is the local (operator-side) instance of N1MM+ not receiving polling responses from the remote K3?

Chris KL9A has recommended switching from using the min-USB and USB as COM1 approach to using the COM1 serial port on the RRC, which means using a USB to serial converter between the PC and the Control RRC for most. He said that improved things for his remote operation.

To the Microbit folks: is there some reason why *not* using the USB at COM1 approach should reduce data loss of N1MM+ polling? Most of this N1MM_ type communications is UDP-based at ports above 12040 - some reason why that would be less reliable using USB as COM1?

Thanks and 73, John K3TN

At the W4AAW remote operation, we are having a high level of N1MM+ "Reset Radio" events, which means the N1MM+ software has gone 15 seconds or more without receiving a response from N1MM+'s polling for frequency/mode information.

I noticed that a 2014 Elecraft firmware update (shown below) says it halts RemoteRig polling when the K3/Mini is PTTed. I've asked for details on what this means, but is there a chance that this lack of response could cause some kind of buffering or data loss in the RRC which then leads to loss of data transfer between the operator-side N1MM copy and the remote K3?

73 John K3TN

MCU 4.93 / DSP 2.83, 10-16-2014

* PSK63 MODE ADDED:  To select PSK31 or PSK63, first tap either end of the MODE switch to select DATA, then hold the DATA MD switch and use VFO A to select the PSK data rate.

* KAT500 POWER-ON REMINDER ON K3 DISPLAY: If a powered-off KAT500 is pulling the auxBus signal low when the K3 is first turned on, "TURN ON KAT500" is displayed. Previously this condition would lock up the K3 without explanation.

* K3/0-MINI TX NOISE REDUCTION:  Polling by Remote-Rig units is suspended during PTT use to reduce a "ticking" noise heard in some cases.

* Changes to synthesizer, KXV3, and KPA3 device drivers (no effect on normal operation).

We have password control turned on for the web interface. That seems to stop changes from any who don't know the password.

However, we recently had an issue where a remote user was VPNed into the radio LAN and started up Microbit Setup Manager to check version of his local Control RRC. The "finder" showed him both his local Control RRC and the Radio RRC at the remote site - and he accidentally changed the IP address of the Radio RRC to a local 10. IP address, knocking it off the air.

Took a while to figure this one out, since I didn't realize Setup Manager could even be used other than for direct USB connection and the remote site is a 90 mile drive...

Is there someway to apply password control for any remote changes made via Setup Manager?

73 JOhn K3TN

Hardware, Cabling, Installations / K3 ERR PTT
« on: 2016-02-28, 23:02:20 »
Using K3/0 or K3/Mini to connect to remote K3 over RRCs, started getting ERR PTT from the remote K3 on startup, indicating PTT was asserted on the remote K3 when it was attempting to power up.

Found that disconnected Control RRC from the K3 Mic jack avoided the error (checked both by removing mic jack connection and disconnecting RJ45 from the RRC - it is not a cable issue) - so, the Control RRC is asserting PTT on that connection.

On the control RRC page, PTT Status says off, but that does not seem to be the case.

Tried remote reset, had local guy  unplug power to the control RRC, tried soft reset with the button on the back panel - no joy, the problem remains.

Anything else to try besides hard reset on the remote button? If that (and restoring everything) doesn't solve the problem, anything other than a hardware fault possible?

Thanks, John K3TN

K3/Mini to K3 Twin configuration. all has been working fine with mic/headphone audio connected directly to the control RRC. I have it connected that way because connecting mic/headphone directly to the K3/Mini causes audio problems and Elecraft sent me a new I/O board. In testing the new board (didn't fix the problem, actually caused new problems until I put the old board back) when I returned the cabling back to the baseline configuration, foot pedal PTT stopped working.

The footpedal is connected to a Bose K3 adapter which is then connected to Microbit adapter to Mic/Aux on the control RRC. I tested the footpedal with a VOM, it switches. I connected the footpedal/headset/Bose adapter directly to a K3, it PTTs - and it PTTs when directly connected to the K3/Mini.

The only things left is the Microbit adapter that goes into Mic/Aux or the RRC itself. I've made no changes to the RRC settings, but did restart both boxes with no change. Tonight I'll try to ring out the adapter cable.

Any setting I should check or something else to look at that might cause a footpedal closure not to cause PTT?

73 John K3TN

General discussion / Micro-PC and PTT again
« on: 2015-03-20, 20:22:44 »
Someone posted a hardware mod to the dongle to have an RTS driven PTT, I'm aware of that. Is there any software approach planned in any update to the client?

I have a remote K3 that is used by myself and a few others with K3s and RRCs. We have one guy who doesn't have a K3 or an RRC but has acquired the Micro-PC client and can connect and hear audio, transmit using PTT on the dongle, etc.

For contests, we use N1MM and he currently can't use N1MM in  to send CW or to PTT and send recorded audio files in SSB, since there doesn't appear to be COM3 functionality or a way to do control-side PTT, other than modifying the dongle.

Is there plan for any upgrade to support such capability? Should he just plan on modifying the dongle? Any advice from Microbit?

73 John K3TN

I bought the "K3 Twin Stereo version" and have stereo cables on all audio connections in a K3/Mini to K3 Twin setup. The Control RRC label on the bottom has the S.

With the Dual RX setting OFF, if I turn the sub RX on I hear the audio mixed into both L and R audio channels.

When I turn the Dual RX setting ON, I hear the same thing - I do not hear the main in my left ear and the sub in my right ear.

Is there something else I need to do, other than changing that one setting?

73 John K3TN

Setup: K3/Mini to K3 through Remote Rig, running N1MM+ and Classic - all works FB in CW with Winkey etc.

For last weekend's ARRL DX SSB contest, we wanted to use the N1MM+ wav files - hit F1, recorded voice says "CQ TEST" etc. In order for that to work, need to pass PTT from the PC to the remote K3.

N1RM rigged up a xistor switch from a serial port to close PTT on the control side K3, which worked fine. I'm thinking there should be a way to pass N1MM PTT thru the RRCs to the radio side K3 and do PTT there without having to add hardware and tie up a serial port on the Control side.

I'm guessing it has something thing to do with I/O settings - USB RTS as PTT on the Control side? and/or the OUT modes on the Radio RRC?

Is there a recommended/standard way to do this?

73 John K3TN

General discussion forum / Web passwords
« on: 2015-02-27, 20:31:02 »
I decided to turn on web passwords on the Radio RRC. However, what I see on the RRC is different from the manual.

On the IP settings tab I see Web page user and then Web page pwd fields but then I see additional Web page user(saving) and then Web page pwd(saving) fields that aren't explained in the manual.

I assumed the (saving) fields were for entering and saving username/password, so I entered there. In order to change some parameters after submit/apply, a login box popped up - seemed good.

But the username/password stays in those fields and are visible to anyone who connects. Removing them from those fields then seems to turn authentication off - no login required.

What are the steps to require a username/password entry for editing, without leaving the username and password visible?

Thanks, John K3TN

Configuration, RRC 1258 / Serial Setting COM1 RTS/CTS
« on: 2015-02-25, 13:58:39 »
To debug some of the problems I'm having with N1MM software over RemoteRig, I did a setting by setting comparison between the settings W1UE uses and graciously sent to me, and how I have the two RRCs configured.

For some reason, I had COM1 RTS/CTS set to Yes and Dennis had it at the default NO setting. I changed that setting to NO, and with limited testing my problems seem to have disappeared.

The manual says that setting "enables transfer of CTS input to the RTS output of other RRC" but nothing says why you ever want to, or not want to, do that.

Is there some mode where I would need that capability? I'm thinking I turned it on when I got FSK RTTY working - would I need it there.

73, John K3TN

General discussion forum / Radio RRC Stopping During Contest
« on: 2015-02-22, 18:02:29 »
Been running K3 Twin in the ARRL DX CW, two different people taking turns connecting to the remote K3. We made over 3200 QSOs by early this morning when all of a sudden, in the middle of a run on 20m, the radio stopped responding (I have a K3?mini, the other guy is using his K3 in terminal mode.)

I could still hear rx audio, and I would hear sidetone when I hit the key, but the TX light wouldn't light on the K3 Mini, and there was no blanking of the RX audio when it was "sending" So, audio continued, data comms did not. Turned the K3 Mini off and on again - and got the busy signal and no connection whatsoever to the remote K3.

Found that the radio RRC could not be reached via browser. Pinging the remote router, showed all is fine there. Doing a remote VNC session to a PC on the radio LAN, still couldn't browse the RRC. The Microbit Setup Manager Find Devices command would find it, but it would launch a browser, and get no response. Pinging the RRC internal address from the radio LAN got no response.

A few hours later it started working again. Got back on and starting running like crazy on 10M, went for an hour or so and same failure mode.

Big snowstorm here means no one can get to the radio site, trying to figure this out remotely. Power issue? RFI? Software bug?

We are running the 10 Feb 2.85 version that has been stable.

Waiting to see if it comes back again, or the snow melts - whichever comes first...

John K3TN

Pages: [1] 2