Band Switching RX & TX Port issue

  • 1
  • Question
  • Updated 6 months ago
  • Answered
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.
Photo of Joe - KC2TN

Joe - KC2TN

  • 97 Posts
  • 24 Reply Likes

Posted 6 months ago

  • 1
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3479 Reply Likes
Official Response
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