Can not make it work with sdrangel 4.11.9
Closed this issue · 8 comments
Hello,
I followed your exact instructions but I can not make your program work with sdrangel 4.11.9.
I have followed the instructions to the letter but nothing happens when I hit the R or T key on my keyboard. There are no errors generated either when I launch the script manually from a terminal
./angeltrack.py --tx or ./angeltrack.py --rx . I also tried "python3 angeltrack.py --tx" , there are no errors either but nothing happens
My understanding is that the parameter --txoffs is optional, right ?
Would be nice to have a step by step procedure on how to install the software, what python librairies need to be installed, how to install those libraries.
I have used other python scrips and they work, so I am confident the REST API is doing ok.
Many thanks
Regards
Peter
Hi Peter,
If running the script does not produce errors, then you should be good in terms of Python dependencies.
What exactly happens when you run ./angeltrack.py --tx and ./angeltrack.py --rx? Do you see sdrangel switch to TX/RX respectively? If so, then only the key bindings might be the problem. Otherwise, maybe something has changed in the REST API.
--txoffs is indeed an optional argument.
Hi Stefan,
Please find below the SdrAngel console output when I run ./angeltrack --tx when receiving on device 0, so with the objective to transmit on device 1. I hope it helps. As I said before nothing happens in SdrAngel, would have expected device 0 (the receiver) to stop and device 1 (the transmitter) to start, but nothing happens; nada, zero, niets, niet etc.. so it is certainly not a simple "keyboard key" issue.
I confirm I have installed argparse, requests and flask and see no errors when I launch angeltrack. However what I did not do is configure anything in terms of reverse API (unless I am mistaken, it was not asked in your instructions), but I see in the SdrAngel console messages that something may have been going wrong at that level.
=> If I have to do something on the SdrAngel GUI to activate with this reverse API for some devices and channels (never done that before) please let me know what needs to be done exactly.
I would also be interested to know with which version of SdrAngel you tested you program, I will clone and compile it, that way it will eliminate a source of possible issues.
I really like your program and would like to make it work as it does all what I need.
Regards
Peter
SdrAngel console message
2019-10-06 09:06:31.757 (D) HttpConnectionHandler (0x56190ca29190): received request from 127.0.0.1 (GET) /sdrangel/deviceset/0/channel/0/settings
2019-10-06 09:06:31.758 (D) HttpConnectionHandler (0x56190ca29190): disconnected
2019-10-06 09:06:31.759 (D) HttpConnectionHandler (0x56190ca29190): received request from 127.0.0.1 (GET) /sdrangel/deviceset/1/channel/0/settings
2019-10-06 09:06:31.761 (D) HttpConnectionHandler (0x56190ca29190): disconnected
2019-10-06 09:06:31.763 (D) HttpConnectionHandler (0x56190ca29190): received request from 127.0.0.1 (PATCH) /sdrangel/deviceset/0/channel/0/settings
2019-10-06 09:06:31.763 (D) SSBDemod::webapiSettingsPutPatch: forward to GUI: 0x56190c2c7690
2019-10-06 09:06:31.763 (D) SSBDemod::handleMessage: MsgConfigureSSBDemod
2019-10-06 09:06:31.763 (D) SSBDemod::applySettings: m_inputFrequencyOffset: 0 m_rfBandwidth: 3000 m_lowCutoff: 300 m_volume: 1 m_spanLog2: 3 m_audioBinaual: false m_audioFlipChannels: false m_dsb: false m_audioMute: true m_agcActive: false m_agcClamping: false m_agcTimeLog2: 7 agcPowerThreshold: -100 agcThresholdGate: 4 m_audioDeviceName: "System default device" m_useReverseAPI: false m_reverseAPIAddress: "127.0.0.1" m_reverseAPIPort: 8888 m_reverseAPIDeviceIndex: 0 m_reverseAPIChannelIndex: 0 force: false
2019-10-06 09:06:31.763 (D) SSBDemodGUI::handleMessage: SSBDemod::MsgConfigureSSBDemod
2019-10-06 09:06:31.764 (D) HttpConnectionHandler (0x56190ca29190): disconnected
2019-10-06 09:06:31.767 (D) HttpConnectionHandler (0x56190ca29190): received request from 127.0.0.1 (PATCH) /sdrangel/deviceset/1/channel/0/settings
2019-10-06 09:06:31.768 (D) CWKeyer::handleMessage: MsgConfigureCWKeyer
2019-10-06 09:06:31.768 (D) SSBMod::handleMessage: MsgConfigureSSBMod
2019-10-06 09:06:31.773 (D) HttpConnectionHandler (0x56190ca29190): disconnected
Ok, I have checked the 4 boxes to activate the reverse API of device R0 and T1 and two corresponding SSB Demod and Mod channels. Now when I do ./angeltrack.py --tx, the audio is muted which is a good start, but R0 does not stop and T1 does not start to transmit....doing ./angeltrack --rx unmutes the audio
I did not change the device index in the reverse API, just checked the 4 boxes. I noticed that indexes are 0 for all 4 settings ? Is this normal ?
Looking good so far!
The idea behind the script is that R0 and T1 continuously receive and transmit (i.e. you manually have to start transmit/receive once for both and they will keep doing that).
The script only controls the audio mute controls (RX speaker muted during transmit, TX microphone muted during receive). So in case that happens for you, everything works as it should. I tend to keep the RX tab open to check on the RX Waterfall during transmissions, the audio muting just gets rid of the annoying audio lag and makes it a convenient keyboard operation with the hotkeys.
Thanks, ok got the point ;-) it is faster that way indeed, in ssb no need to start/stop the devices, controlling the audio is sufficient.
But what about the frequency of the transmitter? I was expecting that it would be updated to match the one of the receiver ? Nothing happens, frequencies do not change. I tried ./angeltrack --tx --txoffs=0 but it does not align the transmit frequency with the receiver one
Yes it does.... So I guess everything works as designed then
The possibility to have an offset on the SSB modulator is of course very useful but Unfortunately it does not solve my my problem, I also want the TX central frequency to be equal to the RX central frequency +/- an offset (for instance to work OSCAR 100, I would listen to the LNB converted signal on 750 Mhz and TX on 2400 Mhz, so that makes a +1650Mhz offset). Would it be complicated to modify your script to add that functionality ? I see no simple solution available and I am not a programmer otherwise I would program it myself
Works as designed