USB Cable Binding in Multiflex

Alan

The setup:

I have Flex Multiflex setup with Smart SDR on my desktop for Satellites and a second instance on my Maestro for HF operations.

I use Flex USB  BIT Cables to configure the antennas for satellites.

To ensure the USB BIT relays work for aligning the Satellite antennas, I must make sure the Flex Multiflex setting is aligned to the Smart SDR Desktop.

It seems that Smart SDR changes the multiflex setting based on whichever device is turned on last, so I have to go back and check the multiflex setting to make sure it is set up to the satellite radio (desktop SDR).

The Question:

How can (if possible) I "bind" the USB cable to a certain radio in multiflex?  Section 4 of the SDR manual describes how to "bind" DAX and CAT settings to a certain radio.  Is there anything similar for USB cables?

I reviewed the "Flex USB Cable Interface Guide".   Nothing there either?

I reviewed the SDR manual on persistence, TX settings, and profiles.  Nothing there?  Or did I miss it?

I have the USB BIT cable set up to switch based on the Source - "TX Slice" and Trigger - "Band".   Would a different trigger source work better for my configuration?

Alan
WA9WUD

Mike-VA3MW

Alan

Can you explain this part further?

It seems that Smart SDR changes the multiflex setting based on whichever device is turned on last, so I have to go back and check the multiflex setting to make sure it is set up to the satellite radio (desktop SDR).

What multiFlex settings are changed?   What are the BIT cables set for?

Sorry, I need a lot more information to help you with this.  Can you actually draw/sketch this out for me?

Thank, Mike 

Alan

Hi Mike.

What multiFlex settings are changed, what are the BIT cable set for:

- the USB BIT cable controlling multiFlex device, changes.  

- The USB BIT cable is set for; Trigger source - TX Slice, Trigger- Band.

My question was based on not fully understanding how Multiflex took control of the USB BIT cables.   It makes sense, that only one multiFlex device at a time should control the USB BIT cable.

I experimented to find how the controlling multiFlex device is determined, and my initial assumption was not correct.  I found that the last multiFlex device to transmit takes control of the USB BIT cable, with the above configuration.  OK, that makes sense.

So, I think I just need to add maybe 100ms PTT delay to allow the satellite antenna coax relays time to re-position, after I hit the MOX or Tune, in cases where the USB Cable controlling device must first change.

I was initially thinking of a more complex solution using profiles and or binding, but now, not so.

Mike, do you agree?

Alan

Eric-KE5DTO

Alan,

Thanks for bringing this question to the table.  When we implemented the multiFLEX functionality, we had to make some tough decisions about how some of these things would work.  For example, when you have 2 clients connected to a radio at the same time and you have a USB Cable using the TX Slice or the TX Band to make decisions about which bits are flipped where, how do you know which client's TX info to use? 

Do we make the user choose a Station with which to associate each USB Cable?  We choose not to do this as it felt clunky and would only work for one Station at a time which would require constant fiddling if you changed between clients.

Ultimately, we settled on using the state of the Station that most recently transmitted for these sourced.  That seemed to give us the best of all options.  This does mean that you will have to transmit on the Station desired to drive the USB Cables at least once in order to cause them to follow, but after that, you shouldn't have to mess with it.

Given your most recent response, it sounds like you ended up coming to this same conclusion.

Alan

Eric.

I like your final solution.  It makes perfect sense and meets the KISS principle.

Unless I missed it, I could not find a description of USB Cable multi-client operation in the SDR Software or Hardware documentation.  If it not included, for sure adding in the next update would be helpful to others.

Alan
WA9WUD

Eric-KE5DTO

Excellent point.  I'll add a note to address this in the next round.  Thanks for pointing this out.