Band Switching RX & TX Port issue

Joe - KC2TN

It seems an OLD problem may have resurfaced or wasn’t completely fixed. OR perhaps this is an N1MM issue?? My RX & TX ANT Ports are running amuck while switching bands. When I change bands using the SSDR Band Menu everything works fine. However, when using N1MM’s Band Switching menu buttons, while connected to SSDR via CAT, my 6700 ANT1 and XVTR RX port goes awry. When changing bands from any XVTR band to 6M or any HF band , the ANT RX port stays on XVTR when it’s supposed to go to ANT1. The TX ANT port however, does switch correctly to ANT1. If I manually correct the RX port to ANT1 for 6M, when I go back to a XVTR band the RX port stays on ANT1 rather than switching back to XVTR. So, once the ports get confused there is no way to correct them short of closing N1MM and manually resetting the antenna ports. But as soon as you restart N1MM the problem returns Again, the ports switch fine without N1MM running and also when I’m running my standard DX Lab logging program.. Anyone else experiencing this issue? I’ll probably forward this to the N1MM guys also. My setup is a Flex 6700, latest version of SSDR 2.X and N1MM. A USB cable provides BIT data to my relay control box from the 6700 to switch the transverter IF’s and PTT’s.

Joe - KC2TN

So, I got this response from John @ N1MM : Our software does not remember the antenna port selection and it does not change the antenna port selection when changing bands. Band changing is performed by programming the radio to the last frequency for that band. We do not use the API for radio control we use the Flex command set. John, K3CT ------------------------ It appears the "port" configurations should be part of Flex's memory per band. As this information is not transmitted by N1MM upon a band change. So, why the band change works with the SSDR menu buttons and NOT the N1MM menu buttons is still a mystery. It would make sense that it's part of FLEX's internal configuration. And All N1MM has to send to the Flex is the new Frequency and Mode. But somehow the Flex is misinterpreting the request to change bands. I can't imagine I'm the only one having this problem given all the Flexes out there and the widespread use of N1MM as the premier contest logging program. I also don't see anything I could set locally in either SSDR or N1MM to manage these band changes. Am I missing something obvious? I'll wait for Flex to weigh in!

Tim - W4TME

Those settings are remembered by band. The problem is that when using CAT to tune the radio, it is not using band persistence.

When you use the Band button, the slices in that panadapter are destroyed, the panadapter is tuned to the new band frequency and the if there are slices in the band persistence table for that band, the slices are recreated using the slice parameters saved on the persistence database.

When you tune a slice using CAT, the slice is tuned in the same manner as if you had done a direct frequency input on the slice flag.  The radio does not destroy the slice resource, it tunes the panadapter to the center of the new slice frequency and then tunes the slice to that frequency, leaving all of the slice parameters unchanged. 

We designed this behavior after a long discussion with multiple folks and some big name contesters

From a previous Community post:

 Ria - N2RJ, Elmer

Band changes on N1MM that are simply invoked by going to another frequency are handled differently from band changes invoked via a band button from within SmartSDR or the M console (or Maestro). The persistence is different, meaning that settings are likely to be retained if you simply change frequency whereas different settings for a new band are invoked if you do a band change via a band button.

 Chris Tate - N6WM, Elmer

to add to Ria's comments, that are spot on, The current workflow of the N1MM initiated band change  vs a SSDR initiated band change compel me to currently recommend that actual band changes be done from SmartSDR(or SSDR-M, the 6600 front panel).  once in band then direct frequency entry from N1MM works fine.  this is just a little "feature" of this environment at this time.

So best practices are currently:

-Install same version of SmartSDR on the computer with the N1MM logger
-make sure smartSDR cat and dax are running, and you have created the needed interface ports (CAT, OTRSP, Winkeyer as needed)
-you do not need to run smartSDR for windows.. (just the cat and dax applets)
-When using the environment, if you need to do a band change, initiate it from SSDR
-Direct frequency entry in N1MM, or clicking spots on the band map works fine once in band

Joe - KC2TN

Since all of these suggestions are known processes or workarounds based on previous discussions, I won't attempt to reopen that can or worms. I'll just accept it as is and deal with it.

There's apparently no obvious permanent solution. Not that it's a major problem but having to watch the antenna ports, during the frenzy of a contest, is not something I really want to deal with. I get thrown off when all of a sudden my receiver goes dead.after changing bands. Frequent band changes is the norm in a VHF contest. When I go to 6M from 2M and I'm waiting for my contact to arrive, I begin to worry when he doesn't show. Then I look up and see my Flex is NOT on ANT1. By the time I realize it, my contact could be gone on to another band. Lost points!

A lot of this persistence stuff, that happens in the background, is not well understood. It's obvious that when changing bands, via different methods, different events happen. It's knowing (or NOT knowing) what's going to happen and why, is what i'm trying to understand. While persistence settings are shown in the user guide, knowing their current state is another matter. 

OK I'll get off my soapbox!
Thanks for the explanation Tim!
It'll give me something to think about!