¿ªÔÆÌåÓý

Date

Re: CW Mistakes

 

Yes, indeed! When you undefine DEBUG, that code disappears, and no longer
takes up any space.

The technique is useful for other things too. When I was messing with the
tuning, I enclosed each of my changes in
#ifdef JERRY_TRYIT
#endif

That way I could search for my changes, & turn them on & off.

- jerry KF6VB


Re: CW Mistakes

 

On 2021-05-16 07:33, Evan Hand wrote:
Arv,
Here is a link to a company that produces the hardware and software to
replace the v6 Raduino with one that is designed for the Teensy 4.1.
*** I have it! Running right now. The Teensy is orders of magnitude more powerful than the Nano: 600MHz clock, a floating point unit( could do DSP stuff! ) , 8 megabytes of flash, 1 megabyte of RAM, buckets & barrels of I/O, and built in Ethernet!

I did have to get a new display. With the original one, the clone Raduino made unacceptable tuning ticks. Replacement with a "Hiletgo" display from
Amazon cured that problem. So now I have a spare display... More about that later.

Only thing is... the Teensy is a $30 processor - as opposed to the nano which costs IIRC $3.

- Jerry KF6VB


Re: CW Mistakes

Jack, W8TEE
 

No problem. I just didn't want readers to try and use a simple if block for the scaffolding.

As to the name, my Dad was named John and I was named Jack (not John). He was a tall man for the times (6'5") and his friends called him Jack. Things changed when I got old enough to use the phone. The names morphed to "Big Jack" and "Little Jack".

Jack, W8TEE

On Sunday, May 16, 2021, 12:09:06 PM EDT, Arv Evans <arvid.evans@...> wrote:


Jack (I got the name right this time!)

Yes, I did not describe it very well.? Thanks for the clarification.?

Arv
_._


On Sun, May 16, 2021 at 9:46 AM Jack, W8TEE via <jjpurdum=[email protected]> wrote:
Arv:

An if (DEBUG statement block will not cause scaffolding code to be excluded from a compile. I think what you mean is something like:

#define DEBUG????????????????????????// Place near the start of the code...
// ...a bunch of program code...

#ifdef DEBUG
Serial.print("val = ");
Serial.println(val);
#endif
// ...more program code...

Now, when you comment out the #define preprocessor directive, that scaffolding code block no longer appears in the compiled code. Uncomment the directive and it returns back into the compiled code. This makes for a great way to "toggle" debugging code into and out of a program with a single edit line, saving a lot of retyping.

Jack, W8TEE

On Sunday, May 16, 2021, 11:33:09 AM EDT, Arv Evans <arvid.evans@...> wrote:


Jerry

I strongly agree with you.? Code organization and functions that contain blocking
code are important and a PITA.? At present I am working on code for some test equipment (Arduino based) which involves a main loop that has some serious timing
constraints.? Slow operation in my initial code was fixed when I converted blocking routines to non-blocking and then spaced the slower sections equally around the
loop, taking care to duplicate critical routines so that they appear multiple times in
a single pass around the loop.

When I added timing discovery points it revealed what was slowing things down
and indicated just where things needed to be moved, deleted, or changed.? In the
process of timing discovery I almost made a real-time version of my code, but
not quite.? John helped me with scaffolding which allowed my DEBUG routines
to become "if DEBUG" so that a compile could include or not include the DEBUG
parts.? Thanks John.? That was a big help.

Some of the C++ based library calls in the Arduino IDE appear to be poorly
constructed for my particular needs.? This caused me to rewrite a few of these
calls.? I think the lesson here is that the Arduino libraries in the IDE should not
be taken as the sacred last word in how to do things.? If you need a special
function call, do not be afraid to write it yourself.? These type things can then
be included in your code and do not need to be formalized and stored as
a library.

Arv
_._


On Sun, May 16, 2021 at 8:23 AM Jerry Gaffke via <jgaffke=[email protected]> wrote:
I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


--
Jack, W8TEE


--
Jack, W8TEE


Re: CW Mistakes

 

Jack (I got the name right this time!)

Yes, I did not describe it very well.? Thanks for the clarification.?

Arv
_._


On Sun, May 16, 2021 at 9:46 AM Jack, W8TEE via <jjpurdum=[email protected]> wrote:
Arv:

An if (DEBUG statement block will not cause scaffolding code to be excluded from a compile. I think what you mean is something like:

#define DEBUG????????????????????????// Place near the start of the code...
// ...a bunch of program code...

#ifdef DEBUG
Serial.print("val = ");
Serial.println(val);
#endif
// ...more program code...

Now, when you comment out the #define preprocessor directive, that scaffolding code block no longer appears in the compiled code. Uncomment the directive and it returns back into the compiled code. This makes for a great way to "toggle" debugging code into and out of a program with a single edit line, saving a lot of retyping.

Jack, W8TEE

On Sunday, May 16, 2021, 11:33:09 AM EDT, Arv Evans <arvid.evans@...> wrote:


Jerry

I strongly agree with you.? Code organization and functions that contain blocking
code are important and a PITA.? At present I am working on code for some test equipment (Arduino based) which involves a main loop that has some serious timing
constraints.? Slow operation in my initial code was fixed when I converted blocking routines to non-blocking and then spaced the slower sections equally around the
loop, taking care to duplicate critical routines so that they appear multiple times in
a single pass around the loop.

When I added timing discovery points it revealed what was slowing things down
and indicated just where things needed to be moved, deleted, or changed.? In the
process of timing discovery I almost made a real-time version of my code, but
not quite.? John helped me with scaffolding which allowed my DEBUG routines
to become "if DEBUG" so that a compile could include or not include the DEBUG
parts.? Thanks John.? That was a big help.

Some of the C++ based library calls in the Arduino IDE appear to be poorly
constructed for my particular needs.? This caused me to rewrite a few of these
calls.? I think the lesson here is that the Arduino libraries in the IDE should not
be taken as the sacred last word in how to do things.? If you need a special
function call, do not be afraid to write it yourself.? These type things can then
be included in your code and do not need to be formalized and stored as
a library.

Arv
_._


On Sun, May 16, 2021 at 8:23 AM Jerry Gaffke via <jgaffke=[email protected]> wrote:
I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


--
Jack, W8TEE


Re: CW Mistakes

 

Hi Evan,

I was sending at 18WPM.

- Jerry

On 2021-05-16 00:10, Evan Hand wrote:
On Sat, May 15, 2021 at 12:40 PM, jerry@... wrote:

It seems that - just occasionally - when you hit the "dit" paddle,
the thing will go
"dit dah", instead of just "dit".
Jerry KF6VB,
What is your WPM setting when doing the tests? Does the error rate
change with the WPM speed setting?
The reason I am asking is to see if it is related to the increased
load on the Nano to deal with the v6 display. I have not noticed the
problem on any of the pre v6 that I have. I will test my v6 to see if
it has the issue if I set it higher than 12 WPM (I do not know the
code well enough to copy or send at any rate higher than that).
73
Evan
AC9TU
Links:
------
[1] /g/BITX20/message/88381
[2] /mt/82850528/243852
[3] /g/BITX20/post
[4] /g/BITX20/editsub/243852
[5] /g/BITX20/leave/10189903/243852/952924773/xyzzy


Re: CW Mistakes

 

Jack and Jerry

Please excuse my renaming Jack to John.? I cannot even blame the
spell checker for that error.? It was just my fat fingers that did it.?

Jack helped me with scaffolding which allowed my DEBUG
routines to become "if DEBUG" so that a compile could include
or not include the DEBUG parts.?
Thanks Jack.? That was a big help.

Like Jack said, when the hourglass of life is almost out of sand, things do
get interesting! ??

Arv
_._


On Sun, May 16, 2021 at 9:33 AM Arv Evans via <arvid.evans=[email protected]> wrote:
Jerry

I strongly agree with you.? Code organization and functions that contain blocking
code are important and a PITA.? At present I am working on code for some test equipment (Arduino based) which involves a main loop that has some serious timing
constraints.? Slow operation in my initial code was fixed when I converted blocking routines to non-blocking and then spaced the slower sections equally around the
loop, taking care to duplicate critical routines so that they appear multiple times in
a single pass around the loop.

When I added timing discovery points it revealed what was slowing things down
and indicated just where things needed to be moved, deleted, or changed.? In the
process of timing discovery I almost made a real-time version of my code, but
not quite.? John helped me with scaffolding which allowed my DEBUG routines
to become "if DEBUG" so that a compile could include or not include the DEBUG
parts.? Thanks John.? That was a big help.

Some of the C++ based library calls in the Arduino IDE appear to be poorly
constructed for my particular needs.? This caused me to rewrite a few of these
calls.? I think the lesson here is that the Arduino libraries in the IDE should not
be taken as the sacred last word in how to do things.? If you need a special
function call, do not be afraid to write it yourself.? These type things can then
be included in your code and do not need to be formalized and stored as
a library.

Arv
_._


On Sun, May 16, 2021 at 8:23 AM Jerry Gaffke via <jgaffke=[email protected]> wrote:
I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


Re: CW Mistakes

 

On 2021-05-15 20:30, Jerry Gaffke via groups.io wrote:
Yes, using various voltage levels into an ADC was done
because of no remaining pins on the Nano.
No longer an issue for me, because I just got the TSW Teensy4.1
card working. It uses a separate dedicated 3-pin header for CW input.

- Jerry


Re: CW Mistakes

 

Evan

TSW is an interesting place to go for ideas and for some interesting boards.
Their Teensy daughter card for the Arduino may be a solution for retrofitting
existing uBITX systems, but I need to look a bit closer to see if it solves the
problem regarding not enough digital ports and the related problem of CW
dits using an analog port.

One potential software method to solve the dit problem without new hardware
is to use existing digital ports for multiple purposes.? For instance, if we have
a data and clock port for I2C, these ports could possibly be redefined at
appropriate times as inputs for CW dit and dot keying and then redefined for
I2C when needed to talk to a peripheral.? There are other digital ports that
might be used in a similar manner.? I have not yet thought this through very
well, so that may change when I have a better idea what I'm doing.? 8-)

Going off in a different direction......
The use of analog voltages for CW inputs has curious voltage windows
(thresholds) for dit versus dah.? Maybe just modifying the voltage thresholds
for each window, or inserting a dead-zone between dit and dah windows,
could be arranged to minimize misinterpretation of CW inputs?? This
involves determining whether the voltage detection or timing for when the
voltages are being read is related to the actual problem.

Arv
_._


On Sun, May 16, 2021 at 8:33 AM Evan Hand <elhandjr@...> wrote:

Arv,
Here is a link to a company that produces the hardware and software to replace the v6 Raduino with one that is designed for the Teensy 4.1.?



They sold an adapter board for the pre v6 Raduino, however that has been discontinued. ??

The cost seems reasonable, considering it is not in high demand and the low volume of boards sold (assumed).? A good choice for someone who wants to experiment with things like DSP or other SW based additions to the uBITX.? The supplied code is open source and can be worked with the Arduino IDE.


73
Evan
AC9TU


Re: CW Mistakes

Jack, W8TEE
 

Arv:

An if (DEBUG statement block will not cause scaffolding code to be excluded from a compile. I think what you mean is something like:

#define DEBUG????????????????????????// Place near the start of the code...
// ...a bunch of program code...

#ifdef DEBUG
Serial.print("val = ");
Serial.println(val);
#endif
// ...more program code...

Now, when you comment out the #define preprocessor directive, that scaffolding code block no longer appears in the compiled code. Uncomment the directive and it returns back into the compiled code. This makes for a great way to "toggle" debugging code into and out of a program with a single edit line, saving a lot of retyping.

Jack, W8TEE

On Sunday, May 16, 2021, 11:33:09 AM EDT, Arv Evans <arvid.evans@...> wrote:


Jerry

I strongly agree with you.? Code organization and functions that contain blocking
code are important and a PITA.? At present I am working on code for some test equipment (Arduino based) which involves a main loop that has some serious timing
constraints.? Slow operation in my initial code was fixed when I converted blocking routines to non-blocking and then spaced the slower sections equally around the
loop, taking care to duplicate critical routines so that they appear multiple times in
a single pass around the loop.

When I added timing discovery points it revealed what was slowing things down
and indicated just where things needed to be moved, deleted, or changed.? In the
process of timing discovery I almost made a real-time version of my code, but
not quite.? John helped me with scaffolding which allowed my DEBUG routines
to become "if DEBUG" so that a compile could include or not include the DEBUG
parts.? Thanks John.? That was a big help.

Some of the C++ based library calls in the Arduino IDE appear to be poorly
constructed for my particular needs.? This caused me to rewrite a few of these
calls.? I think the lesson here is that the Arduino libraries in the IDE should not
be taken as the sacred last word in how to do things.? If you need a special
function call, do not be afraid to write it yourself.? These type things can then
be included in your code and do not need to be formalized and stored as
a library.

Arv
_._


On Sun, May 16, 2021 at 8:23 AM Jerry Gaffke via <jgaffke=[email protected]> wrote:
I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


--
Jack, W8TEE


Re: CNC encoder for ubitx

 

Dennis, thanks for the sketch to use the encoder. In the library, RotoryEncoder, I found a bit of info on these 100ppr encoders available from Matthias, the Arthur. It is very interesting how he took the 4 A-B transitions of one click to go CW or CCW.? I only wish I understood it all.

Now to figure out what to actually do with this thing.?
Barry
K3bo


On Sun, May 16, 2021, 8:07 AM Dennis Zabawa <kg4rul@...> wrote:
If we were all the same, would it not be a VERY?dull world??


Re: CW Mistakes

 

Jerry

I strongly agree with you.? Code organization and functions that contain blocking
code are important and a PITA.? At present I am working on code for some test equipment (Arduino based) which involves a main loop that has some serious timing
constraints.? Slow operation in my initial code was fixed when I converted blocking routines to non-blocking and then spaced the slower sections equally around the
loop, taking care to duplicate critical routines so that they appear multiple times in
a single pass around the loop.

When I added timing discovery points it revealed what was slowing things down
and indicated just where things needed to be moved, deleted, or changed.? In the
process of timing discovery I almost made a real-time version of my code, but
not quite.? John helped me with scaffolding which allowed my DEBUG routines
to become "if DEBUG" so that a compile could include or not include the DEBUG
parts.? Thanks John.? That was a big help.

Some of the C++ based library calls in the Arduino IDE appear to be poorly
constructed for my particular needs.? This caused me to rewrite a few of these
calls.? I think the lesson here is that the Arduino libraries in the IDE should not
be taken as the sacred last word in how to do things.? If you need a special
function call, do not be afraid to write it yourself.? These type things can then
be included in your code and do not need to be formalized and stored as
a library.

Arv
_._


On Sun, May 16, 2021 at 8:23 AM Jerry Gaffke via <jgaffke=[email protected]> wrote:
I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


Re: CW Mistakes

 

Jim,

Sorry that I miss represented the original Raduino adapter. I definitely want one of those to put in one of my v4 uBITX. ?I will go back to the site and order one.?

Thank you for the clarification.?

Good products for all reading this.?

73Evan
AC9TU


Re: CW Mistakes

 

OOPS sorry Evan, The pre V6 stuff has run out of stock and not available right now, but has not been discontinued.? Major problem is with the Si5351a VFO/Clock chip.? I have around 100 on hand and now have located a stock of the Chinese version called the MS5351M which is physically and electrically the equivalent.

I found a special zero-insertion-force socket for the SOP-10 (format of the Si/MS 5351 chips) and had N5IB do a PCB design for a test set.? This test set is now operational here and I've found no significant differences in the Si and MS 5351 chips either electrically or mechanically so I'm glad I took a chance on the Chinese chips and ordered some.? It also appears that Mouser has a few hundred Teensy 4.1 MPU's in stock there, so nothing at TSW using it has been discontinued.? We did, however reduce the price slightly switched from us paying the postage to the customer paying the postage to compensate for variations in postal prices depending on destination.

Jim, W0EB
TSW Project Coordinator

------ Original Message ------
From: "Evan Hand" <elhandjr@...>
Sent: 5/16/2021 9:33:15 AM
Subject: Re: [BITX20] CW Mistakes

Arv,
Here is a link to a company that produces the hardware and software to replace the v6 Raduino with one that is designed for the Teensy 4.1.?



They sold an adapter board for the pre v6 Raduino, however that has been discontinued. ??

The cost seems reasonable, considering it is not in high demand and the low volume of boards sold (assumed). ?A good choice for someone who wants to experiment with things like DSP or other SW based additions to the uBITX. ?The supplied code is open source and can be worked with the Arduino IDE.


73
Evan
AC9TU


Re: CW Mistakes

 

Excuse me Evan!? That adapter board used the Teensy 4.0 (smaller MPU unit) and it has NOT been discontinued.? Don't post things you know nothing about please.

Jim, W0EB

------ Original Message ------
From: "Evan Hand" <elhandjr@...>
Sent: 5/16/2021 9:33:15 AM
Subject: Re: [BITX20] CW Mistakes

Arv,
Here is a link to a company that produces the hardware and software to replace the v6 Raduino with one that is designed for the Teensy 4.1.?



They sold an adapter board for the pre v6 Raduino, however that has been discontinued. ??

The cost seems reasonable, considering it is not in high demand and the low volume of boards sold (assumed). ?A good choice for someone who wants to experiment with things like DSP or other SW based additions to the uBITX. ?The supplied code is open source and can be worked with the Arduino IDE.


73
Evan
AC9TU


Re: CW Mistakes

 

Arv,
Here is a link to a company that produces the hardware and software to replace the v6 Raduino with one that is designed for the Teensy 4.1.?



They sold an adapter board for the pre v6 Raduino, however that has been discontinued. ??

The cost seems reasonable, considering it is not in high demand and the low volume of boards sold (assumed). ?A good choice for someone who wants to experiment with things like DSP or other SW based additions to the uBITX. ?The supplied code is open source and can be worked with the Arduino IDE.


73
Evan
AC9TU


Re: CW Mistakes

 

I had that wrong.??
PARIS is 50 "dot elements", the spaces between the dots count as separate dot elements.
So 20wpm is a rising or falling edge every 1/16.66 = 60 milliseconds, not 30.

With properly organized code, a Nano should have no trouble keeping up.
However, reliably catching that first dot when the processor might be busy doing other stuff
probably does require an interrupt driven digital pin for the key.

Jerry, KE7ER


On Sun, May 16, 2021 at 06:25 AM, Jerry Gaffke wrote:
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.


Re: CW Mistakes

Jack, W8TEE
 

Jerry:

The key to a solution is the last sentence: The feature set of the ?BITX has outgrown the processor and it's time to leave the ATMega328 behind. While I have my own preferences, I think we should agree that it would be worthwhile to live within the Arduino IDE. That would ease the transition from the 328 to...whatever. As it is, the IDE is free, easy to use, and has enough features to make it useful. Even more important, there is an extremely robust set of libraries available and just under a bazillion lines of Open Source code free for the taking. Software patches already exist for the STM32, ESP32, and Teensy family of processors, with the Raspberry Pi Pico on the horizon. The obvious hole in the IDE is the lack of a source code debugger. The good news is that the 2.0 Beta IDE does have a debugger. The bad news is that, at the present time, the Beta has very limited support (i.e., , , , , ). I think that will change, but have no idea the time frame that it will take.

There is not going to be a "vote" on which controller will replace the 328 in the ?BITX. I would love to hear Farhan's feelings on this. In the absence of that, I expect to see the creative people on this Forum take the reins and start making the mods themselves. I just wish I had another 30 years of sand left in the hour glass to see where all of this goes!

Jack, W8TEE

On Sunday, May 16, 2021, 9:25:27 AM EDT, Jerry Gaffke via groups.io <jgaffke@...> wrote:


Absolutely right, the Nano is overloaded, and i2c writes to a display slow it down further.

However, sending CW is reasonably slow, even for a Nano clocked at 16mhz.
Lets assume we are shooting for good operation at 20 wpm.
The word "PARIS" including inter-character and inter-word spacing has the equivalent of 50 dot elements,
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.
If you are updating a slow display while in the midst of sending CW, you are doing it wrong.
And if you want to catch the very first dot of a transmission on an overloaded processor,
it had best be keyed through a digital pin that generates a high priority interrupt.

I've used an i2c 16x2 LCD on my uBitx v3, but would not recommend using i2c on a larger display.
My stripped down code only does straight key mode as well, mostly because I wanted it as simple as possible.
Any keyer must be external.
A faster processor with more pins and more memory would make many things a lot easier.

Jerry, KE7ER



On Sun, May 16, 2021 at 05:34 AM, Bill Cromwell wrote:
Hi,

I went back to using an external keyer just because of the clumsy operation of the built-in keyer in my V3. The uBitX then sees straight key operation regardless of what is outside the radio or what I am doing at my fingertips:)


The lil processor in the radio is overloaded to my way of thinking. It is 'almost' good enough'. The suggestion of using a serial display will slow down the display and there have already been complaints about that. I have some serial displays and I may try one to see if it is tolerable. Some CW ops have reported improvements by tweaking the resistor values for the analog keyer pin. A search of messages or the files section should turn up that approach. Use of a processor with more resources sounds like a better idea. It will cost a little more, of course. "Cost creep" is a real thing.

I have a much different approach to the entire enterprise and *if* I get it completed and *if* it works I will publish the results. My silly ideas are to rearrange the existing blocks with other existing blocks. CW operation should not be an afterthought. Much of the rig in my mind is borrowed from the uBitX design. Some of those blocks are inspired by 'other' radios. No, Kentucky, not vacuum tubes <sly grin>.

73,

Bill KU8H

bark less - wag more

--
Jack, W8TEE


Re: CW Mistakes

 

Part of the CW problem is that there are already many uBITX out there
in use which could use an upgrade.? This involves replacing the whole
Raduino if we want to upgrade to a larger processor.? Ideally we could
come up with a change to existing hardware and/or software that would
fix the dit problem without a large cost and with the existing Arduino.

Arv
_._


On Sat, May 15, 2021 at 9:30 PM Jerry Gaffke via <jgaffke=[email protected]> wrote:
Yes, using various voltage levels into an ADC was done
because of no remaining pins on the Nano.

Best to choose a processor with enough pins for the job
such as the RPi-Pico that Farhan has been looking at.

I believe the ATMega328P can sample the ADC at around 10khz.
Arv's suggestion of reading twice might solve the immediate problem for CW ops.

Could program the two UART pins RX and TX for use as digital inputs
to inspect the dot and dash paddle switches.? Going into CW mode would be handled
by a menu option, and would disallow CAT communications with a USB host.?
The analog pin could still be used for hand keys.?

Or go to an i2c LCD display, that frees up plenty of pins.

Jerry, KE7ER


On Sat, May 15, 2021 at 04:23 PM, Arv Evans wrote:
I am not a "CW Op"...barely able to walk and talk sometimes.? 8-)
?
I must admit that using voltage based switching via an ADC would
not be my first choice for generating CW.? The ADC in an AVR328
has "settling time" in its operation.? For my own use I usually read-
twice to ensure that the voltage reported is closer to reality.
?
The idea that the ADC may be reading CW state during transition
times sounds like a good one.? Possibly just making a slight change
to the threshold voltages between dit and dah could tame the
problem?
?
My guess is that in the initial software there was a shortage of digital
pins that could have been used to initiate a Dit or Dah.? Farhan may
be able to clarify that guess.?
?
There are several ways to "multiplex" functionality of digital pins on
the Arduino, so this could be something to look into if rewriting parts
of the Raduino software.? Back when the uBITX software was being
designed we did not have enough AVR328 experience to reuse
digital inputs for multiple purposes.?
?
Arv? K7HKL


Re: CW Mistakes

 

Absolutely right, the Nano is overloaded, and i2c writes to a display slow it down further.

However, sending CW is reasonably slow, even for a Nano clocked at 16mhz.
Lets assume we are shooting for good operation at 20 wpm.
The word "PARIS" including inter-character and inter-word spacing has the equivalent of 50 dot elements,
So 20wpm is 20*50/60 = 16.66 dots/sec, a rising or falling edge every 1/(2*16.66) = 30 milliseconds.
If you are updating a slow display while in the midst of sending CW, you are doing it wrong.
And if you want to catch the very first dot of a transmission on an overloaded processor,
it had best be keyed through a digital pin that generates a high priority interrupt.

I've used an i2c 16x2 LCD on my uBitx v3, but would not recommend using i2c on a larger display.
My stripped down code only does straight key mode as well, mostly because I wanted it as simple as possible.
Any keyer must be external.
A faster processor with more pins and more memory would make many things a lot easier.

Jerry, KE7ER



On Sun, May 16, 2021 at 05:34 AM, Bill Cromwell wrote:
Hi,

I went back to using an external keyer just because of the clumsy operation of the built-in keyer in my V3. The uBitX then sees straight key operation regardless of what is outside the radio or what I am doing at my fingertips:)


The lil processor in the radio is overloaded to my way of thinking. It is 'almost' good enough'. The suggestion of using a serial display will slow down the display and there have already been complaints about that. I have some serial displays and I may try one to see if it is tolerable. Some CW ops have reported improvements by tweaking the resistor values for the analog keyer pin. A search of messages or the files section should turn up that approach. Use of a processor with more resources sounds like a better idea. It will cost a little more, of course. "Cost creep" is a real thing.

I have a much different approach to the entire enterprise and *if* I get it completed and *if* it works I will publish the results. My silly ideas are to rearrange the existing blocks with other existing blocks. CW operation should not be an afterthought. Much of the rig in my mind is borrowed from the uBitX design. Some of those blocks are inspired by 'other' radios. No, Kentucky, not vacuum tubes <sly grin>.

73,

Bill KU8H

bark less - wag more


Keyers & the 'V6

 

I haven't gotten around to powering up my V6 yet, but I think my solution will likely work the best:? rework the Nano's program to remove the keyer portion, then use a Hamcrafters K44 external keyer.

Gerry

Sent by the Thunderbird