|
Jim
Yes I realized that, but with the Teensy daughter board the problem
either went away, or we outran it.
Arv _._
On Sun, May 16, 2021 at 11:24 AM Jim Sheldon < w0eb@...> wrote: Arv, Jerry was complaining about the CW on the original factory Raduino, not TSW¡¯s Teensy 4.1 card which he now has running.
Jim ? Jerry
Does the new Teensy daughter board for the Raduino still use
the resistive voltage divider to detect whether the CW paddle closure is DIT or DAH?? If that is true, then it might seem that
the problem may be more related to timing than to voltage
thresholds.?
If that is true, then moving the routine that reads the ADC
might be something to look into.? Just repositioning the ADC
read call in original Arduino code might be all that is needed
for those who are stuck with version 3, 4, 5, or 6 Arduino and
the original Raduino.?
Since the original goal of BITX designs was to make a rig
that those with limited funds could use to get on the air, it
would be great if this DIT versus DIT..DAH problem could
be fixed with just a simple change in software.
Arv _._
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
|
Jerry
That sounds good.? As you get further into the Linear with computer assist,
there will probably be even more interesting possibilities to play with.
Arv _._
All,
? ? So with the TSW card working on my uBITXv6, I now have a spare
Raduino & display.? And a new project to work on.
? ? Got a little tiny 100W linear on Ebay, and also a switchable LPF
card.
I'd like to build these into a cabinet the same size as the uBITX, so
I'd
have a pair of twins.
? ? I think I'll use the spare Raduino card to control the linear.?
Truly, it
doesn't need much "controlling", just a select for the bandpass filter,
and TX/RX.? But having two matching boxes, each with a display, will
look really cool :).
? ?I found out that if I plug the bare Raduino into usb, it runs!? The
display lights up, all the buttons appear.? And I can modify that code
with the Arduino IDE.
? ?So I copied the code base to a new directory, and started going
through it & changing stuff.? To start with, I deleted everything
related to "frequency", VFOs and the SI5351.? Also deleted the CW keyer,
but not the morse output routines.? Maybe my linear will have a little
speaker, and it will annunciate band changes with audible CW.? I left
the CAT stuff in for now, just deleted unused variables so it would
compile.
? ?Also, since this is my project now, I'm going through the code and
reformatting to my own standards.? Specifically, I deTest CamelCase!?
Also "K&R" style indenting.? I grew up in the age of Pascal, and long
ago settled on that style.? My dislike for camel case is because it is
not "audible" in my head.? It's hard to remember whether it was
tryUsbConnection() or tryUSBConnection().? And this remembering is
important.? When variable names are very regular, one can code away
without constantly bopping back & forth to look at them.? So for me -
try_usb_connection().
? ?So I got my stripped code to compile, and it's running on the Raduino
sitting on my desk, just plugged into the USB.? Will probably also
delete
all the encoder stuff.? My tiny linear doesn't need an encoder.? So far,
my Nano is using 55% of the program memory and 36% of the RAM.
? ? ? ? ? ? ? ?- Jerry KF6VB
|
Arv:
If you're going a Teensy route, I'll help where I can.
Jack, W8TEE
On Sunday, May 16, 2021, 2:44:07 PM EDT, Arv Evans <arvid.evans@...> wrote:
Jim
Good.? That is why I asked the question.?
We are in a bit of a quandary here.? The uBITX is supposed to be minimal
enough to be an inexpensive entry to Ham Radio, yet at the same time it
is supposed to be fully operational for all the modes that it supports.? One
could claim that because it is entry level, it does not need to support fast
CW, but that sort of defeats its purpose.?
Jerry's use of a faster Teensy CPU seems to indicate that the CW stutter
problem may be fixable in several ways, including software, hardware, and
using a faster CPU.? I think we made some progress this morning.? Now to
do some testing and then decide which of the possibilities might be best,
least expensive, most reliable, and so on.
Eventually I would like to see a Teensy as the basis for a new Raduino. With its speed, memory, and ports it should be possible for a Teensy based?
Raduino to do some very impressive things.? Fast software can replace a lot
of hardware.
Thanks for the information.
Arv _._
On Sun, May 16, 2021 at 11:21 AM Jim Sheldon < w0eb@...> wrote: Arv, I¡¯ll answer this.? TSW has never used an analog voltage divider for our CW routines.? The dot and dash paddle inputs are on two of the teensy¡¯s digital inputs.? There is no timing problem with the keyer whatsoever and it performs nicely from a few WPM to well over 50 WPM. ?
Way back on the V3 uBITX we used the A6 and A7 NANO inputs for separate dot and dash connections, throwing out the voltage divider completely.? We were chastised by many people early on because they claimed A7 was supposed to be a ¡°spare¡±.? We ignored them and used A7 for the dash input anyway.? Our keyer worked right from the beginning.
Jim, W0EB ? Jerry
Does the new Teensy daughter board for the Raduino still use
the resistive voltage divider to detect whether the CW paddle closure is DIT or DAH?? If that is true, then it might seem that
the problem may be more related to timing than to voltage
thresholds.?
If that is true, then moving the routine that reads the ADC
might be something to look into.? Just repositioning the ADC
read call in original Arduino code might be all that is needed
for those who are stuck with version 3, 4, 5, or 6 Arduino and
the original Raduino.?
Since the original goal of BITX designs was to make a rig
that those with limited funds could use to get on the air, it
would be great if this DIT versus DIT..DAH problem could
be fixed with just a simple change in software.
Arv _._
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
--
Jack, W8TEE
|
All,
While I agree that there is enough sample time for the ADC, I have not seen any analysis on the polling time of the main loop of the program.? The program could be doing other things during the sampling process that extends the time of the loop.
Another point to remember is Nyquist requirements.? You must poll at least twice the speed of the fastest signal, and based on my industrial control experience 4 times faster is better.
73
Evan
AC9TU
|
On 2021-05-16 16:15, Evan Hand wrote: All,
While I agree that there is enough sample time for the ADC, I have not
seen any analysis on the polling time of the main loop of the program. I once worked on an embedded project with the following architecture, which is more or less what I use when starting a project from scratch: 1. A main loop. Each run through the loop takes a defined time ( we used 50ms, or 20 times a second ). 2. A timer interrupt. On that project, it happened every 2 ms. It bumped a counter on every invocation. 3. The main loop would time out its 50ms by counting the counter done by the 2ms interrupt. 4. When the main loop finished whatever useful things it was doing, it would set a pin high and wait till the timer count was 50ms. Then it would set the pin low, and go back to the beginning of the loop. 5. We would stick an oscilloscope on that pin, and it would tell us if the CPU was too busy. As the CPU loaded up, the pulse would get shorter and shorter, because the CPU was spending less time just waiting at the end of the 50ms loop. This was done by an Intel 8031 running at 9MHz, with VERY limited resources. At the top of the main loop, the stack pointer was always at the same number. If it wasn't, we knew something was badly wrong, and the processor would log the occurrence and reset. We also set the top 3 bytes of the stack to 0x55. If it wasn't 0x55 anymore, we knew we were close to blowing the stack. - Jerry KF6VB The program could be doing other things during the sampling process
that extends the time of the loop.
Another point to remember is Nyquist requirements. You must poll at
least twice the speed of the fastest signal, and based on my
industrial control experience 4 times faster is better.
73
Evan
AC9TU
Links:
------
[1] /g/BITX20/message/88431
[2] /mt/82850528/243852
[3] /g/BITX20/post
[4] /g/BITX20/editsub/243852
[5] /g/BITX20/leave/10189903/243852/952924773/xyzzy
|
Those are some really good hints on how to instrument code.
A good reason to find a processor with a few more pins than the Nano.
Doesn't really need to be timer based,? can just set pins high when doing?
the various jobs, perhaps include a pin for when it's idle. This is far better than trying
to print stuff to a serial monitor or a display, as writing to a pin is pretty much instantaneous.
One of those $20 DSO138's would be adequate as a scope for this sort of thing.
Driving LED's from those pins would sort of work, but not nearly as informative as a scope.
Checking the stack like that is a very good idea, it can be really hard to debug when the
stack fills up to where it starts stepping on your global variables.? All it takes is one array
invoked as a dynamic variable, or a poorly written library function.? Could set hundreds of bytes
to the magic 0x55 value and count them each loop if you wish, so long as you have time to .
do the counting.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, May 16, 2021 at 06:15 PM, jerry@... wrote:
On 2021-05-16 16:15, Evan Hand wrote:
All,
While I agree that there is enough sample time for the ADC, I have not
seen any analysis on the polling time of the main loop of the program.
I once worked on an embedded project with the following architecture, which is more or less what I use when starting a project from scratch:
1. A main loop. Each run through the loop takes a defined time ( we used 50ms, or 20 times a second ).
2. A timer interrupt. On that project, it happened every 2 ms. It bumped a counter on every invocation.
3. The main loop would time out its 50ms by counting the counter done by the 2ms interrupt.
4. When the main loop finished whatever useful things it was doing, it would set a pin high and wait till the timer count was 50ms. Then it would set the pin low, and go back to the beginning of the loop.
5. We would stick an oscilloscope on that pin, and it would tell us if the CPU was too busy. As the CPU loaded up, the pulse would get
shorter and shorter, because the CPU was spending less time just waiting at the end of the 50ms loop.
This was done by an Intel 8031 running at 9MHz, with VERY limited resources.
At the top of the main loop, the stack pointer was always at the same number. If it wasn't, we knew something was badly wrong, and the processor would log the occurrence and reset.
We also set the top 3 bytes of the stack to 0x55. If it wasn't 0x55 anymore, we knew we were close to blowing the stack.
- Jerry KF6VB
|
On 2021-05-16 11:48, Arv Evans wrote: Jerry
That sounds good. As you get further into the LINEAR WITH COMPUTER
ASSIST, *** Indeed. On screen display of measured power and SWR? Drain current & supply voltage? Calculated efficiency? Right now, I'm designing a clamshell case to 3d-print for it. I could buy a matching case from Farhhan, but it's more fun to make it than to spend money. Although if I value my time, it's far more expensive to make it. - Jerry KF6VB there will probably be even more interesting possibilities to play
with.
Arv
_._
On Sun, May 16, 2021 at 11:28 AM jerry@... <jerry@...> wrote:
All,
So with the TSW card working on my uBITXv6, I now have a spare
Raduino & display. And a new project to work on.
Got a little tiny 100W linear on Ebay, and also a switchable LPF
card.
I'd like to build these into a cabinet the same size as the uBITX,
so
I'd
have a pair of twins.
I think I'll use the spare Raduino card to control the linear.
Truly, it
doesn't need much "controlling", just a select for the bandpass
filter,
and TX/RX. But having two matching boxes, each with a display, will
look really cool :).
I found out that if I plug the bare Raduino into usb, it runs!
The
display lights up, all the buttons appear. And I can modify that
code
with the Arduino IDE.
So I copied the code base to a new directory, and started going
through it & changing stuff. To start with, I deleted everything
related to "frequency", VFOs and the SI5351. Also deleted the CW
keyer,
but not the morse output routines. Maybe my linear will have a
little
speaker, and it will annunciate band changes with audible CW. I
left
the CAT stuff in for now, just deleted unused variables so it would
compile.
Also, since this is my project now, I'm going through the code
and
reformatting to my own standards. Specifically, I deTest CamelCase!
Also "K&R" style indenting. I grew up in the age of Pascal, and
long
ago settled on that style. My dislike for camel case is because it
is
not "audible" in my head. It's hard to remember whether it was
tryUsbConnection() or tryUSBConnection(). And this remembering is
important. When variable names are very regular, one can code away
without constantly bopping back & forth to look at them. So for me
-
try_usb_connection().
So I got my stripped code to compile, and it's running on the
Raduino
sitting on my desk, just plugged into the USB. Will probably also
delete
all the encoder stuff. My tiny linear doesn't need an encoder. So
far,
my Nano is using 55% of the program memory and 36% of the RAM.
- Jerry KF6VB Links:
------
[1] /g/BITX20/message/88423
[2] /mt/82850528/243852
[3] /g/BITX20/post
[4] /g/BITX20/editsub/243852
[5] /g/BITX20/leave/10189903/243852/952924773/xyzzy
|
Jerry
For a test, insert reads of the micerosecond timer and then? subtract difference from? subsequent reads.? That way? you can place calls to this? subroutine where you need? them to build a picture of timing involved.? I used a DEBUG level? To select what stage reports its timing.??
Arv _-_
On 2021-05-16 16:15, Evan Hand wrote:
> All,
>
> While I agree that there is enough sample time for the ADC, I have not
> seen any analysis on the polling time of the main loop of the program.
I once worked on an embedded project with the following architecture,
which is more or less what I use when starting a project from scratch:
? 1.? A main loop.? Each run through the loop takes a defined time ( we
used 50ms, or 20 times a second ).
? 2.? A timer interrupt.? On that project, it happened every 2 ms.? ? ?
It bumped a counter on every invocation.
? 3.? The main loop would time out its 50ms by counting the counter done
by the 2ms interrupt.
? 4.? When the main loop finished whatever useful things it was doing, it
would set a pin high and wait till the timer count was 50ms.? Then it
would set the pin low, and go back to the beginning of the loop.
5.? We would stick an oscilloscope on that pin, and it would tell us if
the CPU was too busy.? As the CPU loaded up, the pulse would get
shorter and shorter, because the CPU was spending less time just waiting
at the end of the 50ms loop.
? ?This was done by an Intel 8031 running at 9MHz, with VERY limited
resources.
? ?At the top of the main loop, the stack pointer was always at the same
number.? If it wasn't, we knew something was badly wrong, and the
processor would log the occurrence and reset.
? ?We also set the top 3 bytes of the stack to 0x55.? If it wasn't 0x55
anymore, we knew we were close to blowing the stack.
? ? ? ? ? ? ? ? ? ? ?- Jerry KF6VB
>? The program could be doing other things during the sampling process
> that extends the time of the loop.
>
> Another point to remember is Nyquist requirements.? You must poll at
> least twice the speed of the fastest signal, and based on my
> industrial control experience 4 times faster is better.
>
> 73
> Evan
> AC9TU
>
>
> Links:
> ------
> [1] /g/BITX20/message/88431
> [2] /mt/82850528/243852
> [3] /g/BITX20/post
> [4] /g/BITX20/editsub/243852
> [5] /g/BITX20/leave/10189903/243852/952924773/xyzzy
|
On 2021-05-16 19:59, Jerry Gaffke via groups.io wrote: Those are some really good hints on how to instrument code.
A good reason to find a processor with a few more pins than the Nano.
Doesn't really need to be timer based, Better to have it timer based. Because then you get ONE waveform that tells you how busy the CPU is from all tasks put together. - Jerry KF6VB
|
Jerry KF6VB,
Perhaps I don't quite understand.
Arduino programs do their work in a loop() function,
where it does a bunch of stuff and then loops around to do it again.
Could set a pin high at the start of the loop, do all the various tasks,
then set that pin low at the bottom of the loop.
Looking at that pin tells me all I need to know about how busy the processor is,
and does not involve any timers.
If you have a low bandwidth scope for looking at that pin, you may want
to have a 1ms delay after setting it low so the scope can see it.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Mon, May 17, 2021 at 05:33 AM, jerry@... wrote:
On 2021-05-16 19:59, Jerry Gaffke via groups.io wrote:
Those are some really good hints on how to instrument code.
A good reason to find a processor with a few more pins than the Nano.
Doesn't really need to be timer based,
Better to have it timer based. Because then you get ONE waveform that tells you how busy the CPU is from all tasks put together.
- Jerry KF6VB
|
Hi Jerry KE7ER,
If you don't have a timer, your pulse will be varying frequency.
It won't tell you directly how busy the CPU is. You will make guesses - if the loop takes this long, then it's plenty fast. If otoh, you use a timed loop, you will see a pulse of fixed frequency but variable duty cycle. The duty cycle in percent will be equal to "how busy the CPU is" in percent. This is valuable info & easy to interpret at 10:00 at night when you're wondering why your program does something strange every third Thursday.
- Jerry KF6VB
toggle quoted message
Show quoted text
On 2021-05-17 08:23, Jerry Gaffke via groups.io wrote: Jerry KF6VB,
Perhaps I don't quite understand.
Arduino programs do their work in a loop() function,
where it does a bunch of stuff and then loops around to do it again.
Could set a pin high at the start of the loop, do all the various
tasks,
then set that pin low at the bottom of the loop.
Looking at that pin tells me all I need to know about how busy the
processor is,
and does not involve any timers.
If you have a low bandwidth scope for looking at that pin, you may
want
to have a 1ms delay after setting it low so the scope can see it.
Jerry, KE7ER
On Mon, May 17, 2021 at 05:33 AM, jerry@... wrote:
On 2021-05-16 19:59, Jerry Gaffke via groups.io wrote:
Those are some really good hints on how to instrument code.
A good reason to find a processor with a few more pins than the
Nano.
Doesn't really need to be timer based, Better to have it timer based. Because then you get ONE waveform
that tells you how busy the CPU is from all tasks put together.
- Jerry KF6VB Links:
------
[1] /g/BITX20/message/88443
[2] /mt/82850528/243852
[3] /g/BITX20/post
[4] /g/BITX20/editsub/243852
[5] /g/BITX20/leave/10189903/243852/952924773/xyzzy
|
How busy the CPU is would be directly proportional to the frequency.
We all have our preferred ways of doing things.
Having timers would make things more regular and perhaps easier to interpret.
But code need not structured around timers for pin setting to be a useful debug aid.
It is good that you brought this up, hasn't been mentioned in the forum before.
I've been setting debug pins like that for decades,
not just with software but when coding firmware for FPGA's.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Mon, May 17, 2021 at 08:56 AM, jerry@... wrote:
If you don't have a timer, your pulse will be varying frequency.
It won't tell you directly how busy the CPU is.
|
Correction for the fastidious:? Inversely Proportional
Time spent doing stuff in seconds is exactly 1/FreqHz
where "stuff" includes any baseline housekeeping required
to get around the loop when nothing is happening.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Mon, May 17, 2021 at 09:24 AM, Jerry Gaffke wrote:
How busy the CPU is would be directly proportional to the frequency.
|
