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.

Goals

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.

Tools

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.

Onward

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!

Rattling the Cup

It's not easy for me to admit that I need help, but sometimes one has to swallow his pride a bit and do that in order to move forward. Now is one of those moments for me. As I noted last year, it's been a bit of a tough time for my family lately, and my ability to work on Etherkit and to give to the community in ways such as blogging and contributing code has suffered quite a bit.

I'm ready and excited to move ahead but frankly, resources for continuing these endeavors are quite tight, as I am not able to divert them from the family income and I don't really make anything from Etherkit at this point. I realized that it would be extremely helpful to have a monthly income for use in advancing the work that I do in electronics and radio, even if it is relatively small.

Therefore, I've setup a Patreon account in order to attempt to give me that bit of regular income so that I can focus more on content creation. If you are not familiar with it, Patreon is a way for creators to ask for pledges from those who value their work. You can ask for either monthly or per-creation pledges. I've decided to ask for a monthly pledge since I intend to increase my output by a fair amount (and my discrete creations usually aren't as intensive as something like making a professional video).

I do realize that it's a bit cheeky to ask for pledges at this point, when my output over the last year has been quite sparse. I would say that if you have received some value from my previously released work, then please consider how becoming my patron would help me to produce more content for free public release in the future. If you don't wish to fund me at this time, I only ask that as I ramp up my output over the coming months that you consider becoming a patron when you are satisfied that I'm producing enough quality content to make it worth your while.

Also, one nice side benefit of Patreon is that it also functions as a microblogging platform, which is something that I've been thinking about for a while. It's a bit easier for me to post more often when I can catch a few quiet minutes during the middle of my busy day.

So I would greatly appreciate it if you head over to my Patreon page to read my pitch and consider becoming my patron. There will be some exclusive perks to becoming a patron, including access to me on a private chat room, exclusive patron posts where I discuss and show off what I'm working on, and information on upcoming Etherkit releases. Thank you!

Wideband Transmission #10

OpenTechLab

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.

Nice DSA815 Upgrade

I know that quite a few of you are, like me, owners of the Rigol DSA815-TG. It's been a reliable workhorse in my lab since I've acquired it, but the one thing I believe that I've wanted to most from it is a an RBW minimum of 10 Hz instead of the specified 100 Hz. That would allow for better characterization of narrow filters like crystal ladder filters and would let you better see fine details about signal.

Well, it looks like today is our lucky day. I've received an email from Rigol that indicates that a new firmware update is available that will turn on 10 Hz RBW! Quoth Rigol:

Improved RBW -- We have improved the RBW spec on the popular DSA815 to 10Hz. This improvement provides users with greater frequency resolution and lower noise floor. 10Hz RBW is now specified on all of our DSA800 Series (1.5GHz, 3.2GHz, 7.5Ghz)

...

Existing DSA815 owners at 1.09 FW or above can upgrade to the latest 1.18 FW version to activate the 10 Hz capability.

Download new Firmware.

I believe that the link provided at the end of the email was a custom tracking URL for me, so I'll direct you to the Rigol NA DSA800 product page, which has a link for acquiring the latest firmware. Make sure that you are getting the 1.18 version of the firmware. The installation is a snap and the RBW improvement is an exciting new feature to get for free. Thanks Rigol!

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!

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:

Linux Mint 18 Has Arrived

Those of you who have followed my blog for a while may be aware that our household has relied upon Linux for years. Earlier on, it was Ubuntu, and then later I migrated to Linux Mint shortly after the Unity environment was released for Ubuntu. I do have a dedicated Windows box for use in my Etherkit shipping station and I have dual-boot Win 10 on my notebook, but I only use Windows when forced. Otherwise, I much prefer Linux Mint, even on my ham shack PC.

Today is an exciting day for us Linux Mint fans, as the newest long-term support release, version 18 (code name "Sarah") has been officially released! Mint is derived from an Ubuntu LTS release, and the version 17 family was based on Ubuntu 14.04, which dates from 2014. Linux Mint 18 descends from Ubuntu 16.06, so there will be updates to the core software compared to version 17. (You can manually update most of these packages in an older release, but there's always a risk of corrupting your installation, so it's usually not worth it if you value stability).

Speaking of corrupting your system, I recently tried to update the kernel on my ham shack PC running Linux Mint 17.3 and messed up the system so bad it wouldn't even boot. Rather than try to spend the time doing a recovery, I decided to install the Linux Mint 18 beta last week and give it a spin. My initial impressions from working with it over the last week are very positive. The shack PC is very modest, using a cheap AMD Athlon 5350 APU (I guess that's their name for their integrated CPU/GPU/SoC) with integrated Radeon graphics. Under Mint 17.3, the Radeon graphic support was kind of terrible. The proprietary fglrx driver kind of worked but was glitchy as hell and the open-source driver had absolutely terrible performance. Under Mint 18 with the newer AMD open source graphics drivers, the machine performs as expected, which is a relief. The Mint-Y theme looks fantastic, and I think I much prefer it over the default Mint-X.

Linux has truly come a long way on the desktop. If you are a Windows user who has dabbled in Linux previously but found it a pain to get working, you should try Linux Mint 18 on live OS installation to see how far it has come. Much more "plug-and-play" than just a few years ago. Grab that ISO torrent, image it to a USB drive, and give it a whirl!

Wideband Transmission #9

Arduino in the Cloud

Selection_108

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.

Selection_110

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

Selection_109

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!

 

TDS1012 LED Backlight Retrofit

Back when I was working at Tektronix (wow, this summer it's been 10 years since I graduated with a AAS in EET and started at Tek), they had a one-time program where an employee could purchase a new TDS1000/2000 series oscilloscope for half of the list price. This was back in the day before the era of cheap and decent Chinese-manufactured scopes, so naturally I jumped on the deal. Even though I wanted more, I found that I could fit the TDS1012 into my budget (list price was a bit more than $1000 at that time).

The TDS1012 was a very faithful instrument on my bench for many years. I came to depend on it quite heavily. Too heavily, in fact, as I left it on a lot. Not thinking about the ramifications of it at the time. A few years ago, the backlight in the scope started fading, and not long after that, gave out completely. I figured I could just replace the display module, but finding a replacement turned out to be more difficult than I anticipated. Tektronix repair didn't stock it by the time that I inquired about it, and I could not find any through the back-channels that I checked with my Tektronix contacts. Even looking for NOS on eBay was fruitless (although later on, some grey market displays started turning up there for expensive list prices).

TDS1012-2

Eventually I gave up hope of realistically finding a replacement display and tried to sell the scope, although not very enthusiastically. The scope stayed in this state for quite a while, until I found something fortuitous. One of my favorite vlogs is The Signal Path, and Shahriar recently released a short video about repairing an VNA with a broken CCFL backlight with a LED replacement.

I'm not sure why it never occurred to me to try this, but I was grateful to have seen a path forward with the TDS1012. I didn't even know that there existed LED backlight upgrade kits, but I shouldn't have been surprised. Long story short, I ordered a handful of parts from eBay and took a chance, and was rewarded with a working display that was able to bring my beloved TDS1012 back from the dead! I'll give you some details below so that hopefully this can be of help to others in the future.

Bill of Materials

LED Backlight Upgrade Kit (there's a wide variety of these available on eBay)

s-l1600

XL6009 DC-DC Boost Converter

s-l1600 (1)

5 kΩ trimmer potentiometer
4.7 kΩ resistor, 0.25 W
Kapton tape
RTV silicone
Epoxy

The Details

The first thing to do was disassemble the TDS1012 so that I could get to the guts. Fortunately, I had done this in the past, so I knew exactly what to do. It's actually quite easy to do in the home lab with just two tools: a deep Torx T15 screwdriver and a small pair of hook-nosed tweezers. Pry off the knobs on the front panel by wedging the hook-nosed tweezers in the gap between the knob and panel, and then using them as a lever.

IMG_20160429_131507

Remove the back case from the instrument by unscrewing four T15 screws: one on the bottom-left, one on the bottom-right near the AC power connector, and two hidden under the fold-up handle.

IMG_20160429_131909

Next, the front panel can be removed by unscrewing five T15 screws: one on each corner and one hard-to-find screw that is between the CH1 and CH2 BNC connectors (on the back of the chassis). You can see side where those screws need to be removed from the chassis in the photo above.

IMG_20160429_132622

Once the front panel is off, you can now remove the display module. There are two cables to disconnect: the CCFL backlight cable going to the HV supply, which is on the top-left of the above photo, and the data cable which is on the right side (unseen in the above photo). Disconnect the CCFL cable and the data cable from the main board, and then remove the four T15 screws from the four corners.

IMG_20160429_132908

Now with the display module removed, you can see where the CCFL lives on the left side, under the beige plastic. I removed the Kapton tape securing the CCFL leads to the module, and then tried to pry the plastic apart at what looked to be interlocking snap tabs.

IMG_20160429_155106

IMG_20160429_155152

That turned out to be a bit of a mistake. The plastic was quite brittle and broke on the back side, including a few fragments from each end that snapped off completely. I think I should have removed that tiny screw that you can see on the center-left of the front of the display module before trying to take the CCFL out.

IMG_20160429_155409

There is some metallic foil that loops around the CCFL. I used a craft knife to slit it down the length of the display, freeing the CCFL from the module.

IMG_20160429_155551

You can see the burned-out CCFL in the photo above, removed from the display module. Now that the defective part was removed, it was time to figure out how to rig up the new LED backlight.

IMG_20160429_130610

Here you can see the LED module as packed by the seller. I was pleasantly surprised. Quite nice and secure.

IMG_20160429_130720

And here is the LED kit. This kit was made for a 15 inch monitor, so I would only need part of the LED strip. As was the case with other LED strips I've used, this module was wired so that groups of three LEDs were in series, with each of those groups in parallel with each other. I cut the LED strip at a multiple of three at a size that would fit where the CCFL used to live. Be very careful with this strip, as it is quite fragile and could easily break at the length it is shipped (which I'm sure it why the seller packaged it so well).

Next, I lashed up the LED driver module on the breadboard to see how it should be wired. As is common with these eBay modules, the documentation is pretty lacking, so I had to put in a bit of work to make sure I got the wiring right. There are four input pins on this module: VCC, GND, ENB (enable), and DM (dim). A bit of experimentation showed me that you needed to tie ENB to VCC and that DM could be fed using a simple voltage divider with a trimmer and fixed resistor to provide an adjustable voltage to DM that ranged from about 0.5 VCC to VCC.

IMG_20160505_121202 (2)

The product page recommends that the DC input be at least 10 VDC, and when driving it with >11 VDC the LEDs were quite bright. Any voltage below about 9 VDC, and the LED just won't light. In a lot of instruments, that may not be a big deal, but it was a problem with the TDS1012. It turns out there is no 12 VDC available, nor anything even close. The only other appropriate DC voltages available from the power supply are 6 VDC and 3.3 VDC. But the module just won't run on a voltage that low. I identified the IC on the LED driver module to be a DF6113. By the looks of the datasheet, it should be able to function as both a boost converter and constant current source for the LEDs, but this particular module will not run at 6 VDC.

A bit of half-hearted reverse-engineering showed me that while the DF6113 has the capability to function as a boost converter, that functionality was not being used here. In the reference design on the datasheet, it shows it being used as a boost converter with an LED output which is ground-referenced. However from what I could suss out of the eBay module, this one was configured to not be ground-referenced. Instead, the lower potential terminal of the LED driver was set at approximately 9 VDC lower than the input voltage, hence the reason why it would not function below 9 VDC input.

Rather than try to hack this module, I figured it would be easier to purchase a DC-DC boost converter module off of eBay from a US seller. After a few days, I had a XL6009-based module in hand, which looks to have a wide range of usable input and output voltages, and can easily source enough current to drive a small strip of LEDs. With the plan to drive the boost converter from the 6 VDC rail available from the TDS1012 power supply board, I set my bench supply to supply 6 VDC to the boost converter, set the boost converter to supply 12 VDC to the LED driver, and managed to get everything set up to light that LED strip from 6 VDC input. I just had to hope that the power supply had enough current margin for this LED strip, plus the losses in the boost converter and driver board.

IMG_20160503_165017

Now that the LED has been verified to work correctly, it was time to fit it into the display module in the place where the CCFL used to be. With the CCFL removed, you can peer down into the cavity it has left behind and see the glass panel that diffuses the backlight. The LED strip was placed facing into the edge of this glass so that the terminals came out of the top of the module (where the old CCFL wiring ran), and I used RTV silicone to secure it in place. I chose RTV silicone for two reasons: it would be easy to remove if I messed up the placement of the LEDs and it would be reasonably transparent if I got some adhesive in between the LEDs and the glass. It appears that was a good choice.

IMG_20160504_150428

Now I used epoxy (the cheap stuff from Harbor Freight) to seal up the plastic cover that I cracked earlier, mainly to provide mechanical stability and extra protection to the LED strip.

IMG_20160504_133547

Once that was dried, I lashed everything up to breadboarded driver circuitry to ensure that the backlight was actually do the job. As you can see above, it looked good so far!

IMG_20160504_134906

The real acid test for me was to see if the TDS1012 could actually drive the new backlight from its own power supply. I really had no idea if the current budget was there in the instrument, as there weren't enough details in the service manual to know. So I had to just lash it together to try. The boost converter was soldered into the 6 VDC and GND terminals on the J9 connector on the power supply board, and then power was applied to check for magic smoke. Nope, success! BTW, if you are replicating this test, be sure to plug all of the modules together, as the instrument won't power up unless all of the cables are connected.

IMG_20160504_140029

Now the job was to stuff the boost converter, trimmer pot, and LED driver module into the existing chassis so that it was secure and safe. The modules were test fitted into spaces where they looked like they would conveniently fit, and then Kapton tape was generously laid down on the chassis to give them a safe mounting point.

IMG_20160504_144309

IMG_20160504_153326

Fortunately, both of the modules were small enough to fit quite nicely in existing space, and both were single-sided boards, which meant that they could sit flush against the Kapton tape easily. The modules and pot were secured in place using more of that epoxy (although hot glue would have probably also worked well).

IMG_20160504_153819

The leads to the LED strip were routed back through the hole in chassis where the old CCFL leads went, and easily were able to reach the new LED driver module. After that, it was a simple matter to reassemble the instrument and power it on for a final smoke check.

IMG_20160504_155414

It works!

Although not the most skillful of hacks, it's always quite satisfying to recover something of value from the scrap heap with a handful of parts (about $15 worth in this particular case). I think the new LED backlight is actually brighter than the old CCFL backlight, but it has been a while since I've seen it with the original backlight, so that's a pretty poor subjective observation on my part.

One small warning here: I have only done rudimentary checks to see what effect the DC-DC boost converter would have on the measurements from the scope. I don't see any obvious hash from the switching power supply on the most sensitive vertical setting, but it's possible that the this might introduce some low-level unwanted spurious into the instrument, which perhaps may be visible when using the FFT function. Caveat emptor. You have been warned.

So for those of you with older instruments with busted CCFL backlights, I would highly suggest that you can retrofit a new LED backlight if you have some moderate electronics skills. There's nothing particularly magical here. The biggest concern is whether you can pull enough current from the existing DC power supply, but I imagine most instruments have power supplies that are designed to easily give up enough extra current to power a small LED strip without and difficulty. And if you have an instrument with 12 to 24 VDC already available, you can skip the boost converter that I had to use and not even have to worry about that. Give it a try and give some old junk new life!

Nerd Famous

It's nice to see we hams, who I think suffer from a bit of an image as throwbacks in the larger maker community, get some recognition for the good stuff we've accomplished. Today on Hackaday, a nice article about Manhattan and Ugly construction was posted, with ample coverage given to the fact that a lot of the best exemplars of these techniques come from the world of amateur radio builders. I'm not certain about how others feel on this topic, but it seems to me that Hackaday is one of the preeminent blogs relating to our hobby, so I get quite excited when we get repped there.

hackaday.com-2016-05-04-getting-ugly-dead-bugs-and-going-to-manhattan-_2

Featured in this article are two names well-known in our circles, and guys that I'm proud to call my friends (although I have never personally met either in real life yet!). Todd VE7BPO, is renowned for his rigorous empirical work in circuit design, as well as his beautiful Ugly circuit creations. They feature one of his designs near the top of the article.

hackaday.com-2016-05-04-getting-ugly-dead-bugs-and-going-to-manhattan-_105

The other is Dave AA7EE, who is probably familiar to almost every reader, unless you just crawled out from living under a rock for the last decade. It's not difficult to see why they chose Dave's work for to illustrate Manhattan construction, as his is some of the best out there. Period. Also unsurprisingly, this is not the first time that Dave's creations have made it to Hackaday.

Well done, gentlemen! Way to show the maker world at large that we've got relevant skills for the 21st century hacker community!