Catching A Rogue Train With Data

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

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

[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

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

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.

Dump Your (Old) Computer’s ROM Using Audacity

If you’ve got an old calculator, Commodore 64, or any other device that used a tape recorder to store and retrieve data, you’ve probably also got a bunch of cassettes lying around, right? Well, you can get rid of them now (or sell them to nostalgic collectors for outrageous prices) because you can just as easily dump them to Audacity, decode them and archive them on a more sane medium.

In [Kai]’s case, the computer was a Sharp Pocket Computer system, and in his post there’s a lot of detail that’s specific to that particular system. If that’s applicable to you, go read up. In particular, you’ll be glad to find that the Pocket-Tools is a software suite that will encode and decode files between the Sharp binary formats and audio. Along the way, we found similar tools for Casio pocket computers too.

For a more general-purpose approach, like if you’re trying to dump and load data from a more standard computer that uses 1200/2400 Hz FSK encoding, this Python library may be useful, or you can implement the Goerzel algorithm yourself on your platform of choice. If you’ve got a particular binary format in mind, though, you’ll have to do the grunt work yourself.

Anyone out there still using these audio data encodings? We know that ham radio’s APRS system runs on two tones. What else? Why and when would you ever transfer data this way these days?

via the Adafruit blog!

Show me the Data: Year #02 has just turned two today and we couldn’t be more excited about how far we’ve come. What started out as a simple proof-of-concept, inspired by ye-olde idea of a “virtual hackerspace,” has truly evolved into a global playground for some of the best, brightest, and most creative minds you have ever met. It also became a home and the place to spend sleepless nights for many of us on the team, and we’re excited to share a few ideas on where we are headed going forward.

But before we do that, let’s look at some data.

The Data

We’re thrilled to report that over the last two years, has grown from zero to a 121,158-member strong community, who have together created a total of 9,736 projects. To put this in context, it is more than a two-fold growth from last year’s milestone of 51,838 users / 4,365 projects. And it doesn’t seem to be showing any signs of slowing down.



Though these “vanity” metrics sure are a nice validation, the number that gets us the most excited is the fact that the 9,731 projects currently on the site have been created by a total 4,966 different users. What’s even better is the fact that 949 projects are a result of collaboration between two or more people. Altogether, a total of 7,170 different users have participated in the creation of the vast body of engineering knowledge currently residing on

Continue reading “Show me the Data: Year #02”

Logging Engine Temperature For RC Models

[Rui] enjoys his remote-controlled helicopter hobby and he was looking for a way to better track the temperature of the helicopter’s engine. According to [Rui], engine temperature can affect the performance of the craft, as well as the longevity and durability of the engine. He ended up building his own temperature logger from scratch.

The data logger runs from a PIC 16F88 microcontroller mounted to a circuit board. The PIC reads temperature data from a LM35 temperature sensor. This device can detect temperatures up to 140 degrees Celsius. The temperature sensor is mounted to the engine using Arctic Alumina Silver paste. The paste acts as a glue, holding the sensor in place. The circuit also contains a Microchip 24LC512 EEPROM separated into four blocks. This allows [Rui] to easily make four separate data recordings. His data logger can record up to 15 minutes of data per memory block at two samples per second.

Three buttons on the circuit allow for control over the memory. One button selects which of the four memory banks are being accessed. A second button changes modes between reading, writing, and erasing. The third button actually starts or stops the reading or writing action. The board contains an RS232 port to read the data onto a computer. The circuit is powered via two AA batteries. Combined, these batteries don’t put out the full 5V required for the circuit. [Rui] included a DC-DC converter in order to boost the voltage up high enough.