As I talked about in my post where I was working with Adafruit's Matrix Bonnet, Adafruit takes a lot of shortcuts in their tutorial when it comes to working with the software side of the Matrix Bonnet. I don't think that's a problem for the main audience they are going for, but I like to know what's going on behind the scenes. So as I did for my other Matrix Bonnet writeup, I'm going to break out the details of what I did to get their LED Matrix Sand Toy up and running.

Obviously, you're going to want a Pi Zero, or Zero W, with the latest and greatest Raspbian Lite on it. Next, I grabbed their setup script and started figuring out what else I wanted to tweak.

Since they're using the hardware mod to decrease flicker, and this is a purpose-built setup, as opposed to my previous one which was just for testing and experimenting, I'm going to compile the software to default to use the Adafruit hardware. Also, technically, I just needed to compile the Python-related parts, but I opted to get everything set up just in case I wanted to play around with the other demos.

cd rpi-rgb-led-matrix/ make -C examples-api-use HARDWARE_DESC=adafruit-hat-pwm cd utils/ make HARDWARE_DESC=adafruit-hat-pwm cd ../bindings/python/ make build-python HARDWARE_DESC=adafruit-hat-pwm sudo make install-python HARDWARE_DESC=adafruit-hat-pwm sudo make clean make build-python HARDWARE_DESC=adafruit-hat-pwm PYTHON=$(which python3) sudo make install-python HARDWARE_DESC=adafruit-hat-pwm PYTHON=$(which python3) sudo chown -R pi:pi .

Next, we should disable the built-in audio hardware. Edit /boot/config.txt and set audio to off:

dtparam=audio=off

Once all the above is done, you'll need to reboot the Pi for the audio driver change to take effect.

After the reboot, I followed the rest of the tutorial and cloned the Adafruit Pixel Dust repo, enabled I2C via raspi-config and finally compiled the code.

I then opted to make the Raspberry Pi read-only. I followed the petr.io site that Adafruit linked to, instead of running Adafruit's script. I skipped into step 2 and did the following:

sudo apt-get remove --purge wolfram-engine triggerhappy cron logrotate dbus dphys-swapfile xserver-common lightdm fake-hwclock sudo apt-get autoremove --purge sudo apt-get install busybox-syslogd; dpkg --purge rsyslog

In his Step 3, I noticed the Stretch-based kernel command line looks different, but I did end up adding the "fastboot noswap ro" to the end of the command line and that ended up working fine.

I then followed Step 4, 5 and 6 as-is. I did some reading up on the UsePrivilegeSeparation option for OpenSSH and it looks like it's been deprecated. I didn't bother diving much deeper to understand what will need to be done in the future. Sorry, Future Dustin.

In Step 7, I moved the /etc/resolv.conf file to the /tmp name and location and then created the symlink.

I skipped the watchdog part, but I did end up adding the bashrc items to both the pi user's .bashrc and to /etc/bash.bashrc. The local user's .bashrc ends up overriding the PS1 variable, so at the very least, you have to tweak that file...or just put the block in both places. I opted for the lazy option and put it in both locations.

After all of that, everything works great. Another great project idea from Adafruit!

I finally got around to putting together Pimoroni's great Scroll Bot kit. Once put together and the attached Pi Zero W configured, it looks something like this:

This kit is great and all, but their tutorial is geared toward someone who just wants to put it together and go, so they provide a shell script that takes care of installing all sorts of things for you. Where's the fun in that?!?! Here are my notes for making this work on a fresh Raspbian Lite (the Stretch version as of this writing) image.

First, install the packages you'll need:
sudo apt-get install git python-scrollphathd python3-scrollphathd python-flask python3-flask python-pil python3-pil

After the above is complete, you should be able to light a single dot:

import scrollphathd as sphd
sphd.rotate(180)
sphd.set_pixel(0, 1, 0.5)
sphd.show()

You can clear the dot with:

sphd.clear()
sphd.show()

From there, you're on your own. If you want to try out the Scroll Bot demo (ie, draw the image as seen on Pimoroni's store front), you'll have to clone their repo:
git clone https://github.com/pimoroni/scroll-phat-hd.git

And then you can run the demo:
cd scroll-phat-hd/examples/; ./robot-mouth.py

That's it...have fun!

I opted to follow the library author's docs after using the tutorial to get familiar with the hardware. The library and CLI tools are at:

https://github.com/hzeller/rpi-rgb-led-matrix

Clean up un-needed cruft:
sudo apt-get autoremove --purge bluez bluez-firmware pi-bluetooth triggerhappy pigpio

Install some needed dependencies and tools:
sudo apt-get install joe git python2.7-dev python-pillow python3-dev python3-pillow libgraphicsmagick++-dev libwebp-dev

Clone the repo:
git clone https://github.com/hzeller/rpi-rgb-led-matrix.git

Build things:
cd rpi-rgb-led-matrix/ make -C examples-api-use cd utils/ make cd ../bindings/python/ make build-python make build-python PYTHON=$(which python3) sudo make install-python sudo make install-python PYTHON=$(which python3)

((get some coffee....))

The Python build above, obviously, only builds for Python 3. I'm not going to bother with 2.x...figure if I'm going to play with Python, I should learn the future rather than the past.

Another note about the build steps I've followed above, is that they assume you're going to pass the correct argument (--led-gpio-mapping=adafruit-hat or --led-gpio-mapping=adafruit-hat-pwm as appropriate) to tell the tool/command/whatever to use the Adafruit Bonnet.

And I lied... I just read further in the Python library docs, and the author has this:

Also interesting: Python3 is a little bit slower than Python2.7. So if you can, stick with Python2.7 for now.

Heavy sigh...I've gone back and edited the build commands above to include building for Python 2.7.

UPDATE, 2016-04-04: Quick update to clarify how the new udev rules get applied after creating the file. No reboot or service restart required.

UPDATE, 2016-04-03: Just as I was about to post this write-up, I discovered some of the info below is included in the README.md included in the BSP files. Their information is only for Debian/Ubuntu distros and they incorrectly state that you need to restart udev for the rules changes to take effect. But hey - the info was there if you knew where to look.

I recently picked up Adafruit's latest Feather board - the the WICED Feather. They have a really great tutorial but it's light on tips and tricks for using the boards under Linux. I thought I'd write down what I had to do to start working with the board on my system in the hopes that it's useful to others. Or at least to me in the future ;)

NOTE: My desktop is running Fedora 23, so the file locations and package names are based on that. They should be similar to Debian or Debian-based systems, but you'll likely have to translate appropriately.

udev Prereqs

If you've ever programmed Arduinos or other microcontrollers on Linux, you probably know what a pain in the butt it is to deal with permissions and the udev rules needed to make things work for a normal, non-root user. The WICED is extra special because it will identify itself as two different USB PIDs to your host system depending on which mode it is in. In normal mode, it uses PID 0010 and in DFU mode, it uses 0008. This tripped me up until I double checked my kernel output and found the second PID when the WICED goes into DFU mode.

When in normal mode, here is an example of what you should see when you connect the board to your Linux box. I've removed the date/time and hostname to make it easier to read.

kernel: usb 3-9.1: USB disconnect, device number 18
kernel: usb 3-9.1: new full-speed USB device number 19 using xhci_hcd
kernel: usb 3-9.1: New USB device found, idVendor=239a, idProduct=0010
kernel: usb 3-9.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 3-9.1: Product: WICED Feather Board
kernel: usb 3-9.1: Manufacturer: Adafruit Industries
kernel: usb 3-9.1: SerialNumber: 00000000001B
kernel: cdc_acm 3-9.1:1.0: ttyACM0: USB ACM device
kernel: cdc_acm 3-9.1:1.2: ttyACM1: USB ACM device

Notice Adafruit's VID (239a) and the board's PID (0010). When you put the board into DFU mode, either manually (double-clicking the reset button) or when uploading code via the Arduino IDE, you'll see something like this in your kernel logs:

kernel: usb 3-9.1: USB disconnect, device number 19
kernel: usb 3-9.1: new full-speed USB device number 20 using xhci_hcd
kernel: usb 3-9.1: New USB device found, idVendor=239a, idProduct=0008
kernel: usb 3-9.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 3-9.1: Product: WICED Feather DFU
kernel: usb 3-9.1: Manufacturer: Adafruit Industries
kernel: usb 3-9.1: SerialNumber: 00000000001C

Notice that bot the PID and SerialNumber have changed, but the VID has stayed the same. We'll need to account for both of these PIDs in our udev rules. I have the following in /etc/udev/rules.d/50-arduino.rules:

# Adafruit devices
ATTRS{idVendor}=="239a", ENV{ID_MM_DEVICE_IGNORE}="1"
# WICED Feather
ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0010", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0010", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0010", GROUP:="wheel", MODE:="0660"
ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0008", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0008", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="0008", GROUP:="wheel", MODE:="0660"

Note that I set the group ownership above to the wheel group. You can use whatever group you want, so long as the the user you're logging in as is a member of that group.

I've also added lines to prevent the MTP and ModemManager subsystems from probing the device when connected.

Once you have your udev rules file all set up, all you need to do is connect your device and the proper files with your specified permissions and ownership will be created. No need to reboot or restart services. If you already had your Feather connected to your host before you created the rules file, simply disconnect, count to five or so, and reconnect.

Additional OS Packages

Next, you'll need to install some support packages that are either required by the BSP provided by Adafruit, or are handy when working with the board.

sudo dnf install pyusb python-click dfu-util

The pyusb and python-click packages are used by the feather_dfu.py command that is part of the BSP. The dfu-util binary is included for OS X and Windows in the BSP, but not Linux - it relies on the tool installed elsewhere on the system.

Arduino BSP

Make sure you have the Arduino IDE/environment installed and functioning. I downloaded the latest as of this writing (1.6.8) and so far I haven't had any issues.

Now you can follow the Adafruit tutorial's instructions to install the BSP. I used the git option and things worked fine.

Serial Port options

Per the Adafruit tutorial, the serial ports ended up being ordered as-described. /dev/ttyACM0 is the "programming" port and should be used as the target in the Arduino IDE and /dev/ttyACM1 is the "debug" port that currently responds to AT-style commands.

Quirks and Wrap-up

That's it - you should be able to flash your WICED Feather with your code now.

I will note that I've seen the following output when I flash code:

Sketch uses 27,104 bytes (20%) of program storage space. Maximum is 131,072 bytes.
Global variables use 5,560 bytes of dynamic memory.
dfu-util 0.8

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 239a:0008
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x080e0000, size = 32264
Download	[=========================] 100%        32264 bytes
Download done.
File downloaded successfully
dfu-util: Error during download get_status

Ignoring dfu-util complaining about an invalid suffix signature (???), even though the last message is an error, note that it does show that the code downloaded successfully and it does in fact work. I'm writing this off as part of the "Developer Edition" quirks mentioned on the product page. I was clearly warned and I expected this.

Happy flying with your new Feather(s)!

Last week's Sonoma State Computer Science Colloquium welcomed Jeremy Gillula from the EFF to talk about their Let's Encrypt project. The have many goals, but basically they want to make it easy and free to encrypt all websites.

This got me thinking that I needed to get the SSL certificate I use here re-issued to move away from SHA-1. In resolving that problem, I wanted to see if I could up my Qualys SSL Labs score. I was able to get my certificate re-issued relatively easily, but I had some chain issues. One of the reasons why Let's Encrypt exists, is because encryption is hard. Jeremy even made the point many of us sysadmins do all the time - it's even hard for people like us who have been doing computers for years.

I always thought chains only mattered on the client, so that you could very the server's certificate all the way back to the CA. Turns out, you should be configuring your server to also present the chain to the client. My certificate vendor sent me the two chain files and the CA file. All I had to do was place the files on the server, and add in the correct Apache config directives.

  SSLCACertificateFile    /etc/apache2/ssl.crt/AddTrustExternalCARoot.crt

  # Server Certificate Chain:
  SSLCertificateChainFile /etc/apache2/ssl.crt/COMODORSAAddTrustCA.crt

  # Server Certificate Chain:
  SSLCertificateChainFile /etc/apache2/ssl.crt/COMODORSADomainValidationSecureServerCA.crt

After reloading Apache's config, I was able to get an "A" on the Qualys SSL report. Turns out it wasn't as hard as I thought.

Update 2013-04-05: I got thinking and realized the SMD version of the JeeNode includes the activity LED - the normal version does not. So while the Hello World sample makes sense, it would be nice if they reminded folks of the SMD difference. I also found a reference to the activity LED and the RF12demo command to control it: "Activity LED"

So I took this week off to play around with some electronics projects I've been thinking about for a while. One of those is the JeeNode. The JeeNode is, yet another, Arduino-compatible device. The cool thing is it has a built-in radio and supporting library. Glancing around that website, the Modern Device website (the U.S. partner) and the JeeLabs Blog, it looked like there was tons of documentation that would be helpful in getting started. Little did I know what I was getting myself into.

In the picture above, you can see the collection of parts I purchased. I also ordered a battery box and some extra header pins. From top to bottom, that's a BUB II (a USB to TTL serial adapter to make programming the JeeNode easier), a JeeNode SMD, a JeeLink (a JeeNode in a USB key form factor that makes it easy for a host to communicate with your JeeNode network), and a Room Board kit. I opted to forgo the SHT11 sensor, because it adds about 30 bucks to the cost of the kit. I'm waiting for a DS18B20 to arrive, that I'll be using instead.

I got the node and BUB soldered up and went to the web to read up on first use guidance. Instead of finding helpful advice, I was met with broken links and either out-dated references to older revisions of the boards or perhaps the info is just plain wrong. It didn't help that I have exactly zero experience with the Arduino universe. In hindsight, I probably should have started there before jumping into the JeeNode world.

First Step

So in hindsight, I should have installed the Arduino IDE first. I tried talking to the JeeNode using minicom, which worked, but I wasn't sure if the lack of output was a minicom configuration issue (oh how I didn't miss you at all, serial communications) or I was doing something wrong with the node. On Fedora, the latest stable Arduino IDE was available, so I installed that:

sudo yum install arduino

I ignored everything I read online about chmod'ing etc. When I first ran the IDE, it suggested my user be added to a couple of groups and offered to do it for me. It runs the appropriate usermod commands for you and then requests you to logout and back in for the group changes to take affect. Once you have the IDE up and functioning, you can launch the Serial Monitor and start playing with the RF12demo sketch that comes pre-installed. The initial output from RF12demo is a usage screen.

The commands are awkward and unclear, unless you read the RF12demo documentation. In hindsight, I should have read it, but I wanted to see my node do something! Both my JeeNode SMD and JeeLink came with an older version of the demo sketch (v7). If you type 1l and send it to the node, a blue LED on the node will light (0l will turn it off). The current version (v12 as of this writing) doesn't list the l command as an option, but it's still in there and will work just dandy. It lives!!!

Next, I mistakenly tried to perform the "Hello World" demo on their site. What they don't bother to tell you is that B1 pin the sketch is going to pull high also happens to be what the blue LED on the node is attached to. The other big problem you'll run into if you've never played with the Arduino language, is that sketch will not work as written. I have no idea if it did in an older version of the IDE or what....but I can't believe they haven't updated it or at least added clarification. Whatever. Luckily, I already know how to code, so I read the output from the IDE and tweaked things accordingly. Here is what the sketch should look like:

#define LED_PIN 9
void setup () {
  pinMode(LED_PIN, OUTPUT);
}

void loop () {
  digitalWrite(LED_PIN, 1);
  delay(500);
  digitalWrite(LED_PIN, 0);
  delay(500);
}

int main () {
  init();
  setup();
  for(;;)
  loop();
  return 0;
}

Factory reset?

OK, so I got the demo sketch working. But now I had lost the RF12demo. Crap. Luckily, everything is Open Source and on GitHub! Check out the JeeLib Project. They have a JeeLib Wiki page, but guess what - it doesn't tell you about the Arduino gotchas when trying to load the library! The first mistake I made, was to assume that I needed to unzip the file. Nope - the IDE expects you to provide it a zip file. The second problem is that the IDE doesn't like anything but alphanumberics in the top directory of the zip file. If you download the zip file of the master branch, the top directory in the zip file is called "jeelib-master" and the IDE chokes. You'll have unzip, rename, then re-zip the directory tree to get the library to properly import.

Once you have the library imported, you can go to the File menu, then examples, then JeeLib. In there you can navigate to the RF12demo. Compile and download it to your node (or link) and you're back to factory defaults.

What's next

Well that's enough for now. I need some dinner and a break - my eyes are starting to bleed. I have some more bits coming next week (like the Dallas Semi part), so truly useful things are still a ways off. This weekend I'll clean my circuit boards and play around with coding some simple network demos so I can get the feel for using the radios.

Some random notes on getting Fedora 20 working on an HP EliteBook 840 G1.

• Brightness keys don't work
  • Edit /etc/default/grub and add acpi_backlight=vendor to the GRUB_CMDLINE_LINUX line.
  • Depending on how you're booting,run the appropriate command to regenerate the grub2 config
    • BIOS: grub2-mkconfig -o /boot/grub2/grub.cfg
    • UEFI: grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
  • Good backlight tips: https://wiki.archlinux.org/index.php/backlight
• Installing w/ bcache
  • If your 840 was purchased with the small SSD cache drive, you can use it to accelerate the hard drive by using bcache. There's a good post on the Fedora Forums: http://forums.fedoraforum.org/showthread.php?t=296015 I didn't follow his post exactly. For example, I use LVM2. I'll update this post later with info on that.