Odd behavior with 'rfpower' and 'tunepower' tags in TX subscription message

Lynn Hansen

Hello all,

I'm finally back to implementing the Flex API on my CTR2 multi-radio controller (see https://community.flexradio.com/discussion/8008383/cat-control-on-usb-cable-no-frequency-control). I'm linking to the radio via WiFi and so far I've been impressed with what I can do with the TCP/IP API.

For reference, I'm running SmartDSR Develop 2.6.2. This is a special update from Eric and the team that fixes the bug I reported in bug report J8057 and described in the link above. However, the same behavior I will describe exists in the plain-vanilla v2.6.2. I don't run v3 so I have no clue if it's in there (but I would assume it is).

I've found that the 'rfpower=' and 'tunepower=' levels in the TX subscription message don't change when the RF Power or Tune Pwr sliders are adjusted in SmartSDR, or when I change them using the 'transmit rfpower=xx' or 'transmit tunepower=xx' commands in the API. The sliders in SmartSDR follow the API commands but the levels reported in the TX subscription message do not.

The TX subscription message values DO CHANGE when I key the radio or start the ATU. I assume then that the subscription values are the 'last measured power levels' for these points.

I run into a problem when I change one or both of these values on my controller. If I don't transmit immediately after setting a new level and then adjust one of these levels on SmartSDR or do something else that causes a TX subscription message (like bypass the ATU), my controller reverts back to it's original settings - but SmartSDR still shows the new values. The TX subscription values (and my controller) will update to the new levels shown on the SmartSDR sliders once a transmission is complete.

You can see that this canbe confusing to anyone using a 3rd party controller.

Am I missing something in the API? Is there a command that will cause the TX subscription message to update to match the slider settings, or is there a way to read the slider settings directly instead of relying on the TX subscription message?

Lynn, KU7Q

Eric-KE5DTO

Lynn,

What kind of client are you using to do this? If it is a non-GUI client, is it bound to GUI client? Without the binding, the radio doesn't know which set of Tune Power/RF Power to show in the status updates until the radio is put into transmit. This is because with multiFLEX, multiple clients can be connected and either could be keyed at any point. So without being bound to a particular client, it is a JIT status message that tells you the setting for the client that keyed the radio.

Note that even though v2.x doesn't support multiFLEX, it shares the API and behaves in the same way.

KD0RC

Hi Lynn, I have the same problem with my "TeensyMaestro" (see my QRZ.com page). It also uses the Flex TCP/IP API and does not get updated Tune or RF power without actually going into transmit first. Everything else comes back as expected.

Turn RF down to 25 from 26 via SSDR slider:

SB895F69C|transmit rfpower=26 tunepower=10 am_carrier_level=100

Click the PTT:

SB895F69C|transmit freq=7.169700 rfpower=25 tunepower=10 tx_slice_mode=LSB hwalc_enabled=0 inhibit=0 dax=0 sb_monitor=0 mon_gain_sb=29 mon_pan_sb=50 met_in_rx=1 am_carrier_level=100 mic_selection=MIC mic_level=30 mic_boost=1 mic_bias=1 mic_acc=0 compander=1 compander_level=70 vox_enable=0 vox_level=25 vox_delay=12 speech_processor_enable=1 speech_processor_level=1 lo=200 hi=2800 tx_filter_changes_allowed=1 tx_antenna=ANT1 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1 break_in_delay=5 cwl_enabled=0 sidetone=1 mon_gain_cw=26 mon_pan_cw=50 synccwx=1

73,

Len, KD0RC

KD0RC

Another issue happens when you connect without SmartSDR running. All of the API commands that I use work properly except for "slice t freq". If I try to change frequency, the radio software crashes with a double-red blink pattern. Flex could not recreate the problem with the program that I sent them, so I suspect they did not set up the same conditions (i.e. no other clients connected). To get around the problem, I issue a "client gui" followed by a "client start_persistence 1". This registers me as a GUI client (which I am not, really...) allowing everything to work properly. To connect as a GUI client, I have it coded to read a button press at boot time. Means having to know that nothing else is connected when starting the TeensyMaestro. A bit of a pain, but at least I can do it now.

Except for the RF Power only updating after I transmit, my project is done and working as I hoped. How is your CT2 project coming along?

I forgot to mention, I am running 3.1.12.51 on a Flex 6400.

73,

Len

Lynn Hansen

Len,

Sounds like you've made good progress on your project. You're a lot like me, never give up, never surrender!

The slice tuning problem you describe sounds like the same one I had back in June. Eric created bug report J8057 and the sent me a v2.6.2 developer version to try. It cured the problem and I can now connect to the 6400 and turn around without SmartSDR running. He said the problem was also in v3.xx so maybe he can send you a copy of v3 to test with. The fix is supposed to make it into the next maintenance release.

CTR2 is coming along great. When I respun the board I threw in the Teensy 4.1 with audio adapter instead of the 4.0. That gave me access to all 8 serial ports, a proper USB host port, and an Ethernet PHY. So much power! I submitted an article on it to ARRL and they accepted it for publication in QEX. They haven't said which issue it's scheduled for yet, but where QEX is only published bi-monthly I wouldn't expect to see it till the later part of 2021.

I just started working on the Flex interface. It has a separate property page since it does things other radio's don't. It's no where done yet, I'm still playing with it. Here's a photo of the current page. To be compatible with other radios I'm using the analog audio from the DE-15 connector on the back of the radio and do my own Tx/Rx DSP audio processing on the Teensy so I don't need access to those features here. This way it 'looks and feels' like every other radio in my fleet. The code will create Slice A if one doesn't exist (SmartSDR isn't running), or it will just use the existing slice if it is. You have the option of leaving the slice open when you disconnect CTR2 so youi can still use SmartSDR, or closing it if you're running headless.

Another feature of CTR2 is that it controls up to 16 radios. Here's a screen shot of the Select Radio page with the radios I currently use. Every radio has it's own database for settings and they all can access a common shared database. Again, the idea is to give you a common interface to all of your radios. I've also design an automatic switch that will connect the selected radio to CTR2 (instead of using manual RJ45 switches). You just have to select it from this page... and I have parts to build an antenna switcher that will follow the radio switch. I have a new QCX-mini on order that will join the QRP stable soon. So many possibilities!

73's,

Lynn, KU7Q

KD0RC

Wow, very impressive!! The audio board is great and the GUI tool that Paul created to hook the functionality together is fantastic. Guys are building SDR radios from that library. Next thing for me to figure out is how to connect to my radio remotely. I am leaning towards trying a VPN solution, but would prefer to use SmartLink. I got some SmartLink info, but don't understand it... In the meantime, I am really enjoying the TeensyMaestro.

I will reach out to Eric. It would be nice if I could get rid of my goofy work-around.

73 & good luck with your proect,

Len

Lynn Hansen

Len,

I downgraded SmartSDR back to the standard v2.6.2 distro and the lockup problem I described earlier returned. As soon as I sent the slice tune command when trying to connect without SmartSDR running, it locked up. I upgraded back to the v2.6.2 developer version and can successfully create a slice and tune with SmartSDR offline.

One interesting thing, which relates to the power problem I wrote about above, when I first connect without SmartSDR running, both the RF power and the Tune power are set to 0. I have to manually enter the power levels to use AND hit the ATU to store them. Once that's done, it works like a charm. I'm thinking I probably need to play with the persistence options.

Fun times,

Lynn, KU7Q

Lynn Hansen

Eric,

That makes perfect sense. I honestly don't know the difference between a GUI and non-GUI interface. My program connects to IP port 4992 and interrogates the radio using the TCP/IP API. It's a lot like KD0RC's TeensyMaestro app.

I'm not binding to a GUI client. I read the Client Bind topic in the API and it didn't make a lot of sense to me (I have a thick skull). It refers to a <User ID> and gives an example command. I couldn't find anything that tells me where I find the User ID this command needs. I tried the using handle provided by the API for my connection but it didn't like it.

Any direction in finding the User ID would be helpful.

Lynn, KU7Q

Alan

Lynn

If you hover over the radio on the SDR sign in screen, you will see the user ID of that client.

Here is a link to the API Wiki, Client section:

http://wiki.flexradio.com/index.php?title=TCP/IP_client

Not sure if it helps as you must have a GUI client attached to the Flex Server for a non-GUI client to work, but, here is a command I used to first bind to my Maestro and then send a "Tune" command:

C173|client bind client_id=CC9EB661-B18E-4CE8-A9A1-DAD17776F3CB\r\n C173|transmit tune 1\r\n

Alan. WA9WUD

KD0RC

Hi Alan, my project (TeensyMaestro) does not do a GUI bind (normally). I just connect to the radio (6400) and can control both the A and B slices concurrently with SmartSDR. If the slice A freq moves via a mouse move in SSDR, my box reflects it. If I turn my VFO A knob, the SSDR slice A moves accordingly. Since I am not bringing back panadapter/waterfall info or audio, I am not a GUI client.

Lynn and I are using non-GUI clients which gives us some advantages in terms of operating as a "parallel" interface to the radio. Whatever happens in the GUI client happens in our non-GUI clients.

At the moment, there is a defect in the API, so the TeensyMaestro cannot be connected to the Flex without a GUI client (like SSDR) being connected. As a work-around, if I want to connect standalone (which is unusual), I do a client bind. If I do a client bind, then open SSDR, I am in "MultiFlex" mode. While I can see both slices, I am no longer operating the TeensyMaestro in parallel with SSDR. It is as if I have a Maestro and a laptop hooked up at the same time, each seeing its own slice.

Sorry if that does not make sense. I can see this very clearly, but I have a hard time explaining it... 🙂

73,

Len, KD0RC

Alan

Len

Thanks for the explanation.

We have different "use cases". In my use case, I am supplementing with additional functions, not replacing the GUI client.

I understand your case is to duplicate the functionality and not rely on bound client.

Both worthy projects, but different in objectives.

Alan WA9WUD

Lynn Hansen

Alan,

When I hover over the radio in the SmartSDR I see the radio's SN, Radio ID (looks like it's MAC address), it's IP address, # of connected users, and the firmware version (I'm running 2.6.2.267, the developer version Eric provided that fixes the crash bug when I connect without the GUI running). I can now connect to, and control the radio without binding to the GUI. Other that the two API power level issues, it works great. Like Len, I don't use the UDP streaming data on my HMI.

I did find what looks like a SmartSDR-Win ID (in the same format as the one you show) when I hover over the Station in the DAX Control Panel so I can try binding to that client. I'm not sure what that gives me, since I, like Len, want to run the Flex and my HMI in parallel. The way it's working now, I can connect to the radio without SSDR and control it. I'll try it out and report back.

Thanks for your help,

Lynn, KU7Q

Lynn Hansen

Alan,

Yes, different use cases. In both you and Len's case (and I imagine about everyone else out there) the idea is to have a separate controller specific to Flex that supplements SmartSDR with additional hardware controls of software options.

In my case, my controller (CTR2) is designed to work with just about any radio out there, from an old boat anchor to the Flex, so it's somewhat limited to the most common tasks like frequency and mode control (if the radio has a CAT port), CW and RTTY keyers/decoders, and audio processing. It uses analog audio from the speaker/mic or line-in/line-out, depending on the radio, and adds DSP and FFT features to these radios. It also provides USB audio and serial control towards the PC, so all of my radios are compatible with digital apps and they all look like a Kenwood TS2000 to the apps. Another nice feature is that since my Flex is in the basement, I have direct key and PTT inputs to it through my remote interface which means I can key the radio directly either from CTR2's keyer, the keyer in the radio (using Bypass mode in CTR2), or from a straight key (i.e. CWX is not required). Admittedly, trying to shoehorn a Flex into such a restricted environment is a challenge, which oddly, is exactly why I'm doing it :) Besides, every once in a while, I just want to operate a radio, not a computer.

Lynn, KU7Q

KD0RC

Well Alan, you got me thinking... I just opened SSDR on one computer, Then opened SSDR on a second computer (MultiFlex). My TeensyMaestro shows both slices, one from each computer. My slice A controls operate the first computer and slice B controls operate the other. I did not even think of this scenario when I built this thing! I don't imagine that I will ever use it this way, but it is fun to see it work.

I built this thing to control slice A and B only, but a pair of them could conceivably control all four slices of a 6600. I guess as soon as someone donates a 6600, I will make the code changes...

73,

Len

N1SH

Was there any resolution as to why the radio does not send out accurate 'transmit rfpower=' status messages?

I am having the same issue (v3.2) where changing the power level sends false/old power level status to connected TCP/IP clients. It sure would be nice to be able to track the actual set power level.

KD0RC

@N1SH Yep, Eric gave the definitive answer. It is working as designed. If you connect as a GUI Client, the power change shows without having to initiate a transmit cycle. If you connect as a non-GUI Client, then it tales a transmission to present the power to the interface.

I normally operate my TeensyMaestro as a non-GUI Client. That way whatever is happening on any slice operated by any client is reflected on my display. At power-up time, I can put it into GUI Client mode so that it acts like a real Maestro in this regard. In this mode the power follows the RF Power slider. I can therefore confirm Eric's statement based on my own observations:

"Without the binding, the radio doesn't know which set of Tune Power/RF Power to show in the status updates until the radio is put into transmit. This is because with multiFLEX, multiple clients can be connected and either could be keyed at any point. So without being bound to a particular client, it is a JIT status message that tells you the setting for the client that keyed the radio."

N1SH

I'm still trying to sort this out based on the documentation and your response.

Do I need to bind _as a_ GUI

client gui

Or just bind _to a_ GUI client

client bind ...

In either case it seems very strange for the radio to be reporting false information when you are not bound.

KD0RC

I wouldn't say false information, I just don't get any info when in non-GUI Client mode. Whatever my own interface had last is what shows on my screen. I can bind my gizmo as a GUI Client, but I am not sure how to bind to a GUI Client.

From the Wiki:

BIND

Registers that a non-GUI client will be binding to a client with a particular ]Client ID]. From a radio perspective as of v3.0, this command is simply for debugging and troubleshooting and assists developers in determining how non-GUI clients are processing radio data, but in and of itself performs no function in the radio. It is recommended that non-GUI clients send the statement when they bind to maximize information for debugging.

C[D]<seq_number>|client bind <client_id>

<client_id>       =  the client_id of the GUI client that this non-GUI client intends to "follow"

If I had a way to query to find the client_id of an instance of SmartSDR, then bind this way, and if that solved the problem, this would be great! Have you done any experimentation with this?

N1SH

Then the only place the docs refer to client_id is in that one page. Where do you get the client_id of other clients?

On a whim, I tried 'sub client all' and got a response with:

---

C1|sub client all

S57E31765|client 0x378A1740 connected local_ptt=1 client_id=3D364B50-F7C0-439A-BB32-8C40E01AA6F0 program=SmartSDR-M station=Flex-6600M

R1|0|

---

Problably going to throw a network sniffer on this sucker and run SmartSDR from windows and see what's really going on here.

Stephen

N1SH

Background, this is all in me building a JavaScript library for the flexradio and to use with NodeRed.

https://github.com/stephenhouser/flexradio-js

and

https://github.com/stephenhouser/node-red-contrib-flexradio

KD0RC

AH, brilliant! Thanks Stephen, that gives me something to experiment with. I can parse out the client ID and if the program parameter contains the text "SmartSDR", then that is a client I can bind to to see if the RF Power (and Profile) behavior changes. The Wiki says that the Bind "...in and of itself performs no function in the radio. ". I will fool around with this to see if the Bind actually gives me a benefit.

N1SH

I just keep getting error responses when trying to bind to those client_ids

N1SH

Len,

Network sniffer reveals all:

C6|client bind client_id=74F5C15A-E4C7-4BDE-8B45-4F9E1E15DFA2

Stephen

P.S. A version of the TeensyMaestro has been on my list since getting the Flex. Thanks for all your work on it.

KD0RC

I was able to get the bind to work (at least it gave me a 0 response code). The Bind is as the Wiki says - performs no function. Oh well...

Here is my quick and dirty test code. The first time I ran just the sub client all which gave me the hex client ID. I took the client ID and plugged it in to the client bind statement.

sendResult = send(sock, "CD7 | sub client all", 21, 0);

sendResult = send(sock, "CD10 | client bind " + 0x4B761ECB, 24, 0);

No joy... I just always get the following, no matter what the power slider says.

S4B761ECB|transmit tune=0 tx_rf_power_changes_allowed=1 max_power_level=100

S4B761ECB|transmit rfpower=100 tunepower=10 am_carrier_level=100

If I do a proper client GUI command, then I get the power slider back, no problem.

I also tried the client bind with the client_id returned from the sub, but that did not work either.

N1SH

Network sniffer traces from SmartSDR session. Really just started and stopped SmartSDR while capturing these.

https://github.com/stephenhouser/flexradio-js/tree/main/samples

N1SH

Success! The last bit is me turning the RFPower knob on the Radio (6600M with built-in Maestro). You can see the RFPower changing as my client is "following" the Maestro interface.

...

C1|sub client all

S720372E5|client 0x378A1740 connected local_ptt=1 client_id=3D364B50-F7C0-439A-BB32-8C40E01AA6F0 program=SmartSDR-M station=Flex-6600M

R1|0|

C2|client bind client_id=3D364B50-F7C0-439A-BB32-8C40E01AA6F0

S720372E5|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=0 tx2_enabled=0 tx3_enabled=0 tx_delay=0 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=0

...

R2|0|0x378A1740

C3|sub tx all

S720372E5|transmit tx_rf_power_changes_allowed=1 tune=0 show_tx_in_waterfall=1 mon_available=1 max_power_level=100

...

R3|0|

S378A1740|transmit tune=0 tx_rf_power_changes_allowed=1 max_power_level=100

S378A1740|transmit rfpower=36 tunepower=10 am_carrier_level=100

S378A1740|transmit band 9 band_name=20 rfpower=36 tunepower=10 hwalc_enabled=0 inhibit=0

S378A1740|transmit tune=0 tx_rf_power_changes_allowed=1 max_power_level=100

S378A1740|transmit rfpower=37 tunepower=10 am_carrier_level=100

S378A1740|transmit band 9 band_name=20 rfpower=37 tunepower=10 hwalc_enabled=0 inhibit=0

S378A1740|transmit tune=0 tx_rf_power_changes_allowed=1 max_power_level=100

S378A1740|transmit rfpower=36 tunepower=10 am_carrier_level=100

S378A1740|transmit rfpower=33 tunepower=10 am_carrier_level=100

S378A1740|transmit band 9 band_name=20 rfpower=33 tunepower=10 hwalc_enabled=0 inhibit=0

...

KD0RC

That is it!!!

sendResult = send(sock, "CD7 | sub client all", 21, 0);

sendResult = send(sock, "CD10 | client bind client_id=E08F5BB7-F75E-4940-8352-624F0BC84106", 66, 0);

So if I bind to the existing client, based on the subscription, RF Power comes back correctly!!! I think the Wiki is outdated on the Bind command. It also does not mention the client subscription.

Now to see if I can get it to work from the TeensyMaestro instead of my debugging program...

Thanks Stephen, this was the breakthrough I needed! I normally want my TM to work in concert with SmartSDR, not instead of it, so this will be great.

Thanks for the kind words on the TM, I appreciate it! It has been a really fun and rewarding project. If you do move forward with it, be sure and post pics and progress here on the TeensyMaestro thread.

David Decoons, wo2x

Hi guys,

yes, I do a C1|sub client all\r\n just once when the

then C|5 client bind client_id=61ED127E-E704-4E93-BB74-F5EA32830EB6\r\n

I parse the client ID that is returned with the sub client all then use that to bind. I typically run with just one client connected at a time.

I look for the client ID length to determine if a client is connected or not. I use that to blank out meters and client info in Node Red when no client is connected. It gives me a visual indication quickly if someone is connected to the radio.

Let me know if you have additional questions. We can compare notes.

73

Dave wo2x

KD0RC

Got the TeensyMaestro working with the client bind command! Now when I change the RFPower slider, I get immediate updates on the TM display. I will have to see what happens when I have multiple clients connected. Maybe I will add a screen that allows you to select one. Haven't thought that through yet, so I may just be blowing smoke at this point...

Lynn Hansen

Stephen & Len,

Thanks for doing the heavy lifting on this problem. I'll take a look at what you've done and see if I can apply it to my controller.

Len,

Have you tried the new SmartSDR v3.2.37 to see if they incorporated the fix for the reset bug I reported? I'm going to try v2.7.5 here to see if I can dump my developer version.

KD0RC

Hi Lynn, is the reset bug the one where changing the frequency of a non-GUI client when there is no GUI client connected causes the radio to software fault and restart?

If so, I have tested that on 3.2.37 and 2.7.5 and both work great now.

Let us know if you have any problems with the client subscription or bind.