OK!!? ?I have preliminary results to report.
?
First, the day started off badly.? ?While working to get going for morning CW practice listening to high speed ops on 80 meters, I got the amplifier going and didn't retune the little auto-tuner between the sBitx & the SB-200 amp.? ?The Sbitx was only at 68% drive (enough to drive the SB-200 to nearly 200 watts, about as much as I dare put into my homebrew 49:1 EFHW balun.)? ?I started to send just a very short identification --- and BAM! the sBitx went DARK.? ? A current meter that hadn't been working very well suddenly showed LOTS of current from the DC power supply (ghosts?) -- and the little DC power supply went into current limiting.? ?Quick, turn off sBitx.? ? Turn back on -- immediate replay of Bad Things -- power goes up, power goes DOWN, something is shorting out the power supply......
?
After getting over the emotions.....somehow I had to have shorted out one of the IRFZ24N's.? ?I have worked with? THREE sBitx's and done all kind of fool things, and NEVER blew out a power amp MOSFET!? ?So this was very, very surprising, when I had used nearly the same setup just a few days before.? ?
?
Later in the day, more composed, I managed to extricate the sBitx from my plywood go-box and the zillion plugs that are normally connected...got cracked open, looked over all the wiring and circuitry that I spent MONTHS diagnosing a shorted diode in the diode-switching systems, a bad MOSFET 7002? and such (MONTHS of work)....got the heatsink back off; my AlN insulators looked fine, but I failed to carefully check the tension on the bar -- but at least the first screw was indeed tight.? ?With some trial and error I found the IRFZ24N that was indeed shorted, and the other one looked fine, so for the moment I left it in there, got the entire thing back together and now it receives again.? ?Drive level set to 1%, can key CW with no output and no damage, so was able then to work with your code.
?
?
Managed after re-learning a bunch of stuff, to insert your very elegant code, recompiles and ran it -- runs.
?
Testing:? ?(this is 32-bit code, my "flatresponse version" from late in 2024
?
1)? Bencher paddle into Sbitx in "Iambic" mode -- seems to key perfectly, very responsive? ? ?The other day I had the feeling it just wasn't timing right and I made lots of errors in sending CW....but this time it seems very responsive at 21wpm internal electronic keying, and I'm not making errors for a change.
?
2)? Bencher paddle into "lil Bugger" ancient transistor/integrated circuit keyer (no longer on the market) -- with sBitx set to "straight key mode" and the "lil Bugger" doing all the electronic wizardry.? ?This keyer COULD NOT PREVIOUSLY SEND GOOD CODE WITH THE SBITX -- IT JUST ACTED LIKE IT HAD BAD LENGTH CODE ELEMENTS -- I THOUGHT IT WAS NOT PROPERLY SHORTING OUT THE SBITX INPUTS OR SOMETHING AND HAD PLANS TO REBUILD THE OUTPUT CIRCUITRY --? ?Now, it is sending GREAT CODE!? ?The sBitx is now responding quite well to the Lil Bugger's code.? ?This suggests your fix is a huge improvement to the Straight Key input.
?
3)? Switched to a homebrew Arduino emulator of a WINKEYER (K3NG code) that our group has laid out boards and built.? ?Bencher paddle into Arduino emulator, output into "straight key" mode of sBitx.? ? ?This is a confirmatory test of the striaght key input -- I sent several sentences and the response of the sBitx was snappy and correct!? ??
?
?
I have not tested the remaining impacts of the change; will have to watch it for a while.? ?Have not yet made the changes you suggest in the T/R code.? This is ONLY the addition to sbitx_gtk.c? you suggested.
?
// every 20 ticks call modem_poll to see if any modes need work done
if (ticks % 20 == 0)
modem_poll(mode_id(get_field("r1:mode")->value));
else {
// calling modem_poll every 20 ticks isn't enough to keep up with a fast
// straight key, so now we go on _every_ tick in MODE_CW or MODE_CWR
if ((mode_id(get_field("r1:mode")->value)) == MODE_CW ||
(mode_id(get_field("r1:mode")->value)) == MODE_CWR)
modem_poll(mode_id(get_field("r1:mode")->value));
}
This simple change seemingly gives a 20 x increase in polling rate for cw only. [added code is BOLDED]
?
Great going, Mike!!! This little part right here so far looks like a big win. It can't fix the non-real-time behavior of Linux....but it is fixing things that were much more of bother to a 20-25 wpm code operator. Based on the change, I would suspect it works past 30 wpm, making this a far far better CW rig already.
?
Next I'll get around to looking at the T/R delays and your suggestions there.
?
THANKS!!!!!
?
Gordon KX4Z
?
?
?
|
I intend to repackage one of them. ?I have plenty of pi’s here and don’t need another one? even if I only save a few bucks. Shipping a bare unpopulated board in an envelope would be reasonable on cost. ?This is the exact reason I want a board only with no pi no screen and no case. ?Even if it’s just a bare unpopulated board I want to add my own case and possibly just a pi4 or 5.
?
Ryan
kk6dzb
|
I'm not sure what a board only kit would look like, omitting the display and RPi 2 Zero W might cut the cost $30, and the case maybe another few dollars, but you're still looking at expensive shipping and paypal fees. You still need to add an RPi, erasing nearly half the savings.
As I recall, the sBitx came in a few versions because RPi boards were scarce and selling at above retail price.
I don't know that the volume is there to justify two versions of the radio - people that want to "re-package" the zBitx would likely be better off buying a finished zBitx and then removing it from the case.
Just my opinion, but since you asked here, not asking HFSIGNALS directly, I assume you also were interested in list members thoughts on it...
toggle quoted message
Show quoted text
On Jan 1, 2025, at 12:29, Ryan Wesolowski via groups.io <cosmo1stgen@...> wrote:
? I got myself on the list for the zbitx the day they came out. ?I also own a modified sbitx v3. ?At some point will the zbitx board be available on its own in either populated or unpopulated form?
?
Ryan
kk6dzb
|
Re: sBitX V3 Microphone input
You can find the circuit diagram on github in the sbitx/src/docs folder. :
You need to measure 3.3V at the ptt point, which is connected to the RPi input.
If you have problems with the microphone, you can find a solution on the , many people have implemented it and replaced the microphone insert.
--
Gyula HA3HZ
|
Gord:
I for one appreciate you frank observations. bringing to light the almost ancient Analog transceiver is a god analogy.
I could go further back to my Johnson Valiant with the HQ-170 Hammerlund Receiver with solid state TR Switching it was in a class all its own. However as you pint out the SBitX receiver out shines them all. The SBitX receiver while inexpensive the software makes it perform almost on par with the Elecraft and Flex receivers. This says a lot. However back to the objective.
How to improve the CW Break-In timing without breaking the radio. Personally I think the programmers are doing a very good job given they are some what constrained by the LINUX operating system. BUT let me say in their defence the advances they make are repeatable in software for anyone to use. This CW turnover time interface is not as simple as turning on and off a switch. The Software control of the SBitX radio is the life blood of the radio system. What is required is a software cardiac programmer to adjust the SBitX pace maker so to speak so the life blood flows to all the capillaries (smallest radio control without causing a bottle neck in the flow of the software blood some where else. I have followed the development of the SBitX Since Ashhar demonstrated it at Dayton. his down to earth approach has as a result more people working toward a common goal for the average Amateur Radio Operator. the vast majority of us do no know how to program our own PVR for TV recordings yet we at time may say things or perhaps only a choice os words hurt the development. I for one am still saving my pennies so I can afford even the SBitX Board so I can become an active member of this elite group. Thanks for Listening Everyone. Dave VE6LX
|
Re: S/N 0994 receiver internal noise
W9BLW, thanks for sharing your experience. I implemented this idea that I shared in message ? #114315? regarding a program error. The idea came from this topic and it was only a matter of time before I implemented it.
I am satisfied with the result and I recommend it to others.
--
Gyula HA3HZ
|
Re: sBitX V3 Microphone input
When I ground it, nothing happens.... maybe there's an error on the circuit board. I'll check the resistors.
It's a brand new V3 board, btw... so not homebrew.
|
Re: S/N 0994 receiver internal noise
wanted to add some comments as i trouble shoot this same issue before i was a part of this IO group.
I had this exact issue and it was VERY bad, huge birdies on the waterfall and very high level of noise at the target frequency.
i noticed the major noise ( for my sbitx V3 at least) was from the flat display ribbon getting close to the radio board. while the radio was on i could move it closer or further away and recreate the issue. if i gently formed it (bent it) away from the radio board the noise dropped of considerably.? i re-organized all of the cables to "encourage" the display ribbon to stay away from the radio board.?
but the but big improvement came when i added aluminum tape to the display ribbon to act as a shield. same tape that is used for shielding on guitars (pretty much the same as the aluminum foil tape for duct work) and covered the aluminum tape with electrical tape so it can not short anything. I was concerned this could cause some capacitance on the ribbon and thus display issues but , no,? no issues to be found.?
Wow what a difference.? i can crank the IF to 100 without getting the noise anymore.??
after reading the comments form this thread i am going to open it back up and add the solutions you have found as well, thank you for sharing all your findings.?
hope this helps someone, W9BLW
|
live reading of incoming voltage
#sBitx
Hi Group,
I want to add an ADC chip to measure incoming voltage, could easily do this over I2C or SPI.?
Is there a document showing what pins on the RPI are being used and for what??
We should even be able to measure individual cells if your battery has a balance plug.? My plan is to run a service in the background that reads and smooths the ADC then pushes the info to desktop top bar "panel plugin"
|
Re: Operating FT8 from a different country
#sBITX_v3
Just a quick note. ?If you haven’t already try switching to the latest 64bit img of sbitx available on jj’s git hub. ?It has wsjtx “improved” installed with an alternative ui for smaller screens. ?You may be able to use it directly on the sbitx without the external monitor. ?
?
read the install wiki and backup your old settings. ?I purchased a 128gb sd card from Amazon and put the old factory one aside just incase. ?But at this point I will never go back?.
?
Ryan
KK6DZB
|
I got myself on the list for the zbitx the day they came out. ?I also own a modified sbitx v3. ?At some point will the zbitx board be available on its own in either populated or unpopulated form?
?
Ryan
kk6dzb
|
I run SDC on Windows and as much as it is really impressive, I wouldn't be tempted in the slightest to try and get it running on the sBitx.??
?
If you haven't already I'd take a look at Fldigi, it can decode multiple CW signals within the audio bandwidth and can perform operator lookups and logging from the decodes.
?
73? Chris M0KNF
|
Re: Operating FT8 from a different country
#sBITX_v3
Februrary is fine. I can live with it till then.?
?
Hooking up a large monitor defeats the purpose of having a portable HF rig with a Pi in it.
?
Thank you HF Signal folks.
|
Re: zBitx orders are closed
Ashhar, that’s a lovely problem!!
and a reflection of your commitment degree!!
?
happy new year!!?
|
Re: zBitx orders are closed
Happy New Year to everyone
On Wed, Jan 1, 2025 at 6:01?AM Ashhar Farhan via <farhanbox= [email protected]> wrote: We have closed the zBitx orders. Frankly, we weren't prepared for the love we got for this little radio. Personally. I was expecting to do a run of 100 for those who have been asking for it (self included). Now, the order list has run into hundreds, and we are sorry to have stopped taking the orders now. We will reopen this as soon as we have a handle on adding this third product into our line up. Thanks all, I will post? few videos in the coming days and weeks about operating the zbitx.? Happy New year to all!!
|
We have closed the zBitx orders. Frankly, we weren't prepared for the love we got for this little radio. Personally. I was expecting to do a run of 100 for those who have been asking for it (self included). Now, the order list has run into hundreds, and we are sorry to have stopped taking the orders now. We will reopen this as soon as we have a handle on adding this third product into our line up. Thanks all, I will post? few videos in the coming days and weeks about operating the zbitx.? Happy New year to all!!
|
Thanks!? ?I may be able to try it also. Gordon KX4Z
On Tue, Dec 31, 2024 at 4:54?PM Mike Johnshoy via <mike.johnshoy= [email protected]> wrote: On Tue, Dec 31, 2024 at 03:55 PM, Gordon Gibby KX4Z wrote:
> Mike, thank you for the note. Can I get you to confirm that you have actually
> tested this much faster polling technique for CW and it did not foul up
> anything else?
>
Gordon, I think these changes should work on the 32 bit baseline (is that what you are running?) As for testing? - I only run cw and the occasional FT8, on an early sbitx DE running v4.2 (64 bit). No foul-ups have been noticed.? Several users switched to the kb2ml branch and tested it on 64 bit baseline with no ill effect. Always hoping to make it better though ...
--
Mike KB2ML
|
On Tue, Dec 31, 2024 at 03:55 PM, Gordon Gibby KX4Z wrote: Mike, thank you for the note. Can I get you to confirm that you have actually
tested this much faster polling technique for CW and it did not foul up
anything else?
Gordon, I think these changes should work on the 32 bit baseline (is that what you are running?) As for testing - I only run cw and the occasional FT8, on an early sbitx DE running v4.2 (64 bit). No foul-ups have been noticed. Several users switched to the kb2ml branch and tested it on 64 bit baseline with no ill effect. Always hoping to make it better though ... -- Mike KB2ML
|
Mike, thank you for the note. Can I get you to confirm that you have actually tested this much faster polling technique for CW and it did not foul up anything else?
If that is confirmed that seems like an obvious improvement.
Add to it a bit of tightening up on the T/R routines and I think you could have a much better working CW system. I think we’ve really got to get this better.
Is there anything wrong with what I’m saying here?
Gordon kx4z
toggle quoted message
Show quoted text
On Dec 31, 2024, at 14:35, Mike Johnshoy via groups.io <mike.johnshoy@...> wrote:
?Gordon,
I have thought about this a bit. There are some good ideas and some smoke out there.
Easiest fix would be to get polling the straight key to work better. Here is how I think that goes. In sbitx_gtk.c there is a function ui_tick(). This function keeps up with user interface changes ... is the volume or frequency knob turning, and what is the state of all the ui buttons that might be pressed and need an update to the screen. ui_tick() increments a ticks counter every time it gets called. At about line #5739 we see this code to call modem_poll() once every 20 ticks.
modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need.
modem_poll() in turn, calls cw_poll()
cw_poll() calls key_poll() which uses digitalRead() to read the right GPIO pin for the key, and we finally see if the key is down or not! [FOOTNOTE: When we see the key is down, it has actually been down for some time, i.e. it either just happened or it has been down the whole sample interval - on average it will be about average - but we are almost guaranteed to miss a bit of the leading edge. Likewise on key up, the software most likely misses the exact moment of key up and the key will seem to 'stick' until the sample interval happens. This makes it look like dot's and dashes are stretched a little, and shifted to the right.]
So what do we do? We saw that modem_poll() gets called every 20 ticks. modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need. So I wanted to add some extra calls when we are in CW mode, so I do this:
// every 20 ticks call modem_poll to see if any modes need work done
if (ticks % 20 == 0)
modem_poll(mode_id(get_field("r1:mode")->value));
else {
// calling modem_poll every 20 ticks isn't enough to keep up with a fast
// straight key, so now we go on _every_ tick in MODE_CW or MODE_CWR
if ((mode_id(get_field("r1:mode")->value)) == MODE_CW ||
(mode_id(get_field("r1:mode")->value)) == MODE_CWR)
modem_poll(mode_id(get_field("r1:mode")->value));
}
This simple change seemingly gives a 20 x increase in polling rate for cw only. Check out the timing table below. at 25 wpm the original timing interval only gave you 2 samples per dit. Sampling theory (which I can only fail to get correct here) seems to tell us, yes, we can just gaurantee that we will see the 'dit' happen, but we won't have the higher freq 'oversampling' needed to have sharply defined edges.
JJ and the 64-bit team have tested all the changes I've given them and and provided great data and feedback (you mentioned using an external keyer to drive the straight key input which I think is a great way to test this - I don't have one). It still doesn't compare to the other rigs the testers have.
I look forward to some feedback and hearing how I might have this all wrong!
re: other approaches ... Still grasping a bit for new ideas. Maybe a hybrid interrupt driven/polling interface. I feel a little constrained by the existing interface to the straight key, but imagine if you could virtually PTT and whistle CW into the microphone (and not use polling to detect the PTT!) ...
I actually started working CW performance by working from the back end - i.e. looking at the timing in the T/R switch. I think there is some un-needed cruft in the old tr_switch that seemed like a good idea in the days of trying not to ruin PA devices (lots of delay() calls, configuring/reconfiguring LPFs, ...) that is no longer needed, I came up with much tinier tr_switch() that runs on all sbitx hardware (but how could I ever guarantee that!!) But those improvements help get sbitx closer to VERY fast break-in times with some new QRP rigs.
Enjoy your ancient family!
--
Mike KB2ML (if I had more time I would have written a shorter message)
<Clipboard_12-31-2024_01.jpg>
|
Gordon,
I have thought about this a bit. There are some good ideas and some smoke out there.
Easiest fix would be to get polling the straight key to work better. Here is how I think that goes. In sbitx_gtk.c there is a function ui_tick(). This function keeps up with user interface changes ... is the volume or frequency knob turning, and what is the state of all the ui buttons that might be pressed and need an update to the screen. ui_tick() increments a ticks counter every time it gets called. At about line #5739 we see this code to call modem_poll() once every 20 ticks.
modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need.
modem_poll() in turn, calls cw_poll()
cw_poll() calls key_poll() which uses digitalRead() to read the right GPIO pin for the key, and we finally see if the key is down or not! [FOOTNOTE: When we see the key is down, it has actually been down for some time, i.e. it either just happened or it has been down the whole sample interval - on average it will be about average - but we are almost guaranteed to miss a bit of the leading edge. Likewise on key up, the software most likely misses the exact moment of key up and the key will seem to 'stick' until the sample interval happens. This makes it look like dot's and dashes are stretched a little, and shifted to the right.]
So what do we do? We saw that modem_poll() gets called every 20 ticks. modem_poll checks on FT8, CW, and any other built in modes. First temptations is to change 20 to a smaller number - good for CW, but then all the modes get more cpu time and attention than they need. So I wanted to add some extra calls when we are in CW mode, so I do this:
// every 20 ticks call modem_poll to see if any modes need work done
if (ticks % 20 == 0)
modem_poll(mode_id(get_field("r1:mode")->value));
else {
// calling modem_poll every 20 ticks isn't enough to keep up with a fast
// straight key, so now we go on _every_ tick in MODE_CW or MODE_CWR
if ((mode_id(get_field("r1:mode")->value)) == MODE_CW ||
(mode_id(get_field("r1:mode")->value)) == MODE_CWR)
modem_poll(mode_id(get_field("r1:mode")->value));
}
This simple change seemingly gives a 20 x increase in polling rate for cw only. Check out the timing table below. at 25 wpm the original timing interval only gave you 2 samples per dit. Sampling theory (which I can only fail to get correct here) seems to tell us, yes, we can just gaurantee that we will see the 'dit' happen, but we won't have the higher freq 'oversampling' needed to have sharply defined edges.
JJ and the 64-bit team have tested all the changes I've given them and and provided great data and feedback (you mentioned using an external keyer to drive the straight key input which I think is a great way to test this - I don't have one). It still doesn't compare to the other rigs the testers have.
I look forward to some feedback and hearing how I might have this all wrong!
re: other approaches ... Still grasping a bit for new ideas. Maybe a hybrid interrupt driven/polling interface. I feel a little constrained by the existing interface to the straight key, but imagine if you could virtually PTT and whistle CW into the microphone (and not use polling to detect the PTT!) ...
I actually started working CW performance by working from the back end - i.e. looking at the timing in the T/R switch. I think there is some un-needed cruft in the old tr_switch that seemed like a good idea in the days of trying not to ruin PA devices (lots of delay() calls, configuring/reconfiguring LPFs, ...) that is no longer needed, I came up with much tinier tr_switch() that runs on all sbitx hardware (but how could I ever guarantee that!!) But those improvements help get sbitx closer to VERY fast break-in times with some new QRP rigs.
Enjoy your ancient family!
--
Mike KB2ML (if I had more time I would have written a shorter message)
|
HA3HZ
VE6LX
Charles Guerin
tzsantos CR7BOG
