Radiated EMI from displays
Hello, I discovered this project last Fall and this reflector even more recently. I have been reading the discussions about "Display Noise' and"SPI issues"? with much interest and since my experience is a bit different I will share it here.
I have built a V12 radio with RF, Main, and Front panel boards in an AI6YM chassis, using STDVer050.2 software.
I originally built the radio with a TFTM070A3-5 v4.0 (7") display and immediately noticed significant amounts of noise not normally heard from a radio with the antenna disconnected. This noise was below the level of the noise coming from my antenna on bands up through 15M, but above that the radio's internal noise was higher than antenna noise.
I made a simple probe from a piece of coax by removing 1 " of the shield from the end, connected the other end to my spectrum analyzer, and probed around the inside of my T41. I discovered what I believe to be a smps in the upper right corner of the rear of the display running at about 1.15 MHz. This smps exists in both the 5" and 7" displays. The 6th harmonic of this can be heard at the bottom of 40M and the 12th harmonic at the bottom of 20M; neither can be heard with my antenna connected but are very noticeable with the antenna disconnected.
I discovered very high levels of EMI radiated from the middle area of the circuit card on the back of the display. The spectrum of this EMI starts in the HF band, peaks around 160 MHz and has very significant strength in the 6M and 2M bands. I then noted that the layout of the boards in my chassis places the receive input circuitry about 2" from both the smps and the display EMI source. Not good!
I then clamped my coax to the chassis such that the 1" "probe" was right next to the receive RF input circuitry. I then made a simple shield/cover for the 7" display. In doing so, I discovered a few issues with the displays. First, the pads around the four mounting holes are not connected to the circuit ground, nor are they even connected to each other. On the 7" display, the four oblong, exposed, pads across the top are connected to the circuit ground, but the four across the bottom of the board are not, nor are they connected to each other.? When I then measured the noise from the probe with and without the shield in place on the 7" display there was some improvement, most noticeably on the smps noise, but the noise on the upper HF bands was still higher than the noise from the antenna.
I then looked at the 5" display. All four of its exposed, oblong, pads are connected to ground. I soldered small clips (from a Harmon EMI kit) to each of those four pads and made a shield to fit in those clips (see attached picture). I had to run a short wire from each clip to the closest mounting post to tie the shield to the chassis. This provided a very significant reduction in the level of noise present at the receive input circuitry.
To quantify the improvement, I measured the radio's sensitivity on each band and converted that to a receive noise figure. That can be compared to the level of noise that I measure from my antenna. This data is shown and graphed in the attached Excel file. The T41 receiver is very quiet now up through 10M. 6M is much improved, but further improvement is desired. Perhaps the cable..., perhaps moving the RF board away....
73,
John W2TX
|
Re: Oscillations on high bands
I'm running 66.4 that I believe you sent me.? RX_SEL_BPF does not change state when PTT is pressed,? You can observe that on J1 of the LPF-Cntl pin 8.? You can see Pin 7 & 8 easily at that connector.? I plug a cable into J1 and then I can use a DVM or scope to easily access the pins.
I definitely have a problem with my setup.? So, my report on isolation will change.
dave
Thanks Dave! Do you mean that RX_BPF_SEL does not change state?
Can you point me to the source of the 66.4 code you're running? I want to try to figure out why this is the case.
On Tuesday, March 25th, 2025 at 9:48 AM, D Solt via <davesolt= [email protected]> wrote:
In ver 50.0 in SSB and CW modes, TX_BPF_SEL
and TR_BPF_SEL both switch states when PTT or Key engaged In ver 66.4 in CW mode, TX_BPF_SEL
and TR_BPF_SEL both switch states when Key engaged. In SSB mode, only
TX_BPF_SEL
switches state.
I am going to sweep the RX and TX paths to try to find blown
MASWSS0179's
dave, n3ds
By comparing your final plot (Isolation PA Out to PA In, LPF Cntl SN1, 25 MHz SSB, ver 50.0) to the plot of the same configuration with oscillating software loaded (Isolation PA Out to PA In, LPF Cntl SN1, 25 MHz SSB, ver 66.4), we see that the isolation is different between these two versions even though they have nominally identical configurations. Are you able to probe the control signals on the LPF board to see how they might differ?
I did notice that the Ver 66.4 CW isolation (which does not oscillate, IIRC) is identical to the Ver 50.0 SSB isolation (which also does not oscillate). So that is the configuration we should be seeking to replicate.
Regardless, the isolation is a lot worse than it should be, regardless of the configuration. Something is not right. We should expect about 48 dB of isolation from the MASWSS0179 switch alone:
This makes it seem like the TR switch is not working -- we should measure the TR switch performance on its own outside of the control board circuit.
On Monday, March 24th, 2025 at 3:55 PM, D Solt via <davesolt= [email protected]> wrote:
I ran some isolation tests today. Below is the first page of my report (attached).
I have had an oscillation at ~35MHz in the K9HZ 20-watt
power amp in my T41 V12 (SW ver 66.4) when I press PTT in the higher
bands. It appears to be caused by low
isolation between the PA Output, J8 and PA Input, J7, on the LPF-Control
board. Below are several plots from my
NanoVNA showing the isolation between 21MHz and 25MHz. On my two systems, the feedback oscillations
only occur above 22MHz.
The first plot shows the isolation with C18 removed from the
PCB. This capacitor is the path between
the transmit and receive RF switching circuits on the LPF-Control board. So is C7, but I didn¡¯t bother removing that. Isolation is better than 65dB with C18
removed.
The next two plots show the isolation at 25MHz in the CW
mode (key down) and SSB mode (PTT) engaged.
Isolation is in the 35dB range.
Additionally, the poor return loss in the SSB mode indicates that the
LPF is not being connected properly.
The next plot shows isolation at 50MHz in SSB mode with PTT
engaged. This is so bad (<25dB) that
I must have a bad RF switch.
The final two plots are done with version 50.0 at 21 and
25MHz. Performance in CW and SSB is
identical.
Conclusions:
¡¤
I may have a hardware problem or a test
equipment problem. Could someone else
duplicate this test?
¡¤
There is a software change in how CW and SSB are
controlled between version 50.0 and 66.4, but that bug doesn¡¯t seem to affect
isolation.
I found that the 25 MHz and 30 MHz bands oscillate, but the lower bands don't, matching what others have found.
To figure out why I measured the insertion loss from the output of the PA to the input of the PA. i.e., I connect port 0 of my NanoVNA to J8, and port 1 to J7. What this measures is the magnitude of the feedback loop.
What I found is that this is a lot higher than it should be, particularly at the higher bands.
| 7 MHz | 14 MHz | 21 MHz | 24 MHz | 28 MHz |
|-------|--------|--------|--------|--------|
|<-80dB | -63 dB | -53 dB | -48 dB | -47 dB |
I would expect roughly 40dB of insertion loss each through the T/R switch and the BPF selection switch U8. Clearly, I'm not getting that. It seems that the feedback amplitude is getting high enough at the higher bands to cause oscillations. What I would like to do next is:
1) Repeat this measurement for a known-good version of the code as identified by Jerry. Is this feedback path amplitude different?
2) Find the reason for the change in the feedback amplitude path by examining the LPF control signals between known-good and known-bad code.
Unfortunately, I am tied up for the week and won't be able to do this until next weekend.
|
Re: Oscillations on high bands
Thanks Dave! Do you mean that RX_BPF_SEL does not change state?
Can you point me to the source of the 66.4 code you're running? I want to try to figure out why this is the case.
On Tuesday, March 25th, 2025 at 9:48 AM, D Solt via groups.io <davesolt@...> wrote:
In ver 50.0 in SSB and CW modes, TX_BPF_SEL
and TR_BPF_SEL both switch states when PTT or Key engaged In ver 66.4 in CW mode, TX_BPF_SEL
and TR_BPF_SEL both switch states when Key engaged. In SSB mode, only
TX_BPF_SEL
switches state.
I am going to sweep the RX and TX paths to try to find blown
MASWSS0179's
dave, n3ds
By comparing your final plot (Isolation PA Out to PA In, LPF Cntl SN1, 25 MHz SSB, ver 50.0) to the plot of the same configuration with oscillating software loaded (Isolation PA Out to PA In, LPF Cntl SN1, 25 MHz SSB, ver 66.4), we see that the isolation is different between these two versions even though they have nominally identical configurations. Are you able to probe the control signals on the LPF board to see how they might differ?
I did notice that the Ver 66.4 CW isolation (which does not oscillate, IIRC) is identical to the Ver 50.0 SSB isolation (which also does not oscillate). So that is the configuration we should be seeking to replicate.
Regardless, the isolation is a lot worse than it should be, regardless of the configuration. Something is not right. We should expect about 48 dB of isolation from the MASWSS0179 switch alone:
This makes it seem like the TR switch is not working -- we should measure the TR switch performance on its own outside of the control board circuit.
On Monday, March 24th, 2025 at 3:55 PM, D Solt via <davesolt= [email protected]> wrote:
I ran some isolation tests today. Below is the first page of my report (attached).
I have had an oscillation at ~35MHz in the K9HZ 20-watt
power amp in my T41 V12 (SW ver 66.4) when I press PTT in the higher
bands. It appears to be caused by low
isolation between the PA Output, J8 and PA Input, J7, on the LPF-Control
board. Below are several plots from my
NanoVNA showing the isolation between 21MHz and 25MHz. On my two systems, the feedback oscillations
only occur above 22MHz.
The first plot shows the isolation with C18 removed from the
PCB. This capacitor is the path between
the transmit and receive RF switching circuits on the LPF-Control board. So is C7, but I didn¡¯t bother removing that. Isolation is better than 65dB with C18
removed.
The next two plots show the isolation at 25MHz in the CW
mode (key down) and SSB mode (PTT) engaged.
Isolation is in the 35dB range.
Additionally, the poor return loss in the SSB mode indicates that the
LPF is not being connected properly.
The next plot shows isolation at 50MHz in SSB mode with PTT
engaged. This is so bad (<25dB) that
I must have a bad RF switch.
The final two plots are done with version 50.0 at 21 and
25MHz. Performance in CW and SSB is
identical.
Conclusions:
¡¤
I may have a hardware problem or a test
equipment problem. Could someone else
duplicate this test?
¡¤
There is a software change in how CW and SSB are
controlled between version 50.0 and 66.4, but that bug doesn¡¯t seem to affect
isolation.
I found that the 25 MHz and 30 MHz bands oscillate, but the lower bands don't, matching what others have found.
To figure out why I measured the insertion loss from the output of the PA to the input of the PA. i.e., I connect port 0 of my NanoVNA to J8, and port 1 to J7. What this measures is the magnitude of the feedback loop.
What I found is that this is a lot higher than it should be, particularly at the higher bands.
| 7 MHz | 14 MHz | 21 MHz | 24 MHz | 28 MHz |
|-------|--------|--------|--------|--------|
|<-80dB | -63 dB | -53 dB | -48 dB | -47 dB |
I would expect roughly 40dB of insertion loss each through the T/R switch and the BPF selection switch U8. Clearly, I'm not getting that. It seems that the feedback amplitude is getting high enough at the higher bands to cause oscillations. What I would like to do next is:
1) Repeat this measurement for a known-good version of the code as identified by Jerry. Is this feedback path amplitude different?
2) Find the reason for the change in the feedback amplitude path by examining the LPF control signals between known-good and known-bad code.
Unfortunately, I am tied up for the week and won't be able to do this until next weekend.
|
That is strange. This sounds like the kind of error that can happen when the data structures stored on the EEPROM change, for instance when you move between versions of the code without erasing the EEPROM. But, by your description, you didn't do that.
|
Bill, I don't have any oscillations, but then I don't have a LPF
or PA built yet. I lost over a week trying to get back to where I
could compile a running version.?
I attached the spectrum of the 10m & 6m outputs from the RF
board. The output on 6m is down significantly.
On 3/24/2025 12:08 AM, K9HZ via
groups.io wrote:
Any
oscillations on 10M or 6M?
?
?
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@...
?
?
?
After totally scrubbing and rebuilding the IDE and libraries,
I can compile and run everything again. However Ver66.4 and
66.9 only run at 600MHz if TCXO is defined. They both freeze
if compiled with 528MHz.
The Receive I&Q Cal worked quite well, except the button
assignments don't agree with the directions.
Compiled with: Faster with LTO, 600 MHz, Dual Serial
SDTVer66.4
Memory Usage on Teensy 4.1:
? FLASH: code:308228, data:132408, headers:8892?? free for
files:7676936
?? RAM1: variables:194528, code:284488, padding:10424?? free
for local variables:34848
?? RAM2: variables:483744? free for malloc/new:40544
SDTVer66.9
Memory Usage on Teensy 4.1:
? FLASH: code:312196, data:132408, headers:9020?? free for
files:7672840
?? RAM1: variables:194784, code:288584, padding:6328?? free
for local variables:34592
?? RAM2: variables:483744? free for malloc/new:40544
--
73 
Bob W3RDL
--
73
Bob W3RDL
|
Re: RA8875 display problems with T4.x - a visual study
On Tue, Mar 25, 2025 at 10:20 AM, John Schindler wrote:
Just curious; do you think a piece of UTP CAT 5 or 6 would work?
I think it would.? I was going to test this but didn't want to make up another cable.? I was sweating it with the one I made thinking I'd get the wiring wrong or connect it upside down.
|
I've made dozens of changes to the 66.9 .ino, sdt.h and config.h files which entailed multiple compiling and loading cycles.
?
I want to say that this is the most stable and easy-to-live with release thus far.
?
Thank you?
|
Re: RA8875 display problems with T4.x - a visual study
On Tue, Mar 25, 2025 at 01:19 PM, K9HZ wrote:
but the noise from the SPI buffer chip brought the noise level in the receiver up to an intolerable level
I've been happy with my 4SQRP T41, but I don't have much experience with this.? What's considered an "intolerable" noise level for that radio?
?
Currently, my partially built v12 has a receiver noise floor 48 dB above my 4SQRP unit.? I have enough experience to know something is wrong with my v12 build.
|
Re: RA8875 display problems with T4.x - a visual study
¡° Bill, are you saying the T41 kits are unusable?? The displays work great! ¡±
I said no such thing. ?The display worked but the noise from the SPI buffer chip brought the noise level in the receiver up to an intolerable level
I habe no knowledge of Marks application. ?
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 Mar 25, 2025, at 2:14?PM, Greg KF5N via groups.io <greg.electricity@...> wrote:
? Any digital bus, by its nature, is going to produce noise.? That's the physics of digital waveforms (high slopes and discontinuities).? This issue is mitigated by applying good EMI design practices including decoupling, board design, and shielding.
This is somewhat of an art and might require multiple prototype passes to achieve.? I was able to make a few simple changes to the T41 boards and the display noise is close to undetectable.? The buffer part was not removed from the design.
What little noise remains certainly can't compete with HF band noise.? The radio also has switching regulators and a Class D audio amplifier.? The radio is working fine and the receiver is a pleasure to operate.
?
Bill, are you saying the T41 kits are unusable?? The displays work great!? I think the biggest problem with the kits is 10 meter operation.? That can be fixed by swapping a couple of parts.
Mark's application may be tolerant of digital noise and the buffer part may be relevant only towards fixing the display robustness.? In other words he may not need to work a lot on EMI issues.
?
--
73 Greg KF5N
|
Re: RA8875 display problems with T4.x - a visual study
Greg et al:
The TMPS previously had noise induced in the audio chain by the display interface when everything was managed by a single Teensy (touching the screen & changing onscreen objects caused a high-pitched whine in the audio...the audio was also interrupted/delayed by the same actions).? That's the primary reason why I split the functionality across two Teensy processors, as well as spreading/reducing the RAM consumption & spreading/reducing the processor load.? Now that the audio & display are on separate Teensy processors, there is absolutely no detectable noise in the generated audio stream & everything executes in real time, so problem(s) solved.
Mark J Culross KD5RXT
On Tue, Mar 25, 2025 at 1:14 PM, Greg KF5N via groups.io <greg.electricity@...> wrote: Mark's application may be tolerant of digital noise and the buffer part may be relevant only towards fixing the display robustness.? In other words he may not need to work a lot on EMI issues.
?
--
73 Greg KF5N
|
Re: RA8875 display problems with T4.x - a visual study
Any digital bus, by its nature, is going to produce noise.? That's the physics of digital waveforms (high slopes and discontinuities).? This issue is mitigated by applying good EMI design practices including decoupling, board design, and shielding.
This is somewhat of an art and might require multiple prototype passes to achieve.? I was able to make a few simple changes to the T41 boards and the display noise is close to undetectable.? The buffer part was not removed from the design.
What little noise remains certainly can't compete with HF band noise.? The radio also has switching regulators and a Class D audio amplifier.? The radio is working fine and the receiver is a pleasure to operate.
?
Bill, are you saying the T41 kits are unusable?? The displays work great!? I think the biggest problem with the kits is 10 meter operation.? That can be fixed by swapping a couple of parts.
Mark's application may be tolerant of digital noise and the buffer part may be relevant only towards fixing the display robustness.? In other words he may not need to work a lot on EMI issues.
?
--
73 Greg KF5N
|
Re: RA8875 display problems with T4.x - a visual study
This information is incorrect. ?The 74HC125 was the source of horrendous noise generation in the HF band spectra when connected to the SPI bus. ?This is documented in the forum exchanges from fall two years s ago. ?
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 Mar 25, 2025, at 1:25?PM, Greg KF5N via groups.io <greg.electricity@...> wrote:
? Hi Mark-
?
The T41 project has been successful with this device:
?
There was a run of a couple hundred kits which used this device between the Teensy 4.1 and the display.
The kits were successful, and if the operation of the display was a problem, we would have heard about it here.
?
I have updated the T41 Main board to what I am calling the T41-2.? Here is the schematic, which shows the above
buffer inserted in the SPI bus between the Teensy and the BuyDisplay:
?
?
I did my best to orient the Teensy on the pcb such that the route is as short was possible.? There is a connector and
a short cable.? The clock is upped to the maximum which I believe is 45 MHz.? The operation has been flawless.
Note that the T41 kits have a longer path and yet there are no reported issues.
?
Note that there may be an alternative.? The Teensy/Arduino libraries do not expose the GPIO strength and bandwidth settings.
These are claimed to exist on the PJRC Teensy 4.1 web page.
?
So it could be a matter of configuring the SPI GPIOs to higher output power and bandwidth.? I did find a discussion of this at
the PJRC forums.? I'm going to look at this problem when I work on the next version of the Main board.? I may insert
jumpers so the board can be built with or without the buffer chip.
?
--
73 Greg KF5N
|
Re: RA8875 display problems with T4.x - a visual study
Very interesting...
Jack, W8TEE
On Tuesday, March 25, 2025 at 01:25:53 PM EDT, Greg KF5N via groups.io <greg.electricity@...> wrote:
Hi Mark-
?
The T41 project has been successful with this device:
?
There was a run of a couple hundred kits which used this device between the Teensy 4.1 and the display.
The kits were successful, and if the operation of the display was a problem, we would have heard about it here.
?
I have updated the T41 Main board to what I am calling the T41-2.? Here is the schematic, which shows the above
buffer inserted in the SPI bus between the Teensy and the BuyDisplay:
?
?
I did my best to orient the Teensy on the pcb such that the route is as short was possible.? There is a connector and
a short cable.? The clock is upped to the maximum which I believe is 45 MHz.? The operation has been flawless.
Note that the T41 kits have a longer path and yet there are no reported issues.
?
Note that there may be an alternative.? The Teensy/Arduino libraries do not expose the GPIO strength and bandwidth settings.
These are claimed to exist on the PJRC Teensy 4.1 web page.
?
So it could be a matter of configuring the SPI GPIOs to higher output power and bandwidth.? I did find a discussion of this at
the PJRC forums.? I'm going to look at this problem when I work on the next version of the Main board.? I may insert
jumpers so the board can be built with or without the buffer chip.
?
--
73 Greg KF5N
-- Jack, W8TEE
|
Re: RA8875 display problems with T4.x - a visual study
Hi Mark-
?
The T41 project has been successful with this device:
?
There was a run of a couple hundred kits which used this device between the Teensy 4.1 and the display.
The kits were successful, and if the operation of the display was a problem, we would have heard about it here.
?
I have updated the T41 Main board to what I am calling the T41-2.? Here is the schematic, which shows the above
buffer inserted in the SPI bus between the Teensy and the BuyDisplay:
?
?
I did my best to orient the Teensy on the pcb such that the route is as short was possible.? There is a connector and
a short cable.? The clock is upped to the maximum which I believe is 45 MHz.? The operation has been flawless.
Note that the T41 kits have a longer path and yet there are no reported issues.
?
Note that there may be an alternative.? The Teensy/Arduino libraries do not expose the GPIO strength and bandwidth settings.
These are claimed to exist on the PJRC Teensy 4.1 web page.
?
So it could be a matter of configuring the SPI GPIOs to higher output power and bandwidth.? I did find a discussion of this at
the PJRC forums.? I'm going to look at this problem when I work on the next version of the Main board.? I may insert
jumpers so the board can be built with or without the buffer chip.
?
--
73 Greg KF5N
|
Re: RA8875 display problems with T4.x - a visual study
Just curious; do you think a piece of UTP CAT 5 or 6 would work?
John, W5JSS On Tue, Mar 25, 2025 at 9:58?AM Terrance Robertson, KN6ZDE via <tmrob4= [email protected]> wrote:
In the T41, there is also crosstalk on the display cable.? In the image below, the shorter ribbon cable does not work.? You need a cable of this type with about half this length to work.? The longer cable has the SPI signals reordered and separated by the ground and power wires.? It does work.? Perhaps it can be longer.? I didn't test that.
?
|
Oh, build results:
Memory Usage on Teensy 4.1:
? FLASH: code:305956, data:129336, headers:9116 ? free for files:7682056
? ?RAM1: variables:191584, code:283272, padding:11640 ? free for local variables:37792
? ?RAM2: variables:483744 ?free for malloc/new:40544
?
600MHz, dual serial, Faster with LTO
|
Hey yall',
I was running Ver66.9 and it seemed to address some of the issues I was having.? Calibrated FREQ and REC I/Q.? All good through several shutdowns and startups. Shut my radio down and brought it back up and now there is no spectrum, waterfall, audio.? Keypad and encoders don't work.? BIT passes.? For a while the SWR 7991 wasn't being picked up (failed), resoldered it and it still failed.? Then, on one restart, it magically passed. ?I reformatted the SD card, no luck. ?Re-extracted the .zip, recompiled and reloaded, no luck.? Weird! Thought MAIN may have failed, but I loaded Ver66.4 and that worked.?
Has anyone seen this?? SWR 7991 commented out.? RF 23017 is at 0x22, not 0x27.
Argh!
Thanks
Mark
|
Re: RA8875 display problems with T4.x - a visual study
In the T41, there is also crosstalk on the display cable.? In the image below, the shorter ribbon cable does not work.? You need a cable of this type with about half this length to work.? The longer cable has the SPI signals reordered and separated by the ground and power wires.? It does work.? Perhaps it can be longer.? I didn't test that.
?
|
Re: RA8875 display problems with T4.x - a visual study
So we designed those resistors into the V12.6 main board after reading the same posts you read¡ and that is what everyone has today (see the main board schematic out on my github). ?After a lot pf experimentation, i found the ISO7241 driver specifically designed to buffer/drive/isolate the SPI bus. ? You might have a look at it to see if it works for your projects. ?
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 Mar 25, 2025, at 10:01?AM, Mark J Culross <mjculross@...> wrote:
? The subject of problems with the SPI interface between the T4.x & RA8875 displays comes up quite often on the Teensy forum.? I would like to point out that the SPI interface is not anything that PJRC has much control over (it's baked into the processor that NXP created).? I'm not defending PJRC, just suggesting that any angst should almost certainly be directed to NXP rather than PJRC.
I personally am using an RA8875 display from buydisplay.com in my TeensyMIDIPolySynth (TMPS) project, & my experience with incorporating this display included some significant challenges.? I initially wire-wrapped a prototype of my TMPS & everything worked like a champ.? When I took the design to PCB, I transitioned through multiple (very expensive, with the PCB being 5.5" x 8.5" !!) versions of the PCB (with additional decoupling caps, with additional ground plane, with no ground plane, with two ground planes sandwiching everything else & a very large number of thru-vias stitching them closely together, with shorter SPI signal traces, with orthagonal SPI signal traces, etc.).
I was very frustrated until I found a few posts on the Teensy forum suggesting placing small value resistors (50-100ohm) inline with some of the SPI signals.? So, I cut traces on one of my non-working PCBs & patched in some resistors.? Doing so actually resolved my specific display problems.? I determined (thru experimentation & by observing the signals on my o-scope) that 100ohm resistors resulted in the cleanest SPI signals for my particular setup, so that's what the final PCB version for my TMPS successfully includes.? I am using the SPI interface connected to the RA8875 display at native speeds, with no software slowdown.? I have not had any RA8875 display problems of any kind since.
To me, this is very counter-intuitive: how could a very sloppy wire-wrapped board work just fine, but a very clean looking PCB not allow the display to work ??? Signal ringing & signal cross-talk were the major contributors to my display failures.? I know that there's some controversy with this "solution" of using inline small value resistors, but, for reference, here's a very recent Teensy forum post that visually shows the difference in the quality of the SPI signals before & after the use of inline small value resistors:
For comparison, I'd be interested in testing one of my non-working TMPS PCBs with the K9HZ buffer chip, if that's still an available option.
Mark J Culross KD5RXT
P.S. As a side note (since the subject of using serial interconnects between processors has also recently been discussed), my TMPS makes use of two Teensy boards: T4.1 runs the display & manages traditional 5-pin DIN serial MIDI, USBmidi, & USBhostMIDI, while a T4.0 manages all of the audio thru a Teensy Audio Adapter.? The two Teensy boards communicate over a shared 500Kbps serial port (settings flow T4.1-to-T4.0, audio/performance status flows T4.0-to-T4.1, & debug info flows both ways).? The device is a 3-voice, multi-waveform, multi-modulator (selectable FM & PM), 12-poly synth, with filtering & envelope control of all generators, where all of the controls are digitally displayed as buttons & sliders on the RA8875 display, switching between & among multiple menu screens, & everything can be adjusted in real time with no degradation of the resulting sound while it is being generated, & no induced delays in the MIDI response.? I am continually impressed with what a beast the T4.x actually is.? MJC
|
RA8875 display problems with T4.x - a visual study
The subject of problems with the SPI interface between the T4.x & RA8875 displays comes up quite often on the Teensy forum.? I would like to point out that the SPI interface is not anything that PJRC has much control over (it's baked into the processor that NXP created).? I'm not defending PJRC, just suggesting that any angst should almost certainly be directed to NXP rather than PJRC.
I personally am using an RA8875 display from buydisplay.com in my TeensyMIDIPolySynth (TMPS) project, & my experience with incorporating this display included some significant challenges.? I initially wire-wrapped a prototype of my TMPS & everything worked like a champ.? When I took the design to PCB, I transitioned through multiple (very expensive, with the PCB being 5.5" x 8.5" !!) versions of the PCB (with additional decoupling caps, with additional ground plane, with no ground plane, with two ground planes sandwiching everything else & a very large number of thru-vias stitching them closely together, with shorter SPI signal traces, with orthagonal SPI signal traces, etc.).
I was very frustrated until I found a few posts on the Teensy forum suggesting placing small value resistors (50-100ohm) inline with some of the SPI signals.? So, I cut traces on one of my non-working PCBs & patched in some resistors.? Doing so actually resolved my specific display problems.? I determined (thru experimentation & by observing the signals on my o-scope) that 100ohm resistors resulted in the cleanest SPI signals for my particular setup, so that's what the final PCB version for my TMPS successfully includes.? I am using the SPI interface connected to the RA8875 display at native speeds, with no software slowdown.? I have not had any RA8875 display problems of any kind since.
To me, this is very counter-intuitive: how could a very sloppy wire-wrapped board work just fine, but a very clean looking PCB not allow the display to work ??? Signal ringing & signal cross-talk were the major contributors to my display failures.? I know that there's some controversy with this "solution" of using inline small value resistors, but, for reference, here's a very recent Teensy forum post that visually shows the difference in the quality of the SPI signals before & after the use of inline small value resistors:
For comparison, I'd be interested in testing one of my non-working TMPS PCBs with the K9HZ buffer chip, if that's still an available option.
Mark J Culross KD5RXT
P.S. As a side note (since the subject of using serial interconnects between processors has also recently been discussed), my TMPS makes use of two Teensy boards: T4.1 runs the display & manages traditional 5-pin DIN serial MIDI, USBmidi, & USBhostMIDI, while a T4.0 manages all of the audio thru a Teensy Audio Adapter.? The two Teensy boards communicate over a shared 500Kbps serial port (settings flow T4.1-to-T4.0, audio/performance status flows T4.0-to-T4.1, & debug info flows both ways).? The device is a 3-voice, multi-waveform, multi-modulator (selectable FM & PM), 12-poly synth, with filtering & envelope control of all generators, where all of the controls are digitally displayed as buttons & sliders on the RA8875 display, switching between & among multiple menu screens, & everything can be adjusted in real time with no degradation of the resulting sound while it is being generated, & no induced delays in the MIDI response.? I am continually impressed with what a beast the T4.x actually is.? MJC
|
Tom - AJ8X
K9HZ
jjpurdum