New Top

All Products By Category

Archive | April, 2014

Modern Device’s Shipping Policy

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

Our Goal: Same- or Next-Day Service

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

Exceptions (The Fine Print)

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

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

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

Educato!

educato_1500px

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

RevEBreadboard800.jpg

 

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.

educato_breadboard

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.

 

More Eagle Tools – The normalize-text ULP

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

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

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

Screen shot 2014-04-18 at 12.29.02 PM

 

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

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

Screen shot 2014-04-18 at 12.32.11 PM

 

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

Screen shot 2014-04-18 at 1.01.03 PM

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

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

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

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

 

Screen shot 2014-04-18 at 12.54.38 PM

 

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

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

Paul

 

 

 

 

 

 

 

 

 

 

 

 

 

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.