Fail Of The Week: Always Check The Fuse

April 6, 2016 by Jenny List 72 Comments

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

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

Autonomous Tractor Brings In The Harvest

April 5, 2016 by Jenny List 53 Comments

[Matt Reimer] is a farmer in Southwestern Manitoba, Canada. It’s grain country, and at harvest time he has a problem. An essential task when harvesting is that of the grain cart driver, piloting a tractor and grain trailer that has to constantly do the round between unloading the combine harvester and depositing the grain in a truck. It’s a thankless, unrelenting, and repetitive task, and [Matt]’s problem is that labour is difficult to find when every other farmer in the region is also hiring.

His solution was to replace the driver with a set of Arduinos and a Pixhawk autopilot controlling the tractor’s cab actuators, and running ArduPilot, DroneKit, and his own Autonomous Grain Cart software. Since a modern tractor is effectively a fly-by-wire device this is not as annoying a task as it would have been with a tractor from several decades ago, or with a car. The resulting autonomous tractor picks up the grain from his combine, but he reminds us that for now it still deposits the harvest in the truck under human control. It is still a work-in-progress with only one harvest behind it, so this project is definitely one to watch over the next few months.

Writing from the point of view of someone who grew up on a farm and has done her share of harvest-time tractor driving it’s possible to see both the strengths and weaknesses of an autonomous grain cart. His fields on the Canadian prairie are very large and flat, there is plenty of space and the grain makes its way from the field to the elevator in a truck. To perform the same task in the smaller and irregular fields of southern England for example with a mile round trip down country lanes to the grain store would be a much greater challenge. Aside from that it’s worth noting that his John Deere is a 220hp 4WD workhorse that is capable of going over almost any terrain on a farm with very few obstacles able to stop it. This thing can do serious damage to life and property simply by running it over or driving straight through it, so safety has a dimension with an autonomous tractor in a way that it never will with for example a vacuum cleaner or even a lawnmower.

Those observations aside, this kind of technology undeniably represents a step change in farming practice on a par with the move from horse power to tractors in the first half of the last century. However the technological barriers that remain end up being solved, it’s likely that you’ll see plenty more machines like this in the fields of the future.

The video below the break shows the autonomous grain cart in action. Plenty of big-sky tractoring action, and for those of you unfamiliar with farming it should provide some understanding of the task of getting grain from combine to store.

We’ve talked about robotic farming more than once here at Hackaday. The gantry-based Farmbot, the six-legged Prospero robot farmer, or another hexapod confusingly also called Farmbot, for example. But these have all been hacker’s solutions to the problem using the concepts with which they are familiar. What makes [Matt]’s project different is that it is a farmer’s solution to a real farming problem by automating the machinery he already uses to do the job. Farmers have been doing what we would now call hacking at the hardware of their craft since time immemorial, [Matt]’s work is just the latest manifestation of a rich heritage.

Continue reading “Autonomous Tractor Brings In The Harvest” →

Facebook To Slurp Oculus Rift Users’ Every Move

April 4, 2016 by Jenny List 70 Comments

The web is abuzz with the news that the Facebook-owned Oculus Rift has buried in its terms of service a clause allowing the social media giant access to the “physical movements and dimensions” of its users. This is likely to be used for the purposes of directing advertising to those users and most importantly for the advertisers, measuring the degree of interaction between user and advert. It’s a dream come true for the advertising business, instead of relying on eye-tracking or other engagement studies on limited subsets of users they can take these metrics from their entire user base and hone their offering on an even more targeted basis for peak interaction to maximize their revenue.

Hardly a surprise you might say, given that Facebook is no stranger to criticism on privacy matters. It does however represent a hitherto unseen level of intrusion into a user’s personal space, even to guess the nature of their activities from their movements, and this opens up fresh potential for nefarious uses of the data.

Fortunately for us there is a choice even if our community doesn’t circumvent the data-slurping powers of their headsets; a rash of other virtual reality products are in the offing at the moment from Samsung, HTC, and Sony among others, and of course there is Google’s budget offering. Sadly though it is likely that privacy concerns will not touch the non-tech-savvy end-user, so competition alone will not stop the relentless desire from big business to get this close to you. Instead vigilance is the key, to spot such attempts when they make their way into the small print, and to shine a light on them even when the organisations in question would prefer that they remained incognito.

Oculus Rift development kit 2 image: By Ats Kurvet – Own work, CC BY-SA 4.0, via Wikimedia Commons.

My Most Obsolete Skill: Delta-Gun Convergence

April 4, 2016 by Jenny List 92 Comments

In a lifetime of working with electronics we see a lot of technologies arrive, become mighty, then disappear as though they had never been. The germanium transistor for instance, thermionic valves (“tubes”), helical-scan video tape, or the CRT display. Along the way we pick up a trove of general knowledge and special skills associated with working on the devices, which become redundant once the world has moved on, and are suitable only reminiscing about times gone by.

When I think about my now-redundant special skills, there is one that comes to the fore through both the complexity and skill required, and its complete irrelevance today. I’m talking about convergence of the delta-gun shadow mask colour CRTs that were the height of television technology until the 1970s, and which were still readily available for tinkering purposes by a teenager in the 1980s.
Continue reading “My Most Obsolete Skill: Delta-Gun Convergence” →

DVB-S From A Raspberry Pi With No Extra Hardware

April 3, 2016 by Jenny List 19 Comments

An exciting aspect of the trend in single board computers towards ever faster processors has been the clever use of their digital I/O with DSP software to synthesize complex signals in the analogue and RF domains that would previously have required specialist hardware. When we use a Raspberry Pi to poll a sensor or flash an LED it’s easy to forget just how much raw processing power we have at our fingertips.

One of the more recent seemingly impossible feats of signal synthesis on a Raspberry Pi comes from [Evariste Courjaud, F5OEO]. He’s created a DVB-S digital TV transmitter that produces a usable output direct from a GPIO pin, with none of the external modulators that were a feature of previous efforts required. (It is worth pointing out though that for legal transmission a filter would be necessary.)

DVB is a collection of digital TV standards used in most of the world except China and the Americas. DVB-S is the satellite version of DVB, and differs from its terrestrial counterpart in the modulation scheme it employs. [Evariste] is using it because it has found favor as a digital mode in amateur radio.

This isn’t the first piece of [F5OEO] software creating useful radio modes from a GPIO pin. He’s also generated SSB, AM, and SSTV from his Pi, something which a lot of us in the amateur radio community have found very useful indeed.

We’ve covered digital TV creation quite a few times in the past on these pages, from the first achievement using a PC VGA card almost a decade ago to more recent Raspberry Pi transmitters using a USB dongle and a home-built modulator on the GPIO pins. Clever signal trickery from digital I/O doesn’t stop there though, we recently featured an astoundingly clever wired Ethernet hack on an ESP8266, and we’ve seen several VHF NTSC transmitters on platforms ranging from the ESP to even an ATtiny85.

Thanks [SopaXorzTaker] for the nudge to finally feature this one.

Raspberry Pi As Speed Camera

April 3, 2016 by Jenny List 110 Comments

Wherever you stand on the topics of road safety and vehicle speed limits it’s probably fair to say that speed cameras are not a universally popular sight on our roads. If you want a heated argument in the pub, throw that one into the mix.

But what if you live in a suburban street used as a so-called “rat run” through route, with drivers regularly flouting the speed limit by a significant margin. Suddenly the issue becomes one of personal safety, and all those arguments from the pub mean very little.

[Gregtinkers]’ brother-in-law posted a message on Facebook outlining just that problem, and sadly the local police department lacked the resources to enforce the limit. This set [Gregtinkers] on a path to document the scale of the problem and lend justification to police action, which led him to use OpenCV and the Raspberry Pi camera to make his own speed camera.

The theory of operation is straightforward, the software tracks moving objects along the road in the camera’s field of view, times their traversal, and calculates the resulting speed. The area of the image containing the road is defined by a bounding box, to stop spurious readings from birds or neighbours straying into view.

He provides installation and dependency instructions and a run-down of the software’s operation in his blog post, and the software itself is available on his GitHub account.

We’ve had a lot of OpenCV-based projects but haven’t featured a speed camera before here on Hackaday. But we have had a couple of dubious countermeasures, like that humorous attempt at an SQL injection attack, or a flash-based countermeasure.

A Keypad Joypad For Your Retro Gaming

April 1, 2016 by Jenny List 15 Comments

[TK] is a retro computer enthusiast who’s had some difficulty locating a joystick for his trusty Amiga 500. New ‘sticks are expensive, and battered survivors from the 80s go for more than they should.

Happily these old controllers were simple devices, having only five control lines for the four directions and a fire button which were active low. [TK] therefore cast around the available components and decided to craft his own controller from a numerical keypad.

Numerical keypads may be ubiquitous, but they’re not the perfect choice for a joypad. Instead of individual switches, they are wired as a matrix. [TK]’s controller works within that constraint without butchering the keypad PCB, though his layout has the left and right buttons below the up and down buttons. Looking at the schematic we wonder whether the 4-5-6 and 7-8-9 rows could be transposed , though joypad layout is probably a matter of personal choice.

Making the controller was a simple case of wiring the pad to a 9-pin D socket in the correct order, and plugging it into the Commodore. He reports that it’s comfortable to use and better than some of the lower-quality joysticks that were on the market back in the day. Veterans of Amiga gaming will understand that sentiment, there were some truly shocking offerings to be had at the time.

Quite a few home-made game controllers have made it onto these pages over the years. There is this one using tactile switches and a ballpoint pen, and a stick made from the idler wheel from a surplus VCR, but the ultimate crown of junkbox joysticks should go to this joystick made from clothes pins. If we take one thing away from all this home-made controller ingenuity, it is that what really matters is not the hardware but the gameplay.