Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

Interlock tx_allowed question

John G3WGV
John G3WGV Member ✭✭
edited November 2018 in SmartSDR API
When my client is connected to the Flex 6000 Interlock state messages are sent, among other reasons, when I tune out of band (tx_allowed=0) and back into band (tx_allowed=1). So far so good.

I use the tx_allowed status to set the colour of the client's frequency display: red for out of band, some other colour for in-band.

When my client connects, no Interlock state message is sent as part of the connection/subscription sequence. If the Tx slice is already out of band when I connect, there appears to be no way of detecting the fact. The first Interlock state message I see is when the Tx slice is tuned back into band.

I might be missing something here. Is there some other way of getting the tx_allowed status on connection?

Happy New Year to all.

John, G3WGV

Answers

  • Mark_W3II
    Mark_W3II Member ✭✭✭
    edited February 2018
    Hello John, You have correctly identified that you can not get the state on demand so you have to figure it out. I believe this is logged as bug #2099

    You need to listen to the Radio properly changed "TXAllowed" messages for then record the fact you have a valid tx_allowed state which I do in "txAllowedValid"

    I calculate the tx_allowed state from the radio the following way.

     public bool TXAllowed

            {

                get

                {

                    // no radio not allowed

                    if (_fradio == null || _fradio.TXInhibit == true)

                        return false;

                    // if we got txallowed status then believe value

                    if (txAllowedValid)

                        return _fradio.TXAllowed;

                    if (_fradio.SliceList.Count == 0)

                        return false;

                    foreach(Slice s in _fradio.SliceList)

                    {

                        if (s.Transmit)

                            return true;

                    }

                    return false;    

                }

            }


    I hope this helps

    73, 

    Mark AA3RK


  • John G3WGV
    John G3WGV Member ✭✭
    edited November 2018
    Hi Mark, thank you for the speedy reply.

    It's good to hear that it's not just me being dense and that it is already logged - it does seem to be something of an oversight.

    I though about using the slice transmit parameter(s) (tx=) as a means of determining the status of tx_allowed but it doesn't work for me. The sub slice command returns the out of band frequency but it also returns tx=1 for that slice. Perhaps you are looking at a different parameter?

    I could, of course, code my own in-band check routine but as Tx bands are so clearly defined by the Flex .turf I thought it better to use that if possible.

    Back somewhere in the past it seems that one could subscribe to interlock events and I imagine that would have sent back the status OK. Looking in radio.cs it's no longer supported and if I try sub interlock all I get an error response.

    Not a biggie by any means. The likelihood of me starting my controller when the existing Tx slice is out of band is probably rather slim. More a matter of curiosity really!

    73, John


  • John G3WGV
    John G3WGV Member ✭✭
    edited November 2018
    In the same vein, here's another curiosity. As I tune LF, say, from somewhere in the 40m band, heading south on an out of band mission, I get this:

    [TCP>] C92|slice tune 0 7.000005
    [<TCP] R92|0|
    [TCP>] C93|slice tune 0 7.000000
    [<TCP] R93|0|
    [<TCP] S0|interlock state=NOT_READY reason=TUNED_TOO_FAR tx_allowed=0
    [<TCP] S0|interlock state=READY tx_allowed=1
    [TCP>] C94|slice tune 0 6.999995
    [<TCP] R94|0|
    [<TCP] S0|interlock state=NOT_READY reason=OUT_OF_BAND tx_allowed=0

    Now that is rather unexpected! At 7.000000 exactly I get TUNED_TOO_FAR, with tx_allowed=0 and then immediately afterwards, with no further tuning, tx_allowed=1.

    As the VFO continues on its voyage below 7.000000, I then get the expected tx_allowed=0 message.

    Never a dull moment with the Flex API!
  • Stan VA7NF
    Stan VA7NF Member ✭✭✭
    edited November 2018
    Technically 7.000000 is in band, until you modulate it with a <30hz square wave (we call it CW keying) and its inherent lower sideband is now out.  :-) 

    How many angels can dance on the head of a pin?

    Stan
    VA7NF
  • John G3WGV
    John G3WGV Member ✭✭
    edited December 2016
    Indeed so. I was somewhat more bemused by the way it was out of band one moment and, 27ms later, (see below, with time stamps) back in band. That's barely time for one dit :)

    19:32:49.086 | [TCP>] C3024|slice tune 0 7.000000
    19:32:49.143 | [<TCP] R3024|0|
    19:32:49.146 | [<TCP] S0|interlock state=NOT_READY reason=TUNED_TOO_FAR tx_allowed=0
    19:32:49.173 | [<TCP] S0|interlock state=READY tx_allowed=1
    19:32:53.763 | [TCP>] C3025|slice tune 0 6.999995
    19:32:53.788 | [<TCP] R3025|0|
    19:32:53.793 | [<TCP] S0|interlock state=NOT_READY reason=OUT_OF_BAND tx_allowed=0



Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.