Welcome to the FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
The latest SmartSDR Software:
SmartSDR v4.2.20 | SmartSDR v4.2.20 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
SmartSDR v4.2.20 | SmartSDR v4.2.20 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
How to Receive Technical Support::
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.
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.
Issue with ATU status message
Options
Doug - K3TZR
Member
The following is an excerpt from a log of messages received from the Radio hardware to my custom client program after performing a "normal" startup (initializeRadio). I'm only showing the ATU messages. Note that in the third and fourth messages that the "atu" string appears in the middle just after "TUNE_MANUAL_BYPASS" and just before the "memories_enabled".
Could this be a bug? Admittedly, my code is new and may not be correct but after looking at it for some time, I think I'm actually receiving what is shown below. I've actually logged it coming in from the socket before any processing is done in my code.
It looks as though the "_enabled=0" portion of the message immediately following the "atu" has been dropped.
It's very repeatable, I've done it multiple times with the same result.
c4|sub atu all
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu_enabled=0 memories_enabled=1 using_mem=0
S0|atu atu_enabled=1
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu memories_enabled=1 using_mem=0
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu memories_enabled=1 using_mem=0
Here's the sequence of commands that I sent to the Radio (they're in Swift but I think you get the gist):
commandToRadio("client program xxxx")
commandToRadio("client gui")
commandToRadio("sub tx all")
commandToRadio("sub atu all")
commandToRadio("sub meter all")
commandToRadio("sub pan all")
commandToRadio("sub slice all")
commandToRadio("sub gps all")
commandToRadio("sub audio_stream all")
commandToRadio("sub cwx all")
commandToRadio("sub xvtr all")
commandToRadio("sub memories all")
commandToRadio("sub daxiq all")
commandToRadio("sub dax all")
commandToRadio("info", callback: infoResponseCallback)
commandToRadio("version", callback: versionResponseCallback)
commandToRadio("ant list", callback: antListResponseCallback)
commandToRadio("mic list", callback: micListResponseCallback)
commandToRadio( "client udpport (vitaManager.vitaPort)")
Could this be a bug? Admittedly, my code is new and may not be correct but after looking at it for some time, I think I'm actually receiving what is shown below. I've actually logged it coming in from the socket before any processing is done in my code.
It looks as though the "_enabled=0" portion of the message immediately following the "atu" has been dropped.
It's very repeatable, I've done it multiple times with the same result.
c4|sub atu all
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu_enabled=0 memories_enabled=1 using_mem=0
S0|atu atu_enabled=1
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu memories_enabled=1 using_mem=0
S7F0D191E|atu status=TUNE_MANUAL_BYPASS atu memories_enabled=1 using_mem=0
Here's the sequence of commands that I sent to the Radio (they're in Swift but I think you get the gist):
commandToRadio("client program xxxx")
commandToRadio("client gui")
commandToRadio("sub tx all")
commandToRadio("sub atu all")
commandToRadio("sub meter all")
commandToRadio("sub pan all")
commandToRadio("sub slice all")
commandToRadio("sub gps all")
commandToRadio("sub audio_stream all")
commandToRadio("sub cwx all")
commandToRadio("sub xvtr all")
commandToRadio("sub memories all")
commandToRadio("sub daxiq all")
commandToRadio("sub dax all")
commandToRadio("info", callback: infoResponseCallback)
commandToRadio("version", callback: versionResponseCallback)
commandToRadio("ant list", callback: antListResponseCallback)
commandToRadio("mic list", callback: micListResponseCallback)
commandToRadio( "client udpport (vitaManager.vitaPort)")
0
Comments
-
Doug - this defect was recently fixed in one of the alpha versions we are testing for the next release. So it will be fixed with the next general release of SmartSDR which should be coming soon.0
-
Thanks Tim. As I'm sure you know, when you're writing a new piece of software and something strange happens you're never sure whether it's your code or something external. As a newbie with Flex, I couldn't be sure it wasn't an error on my part. Glad to hear your team is on top of it.0
Leave a Comment
Categories
- All Categories
- 401 Community Topics
- 2.2K New Ideas
- 691 The Flea Market
- 8.6K Software
- 198 SmartSDR+
- 6.6K SmartSDR for Windows
- 200 SmartSDR for Maestro and M models
- 462 SmartSDR for Mac
- 280 SmartSDR for iOS
- 268 SmartSDR CAT
- 221 DAX
- 395 SmartSDR API
- 9.6K Radios and Accessories
- 118 Aurora
- 354 FLEX-8000 Signature Series
- 7.2K FLEX-6000 Signature Series
- 999 Maestro
- 58 FlexControl
- 872 FLEX Series (Legacy) Radios
- 981 Genius Products
- 486 Power Genius XL Amplifier
- 359 Tuner Genius XL
- 136 Antenna Genius
- 323 Shack Infrastructure
- 228 Networking
- 487 Remote Operation (SmartLink)
- 147 Contesting
- 848 Peripherals & Station Integration
- 148 Amateur Radio Interests
- 1.1K Third-Party Software
