Re: Struggling with tuning clicks and birdie sounds
On Thu, Jun 8, 2017 at 01:26 pm, Richard Spohn wrote:
Allard, I would like to take the opportunity to thank you for your
continuing evolution of the Bitx40 software. You have made yourself
indispensable in making this radio great! I received my Bitx40 box
maybe six months ago and it is still in there, as I watch your
software evolve...and if I had jumped in and made it and modified it
asap, many mods would already have been undone as I find your
programming getting better and better. There is some value in
procrastination after all...
Thanks Rich, it's always good to hear that users like the software. On the other hand, I definitely don't want to encourage any procrastination. The whole idea of the BITX40 project is to encourage experimentation. So open that BITX40 box and start playing! 73 Allard PE1NWL
?
|
Re: Bitx connector pins and Crimping
I have some crimpers, I think I got from Seeed.
I have had trouble using them. The pins are so small, you have to have every thing perfect.
You can smash the pin or it turns sideways? You got to have good eyes. And the stranded wires can not be frayed.
One thing, I use 26 Ga. wire, I got hundreds of feet in 5 or 6 colors.
I have had wires bird cage (fray) while trying to crimp, so I always TIN the wire to hold the strands together. That breaks the no-solder rule.
For the solder method, I use a needle nose and crimp with a roll motion the 2 sides. Solder real quick, and when cool crimp the top strain relief.
Don't do the top Hot, it melts the insulation.
If the solder wicks ups to the top, the wires will break from use. So, just a quick solder job.
Soldering is bad for connector pins. The military and industry have developed crimping on just the wire to cure the problem of work hardening and then breaking. So only us Hobbyists can get away with it!
Mike, WA6ISP
toggle quoted message
Show quoted text
On 6/8/2017 1:29 PM, Vince Vielhaber wrote: I use needle nose and a soldering iron! Seen too many crimp failures over time.
Vince.
On 06/08/2017 04:08 PM, Doug W wrote:
I know I am asking for two things that are typically mutually exclusive,
but has anyone found a cheap and reliable crimp tool for the connectors?
|
Re: Calling all Midwesterners.
K0KIK, Daniel from LeMars, IA. EN12wt
|
Re: Calling all Midwesterners.
John, AD0RW, from Coralville, Iowa. Hawkeye country, right next door to Iowa City and the U. of Iowa.
I have a choice between a dipole at 30 feet and an 80 meter wire vertical (mostly, more like half a 'Y')
tuned as an end fed half wave on 40. The latter seems to work better for long haul contacts.
|
Re: Struggling with tuning clicks and birdie sounds
On Thu, Jun 8, 2017 at 01:43 pm, Jack Purdum wrote:
That's even better, as Allard's code is pretty tight. One of my worries is that we don't fragment and fracture the group with too many processor/code variations. I'm guilty of this, too, as I will soon be releasing my firmware which uses the Arduino Mega 2560 Pro Mini.
Jack,
thanks for your wise comment, but I believe there's no need to worry.
I started my project from the following basic goals:
- provide a "standard" software
- some minimal hardware may have to be added for certain extra functions
- but even without the mods it should still basically work on the standard supplied hardware
So far we have been able to greatly improve the code and we could add some features that any HF radio should have: USB, CW, precise tuning.
We were even able to add some extra features such as Dual VFO, SPIT, SCAN. There are still some things on the wishlist though.
There are still some bytes left, and perhaps Pavel's library will free up some more space, but one day we will come to a point that we have to conclude that we "squeezed" the most out of the poor little nano.
Your project follows a different path from the beginning as it uses different hardware which, undoubtfully, opens new opportunities for extended features that will never fit into a nano.
So I believe the two projects can happily co-exist. And probably even more parallel projects will come up in the future. Nothing is forever, that's true innovation.
After all it's still up to the builders what they want to do with their BITX40's!
73 Allard PE1NWL
|
Did you see the picture. I have had to throw away ones like that. They are made for automated equipment that shears off the sides.
I have had lots of them, they stink. If you don't cut perfect they are too wide to go in for insertion.
There drawing may show them in finished ready to use condition. But if they come connected side by side they are a big pain.
Real Molex from Mouser, you won't have the problem. They break off on the end, or better yet, buy them loose.
They are about $3.20 per Hundred.
But you can save a lot of money buying the actual connectors from Taya.
I just got a few hundred last week, the seem OK, but are not exactly like the Molex. The Molex pins fit them.
Mike, WA6ISP
toggle quoted message
Show quoted text
On 6/8/2017 1:15 PM, Vince Vielhaber wrote:
Did you look at the actual datasheet? They break off from the top.
Vince.
On 06/08/2017 03:11 PM, Michael Hagen wrote:
Tayda has good connectors, but I would not buy their pins if they look
like their picture!
Beware of the pins that look like this! You have to cut them flush on
the sides where they slide in.
I have used them, very troublesome.
Either buy them "Loose" (ready) or if connect together they break off on
the end, not the sides.
On 6/8/2017 11:11 AM, Vince Vielhaber wrote:
Is that the same as these? (note: they use the same pic for all of them)
Vince.
On 06/08/2017 01:47 PM, Michael Hagen wrote:
Mouser Crimp Term 22-30 Ga. by Molex
# 538-08-50-0114
On 6/8/2017 10:24 AM, bwbangerter via Groups.Io wrote:
I would like to obtain a few female pins for the connector bodies used
with the bitx40. But I do not recognize these connectors. It would
be useful to make up shielded cables for some of the connections, and
to make connections without splicing wires. Can anyone tell me what
to order?
|
Re: W8TEE TFT/VFO Board from FDIM talk
Jack,
Thanks for sending the boards. Picked them up today.. Nice looking board!.
I also received my atmega 2560 mini pro and the correct DDS 9850. Mars 3 etc So parts have started to roll in...
1. I presume the vrmini 360,atmega and dds9850 all mount on the same side - the side with the lettering. (on the same side that says tft lcd vfo lettering)?
2. I was thinking of putting headers pins ?/ sockets for ?- ?atmega, dds and vr mini. Just in case of a future failure.? Then run cables from the tft ?display and tft vfo board. ? and mount the tft vfo board on the ?radio chassis and the ?TFT display on the front panel
Does this make sense or do you see any issues?
Any forecast on the code?
Thanks for your service , any info / guidance would be appreciated.
Ps:
?I am preping a new case ( a converted small form dell computer case , for my 3rd bitx - (for your ?Colour TFT/vfo board..) I am making sure this time, to have lots of room for big heatsink and room for ?various modules.etc.... I use my current bitx40 for mostly jt65 - works great and some ssb.
Great fun for a retired senior (me) Joe? VE1BWV
On Fri, May 26, 2017 at 6:10 PM, Jack Purdum via Groups.Io <econjack@...> wrote: All:
Attached is the manual that will go with the TFT/VFO PCB that I am making available. I suggest that you read through it to determine if you want to build it. The manual only talks about the TFT/VFO board. The AGC, CW mode, and speech compressor will be on a separate board. I've also attached a schematic, and BOM for the board. I have a limited amount of the boards and will announce their cost after I package one up and take it to the post office to see what it costs to send it. That won't be cheap as the PO requires it to be Parcel Post rather than First Class.
The way I'd like to do this:
On Monday I will give you the cost, which will include shipping to the US. If you order more than one board, add $0.20 for each additional board. I will give you a Paypal account for the payment.
Please write an email to me first telling me how many boards you want and the address where to send them. If I have boards left, I will write back with "Yes", whereupon you make your payment after which I'll send the board(s). If I say "No", I'm out of boards so don't make a payment. I may reorder and, if I do, I'll post here that they're back in and we start over.
Read the manual and figure out if your interested. My guess is that the first board will cost $6.00.
72, Jack, W8TEE
|
Re: Dhl customs cost to the usa
I ordered my bitx40 in late May, with DHL shipping for $10, and received it in a few days. ?No customs charge.
|
Thanks to everyone who responded. ?That puts me on the right track. ?I use pliers to crimp such pins, then solder. ?A bit fussy to do, but works for me.
|
The $19 DIY DSP audio filter
I came across this superb project. I have already ordered a teensy do I can play with it. It may work?nicely inside our bitx40 It is incredibly well documented  
|
Re: Calling all Midwesterners.
About 5 miles south of Charlevoix, Michigan. Charlevoix is on US 31, south-west of the Straits of Mackinaw.
Rich KC8MWG
On Thursday, June 8, 2017 5:54 PM, KC8WBK via Groups.Io <cruisenewsnet@...> wrote:
South Haven, Michigan, near the shore of Lake Michigan, 80 miles Northeast of Chicago Harbor.
Draw a line down 8 Mile Road all the way from Detroit to Lake Michigan, where 8 Mile Rd (Baseline Rd) hits Lake Michigan, thats where I live. (Actually closer to 7 Mile).
Dipole in the trees running north-south about 35 feet high.
I am in a valley with a sand dune to my west, which seems to block some of the propagation out west.
I have a pipeline to the East Coast, from Boston to Charleston.
|
Re: Struggling with tuning clicks and birdie sounds
Enjoy the vacation Pavel!
Looking forward to your updated library when you're back.
73 Allard PE1NWL
toggle quoted message
Show quoted text
On Thu, June 8, 2017 23:51, Pavel Milanes Costa wrote: Yeah.
I even pretend in the past to made a folk, a mix of one of my project &
bitx40, but time (lack of it) move me to join my efforts to improve
Allards code...
That's the beauty of open source, you has more flavours than the
standard and everyone has a personal taste and version to pick from.
Now is then, I'm going full offline now, away of the cold office into
the sunny beach... people, vacations wait for me... until next week.
I'm directed by my wife to follow this simple rule: no
internet/PC/solder iron/wires/tin, etc until return.
73.
El 08/06/17 a las 16:29, Jack Purdum via Groups.Io escribi??:
That's even better, as Allard's code is pretty tight. One of my
worries is that we don't fragment and fracture the group with too many
processor/code variations. I'm guilty of this, too, as I will soon be
releasing my firmware which uses the Arduino Mega 2560 Pro Mini. I
think it was Jerry who suggested the STM32F processor and others have
mentioned the Teensy. Actually, I'd really be in favor of the Teensy
3.6 as it has a mega-munch of both flash and SRAM memory, is clocked
at 180MHz, and has a bunch of other neat features AND can be
programmed in the Arduino IDE...a huge advantage. Mainly I chose the
Mega because it costs about half what the Teensy sells for and I
really want to have all my "modded" BITX40 for under $100. So, within
a few days, we will have the original Raduino code, Allard code, and
my code. I can see some confusion taking place down the road when
someone cpmplains: "My display is not working." or whatever.
Those with a "standard Raduino" are no doubt happy with it. Many
others have upgraded to the robust feature set that Allard has in his
code, and I doubt that many would want to give those up. Likewise, I
don't want to give up the features my firmware supports. So, what the
answer? I'm not sure. If everyone prefaces their support questions
with: "I'm using the XXX firmware, Ver YYY...", perhaps everyone can
coexist as we do now. I, for one, hope we can keep one group as we all
share at least a core functionality.
Jack, W8TEE
------------------------------------------------------------------------
*From:* Pavel Milanes Costa <pavelmc@...>
*To:* [email protected]
*Sent:* Thursday, June 8, 2017 1:50 PM
*Subject:* Re: [BITX20] Struggling with tuning clicks and birdie sounds
Jack, That's for Allard's code.
I created a Si5351 lib a while ago that it's smaller (firware & SRAM)
than the Jason one () and I was
playing with Allard code and it can cut 25% of the used firmware (I
really don't check how much SRAM but Allard got excited about the sram
it can free)
The problem was that I haven't a real raduino hardware, I assembled
all the hardware with a breadboard and an Arduino Pro and the guide of
the Raduino schematics + a old version of a bitx20 board modded to 40m.
The patch works great here (homebre hardware) but don't works on
Allard tests (real raduino).
Last night I borrowed a real raduino + bit40v3 SMD from a ham friend
and beging testing it... first round result in no hardware
discrepances but it doesn't work (just like Allard noted to me, the
si5351 does not generate any freq.)
I have to go deeper, but it must wait a few days... this night I go on
vacation with the family until next week. 8-)
73 from (almost) the sunny Santa Luc??a Beach on the North Coast of
Cuba.
El 08/06/17 a las 13:01, Jack Purdum via Groups.Io escribi??:
OK...I misunderstood when you said "no clicks". The statement "...the
RF noise is almost gone" makes more sense. I was wondering how you
could completely removed it in code.
I have a battery voltage monitor and I only refresh its field when
the battery voltage drops by 0.2V. This helps reduce the flicker by
only doing updates when it's needed. When you say you are going to
publish a patch that cuts the firmware code size by 25% plus "a lot"
of SRAM, which firmware are you talking about...the original Raduino
code, or Allard's code?
Jack, W8TEE
------------------------------------------------------------------------
*From:* Pavel Milanes Costa <pavelmc@...>
<mailto:pavelmc@...>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Thursday, June 8, 2017 12:33 PM
*Subject:* Re: [BITX20] Struggling with tuning clicks and birdie sounds
Simple:
Minimize the LCD writes and you will be fine.
I implemented a s-meter bar in a raduino like project
() and oh boy... it was a mess
in the RF spectrum INSIDE de receiver... I tracked the problem to LCD
writes...
I have to minimize the lcd writes and make the code just update the
bar in the space it needs to (writing or erasing simple bars, not
just redraw it in full every time) and the RF noise is almost gone...
Confession: that's why I don't like the buffer concept of the LCD in
the raduino code, it write the entire line EVERY time it needs to
update a single digit. For RF quietiness it's better to split it in
zones and only update the zone as it's needed. That also helps, but
can turn into bigger code.
Don't worry abot used code, I'm about to push a patch to cut 25% of
the used firmware and a lot of RAM in the raduino, I'm just
valitating it.
73.
El 08/06/17 a las 09:12, Jack Purdum via Groups.Io escribi??:
Hi Dimitar:
I saw your comment:
(many features - many clicks ..., simple code - no clicks).
and would like to you to explain how that works to me in greater
detail. I know that many of us have experienced this problem and
would like to know how you discovered that simplifying the code,
while still maintaining the features set, was done and how you
simplified the code.
Thanks!
Jack, W8TEE
------------------------------------------------------------------------
*From:* Dimitar Pavlov via Groups.Io <lz1dpn@...>
<mailto:lz1dpn@...>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Thursday, June 8, 2017 3:47 AM
*Subject:* Re: [BITX20] Struggling with tuning clicks and birdie
sounds
Hi all,
Before, I have the same problem with other transceivers, with
various DDS, and with LED/OLED displays.
The tuning clicks, are the software problem, connected to refreshing
frequency for display,
reading frequency for the rotary encoder and other refreshing
frequencies in arduino code (update frequency to Si570/Si5351/AD9851
...).
To resolve this problem need to optimize code, and implement some
wait()/delay() functions.
(many features - many clicks ..., simple code - no clicks).
The QRP transceiver is just QRP transceiver - not need to make
coffee , and read news papper ...
Good idea is to use separate power source (2 or 3 pcs LM7812 / 7805
/ 7806 for DDS, receiver and other ...
(Birdie sounds are harmonics problem with DDS, and it is not
resolving problem. Transceivers also have birdies in other
frequencies,
but Your band plan includes only one/two of them.)
73!
On Thursday, June 8, 2017 12:42 AM, Dr Fred Hambrecht
<AAR4MI@...> <mailto:AAR4MI@...> wrote:
I have braided both the tuning and volume control wires with good
results,
plus it looks better.
v/r
Fred W4JLE
-----Original Message-----
From: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] On Behalf Of
Allard PE1NWL
Sent: Wednesday, June 7, 2017 07:39
To: [email protected] <mailto:[email protected]>
Subject: Re: [BITX20] Struggling with tuning clicks and birdie sounds
It seems there is a huge variability between various BITX40 radios,
and
there are various points where improvements may help.
In my particular case, I achieved the greatest tuning click
reduction just
by using shielded wires to and from the volume potentiometer.
73 Allard PE1NWL
|
Re: Calling all Midwesterners.
South Haven, Michigan, near the shore of Lake Michigan, 80 miles Northeast of Chicago Harbor.
Draw a line down 8 Mile Road all the way from Detroit to Lake Michigan, where 8 Mile Rd (Baseline Rd) hits Lake Michigan, thats where I live. (Actually closer to 7 Mile).
Dipole in the trees running north-south about 35 feet high.
I am in a valley with a sand dune to my west, which seems to block some of the propagation out west.
I have a pipeline to the East Coast, from Boston to Charleston.
|
Re: Struggling with tuning clicks and birdie sounds
Yeah.
I even pretend in the past to made a folk, a mix of one of my
project & bitx40,? but time (lack of it) move me to join my
efforts to improve Allards code...
That's the beauty of open source, you has more flavours than the
standard and everyone has a personal taste and version to pick
from.
Now is then, I'm going full offline now, away of the cold office
into the sunny beach... people, vacations wait for me... until
next week.
I'm directed by my wife to follow this simple rule: no
internet/PC/solder iron/wires/tin, etc until return.
73.
El 08/06/17 a las 16:29, Jack Purdum
via Groups.Io escribi¨®:
toggle quoted message
Show quoted text
That's even better, as
Allard's code is pretty tight. One of my worries is that we
don't fragment and fracture the group with too many
processor/code variations. I'm guilty of this, too, as I
will soon be releasing my firmware which uses the Arduino
Mega 2560 Pro Mini. I think it was Jerry who suggested the
STM32F processor and others have mentioned the Teensy.
Actually, I'd really be in favor of the Teensy 3.6 as it has
a mega-munch of both flash and SRAM memory, is clocked at
180MHz, and has a bunch of other neat features AND can be
programmed in the Arduino IDE...a huge advantage. Mainly I
chose the Mega because it costs about half what the Teensy
sells for and I really want to have all my "modded" BITX40
for under $100. So, within a few days, we will have the
original Raduino code, Allard code, and my code. I can see
some confusion taking place down the road when someone
cpmplains: "My display is not working." or whatever.
Those with a "standard
Raduino" are no doubt happy with it. Many others have
upgraded to the robust feature set that Allard has in his
code, and I doubt that many would want to give those up.
Likewise, I don't want to give up the features my firmware
supports. So, what the answer? I'm not sure. If everyone
prefaces their support questions with: "I'm using the XXX
firmware, Ver YYY...", perhaps everyone can coexist as we do
now. I, for one, hope we can keep one group as we all share
at least a core functionality.
Jack,
W8TEE?
From:
Pavel Milanes Costa <pavelmc@...>
To:
[email protected]
Sent:
Thursday, June 8, 2017 1:50 PM
Subject:
Re: [BITX20] Struggling with tuning clicks and birdie
sounds
Jack,
That's for Allard's code.
I created
a Si5351 lib a while ago that it's smaller
(firware & SRAM) than the Jason one ()
and I was playing with Allard code and it can cut
25% of the used firmware (I really don't check how
much SRAM but Allard got excited about the sram it
can free)
The
problem was that I haven't a real raduino
hardware, I assembled all the hardware with a
breadboard and an Arduino Pro and the guide of the
Raduino schematics + a old version of a bitx20
board modded to 40m.
The patch
works great here (homebre hardware) but don't
works on Allard tests (real raduino).
Last
night I borrowed a real raduino + bit40v3 SMD from
a ham friend and beging testing it... first round
result in no hardware discrepances but it doesn't
work (just like Allard noted to me, the si5351
does not generate any freq.)
I have to
go deeper, but it must wait a few days... this
night I go on vacation with the family until next
week. 8-)
73 from
(almost) the sunny Santa Luc¨ªa Beach on the North
Coast of Cuba.
El
08/06/17 a las 13:01, Jack Purdum via Groups.Io
escribi¨®:
OK...I misunderstood
when you said "no clicks". The statement
"...the RF noise is almost gone" makes more
sense. I was wondering how you could?completely
removed it in code.
I have a battery
voltage monitor and I only refresh its field
when the battery voltage drops by 0.2V. This
helps reduce the flicker by only doing
updates when it's needed. When you say you
are going to publish a patch that cuts the
firmware code size by 25% plus "a lot" of
SRAM, which firmware are you talking
about...the original Raduino code, or
Allard's code?
Jack,
W8TEE
From:
Pavel Milanes Costa <pavelmc@...>
To:
[email protected]
Sent:
Thursday, June 8, 2017 12:33 PM
Subject:
Re: [BITX20] Struggling with tuning
clicks and birdie sounds
Simple:
Minimize
the LCD writes and you will be
fine.
I
implemented a s-meter bar in a
raduino like project ()
and oh boy... it was a mess in the
RF spectrum INSIDE de receiver...
I tracked the problem to LCD
writes...
I
have to minimize the lcd writes
and make the code just update the
bar in the space it needs to
(writing or erasing simple bars,
not just redraw it in full every
time) and the RF noise is almost
gone...
Confession:
that's why I don't like the buffer
concept of the LCD in the raduino
code, it write the entire line
EVERY time it needs to update a
single digit. For RF quietiness
it's better to split it in zones
and only update the zone as it's
needed. That also helps, but can
turn into bigger code.
Don't
worry abot used code, I'm about to
push a patch to cut 25% of the
used firmware and a lot of RAM in
the raduino, I'm just valitating
it.
73.
El 08/06/17 a las
09:12, Jack Purdum via Groups.Io
escribi¨®:
Hi
Dimitar:
I saw your comment:?
(many
features - many clicks ...,
simple code - no clicks).
and would like to you to
explain how that works to me
in greater detail. I know that
many of us have experienced
this problem and would like to
know how you discovered that
simplifying the code, while
still maintaining the features
set, was done and how you
simplified the code.
Thanks!
Jack,
W8TEE
From:
Dimitar Pavlov via
Groups.Io <lz1dpn@...>
To:
[email protected]
Sent:
Thursday, June 8, 2017
3:47 AM
Subject:
Re: [BITX20] Struggling
with tuning clicks and
birdie sounds
Hi
all,
Before,
I have the same
problem with
other
transceivers,
with various
DDS, and with
LED/OLED
displays.
The
tuning clicks,
are the software
problem,
connected to
refreshing
frequency for
display,
reading
frequency for
the rotary
encoder and
other refreshing
frequencies in
arduino code
(update
frequency to
Si570/Si5351/AD9851
...).
To
resolve this
problem need to
optimize code,
and implement
some
wait()/delay()
functions.
(many
features - many
clicks ...,
simple code - no
clicks).
The
QRP transceiver
is just QRP
transceiver -
not need to make
coffee , and
read news papper
...
Good
idea is to use
separate power
source (2 or 3
pcs LM7812 /
7805 / 7806 for
DDS, receiver
and other ...
(Birdie sounds are
harmonics
problem with
DDS, and it is
not resolving
problem.
Transceivers
also have
birdies in
other
frequencies,
but Your band plan
includes only
one/two of
them.)
73!
On
Thursday, June
8, 2017 12:42
AM, Dr Fred
Hambrecht <AAR4MI@...> wrote:
I
have braided
both the
tuning and
volume control
wires with
good results,
plus
it looks
better.
v/r
Fred
W4JLE
-----Original
Message-----
Sent:
Wednesday,
June 7, 2017
07:39
Subject:
Re: [BITX20]
Struggling
with tuning
clicks and
birdie sounds
It
seems there is
a huge
variability
between
various BITX40
radios, and
there
are various
points where
improvements
may help.
In
my particular
case, I
achieved the
greatest
tuning click
reduction just
by
using shielded
wires to and
from the
volume
potentiometer.
73
Allard PE1NWL
|
i have to say that I managed to connect a Baofeng mic using a 4 pin connector -much more reluable and steady connection than a jack 3,5- but i decided to use original mic just for testing. So I made this little mic with a spare push connector and a project box. You may use just about anything? i recycled a usb wire. They are great: 4 wires + shield  
|
Re: Allard's Version 1.113
El 07/06/17 a las 12:23, bigdswitzer
escribi¨®:
Using IDE v1.6.9
Arduino IDE 1.8.x familly introduced a few code optimizations.
(in fact they was tested in the 1.7.x familly but stablished on
the 1.8.x familly)
That's why you see 100% code size, upgrade to the latest Arduino
IDE ASAP and you will notice the size drop using the same code...
73 de CO7WT.
|
Re: Struggling with tuning clicks and birdie sounds
That's even better, as Allard's code is pretty tight. One of my worries is that we don't fragment and fracture the group with too many processor/code variations. I'm guilty of this, too, as I will soon be releasing my firmware which uses the Arduino Mega 2560 Pro Mini. I think it was Jerry who suggested the STM32F processor and others have mentioned the Teensy. Actually, I'd really be in favor of the Teensy 3.6 as it has a mega-munch of both flash and SRAM memory, is clocked at 180MHz, and has a bunch of other neat features AND can be programmed in the Arduino IDE...a huge advantage. Mainly I chose the Mega because it costs about half what the Teensy sells for and I really want to have all my "modded" BITX40 for under $100. So, within a few days, we will have the original Raduino code, Allard code, and my code. I can see some confusion taking place down the road when someone cpmplains: "My display is not working." or whatever.
Those with a "standard Raduino" are no doubt happy with it. Many others have upgraded to the robust feature set that Allard has in his code, and I doubt that many would want to give those up. Likewise, I don't want to give up the features my firmware supports. So, what the answer? I'm not sure. If everyone prefaces their support questions with: "I'm using the XXX firmware, Ver YYY...", perhaps everyone can coexist as we do now. I, for one, hope we can keep one group as we all share at least a core functionality.
Jack, W8TEE?
From: Pavel Milanes Costa <pavelmc@...>
To: [email protected]
Sent: Thursday, June 8, 2017 1:50 PM
Subject: Re: [BITX20] Struggling with tuning clicks and birdie sounds
Jack, That's for Allard's code.
I created a Si5351 lib a while ago that it's smaller (firware
& SRAM) than the Jason one
() and I was playing with
Allard code and it can cut 25% of the used firmware (I really
don't check how much SRAM but Allard got excited about the sram it
can free)
The problem was that I haven't a real raduino hardware, I
assembled all the hardware with a breadboard and an Arduino Pro
and the guide of the Raduino schematics + a old version of a
bitx20 board modded to 40m.
The patch works great here (homebre hardware) but don't works on
Allard tests (real raduino).
Last night I borrowed a real raduino + bit40v3 SMD from a ham
friend and beging testing it... first round result in no hardware
discrepances but it doesn't work (just like Allard noted to me,
the si5351 does not generate any freq.)
I have to go deeper, but it must wait a few days... this night I
go on vacation with the family until next week. 8-)
73 from (almost) the sunny Santa Luc¨ªa Beach on the North Coast
of Cuba.
El 08/06/17 a las 13:01, Jack Purdum
via Groups.Io escribi¨®:
OK...I misunderstood
when you said "no clicks". The statement "...the RF noise is
almost gone" makes more sense. I was wondering how you
could?completely removed it in code.
I have a battery
voltage monitor and I only refresh its field when the
battery voltage drops by 0.2V. This helps reduce the flicker
by only doing updates when it's needed. When you say you are
going to publish a patch that cuts the firmware code size by
25% plus "a lot" of SRAM, which firmware are you talking
about...the original Raduino code, or Allard's code?
Jack,
W8TEE
From: Pavel
Milanes Costa <pavelmc@...>
To:
[email protected]
Sent:
Thursday, June 8, 2017 12:33 PM
Subject:
Re: [BITX20] Struggling with tuning clicks and birdie
sounds
Simple:
Minimize
the LCD writes and you will be fine.
I
implemented a s-meter bar in a raduino like
project ()
and oh boy... it was a mess in the RF spectrum
INSIDE de receiver... I tracked the problem to LCD
writes...
I have to
minimize the lcd writes and make the code just
update the bar in the space it needs to (writing
or erasing simple bars, not just redraw it in full
every time) and the RF noise is almost gone...
Confession:
that's why I don't like the buffer concept of the
LCD in the raduino code, it write the entire line
EVERY time it needs to update a single digit. For
RF quietiness it's better to split it in zones and
only update the zone as it's needed. That also
helps, but can turn into bigger code.
Don't
worry abot used code, I'm about to push a patch to
cut 25% of the used firmware and a lot of RAM in
the raduino, I'm just valitating it.
73.
El 08/06/17
a las 09:12, Jack Purdum via Groups.Io escribi¨®:
Hi
Dimitar:
I saw your comment:?
(many features -
many clicks ..., simple code - no clicks).
and would like to you to explain how that
works to me in greater detail. I know that
many of us have experienced this problem and
would like to know how you discovered that
simplifying the code, while still maintaining
the features set, was done and how you
simplified the code.
Thanks!
Jack,
W8TEE
From:
Dimitar Pavlov via Groups.Io <lz1dpn@...>
To:
[email protected]
Sent:
Thursday, June 8, 2017 3:47 AM
Subject:
Re: [BITX20] Struggling with tuning
clicks and birdie sounds
Hi
all,
Before,
I have the same problem with
other transceivers, with various
DDS, and with LED/OLED displays.
The
tuning clicks, are the software
problem, connected to refreshing
frequency for display,
reading
frequency for the rotary encoder
and other refreshing frequencies
in arduino code (update
frequency to Si570/Si5351/AD9851
...).
To
resolve this problem need to
optimize code, and implement
some wait()/delay() functions.
(many
features - many clicks ...,
simple code - no clicks).
The
QRP transceiver is just QRP
transceiver - not need to make
coffee , and read news papper
...
Good
idea is to use separate power
source (2 or 3 pcs LM7812 / 7805
/ 7806 for DDS, receiver and
other ...
(Birdie sounds are
harmonics problem with DDS,
and it is not resolving
problem. Transceivers also
have birdies in other
frequencies,
but Your band plan
includes only one/two of
them.)
73!
On Thursday, June 8,
2017 12:42 AM, Dr Fred
Hambrecht <AAR4MI@...>
wrote:
I have
braided both the tuning
and volume control wires
with good results,
plus it
looks better.
v/r
Fred W4JLE
-----Original
Message-----
Sent:
Wednesday, June 7, 2017
07:39
Subject:
Re: [BITX20] Struggling
with tuning clicks and
birdie sounds
It seems
there is a huge
variability between
various BITX40 radios,
and
there are
various points where
improvements may help.
In my
particular case, I
achieved the greatest
tuning click reduction
just
by using
shielded wires to and
from the volume
potentiometer.
73 Allard
PE1NWL
|
I use needle nose and a soldering iron! Seen too many crimp failures over time.
Vince.
toggle quoted message
Show quoted text
On 06/08/2017 04:08 PM, Doug W wrote: I know I am asking for two things that are typically mutually exclusive,
but has anyone found a cheap and reliable crimp tool for the connectors?
--
Michigan VHF Corp.
|
Re: Struggling with tuning clicks and birdie sounds
Allard, I would like to take the opportunity to thank you for your
continuing evolution of the Bitx40 software. You have made yourself
indispensable in making this radio great! I received my Bitx40 box
maybe six months ago and it is still in there, as I watch your
software evolve...and if I had jumped in and made it and modified it
asap, many mods would already have been undone as I find your
programming getting better and better. There is some value in
procrastination after all... ...73, Rich WB2GXM
toggle quoted message
Show quoted text
On 6/8/17, Allard PE1NWL <pe1nwl@...> wrote: On Thu, Jun 8, 2017 at 07:21 am, Allard PE1NWL wrote:
Last night I found out that in my latest version raduino_v1.14 there is a
small bug that the display is unneccessarily updated even when the
frequency hasn't changed. This may cause a slight ticking noise.
?I have just uploaded a corrected version v.1.14.1 to Github at
( )
The only difference with the previous version 1.14 is that the display is
now only updated when there actually is a change.
This is the same behaviour as in all earlier versions, only in v1.14 there
was a small bug that it was updated every 50 ms even when there wasn't any
change. This caused some slight ticking even when you don't turn the tuning
pot.
This has now been corrected.
73 Allard PE1NWL
|
Re: Struggling with tuning clicks and birdie sounds
See inline El 08/06/17 a las 14:47, Allard PE1NWL escribi¨®: As Pavel mentioned I have indeed tried his modified library a few days ago
and the initial results were quite promising (except that tuning was not
yet working on a standard raduino, but I trust that Pavel will be able to
fix this).
If his library will be evaluated OK, then we need to open a discussion
whether or not we should switch to Pavel's library.
Potential pro's:
1. no tuning clicks
2. less memory space - more room for extra features 3. Lib's author is a bitx20 supporter and can tweak it for any of our (reasonable) weird features/whishes ;) Potential cons:
1. non standard library
2. certain unused features have been removed by Pavel, these are currently
not needed but might be needed for other (future) hacks or improvements. 3. Autor can be offline in some time periods (this is Cuba, internet is a luxury here) Anyway a good documentation of the library would be an absolute must. Documentation can be improved. I would recommend that the interface would be identical to the one as used
in the standard library, so that you can easily change libraries without
having to recode the sketch (existing sketches would be compatible to
either library). Good point, doable, but it "may" impose a code size penalty against actual code (final firmware may increase) spoiling the main feature (shinked size) I will try that and came back with some numbers/code to tell. 73.
73 Allard PE1NWL
On Thu, June 8, 2017 20:19, Pavel Milanes Costa wrote:
El 08/06/17 a las 13:01, Jack Purdum via Groups.Io escribi??:
When you say you are going to publish a patch that cuts the firmware
code size by 25% plus "a lot" of SRAM... You save 25% of the firmware and about 7% of sram, not much in deed, but
every byte counts: see the data below.
After the patch is applied (depending on Allard, it's his play) I will
try to apply some optimizations learned on another projects; It can
compplicate the code for non coders, but the important is that the code
works and with many coments to explain what every piece of code does I
think it's not a great problem.
I have other features such as CAT control (SRAM agressive), use of a
second Si5351 output as BFO to generate pure CW with and put ALWAYS the
VFO above the RF and get rid of a few birdies, amongs others.
All of these are part of other of my projects, one similar to the
raduino ()
_Raduino (allard 1.13):_
Sketch uses 26886 bytes (87%) of program storage space. Maximum is 30720
bytes. Global variables use 1521 bytes (74%) of dynamic memory, leaving
527 bytes
_Raduino (pavel's patch switch to onther si5351 Lib)_
Sketch uses 19878 bytes (61%) of program storage space. Maximum is 32256
bytes.
Global variables use 1377 bytes (67%) of dynamic memory, leaving 671
bytes for local variables. Maximum is 2048 bytes.
|
Allard PE1NWL