PTT source

  • 1
  • Problem
  • Updated 7 months ago


I have a client that's using FlexLib Version 2.5.1. 

I keep seeing this in an execution trace:
ParseInterlockStatus: Error - Invalid PTT Source (HWCW)

The PTTSource should probably be PTTSource.SW, but it's only set internally by the library code, see ParseInterlockStatus().  Note that the radio is in the cw mode.

I'm also seeing a lot of these Debug items:
Radio::ParseInterlockStatus: Invalid key/value pair ()


Can anybody shed some light as to what might be going on here?

Photo of Jim Shaffer (KE5AL)

Jim Shaffer (KE5AL)

  • 70 Posts
  • 2 Reply Likes

Posted 7 months ago

  • 1
Photo of Mark - W3II

Mark - W3II

  • 260 Posts
  • 55 Reply Likes
If you are using 2.5+ or 3.X for Radio software you need to use FlexLib 3+ or you will get errors.
You will need to update the client to use the latest FlexLib 3.X version SDK for proper operations.

73
Photo of Jim Shaffer (KE5AL)

Jim Shaffer (KE5AL)

  • 70 Posts
  • 2 Reply Likes

My radio is using 2.5.1 also, so there should be no problem.
Photo of James Whiteway

James Whiteway

  • 1088 Posts
  • 305 Reply Likes
I was told some time ago, that several of the Invalid Key/value pair errors can safely be ignored as they are not used. I ran into the same thing with a whole string of them in Debug mode in Visual Studio. I cannot remember which post it was, explained, but, it is in the API section here, where I was trying to get a Panadapter working. (almost 4 years ago) I know that doesn't answer your question.
I haven't got as far as setting the transmit side of things with the API. I am still  working on the Waterfall. (getting very close!)
Good luck. Hopefully, Eric or Steve will see your post and can answer your question.
James
WD5GWY
Photo of Mark - W3II

Mark - W3II

  • 260 Posts
  • 55 Reply Likes
The Interlock parse routine has two anomalies.
First the interlock status from the radio ends with a space which create a trailing empty array element when the string is split up. You can ignore the "Radio::ParseInterlockStatus: Invalid key/value pair ()" .
If you want to rebuild the SDK insert the following code to ignore the empty element.
Radio.cs, ParseInterlockStatus method, first new line in "foreach (string kv in words)" loop
if (string.IsNullOrEmpty(kv)) continue; 
Code now looks like
--- start of snipit -- 
foreach (string kv in words)
            {
                if (string.IsNullOrEmpty(kv))
                    continue;
-- end of snipit --

Second there is a interlock source status value of HWCW coming from the radio which is not currently part of the PTTSource enumeration which causes the emission of this Debug message. You can also ignore this or again modify the SDK code to ignore this value or add to the enumeration to accept this value. You will have to decide if this information is useful. I would lean towards adding it to the enumeration and update the ParsePTTSource method.
public enum PTTSource
    {
        None,
        SW, // SmartSDR, CAT, etc
        Mic,
        ACC,
        RCA,
        HWCW
    }

private PTTSource ParsePTTSource(string s)
        {
            PTTSource source = PTTSource.None;

            switch (s)
            {
                case "SW": source = PTTSource.SW; break;
                case "MIC": source = PTTSource.Mic; break;
                case "ACC": source = PTTSource.ACC; break;
                case "RCA": source = PTTSource.RCA; break;
                case "HWCW": source = PTTSource.HWCW; break;
            }

            return source;
        }

 
Photo of James Whiteway

James Whiteway

  • 1088 Posts
  • 305 Reply Likes
Thanks! That will help a lot. Up till now, I just ignore those messages as long as they don't apply to a particular function I am working on.
James
WD5GWY
Photo of Jim Shaffer (KE5AL)

Jim Shaffer (KE5AL)

  • 70 Posts
  • 2 Reply Likes


Thanks Mark.  I think I'll just ignore those messages.  I don't like modifying the library, especially if not strictly necessary.

The reason I started looking into it was that I'm having a problem wherein the rig seems to lock up in transmit mode.  It happens very infrequently, but once is enough.  Also, I've only seen this on 30 meter cw, but that's where I usually hang out, so maybe it's meaningless.  I initially suspected an RFI problem, but this is the only manifestation, and usually RFI trouble is more unpredictable.  So I'm wondering if anyone else has seen this?

Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 948 Posts
  • 359 Reply Likes
Jim -- there is an open issue related to CW hanging in some situations (#7684). I suspect it may be related. 
Photo of Jim Shaffer (KE5AL)

Jim Shaffer (KE5AL)

  • 70 Posts
  • 2 Reply Likes

Eric, could you please post a description of issue #7684?  Can I lookup those issues?  Also, any prognosis as to when it'll be fixed?
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 948 Posts
  • 359 Reply Likes
No, the issue list isn't publicly available.  Here's what I have for this issue though: 
CW Transmit Hang
I did notice one possible bug. When keying is initiated from a CW macro and then interrupted by paddle input from the operator the transmitter will hang every time. It was usually easy to get the radio to return to RX by either hitting another macro or simple waiting a couple of seconds and then hitting the paddle again. CW setup here with the 6600M was via the CATSDR winkeyer for computer sending and paddles plugged in the back of the 6600M for manual keying.

(this came from an Alpha user via email)
Photo of Jim Shaffer (KE5AL)

Jim Shaffer (KE5AL)

  • 70 Posts
  • 2 Reply Likes
I have never been able to get the radio to return to receive.  I do notice that it seems to happen when using the key, plugged into the front of my 6500.  When this happens, the only way I've been able to recover is by turning the rig off, then back on, (i.e.) a reboot.