A brief update to let you know how things are going. I’ve got a long checklist of things to implement in the OpenBeacon Mini firmware, and much of it I can leverage from my old OpenBeacon 2 firmware (although quite a bit of that needs to be refactored and updated). However, one bit that I never implemented properly in OpenBeacon 2 was a menu system, so I decided to tackle that one first, since it will need to be written from scratch.
That’s what I’m working on at the moment. No Twitch stream for today, as I don’t think this would be very interesting to watch as I stumble around trying to figure out a good way to do this in C++. I’ve created a menu class, and I’m working out all of the details and debugging on the desktop PC, so that I can then transfer it to the Arduino environment once it seems to be working correctly. I think it should have that up and running by the end of the day, and that I’ll have another Twitch stream within a few days once I can get back to code that I’m a little more adept at writing.
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!
Please enjoy this write-up of a nifty, compact signal generator project using the Etherkit Si5351A Breakout Board driven by a Teensy LC. What I really love about it is that it uses an 18650 LiPo cell with a small USB charge controller, so that it is very portable. Neat stuff!
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 seriesofarticlesaboutit. 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:
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
9732256178011768 2df8 foreach_test.ino.elf
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!
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.
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:
I saw a recent post on the Make blog about the new cloud ecosystem for Arduino which has been dubbed Arduino Create. Since this will most likely be the future of Arduino, it seemed wise to get an early look at the platform. It includes quite a few features, but the most notable ones in my opinion are the Project Hub, Arduino Cloud (IoT infrastructure), and Web Editor. Arduino Cloud will allow you to connect your network-capable Arduino to the Internet to allow sharing of sensor data, remote control over the net; your typical IoT applications. The Web Editor gives you access to an Arduino IDE over the web. Your code is stored online, and a cloud compiler builds your project, so you don’t have to worry about configuring that on your machine. However, you still have to install an OS-specific agent program on your PC in order to get the complied firmware from the Web Editor onto the Arduino’s flash memory. The Project Hub is a project-sharing space, similar to hackaday.io, Instructables, etc.
I don’t have much to comment on regarding Arduino Cloud, since I don’t have any of the supported devices and cannot try it out at this time. The Web Editor gives me mixed feelings for sure. No doubt that this was created to compete with the mbed platform, which sounds awfully convenient from what I have seen. I like the idea of being able to easily save and share code with others, as well as having a standard set of build tools for everyone. However, the environment is obviously still in early stages, as there is no support for libraries to be added through the official Library Manager JSON list, nor for external hardware definition files to be used. I had some difficulties getting the Arudino Create Agent talking to my web browser in Linux Mint, and once I did, uploading seemed a bit flakier than it does on the desktop IDE. Of course, this is all still in beta, so rough edges are to be expected. Once they get the features of the Web Editor up to parity with the desktop IDE, it should be a very useful tool. Finally, the Project Hub looks nice, but I wonder if we aren’t starting to see too much fragmentation in this type of service for it to be useful. Still, the one-stop shopping aspect of it all is very spiffy.
Something to Watch
Ham radio seems like a natural fit with the citizen scientist movement, so it pleases me to have discovered that some hams have created a platform to advance citizen science in an area where we are well equipped to do so. The new HamSCI website states its mission as:
HamSCI, the Ham Radio Science Citizen Investigation, is a platform for the publicity and promotion of projects that are consistent with the following objectives:
Advance scientific research and understanding through amateur radio activities.
Encourage the development of new technologies to support this research.
Provide educational opportunities for the amateur community and the general public.
HamSCI serves as a means for fostering collaborations between professional researchers and amateur radio operators. It assists in developing and maintaining standards and agreements between all people and organizations involved. HamSCI is not an operations or funding program, nor is it a supervisory organization. HamSCI does not perform research on its own. Rather, it supports other research programs, such as those funded by organizatons[sic] like the United States National Science Foundation.
They already have three listed projects that they are helping with: the 2017 Total Solar Eclipse, ePOP CASSIOPE Experiment, and Ionospheric Response to Solar Flares. The 2017 eclipse is of special interest to me, as totality will be seen at latitude 45°N here in Oregon, which puts it squarely over Salem; a place I will have easy access from which to observe (which also reminds me that I need to build some kind of solar observation device like the Sun Gun before August 2017).
I wish these folks the best and I hope they are able to make a useful contribution to science.
A Challenger Appears
A EEVBlog video popped into my YouTube feed yesterday that was of significant interest to me, and will probably be to you as well. Most of us who are into having a home test & measurement lab are well aware that the Rigol DSA-815 has been the king of spectrum analyzers for the last few years, due to the very reasonable cost paired with the decent amount of bandwidth and load of useful features that are included. Rigol seemed to own this market space since the DSA-815 was released, as the big boys of T&M didn’t seem to care too much about serving us little guys with our small budgets. However, those days are probably at an end, as a new SA to rival the DSA-815 is on the cusp of release. Dave Jones gives a cursory review of the new Siglent SSA3021X, which looks like it will cost only a few hundred dollars more than the DSA-815 but may be significantly better in the performance category. I’d recommend watching the video below, but here’s a summary of the points that interested me:
User interface seems to be heavily “inspired” by the Rigol DSA-815
The Siglent has significantly better DANL
10 Hz RBW available on the Siglent vs 100 Hz on the Rigol (I’ve seen hints that the Rigol was supposed to have a 10 Hz RBW option, but they never released it)
Reference clock and PLL in the Siglent look better
The Siglent has a waterfall display available, which is missing from the Rigol
Dave spotted some potential unwanted spurious signals in the Siglent, but they were low level and his machine wasn’t a release version either.
Also, don’t miss Dave Jones in typical Dave Jones-style refer to a signal with unwanted sidebands as a “dick and balls”.
My impression is that if Siglent can tighten up the fit and finish of this spectrum analyzer, it could give the DSA-815 a real run for its money. This is nothing but good news, as more competition in this space will mean even better products for us in the future. I’ll be watching this one.
Fun with Marbles & Magnets
Finally as a palate cleanser, enjoy this clever kinetic artwork contraption built to play with marbles and magnets!
2014 was a bit of a mixed bag here. It’s been a transition year for Etherkit, as I reorganize and reorient the business for a renewed push to get the CC1 and other new products to market. I believe that good things are beginning to happen there.
On a personal level, my two boys have been doing fantastic. Noah started preschool and is really enjoying it. Eli is at a bit of a difficult age (the Terrible Twos) and is between baby and little kid, but he’s got an amazing personality and is growing up so quickly. Jennifer and I celebrated five years of marriage and 11 years since our first date! Things haven’t been perfect in the extended parts of our families, but at least in our household we’ve all been pretty healthy and have been able to enjoy many blessings.
Si5351A Breakout Board Campaign
There have been a fair number of neat projects I’ve seen using the Si5351A Breakout Board that I posted on OSHPark, along with my Si5351 Arduino library, which is absolutely wonderful. However, I realize that it’s a pain to order PCBs and all of the parts separately, and that a kit or a finished board would be ideal.
I’ve decided to try something new in order to bring the Si5351A Breakout Board kit to market: we’re going to try crowdfunding the first batch of kits. I’m going to set a modest goal to trigger the funding, but all orders will be welcome over the goal amount. In fact, I intend to set a stretch goal at some higher funding level to devote a certain number of hours to improving the Si5351 Arduino library, including:
Add tuning from 8 kHz to 1 MHz
Add tuning from 150 MHz to 160 MHz
Fix the bug that does not allow output over 125 MHz
Implement access to the phase register
Implement sub-Hz tuning for modes like WSPR
Other bug fixes
I also intend on lowering the BOM cost by removing the broadband output transformers, and offering multiple variants of the kit, including the option to add SMA connectors and a TCXO. I’m composing the campaign on Indiegogo right now, and I’m shooting for a launch in about 10 days. I’m hoping to gain experience with this campaign with the goal of using it to fund CC1 kitting later in the year.
Why am I telling you this now? Because I would like to let those of you are are interested in purchasing one (or otherwise interested in supporing Etherkit) get advance notice so that you can order on the first day that the campaign goes live. This will help to give the campaign more momentum and perhaps help to spread the word further. I will be sure to make a blog post here when the campaign goes live and tweet about it as well, so keep an eye on those channels if this is something that intrigues you.
Simple WSPR Transceiver using Si5351A
I came across this simple WSPR transceiver from KC3XM driven by one of my Si5351A Breakout Boards via @wm6h and Dangerous Prototypes. The WSPR transmitter is simply a BS170 driven by one of the Si5351 outputs, which is buffered by a logic gate and keyed by a standard PNP keying switch. Control of the Si5351 and keying of the transmitter is performed by a plain vanilla Arduino Uno (the code has been posted to GitHub).
This looked so simple to build that I had to give it a try. I quickly built up the transmitter portion, tacked on a 10 meter LPF (the original version is for 30 meters), modified the code for my callsign and grid, and changed the Si5351 output frequency to the 10 meter band. The transmitter put out nearly exactly 1 watt of RF (with only about 1.2 watts of DC input total) into 50 ohms and ran quite cool. Hooked up to my Moxon, it had no problem generating spots when pointed east and started on an even minute so as to properly synchronize. Fun stuff!
If you haven’t been following the blog of KO7M, you should be. Jeff has been doing a lot of experimentation with with NB6M and other home experimenters in Washington state, especially with stuff like the Minima and using microcontrollers in ham radio projects.
Lately, Jeff has been working on getting an Arduino to output PSK audio. He has a series of recent posts about it, but thesetwo are probably the most important. The character timing is not quite right yet, but the basics of how to generate PSK via PWM audio signals are here. Good stuff!
Si5351 and Raspberry Pi
Another really great homebrewer blog is M0XPD’s Shack Nasties (oh you Brits and your silly names) blog. Paul has been doing a lot of work with the Si5351 as well, and his latest post about the Si5351 is details of how he interfaced it with the Raspberry Pi. Excellent information to have, as the RPi is of course much more powerful than your garden variety Arduino.
I appreciate all of the interest in the Si5351A Breakout Board that I have available on OSHPark. I apologize for not having this available sooner, but here is a GitHub repository which hosts the KiCad design files and a PDF of the Breakout Board schematic, which lists the part numbers for the reference oscillator and the output transformers so that you can order your own. Also the few passives on the board are size 0805.
This, along with either the avr-gcc library or the Arduino library, should get you going in generating all kinds of clocks and local oscillators. While this board seems to work fine in interfacing with the 5V Arduinos that I have, I worry that comms might be iffy, so I’m going to add simple MOSFET-based level conversion to the next iteration of this board. Keep an eye on the blog for further developments in this area.
A few exciting developments here on the Si5351 front. First off, I took the C code from my Si5351 library for avr-gcc and converted it to an Arduino/C++ library, which you can find here. It replicates the functionality in the avr-gcc library, but makes it quite a bit easier to rapidly implement designs. I’ve tested this design on an Arduino Uno and an Arduino Uno clone, but I see no reason why the library shouldn’t work on other Arduino variants as well. Please give it a try and leave feedback on the GitHub page if you find bugs or have suggestions for improvements.
The other news is about the Si5351 Breakout Board that I mentioned in the last post. I just got the 3 purple PCBs back from OSHpark and they are most excellent.
I got one quickly populated with components and paired it with an Arduino in order to test the new library. As you can see in the photo at the top of the post, it’s a pretty small little board, but it’s pretty powerful for its size. All you do is connect VCC, GND, and the I2C SDA and SCL lines to the Arduino, and you get three independent transformer-isolated outputs on SMA connectors that can generate 1 to 150 MHz (in the future the library will be modified to allow the full 8 kHz to 160 MHz range)
Will I end up selling these as a kit? I’d like to but I’m uncertain at this point. Oddly enough, I just found out that it’s highly likely that Adafruit will also be selling a Si5351 breakout board. If you watch the video below at about the 6:22 mark, you’ll see it.
I’m a bit surprised by this, as RF is not something that I was aware that Adafruit was interested in. To be honest, it will be difficult to compete against the relatively much larger fish in the hobbyist pond that is Adafruit. Although, it looks as though my breakout board has something that the Adafruit board does not: isolation output transformers. Most likely, I will do one trial kitting run and see if there will be enough interest for another after that. Keep an eye on the blog for further news about that in the near future.