# Rev P Wind Sensor Data

The Modern Device wind tunnel outfitted with a pitot tube and temperature sensor.

We wanted some more “objective” methods to confirm the numbers on our growing collection of anemometers, so we naturally thought about pitot tubes. This is the way that aircraft tell their airspeed. I don’t know how much they get used anymore, but the great virtue of a pitot tube is that it can be entirely mechanical, although that would of course depend on the gauge that is used to translate the pitot tube’s pressure into a number.

The pitot tube actually has two connections. The “high side” connection is exposed to the oncoming air and generates a positive pressure. The “ambient” connection, takes into account any static pressure in the system. The two lines are then read differentially, similar to a differential connections for an op-amp, so that that the output is the high side pressure minus the ambient pressure.

Isn’t this a wonderful looking set of gauges? These are called “Magnehelic” by Dwyer instruments. They are totally analog (although an electronic one is on top) and are hooked up to the pitot tube with small rubber tubes.

Here is some raw data from the Rev P Wind Sensor at 4 different temperature points.

It would be very nice if static pressure was just proportional to wind speed, but few things in life or in physics are so simple. The pressure generated is dependent on the density of the air, which makes sense if you think about it. The density in turn, is dependent on barometric pressure, temperature and humidity.

Here’s a graph that shows the temperature dependency.

So I implemented the math to correct for temperature and barometric pressure. One little hiccup was that “Absolute Temperature” was denominated in the little-used Rankine scale (F + 460). Once I entered the correct values for temperature, some wind speeds that looked very plausible came out the other end of my Excel spreadsheet, whose chart looks like this:

A couple of conclusions that I’m drawing is that at lower air speeds, the ambient correction circuit in the Rev P wind sensor is doing an admirable job, for some reason at higher wind speeds there is still some correlation between output and ambient temperature. It’s curious that the higher temperatures are reporting greater output, because normally one thinks of it taking more energy to get cold air up to temperature.

My current focus is on the ambient temperature correction circuit. The thermistor doing ambient correction is a 10k which is not by my choice. I would have desired a much higher value, but 10K was the highest value available in the thermistor line that I am using. The 10K thermistor dissipates about 3mW which is enough to raise its temperature almost 1 degree K, according to the datasheet. (Datasheet is 4mW/K). This would tend to be velocity sensitive also as at higher wind speeds the self-heating would be swamped by the power of the wind speed to enforce the ambient temperature. It’s just a hypothesis at this point.

Another hypothesis is that the “active” (heated) thermistor and the ambient sensor, just don’t track each other perfectly, leading to some variation over temperature. Indeed I would be shocked if there was no variation over temperature. I can cure the self-heating problem fairly easily, but only a lookup table will compensate for the variation in sensor response over temp, and that is the direction in which we are heading.

The new wind sensors are in the shop here: http://moderndevice.com/product/wind-sensor-rev-p/

By Paul Badger on June 26, 2014.

# New Rev P Wind Sensors

In addition to working on our wind tunnel, we’ve been developing new wind sensor designs. Rev P is not a new version of our rev C wind sensors that we have made for several years. It might have been better with a new name, and may eventually get one, but for now it’s “Rev P”.  “P” stands for PTC or Positive Temperature Coefficient thermistors. The difference between NTC and PTC is as follows: NTC thermistors have smaller resistance as they get hotter, where as PTC thermistors exhibit a larger resistance when they get hotter.

Why new thermistors? The PTC thermistors track each other more closely, and the ambient temp thermistor in the new design actually is part of the Wheatstone bridge, instead of just sensing ambient temperature, as in the Rev C sensor. The part is also available in a higher precision (1%) than the 3% thermistors in the Wind C sensors. The rev P thermistors are supposed to be more stable than the parts in the Rev C, with excellent values for maintaining their values after a year of being heated.

As you can see, the potentiometer has gone away, and the only wind speed output is the voltage output of the wind speed sensor. We have also added a real temp sensor, that is not dependent on the supply voltage. Everything would be great in wind sensor land IF I could buy PTC thermistors in the values I want. The chip I’m using only seems to be available in 100 ohms, which ends up being around 120 ohms by the time it gets up to working temperature. Consequently, to get enough power to heat the chip up, it requires a higher voltage than the Wind C sensor, which is slightly inconvenient. Right now the sensor requires 8 volts, which probably means a readily available 9 volt supply. We will bring out the next version very quickly that will have a boost regulator so that the sensor will run well from five volts.

Current draw is around 40 mA but this goes up at higher wind speeds, which one would expect, since it requires more power to keep the sensor hot at higher wind speeds.

Another feature of the sensor that we have been experimenting with is the non-standard mounting of the chip, with no pcb behind it. This goes a long way toward making the sensor omnidirectional. The chips are only coated on one side so there is still some built-in asymmetry in the sensor’s directional response that probably can’t be compensated out, without using two sensors. We’ll also get that characterized next week.

We’re still gathering data in the wind tunnel on this beauty and should have curves (at least from 25 to 40 degrees) and an Arduino sketch early next week. They’re already in production and in stock.

The new wind sensors are in the shop here: http://moderndevice.com/product/wind-sensor-rev-p/

By Paul Badger on June 6, 2014.

# The Modern Device Current Sensor at 3.3 Volts

When we designed the current sensor we noticed that the hall effect sensors were rated only for a 5 volt supply in the datasheet, so we didn’t know what kind of performance we would get, if any, with a 3.3 volt supply voltage. So while we were doing the calibration research, we gathered some data at 3.3 volts. We didn’t plug in as many different loads as  with the 5 volt sensor but as you can see from the graph below, the output is very linear, once you get past the very low power “hook” on the left end of the curve, which is due to the “noise floor” from the amplified sensors.

So the good news is that the Current Sensor will work fine on a JeeNode or other 3.3 volt microcontroller. One caveat is that the sensor’s saturation point (maximum reportable value) is also a bit smaller than the 3.3 volts supply,  because the output is governed by the topology of the op-amp peak detector.

The peak detector works with diode D1. The op amp IC1D cannot produce a voltage higher than 3.3 volt supply voltage so the maximum value for the peak detector output at IC1C (pin 8) is going to be 3.3 volts minus the voltage from the diode drop, which in this case is about .2 volts because we used a special schottky diode to try to minimize the diode losses.

Paul

By Jeffrey Blum on May 7, 2014.

# Current Sensor – A Quick Calibration Method

Our last post concerned the Current Sensor and how to calibrate it to measure the amount of power being drawn through an AC line. That process involved gathering data and plugging it into a spreadsheet program, validated the sensor and showed that the voltage output of the sensor was very proportional to the power draw in the wire it was sensing. It occurred to us that if the output is linear, then only two points are really required to define a straight line. Thus, it would be fairly easy to develop a quick (but perhaps a bit less accurate) calibration by entering only two data points total.

So we developed a second current sensor program, shown below. To make this one work, all you need is two appliances with different power draws, ideally one around 20 to 200 watts and the other closer to 1000 watts. Measure the voltage generated by the current sensor for those two loads individually then substitute your data points in for V1, P1, V2, and P2, and you are done. The sensor is calibrated. As long as it doesn’t get bumped on its line cord, it should maintain very faithful calibration.

The one caveat is that you should make sure that the sensor is not saturating (hitting its maximum) on your higher current draw, so make sure the output voltage is under 4.3 volts (if powered from 5 volts). The analogous value (highest voltage without saturation) when powering from 3.3 volts is 2.6 volts.

That’s it! The program takes care of finding the equation for you really quickly at the expense of only using two data points, which means less accuracy. But as I said earlier, that might just be enough for you. Enjoy!

```/*
Reads a Modern Device Current Sensor on pin 0, converts it to voltage,
calculates the power, and prints the result to the serial monitor.
Attach the V_OUT pin of the Current Sensor to pin A0, and V_IN and GND
to +5V and ground respectively.

This example code is in the public domain.
*/

//You'll have your own values for these constants

#define V1 0.577  // voltage of first data point
#define P1 225    // power of first data point
#define V2 2.91   // voltage of second data point
#define P2 1000   // power of second data point
float SLOPE;
float Y_AXIS_CROSS ;

void setup() {
//Find SLOPE and Y_AXIS_CROSS for quick calibration
SLOPE = (P2 - P1) / (V2 - V1);
Y_AXIS_CROSS = P1 - V1 * SLOPE;
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
// Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
float voltage = sensorValue * (5.0 / 1023.0);
//Calculates power from voltage
float power = voltage * SLOPE + Y_AXIS_CROSS;
// print out the value you calculated:
Serial.println(power);
}
```
By Jeffrey Blum on May 5, 2014.

# Calibrating the Modern Device Current Sensor

Modern Device sells a handy Current Sensor that can measure the amount of AC current flowing through a cord attached to it with the miniature zip ties we include with the sensors. While the sensor has an analog output and is extremely easy to use to check if an appliance is ON or OFF, we thought we would both validate the sensor and write a tutorial to allow users to put some hard numbers to the analog output. This would allow users to confirm the actual amount of power being drawn by a device.

A Brief Bit of Math
The chips on our sensor actually measure the amount of current flowing through the wire, which is why it’s called a Current Sensor (technically though they measure the magnetic field that is created by the current flowing in the wire, but the magnetic field is also proportional to current).

Luckily there’s an easy formula that equates power (P) to current (I) multiplied by voltage (V). Furthermore, we know that the voltage coming from the wall is constant (around 120 in the United States and 230 in the EU), which makes power proportional to current. In other words,

P = V * I, therefore P  is proportional to I (current) for constant V (voltage)

Perhaps to make things more confusing, the output of the sensor is itself a voltage, although it represents (is proportional to) the sampled current.

Got it? Good, moving on.

The Setup
A standard power strip is a convenient way to test and calibrate the Current Sensor. To start, make sure there are no active loads attached to the power strip (you might as well unplug everything from the power strip, just in case). To set up the test, attach the Current Sensor to the surge protector’s cord as shown above and tighten the zip ties snugly (the sensor should not be able to rotate around the cord unless you physically touch it). For our test, we also set the gain potentiometer on the sensor to its lowest possible setting (all the way counter-clockwise). Connect VIN and GND on the Current Sensor to +5V and GND respectively on an Arduino (we used one of our 3-wire cables as a connector). Finally, attach a voltmeter to the VOUT pin on the Current Sensor and another GND pin on your Arduino. Even though nothing’s plugged in, you should still see some small voltage. This is noise from the sensor, because the sensor is so highly amplified. This low voltage represents the noise floor or the zero current level of the sensor.

Arduino Leonardo, Multimeter, and a surge protector with loads

Now plug in a medium level load (anything between 100 and 400 watts will do) so you get an actual reading. If the voltage doesn’t increase, check your connections and power supply. If you rotate the sensor around the cord, you’ll notice that the voltage changes as the angle of the sensor on the cord changes. If you are more concerned with sensing small to medium loads – say 5 to 600 watts – you will probably wish to set the sensor angle to its most sensitive angle (highest voltage) so the sensor is more sensitive to smaller changes in current.

If you expect to be sensing large loads – we’re talking 600 to 1500 watts or higher – you may wish to use a sensor angle corresponding to a lower voltage so the sensor will not saturate (hit its maximum value – which is around 4.4 volts)  before you reach the maximum desired load to sense. In this case, you may wish to plug in your maximum load now, and rotate the sensor until you observe an output value somewhat below 4.4 volts.

Note the angle of the current sensor relative to the cord

Gathering Data
Once you have decided on a sensor angle, it’s time to collect data. You’ll need a few loads with known power ratings that span the range of power you expect to encounter. Look on the labels of the appliances your are using; in the United States, appliances are required to have their power draw printed on the label. For our test, we used the following loads (you don’t really need this many):

Lamp 18
Lamp 43
Lamp 100
Heat Lamp 125

Our motley crew of loads, three lamps (different bulbs), heat lamp, and the radiator we used to calibrate our current sensor.

Start gathering data by recording the voltage level with no loads at all. Then, record the voltage when each individual load is turned ON by itself. If you want more data, try measuring the voltage when different combinations of loads are turned on (the power ratings simply add together). We took a variety of measurements to prove our point in this tutorial; you should only need 5 or 10 total. That said, the more data you collect, the more accurate your calibration will be. There is an assumption in this that the nameplate ratings of the loads that you test are also fairly accurate.

Be careful NOT to move the current sensor during this step or your measurements will be off.

Finding the Formula
The next step is to enter the data into a spreadsheet program as shown below. We used LibreOffice, which is open source and free, feel free to use Excel, if you own the program and like it better.

A portion of the data we gathered while calibrating our current sensor

Now create a Scatter chart from your data. If you don’t know how to do this, search Google for the instructions; it’s only a couple of mouse clicks. Right click on the data points in the chart (make sure they’re all selected; not just one) and select “Insert Trend Line…” on the drop down menu. A dialog box like the one below will pop up, and under “Type” you should select “Linear” (the exact process might be a bit different for different programs). You should also check the boxes next to “Show equation” and “Show coefficient of determination (R2)”. The R2 value is a statistical measurement of how close an approximation comes to matching the data its approximating. For our purposes, the closer it is to 1, the better the trend line fits the data.

After clicking “OK”, your chart should look something like the one below but without the axis labels (added for clarity). As you can see, our trend line has an R2 value of 0.998, which tells us that the output of the sensor is definitely linearly proportional to the current, and by extension, power.

A graph showing the relationship between voltage and power draw for our current sensor

As cool as the chart is, what you’re really after is that formula, which describes how to take an input voltage and translate it into a measurement of power.

Creating the Arduino Sketch
Now that you have your equation, it’s time to put it to use. Luckily, there’s an example sketch called ReadAnalogValue (it’s under File -> Examples -> 01.Basics) that requires only minor modifications to work for the Current Sensor. The original sketch is as follows:

```/*
Reads an analog input on pin 0, converts it to voltage, and prints the result to the serial monitor.
Attach the center pin of a potentiometer to pin A0, and the outside pins to +5V and ground.

This example code is in the public domain.
*/

// the setup routine runs once when you press reset:
void setup() {
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
// Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
float voltage = sensorValue * (5.0 / 1023.0);
// print out the value you read:
Serial.println(voltage);
}```

All we need to do now is enter the formula that will convert the voltage variable into a power variable!

```/*
Reads a Modern Device Current Sensor on pin 0, converts it to voltage, calculates
the power, and prints the result to the serial monitor.
Attach the V_OUT pin of the Current Sensor to pin A0, and V_IN and GND to +5V and ground respectively.

This example code is in the public domain.
*/

// the setup routine runs once when you press reset:
void setup() {
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
// Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
float voltage = sensorValue * (5.0 / 1023.0);
//HERE'S THE ONE LINE OF CODE WE ADDED - your numbers will vary from ours!
float power = 326.348 * voltage + 26.461
// print out the value you calculated:
Serial.println(power); //Don't forget to change the variable name to "power"!
}```

Remember to change the variable name in that last line, otherwise your beautiful formula won’t actually report anything.

Congratulations! Your Current Sensor is now calibrated to measure power draw!

One last thing: now that your calibration is complete and seems to work for the power draws that you expect to see, you might want to lock the sensor to the cord with a spot of hot glue to keep it from rotating and changing your calibration.

Saturation Warning
If you wrote down the saturation voltage when you were testing, you may wish to add code to warn the user if the sensor is saturated (hit its maximum output), so the power draw is probably not proportional to the output voltage any more. Due to the topology of the sensor’s schematic, the sensor’s saturation point (max output) will be about a .6 volts (“a diode drop”) below the supply voltage. If you are using a 5 volt supply, inserting the line below should do the trick.

```float voltage = sensorValue * (5.0 / 1023.0); // this line in the code above
if (voltage &gt; 4.30) Serial.println("SATURATED");
```

The sensor is in the shop here: http://moderndevice.com/product/current-sensor/
Happy sensing and let us know if there is anything in the tutorial that needs to be clarified.

By Jeffrey Blum on May 2, 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.

# Educato!

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 Fransisco-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.

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:

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

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 an 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:

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.

Paul

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() {
Serial.begin(9600);

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

lcd.begin(screen_width, screen_height);

lcd.print("HUMIDITY STORAGE");
delay(2000);
lcd.clear();
rf12_initialize(20, RF12_915MHZ, 68);
}

void loop() {

int data[3];

lcd.setCursor(0,0);
lcd.print("HUMIDIY: ");
float h = humidity.GetHumidity();
lcd.print(h);
data[0] = (int)(h*100);

lcd.setCursor(0,1);
lcd.print("TmpC");
float t = humidity.GetTemperatureC();
lcd.print(t);
data[1] = (int)(t*100);

lcd.setCursor(9,1);
lcd.print(" F");
t = humidity.GetTemperatureF();
lcd.print(t);
data[2] = (int)(t*100);

while (!rf12_canSend())
rf12_recvDone();

rf12_sendStart(0, data, 6);

delay(1000);
}```

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() {
Serial.begin(57600);
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(buf[i]);
Serial.print(" ");
}
Serial.print("\n");
}
}```

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:

```#!/usr/bin/python
# 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

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
<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`

```cd ./humidity
chmod +x upload.py #make the python script executable

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.

```<html>
<!-- FONTS -->
<meta charset="UTF-8" />
<!-- 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(){
}
});
</script>
<body>
<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>

</body>
</html>```

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.

Stay tuned for more!

By Jeffrey Blum on April 2, 2014.