开云体育

All: It's been since last March that we've made a new source code release and a lot has happened in the interim. First, I doubled the number of Beta testers for the software and that has been invaluable in testing the software, especially since there are some minor hardware differences within the Beta group. A special note of thanks and appreciation goes to Greg (KF5N) who led the Beta effort with notable help from Len (KD0RC), Wes (AC8JF), John (G0ORX), Jack (KC7VLO), Nev (ZL2BNE), and Jerry (KF6VB). Dr. Bill Schmidt (K9HZ) has made numerous hardware additions to the project, including PCB's and a PA kit of his own design. To all of them, a huge thanks! Please note that we are now requiring a micro SD card be in place in the onboard Teensy 4.1 micro SD cardholder. Also, the preferred IDE is now Release 2.1.1. Compiles give two warnings: 1) that the memset() call has overlapping elements (I want it that way), and 2) a warning from the Open_Audio library. I don't want to wade into someone else's library code and make changes since everyone using it in their T41 would have to do the same. Just ignore the warning. Finally, if you do find a bug, post it with the same tag line as seen here. I'm going to "sticky" the post so they stay together. You will find the new code in the Files section. (Go to the File directory, double-click on the right-most column, Update, two times. This will bring the post near the top of the list.) Jack, W8TEE

Completed RX and TX IQ cal all working fine. I went into menu to change display options, as soon as menu came up it returned went back to spectrum display which was only partial display. Now it reboots on its own every few seconds and display is only partial. Locked up power cycle does not help. Tim W4YN

I recently did some ADC measurements in preparation for an update to my Audio VNA. I mention it here as I think it has some stuff of interest to the T41 project. The measurements are on-going, but as of now included the SGTL5000 (ADC side)and the PCM1808. I believe it was the T41 use of the PCM1808 that got me to look at that part---thanks. The web page for the study is https://www.janbob.com/electron/Codec/CODECTest.htm For this group, one interesting element that came out is that the PCM1808 produces 24-bit output data, but this is lost back to 16 if you input I2S via the Teensy AudioInputI2S followed by a Q15 to F32 conversion. If you do the input via AudioInputI2S_F32 of the OpenAudio_ArduinoLibrary, the F32 library, it will include all 24-bits automatically, as well as saving a conversion. Questions, comments and corrections are all appreciated. Bob W7PUA

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.