开云体育

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: https://forum.pjrc.com/index.php?threads/ra8875-teensy-4-1-again.76621/post-356579 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

I’m back for a while and working on kits again. I put a very high priority on the new Display Driver board that fixes the T41 display freeze issue and allows a nice long cable to the display. I offer a 3.3V ONLY kit and a 3.3V and 5V kit (until I run out of 3.3V kits… then I will only stock the combo 3.3V and 5V kit). I’m still writing the assembly manual for the display kits but it should be done by this afternoon. I will order the last few parts for them today… I should have them by Tuesday and will begin shipping them then. Also new to the list is the 20W Dummy Load/ 40 db attenuator tap for the calibration steps. I’ve attached the full list so you can look it over if you need something. Those boards and Kits with $0.00 are not in stock. Remember, don’t send me money, I’ll invoice you… and make SURE you include your address. All prices below are without shipping, taxes, and Paypal fee. I will be at FDIM Thursday night… and have a booth at Hamvention (Booth 4111 in Building 4) where we will have a special guest… Al Peter to show off the T41 and answer any questions. I will be selling boards and kits both places and you won’t have to pay shipping on them if you carry them away. Respond via my private email bill@... as to not clog the space here with our transactions. 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@...

Hello everyone, I have an assembled, tested and calibrated a T41 from 4SQRP that I built as a comparison to my T41EP that I built from scratch (no kit). I wanted to see if my no kit T41 performed as well as the kit from 4SQRP (which it did!). My T41 for sale has the "built like a tank" 20 watt amplifier from K9HZ. The last firmware that I installed is T41EEE by KF6VB. Of course newer versions of firmware/software have been released which you could upgrade the T41 to. The T41 is excess to my needs and I am hoping that someone who wanted this design but missed the one-time production run from 4SQRP may be interested in buying this completed radio. Please contact me directly if interested via PM or email me to the email listed on QRZ.com. Thanks and 73, Frank K1FFJ

All: Just heard from Amazon and the updated version is now being advertised: Jack, W8TEE -- Jack, W8TEE

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 to you! 73 Bob W3RDL Virus-free.www.avast.com

All: Al and I have just updated the 3rd edition T41 book. We moved the calibration info from Appendix C to its own chapter (20). The expanded instructions and new software make T41 calibration much easier. We have also updated the narrative in numerous places and have concentrated discussions on the V12.6 release where those changes are important. Some of you are asking yourself: Do I need to buy this update. Truthfully, if you already own the 3rd edition, we would say no. Most of the important changes are discussed on the web site and photos and schematics are available there, too. On the other hand, this is the last change we will be making to this book. Al and I have been at this for almost 7 years now and we're getting a little burned out. For that reason, we are turning this site over to Oliver King, KI3P, and Dr. Bill Schmidt, K9HZ. Al and I will continue to be active relative to the T41, but will leave the details to Oliver and Bill. If you do want the final version of the book, its new cover looks like this: The book is actually available now, but the Amazon ad will not reflect the new cover for about 10 more days. (If you order now, it will be the new version.) If you are attending the FDIM conference this May (coincides with Dayton Hamvention and the conference hotel is about 10 miles away), Al and I will be selling autographed copies on Thursday night (May 15th) at the conference hotel starting around 8PM. We have reduced the price of the autographed copies from $12,500 to $40...which is a deal and less than the Amazon price! If you have a previous copy of the book, bring it along and we will be happy to sign it. This has been a fun project and we want to thanks the hundreds of people have contributed to its improvement over time. We hope that continues long after Al and I are gone. 72, Jack Purdum, W8TEE Al Peter, AC8GY -- Jack, W8TEE

Hi Everyone, I am continuing to work on the T41 V12 system - both hardware and software. This time the elusive T41 Transmit calibration is addressed. First a bit of background. Initially, when we were working with V10/11 hardware, we attempted to use the internal T41 transmit and receive capabilities to do IQ SSB calibration of both the Receive and Transmit IQ data streams. However, when the new V12 combined RF board arrived, it turned out that the previous scheme did not work very well on transmit. Receive IQ cal is fine. Apparently, there is sufficient RF leakage between the receive and transmit V12 data sections that the transmit calibration was thrown off. The best correction factors determined internally were different from those measured with an external Spectrum Analyzer using the transmitted SSB signal. It would probably require a redesign of the V12 RF board to fix this. Rather than go to that length, I have devised a scheme which uses an external device to measure the IQ image during transmit and allow minimization of the adjacent channel image. Since this is done only infrequently, and most Hams have a second HF receiver available, this appears to be a reasonable work around. The hardware setup is shown in the first image. The T41 was set to 7.2MHz and output level to1W. The modulating tone is at 750Hz. With a Phase correction factor of 0.008 and a Gain correction of 1.02, the narrow band spectrum around 7.2MHz is shown in the spectrum plot. The image at 7.20075 MHz is at about -45dB relative to the peak. The next plot shows the result for a gain of 1.007, which yields the minimum IQ image rejection at about -75dB. With a gain of 1.02, the Yaesu 981 S meter shows about 9 as the reading, shown in the next picture. At a gain of 1.007, the S meter indicated about 4 in the final picture. Finally, a plot of the responses as the gain correction factor is varied is shown. Note that the minimum of the IQ image level is exactly the same when measured with the SA and the HF receiver at a gain value of 1.007. The HF receiver method was quite straight forward to perform and the minimum was easily found. The minimum is quite sharp, and the image rejection is better than 60dB. The Yaesu 891 was chosen for this test as a relatively inexpensive HF transceiver. More capable rigs would probably work even better. A test dummy load can easily be built using standard components. 2W RF resistors should suffice. (Avoid wire wound power resistors.) I used about 60 dB of attenuation for the direct connection. The next step is to refine the T41 software, so it is easier to perform these calibrations. This modification will be available soon in a software release for V12 hardware. Previous V11 cal routines should still function with V11 hardware. Hope this helps to clarify the V12 hardware/software calibration situation. Regards, Al AC8GY

Looking at Ver66-09, I have changed the calls to setBPFPath() so they are the same regardless of CW/SSB mode. No difference, still oscillates :(. Of course, it's still possible for code somewhere else to muck with it. Looking at setBPFPath() itself, I see that it sets the BPF with a write to port A of the I/O expander in the LPF controller card. It's reasonable to assume that access to that controller card is ONLY through a library function: mcpLPF.writeGPIOA(). So I searched the codebase for all occurrences of that function. I found five of them; two in SWR.cpp, and 3 in LPF_Control_V12.cpp. I temporarily commented out the calls in SWR.cpp - no difference, still oscillates. I found one unneeded call to mcpLPF.writeGPIOA() in LPF_Control_V12.cpp - where it's choosing an LPF. That's controlled by port B. Commented that out, no difference. If I had a version N that oscillated, and a version N-1 that didn't, I might be able to diff it into submission. I'm wondering how the BPF *band* is selected. Right now, I only see the code for selecting the bpf *path*. - Jerry, KF6VB