The LM78L09 and LM7809 have very different pinouts and if it smoked on power up it was wired wrong.

I cannot imagine a case where the VFO used more power than a 78L09 could handle.

Allison

The nano is the atmega168 or 328P(more often these days) what you get.
Its the middle child of the set:
? 32k of program space
? 2k of ram space
? 1k eeprom space.

Compared to cpus of my day that is a vast amount of space.
We got the full 5 pounds in the bag with a lot less.

The largest of the atmega family?the atmega2650 aka the arduino Mega2650:?
? ?256K of program space
? ?8k of ram space
? ?4k eprom space
? ?Small chip is the 64pin large is 100 pin? either has far more IO than the 328P.

That would be big enough.
If it can't do it then maybe revisiting system design is in order.? For an analog radio that
would cover a lot of ground and allow a very elaborate user interface.

This does not include refactoring the software for space.? It can be made smaller without giving up things.

I'm currently using a Arduino Pro Mini (328p cpu) with display and 5351 to test firmware ideas,

Allison
?

Hi Vince,

All you need is two 6-lead ribbon cables. 4 pins are not used, just check the schematics.

73, Frank
PA7F

开云体育

Thank you for your reply..

I finally decided to change the LM78L09 with LM7809.. I think it was because the LM78L09 couldn't take the high current.?

Would the BFO frequency shift the filter peak into the 750HZ? range?
I have an audio spectrum analyzer app on my android that uses the mic. sure would be something to investigate.
I have a source of inexpensive 12.000 Mhz crystals. (5 for? $1.00)? Perhaps a parallel filter network with the low slope variable would solve it..

Anyone have a link to a single row 16pin connector for make it yourself Ribbon cable?

Vince
n2aie

Ashhar,
I think it should be the standard.? It fits, and no issues installing.
more Plus than Minus.
1.? Download and run the Memory manager.? Provides user a different look at what is getting written to memory.
2.? All the added features not to mention CAT control at the bare minimum which might be attractive
3.? options for displays
4.? WSPR?
on an on...
de
N2AIE
Vince

Good morning,

Though not specifically uBitx related, the RTTY timing issues has been discussed ad naseum on the RTTY group which has recently rehomed to (RTTY) groups.io and IIRC the issues with timing are based largely in windows as it is not a real time OS. If you are like me, these discussions are, IMHO, very interesting and can be a time sink.

Arduino can and does a very nice job of handling RTTY with Andy, K0SM work creating TinyFSK, see??which incidentally also functions as a CW keyer ala hat tip to Anthony, K3NG and his wonderful arduino CW keyer. Anthony maintains a group (radioartisan) on groups.io. I do use David, G3YYD wonderful 2Tone software which has implementations for tinyFSK as your transmit source built in; see ?In a nutshell, I could not live without 2Tone when I play RTTY as it is truly fantastic and I routinely run several 2Tone receive windows along side Alex, VE3NEA Gritty software (print only - no xmit); see?

The key is ensuring you grab the correct timing packages from Paul over at PJRC (Teensy), see?

All my very best,

Mike N4EEV

Back in the 70's, some CB radio manufacturers used a diode in series with the power and it worked well. A couple brands used a bridge rectifier setup in the input power that way it didn't matter which way you connected to power.
Roxie -- K1AUS

Tim

I disagree.

For example, if the standard code has an iambic keyer but I have run out of flash
trying to implement an SWR indicator, then it would be handy to free up the flash
used by the keyer by changing a #define from true to false with something like this:
#define? IAMBIC_KEYER? ?0

That standard code need not be exhaustively tested for all permutations of the build.
Just that the standard build works well enough to be usable.

The #define's for conditional compilation may or may not work, if they don't work
they are at least a good indication of the original programmer's understanding of
how he thought it should work.

And if I adjust the standard code through a modification of the #define's or?
some other hack to better suit my needs and it does not work for me,
then that is clearly my problem to debug.

Jerry

With all respect, do you understand Ian's code well enough to add
functionality to it? Or is it just better from an operational
standpoint?

tim ab0wr

On Tue, 15 May 2018 07:23:14 -0700
docame12@... wrote:

As a newcomer to Arduino, I really appreciate of the benefits of Dr.
Lee's implementation versus the stock standard currently shipping.

Thanks,
DaveWS1ETI

It was 1967-68.. Detroit when I started college, President of K8EEH Henry Ford College ARC.. Somewhere in Detroit there was a Marine, that had been hit while on the Korean DMZ and was paralyzed- lost the ability to speak. He had the ability to send CW with only his thumb. Hams in Detroit built a CW to RTTY converter and supplied a Teletype in his bedroom so his mother, his care giver (and others), would not have to learn morse code.

CW was extensively used in Alcatraz as depicted in the Movie "Birdman of Alcatraz"? I just saw an article out of NERDS (New England Radio Discussion Society) about the Navy using shipboard flasher signaling lights with an automated Text to CW flash converter. No need to learn CW.

Hi Richard,

If you mean a second LCD or maybe a little OLED, yes, It can be done ( I did ) but you need to write it in to the software and include whatever library that you would need for an OLED for instance. You just write in a separate routine for whatever you want to display. Not a trivial matter if you wish to use? any of C++ based sketches. 73, Don

Jack,

Respectfully, you missed my point. I probably wasn't clear. I didn't
mean a "coding" standard. I meant a standard software load with defined
functionality.

Trying to add functionality that others might want to use, in an
environment of multiple conditional compiles, becomes a true nightmare
of regression testing to insure the added functionality works with all
combinations of the conditional compiles.

Not doing such regression testing and throwing a software modification
out into the wild means many users are going to find that their
individual software load no longer works as intended if they try to use
the software modification.

For instance, your mention of deleting keyer code if you never use CW.
If I develop functionality like a "Tune" option that requires the CW
transmit module and some kind of a CW key to transmit a carrier, it
won't work with someone that has deleted the keyer code using their
conditional compile. If they add my functionality what's the first
thing they are going to see happen? It won't work. Who then gets to
figure out why and then who gets to fix it?

tim ab0wr

On Tue, 15 May 2018 13:25:23 +0000 (UTC)
"Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

I agree with Ron, here. Tim's statement:

????It's important to have a *standard* to write to.

would be nice, but as we all know, there is a difference between
coding style and functionality. Cut-and-paste code is also nice to
have, but any code may be useful if you can read and understand it.
To me, the litmus test of good code is code that can be read and
understood easily. When that's true, it becomes much easier to adapt
it to your needs. Simple things like using #define's instead of
"magic numbers" make it easier to read and adapt code. (If the IDE
had a symbolic debugger, I might use constants, although symbolic
constants are typeless and that can be a huge benefit in writing
reusable code.) Writing "clever" code is rarely a benefit. Which
would you rather read:

?? a = b >> 1;

or

?? averageVoltage = baseVoltage / 2;?? // Voltage divider derives
average voltage that's applied to pin AVERAGEVOLTAGE

Perhaps the only real reason the first version might make sense is to
cause some speed gain in the executed code, or perhaps save some
memory. Even that, however, often makes no sense because the Gnu
compiler is quite good at optimizations. Indeed, my guess is that the
two forms above generate exactly the same code. You can examine the
*.lst file to get a feel for the final answer.

The final step before making it available to the public is to ask
yourself: What can I do to make it easier to read and understand this
code? If you cannot find changes that enhance readability, it's read
for prime time. Even then, readers will have difference preferences
on the way they would write the code...that's to be expected.
However, the fact they have preferences means they can read,
understand, and hopefully use the code.

For reasons most can guess, I have not read Ian's code recently, but
I'm sure it's readable. The fact that Farhan has even suggested using
it as the standard means he's happy with it. If it's possible to
conditionally compile the code (e.g., why have a keyer if you know
you'll never use CW, leaving some room for additions you know you
want), it seems to me to be a moot question.

And to those who argue: "But conditional compiles means the users
have to be able to change the code!" Yeah, so what? If you can't
change the code, you still have several options: 1) accept the radio
"as is", 2) learn enough programming to make the changes you want, or
3) pay a programmer to implement the changes you want. Trying to get
a boo-hoo from me for people who don't want to invest a weekend in
learning how to make such changes is pretty much going to fall on a
deaf set of ears. Besides, this kind of programming is going to get
more important down the road, not less. May as well bite the bullet
and jump on board...you may even find you like it!

Jack, W8TEE



On Monday, May 14, 2018, 11:53:47 PM EDT, W2CTX
<w2ctx@...> wrote:

Tim





?? When I write software I don't have reuse as part of my mindset.? I
try to make something work that is


broken or develop something new that does not exist.? Once it is
tested it is given to the community to


use.





?So if I don't care if others use my code how does that advance the
radio?? Well one case comes to mind in that


my keyer code had iambic A/B working correctly.? After I published
the firmware I believe Ian looked at it.? Now


he could not cut-n-paste my code into his firmware because he used
different timing and different hardware pins.


As he stated in his description of his keyer routine, he looked at my
logic and? adapted my code into his.


And as all good programmers do gave me acknowledgement in his header
of his keyer module.





So you don't have to create code that can be cut-n-paste to be
useful.





rOn


On May 14, 2018 at 10:32 PM Tim Gorman wrote:


John,

If I am writing a function that others might want to use, how do I
know which analog input to look at for a trigger by the CW key?

Does my function need to look at both A3 and A6 just in case? Or do I
use one or the other and let the user worry about fiddling with my
code to make it work?

It's important to have a *standard* to write to.

tim ab0wr



On Mon, 14 May 2018 13:54:44 -0700
"John" wrote:
I disagree that the original software is a good starting point for
building on as its tuning and keying section need work.

I think the uBitx should be shipped with a software that best
promotes it's capabilities. That way the user can enjoy it fully
without having to go through an upgrade process that he may not be
willing to go through.

Making room for later software changes is easy if, as said above, the
software is segmented and shows the "memory cost" of each option.

As an example below is the start of the my ubitx_20.ino file, based
on Ian's 1.061 version.

It is easy to make room by commenting out options to insert one's own
code if desired, or simply enable "extra features".
//================== Compile options for adding/removing features and
saving memory =====================
//When there are no hardware modifications (i.e. wired as per the
HfSignals web-site) // If UNdefined, or commented OUT, assumes that
the CW key is connected to the PTT input (A3) to free-up A6 for //
the handsfree option here. (note that A6 could also be used for SWR
or supply voltage monitoring). No memory impact.

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#49147): /g/BITX20/message/49147
View All Messages In Topic (64):
/g/BITX20/topic/19183012 Mute This Topic:
/mt/19183012/141851 New Topic:
/g/BITX20/post -=-=-
The original BITX
BITX40 by HFSignals
uBITX by HFSignals
BITX Store by Sunil
BITX Web Site of Mike ZL1AXG
/g/BITX20/wiki/home Wiki
-=-=-
Change Your Subscription: /g/BITX20/editsub/141851
Group Home: /g/BITX20
Contact Group Owner: [email protected]
Terms of Service: /static/tos
Unsubscribe: /g/BITX20/leave/defanged<hr
style="height: 0; border: 0; border-top: 1px solid #aaa; margin: 8px
0;">

开云体育

Tim, and all,

Let me preface this with a statement of gratitude to Farhan for supplying such a
useful, functional, and affordable rig to all. It has enabled many to get into ham
radio who would otherwise not have an opportunity, and it has put the fun back into
ham radio for many others. I know Farhan and his crew have put an enormous amount
of work into the endeavor.

Furthermore, Farhan has generously provided useful firmware, with source code, based
on the GNU license. Again, I am grateful for that. He has indicated that he 'launched'
the software with no guarantee, and no obligation to maintain it. Please understand
my following comments are not a criticism of any of his efforts in any way.

I believe the question of adopting KD8CEC firmware as the 'base load' should
be addressed from the viewpoint of external functionality, rather than software
structure.

When I use the original firmware, I note the unreliable CW keying, erratic 'adaptive'
tuning, and lack? of CAT interface. Again, not a criticism in any way.

The KD8CEC firmware resolves these issues. The exception to that is 'adaptive' tuning,
which is tuning is difficult or impossible to implement using the Arduino runtime library,
as it is not a real-time operating system. Ian, KD8CEC, addresses that issue in his later
releases by providing the ability to have four additional front-panel buttons with a minor
hardware mod of adding a few resistors. One of the buttons controls tuning rate without
the need to navigate menus.

It is likely that the vast majority of uBITX users are not eager to jump into coding changes,
with the associated nuances. I understand that, and in the 'voting' process about base
load firmware, I believe it is important to keep that in mind.

I suggest separating the 'which base load' issue from the 'software structure and portability'
issues. The user community is probably more affected by external functionality than software
compatibility. See Jack, W8TEE comments posted today, which I support in concept.

----break, to talk about software structure---

Tim, thank you for emphasizing John, VK2ETA 5/14 post, which I re-read. John put a lot of work
into that, and I like the direction he is headed in. I also suggest re-reading his 5/12 post.

---break, for wrapup---

I really appreciate the contributions to the uBITX community from all over the world.

Tim, as an aside note, please be aware my name is spelled "Rod", not "Ron". An easy
typo blip.

Best to All,

Rod KM6SN

Do you mean a 4-line lcd display?

If so you have to have a software load set up to use a 4-line display.
Have you checked to see if that is the case for your software?

tim ab0wr

On Tue, 15 May 2018 07:17:40 -0700
"Richard E Neese" <kb3vgw@...> wrote:

with the wa6isp and other replacement boards you have i2c but I cant
get multi screens working.. anyone have a howto for multi screen

That's an easy one.
If it's your software then *you* are charged with doing the troubleshooting.

Jerry,

Ian's code may be easy for you to read and understand. That is most
definitely *not* the case for many of us.

Any code that can be changed on the fly by defining options to be
included or excluded probably can't be considered "stable". It becomes
a minefield for others trying to add their functionality. Regression
testing to insure the software still works as intended becomes a
nightmare of trying all the numerous options together in a multiplicity
of option combinations.

This is not meant as disparagement Ian's software. It has a lot of
functionality that many people have asked for. Many people are using
it. There is a good reason for that.

But that doesn't mean it is suitable as the base load for all future
ubitx units.

Does Ashar have the resources to do a full regression testing of Ian's
software as it stands today when changes are made to the ubitx hardware?

tim ab0wr

On Mon, 14 May 2018 22:42:01 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

I haven't looked at Ian's code yet.
But suspect it is plenty readable.
And if it's readable, there's a bunch of people here that could
support it. And I doubt Farhan would ship with it unless he was
confident he understood it and could make his own mods and fixes.

Farhan would be shipping something that is hopefully stable.
And if Ian is so inclined, he will continue adjusting the code to
suit his whims. Now I'm confused, was there somehow a problem with
this??

Generally, a few hundred lines of C code is fairly easy to figure out.
Though there are exceptions:
? ?
? ??

Jerry, KE7ER

On Mon, May 14, 2018 at 09:24 pm, W2CTX wrote:

If CEC firmware is selected to be the delivered "base" then you
must think about the following two implications:

1. Is Ian willing to support the "base" in the future w.r.t. uBITX
production hardware changes?
As well as answering all the "newbie" questions about all the
options everyone is eluding to?

2. If Ian does not support the "base", then customers will be
confused by having CEC as "base" and IAN still supplying CEC
firmware that is different.

As a newcomer to Arduino, I really appreciate of the benefits of Dr. Lee's implementation versus the stock standard currently shipping.

Thanks,
DaveWS1ETI