Quick Hack Cleans Data From Sump Pump

July 28, 2017 by Dan Maloney 11 Comments

Nobody likes to monitor things as much as a hacker, even mundane things like sump pumps. And hackers love clean data too, so when [Felix]’s sump pump water level data was made useless by a new pump controller, he just knew he had to hack the controller to clean up his data.

Monitoring a sump pump might seem extreme, but as a system that often protects against catastrophic damage, the responsible homeowner strives to take care of it. [Felix] goes a bit further than the average homeowner, though, with an ultrasonic sensor to continually measure the water level in the sump and alert him to pending catastrophes. Being a belt and suspenders kind of guy, he also added a float switch to control the pump, but found that the rapid cycle time made his measurements useless. Luckily the unit used a 555 timer to control the pump’s run time after triggering, so a simple calculation of the right RC values and a little solder job let him increase the on time of the pump. The result: a dry basement and clean data.

We recently discussed the evolution of home automation if you want to know more about the systems that sensors and actuators like these can be part of. Or for a more nuts and bolts guide to networking things together, our primer on MQTT might help.

Raiders Of The Lost OS: Reclaiming A Piece Of Polish IT History

March 3, 2017 by James Hobson 48 Comments

In today’s digital era, we almost take for granted that all our information is saved and backed up, be it on our local drives or in the cloud — whether automatically, manually, or via some other service. For information from decades past, that isn’t always the case, and recovery can be a dicey process. Despite the tricky challenges, the team at [Museo dell’Informatica Funzionante] and [mera400.pl], as well as researchers and scientists from various museums, institutions, and more all came together in the attempt to recover the Polish CROOK operating system believed to be stored on five magnetic tapes.

Originally stored at the Warsaw Museum of Technology, the tapes were ideally preserved, but — despite some preliminary test prep — the museum’s tape reader kept hanging at the 800 BPI NRZI encoded header, even though the rest of the tape was 1600 BPI phase encoding. Some head scratching later, the team decided to crack open their Qualstar 1052 tape reader and attempt to read the data directly off the circuits themselves!!

Continue reading “Raiders Of The Lost OS: Reclaiming A Piece Of Polish IT History” →

Bus Pirate Commandeers I2C

February 7, 2017 by Bryan Cockfield 19 Comments

The Bus Pirate is one of our favorite tool for quick-and-dirty debugging in the microcontroller world. Essentially it makes it easy to communicate with a wide variety of different chips via a serial terminal regardless of the type of bus that the microcontroller uses. Although it was intended as a time-saving prototyping device, there are a lot of real-world applications where a Bus Pirate can be employed full-time, as [Scott] shows us with his Bus Pirate data logger.

[Scott] needed to constantly measure temperature, and the parts he had on hand included an LM75A breakout board that has a temperature sensor on board. These boards communicate with I2C, so it was relatively straightforward to gather data from the serial terminal. From there, [Scott] uses a Python script to automate the process of gathering the data. The process he uses to set everything up using a Raspberry Pi is available on the project site, including the code that he used in the project.

[Scott] has already used this device for a variety of different projects around his house and it has already proven incredibly useful. If you don’t already have a Bus Pirate lying around there are a few other ways to gather temperature data, but if you have an extra one around or you were thinking about purchasing one, then [Scott]’s project is a great illustration of the versatility of this device.

Catching A Rogue Train With Data

December 13, 2016 by Jenny List 16 Comments

If you have been a regular traveler on one of the world’s mass transit systems over the last few decades, you will have witnessed something of a technological revolution. Not necessarily in the trains themselves, though they have certainly changed, but in the signalling and system automation. Nineteenth and twentieth century human and electromechanical systems have been replaced by up-to-date computers, and in some cases the trains even operate autonomously without a driver. The position of every train is known exactly at all times, and with far less possibility for human error, the networks are both safer and more efficient.

As you might expect, the city-state of Singapore has a metro with every technological advance possible, recently built and with new equipment. It was thus rather unfortunate for the Singaporean metro operators that trains on their Circle Line started to experience disruption. Without warning, trains would lose their electronic signalling, and their safety systems would then apply the brakes and bring them to a halt. Engineers had laid the blame on electrical interference, but despite their best efforts no culprit could be found.

Eventually the problem found its way to the Singaporean government’s data team, and their story of how they identified the source of the interference makes for a fascinating read. It’s a minor departure from Hackaday’s usual hardware and open source fare, but there is still plenty to be learned from their techniques.

They started with the raw train incident data, and working in a Jupyter notebook imported, cleaned, and consolidated it before producing analyses for time, location, and train IDs. None of these graphs showed any pointers, as the incidents happened regardless of location, time, or train.

They then plotted each train on a Marey chart, a graph in which the vertical axis represents time and the horizontal axis represents stations along a line (Incidentally Étienne-Jules Marey’s Wikipedia entry is a fascinating read in itself). Since it represents the positions of multiple trains simultaneously they were able to see that the incidents happened when two trains were passing, hence their lack of correlation with location or time. The prospect of a rogue train as the source of the interference was raised, and analyzing video recordings from metro stations to spot the passing train’s number they were able to identify the unit in question. We hope that the repairs included a look at the susceptibility of the signalling system to interference as well as the faulty parts on one train.

We’ve been known to cover a few stories here with a railway flavor over the years. Mostly though they’ve been older ones, such as this film of a steam locomotive’s construction, or this tale of narrow gauge preservation.

[via Hacker News]

[Main image source: Singapore MRT Circle line trains image: 9V-SKA [CC BY 3.0], via Wikimedia Commons]

Add Data To Your Shipping Suspicions With This Power-Sipping Datalogger

November 4, 2016 by Gerrit Coetzee 43 Comments

One only has to ship one or two things via a container, receiving them strangely damaged on the other end, before you start to wonder about your shipper. Did they open this box and sort of stomp around a bit? Did I perhaps accidentally contract a submarine instead of a boat? Did they take a detour past the sun? How could this possibly have melted?

[Jesus Echavarria]‘s friend had similar fears and suspicions about a box he is going to have shipped from Spain to China. So [Jesus] got to work and built this nice datalogger to discover the truth. Since the logger might have to go for a couple of months, it’s an exercise in low power design.

The core of the build is a humble PIC18. Its job is to take the information from an ambient light, temperature, and humidity sensor suite and dump it all to an SD card. Aside from the RTC, this is all powered from a generic LiPo power cell. The first iteration can run for 10 days on one charge, and that’s without any of the low power features of the microcontroller enabled. It should be able to go for much longer once it can put itself to sleep for a period.

It’s all housed in a 3D printed case with some magnets to stick it to shell of the shipping container. Considering the surprisingly astronomical price of commercial dataloggers, it’s a nice build!

Hackaday Prize Entry: The Strength Of 3D Printed Parts

August 6, 2016 by Gerrit Coetzee 16 Comments

[Sam Barrett] is doing something that is sorely needed. He’s doing real materials research on FDM parts.

There’s nothing wrong with the rough experiments like hanging a 1 L bottle of water from the end of a rectangular test print to compare strengths. We also have our rules-of-thumb, like expecting the print to perform at 30% of injection molded strength. But these experiments are primitive and the guidelines are based on hearsay. Like early metallurgy or engineering; 3D printing is full of made-up stuff.

What [Sam] has done here is really amazing. He’s produced a model of a printed ABS part and experimentally verified it to behave close enough to the real thing. He’s also set a method for testing and proposed a new set of questions. If it couldn’t be better, he also included his full research notebook. Make sure to read the FDMProperties-report (PDF) in the files section of Hackaday.io.

Sam finally answered a question we've had of what it looks like when the printer over extrudes. — Sam finally answered a question we’ve had of what it looks like when the printer over extrudes.

If research like this is being done elsewhere, it’s either internal to a large 3D printer manufacturer, or it’s behind a paywall so thorough only the Russians can help a regular peasant get through to them. Anyone with access to a materials testing lab can continue the work (looking at you every single engineering student who reads this site) and begin to help everyone achieve an understanding of 3D printed parts that could lead to some really cool stuff one day.

Hackaday Prize Entry: Electronics Anywhere, Any Time

July 12, 2016 by Brian Benchoff 11 Comments

There has always been a need for electronic graph paper – a digital device that records ones and zeros, writes bits, and keeps track of analog voltages. Many moons ago, this sort of device was graph paper, wrapped around a drum, slowly spinning around once per day. With the advent of cheap, powerful microcontrollers and SD cards these devices have become even more capable.

For their entry to the Hackaday Prize, [Kuldeep] and [Sandeep] have built Box0. It’s a lab in a bag, an open source data acquisition unit, and a USB device that toggles pins, all in one simple device.

The hardware for this devices consists of an STM32F0 microcontroller, a USB port, and enough pins to offer up a few SPIs, an I2C bus, eight channels of digital output, two PWM channels, a UART, analog in, and analog out.

Of course, hardware is the easy part. If you want to do something useful with a device like this, you need some software. Here is where the project really shines. They have libraries for Python, Julia, C, Java, and JavaScript. That’s enough to make anyone happy, and makes this Box0 exceptionally capable. For a demonstration, they’ve built a curve tracer for transistors and red, green, and blue LEDs with the Box0. It works, and it looks like this actually is an exceptionally useful device.