Friday, April 14, 2017

Simple Led Nameplates for coworkers -- Kicad/PL9823/Atmega8/Arduino/NeoPixel /w github

This was a quickie that came out really cool...

I designed this project around parts I have mass quantities of... Mainly leftovers from other projects. This kind of thing is a great way to pare down your parts hoard!  This why the PCB is a mishmash of odd components... I have a crap load of ATMega8 PDIP package chips... like seriously 300 or so of them. (Dont ask)  So I tend to use them everywhere.
I designed these around prototype service which is 10 boards 10x10cm for around 16 bucks. This means my friends get one sign and about 9 personalized coasters ;-)

 In kicad I simply plopped my prebuilt ATMega8 MCU board sck file as a hierarchical sheet then broke out nets for the brightness knob analog input, button input and PL9823 pixel data output (A ws2812 compatible in a 8MM T package LED... I LOVE These things!).

Using 12 of these PL9823 8mm devices is way overkill but you can control the brightness with the pot, I didn't really know how it would cast through the PCB so I figured better to be too bright than too dim.  It sure is pretty though.  I do the fronts in 1.2mm thickness and the back in 1.6mm.
 I put the footprint for two POTs since i have lots of both. Also my original ATMega board needed timekeeping it had footprints for crystal oscillator, this design didn't so I did not populate the crystal and even left out some of the bulk and bypass caps... simply not needed.

The pixels are arranged in a string of course, and I added headers for the input and output data... This way I can chain them to another neopixel board or another one of these that simply does not have the MCU populated.  With things like this I try to make the boards are re-usable as possible.  Adding extra footprints is free!

The whole design took a couple hours since I was re-using huge parts of previous designs. If i had it all to do again I probably would have added a serial header to allow easier re-programming. As it is, I am using an ISP programmer which most people will not have on hand. But this was a carry over from the reused block.  If i had done that, this board would look like a Arduino UNO in the Arduino UI. But oh well, that will be V2.5 I guess...

For the logos and graphics i used KiCad's Bitmap2Component and put them on the solder mask layer.  The front has most of the solder mask removed on the back and selectively removed on the front.  This combined with copper layers determines where and how the light passes through the PCB.  The red soldermask completely absorbs some wavelengths of light while the fiberglass PCB transmits everything. So you get a great alternating effect as a given color reacts to the different materials. You really have lots of options to get some cool effects.

I have posted all the design files and code to github.  Links below! Enjoy!


Monday, November 28, 2016

IoT Stranger Danger! -- From an IT Professional and Electronics Hobbyist / Ramble-n-Rant

I sit on two sides of this problem. I am an IT Professional, currently Enterprise Architect at New Jersey Institute of Technology.   My Department manages everything server, storage and network on our campus. We see every manner of device installed (or attempted to be installed) on our network. Consumer devices, smartphones, industrial control devices, PLCs, cameras ... Everything (Even a internet connected fish tank! Seriously.)

On the other hand, because of my embedded/electronics background, I am intimately familiar with the microprocessors, firmware complexities, networking stacks and protocols at play in these devices. Quite simply when you build a device, try to make it as cheap as possible, then make it participate in an increasingly complex network jungle, you are asking for trouble.

Consumer devices are built down to a cost, which means they will often use the smallest microcontroller possible and offload complexity "elsewhere". This means devices like WiFi light bulbs and thermostats often depend on a service running in the cloud for advanced functionality. The simpler you can make a hardware device the less likely there will be show stopping bugs. By using a cloud service the product designer moves some of that bug risk to something under their direct control. A server run in the cloud is capable of giving the user a lush App/GUI, complex functionality and integration with an ever changing field of other devices.

The IoT ecosystem is rapidly evolving, making sure that a consumer device works with IFTTT, twitter, gmail, facebook etc is a minefield of APIs. Putting that complexity directly in the device would be expensive and require frequent firmware updates. (more on that later!)

So, these devices often depend on a cloud service, Does the owner need to know? Most will not care until it stops working. But the design of the device and how it communicates with the owner will largely determine it's lifespan.

From a user's perspective, if it stops working, it's broken and when it's broken, it's trash. Many of these devices will have a direct and short path to the landfill if the company goes belly up and/or shuts down the cloud components. For example, NEST, now owned by Google, announced they would be shutting down their "Revolv" cloud service making the hardware devices junk. To their credit they offered the users a refund. But it's a good example of how a physical device's functionality depends on stuff outside the control of the user.

Let's talk about security... It's a jungle out there. We often think that our local network (home or corporate) is a walled off garden. But this is not really the case. The jungle creeps in...

Consider small embedded device... Let's say a consumer WiFi controlled lightbulb... camera, or a network connected alarm panel. Believe it or not, they are remarkably similar. All have a small microcontroller running a minimal (but complicated!) network stack. They are both likely to be "stuck in time" and forgotten after being installed. Meaning, once the owner "gets it working" it will rarely (or never) have it's firmware updated, at least as long as it continues to work. And finally, after some duration, sometimes remarkably short for consumer items, the company that produced this device will stop supporting it, or worse completely disappear. From the above cloud discussion we know this can spell certain doom for the complex functionality, but lets assume that this device allows you to directly control it and does not rely on a cloud service.

When network connected devices get "stuck in time" they become a hazard to the network owner.  (this means you) This can be a campus with 10,000 deices or your home network with ~10 devices. The scale is different but the hazard is the same.

In some cases the device firmware is vulnerable to direct attack. Perhaps a OpenSSL or HTTPD vulnerability, maybe combined with a Linux kernel hole that allows arbitrary code execution. This can mean that another peer device on the same network can gain access to and control or adulterate firmware on a device. This can be a toehold for a larger attack or simply become a "bot" used to attack elsewhere on the network.

Even if an attacker is not a peer on your local network, these devices are often allowed to make unfettered outgoing connections. If you can induce a device to make an outgoing call to a malicious site, perhaps a malicious DNS server, you may be able to exploit a hole which gives you access an attacker can build on. This means an attacker need not already be on your network. You at home, could browse a malicious website, your computer gets infected and looks for other vulnerable devices on your network. This really does happen and it means your DVR or IP Camera may be quietly participating on a Distributed denial of service (DDoS) attack controlled by a BOTnet.  (See:

Ok, So we have the cloud service evaporation risk, the "Stuck in time" risk, and all those security risks. What should we do? Simply keep using normal light switches? (Well yes, but don't get me started on that...)

I think we all just need to understand where we are in IoT's hypecycle (See: ... We are firmly, I think, on the roller coaster headed down toward the "Trough of Disillusionment". There are going to be some big IoT casualties, some big security exploits, and a LOT of junk in landfills. Understand the risks and proceed with caution. Some suggestions:

  • Don't buy expensive crap -- This might sound obvious but the wording is specific.  If your going to spend a wad of cash on a gadget, try to understand the parent companies commitment to being in business and product support in comparison to how bid the wad is.  If you are buying a whiz-bang cheapo ~$20 IoT gizmo, it's not too difficult to recoup that value even if it doesn't last that long.  (putting landfill ecology aside)  
  • Build a wall -- You might consider setting up a isolated WiFi WAP dedicated to un-trusted IoT devices.  Decent consumer access points are sub $50 these days, and most will intelligently select non-conflicting channels.  This can offer a lot of protection but can also break funcationality, its a trade off.
  • Keep on top of firmware -- Some IoT devices will tell you wen new firmware is available... but that only works if you actually look at the app from time to time.  Lots of these gizmos are set-and-forget, well try not to forget them for too long.   
  • Keep on top of the vendor -- If the company is out of biz or if the product is abandoned/end-of-life'ed it is likely that firmware updates will dry up and you will not know.  If this happens it is important to consider taking those devices off the network.   They become a growing risk as new security vulnerabilities are found. 
  • Buy devices that have direct control -- Some devices have direct control in addition to a more luscious IoT API.    This means, for instance, even if IFTTT support evaporates you can still have some level of control using direct communication with the IoT device.   This is usually a web interface running right on the device, or a app that does not require a cloud service.

In the coming years there will be lots of development of IoT security.  There is a gaping hole for some enterprising developer to fill with a intelligent stateful firewall aimed at IoT devices.   Think of this as a virus/malware protection for your home network that prevents IoT devices from doing bad things based on signatures and heuristics.   I think this will be a growth area for consumer home networking in the next couple years.  Until then, keep safe!

Saturday, June 27, 2015

Allow me to wax philosophical for a moment... On yesterday

(warning, this is not a typical nerd post!)

Children are not born knowing hate.   They are born into a language-less world knowing only love, friendship and cooperation.  Their young minds and bodies need the cooperation of parents to survive and grow.  They don’t know division, bias or hate.  Over time these concepts are absorbed, hopefully not intentionally, but they sneak in.  The idea that people deserve judgement.  That knowing a single fact about a person means you do not need to know anything else.  Sometimes these ideas, ingrained in adults, become reinforced by societal structures.  But we adults make the rules, and we can change them.  

Yesterday, another one of those societal structures was corrected.   That arc of justice was bent just a little more toward that childish ideal world without bias or division.  It’s a long arc, and there is a lot more bend left to go, but it moved.  We all felt it.   

Today, I am proud of my fellow adults.  

Children of today will likely know nothing of rotary telephones or the horrors of dialup internet.  They belong in museums too.  It is exciting to think that, now, maybe, if we just stay out of their way, they will also never know limits to who they can love. 

Sunday, January 18, 2015

The Novena Motherboard / And a post because I was told I should...

Much to my (@sysmatt) delight, my Novena motherboard was waiting on my doorstep when I got home friday night.  Bunnie Huang and (@bunniestudios) Sean Cross's (@xobs) open source motherboard.

At first glance it's simply beautiful.  I knew the dimensions ahead from the mechanical drawings, but it is still surprising how small it is for what is packed into it.  There is a lot of art and engineering that goes into laying out a board of this complexity.

And when was the last time you got anything (that wasn't test gear, and even that is rare today!) that included schematics?  On paper no less!

After making the customary backup copy of the included 4gb SD card, we plug in the very nice 18v 3.4a power brick... (Novena branded, nice touch) and we get linux kernel boot goodness.  I feel at home.  

I think it is pretty safe to say the Novena project is the first of its kind.  There have been many linux devboards over the years, but this one seems special.  It is targeted and tuned for a very specific hacking/fuzzing/etc audience, but also generic enough to be useful for a very broad hobbyist community.  The inclusion of the FPGA just blows the doors off the possibilities.  

That is all for now, Expect more posts a about Novena, and watch my @sysmatt twitter for micro updates!

Enough gushing, time to dig in.

Tuesday, November 18, 2014

Manage your Raspberry Pi with a shell session in a web browser -- Introducing ShellInABox

Raspberry Pi B+ top.jpg
Image Credit:" Raspberry Pi B+ top" by Lucasbosch - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
Sometimes you need to log into a Pi (Or any Linux system for that matter) and you do not have a SSH client installed on the machine you happen to be behind. I have built lots of Raspberry Pi based gizmos and sent them on their way to parts unknown. Using a little chunk of software called "shellinabox" you can use any modern web browser to get a shell session. No plugins, no Flash, no Java applets, no putty, no trying to find the terminal app on a mac. Just point your browser and login. Shellinabox is remarkably fully featured, supporting full VT terminal, colors, copy/paste clipboard, and more. Running VIM and other full screen applications work perfectly. This awesome software has had a long lineage, originally based on a Java Applet the creator Markus Gutschke recently rewrote it to only use javascript, css and AJAX. All standard in modern browsers.

Shellinabox is completely self contained and does all it's work over one port (tcp/4200 by default). It is also relatively light weight, using about 5MB of memory on my systems. The default configuration does exactly what you would expect, when you point a web browser at it it will ask you for a username and password and logs you in to a shell session. Under the hood there are a lot more capabilities. You can actually substitute any interactive program in place of the login shell.

Installing Shellinabox

If you happen to be running Raspbian this is going to be really easy. Shellinabox is a standard package. All we need to do is install it and optionally do some customization.

pi$ sudo apt-get install shellinabox

If you want to install from source code or just explore how Shellinabox works, visit

Customize Shellinabox

You can completely skip this section if you like the default look and feel. Personally black text on white background makes my eyes bleed, so below I will include the steps to customize the colors. I prefer black background, call me old school, but I like the CRT type experience for shell sessions. White on black is acceptable, green on black is preferable.

All configuration for Shellinabox happens in /etc/shellinabox and /etc/default/shellinabox. The color themes are all handled by regular CSS so they are easy to modify. Style sheets are stored in files under /etc/shellinabox/options-available and use filenames that define their precidance with a number. This determines the order in which they are interpreted and the underscore (_) or plus (+) determines if they are enabled by default. These files are then symlinked into /etc/shellinabox/options-enabled to make them available to the user. To give me green on black, I create a file /etc/shellinabox/options-available/00+Green On Black.css which contains:

#vt100 #cursor.bright {
  background-color: white;
  color:            black;

#vt100 #scrollable {
  color:            #00ff00;
  background-color: #000000;

#vt100 #scrollable.inverted {
  color:            #000000;
  background-color: #00ff00;

#vt100 .ansi15 {
  color:            #000000;

#vt100 .bgAnsi0 {
  background-color: #00ff00;

Then, I make the symlinks:

pi$ cd /etc/shellinabox/options-enabled
pi$ sudo rm -f 00*
pi$ sudo ln -s ../options-available/00+Green\ On\ Black.css  .
pi$ sudo /etc/init.d/shellinabox restart

This will leave you with:

ls -l 
total 4
lrwxrwxrwx 1 root root  42 Nov 18 12:10 00+Green On Black.css -> ../options-available/00+Green On Black.css
lrwxrwxrwx 1 root root  42 May  3  2012 01+Color Terminal.css -> ../options-available/01+Color Terminal.css
lrwxrwxrwx 1 root root  38 May  3  2012 01_Monochrome.css -> ../options-available/01_Monochrome.css
-rw-r--r-- 1 root root 189 May  3  2012 README


To connect to your Pi, aim your web browser at port 4200. Use the URL: http://nnn.nnn.nnn.nnn:4200/ where nnn.nnn.nnn.nnn is the IP address or hostname of your Raspberry Pi. You will likely be prompted with a SSL Certificate warning similar to the one below which is from Google Chrome. You can create real certificates for shellinabox, check the documentation if you want to. For now we will proceed by clicking the dialog as shown.

Once past the SSL warning you will be requested to login with a username and password. Do it. Once you are in, you are free to shell around to your hearts content.


Shellinabox is a great little tool to have in your toolbox. When you need to deploy a Raspberry Pi and might need to log in from a station that might not have a SSH client. Use them together, use them in peace.

Thanks for reading, Feedback to @sysmatt on twitter or comment below!

Like this article? Maybe you would like some of my other tutorials and articles: