Determining Mode variant using CAT commands

MIDI, ...
Jeff7500
Posts: 3
Joined: Thu Oct 01, 2020 10:43 pm

Determining Mode variant using CAT commands

#1

Unread post by Jeff7500 »

Hi everyone. I need to identify, using CAT commands, the currently-selected Mode of SDR-Console. I know how to use the MD; command, but it returns only numbers (that’s OK) but the same numbers are used for multiple but related modes (not OK). For example, LSB and WIDE-L each return Mode 1. AM, ECSS-L, ECSS-U, and SAM all return Mode 5. Is there another command I should use, or is there some way to identify the selected Mode’s name using a combination of data? Some Step Sizes are used for more than one Mode, and some Filters are used for more than one Mode (e.g., AM and W-FM). So those options are non-unique and unusable for my purpose. Any advice? Thanks in advance for your time.

Jeff N8GJL

aportela
Posts: 13
Joined: Tue Jun 04, 2024 9:45 am

Re: Determining Mode variant using CAT commands

#2

Unread post by aportela »

I'm developing an external controller and I see that you had the same problem as me with the bug in the CAT commands (viewtopic.php?t=2264). I know that your post is old, but while the software is not patched, in case you are interested I am trying an approximation based on the filter values, I mean:

When I have the console in FM mode (B-FM, W-FM, N-FM) the mode returned by the command "MD;" is always "MD4;" however through the commands "SH;" and "SL;" I can get the values ​​of the filter bandwidth and depending on this (if it is higher or lower) I can establish in a very "rudimentary" way the "real" mode, example:

Sending the commands

MD;SL;SH;

It is received as a response

MD4;SL00000;SH125000;

The "MD4;" It is incorrect in my case (in the console I have the BFM mode and I should get a "MD9;")

But the value of the upper filter indicates 125 Khz which is obvious that it is an FM broadcast

If in the console I select the NFM mode by sending the previous commands again I get:

MD4;SL00000;SH06000;

In this case the mode is "ok" but due to the bug with the other modes, to identify it I see that the upper filter is 6 Khz (which indicates that it is a narrow FM mode

Obviously it is a "patch" that does not work in all cases, I mean if we have the WFM mode but in the console we manually lower the filter to 8Khz (BW) the mode in the console will continue being WFM but in our system with this algorithm it would become NFM.

Jeff7500
Posts: 3
Joined: Thu Oct 01, 2020 10:43 pm

Re: Determining Mode variant using CAT commands

#3

Unread post by Jeff7500 »

Thanks for the tip, Simon!

-Jeff

Max
Posts: 1064
Joined: Thu Aug 13, 2020 9:47 am

Re: Determining Mode variant using CAT commands

#4

Unread post by Max »

Jeff7500 wrote: Thu Dec 15, 2022 9:29 pm Hi everyone. I need to identify, using CAT commands, the currently-selected Mode of SDR-Console. I know how to use the MD; command, but it returns only numbers (that’s OK) but the same numbers are used for multiple but related modes (not OK). For example, LSB and WIDE-L each return Mode 1. AM, ECSS-L, ECSS-U, and SAM all return Mode 5. Is there another command I should use, or is there some way to identify the selected Mode’s name using a combination of data? Some Step Sizes are used for more than one Mode, and some Filters are used for more than one Mode (e.g., AM and W-FM). So those options are non-unique and unusable for my purpose. Any advice? Thanks in advance for your time.

Jeff N8GJL
Just a note to Jeff and aportela that these issues have been highlighted to Simon via the Test Team. He is aware and has a long list of issues to fix when he comes back to 3.4 Release Version. He's otherwise occupied at the moment with his other major project. I don't doubt these issues (and many others) will be addressed in time but most likely not until some time next year at the earliest while Simon concentrates on his new DATV project.

73

Max

aportela
Posts: 13
Joined: Tue Jun 04, 2024 9:45 am

Re: Determining Mode variant using CAT commands

#5

Unread post by aportela »

Thank you for confirming that the bugs have been noted. I didn't mean to demand speed in patching them (if that's the impression I've given), I just wanted to report the problems I was finding. I also develop software and I'm aware of the process of solving bugs, even more so when Simon does all this for the love of art by making this software available to the public and taking into account that he also has other projects.

Post Reply