Date   
Re: Kit box paint removal

Ian Reeve
 

I use a countersink drill bit and carefully remove a thin circular strip of paint and use star washers for all fixings.These washers provide a excellent connection to ground wherever needed..


From: BITX20@groups.io <BITX20@groups.io> on behalf of Curt via Groups.Io <wb8yyy@...>
Sent: Friday, August 23, 2019 6:47:46 PM
To: BITX20@groups.io <BITX20@groups.io>
Subject: Re: [BITX20] Kit box paint removal
 
No exact answers here. I suggest using a large drill bit, by hand, to remove paint at RF connector.

Curt

Re: Kit box paint removal

Mark Hatch
 

I tended to use a Dremel or when I could reach it a belt sander. 

HOWEVER, I seem to remember that there was a thread about the paint somewhere that suggest paint dust and breathing were not something to do at the same time....

73
Mark

Re: Bitx40 very loud, high-pitched, low frequency noise

SP9DEV
 

Alright, time for a follow-up:

I've added two 47nF (0.094uF total) ceramic caps, one 330pF ceramic cap, one 10uF electrolytic cap and another one 100uF cap across the DC input. Unfortunately, the problem is still there.

However, I've assembled a simple 12V battery from one 9V battery and two AA batteries. With this as my power supply, the problem is gone. I can still hear some faint noise, but that's probably due to the fact, that I've been testing this setup right next to my PC, two monitors and a lot of other RFI-generating stuff. So I guess the only way to deal with my problem is to buy a large 12V acid-lead battery and a dedicated charger.

Re: Kit box paint removal

db1bmn@...
 

Re: Bitx40 very loud, high-pitched, low frequency noise

Adrian Chadd
 

Hi,

So if that's the case, how about wrapping the power into the bitx40 through a couple of ferrites? it sounds like you're picking up RFI on the power cable itself and it's making it into the rig.



-adrian


On Fri, 23 Aug 2019 at 11:39, SP9DEV <piotrekslawecki2@...> wrote:

Alright, time for a follow-up:

I've added two 47nF (0.094uF total) ceramic caps, one 330pF ceramic cap, one 10uF electrolytic cap and another one 100uF cap across the DC input. Unfortunately, the problem is still there.

However, I've assembled a simple 12V battery from one 9V battery and two AA batteries. With this as my power supply, the problem is gone. I can still hear some faint noise, but that's probably due to the fact, that I've been testing this setup right next to my PC, two monitors and a lot of other RFI-generating stuff. So I guess the only way to deal with my problem is to buy a large 12V acid-lead battery and a dedicated charger.

Re: raduino crystal question

Gordon Gibby
 

Crystals are specified by their manufacturer to oscillate to correct frequency when placed in a circuit that has a certain amount of parallel capacitance, which is a property of the circuit, not the capacitance per se of the crystal

If you need a few extra picofarads of capacitance and your circuit to meet the manufacturers requirement, that is easily added with a small capacitor.  

The reason that the bitx series tends to oscillate  just a little bit higher than where it should’ve, is because there apparently isn’t enough capacitance in parallel— which makes the crystal oscillator be a little higher than expected 

You can easily fix that in the source code of the software by just changing the designated frequency of the Crystal to match where it actually oscillates, and then all of your adjustments should be simple from then on     A good communications receiver will allow you to measure the actual oscillation frequency.  Dip a  wire near the raduino and you’ll pick up a  signal

Even easier is to command the read you a note to go to the specified frequency of the Crystal, and then measure the amplified output!   That’s a very loud signal!

Add 10-20 picofarads in parallel with the capacitor and you may find that you get it exactly on frequency without doing any software at all

These are wonderful things to learn in 
ham radio


On Aug 23, 2019, at 00:09, "ashok.das81@..." <ashok.das81@...> wrote:

Thanks KE7ER thats helps a lot.

Re: Bitx40 very loud, high-pitched, low frequency noise

Gordon Gibby
 

You may decide that you want to build a real low pass filter, with an inductor etc., similar to what people had to use in the past to get rid of alternator whine 


On Aug 23, 2019, at 14:39, SP9DEV <piotrekslawecki2@...> wrote:

Alright, time for a follow-up:

I've added two 47nF (0.094uF total) ceramic caps, one 330pF ceramic cap, one 10uF electrolytic cap and another one 100uF cap across the DC input. Unfortunately, the problem is still there.

However, I've assembled a simple 12V battery from one 9V battery and two AA batteries. With this as my power supply, the problem is gone. I can still hear some faint noise, but that's probably due to the fact, that I've been testing this setup right next to my PC, two monitors and a lot of other RFI-generating stuff. So I guess the only way to deal with my problem is to buy a large 12V acid-lead battery and a dedicated charger.

Re: Bitx40 very loud, high-pitched, low frequency noise

Woody
 

On 8/23/2019 19:39, Gordon Gibby wrote:
You may decide that you want to build a real low pass filter, with an inductor etc., similar to what people had to use in the past to get rid of alternator whine
--
...Or a new / different power supply.
--
It would be interesting to examine the supply output with an oscilloscope.

W00DY

--

Re: Kit box paint removal

Ian Reeve
 

Should always be mindful of paint dust etc,I never use power tools for this purpose,a hand drill and counter sinking bit work for me.Any dust thus created won't be spread and inhaled as you drill at hand speed.


From: BITX20@groups.io <BITX20@groups.io> on behalf of db1bmn@... <db1bmn@...>
Sent: Friday, August 23, 2019 7:45:02 PM
To: BITX20@groups.io <BITX20@groups.io>
Subject: Re: [BITX20] Kit box paint removal
 

Re: Audio pre-amplifier for microphone?

Dennis Zabawa
 

I have one sitting on my bench that I have not had the chance to wire up.  From the specs, it looks ideal for the task.

Re: Bitx40 very loud, high-pitched, low frequency noise

Ian Reeve
 

I think that your comment about even on battery there is faint noise and it is near your PC is significant.Some pc's give out lots of hash or wine and I wonder if moving the uBITX  further away may silence that last bit of noise.I am surprised that the capacitor combination on the output does not help,that has always worked for me as I proved by my test last evening on a randomly picked switch mode wall wart.  Anyways it's progress in the right direction,keep the leads short and you will minimise pickup.A ferrite ring or two on the cables won't do any harm,the best quality power supplies usually have fitted on the DC lead to keep switching noise away from the DC output.


From: BITX20@groups.io <BITX20@groups.io> on behalf of Woody <woody@...>
Sent: Friday, August 23, 2019 8:58:25 PM
To: BITX20@groups.io <BITX20@groups.io>
Subject: Re: [BITX20] Bitx40 very loud, high-pitched, low frequency noise
 
On 8/23/2019 19:39, Gordon Gibby wrote:
> You may decide that you want to build a real low pass filter, with an
> inductor etc., similar to what people had to use in the past to get
> rid of alternator whine
--
...Or a new / different power supply.
--
It would be interesting to examine the supply output with an oscilloscope.

W00DY

--



Re: bitx and ubitx encoder replacement / Software Issues (too slow)

Sascha Bohnet | DL5SMB
 

Hey, It's me again :-)

Still working on this problem - and since I think I am not the only one who wants to get this encoder working,
I am keeping to this thread.

My next approach to this problem was switching to an I2C adapter.

This way I could free up some digital pins, formerly used by the parallel connection of the display.

The idea was that maybe another rotary encoder libray works better than the standard solution. If thats is not sufficient,
maybe there is still the possibility of using a pin change interrupt libray or port mapping.

So I started making adjustments in the code and inserted the quite popular rotary libray by Ben Buxton,
but it is not working correctly yet. As soon as power is applied the frequency starts going up.

If I push the button I am able to get into the menue. There I can choose within the first layer of
options "Select band, "select VFO"... but as soon as I enter the second layer (80m, 40m, etc)
all band start changing permanently, as If soneone would turn the encoder very fast.

And if the putton is pushed again, a random band is choosen and the VFO starts running up again.
Turning the rotary encoder again does nothing - whatever direction or speed I use. It's still running up.

I assume the problem is caused by the interaction of the two functions

enc_read() (original) in file ubitx.ui (which I modified to this)
            and
doTuningWithThresHold() in file ubitx_20

I thought I understood  vaguely what exactly enc_read() does in the original version, but it seems this function does not simply give back
an increasing or decreasing number.  For example I don't get what purpose the additional "enc_speed++;" is serving.
I don't see where this is relevant in the code or where this is used later.

After playing around a bit I inserted a "delay(1)" within the rotary code before the value is given back. This stopped the VFO
from going wild and allowed tuning again.

But issues persist:

a.) if the encoder is turned to fast, it hangs again (maybe like with the original code?)
b.) in the second layer of the menu no signals of the encoder are recognizes. The menue does not go wild, but you cannot
     choose anything either.

Does anybody see what it is that I am doing wrong?

I once also tried the old mechanical encoder again with the new library at the digital ports.
With that one i needed 20 complete turns in the fuirst layer of the menu to get to the next option ("Change bands" to "Change VFO A").
Maybe this is also relevant.

It would be nice if anyone had some suggestions.

Sascha






 

Re: bitx and ubitx encoder replacement / Software Issues (too slow)

Sascha Bohnet | DL5SMB
 

I totally forgot that changing the title breaks the contiguity.

There is the original thread.

Re: Audio pre-amplifier for microphone?

Gordon Gibby
 

It looks like an excellent solution.  


On Aug 23, 2019, at 16:01, Dennis Zabawa <kg4rul@...> wrote:

I have one sitting on my bench that I have not had the chance to wire up.  From the specs, it looks ideal for the task.

Re: Audio pre-amplifier for microphone?

Don, ND6T
 

Here is what I use: A dynamic mic element feeding a 3-component common-base amplifier. Fits right inside the microphone case. Matches the 600 ohm element to the pre-amp and great frequency response.
Doesn't get much simpler. 73, Don

Wired up Bitx40 and it doesn't work!

mark.wheeler3575@...
 

I finally got around to wiring up my bitx40 QRP radio and when I applied 12v, 2.0 amps from my bench power supply, nothing happens with the bitx40... the bench power supply supply voltage drops down from 12v to 0.49 V, but nothing happening on the Bitx40 display and no sound from the speaker.  I checked the inline fuse and it is working and it did not pop...  

Any suggestions are greatly appreciated. 

--
73,

Mark / WU6R
mark.wheeler3575@...

Re: Wired up Bitx40 and it doesn't work!

Jerry Gaffke
 

Are you measuring that 12v at the power supply terminals?
If so, then I would guess that either the supply is too wimpy or there is a knob somewhere that has set the current limit too low.

If you are measuring that 12v at the Bitx40, then there may be a bad solder job or bad connector between the power supply and the Bitx40.

Jerry
 

On Fri, Aug 23, 2019 at 05:04 PM, <mark.wheeler3575@...> wrote:
I finally got around to wiring up my bitx40 QRP radio and when I applied 12v, 2.0 amps from my bench power supply, nothing happens with the bitx40... the bench power supply supply voltage drops down from 12v to 0.49 V, but nothing happening on the Bitx40 display and no sound from the speaker.  I checked the inline fuse and it is working and it did not pop...  

Re: Wired up Bitx40 and it doesn't work!

Jerry Gaffke
 

Also, make certain that you don't have the +12v and Ground leads from power supply to Bitx40 reversed.
It could be that the reverse polarity protection diode recommended in the Bitx40 instructions actually worked in this case,
and the power supply has folded back into a shutdown mode due to over-current.

Re: bitx and ubitx encoder replacement / Software Issues (too slow)

Sascha Bohnet | DL5SMB
 

So, I played some more and found a simple solution that works for me.

As I could not figure out, why the new library was not working, i rewired the encoder to the analog inputs
and  reloaded the original code - but, based on my earlier findings, made two changes:

Within the enc_read() function, I changed both delay(1) commands to delayMicroseconds(1),
so the function looks like this.

With this change of code I seem to get my 100 pulses per rotation - though the faster I go the more pulses get swallowed.
But I think this workaround is bearable :-)

I also tried fiddling around with the millis(), exchanging them for micros(), but this was more pain than it was worth,
though maybe I just tried the wrong values (I tried 1 and 500 instead of the default 50).

Maybe this helps someone - I just wanted to document what I found for everyone else who does not have too much experience in programming.

Sascha
 

Re: bitx and ubitx encoder replacement / Software Issues (too slow)

Jack, W8TEE
 

Keep in mind that the delay() function is a blocking function. That it, it uses its own interrupt service routine so if you're using an ISR for your encoder and it calls delay(), all kinds of weird things can happen, all usually bad. This is while I wrote MyDelay() which is constructed from non-blocking calls.

Jack, W8TEE

On Friday, August 23, 2019, 8:37:39 PM EDT, Sascha Bohnet | DL5SMB via Groups.Io <saschabohnet@...> wrote:


So, I played some more and found a simple solution that works for me.

As I could not figure out, why the new library was not working, i rewired the encoder to the analog inputs
and  reloaded the original code - but, based on my earlier findings, made two changes:

Within the enc_read() function, I changed both delay(1) commands to delayMicroseconds(1),
so the function looks like this.

With this change of code I seem to get my 100 pulses per rotation - though the faster I go the more pulses get swallowed.
But I think this workaround is bearable :-)

I also tried fiddling around with the millis(), exchanging them for micros(), but this was more pain than it was worth,
though maybe I just tried the wrong values (I tried 1 and 500 instead of the default 50).

Maybe this helps someone - I just wanted to document what I found for everyone else who does not have too much experience in programming.

Sascha