CW Reverse-paddles GUI option missing #70
Comments
|
The second patch here is an ugly hack to mess with the ifdef's, add the reverse-paddle GUI option back in, and make it so that I don't have to de-select CWDaemon to twiddle CW options for my Hermes board. Would need cleanup for the main code. Also: I -think- the "weight" option should more appropriately be named "ratio". "weight appears to be how narrow the dot is within a standard dot spacing. Ratio is the ratio of the dot to the dash timing (and really should always be at 1/3rd). diff --git a/radio.c b/radio.c
|
|
Well, the options look better in the GUI but CW doesn't work for me anymore, whether I enable CWdaemon or not. Key is plugged directly into the Hermes by the way. |
|
Operator error (last comment). The changes still require CWdaemon to be disabled to tweak CW settings, but it has to be enabled to make CW work at all. Something's still not right (but it's better). |
|
I found the gtk_widget_set_sensitive() calls in radio_dialog.c and commented-out the ones that set it to FALSE. I can now change the CW settings. Not getting any audio from CWdaemon yet (issue #72) through pulseaudio. |
|
Hi, I wrote most of the cwdaemon code, so let me try and answer these queries. Firstly, this is still all experimental and I only have a hermes-lite 2, so I'm anxious how some of this functionality might interact with other HPSDR or Anan radios. However, I am keen to improve upon this, so feedback like this is useful, thanks. My main drive behind implementing this was for remote CW. By remote I mean the radio is not located with the user. CWdaemon is primarily for allowing linux logging software (tlf, cqrlog, yfktest) to talk directly to linHPSDR and send CW macros from the logging software. I've used this a lot for contesting over the past 6 months now. If the user wants to do remote CW with a paddle, then the MIDI route must be followed. Please see here for details: https://github.com/softerhardware/Hermes-Lite2/wiki/docs/CW_and_Logging_on_linHPSDR.pdf You will need to homebrew some hardware, but it is very easy. I'm hoping someone will rise to the challenge of integrating a keyer with some MIDI functionality. My todo list is already too big. With this method you will achieve a sidetone latency that I cannot notice any problem at 30 WPM. I measure it as around 12 ms on my PC setup. If I understand correctly, you wish to connect a paddle to your Hermes radio, listen to the rx audio on the PC AND the sidetone on the PC. At the moment the only way to do this is using duplex mode and this does not need CWDAEMON. I would recommend make clean && make with CWDAEMON #ifdef commented if this is what you want to do. However, depending on the speed you wish to send at, the latency will be a big problem. I don't think this is very good solution, hence why I implemented MIDI. I think the Hermes radio allows you to send audio from the PC back to the Hermes? This would allow you to hear sidetone and RX audio? Failing that, you are looking at mixing audio and it all gets messy. In summary, I'm not sure that currently linHPSDR does meet your exact expectation. However, I can assure you that the MIDI route is much better than what I think you expect it should do with paddle connected to the radio. The only thing I'm not sure about with the MIDI route with the other HPSDR/Anan radios is I have a suspicion the TX packet buffers are quite big in the FPGA. This will result in some latency between when you hear sidetone in the PC and when the RF goes out of the radio. Depending on your operating style and speed, this may be a problem. The Hermes-Lite 2 has an option to control the size of this buffer to combat this problem. A few of us have done a lot of work on with the HL2 to really improve use for remote CW. To answer this exact problem, if you change line 1105 in radio_dialog.c from: if ((radio->discovered->device == DEVICE_HERMES_LITE2) || (radio->discovered->device == DEVICE_HERMES)) { to if (radio->discovered->device == DEVICE_HERMES_LITE2) { I think this should allow you to see the reverse paddle box? |
|
I messed with the code a bit to get the reverse-paddles widget displayed but it ended up displaying underneath the cwdaemon socket widget. I tweaked the code some more and put it further to the right. |
|
I think it is best to tackle this 1 issue at a time. As you correctly state, with the configuration I described above, a paddle connected to an Hermes should work and if this is not the case I would like to fix this. From your synopsis of how you wish to operate, I believe that you do not to be compiling linHPSDR with CWDAEMON as an option in the Makefile. I have just done a manual inspection of the code and I can't see why you would have to compile with this conditional to make CW work. Please take a clean git clone and ensure that in the makefile the following line is commented out (which is should be by default): (line 49) #CWDAEMON_INCLUDE=CWDAEMON build this (make). I would like to confirm behaviour of CW operation with this configuration. Then we can tackle paddle reverse options. |
|
With clean Git copy, no changes to the code: Keyer doesn't work. No
transmit, no sidetone. On the Configure main screen I see "Keyer Mode
A" on the first line, no CWdaemon options, and no reverse-paddles
option. Am running with Bencher paddle directly to the radio and
separate speaker plugged into the back panel of the radio. The same
configuration H/W-wise works with piHPSDR, just tested that again as
well, with sidetone coming from that radio-connected speaker.
To answer your previous message about changing that one line of code
to get the "Keys Reversed" set of widgets in there: Yes, that works.
However I'm not seeing the options for CWDaemon on that line at all.
Earlier I was able to get them to appear by messing with the #ifdef's,
but the CWDaemon widgets overwrote the "Keys Reversed" widgets 'cuz
they got written to the same area of the dialog (first line, positions
2 and 3).
…On Sun, Jun 21, 2020 at 12:37 AM m5evt ***@***.***> wrote:
I think it is best to tackle this 1 issue at a time. As you correctly state, with the configuration I described above, a paddle connected to an Hermes should work and if this is not the case I would like to fix this.
From your synopsis of how you wish to operate, I believe that you do not to be compiling linHPSDR with CWDAEMON as an option in the Makefile. I have just done a manual inspection of the code and I can't see why you would have to compile with this conditional to make CW work. Please take a clean git clone and ensure that in the makefile the following line is commented out (which is should be by default):
(line 49) #CWDAEMON_INCLUDE=CWDAEMON
build this (make). I would like to confirm behaviour of CW operation with this configuration. Then we can tackle paddle reverse options.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
Curt, WE7U http://xastir.org http://www.sarguydigital.com
|
|
Disregard my earlier comment regarding "weight" and "ratio" (2nd comment on this Issue). If it was actually "ratio" the perfect setting would be 33 (dot period = 1/3rd of the dash period), but setting "weight" to 33 doesn't sound correct. I'm still messing with it but somewhere between 40 and 60 sounds like more correct code and I expect I'll settle on 50 when I'm done. May do recordings into Audacity and count the time periods to get it correct. I'm doing these timing tests with piHPSDR until I can get the keyer working in linHPSDR, as they use the same keyer inside the FPGA so the tests should be relevant. |
|
Thanks for trying the clean clone and reporting back. As I said before, I don't have a Hermes, so I'm debugging this blind. On the clean clone with CWDAEMON not enabled, please could you try changing the following in protocol1.c: (line 1526) if(radio->tune || radio->vox || !radio->cw_keyer_internal || !radio->cwdaemon) { change to: |
|
Ok. The internal keyer is working with that mod. BTW: Am doing a "make
clean" each time. Progress!
…On Sun, Jun 21, 2020 at 10:49 AM m5evt ***@***.***> wrote:
Thanks for trying the clean clone and reporting back. As I said before, I
don't have a Hermes, so I'm debugging this blind. On the clean clone with
CWDAEMON not enabled, please could you try changing the following in
protocol1.c:
(line 1526) if(radio->tune || radio->vox || !radio->cw_keyer_internal ||
!radio->cwdaemon) {
change to:
if(radio->tune || radio->vox || !radio->cw_keyer_internal) {
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#70 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEMNKXYSBCYND52CDPW4OWLRXZB2FANCNFSM4OC2TKJQ>
.
--
Curt, WE7U http://xastir.org http://www.sarguydigital.com
|
|
Phew! If I understand correctly, you now have cw working without the need to compile with CWDAEMON, a paddle plugged in to the radio works and you can hear sidetone from the radio codec. With the previous 1 line I suggested, you can now reverse paddle keys. I think this fixes all the bugs you have reported? Thanks for the bug reports. |
|
At this point yes, except that enabling CWDaemon doesn't bring in the widgets for that on the Configure main dialog anymore, not that I need them for my current H/W setup. Since that's experimental at this stage anyway, go ahead and close these three issues. I'll open another one shortly, unrelated to these 3. |
|
Of course I meant close them -after- making your code tweaks to master. ;-) |
CW options in linHPSDR don't allow me to reverse paddles (I have mine wired backwards from most people). Found there was a variable in the config file I could tweak to do this, but it's missing the GUI option for setting it.
The text was updated successfully, but these errors were encountered: