New Top

All Products By Category

Archive | March, 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.







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.

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

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:

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.

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)

(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.)

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

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:

The sensor is in the shop