Site Rebuild - Shop Temporarily Offline

  • By: Laurence A. Lee
  • Published: February 6, 2014
Rebuilding, Gadget Shop Temporarily Offline

Update Feb 11, 2014

Sorry, all – the backend migration is a little more involved than I would've preferred, as the eCommerce package I plan to use has some hard dependencies on older components (i.e. Rails 3), whereas I am mostly tooled for Rails 4 when it comes to new applications. It's going to be a few more days to get the dependencies resolved or updated in a private Rails4 fork.

For now, feel free to browse the old Gadget Shop at its temporary home:

- Laurence Lee

Aloha Everyone!

You caught me with my pants down! Yes, I am in the middle of migrating to a new platform, and as part of the migration, the Gadget Shop is being moved over to a new eCommerce engine. I expect the dust to settle in another day or two – at which point, the Gadget Shop will be fully operational once more, and able to accept orders for Kama`aina and Mainland customers.

- Laurence Lee

Filed Under: not404-general

HOWTO: Run TinyG under Minicom

  • By: Laurence A. Lee
  • Published: August 8, 2013

I believe I finally have the Synthetos TinyG v6 working reliably under minicom. To upload Gcode files to TinyG, I found it best to disable the Local Echo ($ee=0), disable the Status Verbosity ($sv=0), disable the Text Verbosity ($tv=0), and finally set the baudrate to 38400 ($baud=3). 

The goal of disabling these three options is to minimize "cruft" that is pushed into the TinyG's output buffers. I suspect (but have not confirmed in the firmware code yet) the TinyG will APPEND the XOFF control code to its output buffer, instead of PREPENDING it in front of anything else waiting in the output buffer.

In addition to the above changes, it appears that uploading text files at 115200 bps is WAY too fast for the TinyG to handle. My guess is that the TinyG winds up sending the XOFF way too late to prevent Minicom from transmitting too much, and at such point, the TinyG's buffers are already overflowed and your job is hosed.

Experimenting with the lower baud rates, uploading ASCII files from Minicom at 38400 bps is still sufficiently fast enough to fill the TinyG's buffers (you can tell because Minicom correctly pauses and resumes the file upload when XON/XOFF are received on an ASCII upload). Since the buffers are still filling up perfectly fine under 38400 bps, I have no problem with any perceived "loss" by transmitting at a lower speed.

With those issues out of the way, I can finally press ahead with the ShapeOko project, using Minicom (or anything else) using a Raspberry Pi as the host.

Filed Under: cnc shapeoko tinyg

HOWTO: Digispark Coding on Fedora 18

  • By: Laurence A. Lee
  • Published: February 26, 2013

Hello, World!

I finally have the Digispark and the RadioBlock devices in stock, and I am now refactoring the slave-controller (Arduino) portion of the "Android-Controlled Arduino" circuit to just the Digispark and the supporting components. More details on that soon.

For now, though, here are my notes on adding Digispark support to Fedora 18. As you know, Fedora has a lot of great tools maintained in their repositories, and that includes the Arduino development environment. Simply do a yum install arduino as root to get the basic tools necessary for Arduino development.

Build Environment Modifications

The Digispark is an Arduino compatible device, which means you must add the extra supporting bits to the Arduino environment. Several changes need to be made to Fedora's standard Arduino development environment. Most of this is derived from the official wiki

  1. Installation of the Digispark Firmware Uploader tool (link)
  2. Installation of the Digispark Libraries into Arduino (link)
  3. Installation of a "redirector " script in place of avrdude - it will invoke the Digispark Firmware Uploader only when the target device is a Digispark; and run avrdude for everything else. (link)

Firmware Uploader Tool

Download, compile, and install.  If you don't already have the Development Tools on your Fedora machine, do a yum groupinstall "Development Tools"

Digispark Libraries

For the Digispark Libraries, I prefer to download, then unpack the bundle into /usr/local/share/arduino to keep the files separate.  For each of the major subdirectories, then, I add symbolic links from /usr/share/arduino to the Digispark libraries:

cd /usr/share/arduino/examples ; ln -s /usr/local/share/arduino/examples/* .
cd /usr/share/arduino/libraries ; ln -s /usr/local/share/arduino/libraries/* .
cd /usr/share/arduino/hardware ; ln -s /usr/local/share/arduino/hardware/* .

Redirector Script

The original instructions say to compile their redirector script (also named avrdude), and then rename the original avrdude to avrdude_original. The intent is to override avrdude and invoke the Digispark's custom firmware uploader when necessary, and run avrdude for everything else.

In my environment, I do compile the redirector as instructed, but I placed their version of  avrdude into /usr/local/bin -- which has a higher precedence in my shell's $PATH. To complete the loop, I don't rename the original avrdude, but instead, create a symbolic link:

cd /usr/bin
ln -s avrdude avrdude_original

Setting things up in this way, none of the originally installed files in Fedora are altered (which keeps yum happy in case of updates or removals), and the build environment fully supports the Digispark target as needed.

Filed Under: arduino fedora digispark projects

Lalee's Shapeoko Build

  • By: Laurence A. Lee
  • Published: February 10, 2013
Mechanical Bits Completed

After a few weeks of procrastination, I finally got around to tapping the rails for the Shapeoko CNC kit. Overall, I like this little kit - pretty easy to assemble with just bolts (with the exception of needing to tap the aluminum extrusions on your own).

All that's left is to install some Home and Limit switches, and wire them up along with the Motors to one of the CNC controllers I have lying around. Beyond that, I'll have it carving into scrap material until it's finally dialed in reasonably enough.

With any luck, I'll be able to use this for Surface-Mount PCB fabrication and improve the turn-around times on fabricating my own boards.

Lalee Shapeoko 01

Filed Under: cnc projects shapeoko

Using Android to Control an Arduino (Part 2)

  • By: Laurence A. Lee
  • Published: February 8, 2013
Arduino Circuit and Software : A Closer Look

I will assume that you have done an Arduino Sketch or two - in which case, you are able to use the Arduino SDK on your computer, connect your Arduino device, and upload (flash) new software to the Arduino. If you don't, please check out other online tutorials; or if you're a Hawaii Hacker on Oahu, come out to the Honolulu Makerspace sometime and ask about any upcoming Arduino sessions.

This article examines the Arduino's role in the overall project. As with most Arduino circuits -- especially those designed on breadboards -- this is a throw-away mock-up of what will ultimately be used in the final circuit. For our purposes of exchanging both commands and sensor readings via JSON messages, an Arduino hooked up to a few simple circuits will work just fine.

Knowing that this portion is a throw-away mock, however, there's little need to spend a lot of time designing the final circuitry just yet. Instead, a handful of established, "tried and true" circuits are dropped onto the breadboard. Furthermore, a few programming conveniences are added to the Arduino Sketch source code to yield a useful mock-up circuit as quickly and as painlessly as possible.

The Arduino Source Code to operate this circuit is on my GitHub Project page.

Not404 Arduino Screen Demo 0201

Software Feature 1 : Adding printf() to Arduino

When rapid prototyping of any sort is done, it's nice to have as many conveniences as possible at your disposal. For Arduino, one convenience that's almost always absent in most examples on the Web is the use of formatted-string output -- like what you'd find in good old printf().  IMHO, that's either extreme laziness, or excessively minimalist. It's certainly not a philosophy I'd buy into for something I intend to build as a quick throw-away mock.

Fortunately, the Arduino "language" is just a simplified dialect of C, and everything is ultimately compiled by a real C compiler under the hood. With the proper incantation, it's entirely possible to make use of vsprintf () or its bigger brother vsnprintf() to construct a printf() equivalent function that outputs on the serial port.  In this project, I use the less-convenient vsnprintf() to future-proof against the possibility of encountering Unicode characters, though the possibility of Unicode reaching an Arduino in production is a bit of a stretch. Still, it's better to be safe than sorry for a routine I'll probably reuse in future projects.

void serialDebug(char *format, ...)
  if (!debug)

  va_list args;
  va_start (args,format);
  va_end (args);
  // string_buffer[ sizeof(string_buffer)/sizeof(string_buffer[0]) - 1]='\0';

Software Feature 2 : Adding JSON Support to Arduino

To accomplish this without the pain of rolling our own JSON parser, we'll just download a freely available JSON library (aJSON) for the Arduino. Drop that into ~/sketchbook/libraries (or appropriate Windows/MacOS equivalent directory), and reference the library from the Arduino sketch. It doesn't get much simpler than that.

#include <aJSON.h>
Circuit 1 : Reading Ambient Light Levels

This circuit is a textbook Arduino example - +5V to one end of a Photo Resistor, and the other end goes to a junction point connecting Arduino Analog Pin (A0), and a grounded 10K resistor.
Not404 Arduino Screen Demo 0201a

Circuit 2 : Controlling a Single LED's Brightness

The PWM features of this circuit are also from a textbook example, with the micro-switch pair derived from yet another textbook example. If it's not obvious by now, I prefer to "stand on the shoulders of giants" when it comes to demonstrating circuits, as there's far better documentation available from the original source that I don't need to repeat here.
Not404 Arduino Screen Demo 0201b

Circuit 3 : Controlling an LED Light Strip's Brightness

The LED Light Strip circuit, which uses a TIP-120 power transistor, is derived from a article.
Not404 Arduino Screen Demo 0201c

Putting it all together

Alrighty then. The Arduino portion is the easiest part of the project thus far, and it's really just a mock (stand-in) for the final circuit I'll be using for the Aquaponics Controller. The purpose of this bit is to get the JSON messaging working correctly across a Serial I/O link, so that we can build up the Web Service code (on the Raspberry Pi), and ultimately the Android Mobile Application, before pulling out the Arduino mock and replacing it with either a DigiSpark or a Teensy3, combined with a RadioBlock transceiver. Things pretty much have to be developed this way, as my set of RadioBlocks is arriving a bit later than originally anticipated.
Not404 Arduino Screen Demo 02 Schem

End Goal Modifications

The end-goal (an aquaponics controller) is to replace (or augment) the Photo-Resistor circuit with something that reads air and water temperature (will eventually be a data-logged feed for a nice graph in the Ruby on Rails application); and replace the PWM-controlled 12 VDC LED Light Strip with a 12 VDC water pump. With those modifications in place, the Android Application can be modified to control the aquaponics water pump's pressure. 

The Android and Ruby-on-Rails application can also be enhanced to turn the water pump on and off on a scheduled basis.  Most aquaponics setups are just clock-timers set to enable the pump for 15 minutes per hour, during daylight hours only. In the future, since this project can track light and temperature levels, I may want to enhance the system to automatically adjust the schedule based on light or temperature readings.

Coming Up in Part 3 . . .

In Part 3, we will dive deeper into the Raspberry Pi parts of this project - going over the RefineryCMS (Ruby on Rails) application, using Node.js as a Serial Port to Socket I/O bridge, and exposing a simple Web Page to test the overall JSON connectivity and command/control structure.

Filed Under: arduino android projects

HOWTO: Bootstrap Fedora 18 ARM (RC2) on Raspberry Pi

  • By: Laurence A. Lee
  • Published: February 2, 2013

Update: February 5, 2013

Fedora 18 Final has been announced this morning. While these image construction instructions are still valid going forward, I will probably create a new process or script in the near future that downloads and combines the Fedora 18 rootfs tarballs and the latest stable Raspberry Pi boot firmware directly. Thanks!

I am happy to see that Fedora 18 for ARM, release candidate 2 is now  available on the Internet :

Being the Fedora Linux Badass that I am, though, I have no intention of waiting for the Raspberry Pi Fedora Remix team to produce their next build. Instead, I've downloaded the Fedora ARM binaries, and cobbled together a homebrew solution to shoehorn (err "bootstrap") the Fedora 18 ARM RC2 binaries for use on the Raspberry Pi. 

Here, then, are my technical notes that you can follow along with to get Fedora ARM 18 running on your own Raspberry Pi.

NOTE: These instructions are not for Linux n00bs. While I will try to document everything as completely and as accurately as possible, there may be a few spots where a little Linux knowledge can come in handy. If you're up for the challenge of learning how to assemble bits and pieces to bootstrap Linux, read on. If you want to be spoon-fed a Linux Distribution for the Raspberry Pi, seek answers elsewhere. I hear Raspbian is a good choice for diaper-wearing Wannabes and Fanboys who can't (or won't) take a moment to solve their own problems.

OK, now that we've separated the men from the boys, let's get started. Grab a spare SD card, 4 Gigs or larger, for this install. I'll assume you're already root on a reasonably modern Linux box for these instructions:

  1. Head over to the Fedora ARM file area and download the vexpress image for arm. (Fedora-18-vexpress-xfce-arm.tar.xz)
  2. Unpack the xz file:  tar -xvJpf Fedora-18-vexpress-xfce-arm.tar.xz
  3. Change into the directory produced by the unpack command:  cd Fedora-18-vexpress-xfce-arm
  4. Write the root filesystem image to the SD Card (assumed to be at /dev/mmcblk0; change as appropriate for your system):  dd if=Fedora-18-vexpress-xfce-arm.img of=/dev/mmcblk0 bs=4M
  5. Alter partition 1 on the SD Card to VFAT:  fdisk /dev/mmcblk0; Change "T"ype of Partition "1" to "b" (Win95 Fat32); then "w"rite the modified partition table.
  6. Create a VFAT partition 1:  mkfs.vfat /dev/mmcblk0p1 && sync
  7. Create two directories as mount points for the SD Card's partitions (you may want to eject/reseat the SD card to force a partition table re-read) :  mkdir sdboot sdroot
  8. Mount the partitions:  mount /dev/mmcblk0p1 sdboot && mount /dev/mmcblk0p3 sdroot
  9. Copy Fedora ARM's initramfs image (which contains additional modules necessary for Fedora to boot) to /boot on the sdcard . We have more configuration to get the initramfs image working. This just gets the image onto the SD card as a starting point :  cp -apf boot/initramfs-3.6.10-8.fc18.armv7l.img sdboot/initrd.gz
  10. Edit the fstab in the root partition, and use the following lines to replace the mount-point entries. This is just to be explicit about the partitions so there's no surprises when things start up. Remember, we clobbered the default boot partition for a FAT32 one, so this step must be done. The Raspberry Pi's GPU bootloader requires the first partition be (V)FAT, it looks for the Linux Kernel as kernel.img, and it uses config.txt and cmdline.txt for additional bootup settings. You cannot use Grub2 like you'd expect on an Intel-based Fedora.
    /dev/mmcblk0p3 					/                       ext4    defaults        1 1
    /dev/mmcblk0p1 					/boot                   auto    defaults        1 2
    /dev/mmcblk0p2 					swap                    swap    defaults        0 0
  11. Now, it's time to populate the /boot partition. The easiest way to go about this part is to grab a copy of /boot from the Fedora 17 Remix to reuse the known-working kernel, command-line parameters, and whatnot. If you are (or aspire to become) a brave, daring, hairy-chested Linux God, you could alternatively reconstruct your own /boot from the contents of the Raspberry Pi GitHub repository, in the firmware directory. I highly recommend starting from the F17 Remix contents first, just to get a working config.txt and cmdline.txt that's compatible with Fedora. You can always swap the Firmware and Kernel in /boot with Raspberry Pi's Upstream once you confirm the baseline setup is working. In a pinch, I have a tarball of my own Raspberry Pi's /boot contents:  (download the tarball)
  12. Tweak the config.txt file in the SDCard's /boot directory to declare our Fedora initrd.gz. This tells the Raspberry Pi GPU bootloader to load our initrd.gz file into memory for the Linux Kernel's benefit.  Add these lines to the tail end of /boot/config.txt
    ## LALEE: This sets up an initrd ##
  13. Tweak the cmdline.txt file on the SDCard's /boot directory. We will tell the Linux Kernel about the initrd.gz file loaded into RAM, and we will also tell it about our Root Filesystem being partition 3, versus Fedora Remix loading it from partition 2. The major difference here is we have an explicit swap partition, whereas Fedora Remix uses a swap file inside the root filesystem (/swap0).  I also add a "3" to the tail end of the kernel command line to force Linux into Runlevel 3 (multi-user, without X). If you don't want a "headless" Raspberry Pi, and want the pain of running Xfce, use "5" instead. Finally, the initrd option takes two parameters - a starting address (0xa00000 as we instructed the RPi bootloader via the config.txt tweak above), and the size of the initramfs.gz file in Hexadecimal notation. For RC2, the size of the initramfs is 0xc2bba3.

    For future reference, you can get the Hex conversion from any "Decimal to Hexadecimal" conversion calculator; use Google to find an online version if necessary.
    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 initrd=0xa00000,0xc2bba3 root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait quiet 3

That should be it. sync, umount sdboot and sdroot. Next comes resizing the root filesystem.

Resize the Root Filesystem

Before trying your shiny new SD card, you'll probably want to grow the root filesystem on your SDCard to the end of all available space to maximize your SDCard's storage space. If you want a friendly, dedicated tool for this, I suggest gparted. As you've probably noticed, I like to do things manually, and for my setup, I use these steps:

  1. Redefine the upper boundary of the rootfs partition: fdisk /dev/mmcblk0, "d"elete partition "3", then "n"ew, "p"artition "3", start and end at the default settings suggested by fdisk, then "w"rite the updated partition table. 
  2. Ensure the partition's contents are "clean", and then perform the resize operation: e2fsck -f /dev/mmcblk0p3 && resize2fs /dev/mmcblk0p3
Try your new image!

Now that the root filesystem is resized, your shiny new SD Card is ready for use in the Raspberry Pi. 

Drop a note on this blog if you get stuck, as this all appears to be working fine for me. Oh, I almost forgot: Your default root password is fedora . Please change that asap. Other than that, enjoy your new Fedora 18 ARM RC2 image! 

My Future Plans for Raspberry Pi / Fedora

I am doing a fair bit of personal research into this area, as it's quite different from anything I've previously done with getting Fedora running on the original Xbox.

Ultimately, I'll probably work toward building my own Fedora Mock environment that watches the ARM source repositories. In this environment, I envision using distcc and cross-compilers running on beefy x64 Intel boxes to compile the "arm7hl" SRPMs for "arm6hl" -- where the cross compilers are specifically tuned for the Broadcom BCM2835 processor.

IMHO, Self-Hosted compilation from a low-powered ARM compilation farm is a "nice to have" goal, but that's just not practical when there's plenty of Intel CPU power readily available.

If you're interested in my research pursuits of an arm6hl distcc/cross-compiled Mock environment (I'm not interested in Koji at the moment, as that's just a bolt-on orchestration framework that can come later), feel free to egg me on in the Comments below. Offers involving contract work, career opportunities or other forms of project-related funding are more likely to get quicker results. :-)

Filed Under: fedora_18 linux-kernel projects raspberry-pi