Fail of the Week: ESP8266 Heats Temperature Sensor

[Richard Hawthorn] sent us in this interesting fail, complete with an attempted (and yet failed) clever solution. We love learning through other people’s mistakes, so we’re passing it on to you.

First the obvious-in-retrospect fail. [Richard] built a board with a temperature sensor and an ESP8266 module to report the temperature to the Interwebs. If you’ve ever put your finger on an ESP8266 module when it’s really working, you’ll know what went wrong here: the ESP8266 heated up the board and gave a high reading on the temperature sensor.

temp2Next came the clever bit. [Richard] put cutouts into the board to hopefully stop the flow of heat from the ESP8266 module to the temperature sensor. Again, he found that the board heats up by around four degrees Celcius or nine degrees Farenheit. That’s a horrible result in any units.

What to do? [Richard’s] first ideas are to keep hammering on the thermal isolation, by maybe redoing the board again or adding a heatsink. Maybe a daughterboard for the thermal sensor? We can’t see the board design in enough detail, but we suspect that a flood ground plane may be partly to blame. Try running thin traces only to the temperature section?

[Richard]’s third suggestion is to put the ESP into sleep mode between updates to reduce waste heat and power consumption. He should be doing this anyway, in our opinion, and if it prevents scrapping the boards, so much the better. “Fix it in software!” is the hardware guy’s motto.

But we’ll put the question to you electronics-design backseat drivers loyal Hackaday readers. Have you ever noticed this effect with board-mounted temperature sensors? How did you / would you get around it?

2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which celebrates failure as a learning tool. Help keep the fun rolling by writing about your own failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail Of The Week: My 3D Printer Upgrade

After years of cutting my hands on the exposed threads of my Prusa Mendel i2, it was time for a long overdue upgrade. I didn’t want to just buy a new printer because it’s no fun. So, I decided to buy a new frame for my printer. I settled on the P3Steel, a laser cut steel version of the Prusa i3. It doesn’t suffer from the potential squaring problems of the vanilla i3 and the steel makes it less wobbly than the acrylic or wood framed printers of similar designs.

My trusty i2. Very sharp. It... uh.. grew organically.
My trusty i2. Very sharp. It… uh.. grew organically.

I expected a huge increase in reliability and print quality from my new frame. I wanted less time fiddling with it and more time printing. My biggest hope was that switching to the M5 threaded screw instead of the M8 the i2 used would boost my z-layer accuracy. I got my old printer working just long enough to print out the parts for my new one, and gleefully assembled my new printer.

I didn’t wait until all the electronics were nicely mounted. No. It was time. I fired it up. I was expecting the squarest, quietest, and most accurate print with breathtakingly aligned z-layers. I did not get any of that. There was a definite and visible ripple all along my print. My first inclination was that I was over-extruding. Certainly my shiny new mechanics could not be at fault. Plus, I built this printer, and I am a good printer builder who knows what he’s doing. Over-extruding looks very much like a problem with the Z-axis. So, I tuned my extrusion until it was perfect.

Continue reading “Fail Of The Week: My 3D Printer Upgrade”

Fail Of The Week: Don’t Tie Those Serial Lines High

Fail Of The Week is a long-running series here at Hackaday. Over the years we’ve been treated to a succession of entertaining, edifying, and sometimes downright sad cock-ups from many corners of the technological and maker world.

You might think that we Hackaday writers merely document the Fails of others, laughing at others’ misfortunes like that annoying kid at school. But no, we’re just as prone to failure as anyone else, and it is only fair that we eat our own dog food and tell the world about our ignominious disasters when they happen.

And so we come to my week. I had a test process to automate for my contract customer. A few outputs to drive some relays, a few inputs from buttons and microswitches. Reach for an Arduino Uno and a prototyping shield, divide the 14 digital I/O lines on the right into 7 outputs and 7 inputs. Route 7 to 13 into a ULN2003 to drive my relays, tie 0 to 6 high with a SIL resistor pack so I can trigger them with switches to ground. Job done, and indeed this is substantially the hardware the test rig ended up using.

So off to the Arduino IDE to write my sketch. No rocket science involved, a fairly simple set of inputs, outputs, and timers. Upload it to the Arduino, and the LED on pin 13 flashes as expected. Go for a well-deserved lunch as a successful and competent engineer who can whip up a test rig in no time.

Back at the bench refreshed by the finest British pub grub, I started up the PC, plugged the shield into the Arduino, and applied the power. My sketch worked. But wait! There’s a slight bug! Back to the IDE, change a line or two and upload the sketch.

And here comes my fail. The sketch wouldn’t upload, the IDE reported a COM port error. “Damn’ Windows 10 handling of USB serial ports”, I thought, as I’m not a habitual Windows user on my own machines. Then followed something I’ve not done for quite a while; diving into the Windows control panel to chase the problem. Because it had to be a Windows problem, right?

arduino-serial-pinsThe seasoned Arduinisti among you probably spotted my fail four paragraphs ago. We all know that pins 0 and 1 on an Arduino are shared with the serial port, but who gives it a second thought? I guess I’d always had the good fortune to drive those pins from lines which didn’t enforce a logic state, and had never ended up tying them high. Hold them to a logic 1, and the Arduino can’t do its serial thing so sketches stay firmly in the IDE.

I could have popped the shield off every time I wanted to upload a new sketch, but since in the event I didn’t need all those inputs I just lifted the links tying those pins high and shifted the other inputs up the line. And went home that evening a slightly less competent engineer whose ability to whip up a test rig in no time was a bit tarnished. Ho hum, at least the revised sketch worked and the test rig did its job exactly as it should.

So that’s my Fail Of The Week. What’s yours?

Header image:, CC-BY-ND via MarkusJenkins

2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which celebrates failure as a learning tool. Help keep the fun rolling by writing about your own failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail Of The Week: Always Check The Fuse

[Tomas] at Umeå Hackerspace in Sweden had some broken audio equipment, including a Sharp CD player/amplifier. What went wrong when he tried to fix it is a fail story from which we can all learn.

The device worked – for about a second after being turned on, before turning itself off. That’s a hopeful sign, time to start debugging. He took the small-signal and logic boards out of the circuit, leaving only power supply and amplifier, and applied the juice.

Magic blue smoke ensued, coming from the amplifier. Lacking a suitable replacement part, that was it for the Sharp.

On closer inspection it emerged that the previous owner had bypassed the power supply fuse with a piece of copper wire, Evidently they had found the fuse to be blowing too often and instead of trying to fix the problem simply shot the messenger.

We have all probably done it at some time or other. In the absence of a replacement fuse we may have guestimated the number of single strands required to take the current, or used a thin strip of foil wrapped around the fuse body. And we’ll all have laughed at that meme about using a spanner or a live round as a fuse.

So if there’s a moral to this story, it’s to always assume that everyone else is as capable as you are of doing such a dodgy fix, and to always check the fuse.

2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which celebrates failure as a learning tool. Help keep the fun rolling by writing about your own failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail of the Week: Battery Pack Jack Wired Backwards

Last Saturday I had a team of teenage hackers over to build Arduino line-following robots from a kit. Everything went well with the mechanical assembly and putting all the wires on the correct pins. The first test was to check that the motors were moving in the proper direction. I’d written an Arduino program to test this. The first boy’s robot worked fine except for swapping one set of motor leads. That was anticipated because you cannot be totally sure ahead of time which way the motors are going to run.

The motor’s on the second robot didn’t turn at all. As I checked the wiring I smelled the dreaded hot electronics smell but I didn’t see any smoke. I quickly pulled the battery jack from the Arduino and – WOW! – the wires were hot. That didn’t bode well. I checked and the batteries were in the right way. A comparison with another pack showed the wires going into the pack were positioned properly. I plugged in another pack but the motors still didn’t run.

I got my multimeter, checked the voltage on the jack, and it was -5.97 V from center connector to the barrel. The other pack read 6.2 V. I had a spare board and pack so swapped those and the robot worked fine. Clearly the reverse polarity had zapped the motor control ICs. After that everyone had a good time running the robots on a course I’d laid out and went home pleased with their robots.

After they left I used the ohmmeter to check the battery pack and found the wiring was backwards, as you can see in the feature photo. A close inspection showed the wire with a white line, typically indicating positive, indeed went to the positive battery terminal. I shaved the barrel connector down to the wires and the white line wire was connected to the outside of the barrel. FAIL!

This is a particularly bad fail on the part of the battery pack supplier because how hard is it to mess up two wires? You can’t really fault the robot kit vendor because who would expect a battery pack to be bad? The vendor is sending me a new battery pack and board so I’m satisfied. Why did I have an extra board and pack, actually an entire kit? For this exact reason; something was bound to go wrong. Although what I had imagined was for one of the students to break a mechanical part or change wiring and zap something. Instead, we were faced with a self-destructing kit. Prudence paid off.

Fail of the week : Watt a loss

This one is a bit dated, but the lessons are still relevant. [Zach Hoeken] posted about the challenges he faced building a CNC stepper driver. He was experimenting with Toshiba motor drivers back in 2012.

The modular motor driver boards he built were based on the THB6064AH – capable of 1/64th step, and 4.5 Amps at up to 50V. [Zach] built a test jig to run the boards through their paces. A couple of messed tracks was the least of his problems – easily fixed by cutting traces and using jumper wires to correct the errors. But the header footprints for the motor drive boards got reversed. The only way out was to solder the headers on the back side.

LESSON : Always check footprint orientation and pin numbering before sending boards to fab.

The surprising part was when someone as experienced as [Zach] messed up on Ohms Law. Based on the current he wanted the motors to run at, his sense resistors needed to be 3.2W, but he’d used SMD footprints (0805 likely) instead. Those tiny resistors couldn’t be used at all, and the 5W resistors plonked on looked like an ugly hack.

Continue reading “Fail of the week : Watt a loss”

Fail of the Week: Not All Mold Releases Release All Molds.

I’m writing a series of articles on resin casting as an extension to my experiences with the instructions found in the wonderful Guerrilla Guide. However, mistakes were made. Having run out of my usual mold release I went to a back-up jar that was lying around from a casting project long, long ago in a workshop far, far away.

Never much for readin’ the nutrition facts myself.

I’m refining a technique of making a mold the quick and dirty way. Everything was going well, the sprues looked good and the master released from the silicone. It was time to do the second half of the mold. As usual I applied a generous amount of mold release. Since it was the first time this mold was to be used I went ahead and did all the proper steps. Rubbing off the dried release and applying a few more coats just to be sure.

I was completely unaware that I was applying mold release designed for urethane molds only. In other words I thoroughly covered my silicone mold in silicone bonding agents. I remained unaware until trying to separate the halves of the mold and found them thoroughly joined. After going through the stages of grief I finally figured out where it all went wrong.

Oh well. I’m ordering some of my regular pick, Stoner A324, and that should do the trick. There’s also Mann- Ease Release 200. While having probably the best name a release agent can have, it doesn’t work as well and needs approximately 100 years to dry. After this setback I’d rather just, grudgingly, learn my lesson and order the correct thing.

I wonder if the smooth-on description can say URETHANE RUBBER a few more times.
Oh. Yes I see. Urethane… Urethane…

So now that we know the right way to fix this is to order the right product, is there a hack to get around it? Does anyone have a homebrew trick for release agent that can be used in a pinch? Leave your comments below.