Ask an electrical engineer.

Questions people ask about electrical engineering, explained in detail.

[askanelectricalengineer]

Can a servo move smoothly?

Adapted from this thread

Part 1: Can a servo move smoothly?

Not easily, but you may be able to by writing and tuning your motion control code such that the jitter is less noticeable.

The way I would go about doing this would be to try moving at a constant velocity by commanding smaller, more consistent changes at a constant interval (i.e. every 50 ms, move no more than 5 degrees). Smoother input in should result in better performance out.

The real answer is a lot gnarlier. The fact that the Tessel, through an asynchronous, garbage-collected event loop, is commanding an off-board chip, which is in turn commanding the servo, which has its own internal control loop whose dynamics are unknown means that getting the servo to dance elegantly is actually a really, really hard controls problem.

The long string of intermediaries between your code and the motion of the motor add latency, but the biggest obstacle to smooth motion is probably the servo itself.

High end 3D printers and whatnot use stepper motors, encoders, and timing belts or ball screws to precisely control position in a quantized manner. With sufficiently frequent updates (on the order of hundreds or more per second), velocity control falls out naturally, which results in motion that can very accurately approximate curves.

Hobby servos, on the other hand, try to update their position ~50 times per second by following logic that looks something like this:

var target = this.readMyTarget(); setInterval(function () { target = this.readMyTarget(); }, 20); var go = function () { if (this.readMyPosition() < target) { this.moveForward(); } else { this.moveBackward(); } setImmediate(function () { go(); }); }

Although this^ is a somewhat harsh simplification, the take-home points are that 20ms is kind of slow and that "move [direction]" will vary widely from servo to servo (whereas a stepper with 0.5 degree steps could presumably be kept within 0.25 degrees of its target position at all times).

The biggest hurdle, though, is the fact that the servo's internal control loop (the specifics of what "move" means to that particular servo) is unknown and has no knowledge of what is attached to the servo's horn (the moment of inertia of the load, specifically). This will have enormous implications for how the servo accelerates and decelerates (will it wobble as it fights the angular momentum the pen gathered as it accelerated the pen toward the target position?), which will manifest themselves in how much overshoot your pen exhibits.

Part 2: How do we command servos and what does it mean for motion control?

Relevant factors:

You update the commanded positions sent to the Servo Module as often as you like (limitation = JS execution speed)

The Servo Module updates the command it sends to the servos themselves at 50Hz

The specified min and max duty cycle fed to servo.configure

The fact that the IC on the Servo Module uses 12-bit counters

The most important thing here is ultimately that the counters inside the IC on the Servo module used to trigger the rising and falling edges of the pulses are 12-bit and that the servo "protocol" maps pulses between ~0.5ms and ~1.5ms long that come every 20ms (at 50Hz) to target positions.

I put "protocol" in quotes because the standard is flexible but imprecise; we found our servos like pulses between 0.5ms and 1.2ms long, while some prefer 1 and 2. What ends up being important is not the absolute duration of the pulses, but rather the difference between the longest and shortest valid ones.

The timing resolution of the servo module works out to be 20ms*1/2^12 = 20ms/4096 = 4.88us. This means that narrowing your min/max duty cycle boundaries buys you mental clarity, but not positional resolution. The fact that you're coercing a float into a 12-bit number wins out in the end, to the tune of ~205 "valid positions" within any given 1ms window.

Sadly, this means that the smaller you make the window, the fewer specific positions you get to specify. We round/coerce internally to the nearest valid one.

Part 3: Next steps

The code you have there is great for finding the limits of your servo's motion, but it's not great for motion planning.

In order to implement the controller I proposed way at the beginning of this essay, you'll want to make an array of evenly spaced target positions and feed them into a carefully timed loop to update the servo's position. Play with the spacing of the positions as well as the time between updates, but don't bother trying too hard to line up with the 50Hz interval on the module itself.

[askanelectricalengineer]

How to use a stepper motor

Adapted from this thread

You will likely use something like this (assuming your motor is bipolar).

Related wiring diagram:

Connection checklist (hardware-agnostic)

You'll need to power the logic for the driver chip (use 3.3V from Tessel; don't pick a part that can't do 3.3V IO) as well as the separate power for the motor itself (voltage depends on the motor, but you will need external power of some kind). Make sure the grounds are common.

The control signals for stepper motor controllers are typically DIR (sets the step direction) and STEP (steps the motor in the set direction on each rising edge) which can both be done via GPIO on Tessel. Note that some controllers will increment in microsteps of some kind.

Never leave reset, enable, sleep, mode select, etc. lines unattended. Connect them to a GPIO or just to 3.3V/GND as appropriate.

Bipolar stepper motors (the most common kind these days) have two or more coils, each with two wires (green and yellow in the diagram above) that must be wired to the controller in a consistent manner. Consult your motor's datasheet for proper wiring, but the punchline is "line up A and B/+ and - for each coil".

Decoupling your power supply (as shown in the diagram) is always a good idea.

Further notes:

On the mentioned chip, you can leave M1,M2, & M3 not connected and you'll just get a full "step". They have internal pulldown resistors according to the A4988's datasheet, so they will be low unless driven or pulled high by some outside signal such as a GPIO or the power rail. According to that table (and Table 1 in the datasheet), this sets the controller up for full-stepping.

You will need to connect the RST to the SLP to enable the board. The rule of thumb here is "never leave an input floating" (the M# lines have internal pull resistors, so even if they're unconnected, they're not floating). If I were you, I'd tie the two together as Pololu suggests so that the pull resistor on one helps pull the other pin high too. One step better would be to also connect them to GPIO on Tessel. If you also tied them together (in the interest of keeping the total GPIO per motor controller to 3 so that it fits into a module port), you'd then use that pin to reset the device and forgo the ability to put the thing into sleep mode. That said, I doubt either one will be used too often.

For pulse generation:

Pulses are just what we EEs call it when a signal goes from one state to another and back again in a relatively short amount of time. Pulses can either be high or low and are named for the state in which they spend the least amount time (low-high-low = a high pulse). They are also classified by their width, measured in [SI prefix goes here]seconds.

This controller will act on high pulses that are longer than and separated by more than one microsecond, as specified in Figure 1 in the datasheet (page 6). The rest of Figure 1 tells you not to change the state of DIR or the microstep control lines within 200 nanoseconds of the rising edge of said step pulse.

...so you'll need to set the STEP GPIO high then low again (which should be set as its default state) pretty much back to back. A very short setTimeout in between couldn't hurt.

[askanelectricalengineer]

How do you use a relay?

Question from salim_alzhrani, answer adapted from this post

Think of the relay module as a pair of on/off switches that need to be placed inline with devices. It does not supply power, so you still need to provide power to the lamp.

Here's how you want to hook it up:

Unplug everything. Never work on live circuits.

If the lamp is powered from a wall outlet (AC voltage), cut the hot wire (the one connected to the smaller of the two prongs in a polarized, US-style plug), which should have black insulation in a properly constructed cable. The image below is an extension cord that has been properly "prepared".

If the lamp is powered off a battery or other source of DC power, cut the wire on the high side/positive terminal of the battery.

Insert both ends of the cut wire into one of the relay connectors (not one hole, one connector). Make sure that no stray wires are outside the connector.

In order to secure the wires, grab a ball point pen (or similar) and push down on the small indentations on the connectors to open up the contacts. Push the conductor all the way into the receptacle, then release pressure on the connector.

Give both wires a tug to make sure they're secure (the last thing you want is an exposed live wire flopping around). You can wrap the module in electrical tape if you want to be extra safe, too.

Plug the cable into the wall/power source. If nothing turns on or smokes, good. If it does, unplug it, assess the damage, and try again after testing the bare module (nothing plugged in, still "clicks"). Either way, unplug the cable from the wall/power source when you're done.

If you're using Tessel's Relay module: Plug the module into Tessel, then plug the cord back into the wall/power source.

Run your code!

[askanelectricalengineer]

Power Work is Never Over

Originally posted on the Technical Machine blog here

12/9/2013— Eric Kolker

We get a lot of questions over email, so today my goal is to answer the question we get asked most frequently: how much power does the Tessel use?

More specifically, the question usually takes the form of:

“Hey, guys, just saw Tessel the other day and it looks sweet! I want to use it to build a [ six word description of the project ]! How much power will it use?”

At which point half of me jumps for joy (cold calls about using Tessel are always appreciated) and half of me rolls up my sleeves. A complete answer touches on power consumption vs. current draw, the role USB can play, and things to be conscious of when designing a Tessellation.

Power vs. Current

As it turns out, power consumption is difficult to calculate, and often people actually care more about current draw. In our case, the two are closely related:

P = IV

The electric power used by a circuit at steady state is equal to the current flowing through the circuit multipled by the voltage across it.

Although most devices are in truth limited by power consumption (rather than current output), it’s good practice to never draw more than a power supply’s rated current. On a good day, an overloaded supply will simply sag its voltage (brown itself out) until P=IV, but on a bad day it could become unstable and damage components connected to it. In order to avoid either scenario, most computers will cut power to a USB port if it draws more than 500 mA (2.5 W of power).

In a world ruled by USB...

Because the Tessel is most commonly powered off its USB connection, it turns out that current draw is usually the more important number to keep track of. As such, the data points I rattle off quickly are as follows:

A bare Tessel, that is, one without any modules attached, draws about 110 mA of quiescent current .

We ran a test with a 3.7 V, 350 mAh LiPo battery where the Tessel pinged Tim’s laptop once per second and the device ran for almost exactly two hours.

The next information I offer is that use of the onboard WiFi radio, flash, and RAM can draw additional currents of 275 mA, 175 mA, and 100 mA, respectively. The astute mathematician will note that 110 + 250 + 175 + 100 > 500, which suggests that the Tessel should constantly be browning itself out and rebooting.

Although it is probably possible for the Tessel to do that to itself, the reality is that those current draw numbers, like many others, represent the peak draw of the chips in question, as opposed to average continuous draw. This suggests that:

The chips usually draw much less current than that (low quiescent current).

When the chips do draw that much, they do so for a very short period of time (high peak current).

Therefore, it’s very unlikely that the Tessel will do that to itself (we’ve never had it happen to us and triggering such event would likely require that high power WiFi transmission and complete wipes of both the flash and RAM happened exactly simultaneously).

Bypass capacitors on the power rail are really important! They help keep the 3.3 V and 5 V rails at their respective values, instead of sagging miserably during bursts of high current draw.

When you think about it, all of these make sense: the WiFi radio is only going to use a lot of power when it’s transmitting or working to decode an incoming packet and the memory will need the most power during read/write operations, both of which shouldn’t be happening all of the time (there’s a difference between “every time” and “continuously”). Last but not least, always decouple your rails!

Plan accordingly

But I digress… Allow me to explain why I often need to take a minute to collect my thoughts before typing up a reply.

In order to estimate of power consumption, you need to know what goes into your device and how you plan to use each part. Here are a few key things you’ll want to figure out:

What modules do you plan to use?

All of the modules are marked with their peak current draw, but the notion that “they don’t really draw that much” rule doesn’t always apply.

Sensor modules (ambient, accelerometer, climate, GPS, camera) tend to use the same amount of current all the time.

The nRF and BLE modules (low power wireless communication) use a modest amount of power over a short amount of time to transmit packets and little power for the rest of the time.

The GPRS module follows a similar pattern, but draws a truly exorbitant amount of current during transmission and has a higher quiescent current.

Because RFID must generate an RF field in order to read tags, it has a relatively high quiescent current. Consumption during transmission is even higher.

The relays we chose latch (save their state), so they only draw current when their state is switched, but don’t provide power to whatever they’re hooked up to. On a related note, please be very careful when dealing with wall power. Unplug everything before inserting anything into the relay module and wrap things up with electrical tape when you’re done.

Servos connected to the servo module are powered externally, so their power draw is not included in the peak power consumption for the module.

NOTE: Although most hobby servos can be powered off 5 V, we strongly recommend against powering them off the Tessel’s 5 V rail (more on this 5 V rail later). The inductive kick from the motors could brown out or permanently destroy the Tessel. The module ships with a 5 V power adaptor for the servos. Please use it.

Does your project have any moving parts?

This is typically only an issue if you have a relay or servo module onboard, but if it’s an issue it will likely be a serious one. I already mentioned the dangers of inductive kick, and it’s worth noting that a standard hobby servo will stall out (maximum torque = maximum current draw here) at upwards of 1 A. If you know you need a motor of some kind, do some research to figure out what kind of motor makes sense based on what you need to move, how quickly you need it to move, and how accurately you need it to move. A good rule of thumb from the field of robotics is that actuators use an order of magnitude (or three) more power than anything else in the system, so plan accordingly.

Plan ahead

Figure out how often everything will be on vs. in standby. See if you can predict how often you’ll need to communicate with the web, and if that will require a long series of back and forths or a simple handshake. Is a live stream of data necessary all the time, or just occasional polling? Can you offload heavy processing or JSON parsing to a back end somewhere?

Finally, before you go spend hundreds of dollars on parts, I’ll remind you to start small and to iterate. If you’re new to hardware, keep in mind that things break and don’t always work the first time, so leave room in your budget for spares, replacements, upgrades, and jumper wires (somehow, they always seem to wander off).

Using the 5 V in pins

Another thing to consider is where the power physically enters the Tessel. The Tessel can be powered either from the micro USB port, or through a pair of 5 V in pins right near it.

Either way, the absolute maximum voltage those pins can accept before you destroy your Tessel is 5.5 V (I only mention this because officially the party line is 5 V, but some phone chargers output 5.1 V and I’d like to let you all know that using such an adapter will not trigger the apocalypse).

The Tessel will use USB power preferentially over the power supplied to the 5 V in pins . This is likely only relevant if you will need a USB data connection to the device some, but not all of the time, and therefore cannot devote the USB port to power alone.

Circuitry onboard the Tessel allows seamless switching between power sources.

Last but not least (and sometimes very important), the external power that goes into the 5 V in pins is whatever you put there. That is, if you attach a 3.7 V LiPo, don’t expect to get 5V out (we’re good, but not that good). The only place on the board which exposes the 5 V rail (be it from the USB port or the 5 V in pins) is on the GPIO bank.

In closing

The more you know about your design the easier it will be to estimate power consumption. My offhand guess for most Tesselations is that a 1A cell phone wall charger will be enough, and it’s not worth your time to worry about it any further. If you can’t afford to be tied down to a wall socket, grab a battery above 5,000 mAh and you should be able to run all day so long as you don’t have any moving parts, try to stream YouTube, or calculate the millionth digit of pi. If you have anything more complicated than that, or just want someone to bounce an idea off of, drop me a line to ask questions.

~e

[email protected]

[askanelectricalengineer]

Inside Eric’s Toolbox: an Electrical Engineering Kit

Originally posted on the Technical Machine blog here

11/21/2013— Eric Kolker

In engineering we talk a lot about tools. Some people have a favorite collection of software, some a metaphorical belt filled with tips, tricks, and techniques, and others a literal box or lab bench filled with instruments. In my experience, a good engineer not only maintains all three, but seeks to expand his or her collection and share it with peers on a daily basis.

Today I’d like to share what I keep in my literal toolbox and provide some commentary and backstory for the tools I carry with me. Expect some tangents and links to more Wikipedia pages, too.

Figure 1: The box. Starts closed, gets opened, returns to closed configuration for transport.

Boxception

Unpacking from the top down, the first thing out is a smaller box.

Figure 2: box of hand tools, closed

The box contains the things I use most often: a plethora of small hand tools. In it I somehow manage to stash:

Wire strippers

Needle-nose pliers

Hemostats

A spool of 30-gauge wire

A spool of solder wick

A spool of solder

A loupe

Three sets of tweezers (yes, I use them all)

Four dental picks (ditto)

An assortment of connectors in various states of dismemberment

Some small plastic bags

A few scraps of wire, heat shrink, and other miscellaneous parts

Figure 3: box of hand tools, open

Big things with two handles

Figure 4: Left to right: wire strippers, needle nose pliers, and hemostats

The wire strippers I use for, well, stripping the insulation off of copper wire. I use them only and exclusively on copper because otherwise I would risk plastically deforming the tool and ruining it. Side note: I used the word "maintain" earlier not only imply that you should keep a kit of tools, but also to hint that good tools warrant, and often require, good care. But I digress: never use wire cutters or wire strippers on anything other than hookup wire. Headers, nails (tack, finger, or toe, it makes no difference), small steel shafts, etc. are not to be cut with my tools.

Needle-nose pliers are great for pretty much everything. I like these in particular because they have good grips (compliant but not too soft and not the kind that dry your hands out or cause blisters), close evenly, and are lightly textured at the ends. They’re also a good size.

Hemostats (point of interest: they’re supposed to be used to clamp arteries during open heart surgery) are a new addition to the box, and are useful because they ratchet shut and don’t let go. I often use them to hold things in place or grab onto tiny wire when I strip it.

Things directly related to soldering

Figure 5: Left to right: 30 gauge wire, solder wick, solder, and a loupe

This tiny spool of tinier wire is what lets me hack boards with surface mount (SMT) parts. Thirty gauge (technically 30 AWG) is small enough that I can attach it to a tiny pad, but big enough that it can actually be manipulated without a microscope. This particular spool is insulated with plastic (as opposed to enamel-coated magnet wire which is a royal pain to strip), so I can run it all over the board without worrying about shorting things out, but strip off the insulation easily (with heat, even, if need be).

Solder wick, sometimes called solder/copper braid, is used to desolder (mop up solder) by following these easy steps:

Place wick on affected area

Place soldering iron on wick (on affected area)

Wait until solder in affected area becomes molten (you’ll see smoke rise when the wick’s rosin flux melts)

Mop up molten metal

Remove tools from affected area

Feel like a boss because your ugly solder job is gone

Up close, this stuff is a flat, woven strap made of tiny copper wires. It comes in different thicknesses, but I generally like think stuff so I can be precise with my solder removal.

Not all solder is created equal. There are a myriad of different blends of tin and lead (and others), flux and no flux, fat and skinny, etc. My preferred blend is 63/37 (%tin, %lead by weight, which is the eutectic ratio for the metals, and corresponds to the lowest melting temperature for the alloy), rosin core, and super thin. It’s one step below good solder paste for precise SMT work.

The loupe is effectively a magnifying glass that sits in your eye socket. I first ran into these guys when I took a photography class (we used ‘em to look at negatives before making prints). If you don’t have a microscope and need to make sure a board looks good (all the solder joints are nicely connected, components are properly seated, etc.), you’ll want one of these and a good flashlight to see what’s up.

Tweezers

(aka “small things with a debatable number of handles”)

Figure 6: Tweezers!

Each pair of tweezers is so important that it deserves its own paragraph. Left to right:

These babies are my go-to. They have a long pointed tip, are acid resistant and anti-magnetic, are lightweight, and have a very abrupt taper at the end. The last two characteristics are especially important when I use them under a microscope because they help me know exactly where my fingers are on the tool at all times.

These next guys are called “reverse action tweezers” because when you pinch they open up, rather than close down. These aren’t super useful for surface mount work because they’re so big, but are great for holding “normal” size wire (~24 AWG) or through-hole components in place when I solder.

The last pair of tweezers is probably the most expensive tool in my box that doesn’t use electricity. They’re made of stainless steel, are corrosion resistant, anti-magnetic, and are designed specifically for SMT soldering (and surely give +5 Dexterity). The shape of the tines lets me apply pressure to chips evenly along the sides (crucial for precise placement) without hitting other components on the board (essential for densely-packed boards). When you turn them sideways (so the tines are vertical), you can grab the chip perpendicularly to the board and still see everything in the microscope.

Dental picks

Figure 7: Dental picks

Unlike the tweezers, these dental picks are all pretty much the same (sorry to disappoint). Some have pointier ends or are better shaped for some specific task, but all are used for some combination of scraping, pushing, or cleaning boards or chips. Because they have all come into contact with lead, I can no longer recommend that they be used to clean teeth.

Miscellaneous smallbox-dwellers

Figure 8: Miscellaneous occupants of my meta-toolbox

This is an odd assortment of stuff. Left to right, top to bottom we have a (probably broken) RFID IC, the cover for one of my super swank multimeter probes (read on!), SMA connectors, two small plastic bags, heat shrink, and some black wires (for ground, should I need ‘em).

SMA connectors are industry standard RF (radio frequency) connectors. They belong to a family of connectors called “coaxial”, whose name comes from the arrangement of the inner and outer conductors (the latter, a ring in cross-section, should always be used for ground). I keep these particular connectors around because 1) connectors in general are expensive (these were maybe $3 each, but some are truly pricey) and 2) because they have been modified (read: I broke off some pieces off of each one) so they’re easy to attach to boards quickly for the purpose of testing something.

Scopes and meters

A tiny oscilloscope

Figure 9: DSO Nano with probes plugged in and the box it comes in

One holds a DSO Nano, which is a pocket-sized oscilloscope/function generator made by Seeed Studio. As far as scopes go it's certainly a budget model, but when you need a scope you need a scope, regardless of how small. I use it when I'm in a pinch, am too lazy to walk to the lab, or have simply run out of channels on a larger and less portable scope. It's also nice to have on hand because it's battery powered, and therefore it floats (in the electrical sense, that is: it has no connection to Earth ground, which could get you into nasty trouble when dealing with things that plug into the wall). ##Multimeters and probes

Figure 10: multimeters and probes.

My old, crappy multimeter and the thoroughly destroyed probes it came with, the probes for a new multimeter, and the new multimeter with my fancy probes. The old meter still mostly works, so I keep it around. The new one is honestly untested, as are the probes it came with, but the probes installed in it are the best. Their tips are spring loaded (called “pogo pins” in the art), interchangeable, stupid sharp, and gold-plated, which make them good for getting a reliable connection on tiny surface mount parts. They even have their own datasheet! The downside is that, as probes go, they have a super high resistance (maybe 0.6 Ohms or so).

Tape

Figure 11: Tape!

I carry Kapton, Crapton, and electrical tapes.

Kapton is great: it’s corrosion-resistant, has excellent thermal properties, is a fantastic insulator, stays sticky even when abused, and is rated by its thickness, so even mechanical engineers appreciate it. It’s a little pricey, though. I use it to cover up wire hacks (when I use that blue wire) and strain-relieve wires I’ve soldered onto a board temporarily for testing.

Crapton is fake kapton. It’s still an insulator (read: when something has been taped up, it can no longer be poked), but I don’t trust it on the other counts. Buyer beware: a lot of the cheap kapton on Amazon is really crapton, which is how I wound up with this roll.

Electrical tape is, well, nonconductive. More often than not, I use the stuff to secure boards to the lab bench when I’m soldering them. Electrical tape is good for that because it ‘s a little stretchy, so I can keep the tape under tension to make sure the board doesn’t slide around.

Soldering paraphernalia

Figure 12: An itty-bitty soldering iron and some syringe tips/needles.

At 12 Watts, this iron is truly puny (even the inexpensive industrial grade ones are usually 60 W, and they do as high as 240 W before you start to get to plumbing gear); you can’t beat the portability. The needles go on the ends of syringes of solder paste, which are stored in a refrigerator (we probably confused some people at Highland this summer…).

The needles allow you to apply paste super precisely to the tiny pads of obnoxious SMT chips, but they often clog, so it’s good to keep extras on hand.

Miscellaneous debugging tools

Figure 13: Assorted jumper wires, a big electrolytic capacitor, a bag of grippy things, a binder clip, a ruler, and a Bus Pirate.

Jumper wires are just generally good to have around when debugging

Same goes for a decently sized capacitor. This particular capacitor (220 microfarads, 50V, aluminum electrolytic) helped me debug Tessel’s power input circuitry.

The grippy things are like small versions of those robot hands they sell at science museums, but for circuits; they’re used to grab onto unsuspecting wires, pins, or leads so that you can measure the voltage there. Lots of different tools come with these kinds of things, but these particular ones are made by Tektronix (one of the big test equipment manufacturers, and a company known for its analog oscilloscopes) and are designed to be used on SMT parts. In short, they’re the best grippy things I’ve come across with their long, skinny necks and super strong grip. There’s a reason I have so many of them.

Binder clips hold stuff, keep bags closed to keep moisture-sensitive parts dry, etc.

This ruler is open source! No, really. It also happens to have metric/imperial conversion charts, PCB spacing guidelines, hole sizes, and a whole slew of other useful information.

The Bus Pirate (and cable assembly) is a piece of OSHW that’s essentially the Rosetta Stone for communication with embedded devices. You tell it what you want to say and what protocol to use and it translates. Works with OSX and Linux and is available from Dangerous Prototypes (the creators) through Seeed Studio and SparkFun.

Knife

Figure 14: Cardsharp, aka TSA bait

This knife usually lives in my pocket, but bears mention because I truly bring it almost everywhere. The blade is good (medical-grade stainless which I keep sharp), but the handle is a little weird when you unfold it.

Cables and boards

USB Cables

Figure 15: USB cables

I have a bunch of USB cables. The ones in this picture are A to B and A to micro, and I use them to talk to an Arduino Uno and Tessels, respectively. The two in the little box are the same kind that our Beta backers get (whoo colors!).

Arduinos and Tessel modules

Figure 16: a handful of modules and an esoteric Arduino

Tessel modules (RFID, Ambient, and GPS), an Arduino Pro Mini, and an FTDI USB to serial adapter + mini USB cable. This particular Arduino is great because, unlike the Uno and the Mega (which I have but don’t always carry with me), it’s a 3.3V device (so’s the Tessel). I use it to test and debug modules without worrying about breaking the module with a 5V signal. The downside to the device is that it needs the external USB to serial adapter in order to be programmed.

Tessel (of course)

Figure 17: my Tessel

Last but not least, my Tessel (and yet another micro USB cable). This particular board has been hacked so that it uses an external antenna, and I’ve been using it to test the range at which Tessels can connect to WiFi. Perhaps “hacked” is a strong word: the current version of the board has the footprint for an MMCX connector (the smallest, most robust RF connector I know of) on it so that it’s easy to swap to a more sensitive antenna. Here I’ve attached an MMCX to SMA adapter from SparkFun to connect to a 2.4 GHz WiFi antenna.

...And that just about does it. The old school EE in me feels compelled to also mention the concept of a good lab notebook (there are actually some interesting legal reasons here) in which you date every page and write only in pen...and that I almost always use a fountain pen. The rest of me would like to remind our readers that I am not, in fact, an old man.

~e [email protected]

P.S. Even though studies overwhelmingly show that learning by doing is the best way to retain information, good whitepapers and lectures still have their place. Here’s a link to my personal stash of application notes and reference guides from a few of the big players in the electrical engineering space. The trove grows with time, and grows fastest when I’m building exciting new things. Enjoy!

[askanelectricalengineer]

Hardware is *different*

6/5/2014– Eric Kolker

Originally posted on the Technical Machine blog here

You hear the phrase “hardware is hard” a lot these days, usually when someone is new to hardware, and often in the context of what it takes to build it. Without forcing words into peoples’ mouths, the speaker is generally trying to convey the sense that building hardware feels more difficult than building other things because there’s so much to keep track of and think about.

As someone who designs hardware but is joining the world of software, I have some problems with this shorthand dismissal and what it implies. I’m also making a conscious point of saying this just as the first Tessels are hitting your mailboxes and as some of you are getting your first taste of hardware.

“Hardware is hard”

No, it isn’t. Really. If anything, software is just incredibly easy. However, because many people who started off in software are now interested in hardware (hopefully you!), it behooves us all to try to understand what they’ve gotten themselves into and how it’s different from what they’re used to.

Allow me to back up, explain, and then offer some advice before we all leap headfirst into the world of hardware.

Context

My background is in electrical engineering. In previous lives, I built and programmed robots small and large – everything from LEGO MindStorms to Boston Dynamics' LS3, which, at the time, was arguably the most advanced quadruped robot in the world. I've designed large portions of a small satellite, an ultra-high bandwidth, medical-grade wireless data link for CT scanners, and my own integrated circuit. I'm used to, and indeed completely comfortable with, creating entire systems which work correctly the first time, due in large part to careful architecting, simulation, and a firm grasp of innards of every would-be black box and pitfall in the system. I’m accustomed to spending enough time planning that the implementation goes off largely without a hitch, which is typically the expectation for electrical engineers.

All that goes to say that hardware engineers must be considerably more careful about the work they do than web developers because the costs of a second chance are so much higher. Case in point: I have never met an EE who would even entertain the notion of "FISI" because doing so is unforgivably irresponsible and expensive on so many levels.

Don’t get me wrong, there are certainly programmers who are more risk-averse than I and whose systems cannot afford to fail. My point is just that many web developers have luxuries which allow them to be a little more cavalier than hardware engineers can typically afford to be. In the end, these luxuries allow for the buildup of bad habits for dealing with hardware.

What’s actually different?

Hardware and software happen at different speeds and require different skill sets. In a nutshell, hardware requires more caution, attention to detail, patience, and knowledge of a broader range of topics than software because most of the time, the building blocks are, admittedly, harder to assemble. The black boxes in hardware are less ideal than those you encounter in software because they exist physically in the real world (as opposed to merely as instances of ideas), and are therefore more sensitive to their neighbors.

A few choice examples come to mind:

Things cost more money and time. Supply chains, fabrication time, shipping, and calibration all have very different definitions and consequences for hardware. Missteps as a result of any of these can destroy companies alltogether.

More fundamentally and ironically, because computers start off as electrical systems, each of their operations happen on electrical timescales (the timescales of chemical reactions and light), while electrical systems begin their lives as mechanical systems, which necessarily move much more slowly.

In hardware, debugging is not as easy as console.log. Instead, it often requires additional equipment that can cost thousands of dollars and takes time to set up, adjust, and calibrate. Fractions of a millimeter and millionths of a second matter, often tremendously; sometimes electrical systems are so sensitive that measuring the system will change the way that it behaves.

On top of all that, a thorough grasp of the system’s physics is often tremendously important, if not essential, to understanding its subtleties (read: pitfalls, failure modes, etc.). This may sound weird, but the simple fact that modern computers are treated as discrete and digital devices with well-defined interfaces is simultaneously one of their most valuable traits and largest liabilities. Because software typically assumes that we can draw hard lines that place things firmly in one of two states, we rarely account for the fact that physical systems are actually analog and asynchronous. These assumptions are therefore implicitly built upon approximations rather than absolutes. ...And without getting too meta, the crux of the issue is that problems typically arise due to the approximations we make at the intersections between digital and analog.

So what?

We've done our best with Tessel to make sure that you don’t need to do or worry too much about any of the really nasty hardware bits, but you'll still need to come the last 10%. Understand that the consequences are more real than they are with software if you don't read the documentation and/or do something careless with the product.

Think about what you want to build, understand your system’s requirements, and set specifications that are both physically possible and sensible. Do research into what goes into anything you build, and ask lots of questions on the forums. I promise we’ll do our best to answer them.

Last but not least, come to terms with the cost of developing embedded systems in JS: performance. Fundamentally, you’re working with an interpreted language (JS) that has been transpiled to another (Lua), which is being interpreted by something other than V8, which is running on a 180 MHz processor. Tessel is certainly no iPhone, but we’re confident that it’s more powerful and more versatile than similar products which run JS because it’s node-compatible and doesn’t need a lifeline to the PC. You’ll be fine so long as you don’t try to stream video, run intensive algorithms, load 14 different node modules, or demand that your loops run at 100Hz.

Call to action

...So what I ask of you is actually pretty simple. Appreciate that Tessel has been about a year in the making and that in order to use it properly you may need to learn a little bit about what goes on under the hood. Together we can make hardware prototyping easier, but doing so will require that we do more than admire electrical systems when they walk by (guilty parties typically include “LED all the things!” and “OMG quadcopters!”). Read our documentation before you run into trouble, then look up anything that continues to misbehave.

Once your projects take you to the edge of what our modules can do, I hope you'll take the plunge and try your hand at building hardware, and in doing so start to see why the people on my side of the table have the habits we do.

Most importantly, I hope you learn a lot and have a lot of fun, so get out there and start building!

Thanks! ~e