SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
How can I retrieve or set DAX RX stream RXgain using FLEXLIB?
I have a program that interacts with my 6600 using the FLEXLIB interface, but I am not able to see changes in the RXGain property of a DAXRXAudioStream object and if I change RXGain, it has no effect. I must be missing something simple.
I have a handler active for the DAXRXAudioStream PropertyChanged event and I see it entered when I create or destroy slices on the radio, noting updates for the Slice and ClientHandle properties as well as frequent updates for the BytesPerSecFromRadio property. However the RXGain property remains always at 50.
Even if I use the SmartSDR DAX program window to move the RXGain slider for a stream from 50 to something else, I do NOT see any corresponding PropertyChanged events in my handler. And if my program updates the RXGain property it is not reflected in the SmartSDR DAX program window.
I have used Wireshark to see what happens when I change the slider from the SmartSDR DAX window and see that the TCP command being sent to the radio is e.g.
C1 1057|audio stream 0x4000009 slice 0 gain 57
The audio stream 0x4000009 when converted to decimal does indeed match the StreamID property of my DAXRXAudioStream object as does the Slice property.
It almost looks like the actual property being manipulated is one named gain instead of RXgain as is exposed by the FLEXLIB DAXRXAudioStream object. What am I missing?
Howard, K7JNX
Answers
-
Howard,
Because the audio stream are considered a per client object with persistence being stored in the client itself, the changes to the audio stream object are not reflected to other clients (and we typically do not reflect changes back to the client that changed a value to prevent loops).
As such, I think what you're observing is the expected behavior of the design. Can you tell us more about what you're trying to do? Perhaps we can suggest a way to do that with the existing API or consider a change going forward.
0 -
Thanks for responding, Eric.
What I'm trying to do is to automatically boost the audio gain of the appropriate DAX RX Stream from 50 to 99 when I switch the mode to CW and to change it back to 50 when the mode switches back to any other mode. (I'm using MRP40 to listen to the DAX audio stream when in CW mode and it is much happier with more audio gain.)
Howard, K7JNX
0 -
I get that the changes you're trying to make are not reflected on the GUI, but have you tried sending the commands to see whether they affect the gain (even though the DAX GUI doesn't change)? I would have to revisit our rules about whether we allow other clients to change the gain for a different client's streams, but I suspect that may work even though the GUI may not change.
0 -
Interesting question "have you tried sending the commands", Eric.
I don't "send commands", instead I set and get the rxgain property of the DAXRXAudioStream object. Having said that, I just now tried the experiment of toggling rxgain between 0 and 99. To my surprise (and as you suspected) I found that when I set rxgain to 0 the audio to a client program is indeed completely cut off and when I set it to 99 the audio is restored and the client can see it again. (And of course the display in the GUI does not change.)
I can sympathize with the idea that it probably makes sense not to raise some propertychanged events of the DAXAudio streams to clients. However I'd strongly argue that it DOES make sense to return the accurate current value of a public property like rxgain to a client when the client explicitly requests it via a property get. Otherwise the published specifications for the DAXRXAudioStream are a falsehood.
Howard, K7JNX
0 -
Point well taken Howard. I'll take this to our software team and we will discuss. Thanks for trying this and for the feedback. This is #J8672 for reference.
0 -
Thanks, Eric.
0 -
Two years later, what's the status of #J8672?
0
Leave a Comment
Categories
- All Categories
- 289 Community Topics
- 2.1K New Ideas
- 535 The Flea Market
- 7.5K Software
- 6K SmartSDR for Windows
- 146 SmartSDR for Maestro and M models
- 360 SmartSDR for Mac
- 249 SmartSDR for iOS
- 231 SmartSDR CAT
- 172 DAX
- 352 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 29 FLEX-8000 Signature Series
- 851 Maestro
- 44 FlexControl
- 847 FLEX Series (Legacy) Radios
- 798 Genius Products
- 417 Power Genius XL Amplifier
- 278 Tuner Genius XL
- 103 Antenna Genius
- 243 Shack Infrastructure
- 166 Networking
- 404 Remote Operation (SmartLink)
- 130 Contesting
- 631 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 870 Third-Party Software