I¡¯ve been pouring through the code and I¡¯ve done something which appears to have improved manual CW sending. ?It also seems to make the upper encoder more responsive and less prone to ¡°slacking¡± when rotating quickly.
In sbitx_gtk.c change:
int?e = g_timeout_add(10, ui_tick,?NULL);
to:
int?e = g_timeout_add(1, ui_tick,?NULL);
This changes ui_tick from being called every 10 mS to every 1 mS.
In ui_tick(), change:
if (ticks == 10){
To:
if (ticks == 100){
And break these two lines out of the (ticks == 100){}:
? ?modem_poll(mode_id(get_field("r1:mode")->value));
? ?update_field(get_field("#text_in"));?//modem might have extracted some text
I don¡¯t know if this actually had an effect on the CW TX/RX cycling problem I¡¯m also experiencing, but that problem went away with this change. ?Keyboard CW sending seems more fluid as well.
?
Code is here:
I¡¯m not sure if this is a prudent code change, or what it may break, I¡¯m just playing around and learning right now¡.
73
Goody
K3NG
toggle quoted message
Show quoted text
I would attempt to use my Arduino keyer, however when I switch over to straight key mode I still notice the delay, so an outboard keyer won¡¯t help.
I reniced the sbitx process several times, and went all the way down to -20 (maximum priority), with no change in the responsiveness.
I¡¯m also experiencing the issue with attempts at keyboard-sent CW putting sbitx into a cycling loop between TX and RX loop with no RF coming out. ?
73
Goody
K3NG
On Aug 8, 2022, at 20:17, Gerald Sherman <
ve4gks@...> wrote:
Might want to look at the WinKeyer by K1EL
Gerry Sherman
Sent by the? Thunderbird
On 2022-08-09 00:12, Anthony Good wrote:
Agreed on the relay coil. ?There are also several TX voltage points, like on R5, R39, R42 that one could tap into.
I¡¯ve had the same questions regarding Linux and timing. ?I noticed initial keying from the CW paddle seems delayed. ?I¡¯m going to play around with nice to see if there¡¯s any difference. ?It may make sense in the future to move timing-critical items out to separate executables.
73
Goody
K3NG
On Aug 8, 2022, at 19:58, Max via
??<
kg4pid@...> wrote:
If it was me, I'd tie into the transmit relay coil, you only need a few milliamps of current for an led. What happens if the radio gets RF into it and locks up the PI? It might not indicate that the radio is in transmit when it really is. That and a time-out timer on the transmitter should be done in hardware, not software.
I wonder how many here know that the version of Linux that is being used is NOT a real time operating system and will do little housekeeping jobs whenever it needs to. I hope this doesn't cause operational problems for the sBit.
Max KG4PID
On Monday, August 8, 2022, 06:10:15 PM CDT, Scott KE8KYP <
scott_massey@...> wrote:
?
Hi All,
I am adding a simple PWR LED to indicate when the PWR switch is turned on.? I am also looking for a way to drive a single LED that activates when the sBitx is in transmit mode.? The reason I think it would be helpful is once the screen saver activates, there is no way to determine if the radio has a stuck PTT or something you might want to know about.? I know Ashhar is extremely busy but in a previous post, he suggested using one of the two unused pins of the encoder.? I don't think he means one of the two rotary but I am confused what he meant.? So I am asking the question to the group: if you were going to drive an LED to indicate transmit, how would you do it?
I am thinking once the tie-in location is identified, writing/adding a define and digitalWrite to turn on the LED is the task.? Of course I am hoping for a single location for the addition, perhaps in in the tx_process but that a guess.? Any suggestions would be great.
Thanks in advance, Scott??
