QSK doesn't work. #1816
Comments
|
Thank you for your report, but please use a current firmware (we have 2.11.71). |
|
BTW, I am not saying the issue is gone in the newest firmware, but we should verify that. |
|
Ok I am now running 2.11.71 and can confirm the issue is still the same. Also I forgot to mention on the original post that the malfunction is also reflected in the action on the front panel green and red LEDs labeled LD1 and LD2 on the v0.7 UI schematics. These indicate green power which is extinguished during TX and red "on air" which is supposed to light during TX but only flashes erratically with seemingly no connection to the CW which is being transmitted. Joe |
|
QSK will not work on all devices. PIN diode switching is very ugly (it distortes the TX signal) so it is recommended to swap to a relay switching. But relay switching is not fast enough for QSK. Additionally we cannot break software receiving chain at any position, because parts will be uninititialized. So we must walk through some small pieces of software at RX/TX switching. I am in doubt this can be done at QSK speed using the existent filter and buffer structures and the transceiver main loop. Changing this might end in writing a complete new firmware (which will not satisfy QSK users who followed the recommended replacing of PIN diode switching by relay switching)... |
|
Well, yes, switching takes some time, but I remember looking at this a long while ago, and it was not too bad, even with a relay we can switch in a couple of ms (the suggested TXRX relay switches in 10ms according to the data sheet, in reality the time is shorter). Which setting are you using for the CW key? Straight or do you use one the integrated CW keyer? |
|
which latency would you like or would you expect? Give us a figure and we can judge whether that would be theoretically (or even practically) possible. There are different figures out there:
One very quick speculative guess is, that with UHSDR and a standard SDR hardware we will never be able to push latency to less than 30msec given the filter processing, codec latency and loop/interrupt handling inside the code. The block handling with 64 samples and subsequent FIR filtering with more than 200 taps at 12kHz internal sample rate is only a small part (5.3msec + 8.3msec) of the total theoretical latency of the receive path. BTW, has anybody really measured the receive latency of UHSDR with any hardware from antenna to headphones? 73 Frank DD4WH |
|
I have some QSK lovers within my friends. They have (mental) problems with 10ms delay at the beginning of TX because the first dit is crippled too much. I do not know if these problems are relevant - because I am not able to work in QSK (and I am sure: I will never be able to). But it is very problematic to do QSK with modern digital driven rigs (except you attach an eight-core PC @ 5GHz clock with 32GB RAM). I am in doubt if we can satisfy a QSK fan with embedded systems computing. Problem is the first sign when going to TX. There should be no delay computing for more than a couple of ms. If the device should be capable of full bk - we have lost using SDR. |
|
@DF80E I don't understand yourcomments from earlier. PIN diode switching is not ugly. Everybody who is serious about QSK uses PIN diodes. The PIN diode does not create intermodulation if it is sufficiently biased, it is only a problem if it is not correctly implemented. Just look at some other designs like Ten Tec or Elecraft for example. Also I am not experienced with the code as written for mcHF but I have worked with assembly language for many years so I understand embedded control to a good degree. Shouldn't the paddle input be assigned to a high level interrupt priority? So how long can it take for the quite fast STM micro to respond to the key? I think it more likely that the sofware implementation doesn't consider the keying as a top priority maybe. Just my guess on it. |
|
@DD4WH The KX3 from Elecraft is such a rig. It has beautiful full breakin QSK. So it is quite possible if the code is correctly written. Hans promises the same from the soon to be released QSX rig. mcHF should be also capable no? |
|
@db4ple I cannot send very fast with straight key but I can use an external keyer to emulate that and will give it a try this evening and report back. I may have to make a cable for that test and I have a new puppy at home who takes my every moment just now but I will try to get it done. |
|
PIN diode switching is not bad in general. It is bad how it is implemented in mcHF. It causes much distortions on TX signal (reproduced by many users) up to PA oscillation. So it is a hardware issue that diode switching does not work as expected. KX3 must not feed waterfall and / or spectrum LCD so it is not comparable. UHSDR is optimized for giving both (simultaneously, if you want) in standalone using one single MCU. That eats horse power... |
|
@RightRudder: take your time, this issue has been in for so long... |
|
OK I am happy to report the QSK works pretty well in straight key mode while using an external keyer. Even the front panel red/green LED's flash as expected. I guess there is a bug somewhere in the internal keyer function? |
|
One more comment, is there any reason the straight key input has to be on the P DAH line which goes to Port E PE0 pin? This maps to the ring terminal of the key jack which caused me some headache. Most external keyers I think use the sleeve and tip terminals. If it is possible to just use the Port E PE1 pin for straight keying that would fix that issue also. |
|
It just happened to be designed like this by Chris, M0NKA. Simply changing the assignment now would make all existing, working setups non-working... |
|
Just for record some measurements. UI board UHSDR-OVI40, cw speed 28 wps, delay 0ms. This is from memory bank. Input using external key. |
Then another possibility would be reverse paddle inputs in menu? I didn't think about that when I tried the test last evening. |
|
I made a recording of the RF signal this evening. I guess I thought it was better with the external keyer, well there is an issue there too for sure, but although the rig is trying to T/R switch at the keying rate, the output is really chopped up. I sent a series of VVV 3 times followed by my call 3x and then SK. |
firmware version: D2.10.0
bootloader version: 5.0.1
Hardware
With TX initial muting time set to 0ms in config menu and CW TX->RX delay set to 0ms in CW mode settings menu there is still a significant delay which makes proper sendin impossible. I tested at wpm set to 25wpm. Both local sidetone and actual on air signal are affected. Another forum member also mentioned this. If the TX->RX delay is set long enough compared to the normal delay between charaters and words then the rig stays in TX mode and sending is smooth but if the rig actually switches back to RX and then TX while sending CW (which it should for proper QSK operation) then an extra delay is introduced which causes keying errors. I searched the term QSK in open issues before opening this issue and found zero results.
The text was updated successfully, but these errors were encountered: