Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
CW Mistakes
|
It seems that - just occasionally - when you hit the "dit" paddle, the thing will go
toggle quoted message
Show quoted text
"dit dah", instead of just "dit". - Jerry KF6VB On 2021-05-15 08:25, jerry@... wrote:
Hello all, |
|
Hi Reed,
toggle quoted message
Show quoted text
The wrong *time*? I am confused. Is it a successive-approximation A-D? I just hauled the Bencher out to the garage and cleaned the contacts with De-Oxit and lacquer thinner. Now seems to be working fine. Time to take off the dummy load and make some contacts! - Jerry On 2021-05-15 10:49, Reed N wrote:
Yep. That's because the hardware implementation is a voltage divider, |
|
The v6 voltage divider pulls at different strengths for dot and dit. If you try and send a symbol that is the stronger pull, there's a small window on the way up and down where the voltage will be at the value where the weaker pull usually rests.
I have two keys, and if I try and send only dits, if I send enough of them on either, I eventually get a dit-dah like you described. However, I've never had an accidental dit after sending only dots. |
|
Which software are we talking about? Is this an RF interference problem, or possibly? a race condition in software? Arv _-_ It seems that - just occasionally - when you hit the "dit" paddle, the |
|
Hi Arv,
toggle quoted message
Show quoted text
It's the factory uBITXv6 software. Slightly modified as to tuning rate, but nothing that would affect CW. Apparently, the paddle input is an *analog* one. Three possible voltages are produced: 1 for dash, another for dot, and a third for *nothing*. I cleaned the contacts on my Bencher, and it got better - but still not perfect. This is a big deal for a CW op. We are judged by our fist. - Jerry "not quite a CW op yet but working on it" KF6VB On 2021-05-15 14:55, Arv Evans wrote:
Which software are we talking about? |
|
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 _._ Hi Arv, |
|
Yes, using various voltage levels into an ADC was done
toggle quoted message
Show quoted text
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:
|
|
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 goJerry 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 |
|
Hi,
toggle quoted message
Show quoted text
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 On 5/16/21 3:10 AM, Evan Hand wrote:
On Sat, May 15, 2021 at 12:40 PM, jerry@... wrote: |
|
Absolutely right, the Nano is overloaded, and i2c writes to a display slow it down further.
toggle quoted message
Show quoted text
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, |
|
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 |
|
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, -- Jack, W8TEE |
|
I had that wrong.??
toggle quoted message
Show quoted text
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. |
|
Arv,
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.
|
|
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,
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.
|
|
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,
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.
|
|
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.?? |
|
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.?? --
Jack, W8TEE |
Jim Sheldon
to navigate to use esc to dismiss