Re: T41 receive attenuator working?

Here's one way to test it.

Load the latest code onto the Teensy. It has an option under the RF set menu to change the input attenuation.

Then, put a 10 MHz (or whatever) signal into the RF_in SMA connector and hook an oscilloscope or spectrum analyzer to the output side of the attenuator bypass jumper.

You should see the signal amplitude change when you adjust the RF input attention setting in the RF menu.

Show quoted text

-------- Original Message --------
On 1/31/25 9:46 AM, D Solt via groups.io wrote:

How do I tell if the receive PE4302 attenuator is working.? I can't tell any difference in received signals at whatever settings or when I jumper it out.? I have two RF boards built up and they behave the same.? Before I swap the chips out, I wanted to get some inputs. I haven't gotten to testing the transmitter circuits yet.

dave, n3ds

Re: MKV VIDOR 4000 shows up

#32526

" not much support from the Arduino crowd."

I'm sorry to hear that, but not surprised. I looked at it two or three years?ago when I wanted eight fairly high speed counters connected to?a microcontroller. It seemed like quadrature counter IP could do it but no one on the official Arduino forum could tell me if it would work or how to do it.

The other two or three boards mentioned here look more interesting, and with this news, they don't have the stigma of maybe not being around as long as some other options.

Show quoted text

On Fri, Jan 31, 2025 at 12:57?PM jerry-KF6VB via <jerry=[email protected]> wrote:

Just curious - what does this particular board have going for it?? Looks
like
not much support from the Arduino crowd.

? ? ? ? ? ? ? ?- Jerry, KF6VB

On 2025-01-31 10:19, K9HZ wrote:
> THIS BOARD IS ACTUALLY A LOT SMALLER THAN IT LOOKS… A LITTLE BIGGER
> THAN A NANO BUT NOT MUCH!
>
> DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
> PJ2/K9HZ
>
> Owner - Operator
>
> Big Signal Ranch – K9ZC
>
> Staunton, Illinois
>
> Owner – Operator
>
> Villa Grand Piton - J68HZ
>
> Soufriere, St. Lucia W.I.
>
> Rent it: [1]
>
> email:? bill@...
>
>
>
> Links:
> ------
> [1]
> [2] /g/SoftwareControlledHamRadio/message/32518
> [3] /mt/110921012/243852
> [4] /g/SoftwareControlledHamRadio/post
> [5] /g/SoftwareControlledHamRadio/editsub/243852
> [6]
> /g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy

Re: [AmateurRadioBuilders] New Display Driver

#32525

You could use pointers because the indices are no different that an index except increment by one moves the byte pointer by sizeof(measure) bytes. Indeed the expression:

??????? int measure[100];

??????? int x;

??????? x = measure[10];

is no different than:

??????? x = *(&measure + (sizeof(int) * 10));

They are syntactically the same.

Jack, W8TEE

On Friday, January 31, 2025 at 02:36:21 PM EST, jerry-KF6VB <jerry@...> wrote:

On 2025-01-31 10:36, jjpurdum via groups.io wrote:
> I can't remember for certain, but I think I did try using a ring
> buffer when we first started the project, but I couldn't get it to
> work correctly. Perhaps I don't understand how we get the rollover for
> free? A program pointer is only 32 bits, so the ring buffer could hold
> 8 program pointers before it rolls over. The fact that you're
> incrementing the index suggests that's the case. Once it rolls over,
> we're back to the head of the buffer which is non-zero from the 8
> prior calls. At some point, the old address needs to disappear using
> that algorithm. You could accomplish the same thing without a ring
> buffer by just saving the return address and using it once the ISR
> finishes. I also tried that early on, but I never got it to work
> reliably. Since it must be easier than I understand it, perhaps you
> could give me the code and I'll test it.

Here's a test program I adapted for the power/SWR sensor in the K9HZ LPF
control
board.? It uses a timer interrupt to poll the device.? There is a
256-entry
circular buffer addressed by a pair of byte indices.? Note that these
are
INDICES, not pointers.? The concept won't work with pointers.? Note also
that
the struct containing the measurements is volatile.

I once wrote a program that converted a fast 286 PC ( this was in the
80's ) into
a recording oscilloscope.? The CPU had a system of registers and
"segment registers".? Each
ordinary register was 16-bit and addressed therefore 64K.? I used a 64K
circular buffer,
and got the rollovers for free because with 16 bits 0xffff + 1 = 0.

? ? ? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB

--
Jack, W8TEE

Re: MKV VIDOR 4000 shows up

#32524

Interesting project.? I have a different FPGA board waiting for my attention.

?

I recently spent about a month working with an (dual core Arm Cortex M7/M4).

There is a bit of a learning curve for the dual core chip even if you're familiar with the STM tool chain.? The learning curve is huge if you're not.? It took me about two days to get a blink program running on each core (the board has 4 LEDs for user use). ?I quickly came to realize how much we benefit from the work PJRC put into the T4.1. ?

?

During my time with the board, I was able to get the two cores talking together with some of my DSP routines running on the M7 core and some graphing routines running on the M4 core, which controlled the display.? However, my plan was to have a complete mockup of the T41 on the board in a quarter of that time.? In the end I put the project on hold because the display controller on the development board would require a sizable rewrite of the T41 display code.? I wasn't willing to do that for a mockup of the T41.? I have other projects that I'd rather spend time on.

Re: MKV VIDOR 4000 shows up

#32523

On 2025-01-31 11:56, K9HZ wrote:
This board has 1) an arduino processor and 2) a Cyclone 10 FPGA on the
same board.  It supports a variety of I/o and HDMI display interface.*** HDMI?  Now that *is* interesting.  Is it connected to the FPGA?  Is
there IP available to drive it?

                   - Jerry, KF6VB

Re: MKV VIDOR 4000 shows up

#32522

开云体育

This board has 1) an arduino processor and 2) a Cyclone 10 FPGA on the same board.? It supports a variety of I/o and HDMI display interface.? It sounds like a lot of cool stuff.? Now, I would never use this board in a radio project... but I might use the ships on MY MAIN board...

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com

?

Moderator: North American QRO Group at Groups.IO.

Moderator: Amateur Radio Builders Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB
Sent: Friday, January 31, 2025 12:58 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [SoftwareControlledHamRadio] MKV VIDOR 4000 shows up

?

Just curious - what does this particular board have going for it?? Looks like not much support from the Arduino crowd.

?

?????????????? - Jerry, KF6VB

?

On 2025-01-31 10:19, K9HZ wrote:

> THIS BOARD IS ACTUALLY A LOT SMALLER THAN IT LOOKS… A LITTLE BIGGER

> THAN A NANO BUT NOT MUCH!

>

> DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ

> PJ2/K9HZ

>

> Owner - Operator

>

> Big Signal Ranch – K9ZC

>

> Staunton, Illinois

>

> Owner – Operator

>

> Villa Grand Piton - J68HZ

>

> Soufriere, St. Lucia W.I.

>

> Rent it: [1]

>

> email:? bill@...

>

> Links:

> ------

> [1]

> [2] /g/SoftwareControlledHamRadio/message/32518

> [3] /mt/110921012/243852

> [4] /g/SoftwareControlledHamRadio/post

> [5] /g/SoftwareControlledHamRadio/editsub/243852

> [6]

> /g/SoftwareControlledHamRadio/leave/10484476/243852/1

> 943518115/xyzzy

?

Re: [AmateurRadioBuilders] New Display Driver

#32521

On 2025-01-31 10:36, jjpurdum via groups.io wrote:
I can't remember for certain, but I think I did try using a ring
buffer when we first started the project, but I couldn't get it to
work correctly. Perhaps I don't understand how we get the rollover for
free? A program pointer is only 32 bits, so the ring buffer could hold
8 program pointers before it rolls over. The fact that you're
incrementing the index suggests that's the case. Once it rolls over,
we're back to the head of the buffer which is non-zero from the 8
prior calls. At some point, the old address needs to disappear using
that algorithm. You could accomplish the same thing without a ring
buffer by just saving the return address and using it once the ISR
finishes. I also tried that early on, but I never got it to work
reliably. Since it must be easier than I understand it, perhaps you
could give me the code and I'll test it.Here's a test program I adapted for the power/SWR sensor in the K9HZ LPF control
board.  It uses a timer interrupt to poll the device.  There is a 256-entry
circular buffer addressed by a pair of byte indices.  Note that these are
INDICES, not pointers.  The concept won't work with pointers.  Note also that
the struct containing the measurements is volatile.

I once wrote a program that converted a fast 286 PC ( this was in the 80's ) into
a recording oscilloscope.  The CPU had a system of registers and "segment registers".  Each
ordinary register was 16-bit and addressed therefore 64K.  I used a 64K circular buffer,
and got the rollovers for free because with 16 bits 0xffff + 1 = 0.


                          - Jerry, KF6VB

ADC_tryit.ino

Re: MKV VIDOR 4000 shows up

#32520

Just curious - what does this particular board have going for it?  Looks like
not much support from the Arduino crowd.

              - Jerry, KF6VB

Show quoted text

On 2025-01-31 10:19, K9HZ wrote:
THIS BOARD IS ACTUALLY A LOT SMALLER THAN IT LOOKS… A LITTLE BIGGER
THAN A NANO BUT NOT MUCH!
DR. WILLIAM J. SCHMIDT - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois
Owner – Operator
Villa Grand Piton - J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com [1]
email:  bill@...
Links:
------
[1] 
[2] /g/SoftwareControlledHamRadio/message/32518
[3] /mt/110921012/243852
[4] /g/SoftwareControlledHamRadio/post
[5] /g/SoftwareControlledHamRadio/editsub/243852
[6]
/g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy

Re: [AmateurRadioBuilders] New Display Driver

#32519

I can't remember for certain, but I think I did try using a ring buffer when we first started the project, but I couldn't get it to work correctly. Perhaps I don't understand how we get the rollover for free? A program pointer is only 32 bits, so the ring buffer could hold 8 program pointers before it rolls over. The fact that you're incrementing the index suggests that's the case. Once it rolls over, we're back to the head of the buffer which is non-zero from the 8 prior calls. At some point, the old address needs to disappear using that algorithm. You could accomplish the same thing without a ring buffer by just saving the return address and using it once the ISR finishes. I also tried that early on, but I never got it to work reliably. Since it must be easier than I understand it, perhaps you could give me the code and I'll test it.

Jack, W8TEE

On Friday, January 31, 2025 at 11:32:08 AM EST, jerry-KF6VB <jerry@...> wrote:

On 2025-01-31 06:57, jjpurdum via groups.io wrote:
> Interrupts on the tuning encoders is a problem because you have to
> know where you return to after the interrupt is serviced. That's the
> reason we do polling on the encoder. Because interrupts can be
> triggered at any point in the code, when that trigger happens, the
> current stack pointer is pushed on the stack and, when the interrupt
> is finished, the stack pointer is popped off the stack and the program
> continues from that point. Because we don't know where the interrupt
> occurred and display updates are fairly constrained, polling was the
> solution. Perhaps there's a better way?

*** Sure there is.? Rotating buffers.? Something interesting happens,
the interrupt loads that fact into the rotating buffer.? Does NOTHING
but that.? Main program checks the buffer, sees that it's not empty, and
does whatever that interesting thing requires.

----------sample code---------------
interesting_thing_t interesting_thing_buffer[ 256 ];? <--- The 256 is
important.? That's what an 8-bit index can address.? We get the buffer
rollover for free.

volatile uint8_t interesting_head_index = 0;
uint8_t interesting_tail_index = 0;? ? //when the indices are EQUAL the
buffer is EMPTY
void interesting_thing_isr()
? ? {
? ? if( head_index == tail_index-1 ) return;? //no room at the inn,
nothing we can do.? Sorry!
? ? interesting_thing_buffer[ head_index++ ] =
the_interesting_thing_that_happened;
? ? }

...main line code....
while( head_index != tail_index )
? ? {
? ? handle_interesting_thing( interesting_thing_buffer[ tail_index++ ];
? ? }

------------ end sample code -----------------
The head index is written ONLY by the ISR.? The tail index is written
ONLY by the main line program.
Note that we don't have to erase the interesting_thing after we handle
it - we just increment the tail index.
We get the rollover from 0xff to 0 for free because the index is an
8-bit variable.

Now if the interesting_thing is an encoder event, we might have to save
the exact time that it occurred.? Or
maybe not - just the order of things in the circular buffer might be
enough.

If we're feeling cheap and 256 entries seems like too much, we can
achieve the same effect with a mask:

tail_index = ( tail_index+1 ) & 0b00001111;
...gets us a 16-item circular buffer.

Note also that with this technique, you don't have to disable
interrupts.? Because one index is written ONLY by the
ISR, and the other one is written ONLY by the main line code. And with
modern processors, an 8-bit write is always atomic.? That is, there's no
possibility of getting an interrupt while the byte is partially written.

? ? ? ? ? ? ? ? - Jerry, KF6VB

--
Jack, W8TEE

MKV VIDOR 4000 shows up

#32518

开云体育

This board is actually a lot smaller than it looks… A little bigger than a Nano but not much!

?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:

?

email:??bill@...

?

Re: [AmateurRadioBuilders] New Display Driver

#32517

On 2025-01-31 06:57, jjpurdum via groups.io wrote:
Interrupts on the tuning encoders is a problem because you have to
know where you return to after the interrupt is serviced. That's the
reason we do polling on the encoder. Because interrupts can be
triggered at any point in the code, when that trigger happens, the
current stack pointer is pushed on the stack and, when the interrupt
is finished, the stack pointer is popped off the stack and the program
continues from that point. Because we don't know where the interrupt
occurred and display updates are fairly constrained, polling was the
solution. Perhaps there's a better way?*** Sure there is.  Rotating buffers.  Something interesting happens,
the interrupt loads that fact into the rotating buffer.  Does NOTHING
but that.  Main program checks the buffer, sees that it's not empty, and
does whatever that interesting thing requires.

----------sample code---------------
interesting_thing_t interesting_thing_buffer[ 256 ];  <--- The 256 is important.  That's what an 8-bit index can address.  We get the buffer rollover for free.

volatile uint8_t interesting_head_index = 0;
uint8_t interesting_tail_index = 0;     //when the indices are EQUAL the buffer is EMPTY
void interesting_thing_isr()
   {
   if( head_index == tail_index-1 ) return;  //no room at the inn, nothing we can do.  Sorry!
   interesting_thing_buffer[ head_index++ ] = the_interesting_thing_that_happened;
   }

...main line code....
while( head_index != tail_index )
   {
   handle_interesting_thing( interesting_thing_buffer[ tail_index++ ];
   }

------------ end sample code -----------------
The head index is written ONLY by the ISR.  The tail index is written ONLY by the main line program.
Note that we don't have to erase the interesting_thing after we handle it - we just increment the tail index.
We get the rollover from 0xff to 0 for free because the index is an 8-bit variable.

Now if the interesting_thing is an encoder event, we might have to save the exact time that it occurred.  Or
maybe not - just the order of things in the circular buffer might be enough.

If we're feeling cheap and 256 entries seems like too much, we can achieve the same effect with a mask:

tail_index = ( tail_index+1 ) & 0b00001111;
...gets us a 16-item circular buffer.

Note also that with this technique, you don't have to disable interrupts.  Because one index is written ONLY by the
ISR, and the other one is written ONLY by the main line code. And with modern processors, an 8-bit write is always atomic.  That is, there's no possibility of getting an interrupt while the byte is partially written.

               - Jerry, KF6VB

Re: [AmateurRadioBuilders] New Display Driver

#32516

On Thu, Jan 30, 2025 at 08:30 PM, K9HZ wrote:

Seems like the right thing to do… but then what?

Look for optimizations in the software.

Re: [AmateurRadioBuilders] New Display Driver

#32515

I'm really not advocating that because I don't know what can be thrown out of the loop. As I stated earlier, not everything in the loop is interrupt-driven and I explained why. I'm not sure threading would improve things much, either. Adding a second processor, to me anyway, simply adds another layer of complexity to the system no matter what (i.e., interrupts or threading).

I think the "...but then what?" is a valid point.

Jack, W8TEE

On Thursday, January 30, 2025 at 11:30:57 PM EST, K9HZ <bill@...> wrote:

“throw them out and assess their impact on the performance.”

?

Seems like the right thing to do… but then what?

?

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it:

?

Moderator: North American QRO Group at Groups.IO.

Moderator: Amateur Radio Builders Group at Groups.IO.

?

email:? bill@...

?

Show quoted text

From: [email protected] <[email protected]> On Behalf Of jjpurdum via groups.io
Sent: Thursday, January 30, 2025 9:08 PM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New Display Driver

?

There has been a lot of code added in loop() that wasn't there to begin with, and all of that take time. If you want, perhaps there are things within that loop that you can live without. If that's the case, throw them out and assess their impact on the performance.

?

Jack, W8TEE

?

On Thursday, January 30, 2025 at 08:39:33 PM EST, jerry-KF6VB <jerry@...> wrote:

?

On 2025-01-30 14:04, K9HZ wrote:
> The higher the frequency, the faster the display updates, but the
> higher the SPI frequency is into the HF band causing harmonics.? That
> is the wrong direction!

*** The problem with a slow display is that it slows down the whole
system.
Each swing of the main loop happens after the display updates.? When you
are
tuning around, the audio pauses between clicks.? Each pause lasts until
the
frequency display finishes updating.? So if you tune around, you get
small bursts
of audio, interspersed with periods of silence.? The shorter those
silences are,
the better!

? As it is, if you tune any faster than "glacially slow", you literally
cannot
hear what you're tuning past.

? ? ? ? ? ? ? ? ? - Jerry, KF6VB

? See how low you can go and still have a
> decent display...
>
>
> Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
> PJ2/K9HZ VP2EHZ
>
> Owner - Operator
> Big Signal Ranch – K9ZC
> Staunton, Illinois
>
> Owner – Operator
> Villa Grand Piton – J68HZ
> Soufriere, St. Lucia W.I.
> Rent it:
>
> Moderator: North American QRO Group at Groups.IO.
> Moderator: Amateur Radio Builders Group at Groups.IO.
>
> email:? bill@...
>
>
> -----Original Message-----
> From: [email protected]
> <[email protected]> On Behalf Of jerry-KF6VB
> Sent: Thursday, January 30, 2025 3:58 PM
> To: [email protected]
> Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New
> Display Driver
>
> On 2025-01-30 13:55, K9HZ wrote:
>> You should make that divisor as big as possible up to the point that
>> the display still works.... makes the SPI as slow as possible and
>> creates less noise.
>
> *** You sure?? Wouldn't a faster SPI give faster display updates?? And
> therefore less chunky tuning?
>
>? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>
>
>
>>
>>
>> Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
>> PJ2/K9HZ VP2EHZ
>>
>> Owner - Operator
>> Big Signal Ranch – K9ZC
>> Staunton, Illinois
>>
>> Owner – Operator
>> Villa Grand Piton – J68HZ
>> Soufriere, St. Lucia W.I.
>> Rent it:
>>
>> Moderator: North American QRO Group at Groups.IO.
>> Moderator: Amateur Radio Builders Group at Groups.IO.
>>
>> email:? bill@...
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> <[email protected]> On Behalf Of jerry-KF6VB
>> Sent: Thursday, January 30, 2025 3:24 PM
>> To: [email protected]
>> Cc: K9HZ <bill@...>
>> Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New
>> Display Driver
>>
>> On 2025-01-30 10:58, K9HZ wrote:
>>> You can test that...
>>>
>> *** Indeed.? I just added the following line near the top of setup():
>>
>>? ? SPI.setClockDivider( SPI_CLOCK_DIV2 );
>>
>>? ? I'm not sure if it's faster or not.? It does compile, and the radio
>> works.
>>
>>? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>>
>>
>>>
>>> Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
>>> PJ2/K9HZ VP2EHZ
>>>
>>> Owner - Operator
>>> Big Signal Ranch – K9ZC
>>> Staunton, Illinois
>>>
>>> Owner – Operator
>>> Villa Grand Piton – J68HZ
>>> Soufriere, St. Lucia W.I.
>>> Rent it:
>>>
>>> Moderator: North American QRO Group at Groups.IO.
>>> Moderator: Amateur Radio Builders Group at Groups.IO.
>>>
>>> email:? bill@...
>>>
>>>
>>> -----Original Message-----
>>> From: [email protected]
>>> <[email protected]> On Behalf Of jerry-KF6VB
>>> Sent: Thursday, January 30, 2025 11:39 AM
>>> To: [email protected]
>>> Cc: [email protected]
>>> Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New
>>> Display Driver
>>>
>>> How fast will the display go?? I understand that the SPI clock is
>>> generated from the Teensy.
>>>
>>>? ? ? ? ? ? ? ? ? ? ? ? - Jerry
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>

--
Jack, W8TEE

Re: [AmateurRadioBuilders] New Display Driver

#32514

Interrupts on the tuning encoders is a problem because you have to know where you return to after the interrupt is serviced. That's the reason we do polling on the encoder. Because interrupts can be triggered at any point in the code, when that trigger happens, the current stack pointer is pushed on the stack and, when the interrupt is finished, the stack pointer is popped off the stack and the program continues from that point. Because we don't know where the interrupt occurred and display updates are fairly constrained, polling was the solution. Perhaps there's a better way?

Jack, W8TEE

On Friday, January 31, 2025 at 07:02:06 AM EST, John Lonigro via groups.io <jonigro@...> wrote:

Consider Jack's analogy of the smoke detectors in a building.? If you
start with a single story building with only a few smoke detectors, then
sequentially checking the status of each one vs having interrupts
doesn't make much difference.? As you add stories to that building,
you'd get to the point where doing sequential checks takes too long and
you need to go to a system of interrupts. Is this the case with the
T41?? It's pretty late in the game to change the code so drastically, so
perhaps going through the code and cutting back on the number of
sequential checks is a more reasonable solution, accepting some
compromises along the way.

Just my 2 cents worth.

73,
John, AA0VE

Show quoted text

On 1/30/25 23:12, K9HZ via groups.io wrote:
> You seem very fixated on a processor that can't achieve your goals then...
>
>
> Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ
>
> Owner - Operator
> Big Signal Ranch – K9ZC
> Staunton, Illinois
>
> Owner – Operator
> Villa Grand Piton – J68HZ
> Soufriere, St. Lucia W.I.
> Rent it: www.VillaGrandPiton.com
>
> Moderator: North American QRO Group at Groups.IO.
> Moderator: Amateur Radio Builders Group at Groups.IO.
>
> email:? bill@...
>
>
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB
> Sent: Thursday, January 30, 2025 10:57 PM
> To: [email protected]
> Cc: K9HZ <bill@...>
> Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New Display Driver
>
> On 2025-01-30 20:30, K9HZ wrote:
>> “throw them out and assess their impact on the performance.”
>>
>> Seems like the right thing to do… but then what?
> Well.? It's all a matter of priorities, isn't it?? What must happen every loop?? What can be deferred?
>
> Right now, it defers updating the spectrum - and probably, running the loop - while you tune.? The thing that seems to be taking time, and interrupting the audio - is just updating the frequency display.
>
> Maybe I'd rather hear what I'm tuning than see the frequency?
>
> Another way to skin the cat could be to move the frequency display to a timer interrupt.? Have it do it a few times a second or so.? So if you tune fast, you get ahead of it.? Not optimum, but maybe better than not hearing where you're tuning.
>
> The timer interrupt would have to be lower priority than the audio interrupt.
> I suspect that if you use the standard PJRC libraries, that is already the case.
>
>? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>
>
>
>
>
>
>
>
>
>

--
Jack, W8TEE

T41 receive attenuator working?

#32513

How do I tell if the receive PE4302 attenuator is working.? I can't tell any difference in received signals at whatever settings or when I jumper it out.? I have two RF boards built up and they behave the same.? Before I swap the chips out, I wanted to get some inputs. I haven't gotten to testing the transmitter circuits yet.

dave, n3ds

Re: [AmateurRadioBuilders] New Display Driver

#32512

So when my desktop computer gets too slow, I just get a new one that's faster?


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com

Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.

email:  bill@...

Show quoted text

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of John Lonigro via groups.io
Sent: Friday, January 31, 2025 6:02 AM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New Display Driver

Consider Jack's analogy of the smoke detectors in a building.  If you start with a single story building with only a few smoke detectors, then sequentially checking the status of each one vs having interrupts doesn't make much difference.  As you add stories to that building, you'd get to the point where doing sequential checks takes too long and you need to go to a system of interrupts. Is this the case with the T41?  It's pretty late in the game to change the code so drastically, so perhaps going through the code and cutting back on the number of sequential checks is a more reasonable solution, accepting some compromises along the way.

Just my 2 cents worth.

73,
John, AA0VE

On 1/30/25 23:12, K9HZ via groups.io wrote:
You seem very fixated on a processor that can't achieve your goals then...

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ 
PJ2/K9HZ VP2EHZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com

Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.

email:  bill@...

-----Original Message-----
From: [email protected] 
<[email protected]> On Behalf Of jerry-KF6VB
Sent: Thursday, January 30, 2025 10:57 PM
To: [email protected]
Cc: K9HZ <bill@...>
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New 
Display Driver

On 2025-01-30 20:30, K9HZ wrote:
“throw them out and assess their impact on the performance.”

Seems like the right thing to do… but then what?Well.  It's all a matter of priorities, isn't it?  What must happen every loop?  What can be deferred?

Right now, it defers updating the spectrum - and probably, running the loop - while you tune.  The thing that seems to be taking time, and interrupting the audio - is just updating the frequency display.

Maybe I'd rather hear what I'm tuning than see the frequency?

Another way to skin the cat could be to move the frequency display to a timer interrupt.  Have it do it a few times a second or so.  So if you tune fast, you get ahead of it.  Not optimum, but maybe better than not hearing where you're tuning.

The timer interrupt would have to be lower priority than the audio interrupt.
I suspect that if you use the standard PJRC libraries, that is already the case.

                  - Jerry, KF6VB

Re: [AmateurRadioBuilders] New Display Driver

#32511

Consider Jack's analogy of the smoke detectors in a building.? If you start with a single story building with only a few smoke detectors, then sequentially checking the status of each one vs having interrupts doesn't make much difference.? As you add stories to that building, you'd get to the point where doing sequential checks takes too long and you need to go to a system of interrupts. Is this the case with the T41?? It's pretty late in the game to change the code so drastically, so perhaps going through the code and cutting back on the number of sequential checks is a more reasonable solution, accepting some compromises along the way.

Just my 2 cents worth.

73,
John, AA0VE

Show quoted text

On 1/30/25 23:12, K9HZ via groups.io wrote:
You seem very fixated on a processor that can't achieve your goals then...


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com

Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.

email:  bill@...


-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB
Sent: Thursday, January 30, 2025 10:57 PM
To: [email protected]
Cc: K9HZ <bill@...>
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New Display Driver

On 2025-01-30 20:30, K9HZ wrote:
“throw them out and assess their impact on the performance.”

Seems like the right thing to do… but then what?Well.  It's all a matter of priorities, isn't it?  What must happen every loop?  What can be deferred?

Right now, it defers updating the spectrum - and probably, running the loop - while you tune.  The thing that seems to be taking time, and interrupting the audio - is just updating the frequency display.

Maybe I'd rather hear what I'm tuning than see the frequency?

Another way to skin the cat could be to move the frequency display to a timer interrupt.  Have it do it a few times a second or so.  So if you tune fast, you get ahead of it.  Not optimum, but maybe better than not hearing where you're tuning.

The timer interrupt would have to be lower priority than the audio interrupt.
I suspect that if you use the standard PJRC libraries, that is already the case.

                  - Jerry, KF6VB

Re: [AmateurRadioBuilders] New Display Driver

#32510

On 2025-01-30 21:12, K9HZ wrote:
You seem very fixated on a processor that can't achieve your goals then...*** Fixated?  It's the processor I have, Bill.  I didn't choose it.

                  - Jerry



Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ VP2EHZ
Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois
Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.
email:  bill@...
-----Original Message-----
From: [email protected]
<[email protected]> On Behalf Of jerry-KF6VB
Sent: Thursday, January 30, 2025 10:57 PM
To: [email protected]
Cc: K9HZ <bill@...>
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New
Display Driver
On 2025-01-30 20:30, K9HZ wrote:
“throw them out and assess their impact on the performance.”
Seems like the right thing to do… but then what?Well.  It's all a matter of priorities, isn't it?  What must happen
every loop?  What can be deferred?
Right now, it defers updating the spectrum - and probably, running the
loop - while you tune.  The thing that seems to be taking time, and
interrupting the audio - is just updating the frequency display.
Maybe I'd rather hear what I'm tuning than see the frequency?
Another way to skin the cat could be to move the frequency display to
a timer interrupt.  Have it do it a few times a second or so.  So if
you tune fast, you get ahead of it.  Not optimum, but maybe better
than not hearing where you're tuning.
The timer interrupt would have to be lower priority than the audio interrupt.
I suspect that if you use the standard PJRC libraries, that is already the case.
- Jerry, KF6VB

Re: [AmateurRadioBuilders] New Display Driver

#32509

You seem very fixated on a processor that can't achieve your goals then...


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com

Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.

email:  bill@...

Show quoted text

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB
Sent: Thursday, January 30, 2025 10:57 PM
To: [email protected]
Cc: K9HZ <bill@...>
Subject: Re: [SoftwareControlledHamRadio] [AmateurRadioBuilders] New Display Driver

On 2025-01-30 20:30, K9HZ wrote:
“throw them out and assess their impact on the performance.”

Seems like the right thing to do… but then what?Well.  It's all a matter of priorities, isn't it?  What must happen every loop?  What can be deferred?

Right now, it defers updating the spectrum - and probably, running the loop - while you tune.  The thing that seems to be taking time, and interrupting the audio - is just updating the frequency display.

Maybe I'd rather hear what I'm tuning than see the frequency?

Another way to skin the cat could be to move the frequency display to a timer interrupt.  Have it do it a few times a second or so.  So if you tune fast, you get ahead of it.  Not optimum, but maybe better than not hearing where you're tuning.

The timer interrupt would have to be lower priority than the audio interrupt.
I suspect that if you use the standard PJRC libraries, that is already the case.

                 - Jerry, KF6VB

Re: [AmateurRadioBuilders] New Display Driver

#32508

On 2025-01-30 20:30, K9HZ wrote:
“throw them out and assess their impact on the performance.”
Seems like the right thing to do… but then what?Well.  It's all a matter of priorities, isn't it?  What must happen
every loop?  What can be deferred?

Right now, it defers updating the spectrum - and probably, running the loop -
while you tune.  The thing that seems to be taking time, and interrupting
the audio - is just updating the frequency display.

Maybe I'd rather hear what I'm tuning than see the frequency?

Another way to skin the cat could be to move the frequency display to a timer
interrupt.  Have it do it a few times a second or so.  So if you tune fast,
you get ahead of it.  Not optimum, but maybe better than not hearing where you're
tuning.

The timer interrupt would have to be lower priority than the audio interrupt.
I suspect that if you use the standard PJRC libraries, that is already the case.

                - Jerry, KF6VB