开云体育

In the spirit of posting efforts currently underway, I have been working on a new RF board and associated driver software. In a nutshell, the new board uses the Skyworks SI5340 instead of the SI5351. This change addresses several issues. The SI5340 offers rock solid performance from 100 KHz to 250 MHz with LVCMOS outputs (employed by the prototype RF board), dramatically reduced phase noise and jitter, much improved clock symmetry (upon which the performance of Tayloe mixers depends), and much simpler application-level control software (no mucking about with the PLL, Multisynth, or phase at the application level). The new RF board replaces the 5351 with the 5340, and restores true split operation (the SI5340 has four outputs, three of which are used for RX, TX, and CWTx). The most challenging part of the software was the algorithm for setting output frequency, that is, given a desired frequency, find near-optimal numerator and denominator values for the various dividers used within the SI5340. My software employs a mediant-based algorithm attributed (incorrectly) to Farey, and efficiently produces results comparable to those produced by ClockBuilder Pro (the stand-alone program for configuring Skyworks parts). Current status: 1) Driver and driver example code complete and tested with main board and SI5340 EVB 2) T41 software (forked from V66.9) patched to ifdef choice of SI5340 or SI5351 RF Board compiling and in test 3) New RF board hardware under construction (PCBs back from China; parts on hand) For the curious, prototype schematic and board pic are attached. 73, John Bennett AE0AM

Greetings All, I don't see much mentioned lately regarding the MCT, but having recently purchased the 'Microcontroller Projects for Amateur Radio' book (via Amazon); I've decided I would like to build an MCT of my own. I've been a licensed ham since 1971 and would like to take one last(?) crack at CW. I've been searching the web for either a kit, or at the very least a PCB (as mentioned in the book) but so far haven't found anyone (in my hemisphere) currently offering one that goes with the text. I also understand that the gerbers, schematics, source code etc., have been made available in the files section and github. I just thought I'd ask before messing up square feet of perf board, whilst attempting to wire up the pieces-parts. I also considered trying to have a PCB made, but I've only ever done that once. The results were good enough, I simply don't need a handful of boards when one will suffice. :) Sorry for the ramble. Any advice...? Thanks. 73, Vern - N7GTB

I've been wrestling with the datasheet for this 7" display. I checked all the jumpers and it is configured as 4-wire serial. It seems like there is a typo in the datasheet, as they have two J2 connectors, one with 10 pins and the other with 40 pins (labeled Parallel/Serial Interface and CTP (capacitive touch panel) interface. I want to double check if my assumptions are correct in the following connections to the display: Use only the first 8 pins of the 40 pin connector Pin Number (J2 AKA J3 on the device) 1 and 2 VSSGroundGND 3 and 4 VDDPower SupplyVCC 5 /SCS Serial Mode Chip Select (/CS), Low activeC/S 6 SDO 4-wire SPI Data Output (MISO)MISO 7 SDI 4-wire SPI Data Input (MOSI)MOSI 8 SCLK SPI Clock (SCLK)SCLK I've attached the datasheet. Thanks for you help.

Hi everyone. Its been a LONG time since I've done any compiling, so I don't know how to go about understanding the meaning of : undefined reference to. . . Would someone be so kind to enlighten me? Thanks, Duane - K5CA

I put together the BPF board, only three bands, powered up and had no connection between the teensy and computer. Disconnected the board and had connection with computer. Replaced teensy, now on fifth one, put back together and had connection. Teensy can not find the BPF board. I checked and rechecked the solder connections still nothing. Where or what should be looking for? Tom AB9EK

Hi Bill, In the boards that I have received, I noticed that there are 2 different encoder boards. In my first order I received the skinnier board labeled 3428224AP11-230315. In a recent order I received only 2 of the wider board, labeled 3428224A_P56_250122. What is the new board for and why only 2? Sorry if this was already answered, but I couldn't find it mentioned in my search here. Best regards, John K1JO

I have looked at all schematics and construction files, where is the j22 connector on main board connect to?

Some people may be interested https://nescacademy.nasa.gov/video/6575557f0e3a4a78a3e61b63f4ab7f361d Site seems to take an age to load.... The grouding one is interesting ref differitial interconnections and ground bounce. https://nescacademy.nasa.gov/video/6575557f0e3a4a78a3e61b63f4ab7f361d also EMC Fundamentals Part 10: Grounding, Bonding & Shielding https://nescacademy.nasa.gov/video/157dd3713d19419194643a13fd9de0dc1d I'm sure there are loads of others out there -- 73 Chris M0YGH

I wanted to share a little information on how I'm going to go about restructuring the T41 code. The most difficult bugs to track down in the current code have been those caused by the radio being in an unknown state -- some line that controlled a switch on the RF board or a parameter in the DSP chain was inserted or omitted somewhere in the code. Because all variables are global, this could be literally anywhere in the nearly 30,000 lines of code. Finding the source of the bug without the ability to use a debugger is a challenge. It also possible to insert an entirely valid line of code that places the radio in an invalid or undesirable state -- for instance, imagine turning the CAL switch on when trying to transmit SSB. I'm going to solve this problem by using state machines. In the new code structure, the state of the radio hardware will be controlled entirely by a radio mode state machine. This state machine is the only place in the code where the hardware state is changed. Using a state machine to control the hardware ensures that all hardware is always in a known configuration state. I'm working my way through the hardware boards, defining the valid configuration states for that hardware. I will then write functions that put the boards into each valid configuration state. The only way the rest of the code can affect the radio hardware is by calling one of those functions, and the only part of the code that will call those functions is the radio mode state machine. Here's an example of some of the states for the RF board (does not include the calibration states). State machines can be written entirely in C code, but it’s easier to understand how the state machine operates through a visual diagram. I've found an open-source solution, StateSmith, that allows you to draw the state machines in a graphical environment (I'm using draw.io) and then automatically generate the C code that implements the state machine. Here's the state machine I've created for the radio hardware. I'm working on a separate state machine to control the state of the graphical display. Here's how I imagine them all working together: The software runs in a loop as shown in the diagram above. It performs three major functions: Handle interrupt events: if an interrupt was registered by, for example, a button being pressed, then pass the appropriate event on to the state machines to change the hardware and UI states. Perform the appropriate signal processing, based on the current radio mode. Update the display, based on the current UI state. Then go back to step 1 and repeat. This loop should take at most 10ms to execute in order to avoid buffer overflows in the IQ buffers. I'm building this up from a blank canvas. I've spent most of my effort over the last few weeks learning how to use StateSmith and how to build an automated test environment using Google Test. I've now started to write code, starting with the signal processing, and writing unit tests for the code as I go. I've found the unit tests to be very helpful. If I decide to change a function's prototype or modify what the function does, I'll immediately know if that change breaks something somewhere else in the code. It should make the process of getting the code running on the Teensy much faster. I'm going to clean up the code as I move it over, piece by piece, to this new structure -- remove dead code, apply consistent style formatting, minimize the use of global variables, and write tests for every function so we know what it's supposed to do and when it stops doing this.

Hi Everyone, I have begun evaluating the 20W RF power amp by K9HZ (Dr. Bill Schmidt) with T41 to address the increased T41 V12 frequency and CW capabilities. Some of what I have found is as follows: Frequency Response A Bode plot of the amp stand-alone is shown in the first figure below. The response at both 5W and 15W (RMS) is essentially flat from 1MHz to over 50MHz. This covers the 6M band that the original T41 amp could not reach. Power Output Note that Bill (K9Z) rates the amp at 20W PEP, but it is current limited to about 16W (RMS). I tested the amp with two equal amplitude 7MHz tones but1KHz apart in frequency. at 16W RMS. The PEP of that is well over 20W and a scope plot of the LP filtered PA output (through a 50-ohm attenuator), showing the clean out, is contained in the next figure. A rating of 20W PEP represents a real-world SSB condition, since we rarely transmit sine waves on SSB, but rather complex speech waveforms. I have used the amp quite a bit over the past week, and it performed flawlessly. No overheating at full power for extended periods on the 3.5"x1.5"x1.25" heatsink, with no fan. No thermal run-away. Also, because of the included current limiting, it is not possible to drive the output stage transistors to destruction. Since each final RD16H MOSFET is rated at 16W max dissipation, the amp is conservatively designed. For anyone concerned about less tha20W output, note that the difference between 16W and 20W is about 1dB, or 1/6 of an S unit on the receiver - not much at all. SSB Signal quality That is currently under test and will be reported in the near future (waiting on some hardware components). CW signal quality As contrasted with SSB signals, CW is always a single tone, which is limited to 16W RMS (for sine waves 16W RMS is equivalent to16W PEP). The first CW plot is a narrow band spectrum of a 7.2Mz CW tone from the T41 V12 into the K9HZ amp. The plot is centered on 7.2MHZ with a 20KHz span. Within that bandwidth the signal is almost 80dB above the noise, with no other spurious components. The next plot is a wide band spectrum from 3Mz to 30MH of the 16W 7.2MHz amp output, through the T41 LP filter. The second harmonic is at -51.5dB relative to the 7.2MHz fundamental, well below the -43dB limit. Efficiency The amp draws about 620mA with no signal and 2.46A at 16W, indicating a class AB mode with about 45% efficiency at full power. For reference, a typical 300WH portable 12V battery would provide well over 15 hours of SSB operation with the T41 and K9HZ amp. Bottom line Jack and I fully recommend the K9HZ 20W amp for use with T41, especially for those wishing to have an extended frequency response to 6M, with V12 T41 boards. For readers of the T41 book, please note that we plan to include this material and more regarding V12 performance in a revision of the book to be added in the near future. These additions are reflective of changes suggested by builders of the T41. Afterall, the T41 was designed to be an experimenter's platform and that is exactly what has happened, both in hardware and software innovations. Thanks to all who contributed. For those who already have the book, we will post the additional material to this site in the files section at the same time the book revisions are completed and uploaded. K9HZ 20W power amp Frequency response K9Hz amp output at 16 W with Two-Tone input Narrow-band spectrum T41 CW mode at 16W Wide- band spectrum CW output at 16W

I put a jumper on the V12 Main board to add PTT to the microphone jack. I'm finding it handy.