Empyrean, Etherkit, OpenBeacon Mini

OpenBeacon Mini Status – Early June 2018

It’s time for a brief update on how things are going with OpenBeacon Mini, the successor to the OpenBeacon MEPT that’s been a long time in the making. For those who are unfamiliar with the new project, allow me to give a very brief overview of its capabilities. The OpenBeacon Mini is an automated transmitter for amateur radio operators that allows for automated transmission of messages using propagation study modes such as WSPR and QRSS, along with many of the other JT modes and CW as well. The carrier is generated by a Si5351A clock generator IC which is fed with a TCXO reference clock for frequency stability. Low-pass filter plug-in band modules allow operation on any single band from 630 meters to 2 meters. The OpenBeacon Mini detects which band module is inserted and sets the frequency accordingly, making band changes as easy was swapping out a plug-in module. The power and a data connection is provided from a USB micro B connection to any PC. Accurate time synchronization is accomplished through this connection, as long as the PC has time set through NTP. The user interface is a 128 x 32 px OLED display and 7 pushbuttons. As always with Etherkit products, all firmware, hardware design files, and and software is open source. Extra pins from the microcontroller and extra clock ports from the Si5351 are broken out for use in experimentation and expansion.

Something like this project has been on the back burner for a long time, and is finally now able to see the light. I intend to launch this as a crowdfunded product at the same time as my Empyrean microcontroller, which is at the heart of the OpenBeacon Mini. The Empyrean is an Arduino Zero derivative in the form factor of small DIP module perfect for breadboarding. I’ll have more about this initiative to post on the blog in the near future.

My first beta tester, LA3PNA, recently received his OpenBeacon Mini and had a chance to put it on a NVIS antenna for a few hours on 60 and 20 meters. As you can see from below, he received plentiful WSPR spots in that short amount of on-the-air testing.

I have another early beta tester working on getting his OpenBeacon Mini on the air soon as well. I am looking at getting one more early beta tester going with this PCB spin, just so that I can be very sure that the next PCB spin will iron out all of the kinks. If you are familiar with MEPTs, using the Arduino environment to compile and load firmware, and don’t mind a little bit of firmware roughness, I’d love to have you on board. Send me an email to milldrum at gmail dot com to let me know you’re interested.

This weekend, I plan to get OpenBeacon Mini going on 6 meters in order to see how it performs there. It should be a perfect time, since it’s also the weekend for the ARRL VHF Contest. Keep an eye on my Twitter account and this blog for further updates on this project.

Computing, Empyrean, OpenBeacon Mini

OpenBeacon Mini Progress

I know it’s been quiet on the blog front. It’s because I’ve been working through some tricky issues with OpenBeacon Mini firmware. A long story, but the gist of it is that a timer subtlety was causing some hard-to-troubleshoot problems causing inconsistent transmit timing for WSPR. I’ve finally overcome that particular family of bugs, and now have the transmit working reliably. As you can see, I’ve put OpenBeacon Mini on the air for the first time and it’s receiving spots. Now that I’ve confirmed that the basic functionality is working, I need to fill out a few more firmware features and then actual beta testing can start, which shouldn’t be very long now.

On another note, I’ve also been doing more PC and PC parts hustling on OfferUp in order to fund an upgrade to my main workstation. I managed to snag a Ryzen 5 1600 for a good price at $159 at Fry’s, since the new Ryzen refresh CPUs were just released. I’ve been using it for a few weeks now and it’s a fantastic processor. It also handles OBS much better than my old i3, so when I do get back into streaming on a more regular basis, my stream quality should be even better yet. From my testing, I should now be able to push out 1080p 60 FPS video to Twitch with no problem now.

Stay tuned, as the news around here should pick up again.


Si5351 Library Mbed Port

A quick note to let you know that courtesy of David Mills, G7UVW, the Etherkit Si5351 Arduino library has now been ported to the Mbed platform. He reports that it seems to be behaving the same as the Arduino library, so if you’re an Mbed user, definitely go check it out. I was giving some consideration to making this port, but I’ve got so much other stuff on my plate at the moment that I just hadn’t got around to it yet.

Three cheers to David for this! Huzzah! Huzzah! Huzzah!

Arduino, Etherkit, OpenBeacon Mini

A New Arduino Library Appears!

Since I’m waiting for circuit boards for OpenBeacon Mini to arrive, I want to keep the waiting time as productive as possible, so I’ve been working on the firmware. Specifically, one of my recent goals was to factor all of the modulation code out of the spaghetti mess that is the current state of the OpenBeacon 2 firmware (which is my starting point for OpenBeacon Mini).

In that vein, today I managed to finish up work on release v1.0.0 of the Etherkit Morse Arduino library. The majority of the coding work was done during my last few Twitch livestreams, so other than tweaking and cleaning up the code, most of the work today consisted of creating documentation and getting the repository in shape to be a proper Arduino library.

The way that this library functions is quite simple. Since timing in Morse code sending is critical, the end user of the library is required to provide a function that calls the library’s update method every one millisecond. This type of interface was chosen so that the library can be platform agnostic (since Arduinos come with different microcontrollers which have totally different timer functions). An transmit output pin and speed in words per minute is specified when the class in instantiated, and then all you have to do is call the class’s send method to send Morse code on the digital output pin. Alternately, you can have your sketch poll the class’s tx variable and act on it accordingly. Pretty easy stuff.

I’ve put in a request for the library to be included in the official Arduino Library Manager, so if you want to give it a try, wait a day or so for it to be listed there. If you really can’t wait, there are instructions in the README about how to manually install it. Hopefully you find it useful, and as always, please file your bug reports and suggestions for improvements as an issue on GitHub. Thanks!

Empyrean, Etherkit

OpenBeacon Mini Proto PCB Layout Complete

I managed to finish the layout of the OpenBeacon Mini prototype PCB in KiCad this evening while livestreaming on Twitch. A 3D rendering from KiCad is above. It looks about how I sketched it out and wasn’t too nasty to route, so I got that going for me. So I’ll get on order off to the PCB fab soon. I’d like to get some PCBs completed before Chinese New Year, so I can’t delay very long.

While I’m waiting for my PCBs to be manufactured, there’s still plenty to do. Twitch streaming is kind of nerve-wracking for me yet kind of fun, so I plan to do more. I have a little more gear on the way that will allow me to also Twitch stream from my workbench, so that you can spy over my shoulder there as well. I even have a USB webcam for my microscope so I’ll be able to connect that to Twitch for your viewing pleasure. Stop by sometime on the livestream and chat me up.

Empyrean, Etherkit, Meta

The Road Forward

Per my last blog post, I’ve completely deleted my Patreon account. Those days are over and are not coming back. I’m still not sure what will replace it, or if anything will. It is already difficult for me to ask for money in return for mostly intangible benefits. Losing the Patreon monthly income will hurt a bit, as that was the funds I was using to pay for OpenBeacon Mini (and other project) development. I only sell a modest amount of the Si5351A Breakout Boards via Etherkit; basically just enough to pay for keeping the lights on there for now.

So allow me to start using this blog again for what I was doing on Patreon, sans the locked content.

OpenBeacon Mini has a schematic finished and I’m just about ready to lay out the PCB. Empyrean (my Arduino Zero derivative) testing is going to be delayed a bit while I figure out how to fund the beta batch. Those two projects are going to be my main focus and I hope to be going into release with both of them by Q1 2018. Further down the line, I don’t want to speculate too much, but I’ll probably tidy up and finish some half-finished smaller boards that I want to add to my Etherkit lineup in order to fill out the catalog with some more RF products.

I’ll work on ramping up the blogging here, using my own site much as I was using Patreon: to post smaller updates about project progress. I always felt the need to make more substantial posts here, which often deterred me from writing. I believe that was a mistake. Expect to see more content in line with microblogging here in the future. Thanks for hanging in there.

Arduino, Coding, Microcontrollers

Arduino C++ Investigations – Introduction

As mentioned in the last Wideband Transmission, I recently viewed a presentation from CppCon 2016 which convinced me that a lot of my preconceived notions about the (lack of) suitability of C++ for use in microcontroller applications might be misplaced.

The standard lore (go ask Wes Hayward W7ZOI his opinion of lore) states that C++ is inefficient in generating the compact binaries that are required when using a device with very limited program storage and RAM space, as you will find with microcontrollers (especially 8-bit controllers). Given that C is a probably fairly categorized as a mid-level language, and that C++ easily falls into the high-level language category with its much larger feature set, it seems natural to believe that there has to be an overhead cost to pay when using C++ over C. Yet, if you take the time to watch that video, you can see that it is possible to use advanced features of C++ and incur little to no overhead in the binary.

Not to say that you can just blithely use C++ without the possibility of incurring an overhead penalty. I’ve tried it and had some horrible results, and chalked my experience up to the old lore being correct as a general case. But that’s obviously not true.


What I intend to do with this series is to look into ways that the features of C++ (mostly C++11 at this point) can be leveraged in the Arduino environment to take advantage of the advanced features of the language (and perhaps even things such as the Standard Template Library) while incurring no or perhaps a very small penalty in flash and RAM usage.

As most of you are probably aware, Arduino is based on C++, and every Arduino library coder has to use at least minimal C++ functionality in order to create a library. However, in the name of abstracting away much complexity, Arduino sketches are written more in C-style than modern C++. That being the default case, there’s no reason we can’t incorporate more C++ coding techniques into our Arduino sketches, as long as doing so serves our purposes of being able to use the higher-level abstractions without paying a penalty.

Before seeing the above presentation, I had already been thinking about this topic because good old Hackaday has been running a series of articles about it. While I may cover some areas previously addressed by said articles, I notice that many (but not all) of the previously mentioned posts don’t delve into making the measurements of how implementing the C++ coding patterns affect code and RAM size (or perhaps execution speed). Data is king, so I intend to provide as much of it as possible so that you can see actual proof of the effects of migrating to C++ coding.

Just so you know where I’m coming from, let me tell you about where I’m at in my journey as a coder. I’ve been writing C for microcontrollers for a fair bit of time now, and I think I’m at least proficient at it, but not an expert by any means. I’ve dabbled in C++, but never really written any major programs in it, so I’m on a learning journey here as well. I’m sure I probably won’t do everything perfectly or the most efficiently, but by holding to what the data tells me, I think I can provide some useful information to all while I learn some new things for myself.

Areas of Investigation

At this point, I don’t have a list of topics for this series that is set in stone. I do have some initial ideas for investigation, but plan to follow other leads as they present themselves and as I learn more about this topic. From my initial notes, here are some potential topics you may see in future posts:

  • Using constexpr
  • C++ Standard Library and Standard Template Library usage
  • Using lambda functions/inline functions
  • Variable declaration: auto vs explicit
  • Other C++11 features, such as the new for loop syntax that functions as a foreach

Please feel free to comment below if you have some other topics of potential interest.


In order to maintain consistency across the series, I intend to use the same microcontroller platform in all articles. The controller of choice will be my Empyrean Alpha board, which is basically an Arduino Zero minus the debugging circuitry on a form factor that can be plugged into a solderless breadboard, just like the Arduino Nano and related products. The Empyrean Alpha uses an Atmel ATSAMD21G18A microcontroller, which runs with a 48 MHz clock speed and has 256 kB of flash program memory and 32 kB of RAM, which is ample for many types of projects.

Hopefully in the near future, I’ll be selling the Empyrean Alpha and its little brother Beta through Etherkit, so stay tuned for further news on that.

The Arduino environment for ATSAMD microcontrollers uses the arm-none-eabi-gcc toolchain, which has a variety of very nice tools that are available in addition to the compiler. One of those is arm-none-eabi-size, which can give a breakdown of the flash and RAM usage of a sketch simply by feeding it the file name of the ELF file that the compiler generates. For example:

jason@oberon /tmp/arduino_build_994621 $ arm-none-eabi-size -B foreach_test.ino.elf
   text    data     bss     dec     hex filename
   9732     256    1780   11768    2df8 foreach_test.ino.elf

From the above, you can see the text section, which indicates size of the program in flash memory, the data section, which is the initialized variable storage in RAM, and the bss section, which is allocated but uninitialized variable storage in RAM. Pretty easy to use and interpret. We’ll talk about this tool a bit more in the first investigation so that we have a good understanding about it.

Most likely, I’ll also be using the Compiler Explorer tool, as was used in the video above. It looks like a very handy way to quickly and roughly demonstrate how code changes affect the assembler output from the compiler.


Now that we have the preliminaries out of the way, I’m ready to start tackling this series. Watch this blog for the first installation, which will be coming soon. My patrons will have early draft access to articles in the series, and will have a chance to chime in there with suggestions to help me with the final article on nt7s.com. See you soon!

Arduino, Etherkit, Microcontrollers, Test and Measurement, Test Equipment, Wideband Transmission

Wideband Transmission #10


If you’ve been reading my blog for any amount of time, you’ve probably observed that I’m a big fan of all things open source, especially on the hardware side of things. One area where OSHW seems to be lagging a bit is in the test & measurement department, so it was a very pleasant surprise for me to stumble upon a fairly new channel on YouTube about a month ago.

As you can see from the first video, the presenter (sorry, I couldn’t find the name of the bloke who makes these videos) gives an overview of the cheap logic analyzers on the market that can be loaded with open source firmware and then gives a very detailed demonstration on how to use the devices with the nifty open source Sigrok T&M suite (especially the PulseView GUI tool) and how to use a Linux environment and scripting to take measurements.

If you have any interest in this space, this is definitely a channel to which you should subscribe. There is also a show notes site that has links and other resources for the videos.

Using C++ in Arduino

In another case of me stumbling upon something which takes me down a rabbit hole, last week I was watching coding videos on YouTube when this one was recommended in the comments of another:

It’s quite a long video, but if you have any interest in coding and are an old fart who grew up with 8-bit personal computers (or are at least a fan of retrocomputing), then the time will pass quickly on this one. It sounds crazy, but the presenter (Jason Turner) of this talk was able to make a game for the Commodore 64 in modern C++! The way he did it was to create a tool to convert from the 80386 flavor of x86 assembler to 6502 assembler (well really 6510 in this case), which apparently is more feasible than you may think. His development environment is an online tool called Compiler Explorer, which for some reason I only learned about with this video. It automagically spits out assembler from C++ compiled from a variety of different compilers. In this case, the Turner created a custom local version of this tool to do the 6502 conversion.

I was gobsmacked at multiple times in this video. Many of the newest C++ features (from the C++17 standard) were used. With some careful coding, Turner was able to produce code with literally no overhead from all of the C++ features. The compiler was able to optimize many lines of C++ down to a handful of assembler op codes. Just watch it, you’ll be amazed as well.

This video, in conjunction with the series of posts that Hackaday has been running about using C++11 in Arduino, has convinced me that it would worth it to investigate the use of C++ in the Arduino coding environment. Arduino library coders already have to use a base level of C++ when they write for the ecosystem, but most people who write sketches do it in vanilla C-style (well, the bastardized Arduino version of it anyway). After seeing that talk, I had a lot of preconceptions of C++ overhead blown away. The ability to use the modern features of C++11 sound tempting indeed, so I plan to do some investigations into the feasibility of incorporating more C++ patterns into Arduino sketches, and I’ll be posting my findings here. Stay tuned.

KiCad PCB Rendering Tool

I have a habit of skimming my RSS reader (yes, I’m one of those old fogies who still uses one) in the morning while drinking my coffee, opening tabs of interesting things to examine in further detail later, while simply reviewing the rest of the new posts. Sometimes that means it takes me a bit to get back around to something intriguing among my many browser tabs.

Such is the case with this article from Hackaday. It’s just a short blurb about a new open source Python tool for making 2D renderings of KiCad boards. The attached demonstration image certainly looked nice. When I finally got around to downloading the code from GitHub and trying it out on one of my designs, I was pleasantly surprised. The script made a very sharp SVG rendering of my board, but unfortunately, there are only a handful of components in the PcbDraw-Lib library, which meant that most of my stuff didn’t get rendered.

Since I’ve been looking for a way to make nice illustrations of my PCBs for documentation and promotional purposes, I decided that I’d invest some time in adding components to the library, since I think the project has a lot of promise. After about half a day of muddling through making component drawings in Inkscape by studying datasheet engineering drawings, I was able to output a complete render of my Empyrean board, which you can see above. I’m quite happy with the result.

I’ve got a pull request in for the components that I’ve created so far, and as I continue to use the tool and fill out more of the library, I will continue to submit them upstream. While it’s still pretty rough around the edges, this project gets a strong recommend from me.

Etherkit, Microcontrollers

Market Research

It has been awfully quiet on the public front here for sure, but I have been working on quite a bit of things behind the scenes here at Etherkit Galactic HQ. It’s been a challenging year since I last wrote about the personal things going on here, but things have been going reasonable well after a rough half-year immediately following that post. I’m just about ready to attempt to revamp Etherkit, however there are still a few challenging roadblocks to overcome, and I could use a bit of guidance.

The most difficult issue is trying to re-bootstrap the business financially. I’m currently only selling the Si5351A Breakout Board, which obviously isn’t enough to expand a business upon. The possibility of a capital infusion unfortunately broke down, and so the only practical way forward at this point is most likely another crowdfunding campaign.

As mentioned in the opening paragraph, I have been working on various projects, and so I do have some candidates. Many of the projects that are in the works or only even in the planning stages require the use of a microcontroller, and so last year I decided to make my own Arduino-compatible microcontroller board family which I can then use as the heart of many of these products. I’ve taken a real liking to the Arduino Zero because of its speed and features, but the cost is fairly high and the standard Arduino form factor isn’t great for many purposes. Therefore, I have decided to make a new standalone board derived from the Zero which I call Empyrean, and you can see in the photo at the top of the post. It comes in two flavors: Alpha and Beta. The Alpha is based on the Atmel ATSAMD21G18A microcontroller, same as the Arduino Zero. The Beta uses a controller (ATSAMD21G16B) with a bit less flash and RAM than the Zero (but still more than an Arduino Uno), but is also priced similarly to the ATmega328 line of microcontrollers. Both come on a small board similar in size to the Nano and has nearly all of the same circuitry of the Arduino Zero except for the EDBG support.

It is true that there are a flood of Arduino clones out there and this makes entering the market with another one somewhat crazy. My value proposition for Empyrean is based on the confluence of breadboard-friendly form factor along with a wallet-friendly price. My target price point is around $15 for Alpha and $10 for Beta. While that is a fair bit more than your typical eBay Nano clone, Empyrean would also be quite a bit more powerful than a Nano, in both clock speed and available memory. So my question to you, dear reader, is whether you would be interested enough in this product to back a crowdfunding campaign in order to have it made? I do plan to make a serious push on a radio soon, but it would be nice to ramp up the business before that, while also solidifying the microcontroller platform that will be used in future products. Let me know what you think in the comments, or send me an email.

In the mean time, I thought I’d let you know that I’m working on a Rev D board spin of the Si5351A Breakout Board. You can see a prototype in beautiful OSHPark purple above. The most significant changes in this revision will be to change the coupling of the reference oscillator to the Si5351 XA input pin to meet datasheet specs and to panelize the board in preparation for future pick-and-place operations (they are currently hand-assembled!).

Perhaps even more interesting is that I also hope to be able to soon offer a frequency calibration report with every board sold. Thanks to LA3PNA, I am now in possession of a decent 10 MHz GPSDO to use as a lab reference, which will allow me to measure the frequency correction value accurately enough for hobbyist usage. I now have a small printer on hand, and so now what I need to do is add new code to my board test script to measure the correction value and print it for inclusion with each board sold. Stay tuned for notification when I’m ready to go live with this; hopefully soon.

Let me reiterate: I’d love to hear your thoughts about the above proposals. I’m interested in serving the needs of my customers. Thank you!

Coding, Etherkit, Microcontrollers

Break My New Library

I know that the updates here have been extremely sparse. For that I do apologize. Things are slowly starting to settle into a new normal around here, and I’ve been able to regain the ability to put time back into work. There’s a large to do list on my whiteboard, and many of the things on that list depend on improvements and bug fixes to the Si5351 Arduino library. So that has been my first priority as I dip my toes back in the water.

There were quite a few features of the Si5351 that the older versions of the library did not support, such as all of the 8 outputs of the variants excluding the A3 and the VCXO of the B variant. Also, there is a pretty big bug in how the tuning algorithm handles multiple outputs assigned to the same PLL, which causes tuning errors to crop up.

Therefore, I decided in one fell swoop that I needed to totally rewrite the tuning algorithm and add support for as many of the neglected features as I could before moving on to other projects involving the Si5351. Over the last month, I’ve been hacking away on the code in my spare time, and I’m glad to finally be able to announce that a beta version of the Si5351 Arduino v2.0.0 library is ready for public use.

Because it’s such a drastic change to the underlying code, I’d like to have it in limited beta release before doing a final release via the Arduino Library Manager. So that means that if you would like to try it (and I encourage you to do so), then you’ll need to install it manually, which isn’t terribly difficult.

Go here and click on the green button on the upper right that says “Clone or download”. Select “Download ZIP”. Next, find where on your filesystem your Arduino libraries folder resides and delete the existing “Etherkit Si5351” folder. Inside the ZIP file you just downloaded, there is a folder entitled “Si5351Arduino-libupdate”. Unzip this folder into the Arduino libraries folder, and then restart the Arduino IDE.

Since this is a new major version release, I took the opportunity to tweak the interface a bit, which means that you’ll have to adjust your current code to work with the new library (but fortunately not too much). You’ll find the details on how to do that here.

Please check out the updated documentation on the GitHub page, as it has been greatly expanded and should explain all of the new features in detail. Also, quite a few new example sketches have been added to the library, which you can find in the usual place in the Arduino IDE. I encourage you to try the new library in your existing projects, as it should be a bit more streamlined and stable. Also, there is plenty of opportunity to make new projects with the B and C variant ICs. If you do encounter any problems with the new library version, I would like to strongly encourage you to use the Issues feature of GitHub to let me know so that I can get on to fixing it as soon as possible. When I’m satisfied that there are no big show-stopper bugs in the code, I’ll merge it to the master branch of the repository and tag it for release via the Arduino Library Manager, but I need help in testing it before I can do that.

Once there’s a stable release of this version of the library out in the wild, then I’ll be able to move forward with other projects based on this Si5351. With any luck, some more interesting things will be coming from this shack again in the near future. Thank you for all of your help and support!

Edit: an exclusive look into the development process: