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 - K3TN

Pages: [1] 2 3 ... 5
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

Thanks, Mike - I tend to favor always avoiding serial to USB converters, but one of our operators (N6NC) is going to give it a try, will report on results.

Frank - in your configuration, with USB _> COM1 NO, what actually is the USB connection from the PC to the front panel RRC Mini-USB actually doing? (Outside of that, your configuration is very similar to what KL9A is using.

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).

General discussion forum / Re: K3/0-mini poor audio
« on: 2016-09-08, 19:08:39 »
Jonas - I have the same problem and Elecraft's solution was to send me a replacement audio board, which didn't seem to change the problem. My solution was simply to plug my headset (both mic audio and headphone audio) into the RRC and not the Mini. If I had it to do over again, I would have bought a used low end K3 rather than the K3 Mini.

73 John K3TN

Thanks, Mitch/Jan - I shouldn't have mentioned the 90 mile drive! Until I figured out that Setup Manager worked over the VPN, I thought I had to make that drive!  Rick N1Rm actually figured it out and reconfigured the Radio RRC.

So, the good news is that feature saved us that drive.

The bad news is lack of access control to that feature enabled someone 2,500 miles away to change the Radio RRC to a 10. address because he thought he was actually accessing his local Control RRC! Definitely his mistake, but as we add operators the odds continue to climb that others may make that mistake again.

I understand the tradeoff -  a forgotten password would then require that drive. The lack of security also makes it easy to recover, but personally I'm in favor of avoiding mistakes where possible. I've worked in computer/network security for over 35 years now, and lack of passwords (or use of hardcoded passwords) is at the root of much evil!

So, I'd be in favor of an option for requiring authentication (or direct USB connection) for changing the IP address of a Radio RRC.

73 John K3TN

Yes, Setup Manager does work to allow remote setup, but anyone on the LAN or VPNed in to the LAN can do that!

We have 6 or 7 operators who remotely operate one K3/Radio RRC configuration. Only two of us have the web interface password for the Radio RRC - but apparently all ops can use the Setup Manager and much with the RRC IP settings.

So, the question is: anyway to limit Setup Manager access via password to limit such access?

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 / Re: K3 ERR PTT
« on: 2016-02-29, 12:08:25 »
Problem solved, {insert chagrin-faced emoticon here}

I had disconnected my headset from the RRC. When I reconnected, I plugged the mini-phono mic plug into a mini-phono connector - but instead of plugging into the mic one, I plugged into the one on a Y for the footpedal. So, I guess the microphone looked like a low impedance short on the footpedal PTT signal. Big sigh.

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

On a different matter, I'm still having a severe high gain problem with the K3-Mini speaker amp.  As always, I'll need to slay this dragon on my own and redesign the feedback network.

Paul - I have two problems with my K3 Mini:

1. Low audio - audio coming out of the RRC is fine is I plug my headset there. But if I plug my headset into the K3/Mini, audio is 20 db down - I have to turn RF gain up to 9 o'clock vs. 3 o'clock, sounds crappy.

Elecraft first sent me a replacement I/O board which didn't work, so I set the Mini back to them - and they sent it back saying it works fine. It appears that the initial Mini's had a lot of digital noise getting on the audio, so they put some kind of bandpass filter on the audio that is the cause of the attenuation. They recommend cranking up the audio gain on the RRC. I'm not wild about that solution, should have just gotten a bare bones K3 instead of the Mini. For now, I am using the RRC audio vs. connecting headset to the Mini.

2. Distorted xmit audio. I'm using a wall wart for the Mini that is rated to handle stated Mini current needs but was getting high hum and distortion on the mini. Switched to feeding it from a 4 a 12v real supply, that seems to have dealt with the audio distortion.

Not everyone seems to be having or care about the low audio problem, so Elecraft has shown no interest in any new fix. Maybe if they come out with a K3S/Mini? I wish they would have stuck with the K3/0, I'm not impressed with the Mini in action.

73 John K3TN

The PTT wire (yellow) in the Microbit RJ45 Mic/Aux cable had pulled out of the RJ45 connector at the RRC end. This was an expensive cable and probably needs a better strain relief on the RJ45 end, or explicit instructions not to allow that cable to bend.

I snipped off the RJ45 connector, crimped a new one on and moved the RRC further back on the operating table to keep the RJ45/K3 Mic cable flat and PTT is back working.

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

Pages: [1] 2 3 ... 5