Meta

Now Streaming?

Given my withdrawal from Patreon, this seems like a good time to try out some new ideas that have been rattlin’ around the noggin for a while. One of those ideas was to get a little more social (at least in internet terms) by streaming some of my work sessions on Twitch.

So I’ve set up a channel, installed OBS Studio, and have started to learn how to use the software to at least provide a minimal amount of production value. My old Logitech 720p webcam was dusted off, and I even found another of the exact same model for sale at Goodwill in order to give me a couple of different video sources. I imagine I should be able to connect my USB microscopes to OBS as well so that you could get a good look at circuits up close.

At the moment, I’m getting this all set up at my battlestation, which will probably take another week or so to complete, along with the software learning curve. Watch for some test streams in the near future. I’ll try to make sure that Twitch announces when I’m QRV via my Twitter account. I have no idea how interesting this will be, but I figure it might be worth trying.

Meta

New Blog Theme

As you can see, I’ve changed the blog theme and I’m trying out some of the different post formats, so that I can hopefully make this platform more conducive to the type of “microblogging” I was doing on Patreon.

Meta

Some Site Updates

You may have noticed that nt7s.com now has HTTPS enabled (thanks to the wonderful Let’s Encrypt) and redirects all traffic to that protocol. I think everything is working ok, but please contact me if you find problems with the blog.

I added encryption for a couple of reasons. First, I’m on-board with the idea of HTTPS everywhere, if only to thwart any kind of future problems from intermediaries of various types using your browsing against you. Second, I needed to enable it so that I could start accepting revenue from Brave Payments using the Basic Attention Token (abbreviated BAT). What’s the tl;dr? This is a way to get revenue from your content via a decentralized, cryptocurrency token system based on anonymous data from people’s web browser. It’s still very new and I admittedly am not the most up to speed on blockchain/cryptocurrency, but I sounds right up my alley, so I’d like to try it. This blog was just authorized in the Brave Payments system, so I should now be able to receive BAT in my payments wallet if people choose to allocate them to me. Let me know what you think of all this!

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.

Meta

Patreon Shenanigans

What’s the Deal?

I’m sure most of you have seen my promotion of the Patreon account that I set up for myself about half a year ago in order to help fund the development work that I do. Yesterday, out of the blue, Patreon sent an email to its creators to notify them of a big change that is coming soon:

Dear creator,

In order to continue our mission of funding the creative class, we’re always looking for ways to do what’s best for you – creators.

With that, we’re writing to tell you of a change we’re making so that all Patreon creators take home exactly 95% of every pledge, with no additional fees.

Aside from Patreon’s existing 5% fee, you may notice that your income on Patreon varies because of processing fees every month. Your patrons may not even be aware that you actually take home a lower percentage of their intended pledges because of it. Our goal is to make your paycheck as predictable as possible, so we’re restructuring how these fees are paid.

A new service fee of 2.9% + $0.35 will be paid by patrons for each individual pledge starting on December 18th. This streamlines fees for both creators and patrons to ensure that you pay no more than 5%.;

As I wrote on a Patreon post, I do not want this change in the fee structure; I am in fact strenuously opposed to it. However, we creators were given no choice in the matter. Patreon claims they have tested this new fee schedule and received feedback from select creators. I haven’t seen one creator actually step up to say that they participated in this trial, so I have no idea how many were actually enlisted into this. Certainly, from the backlash I have seen on Twitter, the fee change has come under nearly universal condemnation from creators.

You Didn’t Agree To This

For its entire lifespan, until now, Patreon’s funding model was that when you pledged $1 to a creator, you paid $1. When you pledged $20, you paid $20. Of course, the payment processors have to get their fees and Patreon has to pay their expenses and make some money from the business, so there was a 5% cut for Patreon and a variable amount taken out for payment processing. All of that was deducted from the creators funds before they were disbursed, which is how nearly all businesses do things and how I believe it should be done.

Now, under the guise of giving more money to creators and stabilizing the amount of income a creator can count upon (which is a fallacy under this new system), the flat 5% is deducted from the creator’s funds from the “pledged” amount, and a 2.9% processing fee plus a fixed $0.35 are pushed onto the patron, on top of the amount of money they have pledged to the creator. There is no way to opt out of this new system and have the creator eat the cost of the fees so that a patron only pays what he agreed to pay.

All of my current patrons signed on under the model where they were making a once-per-month payment of whatever dollar amount they pledged, not a penny more. I wouldn’t dare think of trying to nickle-and-dime my generous patrons by asking them to eat my fee expenses, but Patreon corporate is forcing that upon us. My patrons pledged what they pledged because that’s what they budgeted for. Forcing a unilateral increase upon them in this type of funding situation feels incredibly scummy to me.

What’s worse is that it puts both we creators and the patrons in a bad place. Patreon pushed this change on us, but we have to manage the fallout (and they have shown no interest in dealing with it from what I have seen). Patrons now have to decide whether they want to suck it up and be forced to pay more in order to support the people that they like at the same level, cut out certain creators in order to stay within their budget, or drop the whole thing all together. I’m sure it doesn’t feel good for the ones dropping some support or cancelling accounts completely to leave the creators high and dry. But I don’t blame any patron for making that choice one bit.

Surcharges Suck

You should be paying the amount that you pledged, not a penny more. Converting creator goodwill into monthly contributions is already a bit tricky, for understandable reasons. One of the great things about the old Patreon system is that it made the barrier to entry to supporting creators quite low; even more so once a person had established a patron account and was supporting their first creator. Offering a $1 pledge level (which I believe most creators used) gave people a low-risk way to showing support, which had the chance of being converted to a higher pledge level later if the patron liked what the creator was doing. Also, it is important to remember that Patreon used to brag about their system of bundling pledges into one monthly transaction in order to save fees.

But that’s gone now, because there is no $1 level any longer. The minimum amount that you’ll be able to ask for is $1, and then Patreon will add the 2.9% plus $0.35, or $0.38 to every $1 pledge. That doesn’t sound like a huge change, but the problem is that a lot of people like to spread the love around and support many creators with small pledges. This will become much less tenable under the new regime. As has been pointed out on Twitter, when you support one creator with a $10 pledge, your new out-of-pocket cost will now be a relatively modest increase to $10.64. On the other hand, if you support 10 creators with a $1 pledge each (not an uncommon scenario), your new out-of-pocket cost is going to be $13.80. That’s an awfully big jump.

The fact is that this new fee schedule is regressive because of the $0.35 fixed fee on every pledge. It is my understanding that the lower tier patrons are the lifeblood of most creators. Sure it’s nice to have a few big contributors, but by having a lot of smaller ones your funding has a wide and stable base. This fee change sticks it to those who don’t have a lot to contribute each month and erodes that stable base of support (to an extent that we don’t know yet, but I suspect isn’t insignificant).

Even more infuriating is how this would affect creators who supported other creators, which I imagine, is most of us. In the old system, once you got your pledge funds, Patreon would then use those to pay out to the creators that you support. But it sounds like those days are over.

Now they are going to get those payment processing fees from us creators as well, because they won’t let you use internal funds to pay other creators any longer. Oddly, I noticed that my credit card was charged for my pledges on 1 December, which doesn’t usually happen. At the time I chalked it up to a glitch and didn’t think much of it, until I saw that tweet. It seems they have already implemented that change under the radar.

For all of the PR spin that they were making these changes to help creators, the truth is that this only hurts us. The ecosystem of Patreon depends on creators supporting other creators, and they just made that more costly as well.

Propaganda

One of the most galling things to me is the way communications on this have been handled, and how Patreon has offloaded the worst of this work to we creators. This news was unceremoniously dumped on us a few weeks before Christmas, and they told us creators one day before notifying patrons. I felt is was only fair to notify my patrons immediately, as this change was going to have a large impact on them. It was coming so quickly, I had no time to consider a good way to deliver the news. I suspected this was going to cause concern, and potentially cause patrons to withdraw their support, and that’s exactly what happened. In one day I lost $11 out of the $65 that I was pledged monthly, a 17% decrease. Again, I don’t begrudge those decisions one bit. It makes sense to me.

The real slap in the face was that they expected us to carry the water for their PR department. In the Q&A document they linked, there is a section about patron concerns:

Q: What do I need to tell my patrons?

A: We are sending notification to patrons about the change so you do not need to send them additional communication. That said, patrons always want to hear from their creators. It can often be helpful for them to hear about the change from you as well. If a patron reaches out to you for more clarity, we’ve prepared a helpful statement you can share with them for more detail:


In the past, I was covering Patreon’s 5% fee and all of the processing fees in full for all of my patrons. This meant that every month I saw anywhere from 7-15% of my earnings taken out to cover those processing fees.

Starting December 18th, Patreon will apply a new service fee of 2.9% + $0.35 to each of your individual pledges. This service fee helps keep Patreon up and running and standardizes my processing fees to 5%.

This ensures that creators like me keep more earnings in order to continue creating high-quality content. I hope you understand and continue your pledges on Patreon. You can read even more about the service fee here.

So they were helpful enough to give us some canned talking points to assuage the anxiety about a huge change to the service terms that they themselves weren’t going to address until later, and try to sell it as a benefit. Thanks.

Patreon Responds

As of the time that I was wrapping up this post, I was notified that Patreon had posted an extended explanation on their original post:

First off, I want to point out their response mostly ignores the complaint that everyone has: that pushing the fees onto patrons is just wrong and will hurt everyone. Also, look at the replies and you’ll get a palpable sense of the anger and frustration that Patreon is plowing ahead with this change while ignoring the big concern and only paying the slightest bit of lip service to the perception that there is even a problem at all.

To be honest, at first I thought that it was pure greed that was driving them to make this change. Why else would they charge a fee on literally every pledge? As it turns out from my reading of that update, it actually sounds like pure stupidity. In trying to fix the perceived problem, they are changing to a model where a patron is charged at multiple times per month, once for each pledge. Which apparently why that payment processing fee is being assessed for every pledge. What’s astounding is that this is literally the opposite of my understanding of Patreon’s founding business model. They bragged that they saved money by bundling payments, allowing you to spread around a lot of small-value pledges economically.

This is so gobsmacking to me I really don’t even know what else to say about it at this point.

My Response

Yesterday, I decided to wait before taking further action to see if they might reverse course. After seeing a huge negative backlash online, I held out hope that there may have been a chance that they would actually do it. But from what I have seen from the official Patreon updates and from Jack Conte (Patreon’s founder), I now have little hope they will listen to people and back out from this mess.

Regardless of whether they do or not, I’m done with them. They have lost my trust. On principle, I will not allow them to jack up the prices to my patrons, and therefore I will delete my account.

Alternatives

This is all quite disheartening for me, because I was finally getting to the point with my Patreon campaign where I felt like it was making a real difference in my life and not just giving me a few bucks to get a Dutch Bros coffee once a month. I don’t give this up lightly.

Apparently, there are some alternative options, but none of them really do everything that you could do on Patreon. One can receive one-off PayPal or Ko-Fi payments (and for now I decided to add a PayPal button on the blog sidebar), but that doesn’t cover recurring charges. Having a stable bit of monthly income is a big deal. I’ve heard mention of something I had never heard of before called Liberapay, which sounds perhaps the closest thing to Patreon currently available, but it still is quite different in funding structure and doesn’t support the content distribution part.

The best potential competitor to Patreon is something called Drip from Kickstarter. From the looks of it, it seems to function very similar to the old Patreon. The problem is that it’s currently in closed beta, which is no good for those looking to jump ship right now.

This brings up a larger problem. I could hold out and jump to Drip when it is public, but what’s to say they don’t take the same route of screwing their customers once they become significant? You still don’t have control over the terms there, and are hostage to their whims. The more well-established you are as a creator on their platform, the harder it is for you to break away when they crap on you (which is what I’m sure Patreon is counting on right now).

So ideally, I’d like to find a way to diversify my funding and use funding sources that are as decentralized as possible. It isn’t going to happen over night, but I need to be moving that direction. Because of those requirements, I’m intrigued about cryptocurrency solutions, and the first one I’m going to look into is the Basic Attention Token. Long story short is that this is a completely different funding model, and I recommend you look at that website (this may actually be a bit easier to understand). I’ve already applied to receive funding via that method. I have no idea if anything will come of it, but I believe it is worth trying.

In the mean time, I don’t know what I want to do to replace the recurring payments. I want to carefully consider things before jumping into another site such as Drip. I’d gladly listen to any suggestions below.


When I started Patreon, the payment model, ecosystem, and community were very attractive, but there was a nagging voice at the back of my head warning me about getting tangled up in a proprietary site (I think even some of my friends warned me outright :). I posted a fair bit of content on Patreon, and ended up not giving my own blog enough love. Perhaps this is a bit of a blessing in disguise, as I should now put more work back into this blog and look for a different funding model.

Fin

I am sorry to rant for so long that is probably inconsequential to most of my readers. I felt I owed an apology to those who were kind enough to donate to me in an ongoing fashion each month. And I was pretty steamed up about the matter, and wanted to get some things off my chest. Thanks for listening and thank you so very much to those who have supported me financially and otherwise over the years.

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.

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!

Meta

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!

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

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.

Test Equipment

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!

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!