SmartSDR v4.1.5 | SmartSDR v4.1.5 Release Notes
SmartSDR v3.10.15 | SmartSDR v3.10.15 Release Notes
The latest 4O3A Genius Product Software:
The latest 4O3A Genius Product Software and Firmware
If you are needing assistance with FlexRadio products, 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.
PTT source
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?
Comments
-
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.
730 -
My radio is using 2.5.1 also, so there should be no problem.0 -
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
0 -
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;
}
0 -
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 WD5GWY0
-
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?
0 -
Jim -- there is an open issue related to CW hanging in some situations (#7684). I suspect it may be related.0
-
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?
0 -
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)0 -
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.
0
Leave a Comment
Categories
- All Categories
- 389 Community Topics
- 2.2K New Ideas
- 658 The Flea Market
- 8.4K Software
- 157 SmartSDR+
- 6.5K SmartSDR for Windows
- 186 SmartSDR for Maestro and M models
- 439 SmartSDR for Mac
- 275 SmartSDR for iOS
- 265 SmartSDR CAT
- 204 DAX
- 386 SmartSDR API
- 9.4K Radios and Accessories
- 53 Aurora
- 297 FLEX-8000 Signature Series
- 7.2K FLEX-6000 Signature Series
- 971 Maestro
- 58 FlexControl
- 867 FLEX Series (Legacy) Radios
- 945 Genius Products
- 472 Power Genius XL Amplifier
- 347 Tuner Genius XL
- 126 Antenna Genius
- 307 Shack Infrastructure
- 215 Networking
- 468 Remote Operation (SmartLink)
- 142 Contesting
- 811 Peripherals & Station Integration
- 144 Amateur Radio Interests
- 1.1K Third-Party Software

