Archive / April, 2014

Modern Device’s Shipping Policy

In an effort to ensure that customers are completely satisfied with their shopping experience here at Modern Device, we’ve done a little data analysis to come up with our official shipping policy, lovingly titled the 2-Day Guarantee. Basically, if you place an order with us by 3:00 PM, we guarantee that it will ship in two business days or less (some exceptions do apply). If we can’t ship it in two business days, we’ll upgrade the shipping on your order for FREE. For all the wonderful details, read on.

Our Goal: Same- or Next-Day Service

At Modern Device, we strive to fulfill orders as soon as possible, and in the past eight months over half of all orders have shipped the day they were received. More than 80% of all orders have shipped within one business day. Those numbers might be impressive, but we’re constantly working to get them higher. In the meantime, our data shows that a whopping 89% of orders go out within two business days, which is why we’re introducing our 2-Day Guarantee.

Exceptions (The Fine Print)

The 2-Day Guarantee does not apply to orders containing items that have been specifically labeled as pre-ordered or backordered.

Since we are a small outfit, we may not be able to fulfill some larger orders within 2 business days due to production lead time. If you place an order that we anticipate will require more than 2 business days to fulfill, the 2-Day Guarantee will be waived and we will contact you by email with a more realistic estimate of when the order will ship. These estimates are not backed by any kind of guarantee.

Based on the usual USPS and UPS pickup times, we’ve set 3:00 PM as our same-day cutoff. That means orders placed after 3:00 PM count as being received the following business day for the purposes of our 2-Day Guarantee. However, if you place an order with expedited shipping after 3:00 and need it shipped that day, you can call us at (401) 709-2424 and we’ll let you know if we can get it done.

By Jeffrey Blum on April 22, 2014.



One would think that 10 years on, the market for DIY Arduino boards would be somewhat lacking in excitement – to put it in milder terms than I realize a lot of techies might use. Still, TechShop, a San Francisco-based DIY technology and maker space outfit, has been building a lot of our BBB’s (Bare Bones Boards) in their Arduino classes. They find that students are very excited about building their own boards, and then using them to learn how to program.



I have the same experience with the BBB in my classes at the Rhode Island School of Design. But both TechShop and I have had the same experience which is that someone always wants to use a shield of some form, on their board. This creates a form factor problem and while it’s usually fairly easy to solve the problem, the solutions are always sub-optimal, in regards to the form factor. Here’s a BBB sitting on top of an Adafruit Wave Shield, and the “pin torture” that made it happen.

It should be pointed out here, that this whole mess is caused by the Arudino’s failure to mate with a breadboard. This debate goes back to the early days of Arduino and at one point, the Arduino guys were ready to change the form factor to be breadboard compatible, from what they admitted was just a mistake in the first prototype. All seemed good to rectify the mistake when two shield vendors (who shall remain nameless here) complained that their shields would have to be respun or adapted. The rest has been history.  I was part of that online debate so I can say I was there when the Arduino adopted this dubious (or sub-optimal) layout.

In any case, we are many years down that road, and many Bare Bones Boards later. It was time to try again with the existing facts on the ground, to create a breadboard friendly Arduino that still could accommodate a shield. When TechShop asked me to try to reinvent this wheel, I realized that I could also solve the same issue that existed with my own classes.

Here’s the Educato on a breadboard, showing again, what I believe is the advantage of “hiking” the board out over the edge of a breadboard, so that you can use both sides of the breadboard in a circuit. An LED and a resistor, say.


The board looks large but it is really only larger than the UNO outline in two places. In the front row of pins it has two extra rows to accommodate the breadboard pins. On the top right (closest to you in this picture) there is a little tab added on to accommodate the power rail pins. Other than that it’s just a copy of an Arduino Uno footprint. One mounting hole did have to be omitted though to accommodate the analog block. I won’t go over all the boards features here, but let me just mention one.

When we hook up hobby servos in my classes, students inevitably hook them up with their power lines drawing power from the boards power rails. That is, after the voltage regulator.  The stock voltage regulator on the BBB only supports 300 mA so this usually results in sub optimal results and unhappy students. I have to show students how to route the power for servos around the voltage regulator, which has two benefits:

  1. The current available for the motors isn’t throttled down by the voltage regulator
  2. The motor noise and voltage drops from the hobby servos are kept off the main power lines.

The Educato board can be configured to route the power line around the voltage regulator to three power pins on the analog block. These setup was designed to support hobby servos without a lot of fuss. A little shunt just below the analog block headers can be shifted from 5 volts (after to the regulator) to Vin (before the regulator, from the external power jack). This is an ideal power setup for three servos.

The kits come with all the surface mount parts soldered on and tested. It’s an easy build which beginners might expect to take a bit over an hour and more experienced builders a little over a half hour.

To celebrate the Educato launch I am giving away six Educato kits (one to a customer please) with an order over ten dollars. Just use code Educato.


By Paul Badger on April 18, 2014.

More Eagle Tools – The normalize-text ULP

As you might have guessed from my previous posts about the Eagle interface, I’m not Eagle’s largest fan. There does seem to be a user fanbase that have “drunk the Kool-Aid”, but enough of that for now. The CadSoft people have said that after another version or two, they will finally turn to addressing the interface. In the meantime (which may be a year or longer), you’re on your own with the tool you have (to paraphrase the inimitable Donald Rumsfeld).

Changing the size of text in an entire layer is a tedious task that I do once and a while, and like a lot of things in Eagle, seems entirely too much fuss. Sensing that there may well have been some other irritated users before me, who had solved my text-change problem (actually missing Eagle functionality) in an ULP, I searched for a ULP (user language program) to automate this task.  What I was a found a nine year old ULP named “normalize-text.ulp” by Tennessee Carmel-Veilleux.

Part of the problem of searching through Eagle ULPs for a particular job is that there is no rating system or attempt to curate the ULPs into what people find most useful. There are also no categories into which ULPs are organized, such as  “Text Modification”. Below is a screenshot of a couple random ULPs on the list of user language programs (ULPs) at CadSoft.

Screen shot 2014-04-18 at 12.29.02 PM


As you can see there is a “Like” button, and number of downloads, and the authors description to guide you, but no real rating system or “greatest hits”. I guess you could argue that there is some curation in the ULP’s, in that CadSoft includes a set of ULPs with Eagle, but I find the large folder of ULPs (titled “ulp” in the Eagle folder) to be vertigo inducing and without a lot of solutions for the jobs I actually do in Eagle, although I do use a couple of ULPs from the ulp folder.  The ULPs in the ulp folder also doesn’t do a very thorough job of patching the very large holes in the Eagle interface, for example, the useful “align.ulp”, I featured last post, is not included in the Eagle distribution.

OK, so I downloaded the normalize-text.ulp by Tennessee Carmel-Veilleux, and fired it up. It purported to normalize all the text on my “silkscreen layers” to my desired setting. Below was the original dialog box:

Screen shot 2014-04-18 at 12.32.11 PM


Not bad at all, as far as it goes. I fired it up and it generated a script of changes it wanted to make.

Screen shot 2014-04-18 at 1.01.03 PM

Not having a lot to go on, I punched “Execute” and … nada. Nothing changed. So I did what any adventurous Eagle user would do (on a junk design) I started cutting and pasting parts of the script. And quickly figured it out that it did indeed work. The “Display None tPlace bPlace;” line seemed to be turning off the tName layers that I was interested in changing, so the script didn’t work. A short patch later and the script was operational. It only seems to affect layers that are visible, which is probably a good thing in my book. Most times you don’t want computers changing things you can’t see in a file, especially if you don’t know exactly what they’re doing.

Anyway, I had a few complaints with the normalize-text ULP, even after I got it working. It wouldn’t save my settings between calls to the ULP, so I had to remember what settings I had used last time (you may feel this is trivial, but in my view, dialog boxes should remain the same between calls to a utility program – check the behavior of Photoshop filters for example).

More importantly, I couldn’t control the layer the program was acting on, so the ULP acted as something of a shotgun, without a clear idea of what it was aiming at, unless you knew what “silkscreen layers” were, or were inclined to dig through the docs and source code (and had the skills to do so).

So with a couple hours work, and a bit of coding I had this:


Screen shot 2014-04-18 at 12.54.38 PM


The ULP now worked with Eagle 6.5, and had  fine grained control over which layers it covered. It switches units seamlessly and also remembers all of the user parameters between ULP calls. Because it needs to write a scratch file, it will even remember your last-used parameters between Eagle restarts. The original author, Tennessee Carmel-Veilleux has given me his blessing to put a new revision number on the ULP.  I’ll upload the modded ULP to CadSoft, too, but in the meantime, it’s in our “tools” repository as normalize-text2.0.ulp, and you’re welcome to take it for a spin if you use Eagle. Eagle Kool-Aid lovers needn’t bother, because “it’s easy to change text on a layer in only four or five steps” :), as I’ve read several times in Eagle forums.

I’ll repeat the warning about not expecting our Tools folder to look too organized, I keep downloading ULPs to find more useful gems. Incidentally my idea with the tools folder, is that I won’t have to do a lot of digging to change versions of Eagle. I just drag the tools folder into the new version and I’ve got all my  mods and hacks with me.















By Paul Badger on April 17, 2014.

Eagle Tools

After my last post about Eagle I heard from several people who agreed with me and others who partially agreed with me. But I found just as many who vehemently loved Eagle regardless of its flaws. There seems to be a  group of power users who have “drunk the Kool-Aid” but I’m sure other power users  have just moved on. You can make of this what you will if you are an Eagle user, but again I would emphasizing that IT DOESN’T HAVE TO BE THIS WAY. The Eagle team has said that after the Eagle 7 release, they will start to address some interface issues, so that is a good thing, even it happens in 2015.

One of my points was that the vast majority of Eagle  clunkiness would be much easier to fix than the things CADSOFT has chosen to spend their time working on. For someone who actually pays for an Eagle license – and updates – on a regular basis, this has the effect of taking a lot of wind out of one’s sails, so to speak.

Below is a wonderful list of essays on fixing Eagle’s flaws and improving it that came up during the online discussion.

Many of these posts have been moved from the new Newark Eagle forum, so the dates are not very accurate. The posts date from November of 2011 so about two and half years ago. In that time CADSOFT has released three – six updates (sorry I’m too lazy to document this accurately), and virtually none of what they have added in the versions has addressed anything in the essays, which are way more elaborate than anything I have had to say. The essays are definitely in the same spirit and direction as my earlier remarks. So one might be forgiven from assuming that the CADSOFT team doesn’t put much credence in what their users have to say, or the things that bug them about the package. If nothing else, improving the product would help CADSOFT sell to new users, and stop migration of their current users. If I was a Windows user I would have been gone a long time ago.

In any case, you can’t whine about the broken things in the world. The world is too broken in too many places. If you can’t get what you ask for, then you have to do it the Eagle way, which is definitely DIY. There is a very nice ULP written by Danny Danhave called “align.ulp”. It works very nicely, for what the things it does, but is all command line driven, which means you have remember the syntax for up to 10 flags, and their combinations and arguments. I decided I would learn Eagle’s User Language and try to put a front end on the ULP. After more time than I would have wished (3.5 days), I arrived at a tool that works really well, as far as it goes. Here’s the dialog box.

It only works in the board menu. So you can’t line up pins for parts etc. or schematic symbols.  It only lines up parts and not traces and vias. There are other ULPs that do work on Libraries and Schematics, but I have to ask myself whether I want to keep on coding on an Eagle workaround for a function that is now built into virtually every drawing and CAD program in existence. And doing this in a user language program instead of the source code base just seems silly. So we’ll see about updating the tool. I’m a lot more interested in seeing CADSOFT get their tool out of the dark ages.

In the meantime, here’s the tool, called alignD.ulp, with many credits to the original author Danny Danhave. He did all of the heavy lifting. I like the fact that the ULP has a distribute option that can be used to evenly space parts. It can also be used to line parts up with previously existing parts or accept a parts list. The “Distribute” option toggles with the “Increment” option, which can be used to put a known distance between parts. All in all it’s a great little tool but it has a long TODO list.

  • Make it work with vias and traces
  • Make it work in the device editor
  • Make it work with vias and traces
  • Make the “Distribute” option work independently of having to align an object
  • Restore some command line functionality to it, so that it will run “headless” with the last settings.

I also dug into the menu ulp to make myself a menu to start driving (and organizing) some of the Eagle DIY dodads I’m finding and making. I made an Eagle script to load a lot of my preferences and a decent palette. The Eagle palette tools are a post for another day – if you’ve ever used Photoshop, you know how deficient they are.

Here’s my little menu so far.

There are all sorts of things you can automate, but most of what I’ve automated so far should be in the interface. I’m sounding like a broken record I know. Here’s my Grid menu which automates the grid box.

It has all the settings I normally use with the grid. You might be used with the ‘m’ notation. That is the multiple box, where you can have a grid of 5 mils say and then have a grid line only appear every 5 units, (or 25 mils). I find “5m2 1”  to be surprisingly useful and one of my go-to settings.

Above is the layer menu and it utilizes a mix of just eagle scripting and running ULPs. You can run a ULP from a Script but not a Script from a ULP. One notable feature is the “BottomOnTop” menu item which changes the display order for layers.

Here is my ULP menu with a grand total of two ULPs so far. There is one called something like change-text-in-library.ulp that despite a lot of mention on the Eagle forums doesn’t seem to be in plain sight right now. It’s probably just changed names slightly, or I’m overlooking it.

Here’s the view menu with a few useful things I’ve found. The fill and nofill commands are just aliases to ratsnest and it’s curious opposite, which is also curiously missing from the Eagle tools menu, just under Ratsnest – aka Rip @; which removes the fill on polygons that makes it very hard to see what’s going on. Up till reading the manual and finding this gem, I would always have to move the corner on a polygon to get it to display unfilled again. It’s the joy of Eagle.

OK – I’m wrapping up this Eagle tools post. There are many more Eagle details I could talk about but here’s the link to my tools folder on Github. Just don’t expect it to be very organized, it’s still a work in progress. There are also some useful CAM files in it that automate that tedious and confusing process a bit.

To use the tools, download the zipped file from Github to your Eagle folder, unzip the file and rename the folder  “tools”. In the Eagle IDE choose File->Execute Script and point to the “MDmenu.scr” file inside the tools folder.  This will load the menu script I just (partly) explained.

If you want to check out more of my preferences and settings run “eagle.scr” in the tools folder. Voila, you have all of my  tool settings  and preferences. which I don’t expect you will like 100 percent. So start modifying and improving my scripts. With Eagle, it’s the only way you’re going to get a half way fluid interface, it’s a DIY world baby! If you don’t like any of this, the standard Eagle script will run the next time you open Eagle (and choose new->Board/Schematic – it’s an Eagle quirk that you have to choose a “New Board/Schematic” (sic)). This will wipe out all my menus and prefs I believe. The menu will need to be reloaded every session your want to use it, but it’s also called from “tools/eagle.scr”.

I’d love to make this menu as usable as possible so send me any leads you come across on useful ULPs and Scripts, or better yet, make your own menu compilations.


By Paul Badger on April 11, 2014.

Arduino Yún: Connecting a JeeNode to the Internet

Last week Paul handed me one of our new Arduino Yún boards and asked me to get a project going. I know the Uno and the Arduino environment well, but the Yún has an Atheros processor running Linux. I had little idea how I was going to wrap my head around the command-line oriented Linux part of the equation. I figured I’d give it a shot and see if I could have my way with the Yún’s Linux processor. As you’ll see, I had a lot more success than I thought I would.

Setting up the Yún’s wi-fi for the first time is fairly straightforward, so I’m not going to bother explaining how to do that when you can find a great start-up guide at the Ardiuno website. The only thing I’d add is that accessing the setting in my browser was hit or miss when I tried accessing http://[board name].local. Instead, I recommend memorizing the Yún’s IP address from the configuration window because accessing it that way (http://[IP address]) worked every time and the IP address is how you access the Linux processor through SSH. I should also mention that only the absolute latest version of the Arduino IDE, version 1.5.6-r2, actually supports the Yún, so make sure you install that too (you can find it here).

For my first Yún project, I wanted to focus on the Atheros processor because the Atmel processor is identical to that of the Arduino Leonardo and functions essentially the same. But what to do? As it turns out, we have a hot box that we use to keep the radios dry for our JeeLabs products, and when it was first set up we added a humidity sensor connected to a JeeNode USB that output humidity and temperature data to a LCD screen via an LCD plug (for the sake of product placement, I might as well mention that a Jee ProtoBoard was involved as well). The thing is, every now and then the darn thing would freeze and need to be reset, and with everything that goes on here no one really has time to check on the hot box with any kind of regularity. Clearly we needed a way to be able to check the status of the hot box from anywhere. That’s where the Arduino Yún would come in.

To start, let’s see how the data gets from the box to the Yún. Here’s the code for the JeeNode USB on the hot box itself. It’s pretty straightforward; the data points are collected, sent to the LCD for display, and cast to integers after multiplying by 100 to preserve two decimal places before being broadcast by the radio. There’s a one-second delay and then the whole thing repeats. Note the group number 68 from rf12_initialize; we’ll need to make sure the JeeLink on the other end gets configured with the same number.

#include <PortsLCD.h>
#include <Wire.h>
#include <LibHumidity.h>
#include <jeelib.h>

PortI2C myI2C (1);
LiquidCrystalI2C lcd (myI2C);
LibHumidity humidity = LibHumidity(0);

#define screen_width 16
#define screen_height 2
int Fan = 7;

void setup() {
  pinMode(Fan, OUTPUT);
  digitalWrite(Fan, LOW); //LOW is on

  lcd.begin(screen_width, screen_height);

  lcd.print("HUMIDITY STORAGE");
  rf12_initialize(20, RF12_915MHZ, 68);

void loop() {

  int data[3];
  lcd.print("HUMIDIY: ");
  float h = humidity.GetHumidity();
  data[0] = (int)(h*100);
  float t = humidity.GetTemperatureC();
  data[1] = (int)(t*100);
  lcd.print(" F");
  t = humidity.GetTemperatureF();
  data[2] = (int)(t*100);
  while (!rf12_canSend())
  rf12_sendStart(0, data, 6);

The code for the JeeLink that receives the data is even simpler. It just receives, unpacks, and prints the data sent by the JeeNode USB. You should also note the group number, 68, which matches the code on the transmitting JeeNode USB, and the serial baud rate, 57600, which we’ll need later.

#include <jeelib.h>

void setup() {
  rf12_initialize(18, RF12_915MHZ, 68);

  Serial.print("Receiving data...");

void loop() {
  if (rf12_recvDone() &amp;&amp; rf12_crc == 0) {
    int* buf = (int*) rf12_data;
    for (int i=0; i&lt;3; i++) {
      Serial.print(" ");

Now that we’ve got the JeeLink streaming data over Serial, we can use the Yún to put it on the web. To do this, we’ll need to go directly to the Atheros processor, which we can do with a simple SSH in Terminal.

ssh root@[Yún IP address]

The first time you do this it will give you a security warning, so just enter “yes” to connect to the Yún. Once you’ve done that, we’ll need to install the FTDI drivers so the Yún can interpret serial data sent through the USB port. Luckily, the Yún’s Linux distribution Linino uses a package system that makes installing such things incredibly simple from the command line, so we’ll also install a second package we’ll need later.

opkg update
opkg install kmod-usb-serial-ftdi
opkg install pyserial

The first command just updates the package list so you only have to do this once. If you ever have trouble finding a package, try running update again.

With the FTDI drivers installed, the Yún can now interpret serial data sent to it from the JeeLink through the USB port. To put that data on the web, we need a Python script. That script, in all its in-line commented glory, is as follows:

# This program reads off /dev/ttyUSB0 and writes an auto-updating html file with the results
# We have a jeelink on /dev/ttyUSB0 sending us data like "2580 7183 16132", which we divide by 100 to
# get humidity, temperature in celsius, and temperature in fahrenheit

import serial # Load pyserial
ser = serial.Serial('/dev/ttyUSB0', 57600, timeout=3) # Open the serial port at 57600

while True: # Loop forever
        data = ser.readline().split() # Split our data into an array, "2580 7183 16132" becomes [2580, 7183, 1613]
        if len(data) is 3: # The first line usually says something like "reading data..." ignore it.
                data = [float(thing)/100 for thing in data] # Divide each number by 100
                file = open('data.html', 'w') # Open the html file for writing
                file.write("<html><head></head>\n<body>\n \
<title>Yun server</title>\n<p>Humidity: {0:.2f}</p>\n<p>Temperature (C): {1:.2f} \
                </p>\n<p>Temperature (F): {2:.2f}</p>\n</body></html>".format(*data)) # Write the html page with the data-- *data unpacks it
                file.close() # Close the file

To make this available on the web, we have to move it to a special directory for files that we want the Yún’s server to host called “/www/”. We’ll also move our code (we named the file to its own subfolder because it’s going to create a file.

#Starting from the Yún's root directory
cd /www/
mkdir humidity

In a new terminal window, navigate to the folder containing, then use the following command to copy it to our target directory.

scp root@[Yún IP address]:/www/humidity/

Enter the password, then go back to your original Terminal window.

cd ./humidity
chmod +x #make the python script executable
./ #run it!

The last step is to build the webpage around the data to make it look nice. The index.html file, which will need to be moved to the same directory as, is as follows. I didn’t write this part (credit goes to Noah Beford), so I’m just going to call it a magical box. What I can tell you is that the stylesheet isn’t necessary, we just wanted it to look like the rest of our website.

<!-- FONTS -->
<meta charset="UTF-8" />
<link href='' rel='stylesheet' type='text/css'>
<link href=',700' rel='stylesheet' type='text/css'>
<!-- END FONTS -->
<link rel="stylesheet" type="text/css" href="humidity/style.css" media="screen" />
<script src=""></script>
<script type="text/javascript">
function reloadData(){
<b>Here's the data from the Modern Device dry box, where we keep the <a href="">radio chips</a>:</b><br />
<br />
<div id="data"></div>

<p>This is being relayed from a <a href="">Jeenode</a> mounted on the dry box to a <a href="">Jeelink</a> plugged into an <a href="">Arduino Yun.</a></p>


Now that everything’s in place, we can access the data stream by going to http://[Yún IP address].local/humidity. To make it available to the public, we set up a redirect for port 80 of our external IP address to the internal Yún IP address (more on that in a future post; for now, you can just ask a friend who’s a gamer). We also set up a special subdirectory on our website so you can see the final results by going to

GitHub repository for this project
Buy your own Arduino Yún

Stay tuned for more!

By Jeffrey Blum on April 2, 2014.

Modern Device and Facebook

Almost ten years ago, Modern Device was founded with the simple mission of making DIY electronics accessible to everyone.
Today, we’re happy to announce that we’ll be joining a similarly minded company, a company with the goal of bringing people together, a
company which is now a household name. We’ve always been happy to help people with their electronics projects, and we’re looking forward to
developing the products Mark and Cory proposed when they stopped by with an offer last Tuesday.
We can’t disclose anything quite yet, but let’s just say the day when you can “Like” something with your physical thumb isn’t too far off.
As for the Modern Device website, wiki, and forum, all will remain untouched– everything you love about Modern Device will remain. We’re excited
to see what opportunities this partnership produces.

Keep hacking!

Paul, Jeffrey, Noah, and the Modern Device toaster.

By Nadya on April 1, 2014.