ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
esc to dismiss
|
Hi Steve,? I worked on the CW improvements for the the latest 64-bit dev code. Like you indicated, the issues is how GPIO is polling the key input.? However, I did find a major issue in the Iambic B code that has been addressed in the upcoming 64-bit code release. I find most people are not Iambic B users, or only uses it as back-and-forth paddle keying and not squeeze keying. Initially before addressing this bug, I could not send at all with the sBitx and would constantly mess up at the ending of the character sequence.
The polling issue is still there using the internal keyer in the 64-bit dev code. The current polling method requires the CW_DELAY? to be delay to be extended to avoid the initial poll. If the paddles are not held for a split second longer, you can still miss a initial character sequence. I've train my mind to let go of the dot/dash after I start hearing the character being sent. This is annoying at higher speeds, but my mind is slowing compensating for this.? I can spend reliably at 30wpm.?
I've looked at improving the straight key mode, and may have improved it slightly, but still not happy, especially with an external keyer at high speeds. This is not included in JJ's release as it's more for experimenting.? Again, the polling for the input is the issue.? It would require major rework and setting up interrupts to handle the cw key input.?
I also cleaned up the spacing for the keyboard and macros.? The spacing was way too long.? The new code sounds much better.? I am curious to see what you think.
IMO, internal keyer now useable, but not perfect.? Another thing to note, the Iambic mode, which I assume should be A, is not correct.? It's still remembering the latest dot or dash, like Iambic B.? I haven't had time to look at that as I can't send using Iambic A.? The Iambic B mode seems to work best for the "non" squeeze CW operators.
73,? Chris w0anm
|
I am going to ask the question then. how do the Elecraft and Flex transceivers get around this problem by using external keyers as their users suggest this solves their high speed CW issues. As a processor the Raspberry Pi is no slouch when it comes to sped of processing. or is the issue the means of translating the man written computer written code into machine derived code (Compiling). Remember even the original Mac had to write some parts in binary to make it fit the available memory and the required speed of processing. I for one do not believe CW requires more clock cycles than the Radio. A Software Defined Transmitter (encoder) does require more clock cycles than a pure CW transmitter. These are the times when having a pure CW transmitter and a pure CW Receiver have advantages (frequency spotting is one) the lack of wasted power in the side bands is another, just because the carrier is suppressed does not mean the Power Amp is not amplifying the upper and lower carriers. There has been many papers written on this subject as to the destructive waste of power these sidebands create or burn up in the form of excess Heat and excess RF Noise. With a Software Defined Radio why not create a pure CW Transmitter and pure CW Receiver. Has anyone even considered going back a step.
As Ashhar has stated the SBitX is a Hybrid SDR for a reason. There are RF components at the Front and Back end for a reason. Perhaps a second look at the process in light of the users wanting a CW Transceiver.?
Look at the Simple CW only Devices on the market for the POTA and SOTA Crowd. While a SSB Transceiver does enable all the digital modes with ease. In the basic design is it possible to configure the software to enable a Pure CW Transmitter and a Pure CW Receiver. Is the required hardware for this physically present or is this an unrealistic dream or just an oversight due to expediency of simplistic design, if one assumes an SSB Transceiver is good enough. It may well be it is good enough for the average Amateur Radio operator and the CW purists should really look elsewhere or to different technology to satisfy their addiction to high speed Morse via radio.
Thanks for Listening to an old (83) grump. VE6LX
|
I have looked at the operating manual for the K1EL WinKeyer ICs, which would fall in the external keyer. The manual is virtually a text book on nuances around the art of sending morse code. For example, here is short commentary on the problem of break-in keying that shows we aren't the first to appreciate this problem...
"WinKeyer addresses problems often encountered when keying older transceivers with slow break in
response. Due to a slow receive to transmit changeover time, the first dit or dah of a letter sequence can be
chopped and reduced in length. Adding a fixed amount to the first element of a sequence can compensate
for this ... A challenge in this scheme is to determine when sending has stopped long enough to cause the transceiver
to switch back to receive. If it has it’ll require a new first element correction on the next sequence. WinKeyer
uses the PTT tail timer to determine this" (I copied everything in the quotes from the WinKeyer manual)
So, we sbitx folks have got really ambitious expectations. To get fast break-in, we've already got fast relay-less T/R switching. But in the short break between dits and dahs at high speed is it reasonable to expect we can collect a long enough set of samples, convert to audio and hear something meaningful, while continuing to poll for the state of the keyer? Analog rcvrs do seem to have an easier problem ...
It's working surprisingly well I think, and it's going to get better.
--
Mike KB2ML
|
Why not poll faster during the times you can tell that the operator is sending CW? ? There is really no reason to receive while transmitting in a unit that can’t quite do full break-in, is there? ?speed up the polling to maybe 30 times per second. ?While polling faster, don’t try to initiate FFT receive ;?
When you observe no straight key closures for a time equal to or greater than CW delay * n , change the polling back to slow polling.
Try a different values of n until it works right
That still gives you relay-free ?transmit/receive, switching, probably between words?
Gordon?
toggle quoted message
Show quoted text
On Sep 28, 2024, at 13:51, VE6LX via groups.io <dclarke2@...> wrote:
? I am going to ask the question then. how do the Elecraft and Flex transceivers get around this problem by using external keyers as their users suggest this solves their high speed CW issues. As a processor the Raspberry Pi is no slouch when it comes to sped of processing. or is the issue the means of translating the man written computer written code into machine derived code (Compiling). Remember even the original Mac had to write some parts in binary to make it fit the available memory and the required speed of processing. I for one do not believe CW requires more clock cycles than the Radio. A Software Defined Transmitter (encoder) does require more clock cycles than a pure CW transmitter. These are the times when having a pure CW transmitter and a pure CW Receiver have advantages (frequency spotting is one) the lack of wasted power in the side bands is another, just because the carrier is suppressed does not mean the Power Amp is not amplifying the upper and lower carriers. There has been many papers written on this subject as to the destructive waste of power these sidebands create or burn up in the form of excess Heat and excess RF Noise. With a Software Defined Radio why not create a pure CW Transmitter and pure CW Receiver. Has anyone even considered going back a step.
As Ashhar has stated the SBitX is a Hybrid SDR for a reason. There are RF components at the Front and Back end for a reason. Perhaps a second look at the process in light of the users wanting a CW Transceiver.?
Look at the Simple CW only Devices on the market for the POTA and SOTA Crowd. While a SSB Transceiver does enable all the digital modes with ease. In the basic design is it possible to configure the software to enable a Pure CW Transmitter and a Pure CW Receiver. Is the required hardware for this physically present or is this an unrealistic dream or just an oversight due to expediency of simplistic design, if one assumes an SSB Transceiver is good enough. It may well be it is good enough for the average Amateur Radio operator and the CW purists should really look elsewhere or to different technology to satisfy their addiction to high speed Morse via radio.
Thanks for Listening to an old (83) grump. VE6LX
|
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
|
The main challenge is to improve the response time of linux. It is Not a real time kernel.
The best way is to memory map the gpio for fast polling. That means running it at super user privilige.
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
|
I don’t know what most of that means but it sounds like a good idea if we can improve the response time, which might improve the possibilities for CW back up to usable speed for contest, which should be all the way to 30 words per minute. ? The primary usage of the raspberry is to service the radio so I don’t see any problem with it Operating at super user !
toggle quoted message
Show quoted text
On Sep 30, 2024, at 12:29, Ashhar Farhan via groups.io <farhanbox@...> wrote:
? The main challenge is to improve the response time of linux. It is Not a real time kernel.
The best way is to memory map the gpio for fast polling. That means running it at super user privilige.
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
|
|
|
toggle quoted message
Show quoted text
On Sep 30, 2024, at 15:10, Gordon Gibby KX4Z via groups.io <docvacuumtubes@...> wrote:
?
I don’t know what most of that means but it sounds like a good idea if we can improve the response time, which might improve the possibilities for CW back up to usable speed for contest, which should be all the way to 30 words per minute. ? The primary usage of the raspberry is to service the radio so I don’t see any problem with it Operating at super user !
On Sep 30, 2024, at 12:29, Ashhar Farhan via groups.io <farhanbox@...> wrote:
?
The main challenge is to improve the response time of linux. It is Not a real time kernel.
The best way is to memory map the gpio for fast polling. That means running it at super user privilige.
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
Is it not possible to use the wiringPi wiringPiISR function to trigger a callback from the key/paddle gpio pin state change?
--
73
??? Bob? KD8CGH
|
?
This link has some good examples on invoking a callback on a gpio event
|
Mike assuming 60 WPM this would be equivalent to 25 dits per ?second which is 50 changes of state per second. the Computer would have to pole the keyer and the Transmitter on or off timing 50 times per second. this comes from the timing as described by Mark Amos, W8XR ()
|
I think if you get to 30 words per minute you would satisfy 98% of the audience.?
toggle quoted message
Show quoted text
On Oct 6, 2024, at 11:20, VE6LX via groups.io <dclarke2@...> wrote:
? Mike assuming 60 WPM this would be equivalent to 25 dits per ?second which is 50 changes of state per second. the Computer would have to pole the keyer and the Transmitter on or off timing 50 times per second. this comes from the timing as described by Mark Amos, W8XR ()
|
When you’re running a processor as fast as the raspberry pie, and when there are now apparently real time additions to Linux, I think you just really need to get CW handled, someway, even if you have to make some allow allowances, such as shutting down some other portions of the system, when it’s obvious that the person is sending morse code. ??
Every other other SDR ?radio, apparently is doing this, aren’t they ? I don’t have any problems with my 7300.?
Gordon?
toggle quoted message
Show quoted text
On Oct 6, 2024, at 11:31, Gordon Gibby <docvacuumtubes@...> wrote:
? I think if you get to 30 words per minute you would satisfy 98% of the audience.?
Gordon? On Oct 6, 2024, at 11:20, VE6LX via groups.io <dclarke2@...> wrote:
? Mike assuming 60 WPM this would be equivalent to 25 dits per ?second which is 50 changes of state per second. the Computer would have to pole the keyer and the Transmitter on or off timing 50 times per second. this comes from the timing as described by Mark Amos, W8XR ()
|
What about being interrupt-driven instead of using timer-based polling? ?It looks like so far it’s done only for the encoders. ?
27006ea3 sbitx_gtk.c ?wiringPiISR(ENC2_A, INT_EDGE_BOTH, tuning_isr); 27006ea3 sbitx_gtk.c ?wiringPiISR(ENC2_B, INT_EDGE_BOTH, tuning_isr);
I was going to ask at some point anyway: what are the advantages or reasons for choosing WiringPI? ?I see there are a few GPIO libs to choose from, and don’t have much experience with RPI GPIO yet. ?(Although I did manage to read the encoders in a separate program.) ?Maybe it turns out that some make this sort of thing easier than others?
Another conventional solution would be to use a microcontroller for real-time aspects and queue up events over USB or a serial port. ?But it adds cost unless you can use one that is already needed anyway, or use a chip that has programmable I/O features.
toggle quoted message
Show quoted text
On Sep 30, 2024, at 6:28?PM, Ashhar Farhan <farhanbox@...> wrote:
The main challenge is to improve the response time of linux. It is Not a real time kernel.
The best way is to memory map the gpio for fast polling. That means running it at super user privilige.
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
|
This is why I have suggested the use of an external Keyer such as the K16 EXT by K1EL which has Lead-In and Tail-Timing built into the Keyer functions, this enable the Transceiver PTT to be activated by the Lead-In Timer by (x ms) prior the the first CW element and a Tail-Timer to hold the PTT (y ms) after the last CW element. this every old technology from the Tube Transmitter and Receiver Days and still works to day, the old Mercury Vapour Tubes used as High Voltage Diodes has a tendency to create Chirp but if the transmitter was keyed on a few ms before the first CW element was sent the Chirp was much reduced.
Please Note: at 60 WPM the computer polling of the Keyer state and the transmitter PTT state is every 17 ms
|
I have done some experiments to look into improving sBitx keying. I am running the 64 bit code, v4.02 - the folks maintaining that code base encouraged me to try some things.
The first dit or dah can't get out until the software get's through the tr_switch_de code. I inserted some code at the top of tr_switch_de like this:
void tr_switch_de(int tx_on) {
struct timespec start, end; // FOR TIMING ANALYSIS ONLY
if (tx_on) { // switch to transmit
clock_gettime(CLOCK_REALTIME, &start); // FOR TIMING ANALYSIS ONLY
and then just at the end of code that makes the switch I have this:
// FOR TIMING ANALYSIS ONLY
// Get end time and print it
clock_gettime(CLOCK_REALTIME, &end);
double elapsed = 1000*((end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9);
printf("tr_switch_de to transmit: %f milliseconds\n", elapsed);
On my sBitx it takes (on average) 31.6 milliseconds to do the switch to transmit. That's a good chunk of the time "budget" if we think a dit at 30 wpm is 40 milliseconds.
So - looking at the code there are lot's of delay() calls. The DE has electronic TR switching. Have some of these delays been made obsolete by hardware changes to the PA? I just started commenting out the delays until almost all of them are out. RESULTS: The 31.6 milliseconds goes down to 7.3 milliseconds. Seems significant. Similar changes could be made in tr_switch_v2 (I would like to hear some ideas on what the minimum set of differences between de and v2 code really need to be - I could see running them both on the same tr_switch code. I can't test the v2 code).
I have worked CW and FT8 with the trimmed down code, and I'm still on my original finals. Can the RF amplifier folks here talk about the risks involved in streamlining the code?
--
Mike KB2ML
|
Great investigation and work, Mike, I may have some time next week to take a look at it.
This really needs to get solved.
I had an external keyer that I thought was defective because it just couldn’t send good code through the sbitx but it has been come clear that It is probably the sBitx problem.
toggle quoted message
Show quoted text
On Oct 17, 2024, at 19:21, Mike Johnshoy via groups.io <mike.johnshoy@...> wrote:
?I have done some experiments to look into improving sBitx keying. I am running the 64 bit code, v4.02 - the folks maintaining that code base encouraged me to try some things.
The first dit or dah can't get out until the software get's through the tr_switch_de code. I inserted some code at the top of tr_switch_de like this:
void tr_switch_de(int tx_on) {
struct timespec start, end; // FOR TIMING ANALYSIS ONLY
if (tx_on) { // switch to transmit
clock_gettime(CLOCK_REALTIME, &start); // FOR TIMING ANALYSIS ONLY
and then just at the end of code that makes the switch I have this:
// FOR TIMING ANALYSIS ONLY
// Get end time and print it
clock_gettime(CLOCK_REALTIME, &end);
double elapsed = 1000*((end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9);
printf("tr_switch_de to transmit: %f milliseconds\n", elapsed);
On my sBitx it takes (on average) 31.6 milliseconds to do the switch to transmit. That's a good chunk of the time "budget" if we think a dit at 30 wpm is 40 milliseconds.
So - looking at the code there are lot's of delay() calls. The DE has electronic TR switching. Have some of these delays been made obsolete by hardware changes to the PA? I just started commenting out the delays until almost all of them are out. RESULTS: The 31.6 milliseconds goes down to 7.3 milliseconds. Seems significant. Similar changes could be made in tr_switch_v2 (I would like to hear some ideas on what the minimum set of differences between de and v2 code really need to be - I could see running them both on the same tr_switch code. I can't test the v2 code).
I have worked CW and FT8 with the trimmed down code, and I'm still on my original finals. Can the RF amplifier folks here talk about the risks involved in streamlining the code?
--
Mike KB2ML
|
There was a commit on 8 July called "Merging the CW keying time lag fix". Did you notice any improvement?
Mike
toggle quoted message
Show quoted text
For the CW operators here ... have you had any problems with the sBitx CW
keyer?
The timing seems off for me when keying at higher speeds, and the TX isn't
quite right even using an external keyer. I took a couple of videos showing
what I mean:
Using an external keyer at 25 wpm, the dits are much more staccato than they
should be and sometimes entirely cut off. The TX is bad enough that the RBN
will not pick up my call when using the external keyer:
|
Mike I believe this is precisely what I have been suggesting from my first post. It is not the CW keyer per say rather the need to turn on the transmitter X ms prior to the first CW character reaches the Transmitter input port (Lead-In Timing) and on the Exit the (Tail Timer) time Y ms after the last CW character prior to shutting off the transmitter and another short time Z ms to create a signal to turn on the receiver.
This technology really goes back a ways in history as the "collective we" have forgotten how spoiled we (collective we) have become with the advent of transistorized radios. Now in the Age of the computer or "Software Defined Radio" all perviously insignificant timing events now have to be coded into the operational software. The physical amount of time may be very short but remember in the Computer Driven World even the smallest amount of dead air time has to be part of the Operational Software Code.
|
Mike
What dev was the July 8th commit to? I don't see it in JJ's timeline.
--
73
??? Bob? KD8CGH
|
VE6LX
Bob Benedict, KD8CGH