¿ªÔÆÌåÓý


Re: Z bitx poor sensitivity

 

Just got my zbitx yesterday and have begun playing with it. Made a bunch of FT-8 QSO's right away on 20m last night with 2w out to a vertical, so that was interesting and pleasantly surprising.
Did some receiver testing today.
The factory Test Report card that came with the xcvr indicates a sensitivity of -105dbm.
I attached my S9 signal generator set at -103dbm (about S4) and it could not be heard on any band, even with the IF gain at 100.
With the generator set at S9 (-73dbm) it could be plainly heard on all bands with the IF gain set at 50, however, the audio heard was not
perceived to be an S9 signal. Turning the IF up to about 65 helped a lot, but the radio seems to lack audio gain as well.
The S meter on the zbitx did read approximately S9 at this setting.
?
This lack of sensitivity surprises me greatly - even my super cheap and dated technology SoftRocks easily hear better than that, as does a simple analog rig like a QCX.
Something does not seem right to me. I expected better.
The concept of this radio is really great IMO, and obviously a lot of work has already gone into its implementation, so hats off to the developer, however,
this receiver performance seems to be a serious issue to me, even at this price point.


Re: sBitx original handheld microphone upgrade #sBitxDevel #sbitx_v2 #sBITX_v3

 

I talked about this, but I didn't post a picture, a picture always says more, so I'll post it now:
?
?
?
--
Gyula HA3HZ


sBitx original handheld microphone upgrade #sBitxDevel #sbitx_v2 #sBITX_v3

 

Today I made a conversion of the original handheld microphone purchased with sbitx, similar to the 'Meeting MIC', which I documented in the attached file.
If I missed something, please feel free to ask, I will answer when I can.
--
Gyula HA3HZ
?
?


Re: zBitx Power Supply

 

Hi Yvon!?
Unfortunately not! It makes a lot of noise on the amateur band. You need to use a battery or a better quality power supply. Sorry.

Yvon AE7YD via <Yvon=[email protected]> ezt ¨ªrta (id?pont: 2025. m¨¢j. 16., P 18:23):

Laci,

did you succeed to modify your power supply?
?
73, Yvon


Re: zBitx Power Supply

 

Laci,

did you succeed to modify your power supply?
?
73, Yvon


Re: ZBitx Shutdown Function #zbitx

 

¿ªÔÆÌåÓý

I just use 'sudo shutdown' from the terminal.

Assume that properly shuts off the Pi-Zero.

Now, how do you shut off the Pico?

Don in Austin,? N5CID



===============================================

On 5/4/2025 6:49 AM, Karl Heinz Kremer, K5KHK wrote:

After working with Unix/Linux systems for a lifetime, i know that bad stuff will happen if you just disconnect the power on a regular basis. I still feel a twitch in my fingers if I don¡¯t run sync; sync; sync; before a shutdown or halt command ;)

?

I¡¯ve forked Farhan¡¯s code and added a button on the UI to shut down the Pi Zero:

The "Shutdown" function is behind the "Menu" button. After selecting it and confirming, wait until the LED on the Pi Zero (which you can see through the covered USB connector) stop to blink. I moved the confirmation button a bit up so that it¡¯s harder to fat finger the shutdown with an unintentional double tap on the shutdown button.

?

de Karl Heinz - K5KHK



Re: Update On Shipping Delays from HF Signals

 

Got my ship notice will be here next week.
?
?
Jim
KE0VVU


How to place an order for Zbitx from India?

 



Re: Update On Shipping Delays from HF Signals

 

Wooohooo....got my ship notice (order #3941).? Be here next week
--
"POWER, WE DONT NEED NO STINKIN' POWER" - Every KX2 Owner
Always respect the air waves,
73 de KI7PBR, Gary


Re: Order # 3869 April 2

 

ORDER # 3930 - Status changed to packed and ready to go this morning.
?
Shane
KD7ZYN


Re: Order # 3869 April 2

 

Order 3929, placed April 3rd, just shipped
?
Lincoln
N9IN


Re: zbitx, compiler optimizations #zbitx

 

¿ªÔÆÌåÓý


On May 16, 2025, at 02:46, Jody - K3JZD via groups.io <k3jzd.jody@...> wrote:

Check my thread about a zBITX Memory Leak.? ?I concluded that the i2cbb.c program in sBitx version 3.052 being used in the xBITX was being swamped with send requests, resulting in a huge number of bus contentions, disconnects, and reconnects.? Odds that has contributed to the large time spent in what has been identified here as 'ic2_delay'.? ? I also identified the root cause of the huge number of send requests that are swamping the ic2 bus handling functions.? ?
?
I also think that the RasPi Zero used in the zBITX has enough horsepower to do the job.? Back when I was doing sales support for custom computerized control systems, and potential customer had spec'ed that they wanted the CPU usage to be 75% maximum, I always asked what they will do with the other 25%.? Sure, we could limit it to that, but why slow down the system for an artificial constraint.

OK, I guess I should read that thread.

I think the i2c communication must be excessive in general. ?It makes audible noise (everybody¡¯s complaining about ¡°chugging"), but I¡¯ve also found that when I have a USB ethernet adapter attached, communication there makes noise too. ?(Of course, the electrical design could be better, but I don¡¯t yet know how to pinpoint why that is happening.). (To me it sometimes sounds like hard drive seeking noises. ?;-) ?One obvious solution to do less communication is using notifications/signals: each field should notify when it has changed (only when the stored value really changed), and that should trigger the updates: those that go to the GTK UI, i2c UI update commands, and/or some network protocols. ?In Qt one uses signals: ?


But I think gtk/glib has something like that too. ?? leads to?? : yep that looks like what we need.

For 9p I just tried an explicit callback first (and I¡¯m not calling it from enough places yet):

void notify_field_changed(const char *field_id, const char *old, const char *newval);

The implementation of this function could take care of notifying the various UIs and network protocols. ?But probably it should rather emit a signal: each ¡°client¡± should subscribe for notifications. ??is something that just about everybody has to do at some point...


Sbitx/zbitx is doing too much polling and timer-based refresh instead, and that is creating a lot of inefficiency. ?Especially with the excessive string comparison and conversion going on.

The network protocol is important to me because I want to decouple the GUI from the radio daemon anyway. ?This daemon will eventually need to avoid using gtk/gdk at all: pure C for the core functionality. ?(Why does zbitx have to run X11 and a GTK UI under the condition that nobody is looking at it? ?Sometimes HDMI is connected, sometimes not. ?We only have 512MB, and startup time is noticeable too.) ?9p is gonna be great for that, eventually, probably. ?I have a working client on Plan 9 now, just rather buggy and incomplete compared to the GTK one. ?I just got a waterfall added to it, without taking much bandwidth (because I only send the latest line of samples at a time; too bad it¡¯s only about 440 actual pixels, despite the memory allocated to hold 1024 * history size). And later I will do a Qt client with the same protocol, for all the other platforms. ?That one can have fancier features.

sbitx-plan9.png


Re: zBITX Crashes - Suspect Memory Leak #zbitx

 

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?


Re: You don't hear it from me

 

Maybe Hans can check the output from the zBitx he won on a spectrum analyzer? :-)
73, Ron, n6ywu


Re: zBitx +-2 MHz transmit spurs?

 

Has any more work been done on finding a way to reduce or eliminate the transmit spurs that some people have found generated by their zBitx? ? The spurs appears to be the intermodulation or mixing of two of the Si5351 clock generator outputs, and can be a few MHz apart, thus not eliminated by the output filters. ?I don't want to connect my zBitx to an antenna if it's generating non-compliant levels of interference well outside the ham bands.
73, Ron, n6ywu


You don't hear it from me

 

Hi
QRP Labs Hans G0UPL won a zBITx from Farhan yesterday at FDIM :) :) :)
It was a random giveaway, random number generator picked Hans's number :) :) :)

73 muhsin TA1MHS


Re: zBITX Crashes - Suspect Memory Leak #zbitx

 

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? ? ?


Re: zbitx, compiler optimizations #zbitx

 

Check my thread about a zBITX Memory Leak.? ?I concluded that the i2cbb.c program in sBitx version 3.052 being used in the xBITX was being swamped with send requests, resulting in a huge number of bus contentions, disconnects, and reconnects.? Odds that has contributed to the large time spent in what has been identified here as 'ic2_delay'.? ? I also identified the root cause of the huge number of send requests that are swamping the ic2 bus handling functions.? ?
?
I also think that the RasPi Zero used in the zBITX has enough horsepower to do the job.? Back when I was doing sales support for custom computerized control systems, and potential customer had spec'ed that they wanted the CPU usage to be 75% maximum, I always asked what they will do with the other 25%.? Sure, we could limit it to that, but why slow down the system for an artificial constraint.
?
Just my opinion.
?
72,
Jody - K3JZD


Re: zBITX Crashes - Suspect Memory Leak #zbitx

 

?
?
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/


Re: zBITX Crashes - Suspect Memory Leak #zbitx

 

¿ªÔÆÌåÓý

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


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? ? ??
?
?
??