Dr. Bill,
?
In yeterday's Mouser delivery, there were a couple .
I will have to look at the ?
I am intrigued with the OnBoard HDMI Interface. It looks like a mini-hdmi to HDMI cable would?
make it work.?
Adding the W550 Ethernet Shield might be the way to add Ethernet Connectivity.
?
On an interesting note, one of the Hermes Variants, the , is based on the Cyclone 10.
The link is to the
?
We will have to see if the RadioBerry development will lend itself to using the MKR VIDOR 4000.
?
..jpw J P Watters
KC9KKO
Morris, IL USA
?
?
?
|
Re: Not Displaying the Frequency....
On 2025-02-02 07:25, jjpurdum via groups.io wrote: Character displayed in first position, character displayed in second
position - etc. Then
erase and rewrite ONLY those characters that have changed.
Updating the characters used in the frequency display uses very little
time. *** Yet it is very disruptive to the audio. Why is that? I think it's because interrupts are disabled during SPI transfers. Tracking what has changed and what hasn't changed would likely take more time and updating the entire string. *** Microseconds. Literally zilch. And during the process of this figuring, interrupts are open, and the audio continues. The real time eater is the updating the spectrum/waterfall displays. The waterfall is less of
an issue because it's only changing 1x512 pixels on each pass. *** For some reason - that I don't really understand - the spectrum/waterfall is not a problem. I *suspect* that we are leveraging an internal function of the display to do partial scrolls or block moves. Since you can "see" which signals are active, I'm less concerned about
the audio _while _tuning than the audio when you _stop _tuning. *** Jack, I respectfully disagree. Smooth tuning is VERY important. When I'm zeroing in on an SSB signal or tuning past a CW signal, I want to hear it. Tuning around with my ancient Signal/One is more pleasant than tuning around with the T41 - although once you get there, the T41 receives better. Personally, at least half the time I spend in front of a ham radio is just tuning around. The equipment manufacturers understand this: Just think of all the elaborate main tuning mechanisms that have been used over the years. I think that the tuning can be seriously improved without loading down the radio to any appreciable degree. Just leaving out the update of the inactive VFO is making a big difference. Tuning only affects the main VFO. Why are we erasing and rewriting the inactive one - that doesn't change while tuning? ... let those people who think optimizing is so easy make the improvements to those things that are working. *** Working on it Jack. I am not a guy who takes software challenges lightly. Not any sort of programming genius or cowboy. But I don't think this particular one is too hard. I did embedded software for a living for 20 years, and I developed a pretty good nose for what's hard, and what's not hard. The first most obvious thing is to have a global variable for each display item that tells us *WHAT IS BEING DISPLAYED NOW*? If the new thing to display is the same as what's being displayed now, we don't mess with it. Why change it if it's already right? Working toward minimal audio disruption from display changes will make the tuning useable - but still not nice. To make it *nice* we will need to look at the big fat *tick* that happens at every encoder event. That is IMHO a harder nut to crack. But I remember the old encoder system with the encoders directly connected to a couple of I/O ports as being much smoother. - Jerry, KF6VB
|
All:
I'm winding the toroids for a new LPF board. Because the filter might be used with Bill's 100W PA, the wire size is increased to #20 gauge for winding on T68 cores. Because of the thicker wire and relative small cores, the Crochet Hook method suggested in the QST article doesn't work very well and runs the risk of kinking the wire. Therefore, I'm back to "hand-winding" the toroids.
FWIW, I've found that after I've threaded the wire through the center of the core, placing the wire between my thumb and forefinger, with the forefinger "on top" of the wire and gripping tightly and pulling the wire taught with my thumb "under" the wire tends to curl the wire that makes threading it through the center for the next turn much easier.
The curl thus formed is in the direction of the next turn and makes kinking less likely.
Jack, W8TEE
-- Jack, W8TEE
|
Re: Not Displaying the Frequency....
Character displayed in first position, character displayed in second position - etc.? Then
erase and rewrite ONLY those characters that have changed.
Updating the characters used in the frequency display uses very little time. Tracking what has changed and what hasn't changed would likely take more time and updating the entire string. The real time eater is the updating the spectrum/waterfall displays. The waterfall is less of an issue because it's only changing 1x512 pixels on each pass.?
The spectrum display is more difficult because it updates the entire 150x512 pixel area. At each point in that display you must first erase the old pixel and write the new pixel. If they are the same, no write is needed. However, I don't know which is quicker: 1) just rewrite the old and new pixel, or 2) test the two values and only rewrite if they are different.
Since you can "see" which signals are active, I'm less concerned about the audio while tuning than the audio when you stop tuning. Given a finite amount of time, I need to devote my time to those things that don't work than to optimizing those things that do work. After everything is working, then go back and optimize those things that can be improved. The other path is to continue to fix things that aren't working and let those people who think optimizing is so easy make the improvements to those things that are working.
Jack, W8TEE
On Sunday, February 2, 2025 at 12:05:39 AM EST, jerry-KF6VB <jerry@...> wrote:
Things are a little improved.? There is a call to tft.fillRect() that
erases the area where the frequency is displayed.? Theorizing that
audio interrupts are held back while that's done, I split it up into 5
fillRect()s.? So - clear this little bit, then come up for air and let
the
audio go.? Then clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current
frequency
into 10 mini-clears.? Much Better!? The audio is still chunky, but you
can
hear what you're tuning past.
? An obvious next step is to *selectively* rewrite stuff.? Why erase and
rewrite
stuff that hasn't changed?? Keep a string variable "displayed
frequency".? Or to
make it even simpler, have an array of 8 bytes:? Character displayed in
first position, character displayed in second position - etc.? Then
erase and rewrite
ONLY those characters that have changed.
? ? ? ? ? ? ? ? - Jerry, KF6VB
On 2025-02-01 20:39, jerry-KF6VB wrote:
> I suspect I understand...and it's not good.
>
> I think that SPI requires precise timing, and audio interrupts are
> disabled during long video transfers.
>
> Yet... the audio works fine while the spectrum, the S-meter bargraph,
> and the waterfall update.? Sigh.
>
>? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>
>
>
>
> On 2025-02-01 18:50, jerry-KF6VB wrote:
>> ...When tuning.
>>
>>? The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
>> unpleasant.? As you tune around, you get tiny
>> blips of sound, interspersed with long display updates.? You basically
>> cannot hear what you're tuning past.
>>
>>? I just tried commenting out the bit of code that displays the
>> frequency as you tune.? Tuning is much better.
>> There is still a burst of nasty noise with each encoder *tick*, but
>> it's short, and you can easily hear what you're
>> tuning past.
>>
>>? Naturally, that's not a real fix.? The instant you start tuning, the
>> frequency display is wrong...and that's just wrong!
>>
>>? What would be a fix?? A few things:? First of all, we *could* do a
>> timer thing where we don't bother to display
>> the frequency until we stop tuning.? There was tuning, and now there
>> isn't?? Ok, display where we got to.? Still not optimal.
>>
>>? I note that it always updates ALL the digits of the frequency, even
>> those that haven't changed.? It even
>> redisplays the VFO B frequency.? Surely it doesn't need to update all
>> that.
>>
>>? Also - I wonder why on earth the audio pauses or stops or gets
>> discarded while it writes the display?? Surely
>> audio interrupts can continue during this time....?
>>
>>? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>>
>>
>>
>
>
>
-- Jack, W8TEE
|
Ozarkcon 2025 QRP convention
Good Morning
?
Registration for the 2025 annual Ozarkcon is open.
Information can be found here:
We would love to have you join us this year.
It will take place on April 4th and 5th 2025.
?
I hope to see you there.
72
Johnny AC0BQ
?
?
?
|
Re: Not Displaying the Frequency....
On Sat, Feb 1, 2025 at 10:22 PM, jerry-KF6VB wrote:
you gotta get the basics right. THEN you add all the fancy stuff.
Fun stuff!
|
Re: Not Displaying the Frequency....
On 2025-02-01 22:06, K9HZ wrote: Hmmm Stripping functionality out of the radio. Quite the dilemma when you
will likely prefer to "do more" with your radio long-term than less... Stripping functionality was just done as a test. As a solution - doing video in small chunks is just as functional as doing it all at once. And - you gotta get the basics right. THEN you add all the fancy stuff. - Jerry, KF6VB Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
VP2EHZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C 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: Saturday, February 1, 2025 11:06 PM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] Not Displaying the Frequency....
Things are a little improved. There is a call to tft.fillRect() that erases
the area where the frequency is displayed. Theorizing that audio interrupts
are held back while that's done, I split it up into 5 fillRect()s. So -
clear this little bit, then come up for air and let the audio go. Then
clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current frequency
into 10 mini-clears. Much Better! The audio is still chunky, but you can
hear what you're tuning past.
An obvious next step is to *selectively* rewrite stuff. Why erase and
rewrite stuff that hasn't changed? Keep a string variable "displayed
frequency". Or to make it even simpler, have an array of 8 bytes:
Character displayed in first position, character displayed in second
position - etc. Then erase and rewrite ONLY those characters that have
changed.
- Jerry, KF6VB
On 2025-02-01 20:39, jerry-KF6VB wrote:
I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny blips of sound,
interspersed with long display updates. You basically cannot hear
what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're tuning past.
Naturally, that's not a real fix. The instant you start tuning,
the frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display the frequency until we
stop tuning. There was tuning, and now there isn't? Ok, display
where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even redisplays the VFO B frequency.
Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely audio interrupts can
continue during this time....?
- Jerry, KF6VB
|
Re: Not Displaying the Frequency....
Hmmm Stripping functionality out of the radio. Quite the dilemma when you
will likely prefer to "do more" with your radio long-term than less...
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
VP2EHZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C 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@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected]< [email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, February 1, 2025 11:06 PM To: [email protected]Subject: Re: [SoftwareControlledHamRadio] Not Displaying the Frequency.... Things are a little improved. There is a call to tft.fillRect() that erases the area where the frequency is displayed. Theorizing that audio interrupts are held back while that's done, I split it up into 5 fillRect()s. So - clear this little bit, then come up for air and let the audio go. Then clear the next little bit, then come up for air... etc. I disabled updating VFO-B, and divided the clear of the current frequency into 10 mini-clears. Much Better! The audio is still chunky, but you can hear what you're tuning past. An obvious next step is to *selectively* rewrite stuff. Why erase and rewrite stuff that hasn't changed? Keep a string variable "displayed frequency". Or to make it even simpler, have an array of 8 bytes: Character displayed in first position, character displayed in second position - etc. Then erase and rewrite ONLY those characters that have changed. - Jerry, KF6VB On 2025-02-01 20:39, jerry-KF6VB wrote: I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny blips of sound,
interspersed with long display updates. You basically cannot hear
what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're tuning past.
Naturally, that's not a real fix. The instant you start tuning,
the frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display the frequency until we
stop tuning. There was tuning, and now there isn't? Ok, display
where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even redisplays the VFO B frequency.
Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely audio interrupts can
continue during this time....?
- Jerry, KF6VB
|
Re: Not Displaying the Frequency....
I think you already know the answer...
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
VP2EHZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C 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@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected]< [email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, February 1, 2025 8:51 PM To: [email protected]Subject: [SoftwareControlledHamRadio] Not Displaying the Frequency.... ...When tuning. The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is unpleasant. As you tune around, you get tiny blips of sound, interspersed with long display updates. You basically cannot hear what you're tuning past. I just tried commenting out the bit of code that displays the frequency as you tune. Tuning is much better. There is still a burst of nasty noise with each encoder *tick*, but it's short, and you can easily hear what you're tuning past. Naturally, that's not a real fix. The instant you start tuning, the frequency display is wrong...and that's just wrong! What would be a fix? A few things: First of all, we *could* do a timer thing where we don't bother to display the frequency until we stop tuning. There was tuning, and now there isn't? Ok, display where we got to. Still not optimal. I note that it always updates ALL the digits of the frequency, even those that haven't changed. It even redisplays the VFO B frequency. Surely it doesn't need to update all that. Also - I wonder why on earth the audio pauses or stops or gets discarded while it writes the display? Surely audio interrupts can continue during this time....? - Jerry, KF6VB
|
Re: Not Displaying the Frequency....
Things are a little improved. There is a call to tft.fillRect() that
erases the area where the frequency is displayed. Theorizing that
audio interrupts are held back while that's done, I split it up into 5
fillRect()s. So - clear this little bit, then come up for air and let the
audio go. Then clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current frequency
into 10 mini-clears. Much Better! The audio is still chunky, but you can
hear what you're tuning past.
An obvious next step is to *selectively* rewrite stuff. Why erase and rewrite
stuff that hasn't changed? Keep a string variable "displayed frequency". Or to
make it even simpler, have an array of 8 bytes: Character displayed in first position, character displayed in second position - etc. Then erase and rewrite
ONLY those characters that have changed.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-02-01 20:39, jerry-KF6VB wrote: I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny
blips of sound, interspersed with long display updates. You basically
cannot hear what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're
tuning past.
Naturally, that's not a real fix. The instant you start tuning, the
frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display
the frequency until we stop tuning. There was tuning, and now there
isn't? Ok, display where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even
redisplays the VFO B frequency. Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely
audio interrupts can continue during this time....?
- Jerry, KF6VB
|
Re: Not Displaying the Frequency....
I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph, and the waterfall update. Sigh.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-02-01 18:50, jerry-KF6VB wrote: ...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny
blips of sound, interspersed with long display updates. You basically
cannot hear what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're
tuning past.
Naturally, that's not a real fix. The instant you start tuning, the
frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display
the frequency until we stop tuning. There was tuning, and now there
isn't? Ok, display where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even
redisplays the VFO B frequency. Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely
audio interrupts can continue during this time....?
- Jerry, KF6VB
|
Not Displaying the Frequency....
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is unpleasant. As you tune around, you get tiny
blips of sound, interspersed with long display updates. You basically cannot hear what you're tuning past.
I just tried commenting out the bit of code that displays the frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but it's short, and you can easily hear what you're
tuning past.
Naturally, that's not a real fix. The instant you start tuning, the frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a timer thing where we don't bother to display
the frequency until we stop tuning. There was tuning, and now there isn't? Ok, display where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even those that haven't changed. It even
redisplays the VFO B frequency. Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets discarded while it writes the display? Surely
audio interrupts can continue during this time....?
- Jerry, KF6VB
|
Re: T41 receive attenuator working?
The latest RF boards have holes in the back, behind the PE4302 chips for easier soldering the back pad. ?That said, ill look into having RF boards made with the PE4302¡¯s and the si5351 pre placed. ?I don't think that would cost much. ?
Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton - J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com
email:??bill@... ?
toggle quoted message
Show quoted text
On Feb 1, 2025, at 9:35?AM, jerry-KF6VB <jerry@...> wrote:
? On 2025-02-01 06:53, D Solt via groups.io wrote:Thanks Jerry. ?I now have 3 boards built with the attenuator and the
spectrum doesn't move up and down on any of them. ?I'll try monitoring
right at the attenuator with a sig gen input. ?It is a difficult chip
to install and I'm guessing I don't have it soldered on all pins.
*** Yeah, I think I had to install two or three before it finally worked.Those chips - and the si5351a - really beg for pick-n-place.I think it worked after... ?...I got some low temperature solder paste and diluted it with liquid flux.Put a tiny drop on each land under a microscope with a brand new Xacto knife tip.Soldered it on a little computerized hot plate. ???????????????????- Jerry, KF6VB
|
Re: T41-EP V11 PA Board JP1 Reference
Thanks Greg. I will do the bias adjustment and then remove the
resistor.
?
73 Rocco
toggle quoted message
Show quoted text
From: Greg KF5N via groups.io
Sent: Saturday, February 1, 2025 3:46 AM
Subject: Re: [SoftwareControlledHamRadio] T41-EP V11 PA Board JP1
Reference
?
Hi Rocco, the jumper is used only for setting the bias of the IRF510
transistors.
It forces the bias voltage generator circuitry to ON.? So it is only
used temporarily, in the preliminary tune-up of the amplifier.
?
--
73 Greg KF5N
|
Re: More on the display driver
|
Re: T41 receive attenuator working?
On 2025-02-01 06:53, D Solt via groups.io wrote: Thanks Jerry. I now have 3 boards built with the attenuator and the
spectrum doesn't move up and down on any of them. I'll try monitoring
right at the attenuator with a sig gen input. It is a difficult chip
to install and I'm guessing I don't have it soldered on all pins. *** Yeah, I think I had to install two or three before it finally worked. Those chips - and the si5351a - really beg for pick-n-place. I think it worked after... ...I got some low temperature solder paste and diluted it with liquid flux. Put a tiny drop on each land under a microscope with a brand new Xacto knife tip. Soldered it on a little computerized hot plate. - Jerry, KF6VB
|
Re: T41 receive attenuator working?
Thanks Jerry.? I now have 3 boards built with the attenuator and the spectrum doesn't move up and down on any of them.? I'll try monitoring right at the attenuator with a sig gen input.? It is a difficult chip to install and I'm guessing I don't have it soldered on all pins.
dave, n3ds
When I change the attenuator, I can see it clearly across the entire
spectrum display.? Everything just moves down.
? ? ? ? ? ? ?- Jerry, KF6VB
On 2025-01-31 17:15, D Solt via wrote:
> Thanks Oliver. I¡¯ll try this
> dave
>
>> On Jan 31, 2025, at 6:14?PM, Oliver KI3P via
>> <oliver=[email protected]> wrote:
>
>> ?
>>
>> 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.
>>
>> -------- Original Message --------
>> On 1/31/25 9:46 AM, D Solt via 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
>
>
>
> Links:
> ------
> [1] /g/SoftwareControlledHamRadio/message/32529
> [2] /mt/110916510/243852
> [3] /g/SoftwareControlledHamRadio/post
> [4] /g/SoftwareControlledHamRadio/editsub/243852
> [5]
> /g/SoftwareControlledHamRadio/leave/10484476/243852/1943518115/xyzzy
|
Re: More on the display driver
Wont matter what side of the board you solder it/ plug it into¡ just put the connectors on the opposite side of the board and keep the board faced the same way¡ meaning the chip faces the BACK SIDE of the board. ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C 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@... ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Tim via groups.io
Sent: Saturday, February 1, 2025 7:22 AM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] More on the display driver? For those who have not populated board yet could there be an additional version that soldered to back side of board? Would make sense for 7" display
|
Re: More on the display driver
For those who have not populated board yet could there be an additional version that soldered to back side of board?
Would make sense for 7" display
Tim
|
Re: T41-EP V11 PA Board JP1 Reference
Hi Rocco, the jumper is used only for setting the bias of the IRF510 transistors.
It forces the bias voltage generator circuitry to ON.? So it is only used temporarily, in the preliminary tune-up of the amplifier.
?
--
73 Greg KF5N
|
jjpurdum
Johnny AC0BQ
K9HZ