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 upload.py) 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 upload.py, then use the following command to copy it to our target directory.

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

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

cd ./humidity
chmod +x upload.py #make the python script executable
./upload.py #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 upload.py, 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='https://fonts.googleapis.com/css?family=Open+Sans+Condensed:300' rel='stylesheet' type='text/css'>
<link href='https://fonts.googleapis.com/css?family=Roboto+Slab:400,700' rel='stylesheet' type='text/css'>
<!-- END FONTS -->
<link rel="stylesheet" type="text/css" href="humidity/style.css" media="screen" />
<script src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
<script type="text/javascript">
function reloadData(){
<b>Here's the data from the Modern Device dry box, where we keep the <a href="http://moderndevice.com/product/rfm12b-radio/">radio chips</a>:</b><br />
<br />
<div id="data"></div>

<p>This is being relayed from a <a href="http://moderndevice.com/product/jeenode-v6-kit/">Jeenode</a> mounted on the dry box to a <a href="http://moderndevice.com/product/jeelink-module-assembled/">Jeelink</a> plugged into an <a href="http://moderndevice.com/product/arduino-yun/">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 humidity.moderndevice.com.

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 Noah on April 1, 2014.

Eagle CAD: Beginners and Power Users

Eagle CAD or Eagle PCB or just Eagle is the electronic design automation (EDA) software package that most hobbyists and beginners use. Some of this blog post is probably useful to Eagle beginners, or people just learning the package. Other parts of it are only going to be understood thoroughly by people who have used Eagle for a while, and experienced its mysteries. This is NOT a tutorial on how to begin using Eagle, there are lots of excellent ones on the web. Not too many of them actually take a critical attitude toward Eagle though, and ask why things are the way they are.

Newark Electronics bought Eagle about six months ago, so perhaps they are ready to throw a little money at CadSoft to move Eagle a little closer to modern EDA software packages. This blog is offered in the spirit of both constructive criticism, and as caveat emptor (let the buyer beware), for potential purchasers and adopters of Eagle.

Some of the reasons why the DIY electronics and Open Source community have adopted Eagle are summarized below:

  • Cross platform versions with Windows, Mac and Linux available.
  • Reasonably priced and freeware options: basically Eagle is one of the lowest cost EDA products after freeware, for our shop, it’s the EDA software we can afford.
  • Extensive libraries are available.
  • An extensive user community – at least on the “low end” of hobbyists, DIY and casual users.

Modern Device also uses Eagle, with our choice influenced mostly by the cross platform availability.  There are several other nice features of Eagle – I’ll get to the downsides in just a bit :)

  • An extensive user scripting language that allows extending the software package with script files being plain text so that they are human readable. This is a double-edged sword,  being handed a DIY interface instead of a finished, sensible GUI might seem like “thin gruel” but it does really allow one to have some things the way you would wish.
  • The navigation seems to be usable. You may laugh at this, but many software packages don’t allow flexible
    “zooming to navigate”, one of the fastest ways to move around. InDesign comes to mind.
  • The interface, while clunky at times, is modifiable in many ways.

The Downside

OK here comes the rant. Eagle has many, many rough spots that require getting used to, especially for Mac users who are accustomed to more fluid user interfaces. Let me lay out of the list of my pet peeves then I’ll have some words of explanation about each one. This list is fresh in my mind as I recently had a lengthy conversation with a representative of CadSoft, the publishers of Eagle.

First a few words about the nature of my comments. There are many things that Eagle can’t do, and which Eagle does not try to do. For example, the Beagle Board and Raspberry PI were not designed in Eagle because it would be slightly insane to attempt projects of that complexity without proper design automation tools to accomplish the job. These are not the downsides I’m talking about with Eagle. I am talking about basic things that the package should do because they are standard interface items on low-end (and free!) CAD and drawing packages.

  • In Eagle, the mouse is used in a manner that is likely different than any way you have used it in other drawing or CAD packages. CadSoft seemingly invented the GUI  from whole cloth, impervious to existing interface design. The CadSoft rep told me that Eagle had been in existence for 25 years, so my technician’s remark that “Eagle looks like it was designed before modern GUIs”, might in fact be partly true.
  • The UNDO buffer is different from any software package I have ever used.
  • The user interface forces the user to do many things the “Eagle” way.
  • Error messages are often wrong, leading new users to the wrong place to try to get their task accomplished.
  • Creating parts is quite mysterious and a bit tedious. Which doesn’t mean that it’s impossible to create parts, just harder than it should be in my view.
  • Some tasks require using the command line interface because there is no menu item for the task.
  • Seemingly paradoxically, some tasks require using the mouse, because there is sensible command line equivalent.
  • There is no dialog or even method for aligning parts, or distributing them (spacing them evenly over a distance), something I find very useful. Yes I know there is a grid, and no, it does not make up for this lack of functionality.
  • The arrow keys do not move a part a custom distance, this is highly useful part of many other drawing and CAD programs. How hard can this be to implement?
  • Many items have less than useful default settings for tools and GUI behavior.
  • Color palettes are not able to be loaded, saved and saved in files the way they should be.

The mouse

As I said above, Eagle uses the mouse in entirely different ways than any graphic programs I have used. Selecting objects is a entirely new experience, for example you can’t shift-click to add to a selection, nor command-click to subtract from a selection. The main way in which Eagle varies from other graphics packages though is that in most (all?) of the other software packages I’ve used, one selects an object and then decides what operation to perform on the object. In Eagle this is inverted, one first decides what to do with an object and then selects either an object or a group, further mouse clicks are required to actually confirm the operation. This has the effect of multiplying mouse clicks by at least one third. Many things in Eagle just seem like they take much more work than they should.

In many graphic software packages it is possible to select a group of objects just by dragging a rectangle around them with the same arrow tool that does the clicking. Eagle requires the use of a group tool to do the same thing, which again increases mouse clicks for no good reason that I can see. I’m not holding my breath for Eagle to change this bizarre feature though, since it has been a part of Eagle for too long to ever be changed without irritating some die hard “clickers”. The group tool in general is a pain to use. After selecting a group, the tool defaults back to its “function” tool (the last tool clicked before the group tool). To select the group tool, one needs to click on it again, more useless clicks IMO. Considering that a more conventional paradigm would eliminate the need for the “group” tool, and some items in sub-menus, is enough of a reason to change this in my opinion. The KISS principle should apply here I’d say.

Undo what?

The UNDO buffer is also implemented in a fairly bizarre way. Often undoing a move, also undoes the last (desired) action, so that one has to go back and redo the correct action one just performed before the mistaken action. This is easily worked around by continuing to perform another errant click, and then UNDOing but WHY? Again, it just seems to be the Eagle way. It’s hard to say if this could ever change, it doesn’t seem like such a hard thing to me,  but the motivation to fix something which maybe doesn’t seem broken (to CadSoft) is probably lacking.

You can’t do that from here!

The Properties dialog box

I have several examples of being forced to do things “the Eagle way”, but one undoubtedly has wasted several human-years of time, especially for Eagle beginners. The useful Properties dialog box lets users change almost every property of a pcb trace.  And one can even change the signal name (which determines the network of (parts) to which the trace is connected). IF THE SIGNAL NAME IS A NEW NAME, all works well. If however an existing signal name has been used before, Eagle brings up the following dialog.

The vile error message! Why God, why?

OK, so instead of the Eagle programmers sending us elsewhere, why doesn’t Eagle just change the damn name of the signal, as if one were in the Names dialog box? I’m afraid this is a divine mystery and it may have been this way for 25 years. It has been baffling newbies and intermediate users just as long.

Another example is copying a symbol in the library editor. Although the Copy command works from the command line with Devices and Packages, the same functionality is missing from Symbols. Again, why? Humans are very flexible and will learn to use every kind of clunky interface. They’ll even complain when a bad interface is changed to a better one, because they have invested so much time in learning the bad interface, but it doesn’t have to be this way.

Warning: error messages are wrong!

Here’s a little experiment. Take one your Eagle board designs that has a ground plane. Add a via from the Draw menu, Name it GND (with the Name tool sic) , or whatever you have your ground plane named, and then try and delete the via. Depending on the circumstances, it will delete, or it will bring up this dialog:

So if you were a beginner, you would go to the schematic and start looking for your Via, which of course is nowhere on your schematic. The trick, which every intermediate user and beyond knows, is to use the Ripup tool. So why hasn’t CadSoft figured out how to parse out what people are trying to delete and send them to the appropriate tool? The same thing holds when a user wants to “delete” a trace, when they really want to Ripup a trace. Again they are sent to the schematic page when all they want to do is to rip up a trace, which looks strikingly similar to deleting a trace, to a beginner. This is simple stuff to fix (change the error messages – it doesn’t get easier than that).  CadSoft keeps adding much more complex features and ignoring these trivial details to fix.

The parts editor

Making parts in any CAD package is tedious and requires concentration. Eagle just seems to make it harder than it should be. In Eagle a device is umbrella container which holds the schematic symbol and the package (board footprint) together. From the device editor window, one may click to edit either the symbol or the package (footprint), but once done editing, there is no way to get back to the device window without digging through a possibly quite lengthy menu.

When you open a library to edit parts, the library window has a column of “date modified” values. When you Add a part, or go to the Control Panel, the “date modified” column is no where to be found. When one Adds a part, there is a nice search box to find your part in a long list of libraries. However when you visit the Control Panel to copy a part into another library, the search box is nowhere to be found.  Why? Is it useful in one context and not in another? It’s another divine mystery and you can ask the Vatican (or not) if you want an answer. Copying, renaming and deleting parts is also more complex, inconsistent and far from intuitive than it should be.

The missing align/distribute tool

If you have ever used a drawing program or page layout program you know that guide lines and methods of aligning things is highly useful. Here is one from Inkscape:

Adding this functionality is not rocket science. If you think back to your high school coordinate geometry.
An algorithm for aligning parts might look like this:

  • Find the centers of the selected parts.
  • Check to see if the x or y dimension of the parts is more consistent
  • Set all the centers to the average of all the parts, or the nearest grid point, or whatever.

It just is not that hard. Why hasn’t this been added ages ago? There is a user language program (ulp) which aligns and distributes parts. It works OK, but is a thin shadow of the dialog box above. For CadSoft it would be a good introductory assignment for their intern programmers just getting up to speed in the ulp language.

The missing arrow keys functionality

In most drawing and layout programs, the arrow keys nudge the selected element according to the direction selected by the user. The amount could be set by the grid or in a separate dialog. Again, the functionality is AWOL without good reason.

Less than useful defaults – the color palette

Eagle comes with sixteen extremely saturated colors in a palette of 64 colors. The rest of the colors are set to middle gray. Many of the layers in the default setting are set to gray. Why? More subtle and more transparent colors are more useful. Ask Edward Tufte. Saturated colors tend to take over and displace other information. Even Sparkfun figured out that they should set the defaults of the top and bottom copper layers to something less saturated. OK I’ve spent some time in art school. How much work does it take to get someone to design a decent palette and put it into Eagle instead of gray squares. Why can’t I load and save palettes and why aren’t they saved in files, so when I send a file to someone else I can know that they are seeing the same thing I am when I discuss the file?  The programming (and other simple UI things above) for features such as a decent color palette implementation is much simpler than the Meander distances that the Eagle programers seem to have been working on of late.

The defaults for the text sizes and trace widths are less than useful too. Yes you can set these things in a script file (but they’re not shown in the default eagle.scr file) but how about a decent preferences page with these things in it, so users don’t have to program to setup their software?

Scripting Eagle – “the Eagle way”

Although the interface does leave a ton of things to be desired, CadSoft should be recognized for their scripting system, which allows users to add back some of the missing functionality, albeit in a slightly less convenient way.

Wrapping up

Tomorrow I’ll go over my first attempts at setting up a personal style for the editor with a couple of my own scripts.

If you know of good script repositories and script resources, I would appreciate the information. We may not have been offered a truly professional grade tool like Photoshop, but we can still control a lot of it ourselves, which is at least a palliative.

I’ll also keeping adding and editing this post for a while. I’m going to link to it from the Eagle forum. The CadSoft representative I spoke to said that the programmers work on what users are asking for, so register on the CadSoft forum and start posting if you agree with any of the things I’ve said. You may also want to have a word with your Newark representative, if you buy parts from Newark, they now own CadSoft and Eagle. I believe my conversation with the CadSoft rep was initiated when I mentioned Eagle in a marketing phone call from Newark.







By Paul Badger on March 28, 2014.

Wind Sensor Progress II

In the last post I described the effort to record zero wind values at a range of wind speeds and to integrate that information with data we had gathered previously. We had a an experimental but useable data set from our temperature controlled wind tunnel tests. The data made nice curves like this:


This only shows two temperature points but we have a dataset of about 10 datapoints 2 degrees apart, so about 20 degrees C. The curves all have very similar shape, so we took the liberty of  just shifting the same curve up and down on the y axis, according to temperature. From a handy website the Caimbridge (UK) Engineering Department posted on hot wire anemometers, we found this reference on calibrating hot wire sensors.

In practice, the voltage registered at the anemometer output is not that across the sensor but the e.m.f. E that is applied to the top of the Wheatstone bridge, the two arms of the bridge acting as potential dividers so that the relationship becomes in effect

E2A2 = B U0.5

The constant A may be replaced by the zero-flow voltage E0 when high accuracy is not required. In practice, the value of the exponent changes with sensor and velocity as do the values of A and B and its therefore necessary to calibrate each sensor individually and to check this calibration frequently. An exponent of 0.45 is nearer to that found in practice.

After some tests and false starts we came up with the workable.

Vraw = Vzw + b * Windspeed ^ c

Where Vraw is the wind sensor’s VR output, Vzw is the zero-wind value determined from the coldbox data. b & c are constants to be determined by our hard-working Excel solver.

Because our first calibration was just going to scale the same curve up and down the y axis, the only thing that needed to change for each wind-speed calculation was to determine the Vraw value and the Vzw value (from the Thermistor).

I had never used the Excel solver before, but having a reason to use it was very exciting for me. As a new user, I’m not going to attempt to give you a tutorial or any details on the solver, but let me give you general description of how the problem is solved.

First one needs an Excel formula  that translates the equation above into a “calculated” columns of values. The  b & c constants are plugged into Excel cells of their own. Then the “fit” values are subtracted from the actual data values, and the difference is squared. This is a really traditional way to examine how well a curve (equation) “fits” the data, and it also has the virtue of getting rid of negative numbers.

We set this up on the excel spreadsheet and summed the whole column of these errors. We then set up some cells which contained  the constants b & c. The solver’s job then was to tweak the constant values to minimize the errors in the “fit”. If you’ve never done this before my description is probably not going to get you there, but having done it once, it’s pretty straightforward and seems magical. The amount of brutal arithmetic that the solver is saving is slightly mind-bending to me.

OK – so how does well does it all work? We have a lot more validation to do but according to our first results with calibrated sensors, they work brilliantly and maintain their temperature insensitivity very well.  The math is still very rough though. Instead of just moving the curves up and down, separate curves really should be stored for every two degree temperature point and be used by the calculations, for that particular temperature.

In an electronic sense several targets have been identified and several new prototypes are under way. The ambient temperature thermistor days are numbered especially, to be replaced with a temperature sensor whose output is independent of the supply voltage.

The new .1% resistors also work brilliantly and two random sensors pulled off the line and input into our laptop test jig matched fairly closely as you can see from the data below.

Screen Shot 2014-03-06 at 3.30.22 PM

This data is from a stroll down our hallway so the speed is realistic, but I’m more excited about how well the sensors track each other. The offset lines are from alternating sensors.

Screen Shot 2014-03-06 at 3.29.26 PM

This is outdoor data on a mild (coldish) day. You can see that my independent temperature sensor is reporting 6.56C and the thermistors are at -4.24 so there is some discrepancy there that needs looking into. The wind speeds seem to be tracking each other quite closely, so I’m happy about that.

I added a calibration line in the sketch that can be used to globally adjust the zero wind voltages to help calibrate out the error of various wind sensors. It seems to work well on a basic level but also needs further verification.

// to calibrate your sensor, put a glass over it, the sensor should not be touching desktop surface however.
// adjust the zeroWindAdjustment until your sensor really reads about zero at zero wind. 

const float zeroWindAdjustment =  .2; // negative numbers yield smaller wind speeds and vice versa.

Here are the links to the wind sensor in the shop and calibration sketch again:

By Paul Badger on March 6, 2014.

Debian on the HP 110-210


We have a GNU/Linux box in the corner at Modern Device, it’s
an HP Pavilion 7955, an ancient machine, and it runs a suite of
bash scripts which set fuses and flash firmware using
avrdude and open terminals using screen. It has streamlined
the testing process for many of our products. It has also held up
for about a couple years since its conversion from Windows XP.

On Wednesday, we came in to Modern Device to find it refusing to boot
(kernel panicking), complaining about ext4 issues. We figured its drive
had died after all these years, we’d just boot into GNU/Linux from
another device, copy over the production scripts, drop in a
new machine, install Debian, and be ready to
go. A process which an optimistic person might assume would take
around half an hour, and I figured it might take around three.

Initial hangups

Things were, of course, not that easy. The Pavilion would not
boot from USB, so Paul went to Staples and bought some CD-Rs.
While he was there he picked up the the lowest cost box in sight,
an HP 210-110 for $300, slated as the replacement
for our now-dead production Debian box.
We soon learned that the DVD-ROM drive didn’t support CDs, and
the CD drive was broken. Paul ducked into the next room and
returned with an ancient eMachine, running windows XP.

At this point I hoped beyond hope that the HP 210-110
would be both new enough to boot off USB, but old enough to support IDE.
No such luck; it’s a netbook in a bulky case.

I’d rather not touch Windows XP, so I tried to boot the eMachine off USB–
which didn’t work either. I tried instead booting off a CD, but it turns
out the eMachine’s single lite-on combo drive was also completely dead.

Data recovery

At this point we were saved by ext2fsd, a filesystem driver for Windows
capable of reading ext4 drives. Ext2fsd was written by someone whose
idea of a Windows installer is a .bat script, which took me a little
while to figure out, but once I ran setup.bat in cmd, everything worked
fabulously– we installed the old HD in the eMachine and copied
the production scripts to a USB drive.

Installation on the new machine

The HP 110-210 doesn’t have onboard WiFi, so I shared the connection
from the nearby production Mac, which acted very well in its capacity
as a mentor for the confused fledgling reincarnation of the Debian machine.

At this point, I figured everything would be easy. A brand new $300
machine should be a breeze to throw Debian on, right? And we could
even get a Windows 8 refund, as we didn’t use it for anything.

With this misconception, I downloaded the Debian net install iso, copied
it to a flash drive from Mac OS:

diskutil list # Figure out which disk is the flash drive, in our case, disk3
dd if=debian-7.4.0-amd64-netinst.iso of=/dev/rdisk3 bs=1m # OSX uses lowercase m

Disabling secure boot

Modern machines come with a piece of software which sits on top of BIOS
called UEFI (now usually shortened to EFI) which prevents GNU/Linux
installation by default. To disable it on the HP 110:

  • Mash the F10 key until you get into the BIOS
  • Go into the Secure Boot menu (Security -> Secure Boot Configuration)
  • Turn off Secure Boot and Fast Boot
  • leave Legacy Support off, or Debian may install without UEFI support

The solution

We left the Debian installer running all night, came in the next morning,
and it still wouldn’t boot. I tried rEFInd, gummiboot, elilo, and almost
tried to install boot-repair (not yet in Debian). At this point I
had almost given up on Debian. I downloaded Ubuntu 12.04 LTS, but it
complained that it wanted a missing rtl8105e file, proprietary RealTek firmware.
HP was really scraping the floor for hardware on this one.
I figured I’d give Debian one last shot and found the solution in a post by
Rod Smith, author of rEFInd, on the Ubuntu forum:
how work around HP’s UEFI misimplementation.

HP’s EFI wants your grubx64.efi file to be called /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi.

mkdir /boot/efi/EFI/Microsoft/Boot/ # Debian overwrites this, back it up if it's still there
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

Finally, GRUB appeared! After that, a blank screen, but that was solved by
replacing ‘quiet’ with ‘nomodeset’ in the GRUB configuration (/boot/grub/grub.cfg)

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset radeon.modeset=0"

(the Radeon line is to prevent a problem with the Catalyst driver later.)

X didn’t start, so we install the latest AMD Catalyst driver.
(you can’t just grab it with wget– AMD uses Javascript to force you
to download it on a computer with a graphical web browser, defeating
the point entirely. Well played, AMD. Hopefully someday someone will
make a real driver for these cards.)

mount /dev/sdb1 /mnt/sd
cd ~
cp amd-catalyst-13.12-linux-x86.x86_64.
unzip amd-catalyst-13.12-linux-x86.x86_64.
chmod +x amd-catalyst-13.12-linux-x86.x86_64.run 
apt-get install linux-headers-`uname -r` build-essential
aticonfig --initial
nano /etc/default/grub

Shame on Microsoft for Secure Boot, HP for enabling it and misconfiguring
their UEFI, and RealTek and AMD for their proprietary firmware drivers.

It took a day or two, and it was painful, but we circumvented all of the obstacles,
thanks in very large part to Debian, the Ubuntu forum, and people willing to
write filesystem drivers for Windows. Too many hours later, had a Debian login
and took at victory lap. We tried to get a refund on the
vaporized Windows software, but that looks fairly unlikely after reading through
Microsoft’s policy concerning OEM refunds on Windows. We called HP and
they claim the software is “bundled”– an antitrust violation, but we don’t have
time to fight them on it.

We also hope this helps a person or two through the minefield on a way to a generic
Linux Box.

Author: Noah Bedford

Date: 2014-03-06 16:13:06 EST

HTML generated by org-mode 6.33x in emacs 23

By Noah on March 6, 2014.

Wind Sensor Progress

After way too long I finally got back to work on the Modern Device wind sensor data and calibration. I received some good news and some bad news for my efforts.

First lets review some of the problems. The Modern Device wind sensor works on heat, similar but not the same as, a hot wire anemometer. A thermistor is heated and maintained at a temperature 50 degrees C above ambient by an op amp control loop. When the wind blows, it cools off the sensor, which causes the sensor’s resistance to rise, which causes the voltage at the op amp output to rise. This raises the bridge voltage across the sensor, which in turn heats the sensor up more and lowers the voltage output from the op amp. To the sensor is in an equilibrium state whose voltage level depends on the wind speed.

So the voltage is related to the wind speed. But there are problems.

    The voltage is related to the square root (or some arbitrary root) of the wind speed, so it has a power relationship, not a linear one.
      Since the thermistor is maintained at a constant temperature, cold air, which cools the sensor faster, results in higher voltages than warm air. This can be compensated for in a number of ways, however the most simple method is just to determine the zero wind voltage at a particular temperature and subtract the zero wind voltage from the sensor reading. So it’s all done in software.


    The voltage at zero wind is not zero – after all the sensor has to heat the thermistor up above ambient to be able to measure the wind. So the relationship is a little more complicated. One way to state the relationship is that the sensed voltage minus the zero wind voltage is proportional to some root of wind speed.

I’ll get to more detail on the math and some charts later but first let me say that I needed to have the measurements of the temperature sensor at zero wind over a variety of temperatures. I had been working with the wind tunnel which has a heater to control temperature. The problem is that there really isn’t a way to maintain temperature with zero wind speed in the wind tunnel. After all, some airflow would be required to provide the correct temperature air to the sensor. The heater especially doesn’t like low air-flow, as one might imagine.

After thinking about this for a bit, the answer which occurred to me was deceptively simple. If I sealed the sensor up in a box with a temperature sensor and some freezer bags, I could just let the box get warmer, or colder, I could record zero wind values as the sensor passed temperature thresholds. Below are some images of my fairly jury rigged apparatus, which I affectionately named the coldbox. The box could look a lot more professional, but I figured zero wind was zero wind. The cardboard box was taped shut and the sensors were enclosed in another inverted box, to keep the box’s convection currents off the sensor. The final shot has some styrofoam packing material taped to it, for insulation.

Sensors on Crossbar



The box was filled up with cold packs and allowed to cool off, then data was gathered as the box slowly warmed up either naturally or from the heater. Once the box was at room temperature – which has been averaging about 63 F in my office !?, I switched on the heater and let the box warm up, with the cold packs slowing things down with some thermal inertia. In any case, I performed the experiment a couple of times and the data tracked very closely each time. For a temperature sensor I used the temp421 sensor which we sell. The sensor is sensitive to 1/16th of a degree C and absolutely accurate to about 1 degree C.

The data I wished to gather were just two voltages. The voltage of the sensor at zero wind, and the voltage of the wind sensor’s thermistor output. Both of the these were gathered correlated with the temperature, over a wide temperature range. My coldbox data looked like this:

Screen shot 2014-03-05 at 5.16.42 PM

There were two sensors in the box so I have t1 & w1 for temp and wind from the first sensor and t2 & w2 for the second sensor. One thing you’ll notice right away is that the t1 & t2 (the thermistors on the wind sensors) track each other tighter than w1 & w2 do. This was a small revelation, but made perfect sense in that the temp thermistor is a 1% part, but I can only buy the wind-sensing thermistor with a tolerance of 3%.

Once I had the coldbox data (which covered the hot end of the range too), it was a pretty simple matter to let Excel chart the data. Then I just added trend lines and checked the “print formula” box and Excel dutifully spit out very nice equations for the correlations. I went for a second order polynomial trendline, and also printed the R^2 value, which ranges from 0.0 to 1.00, and gives one an idea about how well the polynomial fits. You can see by the number (.99977) that the fit is excellent.

Screen shot 2014-03-05 at 5.26.10 PM

I had never used these trendline features in Excel so it was lots of fun. I felt like Excel did all the drudge work for me and I just got to happily use the results. I also plotted the thermistor value against the zero wind values so it would be easy to generate the zero wind value from the thermistor values.

Screen shot 2014-03-05 at 5.43.09 PM


Again Excel just spit out the equation and I inputted it directly into an Arduino sketch. I’ll leave the rest of the math and the regressions for tomorrow’s post.

I will say that gathering data is a good way to characterize your hardware, and the sensor-to-sensor wind-speed differences we were seeing in individual wind sensor units was slightly disturbing to us. As an immediate fix, we priced out .1% resistors (we had been using 1% tolerance). Thanks to modern laser trimming the resistors turned out to be fairly affordable and available in the same footprint sizes as our current design. Surprisingly though, I couldn’t purchase a 1 ohm .1% resistor though in the size I needed so the value had to change to 2.21 ohms and another bridge resistor had to change ratiometrically.

Tomorrow – Fun with Regressions

For those of you who wish to get your hands on the Arduino calibration sketch, I uploaded it to our Github repository: https://github.com/moderndevice/Wind_Sensor.

The sensor is in the shop http://moderndevice.com/product/wind-sensor/


By Paul Badger on March 5, 2014.

Thumb Lites


A salesman sent me some samples of these little LED lights. I stuck one on my keys about a month ago and it’s still kicking.

There is always virtue in a product that only does one thing well. These mini flashlights are perfect for car keys or house keys. If you are unlucky enough to own a car old enough not to have a radio fob, these lights are amazingly effective and handy. They only do one thing very, very well, and they can save you from having to dig out that $400 flashlight otherwise called a smart phone.

I have had this one riding around on my somewhat battered car key, for about a month. I was pleasantly surprised that it hasn’t fallen off in that time, so the self adhesive glue seems quite aggressive. It also hasn’t gone dead from brushing against other things in my pocket. The battery is replaceable by just removing the one screw that is visible in the photo. It also has not called any of my friends at awkward hours in the evening.

Here’s a summary of the features as I see them:

  • Inexpensive.
  • Made of metal.
  • Replaceable battery with easy access.
  • Aggressive self adhesive pad on rear sticks to keys.
  • Switch is hard enough to prevent accidental activation.
  • Preempts having to dig out expensive smart phone “flashlight”.
  • Great gifts for geeks and civilians alike.

I’m giving away 15 of them with orders (you have to buy something else) with discount code “ThumbLite”.
In the shop here.

By Paul Badger on October 17, 2013.