Re: Toroid inductor in sBitx DE upgrade kit
Yellow toroids are usually powdered iron, not ferrite, and specifically mix #6. The toroids in the upgrade kit are not 1/2 inch; they are smaller; the wire on them makes it hard to get an accurate measurement, but my best guess is that they are 0.3 inches. (I have 0.25 and 0.37 inch toroids in my stock; they're bigger than the T25 and smaller than the T37.
They have 15 turns of wire, at least the one I still can find does :) According to the calculator on , 15 turns on a T30-6 would only be a 0.81 uH inductor, far below the 1.2 uH value that the upgrade instructions say it should?be. A 1.2 uH inductor would need to have 18.3 turns. I suppose I could desolder the one I still have and measure it with my L/C meter to see what its value is.
If the value and my observation of the inductor had matched the values for a T30-6 I would have just gone ahead and wound a couple. (Two because they're used in a push-pull circuit so it's probably best for them to match as closely as possible.) But they don't, which is a reason I asked here; I thought they might be toroids from another source that don't have the same specs as the Micrometals ones. And if they are T30 toroids it will be time for me to put together an order for Diz.
On Wed, Jun 7, 2023 at 7:44?PM John Terrell, N6LN < N6LN@...> wrote: Shirley,
Those are 1/2 inch toroids, so FT-50
and I believe yellow is mix 43, which is good for LPF in the HF range, so FT-50-43
Can someone confirm this?
Jack, N6LN
|
Re: Toroid inductor in sBitx DE upgrade kit
Shirley,
Those are 1/2 inch toroids, so FT-50
and I believe yellow is mix 43, which is good for LPF in the HF range, so FT-50-43
Can someone confirm this?
Jack, N6LN
|
Re: #sbitx a software update to fix the spikes
#sBitx
Thanks for all your work.
Just ordered an SBITX yesterday, hope it gets the latest software version.
Looking for to play with the new rig.
Joe
VE1BWV
|
Thanks for sharing.
Just ordered a Sbitx, saw your stl's and printed a PLA silver silk version while waiting for the rig!
Joe?
VE1BWV
|
Toroid inductor in sBitx DE upgrade kit
I managed to drop one of those two yellow inductors in the process of finally upgrading my rig, and it skittered to places unknown. I would like the specs of it so I can replace it.
|
|
|
Evan,
Thanks for your reply!
I believe I can accurately measure the tuning error via the CW transmit method.? Sounds like maybe the easiest thing to do is to turn on RX shift (TX shift off) and look for a pure-ish sinewave at the dial frequency, yes?? From what I was reading, the CW tone is created from a filtered square wave from the Arduino.
Any suggestion for attenuation values?? I do have a set of different attenuators acquired when my ex-employment went belly up.? I'll have to check the max input value to my spectrum analyzer.
My test was to verify that the known AM signal was the same tone when set to 1kHz above or below the dial frequency and then switch between USB and LSB.? The tone should stay the same.
I can try this as well.? Just to clarify, I'd set the tuning dial to something like 15.000 MHz and then create a tones with the freq. gen. at 15.001 MHz and 14.999 MHz and select the proper LSB and USB setting.? The audio tone from the radio should be the same frequency.? Correct?? I'll see if there's a phone app that acts as an audio spectrum analyzer.
Also, adding a tuner (ATU-100) definitely seems to have made a massive difference as well.? The newer versions can tune down to 1W, which is good because I was measuring 4.5W output on 20m this morning.? I'm running the MFJ EFHW 80m - 10m antenna.
Next is to do the Allison mod, hopefully to get a full 10W throughout the bands.? I have parts inbound for this weekend, hopefully.? I'm not sure if I want to do the bass boost modification if I'll be running digital modes for the moment.? A flatter overall audio response might be best.? Any thoughts?
Again, thanks again for your ear!
73
Bryce
AK4MG
|
Hi Bryce,
Congratulations on a working radio!
Rather than play with the tuning, now that you have a working radio, I would use the Memory Manager to try to get as close as possible to a known reference.?
Can you accurately measure the tuning error?? If so, you can use a linear relationship between the current calibration value, the reference frequency, and the error frequency.? If I remember correctly, each hertz error has an 835 impact on the calibration value.? Try searching the messages for calibration spreadsheets to see how others have done it.? The other option is to dig into the code as you have suggested.
My test was to verify that the know AM signal was the same tone when set to 1kHz above or below the dial frequency and then switch between USB and LSB.? The tone should stay the same.
Another method I tried was to measure the transmitted frequency with a very accurate frequency counter through the appropriate attenuator to verify the transmission of CW.? You do need to take into account the setting of the CW sidetone depending on the settings in the memory manager.? With the KD8CEC software, you can have either the transmitted or received frequency offset when in CW mode.? This is set in the Memory Manager.
Have fun learning!
73
Evan
AC9TU
|
Thanks Evan!
I followed your advice last night and created wire antennas for the function generator and radio.? I then tuned to the zero beat frequency.? I had updated to v1.2 of KD8CEC code and the freq. cal seems a bit coarse between steps.? But now, switching between bands keeps the FT8 traffic at very close to correct frequencies (as best I can tell).?
Pondering it now, I wonder if the calibration step size is related to the tuning frequency step size.? This could explain the coarse adjustment...? Regardless, I'm definitely tuned in quite a bit closer to ideal and was able to make some quick FT8 contacts this morning.? ?Again, thanks for your help!
I'll have to try to calibrate again with a 1 Hz tuning step size and see if that makes a difference.? I guess I could always delve into the code to see if this is how it works as well.
The next step is to try out KD8CEC v2.0 from Mark.? Looking forward to it, but I currently don't have an alternate radio, so I'm hesitant to break things now that I have them working again.? The uBitX was of course meant to be a learning radio, but since I'm new to HF in general, the bug to make contacts is running hot.
73
Bryce
AK4MG
|
Re: #sbitx a software update to fix the spikes
#sBitx
toggle quoted message
Show quoted text
On Tue, Jun 6, 2023 at 11:10?PM Ashhar Farhan < farhanbox@...> wrote: Peeps, We have seen reports from many users about the blowing up of the PA transistors. There were?hardware reasons for this to happen (like improper?heatsink mounting) these have been fixed through changes in clamping etc. However, there was a particularly nagging problem of large spikes at the start and end of the transmissions.? See the attached images from the oscilloscope traces. The blue trace is the TX_LINE that goes high on transmit and comes down on receive.? You will note that there is a large burst of RF of 160 v peak to peak at the beginning?and end of transmissions. Sometimes these bursts extend?to 180 v.? The input to the gates of the PA that leads to such high transients exceeds 20v, the breakdown voltage of the PA transistors, leading to catastrophic results. These needed to be cured and I have been investigating this for sometime now. I finally have arrived at the cause and, thankfully, also an entirely software based fix for it. The?transient at the beginning?of the transmission is from the function tx_process() in sbitx.c, the main function that generates transmission signal at 24 KHz. The? tx_process handles a bunch of audio samples from the mic at a time, converts it to frequency domain, etc. To prevent abrupt start and end of the? signals, we use prefix samples from a previous block to the current block of samples to make the signal look continuous. This works well, except that the first time you want to transmit, there are no previous samples and that buffer is full of random numbers that mess up the tx output. I added a code to reset the overlap buffers. The transient at the end of the transmission was discovered to be for those few microseconds where the PA capacitors still have voltage on them while we also open up the T/R switch to bypass the PA, thereby shorting the PA input and output together, creating a nice oscillator that runs until the PA capacitors discharge. The way to stop oscillations is to break the loop. We do this by turning off the LPF switches before switching off the TX_LINE to bypass the PA.? The pictures of the RF output after the patch are given here as well. I pushed these changes a few minutes ago. I recommend this update to protect your PA.
|
Farhan bhai, What about us Indians (hamare liye?) ??
#sbitx_v2
Farhan,
sBitX V2 is still not available in India, please do something about it. If possible, please share pcb design files so that something can be done.
Regards
Ashutosh
|
Ubitx v6 and ModMic Uni (Antlion Audio)
Hi,
If anyone has successfully gotten a ModMic Uni to work with Ubitx v6, I¡¯d love to correspond with you on your set up. ?It works great on my Icom 7300, but I haven¡¯t figured out how to make it play with the Ubitx v6. ?
Thanks 73
Russ K3Pi?
radiok3pi@...?
|
Re: #sbitx a software update to fix the spikes
#sBitx
Btw, just a side note, using a non-atomic control variable and a sleep for thread synchronization is not correct and can create undesired behaviors (apart of the inherent delay). As in some other parts of the code, better use proper thread synchronization primitives. There is a fork that went through the list which fixes some of the thread synchronization issues, for example, in the threads creation. Can anyone remind me that repo address?
Cheers,
Rafael
toggle quoted message
Show quoted text
On 6/7/23 04:09, Ashhar Farhan wrote: Peeps,
We have seen reports from many users about the blowing up of the PA transistors. There were?hardware reasons for this to happen (like improper?heatsink mounting) these have been fixed through changes in clamping etc.
However, there was a particularly nagging problem of large spikes at the start and end of the transmissions.? See the attached images from the oscilloscope traces. The blue trace is the TX_LINE that goes high on transmit and comes down on receive.
You will note that there is a large burst of RF of 160 v peak to peak at the beginning?and end of transmissions. Sometimes these bursts extend?to 180 v.? The input to the gates of the PA that leads to such high transients exceeds 20v, the breakdown voltage of the PA transistors, leading to catastrophic results.
These needed to be cured and I have been investigating this for sometime now. I finally have arrived at the cause and, thankfully, also an entirely software based fix for it.
The?transient at the beginning?of the transmission is from the function tx_process() in sbitx.c, the main function that generates transmission signal at 24 KHz. The? tx_process handles a bunch of audio samples from the mic at a time, converts it to frequency domain, etc. To prevent abrupt start and end of the? signals, we use prefix samples from a previous block to the current block of samples to make the signal look continuous. This works well, except that the first time you want to transmit, there are no previous samples and that buffer is full of random numbers that mess up the tx output. I added a code to reset the overlap buffers.
The transient at the end of the transmission was discovered to be for those few microseconds where the PA capacitors still have voltage on them while we also open up the T/R switch to bypass the PA, thereby shorting the PA input and output together, creating a nice oscillator that runs until the PA capacitors discharge. The way to stop oscillations is to break the loop. We do this by turning off the LPF switches before switching off the TX_LINE to bypass the PA.
The pictures of the RF output after the patch are given here as well.
I pushed these changes a few minutes ago. I recommend this update to protect your PA.
|
Re: #sbitx a software update to fix the spikes
#sBitx
I was realizing that too. Thanks Ashhar!
toggle quoted message
Show quoted text
On 6/7/23 07:38, Ashhar Farhan wrote: It took me a full 24 hour nonstop sprint!
On Wed, Jun 7, 2023, 11:26 AM Raj vu2zap <rajendrakumargg@...> wrote:
Great bug hunt Farhan!
On 07/06/2023 10:41 AM, Ashhar Farhan wrote:
On Wed, Jun 7, 2023 at 10:39?AM Ashhar Farhan
<farhanbox@...> wrote:
Sending the before and after snaps.
- f
On Wed, Jun 7, 2023 at 10:21?AM Ashhar Farhan via groups.io
<> <farhanbox@...> wrote:
It is called tx_stop_fixed. I have it attached in the
original?email
On Wed, Jun 7, 2023, 9:25 AM Evan Hand
<elhandjr@...> wrote:
Farhan,
I believe that the "fixed" traces are the same.? I
take your word that the tx stop is fixed as well.? I
would be curious to see what the tx stop trace looks
like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
It took me a full 24 hour nonstop sprint!
Great bug hunt Farhan!
On 07/06/2023 10:41 AM, Ashhar Farhan
wrote:
On Wed, Jun 7, 2023 at
10:39?AM Ashhar Farhan < farhanbox@...>
wrote:
Sending the before and after snaps.
- f
On Wed, Jun 7, 2023 at
10:21?AM Ashhar Farhan via
<farhanbox= [email protected]>
wrote:
It is called tx_stop_fixed. I have it
attached in the original?email
On Wed, Jun 7, 2023,
9:25 AM Evan Hand < elhandjr@...>
wrote:
Farhan,
I believe that the "fixed" traces are the same.? I
take your word that the tx stop is fixed as well.? I
would be curious to see what the tx stop trace looks
like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
Great bug hunt Farhan!
On 07/06/2023 10:41 AM, Ashhar Farhan
wrote:
toggle quoted message
Show quoted text
On Wed, Jun 7, 2023 at
10:39?AM Ashhar Farhan < farhanbox@...>
wrote:
Sending the before and after snaps.
- f
On Wed, Jun 7, 2023 at
10:21?AM Ashhar Farhan via
<farhanbox= [email protected]>
wrote:
It is called tx_stop_fixed. I have it
attached in the original?email
On Wed, Jun 7, 2023,
9:25 AM Evan Hand < elhandjr@...>
wrote:
Farhan,
I believe that the "fixed" traces are the same.? I
take your word that the tx stop is fixed as well.? I
would be curious to see what the tx stop trace looks
like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
On Wed, Jun 7, 2023 at 10:39?AM Ashhar Farhan < farhanbox@...> wrote: Sending the before and after snaps. - f
On Wed, Jun 7, 2023 at 10:21?AM Ashhar Farhan via <farhanbox= [email protected]> wrote: It is called tx_stop_fixed. I have it attached in the original?email
On Wed, Jun 7, 2023, 9:25 AM Evan Hand < elhandjr@...> wrote: Farhan,
I believe that the "fixed" traces are the same.? I take your word that the tx stop is fixed as well.? I would be curious to see what the tx stop trace looks like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
Sending the before and after snaps. - f
On Wed, Jun 7, 2023 at 10:21?AM Ashhar Farhan via <farhanbox= [email protected]> wrote: It is called tx_stop_fixed. I have it attached in the original?email
On Wed, Jun 7, 2023, 9:25 AM Evan Hand < elhandjr@...> wrote: Farhan,
I believe that the "fixed" traces are the same.? I take your word that the tx stop is fixed as well.? I would be curious to see what the tx stop trace looks like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
It is called tx_stop_fixed. I have it attached in the original?email
On Wed, Jun 7, 2023, 9:25 AM Evan Hand < elhandjr@...> wrote: Farhan,
I believe that the "fixed" traces are the same.? I take your word that the tx stop is fixed as well.? I would be curious to see what the tx stop trace looks like.
73
Evan
AC9TU
|
Re: #sbitx a software update to fix the spikes
#sBitx
Farhan,
I believe that the "fixed" traces are the same.? I take your word that the tx stop is fixed as well.? I would be curious to see what the tx stop trace looks like.
73
Evan
AC9TU
|
Shirley Dulcey KE1L
John Terrell, N6LN
Raj vu2zap
