As a casual contester, I have N1MM+ setup and optimized for contesting. But I find that I also like using N1MM+ and its hardware setup for non-contesting operations as well. Unfortunately, N1MM+ lacks many of the necessary non-contesting features found in general purpose logging programs.
For the past few years the developers at DXLab and N1MM+ have collaborated to support a logging interface between N1MM+ and the DXLab DXKeeper. The auxiliary program, called N1MM-DXKeeper Gateway, inserts records into the DXLab DXKeeper database after they have been logged in N1MM+. This gateway works well and allows me to take advantage of the feature-rich software suite provided by DXLab.
During last CQ WW SSB contest, I had a few teenagers in my shack to get on the air. We kept looking up countries we worked on an online map to find out which contact was the farthest, whether we could find any photos about the remote stations, and other interesting information. This is when I got the idea for improving the existing N1MM-DXKeeper Gateway. Wouldn’t it be very helpful and educational if all the information we could get about a call automatically pops up during the QSO? I also think this would be a very effective feature to show on a FieldDay GOTA station.
A few emails with the programmer of DXLab, David, AA6YQ and the plan was made to get this in both DXLab and N1MM+.
There is now a new version of the gateway that provides this functionality of looking up a callsign (in addition to the previous function of logging QSOs). It can be found here.
In N1MM+, of version 7336 or later, this feature can be enabled in the Configurer dialog.
With the new gateway launched as part of DXLab’s launcher (or by any other means), the highlighted pieces of information are all automatically looked up and populated as soon as the user hits the SPACEBAR or TAB key in the N1MM+’s entry window. The most amazing feature to demo to others (think: new hams!) is the “Fly to selected location” feature in DXView/Google Earth.
As a side note, this feature is built generally into N1MM+ via UDP packets. Other logging programs are welcome to integrate this as well.
There should not be a noticeable impact on performance to enable this as the implementation is not blocking the program flow (parallel threads). If you do see performance issues, it is possible that this is caused by your virus scanner. Make sure you exclude the program and user directories of N1MM+, N1MMDXKeeperGateway and DxLab (CWSkimmer, RBN Aggregator, etc.) from your virus scanner. I have experienced serious performance issues before I did this. I believe the patterns of DX cluster and UDP data traffic from ham programs look very suspicious to these scanners.
I want to thank David, AA6YQ, and Larry, K8UT, for their help in designing and testing this feature.
The radio is built with SO2R in mind (2 ANT outputs, receive filters for contesting bands). The amplifier came in form of a kit and produces legal limit of power on all bands below 6 m. Putting the amp together was easy and took me about 1 day. I like the fact that the amp can be tucked away and can be fully remote controlled from any computer device on the network.
After working for a few days with the new toys, I realized that I could use the amp for both slices by swapping ANT1 and ANT2 on the radio and switching my 6 x 2 remote antenna switch appropriately. This worked great, however, was cumbersome to do during a contest. Time-consuming enough that it pretty much prevented a semi-competitive contest entrance. For SO2R and in High Power category, you want to run with high power and also do S&P with high power. Or even run on two bands with high power. My next question was: Do I really need 2 amps for this?
Turns out, the answer is NO. I found this neat antenna switch called “1 AMP 2 radio switch” and made by 4O3A. That allows not only to share one antenna with 2 radios, but I can share one amplifier with 2 radios/VFOs.
For more details, read on below.
And by the way, the should be doable with any other CAT controllable radios and amplifiers. No affiliation to any manufacturer referenced in this blog.
Understanding the equipment better
Before putting this all together, I had to learn and understand more about PTT, PTT lead times and how it relates to all three pieces of equipment at play. Here are a few of my notes:
RF2K+ kit
If the amp has to switch band relays (transmission about to occur on a different band), it takes about 15 ms.
PTT lead time before RF is not needed by the amplifier, its likely more needed by transceivers and antenna switches. A “good-citizen” value would be maybe 10ms.
The amplifier has multiple rig control modes. I have played with CAT, UDP and Universal.
Universal rig control mode:
Basically, this is without any rig control and have the amplifier figure everything out.
In this mode, the amp runs a comprehensive RF sensing routine, that takes up to 15 ms.
With a PTT lead time of 10 ms it would take <= 40 ms (10 + 15 + 15) till High power goes out, and <= 30 ms would be lost of the signal.
UDP/CAT:
The amplifier can receive UDP packets that tell it what frequency. This is very similar to a simple Kenwood-style CAT protocol that can also be used.
If the amp is in CAT or UDP mode, it does a short RF sensing routine, that takes about 3-5 ms.
With a PTT lead time of 10 ms it would take 13-15 ms (10 + 3-5) till High power goes out, and 3-5 ms would be lost of the signal.
1 AMP 2 Radio switch
This is a fairly simple device. The main consideration is how long the relays take to switch. I am hoping 10 ms is enough.
Experimenting
Rig control mode
My initial thought was to use CAT. Hooking this all up was a breeze with a null modem cable between 6600M and the RF2K+. The 6600M provides a way to use CAT control for the slice with TX focus. That’s exactly what I needed and the switching works correctly, but unfortunately not 100% of the time…
Second test was with UDP. UDP is a little harder, as N1MM+ provides UDP packets for both EntryWindows every couple of seconds. So, I had to build a small translator (in N1MM+ software) to only send the UDP packet for the TX active slice. That also worked, and similarly as the CAT control. Most of the time only…
The last option was to use Universal mode. Have no rig control and just have the amp do the work. Even though I thought this would be a brute-force method and not advisable, it turned out to be very reliable. The amp does not miss a beat during dueling CQ and also during breaking into a running CQ on radio 1 by hitting F4 (my call) on the other radio. Reliability is a must, so I considered going with this approach.
But what about the loss of the signal during the leading few milliseconds? With the help of over the air tests with N2IC it turned out that it is actually not a big deal. I sent leading Vs (starts with a dit) at 36 word per minute. The slight cut off of the signal is very small and almost not noticeable on the receiving end.
So, why is it not as reliable with CAT or UDP? I can only guess. I think it may be possible that the amplifier needs more time to process these control signals. I am fairly certain that I was able to send the UDP messages very fast, so it may be either network related or slowness of the amp. At this point I am not sure, but will contact the maker of the amp.
Temperature
What does it do to the amplifier’s temperature, if used in SO2R mode in duelling CQ mode? Well, it gets a little hotter. Different bands need different amount of bias current and therefore produce different amount of temperatures. I found, when 20 m band was involved and running 1.5 kW on both bands, I was sometimes reaching the maximum temperature that is programmed into the amp to switch from Operate to Standby, 72 degrees Celsius. I had the amplifier built in a way that favors the quietness of the fans (12 V fan drive). I have now reconfigured this and switched the fans to run in the 15 V mode, and have yet to reach the limit. I have to watch this a little bit in the future and will report back if I find any other issues. Off course the fans are now a little louder, but only under extremely high duty cycle. This should also help with doing digital modes or long rag chews in SSB on 20 m.
Cross-band RFI
Well, it turns out that I need to work on some RFI suppression. Apart from the receive filters built into the 6600M, I have no other band pass filters. Next project to tackle…
Summary
Here is a list of all settings that I found work best for my equipment.
N1MM+:
CAT for Slice A and B: PTT delay 10 ms
CAT for WinKey: PTT delay 10 ms
WinKey: Lead time: 1, Hang time: 2.00
6600M:
TX profile: TX delay 10 ms
TX profile slice A: RCA TX1: Enabled
TX profile slice B: RCA TX2: Enabled
Breakin: Enabled
CW sidetone: Off
CW delay: 0
RF2K+:
None. Just use Universal
Special thanks to DH3NAB (maker of the RF2K+), K8UT, N7HQ and N2IC for discussions, insights and over-the-air tests.