What Could Go Wrong: SPI

July 1, 2016 by Elliot Williams 58 Comments

Serial Peripheral Interface (SPI) is not really a protocol, but more of a general idea. It’s the bare-minimum way to transfer a lot of data between two chips as quickly as possible, and for that reason alone, it’s one of my favorites. But that doesn’t mean that everything is hugs and daffodils. Even despite SPI’s simplicity, there are still a few ways that things can go wrong.

In the previous article in this series, inspired by actual reader questions, I looked into troubleshooting asynchronous serial connections. Now that you’ve got that working, it’s time to step up to debugging your SPI bus! After a brief overview of the system, we’ll get into how to diagnose SPI, and how to fix it.

Continue reading “What Could Go Wrong: SPI” →

Fail Of The Week (in 1996): The 7 Billion Dollar Overflow

June 30, 2016 by Gerrit Coetzee 50 Comments

The year was 1996, the European Space agency was poised for commercial supremacy in space. Their new Ariane 5 Rocket could launch two three-ton satellites into space. It had more power than anything that had come before.

The rocket rose up towards the heavens on a pillar of flame, carrying four very expensive and very uninsured satellites. Thirty-seven seconds later it self destructed. Seven billion dollars of RUD rained down on the local beaches near the Guiana Space Centre in ~~Southern~~ South America. A video of the failed launch is after the break.

The cause of all this was a single improper type cast in a bit of code that wasn’t even supposed to run during the actual launch. Talk about a fail.

There were two bits of code. One that measured the sideways velocity, and one that used it in the guidance system. The measurement side used a 64 bit variable, but the guidance side used a 16 bit variable. The code was borrowed from an earlier, slower rocket whose velocity would never grow large enough to exceed that 16 bits. The Ariane 5, however, could be described with a Daft Punk song, and quickly overflowed this value.

The code that caused the overflow was actually a bit of pre-launch software that aligned the rocket. It was supposed to be turned off before the rocket firing, but since the rocket launch got delayed so often, the engineers made it timeout 40 seconds into the launch so they didn’t have to keep restarting it.

The ESA never placed blame on a single contractor. The programmers had made assumptions. The engineers had made reasonable shortcuts to make their job easier. It had all made it through inspections, approvals, and finally the launch event.

They certainly learned from the event; the Ariane 5 rocket has flown 82 out of 86 missions successfully since then. It has at least five more launches contracted before it is retired in 2023 for the Ariane 6 rocket being developed now. This event also changed the way critical software and redundant systems were tested, bringing the dangers of code failure to the attention of the public for the first time.

If you want to read more, there is a great discussion on Reddit which tipped us off to this fail, a quite thorough Wikipedia article, and the original article that ran in the New York Times is mirrored here.

Continue reading “Fail Of The Week (in 1996): The 7 Billion Dollar Overflow” →

Tools Of The Trade – Inspection

June 29, 2016 by Bob Baddeley 15 Comments

In the last episode, we put our circuit boards through the reflow process. Unfortunately, it’s not 100% accurate, and there are often problems that can occur that need to be detected and fixed. That’s what the inspection step is for. One could insert an inspection step after paste, after placement, and after reflow, but the first two are icing on the cake — the phase where most mistakes can be caught is after reflow.

There are a number of problems typical with a surface mount reflow process: Continue reading “Tools Of The Trade – Inspection” →

Retrotechtacular: ASCII Art In The 19th Century

June 28, 2016 by Al Williams 43 Comments

Computer graphics have come a long way. Some video games today exceed what would have passed for stunning cinema animation only a few years ago. However, it hasn’t always been like this. One of the earliest forms of computer-generated graphics used text characters to draw on printers.

Early computer rooms were likely to have a Snoopy character on green and white fan-fold paper. Calendars with some artwork were also popular (see left, and find out about the FORTRAN that created it, if you like). Ham radio operators who use teletypes (RTTY, in ham parlance) often had vast collections of punched tape that held artwork. Given that most hams in the 1950s and 1960s were men and the times were different, a lot of them were more or less “R” rated.

Not all of them were, though. For example, Richard Nixon was decidedly “G” rated (see right). Simple pictures would use single characters, but sophisticated ones would use the backspace character to overprint multiple characters.

Ham Radio Art

You often hear this described as ASCII art, today, although hams usually use 5-bit BAUDOT code, so that’s a misnomer for those images, at least. Of course, today, people aren’t keen on storing roll after roll of paper tape (or even owning a tape reader) so there have been several projects to capture this art in a more modern format.

Although there is still some RTTY art activity, picture sending has been mostly replaced by slow scan TV (SSTV) which sends actual still images or other modes like FAX. Some of the newer digital modes even have the ability to send pictures. You can be discussing your radio for example, and then show the other ham a photo of the radio.

Continue reading “Retrotechtacular: ASCII Art In The 19th Century” →

Serially, Are You Syncing Or Asyncing?

June 28, 2016 by Rud Merriam 25 Comments

I know you’ve heard of both synchronous and asynchronous communications. But do you really know the differences between the two?

Serial communication was used long before computers existed. A predecessor is the telegraph system using Morse Code, one of the first digital modes of communication. Another predecessor is the teletype, which set standards that are still used today in your Arduino or Raspberry Pi.

All you need is two wires for serial communications, which makes it simple and relatively robust. One wire is ground and the other the signal. By interrupting the power with predefined patterns, information can be transferred over both short and long distances. The challenge is receiving the patterns correctly and quickly enough to be useful.

I was a bit surprised to find out the serial port on the Arduino Uno’s ATmega328P microcontroller is a Universal Synchronous Asynchronous Transmitter Receiver (USART). I’d assumed it was only a UART (same name, just leave out synchronous) probably because my first work with serial communications was with the venerable Intel 8251 “Programmable Communication Interface”, a UART, and I didn’t expect the microcontroller to be more advanced. Silly me. Later I worked with the Zilog 8530 Serial Controller Chip, a USART, the term I’ll use for both device types.

All these devices function in the same way. You send a byte by loading it into a register and it is shifted out one bit at a time on the transmit (TX) line as pulses. The receiver accepts the pulses on a receive (RX) input and shifts them into a register, which is then read by the system. The transmitter’s job is pretty easy it just shifts out the bits at a known clock rate. The receiver’s task is more complex because it needs to know when to sample the incoming signal. How it does this is the difference between asynchronous and synchronous communications.

Continue reading “Serially, Are You Syncing Or Asyncing?” →

Taking Killer Robots Seriously

June 27, 2016 by Elliot Williams 61 Comments

Killer robots are a mainstay of science fiction. But unlike teleportation and flying cars, they are something that we are likely to see within our lifetime. The only thing that’s stopping countries like the USA, South Korea, the UK, or France from deploying autonomous killing machine in the very near term is that they’re likely to be illegal under current international humanitarian law (IHL) — the rules of war.

But if you just sighed in relief that the fate of humanity is safe, think again. The reason that autonomous killing machines are illegal is essentially a technicality, and worse, it’s a technicality that’s based on the current state of technology. The short version of the story, as it stands right now, is that the only thing making autonomous robotic killing weapons illegal is that it’s difficult for a robot to tell a friend from an enemy. When technology catches up with human judgement, all bets are off.

Think I’m insane? The United Nations Office at Geneva (UNOG), the folks who bring you the rules of warfare, started up a working group on killer robots three years ago, and the report from their 2016 meeting just came out. Now’s as good a time as any to start taking killer robots seriously.

Continue reading “Taking Killer Robots Seriously” →

Hackaday Links: June 26, 2016

June 26, 2016 by Brian Benchoff 40 Comments

Solar Freaking Roadways. What is it? It’s technology that replaces all roadways with a smooth sheet of glass and solar panels. You know how asphalt is soooo easy to repair and soooooo cheap? Yes, this is the exact opposite of that. They’re coming to freaking Missouri. A parking lot for the Route 66 Welcome Center in Conway, MO will be paved with the solar freaking roadways that netted $2 Million in an Indiegogo campaign two years ago.

There is a National Potato Expo. As far as I can tell, this is a trade show for potatoes and potato-related paraphernalia. As with all trade shows you need a great demo, in this case one involving potatoes. How about a phone charging station powered by potatoes? It’s a bunch of potatoes, copper pipe, galvanized nails (neat design, btw), and a USB socket. Yes, it works, but not well.

The travelling hacker box is a USPS flat rate box filled to the brim with random bits and bobs of electronics, shipped back and forth between dozens of electron enthusiasts. It’s making one last trip around the US, and now the travelling hacker box needs destinations from Idaho to Michigan. Idaho, of course, is a fictional state created in 2004 for Napoleon Dynamite, but that still leaves Montana, the Dakotas, Wisconsin, Minnesota, and the UP. If you live in one of these states, there’s a travelling hacker box with your name on it. Request to join the project and PM me on hackaday.io.

It’s election year in the US, and that means half of the population hates one candidate, half of the population hates another candidate, and half of the population will vote. Don’t think about that for too long. Here’s an Arduino doing something topical with Twitter.

Hotends for 3D printers are getting more and more robust, but thermistors are fiddly little things. E3D just came up with the solution. It’s a standard, modular temperature ‘cartridge’ that fits in E3D’s heater blocks. You can already change out the heater cartridge on a 3D printer for a higher wattage model, and now you can change out a thermistor for a thermocouple just as easily. E3D sells their stuff in GBP, so considering recent events it might be a good time to pick up a new hotend for that Monoprice 3D printer you picked up

The 8-Bit Generation recently released their documentary The Commodore Wars, chronicling the stupendous rise and meteoric fall of Commodore. Now they’re working on the Atari version and they’re funding it with a Kickstarter. Rumor has it Hackaday’s own [Bil Herd] has been asked to narrate.

Here’s another Hackaday Retro Edition success story @KetturiFox pulled up the Hackaday Retro Edition on a Texas Instruments TravelMate 5000 laptop. That’s a relatively modern laptop with a 75MHz Pentium, PCMCIA slots, and a nub mouse.