I wanted to take a moment to talk about the supply chain issues that everyone in the electronics manufacturing industry are facing, and specifically how it's affecting Etherkit. As I'm sure a lot of you are aware, we've been facing a continuous problem of component shortages, which has made continued manufacturing difficult, especially for us small operators. For example, as I mentioned in a previous post here, I recently reworked the circuit of my simple Twin-T code practice oscillator and created a new PCB design for it, using a drawing from my son. I did this in order to try to get a project out which hopefully could escape from the current parts shortages, but I was wrong. In between the time I ordered the PCBs and when they arrived from the fab, most of the non-generic components went out of stock everywhere, and stupidly I didn't order enough components for a production run.

Frankly, it's an extremely frustrating position to be in, and I'm worried that it's going to grind all of my manufacturing activities to a halt. I do have a small stockpile of parts for Si5351A Breakout Board, but those won't last forever and I have no idea when more Si5351A ICs will be available again.

For now I've been doing a deep-dive into some issues with the Si5351 Arduino library, in order to help improve that. I may be stuck doing coding only for quite a while unless turn around soon.

I've got a modest new hardware product in production, with a related update for subscribers in the post below this one. In addition to working on that, I also recently pushed v1.3.1 of the JTEncode library, which adds a convenience function to convert decimal degrees to a Maidenhead locator. Handy for those of you paring your WSPR transmitter with a GPS.

Next up is to tackle an issue that's been plaguing the Si5351Arduino library. The PLL algorithms in the library aren't accurate enough to generate MSFK signals properly on VHF. I know that a lot of people have emailed me about this over the last few years and I haven't responded to many of the mails. I get a ton of unsolicited emails, and as much as I'd like to be able to help everyone, most of the requests I get would require a non-trivial amount of time for me to properly answer. However, this is one of the things that I hear about a lot, and it needs to be fixed.

My plan is to do a careful analysis of the current tuning characteristics of the library at VHF. In order to do that, I needed a new frequency counter with better precision than the ones I currently have (and also very importantly, the ability to lock to my 10 MHz GPSDO). I managed to find an affordable instrument through tequipment.net and was able to pay for a large chunk of the cost with the money I've received through SubscribeStar. Thank you very much subscribers for your support, which helps me to fund important new lab equipment!

So I'll be drafting up a test protocol so that I can quantify the current tuning inaccuracies and have a way to ensure that I improve them with new code. Stay tuned here for further updates on this project. I hope to have some good improvement to push in the near future!

I recently returned from our annual family summer vacation and I'm back to work here in Beaverton. In addition to working on OpenBeacon 2 and a few smaller projects that I plan to release fairly soon (that hopefully can avoid the nasty supply chain problems that is a scourge in the electronics industry right now), I'm also starting to chip away at some of the support backlog on my open source code.

One of the biggest requests I've had is to add WSPR type 2 and type 3 message support to the JTEncode library for Arduino. This weekend I finally knuckled down, dove into the WSJT-X Fortran source in order to understand how those type of messages are encoded, and then add my own interpretation of the encoding algorithm to JTEncode. I'm happy to report that I seem to have a working encoder for the expanded WSPR message types. I've tested the new code here in about as many different ways that I could think of, but there's of course a chance that I've missed some bugs. You can see a screen shot of some of my testing below, showing the different message types being sent and received.

If you are curious about the new capabilities and would like to try the library, you can grab the files from the 1.3.0 branch on the repo and manually install them into your Arduino libraries folder. After some more testing from a few outside parties and I'm satisfied that the new code works reasonably well, I'll pull the new branch into the main code. I hope you find this useful! Let me know if you try it out and it works or doesn't work for you.

I'm pleased to report some good news about the Si5351A Breakout Board reference oscillator situation. While the original Abracon TCXO is still basically unavailable as of the date of this post, I have found a suitable replacement TCXO for now. I spent a few days in the lab running a batch of test boards through the normal test and calibration routine (which they passed with flying colors), but also doing extended testing on frequency stability, temperature sensitivity, and very narrowband TCXO tuning compensation behavior. The new TCXO looks at least as good as the Abracon osc, and could possibly be even a bit better (although that's based on an estimation, since I didn't directly put the two different oscillators through the same tests at the same time). They are certainly suitable for the Si5351A Breakout Board according to my standards, so I will be using these going forward.

I've secured a decent amount of these, which should keep me supplied for at least a few months. Once the Abracon oscillators are available again, I may continue to use them if supplies of this new oscillator become scarce, but I don't expect that users will notice any significant difference between the two.

Also, I wanted to note a small change in the Si5351A Breakout Board calibration report due to some confusion. In previous reports, the calibration factor was written in the sign needed to add or subtract from the nominal 25 MHz ref osc frequency (in other words, if the ref osc was 1000 ppb high, the report would print the correction as "-1000 ppb"). However, in the Etherkit Si5351 Arduino library, the factor you need to use to set the correction has the opposite sign, so in the previous example, you'd need to put in a positive correction, not negative. From this date forward, our calibration reports will use the latter standard, so that you put the number printed on the calibration report as is into the Arduino library correction method.