Receiver Data Transmitted when Selecting PTT in DGT Mode.
I now have an update on the subject of erroneous TX power being output at the point of actuating the PTT in the DGT Mode.
To recap, here is my original post:-
" If I select PTT when in the DGT-U Mode I get TX Drive output for approximately 0.5 Seconds then the TX output disappears. I do not have any other digital application running at the time of this test. I would have expected Zero TX Output in this test ?
This result is the same for a Null Mic or the Internal PC Mic or an external USB Mic having been selected.
I then selected the Spot Slider and reduced the Slider value to Zero. I still see a TX output for a short period of time when selecting the PTT. I get Zero TX Output when I select Spot in this condition, the Spot also commands the Radio to go into TX at this time, which is correct.
To conclude, TX Drive is being produced momentarily when selecting the PTT. But there is no application providing a TX Drive. This PTT RF is NOT present in the SSB Modes, only DGT Modes. "
I now have additional data on the above with the DGT Mode selected:-
1) The duration of the transmitted RF is approximately 300 to 500 milliseconds at the start of selecting the PTT.
2) When receiving ' Atmospheric Noise ' at the point of selecting the PTT, the RF Output Power
Level is a function of the Filter Bandwidth. The greater the Filter Bandwidth, the greater the RF Output Power.
3) The RF Output during the above test is RANDOM noise in character. ( Power Level approximately 3 to 5 watts).
4) When receiving the ( High Level) TEST 1 Continuous Tone at the point of selecting PTT, there is now 500 milliseconds of CONSTANT amplitude High Level RF Output. ( Power level in the order of 30 Watts o/p.)
5) If I use Digital Apps with Quisk set up I.A.W. your installation information, the RF is present at the start followed with the App RF Transmission Data.
The conclusion is that the Receiver Data just prior to the selection of PTT is Transmitted for 300 to 500 milliseconds at the start of TX operation in the DGT Mode. Only the DGT Mode is affected, all other modes operate as expected.
I hope the above additional information helps in you being able to replicate the issue.
Re: Receiver Data Transmitted when Selecting PTT in DGT Mode.
Thanks for your latest version 40. It is excellent work.
We are currently continuing our qualification testing and to date there has been no appearance of the python crash, which is excellent.
Regarding the receiver data being transmitted when selecting PTT with the DGT Mode selected.
At the start of TX the issue is still there using the Globemaster SDR.
I then decided to set up my Softrock SDR and go through the same test.
I am observing the same DGT issue with the Softrock.
Below is the config in use during the testing of the Softrock.
Hardware file path: softrock/hardware_usb.py
Widget file path: softrock/widgets_tx.py
Vendor ID for USB control: 0x16c0 Product ID for USB control: 0x05dc
I2C address: 0x55 Use Si570 direct control: False
Si570 crystal frequency: 114285000 Key poll time msec: 0
Key hang time secs: 0.7 Repeater delay secs : 0.25
Max ampl correct: 0.2 Max phase correct: 10.0
Tx audio level: 0.7
Play latency msec: 150 Digital output level : 0.7
Radio Audio Output: 48000 Ch I ( Blank), ChQ ( Blank), Delay (Blank). Speakers (Plantronics .Audio628USB)
Microphone Input: 48000 Ch I 0, Ch Q 0, Delay ( Blank), Microphone (Plantronics .Audio628USB)
I/Q Sample Input: 48000 Ch I 0, Ch Q 1, Delay ( Blank), Microphone (High Definition Audio Device)
I/Q Tx Output: 48000 Ch I 1, Ch Q 0, Delay ( Blank), Speakers (High Definition Audio Device)
Digital Input: 48000 CABLE Output(VB-Audio Virtual Cable)
Digital Output: 48000 CABLE Input(VB-Audio Virtual Cable)
I/Q Sample Output: ----------------------Blank--------------------------------
Digital Rx 1 Output: ----------------------Blank--------------------------------
I am using a Plantronics 628 USB Headset for the Microphone and Speaker function.
The Microphone and Speaker(High Definition Audio Devices) are the Line in , Line Out functions on a Samsung Laptop PC that I am using.
The Softrock SDR is fine on the other Modes, SSB CW AM FM - Just like the Globemaster SDR.
The issue is only with the DGT Mode at the moment of selecting PTT.
The easiest way to display the maximum RF Output at PTT selection is to be set up receiving the RX 'Test 1' Tone at the point of actuating the PTT Button.
Jim, I hope you can replicate the condition with the above settings.
I presume you do have a Softrock SDR ?
BTW, I had not switched on the particular Softrock used for the this test for years. Nice to see it perform as ever.
Thank you again for all your work on the Quisk Application. Andrew and myself are very mindful of the many thousands of hours it takes to produce Hardware and Software of this quality.
Re: Receiver Data Transmitted when Selecting PTT in DGT Mode.
I created a test setup using the SoftRock according to your instructions and I was able to duplicate your problem. I was always puzzled why radio sound output could make it into the transmit path. Quisk has no such path. The digital transmit data is on the mic path. I now see that the VB-Audio Virtual Cable is looping receive audio back to the Tx path.
The Quisk receive audio is always sent to the VB-Audio for use by an attached digital program. I added code to Quisk to monitor the level of audio received by the mic and by the VB-Audio transmit data sent back to Quisk. The mic was easy. A low level of noise was received which increased when I spoke into the mic. The level read from the VB-Audio was unexpected. With no digital program attached to the VB-Audio (VB-Audio devices in use but no digital program), the VB-Audio sends its input back to its output. That is, it sends the Rx audio Quisk is sending back to the transmit path Quisk is receiving. When the PTT button is pressed, the various buffers have Rx audio in them that is transmitted. Quisk will stop sending audio, and so the received audio will go to zero after the buffers flush.
With no digital program connected I expected the VB-Audio to either send zero-valued samples or to report no samples available. I tested the same setup on Linux, and the loopback device returns zero-valued samples. That explains why the problem only appears on Windows.
It is alarming that the VB-Audio may loop back its audio even with a digital program connected. I did not test this.
Next we need to figure out how to fix this. Perhaps VB-Audio has a setting somewhere to defeat the loopback. Perhaps a different virtual cable would not have a loopback. I can change Quisk to flush the Quisk buffers on key down. I can also provide a delay while the VB-Audio internal buffers drain, but this seems like a hack.