Interlock tx_allowed question

John G3WGV

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

Mark_W3II

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

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

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

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

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