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.

My apologies are in order for going a bit dark over the winter. Without going into unnecessary details, I was struggling with some personal health issues that were difficult but not dangerous. That, in addition to my job as second teacher to my boys while school is still online-only here in Beaverton meant that I had to pause development work Etherkit for a bit. Now that things are mostly better, I'm back to proceeding with plans.

As you can see below, I have reformed my business from a sole proprietorship to a limited liability company in Oregon. I have still retained my assumed business name of "Etherkit", so I'll still be publicly identifying as such. I've reorganized because I intend to make a more serious push into manufacturing by developing more new products and the capability for me to do more mid-scale manufacturing from here. In that vein I've already acquired some new equipment and will be investing in even more soon.

The current plan here is still similar to what I posted late last year: invest some time in the large backlog of issues for my libraries on GitHub, finish OpenBeacon 2 and bring it to market, and then release some other breakout boards and such which have been in the hopper for a while waiting for a final release to manufacturing. I will have more actual news to report soon. Thank you!

In a bit of Etherkit news, we've encountered a supply chain issue that could put a squeeze on Si5351A Breakout Board with TCXO reference oscillator manufacturing. Late last year, there was a fire at the factory that manufactures many different oscillators, including the Abracon product that is used in the Etherkit Si5351A Breakout Board.

On Oct. 20, Abracon became aware of a fire at the Asahi Kasei Microsystem (AKM) semiconductor factory in Nobeoka, Miyazaki prefecture, Japan. Products produced at this factory are used in many Abracon TCXO oscillator products. At this time, there is limited information on the actual effect the fire will have on production and supply.

I have been able to acquire small quantities of the TCXO used in the breakout board until my most recent attempt. That particular part now is out of stock at all of my usual distributors, and is only available at one distributor but at a substantial markup from the usual price.

As of now, I'm considering the qualification of an alternate TCXO, but that will take some time to do. It may be necessary if Abracon cannot bring production back online in the near future, but I'm hoping they can source alternate manufacturers as is stated in the press release above. In the mean time, there may be a period where the Si5351A Breakout Board with TCXO is out of stock. The breakout board with crystal oscillator is not affected by this and will continue to be in stock.

Today I'm happy to release a small project that I've been working on that's very helpful for home lab organization. The Parametric Cable Comb is a tool that allows you to create a cable comb for hanging/storing cables to your specifications. All you need is a 3D printer and some filament. Once you set the parameters in the Thingiverse Customizer tool (alternately you can download the .scad file from GitHub and use the OpenSCAD Customizer), you can then export a custom STL file that can than be processed using your normal 3D print workflow.

I first learned about these while working at Tektronix, and found them extremely useful. However, they don't seem to be common in hobby electronics, although I understand they are used more often in the musical world. This was my first attempt at making a parametric 3D model and my first serious attempt at learning OpenSCAD. If I may say so, it turned out better than I expected. I hope you also find it useful. As always, if you encounter any problems or have suggestions, please let me know.

Built two panels of Empyrean Alpha today; roughly half of what is needed to complete the Empyrean campaign. Here are both panels after finishing post-reflow visual inspection. Should be able to build the other two panels within a few days, then I'll be able to proceed with test. Hoping to start shipping the remaining orders within a week or so!

In a previous post, I mentioned that I was going to need a new laptop so that I could continue working at the dining room table while my boys did their online school work. After doing some research into the options, we were able to budget for a moderately priced laptop in the midrange. I'm already a fan of the desktop AMD Ryzen CPUs and I had heard that the new Ryzen 4000 series mobile APUs were really good, so that's where I targeted my search.

I ended up settling on the Acer Nitro 5 with the Ryzen 5 4600H CPU and Nvidia RTX 1650 GPU (model AN515-44-R99Q). This rig is categorized as a budget gaming laptop, which is not something I strictly needed of course, but competing general purpose laptops with the same CPU cost about the same price, so I figured I'd get the one with the additional GPU instead of relying upon the APU's built-in graphics so that I could do a bit of gaming with my boys during downtime. The Nitro 5 also has a slot for a 2nd SODIMM (running Ryzen in dual-channel memory mode gives you a lot more performance vs single-channel mode) and has room for a 2nd M.2 drive and a 2.5" SSD if desired.

After about a week of using this laptop, I'm extremely satisfied with the performance. It has 6 cores/12 threads for some major CPU power, and it can run a single core at quite a high frequency for applications that like that. It's very snappy in every day use. Also, the battery life is fantastic and unit keeps cool under normal operating conditions. Even when all of the cores are being used, it gets warm but not unbearably hot. The biggest complaint I've seen in reviews is the display. It's a 60 Hz IPS display with 300 nits of brightness. If I were using this primarily for gaming I might like something nicer, but this display still looks so much better than the one on my previous laptop, which was I think a 720p TN panel. I never even use the display at full brightness anyway, in order to conserve battery power.

Overall a big thumbs up from me. AMD has a real winner in the mobile space with their new APUs. The computing power of this laptop approaches that of my main desktop, which is really impressive. Solid recommend from me.

I recently updated my GitHub profile and I'm putting a copy here for reference, since I doubt too many will see it there.

Hello

Hi, my name is Jason Milldrum and my amateur radio callsign is NT7S. I'm the owner of Etherkit, my business which sells open source electronics and amateur radio products. I open source the hardware, firmware, and software of every product that I develop for sale (and others which I don't sell and only post here for others to use).

If you enjoy my released work, take advantage of it, or just like what I'm doing in general, you can help me by subscribing to my SubscribeStar account. At this point, Etherkit makes enough to keep itself afloat and occasionally funds a new bit of lab gear, but that's about it. Purchasing my products through Etherkit or giving further assistance via SubscribeStar helps me to fund the development of new open source products and software/firmware libraries. I believe in Elmering and giving back to the community when I can, and I definitely plan to do more in this area in the future.

As of September 2020, here's what I'm working on and what is coming soon: - I'm completing my Empyrean campaign on Indiegogo and will be moving it to regular production soon. - Next up I will be finishing work on my amateur radio MEPT (Manned Experimental Propagation Transmitter) named OpenBeacon 2. - Working through the large backlog of issues here on my GitHub repos. I have seen them and I'm not ignoring them, I have had to prioritize other things first. - Smaller projects that are mostly completed, such as a Si5351B/Si5351C breakout board, QRP antenna trap board, and some various boards useful for the workbench. - I definitely want to get back to the development of a QRP transceiver for amateur radio use, much like I almost did with my CC1 project. - I'm also interested in make some easy kits for kids to make, as I have a couple of them in my own home! - Would like to put some more work into the Test and Measurement document that I'm collaborating on with LA3PNA. - How to help get new folks interested in ham radio homebrewing is something I'm also mulling over.

This post will be a little more personal than the usual one, but it does involve Etherkit indirectly, so I needed to vent about it.

As you may have seen in previous posts, earlier this year, during the beginning of the lock down, I used my time to complete a big project I was eager to finish: a new office/ham shack for me. We live in a modestly sized house and our boys needed their own rooms, so my office needed to move. The new office turned out just the way I was hoping, but I haven't been able to use it as much because my boys have been home from school since March.

It now turns out that the Beaverton School District won't be holding any kind of in-person school until November at the earliest. The problem with that for me is that the slap-dash online schooling that the boys received at the end of last year was pretty abysmal, and I haven't seen one shred of evidence this summer that shows that Beaverton SD will implement a better system. Since I don't want my kids to fall behind in their education, we decided to enroll them in an online school this year. We made this choice because if they are forced to attend online school, I'd like them to use a system that is proven to work and has been in use for a while. We also got a couple of positive referrals to this school from acquaintances.

What this means for Etherkit is that I'll be out of the office most of the day, and I will be inside, at the dining room table with my boys as they do school on their Chromebooks. The good news is that enough of my work can be done just on a laptop that I think it won't slow me down too much, as long as I invest in a new laptop soon (currently have a 4th gen Intel i3). So even though I'm a bit bummed that I won't have as much time at the workbench, I believe that it won't slow me down too much. The Empyrean campaign should still be on schedule, as of how things are going right now. We all have to adjust to the current conditions. It's not fun, but I'm grateful that our family hasn't been impacted as badly as a lot of others have, even if it has been a frustrating time.

Thanks for listening and for your continued support!

Two days ago, my GPSDO (which I rely upon in the lab as my 10 MHz reference so that I can do accurate Si5351A calibrations, upon other things) stopped acquiring GPS lock. Nothing significant happened in the lab that I was aware of, so I wasn't sure what the issue was. I was just hoping it wasn't a problem with the GPSDO itself. Fortunately a little bit of troubleshooting allowed me to determine that the coax cable from the antenna mounted on the exterior of the shack to the GPSDO had developed a fault. I shouldn't be too surprised by this, as I was using an old bit of RG8X that I've had seemingly forever. I'm lucky to have Ham Radio Outlet in the area, so one phone call and a bit of a drive later, and I had a new length of LMR400 to use as a replacement. The RG8X gave marginal performance, so upgrading to LMR400 was definitely worth it, as I now have even stronger signal levels than before. It's a good reminder that everything degrades, and you can get bitten by entropy at any time.

Regarding the Empyrean campaign, I'm currently in the process of creating a panelized version of the PCB and sending out for quotes. The components to populate the PCBs are now all on-hand. My goal is to send out the panelized PCB for manufacturing within a week. While I'm waiting on those to arrive, I'll be working on the design of the Empyrean test jig. I already have some toggle clamps for the jig and a rough idea of how I want to execute it. Stay tuned for further updates!

I'm building and testing my first batch of Si5351A Breakout Boards in Shack 2.0. Took a bit of work to get my Python test script converted from running on my previous Linux Mint box to now running on a Raspberry Pi 3B+, but now it's working like a charm.