|
After letting my zBITX sit unattended in Receive Mode for a while, the main RasPi CPU crashes.? I have never timed it because I'm not just sitting there watching it.? But it seems like it only takes about an hour or so to crash.? I am not able to get a SSH connection to the main CPU at that time.? The display CPU is still running at that time.
?
While the device is warm whenever this occurs, I do not think that it is a thermal issue because if I disconnect and reconnect the power it reboots and runs fine.
?
I have never stopped the sbitx application to see if something else on the RasPi could be causing it.? I have SSH and VNC enabled, but I am not using either of those connections.? I do not have anything else running on the RasPi.? So, I really do not think that it is some other RasPi appllication.?
?
I think that it is probably a sbitx application memory leak.? ?Don't see how something like a character array overflow would occur after just sitting there unattended for that period - nothing is being done on the GUI during that time.
?
This crashing occurred whenever I had version 3.021 installed,? And it is still occurring with version 3.052 installed.
?
If you are running on batteries, the batteries may be depleted before this crash occurs.? You will never see it.? I am using a 7.5vdc power supply.??
?
72,
Jody - K3JZD
?
|
I¡¯m not sure how One tests for this?
Do you write a small program that every five minutes asks for various amounts of space and reports which ones it was able to be given?
And then just watch it? Or does that only report the heap? I don¡¯t know a lot about the different ways Memory is handled
But sounds like you¡¯re definitely onto something that can get fixed!
Gordon?
toggle quoted message
Show quoted text
On May 14, 2025, at 14:47, Jody - K3JZD via groups.io <k3jzd.jody@...> wrote:
? After letting my zBITX sit unattended in Receive Mode for a while, the main RasPi CPU crashes.? I have never timed it because I'm not just sitting there watching it.? But it seems like it only takes about an hour or so to crash.? I am not able to get a SSH connection to the main CPU at that time.? The display CPU is still running at that time.
?
While the device is warm whenever this occurs, I do not think that it is a thermal issue because if I disconnect and reconnect the power it reboots and runs fine.
?
I have never stopped the sbitx application to see if something else on the RasPi could be causing it.? I have SSH and VNC enabled, but I am not using either of those connections.? I do not have anything else running on the RasPi.? So, I really do not think that it is some other RasPi appllication.?
?
I think that it is probably a sbitx application memory leak.? ?Don't see how something like a character array overflow would occur after just sitting there unattended for that period - nothing is being done on the GUI during that time.
?
This crashing occurred whenever I had version 3.021 installed,? And it is still occurring with version 3.052 installed.
?
If you are running on batteries, the batteries may be depleted before this crash occurs.? You will never see it.? I am using a 7.5vdc power supply.??
?
72,
Jody - K3JZD
?
|
My go-to for debugging this sort of thing is valgrind, but that's likely to be really slow when running on the actual hardware (and may have memory issues given the small headroom?).
I've been meaning to ask - have people been compiling this on the device, or does anyone have a cross-compilation environment set up? It's on my list to figure out, but if anyone already has something put together that might speed up development.
On Wed, May 14, 2025 at 1:57?PM Gordon Gibby KX4Z via <docvacuumtubes= [email protected]> wrote:
I¡¯m not sure how One tests for this?
Do you write a small program that every five minutes asks for various amounts of space and reports which ones it was able to be given?
And then just watch it? Or does that only report the heap? I don¡¯t know a lot about the different ways Memory is handled
But sounds like you¡¯re definitely onto something that can get fixed!
Gordon?
? After letting my zBITX sit unattended in Receive Mode for a while, the main RasPi CPU crashes.? I have never timed it because I'm not just sitting there watching it.? But it seems like it only takes about an hour or so to crash.? I am not able to get a SSH connection to the main CPU at that time.? The display CPU is still running at that time.
?
While the device is warm whenever this occurs, I do not think that it is a thermal issue because if I disconnect and reconnect the power it reboots and runs fine.
?
I have never stopped the sbitx application to see if something else on the RasPi could be causing it.? I have SSH and VNC enabled, but I am not using either of those connections.? I do not have anything else running on the RasPi.? So, I really do not think that it is some other RasPi appllication.?
?
I think that it is probably a sbitx application memory leak.? ?Don't see how something like a character array overflow would occur after just sitting there unattended for that period - nothing is being done on the GUI during that time.
?
This crashing occurred whenever I had version 3.021 installed,? And it is still occurring with version 3.052 installed.
?
If you are running on batteries, the batteries may be depleted before this crash occurs.? You will never see it.? I am using a 7.5vdc power supply.??
?
72,
Jody - K3JZD
?
|
I wondered why the zBitx crashed after some time... Makes sense, because the PI Zero 2W would NOT work as a 'normal' internet browsing setup, after a few minutes and some websites past, the memory would be filled 100%.
Good luck!
Martin, PD0ZZ
|
|
I have used htop and top to track memory usage. ?The original 32bit software would have memory usage grow and then reset back to the minimum. ?I did that monitoring, not writing to a file. ?I believe it is possible to pipe the output to a file.?
73
Evan
AC9TU
|
|
Jody, I see something similar, though the sbitx program seems to keep running. After a while (anywhere between 15 minutes and an hour) the tcp connection dies. I had the web interface running and an open ssh session, and the web interface reverted to the login page and the ssh session terminated. Rebooting brought everything back to normal. This has happend a couple of times. Receiving was still OK though.
73 Frank PA3CNO?
After letting my zBITX sit unattended in Receive Mode for a while, the main RasPi CPU crashes.? I have never timed it because I'm not just sitting there watching it.? But it seems like it only takes about an hour or so to crash.? I am not able to get a SSH connection to the main CPU at that time.? The display CPU is still running at that time.
?
While the device is warm whenever this occurs, I do not think that it is a thermal issue because if I disconnect and reconnect the power it reboots and runs fine.
?
I have never stopped the sbitx application to see if something else on the RasPi could be causing it.? I have SSH and VNC enabled, but I am not using either of those connections.? I do not have anything else running on the RasPi.? So, I really do not think that it is some other RasPi appllication.?
?
I think that it is probably a sbitx application memory leak.? ?Don't see how something like a character array overflow would occur after just sitting there unattended for that period - nothing is being done on the GUI during that time.
?
This crashing occurred whenever I had version 3.021 installed,? And it is still occurring with version 3.052 installed.
?
If you are running on batteries, the batteries may be depleted before this crash occurs.? You will never see it.? I am using a 7.5vdc power supply.??
?
72,
Jody - K3JZD
?
|
I have been compiling right on the xBITX device.? I use SSH and Putty to login as? ?pi / hf12345? ?and get a terminal window.? ? Then I do a? ?cd? sbitx.? ?There is a build script there - just execute? ?./build.? ?That will create a new sbitx application in the same subdirectory which auto-starts whenever the zBITX device is powered up.? You can manually shut down the running sbitx application that was auto=started? and run it manually from there with? ./sbitx? ? The second RasPi processor that runs the LCD GUI remains running and it all reconnects whenever manually starting sbitx.?
?
I have never used the zBITX remote web interface feature.? When you use that, It looks like that is a separate web interface task that then connects to the zBITX's sBitx application.? ?If your remote web interface. connection; is being terminated, is is probably the? sbitx? program crashing, which probably causes the the web interface program to revert back to its login page.? ?Just my guess.
?
Finding memory leaks? is difficult.? I do not have any silver bullets for that.? If it is my program, I am better at it because I have ideas about where I might have gotten careless or took shortcuts.? And I always suspect my latest revision(s) .? With someone else's program, I generally trace all of the activity associated with every variable.? One thing I look at very closely is global variables .? And I look for same named local variables in functions..? Some compilers will catch that - some will not.? And simple variable names being reused for different purposes in many different places are suspicious.? (for example, in sbitx_gtk.c,? the variable name? f? is heavily used for many different purposes). ?There are tools to do this time consuming job, but I don't have any of them.
?
Watching available memory diminish in a program like this one that is busy doing many things while in Receive Mode will not help you figure out why.? Probably will need to turn off one of the 'things' that are active and let it run for a few hours to see if? the memory is no longer being diminished and if it no longer crashes.? If that didn't cure it, then move on to stopping the next active 'thing'. and do it again.? One generally needs a good understanding of the program to figure out how to stop just one 'thing' from running.? And a of of time.
?
Forgive me if I ramble on - I tend to think and expand as i type.? Short stories become long stories.
?
72,
Jody - K3JZD
|
What causes a crash??? Typically pointers to zero, buffer overruns, memory leaks, pointers to auto class variables.? Others?
My C skills are very rusty but this function looks suspicious to me as it seems to return a pointer to an auto class.? It is in sbitx_gtk.c
?
static struct font_style * set_style(cairo_t *gfx, int font_entry){
? ? struct font_style *s ?= font_table + font_entry;
? ? ? cairo_set_source_rgb( gfx, s->r, s->g, s->b);
? ? cairo_select_font_face(gfx, s->name, s->type, s->weight);
? ? cairo_set_font_size(gfx, s->height);
? ? return s;
}
|
My sBitx can be left for hour after hour & never crashes. ?So NEW CODE for the ZBitx might be the hunting ground & display code probably changed¡
Gordon kx4z?
toggle quoted message
Show quoted text
On May 14, 2025, at 21:59, Ron Carr via groups.io <rcarr@...> wrote:
? What causes a crash??? Typically pointers to zero, buffer overruns, memory leaks, pointers to auto class variables.? Others?
My C skills are very rusty but this function looks suspicious to me as it seems to return a pointer to an auto class.? It is in sbitx_gtk.c
?
static struct font_style * set_style(cairo_t *gfx, int font_entry){
? ? struct font_style *s ?= font_table + font_entry;
? ? ? cairo_set_source_rgb( gfx, s->r, s->g, s->b);
? ? cairo_select_font_face(gfx, s->name, s->type, s->weight);
? ? cairo_set_font_size(gfx, s->height);
? ? return s;
}
|
Ron : I will have to spend some time with the code snippet that you highlighted - I do not have any experience at all with the gtk library.
?
Gordon : I thought that mine had crashed with version 3.021.? But I was doing so many things working with it then, any of those things that I was doing could have caused my version 3.021 to crash.? ?So, maybe what I am remembering was self-induced.? This is good info though.? Always suspect the last change that you made whenever problems surface is the golden rule.
?
Today I got lucky.? I had my unit running beside me while I was doing some other things.? Mostly it was just sitting there in Receive Mode.? ?But I was sending some Straight Key CW once in a while to make sure that it was still responsive.? ?I had a SSH login.? After about 1.5 hours, my Receiver noise got sporadic.? Sending CW got very choppy - it was totally unusable.? ?My SSH login was sluggish. but still usable.? I ran HTOP.?
?
What I found supported my Memory Leak theory.? See the attached.? ? sbitx runs from the start.sh script.? ?I highlighted that line.? 73.8% of the memory consumed.? ?Swap Space maxed out.? Total Memory very close to being maxed out.? As the system choked, my SSH connection became super sluggish.? ?I got HTOP to run again, but it took about 15 minutes to come up and rarely updated.? ?Memory consumption looked pretty much the same - I guess the RasPi OS keeps some memory in reserve.? ?So I guess the zBITX RasPi is not totally crashing - it is just becoming very unresponsive and from the outside it looks like it crashed.?
?
So, I guess it is time to do Diffs on all of the changes made in the files that were changed last month to create version 3.052.? Mostly it was adding the input pin IRQs and changing the program control structure to give manual CW priority.? But some changes were also made to support some problems that had been reported whenever using FT8 and other digital modes.?
?
While I have other stuff on my plate, this problem seems to keep grabbing my attention.? So. I will try to fit in some more time to look at it.? In the mean time, it you have version 3.052 installed, just power down / power up your zBITX every 30 minutes or so.
?
72,
Jody - K3JZD? ??
?
?
|
Jody,
do you have an image of ver 3.021 that you can share?
I will like to try your sbitx_gtk.c file.?
|
... I admire your tenacious perseverance.
My zBitx will remain off until there is a definitive, functioning
image.
I don't understand anything about programming...
?
73/55 , Jens / HB9JOI
?
+++
?
toggle quoted message
Show quoted text
From: Jody - K3JZD via groups.io
Sent: Thursday, May 15, 2025 5:56 PM
Subject: Re: [BITX20] zBITX Crashes - Suspect Memory Leak
#zbitx
?
Ron : I will have to spend some time with the code snippet that you
highlighted - I do not have any experience at all with the gtk library.
?
Gordon : I thought that mine had crashed with version 3.021.? But I
was doing so many things working with it then, any of those things that I was
doing could have caused my version 3.021 to crash.?? So, maybe what I
am remembering was self-induced.? This is good info though.? Always
suspect the last change that you made whenever problems surface is the golden
rule.
?
Today I got lucky.? I had my unit running beside me while I was doing
some other things.? Mostly it was just sitting there in Receive
Mode.?? But I was sending some Straight Key CW once in a while to make
sure that it was still responsive.?? I had a SSH login.? After
about 1.5 hours, my Receiver noise got sporadic.? Sending CW got very
choppy - it was totally unusable.?? My SSH login was sluggish. but
still usable.? I ran HTOP.
?
What I found supported my Memory Leak theory.? See the
attached.??? sbitx runs from the start.sh script.?? I
highlighted that line.? 73.8% of the memory consumed.?? Swap
Space maxed out.? Total Memory very close to being maxed out.? As the
system choked, my SSH connection became super sluggish.?? I got HTOP
to run again, but it took about 15 minutes to come up and rarely
updated.?? Memory consumption looked pretty much the same - I guess
the RasPi OS keeps some memory in reserve.?? So I guess the zBITX
RasPi is not totally crashing - it is just becoming very unresponsive and from
the outside it looks like it crashed.
?
So, I guess it is time to do Diffs on all of the changes made in the files
that were changed last month to create version 3.052.? Mostly it was adding
the input pin IRQs and changing the program control structure to give manual CW
priority.? But some changes were also made to support some problems that
had been reported whenever using FT8 and other digital modes.
?
While I have other stuff on my plate, this problem seems to keep grabbing
my attention.? So. I will try to fit in some more time to look at it.?
In the mean time, it you have version 3.052 installed, just power down / power
up your zBITX every 30 minutes or so.
?
72,
Jody - K3JZD???
?
?
|
OK - I have it figured out.? ?It was not a traditional "Memory Leak".? However it was a 'Memory Eater" (a subtle difference)? ?It only ate Memory during sending CW.? It was not a CPU resource issue - there is plenty of CPU to run manual CW with the zBITX ( I can't speak for any other mode ).
?
I had been saying that I have been running my zBITX in Receive Mode.? If I had done exactly that, then mine would have run for hours and hours, much as Gordon's zBITX does.? ?In reality, I have been sending a little CW from time to time, just to check and see if it is still healthy and responsive.? So, for me, it has been maybe 90-95% listening and 5-10% sending CW.
?
Whenever you power up your zBITX, a script called start.sh automatically runs.? ?I'm no linux guru, so don't shoot me if I do not describe this properly.? As I understand it, that script then starts up the sBitx program in a new shell.? Anything that the sBitx program writes out to the console (stdio) is written to this new shell.? ?What was happening was that a program (? i2cbb.c? ) was madly writing error messages to this shell.? But it only did that whenever a CW key was being pressed.? ?So whenever sending CW, this shell kept growing and growing until it eventually ate all of the memory.? The sBitx program did not 'crash', it just eventually became totally unresponsive.? In fact the entire Pi Zero became so sluggish that it took it 15 minutes to produce a directory listing.
?
This ic2bb.c program was writing out messages when (1) it tried to get control of the I2C bus, but could not because the I2C bus was already busy, and (2) whenever it got so backed up with the rush of incoming requests for the I2C bus that it aborted and reconnected.? This? ic2bb.c? program was not changed during the upgrade from version 3.021 to 3.052.? But in version 3.052 it is being called 'a whole lot more'.?
?
I have made an initial fix.? I have tested my initial fix by running my zBITX for the last 4 hours, while periodically sending some CW, and watching the memory usage.? ?What was my initial fix?? ?I commented out all of the messages that I2cbb.c was writing out to this shell, causing it to grow to an astronomical size.
?
So why now in version 3.052 and not in version 3.021?? The root cause was adding in the Interrupts (IRQs) for the manual CW Mode.? ?I see two things that caused the? i2Cbb.c functions to become overwhelmed :? The new IRQs are now being generated on 'Key Contact Closed' and 'Key Contact Open'.? Only Key Contact Closed is needed.? ?And the IRQ processing function is is not debouncing the Key Contact Closed (or Key Contact Opened).? ?What you may think is one Contact Closure generating one Interrupt, is really one Contact Closure generating tens to hundreds of Interrupts. Even though I have inhibited the messages that were causing the memory eating problem, this massive influx of unnecessary interrupts is still occurring and is still overwhelming the functions handling the I2C bus, which is causing unnecessary instability in the device.? ?
?
So,? I will be going back into the version 3.052 sbitx_gtk.c, and making these IRC related changes.? Once I have finished that and have tested it, I will post my new i2cbb.c program and my new sbitx_gtk.c program.
?
If you are inclined to do a quick fix for your i2cbb.c program yourself, just go into it and comment out every? printf()? that is in there.? Then do a? ./build,? power down and power back up.
?
72,
Jody - K3JZD? ? ??
?
?
??
|
Excellent, Jody!! ?This is incredibly good detective work.
A correction, I don¡¯t have a Z bit X, what I have is an SBitx and it seems thoroughly stable
toggle quoted message
Show quoted text
On May 15, 2025, at 20:27, Jody - K3JZD via groups.io <k3jzd.jody@...> wrote:
? OK - I have it figured out.? ?It was not a traditional "Memory Leak".? However it was a 'Memory Eater" (a subtle difference)? ?It only ate Memory during sending CW.? It was not a CPU resource issue - there is plenty of CPU to run manual CW with the zBITX ( I can't speak for any other mode ).
?
I had been saying that I have been running my zBITX in Receive Mode.? If I had done exactly that, then mine would have run for hours and hours, much as Gordon's zBITX does.? ?In reality, I have been sending a little CW from time to time, just to check and see if it is still healthy and responsive.? So, for me, it has been maybe 90-95% listening and 5-10% sending CW.
?
Whenever you power up your zBITX, a script called start.sh automatically runs.? ?I'm no linux guru, so don't shoot me if I do not describe this properly.? As I understand it, that script then starts up the sBitx program in a new shell.? Anything that the sBitx program writes out to the console (stdio) is written to this new shell.? ?What was happening was that a program (? i2cbb.c? ) was madly writing error messages to this shell.? But it only did that whenever a CW key was being pressed.? ?So whenever sending CW, this shell kept growing and growing until it eventually ate all of the memory.? The sBitx program did not 'crash', it just eventually became totally unresponsive.? In fact the entire Pi Zero became so sluggish that it took it 15 minutes to produce a directory listing.
?
This ic2bb.c program was writing out messages when (1) it tried to get control of the I2C bus, but could not because the I2C bus was already busy, and (2) whenever it got so backed up with the rush of incoming requests for the I2C bus that it aborted and reconnected.? This? ic2bb.c? program was not changed during the upgrade from version 3.021 to 3.052.? But in version 3.052 it is being called 'a whole lot more'.?
?
I have made an initial fix.? I have tested my initial fix by running my zBITX for the last 4 hours, while periodically sending some CW, and watching the memory usage.? ?What was my initial fix?? ?I commented out all of the messages that I2cbb.c was writing out to this shell, causing it to grow to an astronomical size.
?
So why now in version 3.052 and not in version 3.021?? The root cause was adding in the Interrupts (IRQs) for the manual CW Mode.? ?I see two things that caused the? i2Cbb.c functions to become overwhelmed :? The new IRQs are now being generated on 'Key Contact Closed' and 'Key Contact Open'.? Only Key Contact Closed is needed.? ?And the IRQ processing function is is not debouncing the Key Contact Closed (or Key Contact Opened).? ?What you may think is one Contact Closure generating one Interrupt, is really one Contact Closure generating tens to hundreds of Interrupts. Even though I have inhibited the messages that were causing the memory eating problem, this massive influx of unnecessary interrupts is still occurring and is still overwhelming the functions handling the I2C bus, which is causing unnecessary instability in the device.? ?
?
So,? I will be going back into the version 3.052 sbitx_gtk.c, and making these IRC related changes.? Once I have finished that and have tested it, I will post my new i2cbb.c program and my new sbitx_gtk.c program.
?
If you are inclined to do a quick fix for your i2cbb.c program yourself, just go into it and comment out every? printf()? that is in there.? Then do a? ./build,? power down and power back up.
?
72,
Jody - K3JZD? ? ??
?
?
??
|
?
?
Great work, Jody. A quick fix may be to redirect the
Output to /dev/null - see the link
?
https://www.ubuntumint.com/redirect-output-in-linux/
|
On Thu, May 15, 2025 at 04:56 PM, miguel medina wrote:
Jody,
do you have an image of ver 3.021 that you can share?
I will like to try your sbitx_gtk.c file.?
Miguel,
?
My version 3.021 sbitx_gtk.c will not run with your version 3.052 system.
?
I will be posting one for version 3.052 based on my latest discovery.?
?
I identifies a quick fix for version 3.052.
?
72,
Jody - K3JZD? ? ?
|
thanks Jody,
I'll wait for your fix, but I was asking for a copy of 3.021 on an iso or img file format to test your sbitx_gtk.c file.
Idk if theres a ver 3.021 on the official github and if theres 1, idk how to compile to a fresh raspian OS.?
72 de KP4MI?
|
Note - This only applies to using Manual CW (Straight Key Mode or Iambic Mode) with sBitx Version 3.052.?? This recap includes some previously shared information.
Goal
Make my zBITX with sBitx version 3.052 firmware usable for Manual Straight Key CW Mode and Manual Iambic Paddle CW Mode.? At any speed.
Problem
A script starts the underlying sBitx program in a new virtual shell.? Anything that the version 3.052 sBitx program writes out to the console (stdio) is written to this new virtual shell.?Whenever using Manual CW, programs (mostly i2cbb.c) are madly writing error messages to this virtual shell on every Key Down event and every Key Up event.? This virtual shell keeps growing and growing until it eventually consumes all available real memory and all swap space.? Whenever that happens, the sBitx program becomes totally unresponsive.? From the outside, it looks like the zBITX has crashed.
Cause
The main RasPi Zero computer running the sBitx program talks to the RasPi Pico computer running the zBITX¡¯s LCD Display using the I2C protocol.
Due to the way that Manual CW is now being handled in sBitx version 3.052, the ic2bb.c program that is managing I2C communications is now writing out error messages whenever (1) it wants to get control of the I2C bus, but cannot because the I2C bus is already busy, and (2) it gets so backed up with the volume of incoming requests for the I2C bus that it aborts and reconnects. ?The sBitx version 3.052 sbitx_gtk.c program is also writing out I2C related status messages.?
So why now in version 3.052 and not in version 3.021?? The ic2bb.c program was not changed.? The root cause was adding in the Interrupts (IRQs) for the manual CW Mode in version 3.052.? ?I see two things that cause the i2Cbb.c functions to become overwhelmed: ?These IRQs are now being generated on both a 'Key Contact Closed' and 'Key Contact Open' (the downstream CW processing requires both events). And the IRQ processing function is not debouncing the Key Contact Closed event or the Key Contact Opened event.? ?What you may think is one Contact Closure generating one Interrupt, is really one Contact Closure generating tens of Interrupts.
?Solution
A ¡®Partial Solution¡¯ was achieved by modifying the i2cbb.c and the sbitx_gtk.c files to comment out all of these I2C related Debug and Status Messages that were being written out.?? This eliminated the ever-growing virtual console problem that was bringing down the zBITX whenever using Manual CW.
The ¡®Real Solution¡¯ is to debounce the 'Key Contact Closed' and 'Key Contact Open' inputs to minimize the large number of redundant messages that are going to the i2cbb.c I2C handler. ?My ¡®Partial Solution¡¯ only gets rid of the subsequent Error Messages and Status Messages.? The i2cbb.c program is still being bombarded with a large number of redundant messages, and it still has the same resource contention, connection aborts, and reconnections. ?While the zBITX device continues to run while this is happening, you will see jitter and delayed information being displayed on the LCD display.
Result
I had no problems implementing the ¡®Partial Solution¡¯.? The files needed to do that for sBitx version 3.052 are available below.
However, I have thrown in the towel on implementing the ¡®Real Solution¡¯.? Over the last several days, I have tried many different approaches to debounce both the 'Key Contact Closed' and the 'Key Contact Open' events.? RasPi OS interrupt handlers, microsecond timers, and fprint() debug messages don¡¯t seem to play nice with each other.? Nothing that I tried would catch and debounce a 'Key Contact Open' event right after a debounced 'Key Contact Closed' event.?? Not saying it cannot be done ¨C just saying I am tired of spending my time seeking a way to achieve this. ??Sorry.
Going Forward
You have a few choices:
If you are using Manual CW (Straight Key or Iambic) with your sBitx version 3.052 system, and you are willing to remove power and reapply power every 30 minutes or so, you may continue on with what you have.
If you are using Manual CW (Straight Key or Iambic) with your sBitx version 3.052 system, and you are able to install my revised files, then you can use my ¡®Partial Solution¡¯.? Save your existing /home/pi/sbitx/ic2bb.c and /home/pi/sbitx/sbitx_gtk.c files to a safe place.? Put my revised i2cbb.c and sbitx_gtk,c files into you /home/pi/sbitx subdirectory.? Then while in /home/pi/sbitx, ?execute ?./build ???Then remove power and reapply power.? As far as I know, this will let you use Manual CW, at any speed, for many hours.
If you are using Manual CW (Straight Key or Iambic) with your sBitx version 3.052 system, you may wait for Ahhan to provide a new zBITX firmware release that fixes this problem of Manual CW operation consuming all available memory and all swap memory.
Caveat
This is not an official zBITX release.? I am not setup for using SSB, AM, FT8, or any other mode with my zBITX.? ?While I do not see where my changes to this i2cbb.c file and this sbitx_gtk.c file to make Manual CW usable will have any impact on these other modes, I have not tested any other mode.
72,
Jody ¨C K3JZD
|
Jody,
the "partial" works good? down to 50ms. (iambic)
thanks so much.
iambic b , no joy
|
Miguel,
?
That is great.? ?The CPU utilization went down with my changes.? And swap memory is not being used at all.? Maybe that is contributing to what sounds like nearly full QSK.
?
Iambic B has more strict timing requirements.? The system is still busy with some unnecessary stuff, and probably cannot handle that more strict timing .? I think it probably needs to be restructured as a state machine, with dedicated states for each Mode .? And with Iambic, Iambic B, and Straight Key Mode each being a separate state.? And when transmitting, each Mode would have the full attention of the CPU.? What is there now looks like a lot of 'add ons' were accommodated by blending them in.? ? ? ?
?
With a Straight Key, where the CW timing is not as predictable as iambic, I keep my Semi-QSK Delay at 500ms,
?
72,
Jody - K3JZD?
?
?
|
Jens/HB9JOI