Syndicate content Hackaday
Fresh hacks every day
ถูกปรับปรุง 12 min 54 sec ก่อน

Beest of an RC Toy

อังคาร, 06/30/2015 - 18:01

Sometimes hackers and makers hack and make stuff just because they can. Why spend hours in a CAD program designing a gazillion gears, brackets and struts? Why cut them all out on a homemade CNC? Why use a PIC and perf board to control everything? Because we can. Well, because [Est] can, rather. He put together this RC controlled beast of a toy with multiple legs and crushing claws.

It’s made out of 6 mm acrylic and threaded rod. The legs are controlled by two DC motors, while the mouth uses two geared steppers. The beast talks to the controller via a pair of 433 MHz transceivers using a protocol similar to how an IR remote talks to a television. A handful of LEDs lights up the clear acrylic, making it look extra scary.

This design is, of course, based on the Strandbeest concept from [Theo Jansen]. It’s a great robotics project because your project doesn’t suffer under its own weight. It’s more like a tracked machine. In fact, we saw a huge rideable version made of metal at BAMF this year. That’s one you just can’t miss!

Filed under: toy hacks

Vibrating Distance Torch Illuminates the Dark without Light

อังคาร, 06/30/2015 - 15:01

If you’ve ever had to move around in a dark room before, you know how frustrating it can be. This is especially true if you are in an unfamiliar place. [Brian] has attempted to help solve this problem by building a vibrating distance sensor that is intuitive to use.

The main circuit is rather simple. An Arduino is hooked up to both an ultrasonic distance sensor and a vibrating motor. The distance sensor uses sound to determine the distance of an object by calculating how long it takes for an emitted sound to return to the sensor. The sensor uses sounds that are above the range of human hearing, so no one in the vicinity will hear it. The Arduino then vibrates a motor quickly if the object is very close, or slowly if it is far away. The whole circuit is powered by a 9V battery.

The real trick to this project is that the entire thing is housed inside of an old flashlight. [Brian] used OpenSCAD to design a custom plastic mount. This mount replaces the flashlight lens and allows the ultrasonic sensor to be secured to the front of the flashlight. The flashlight housing makes the device very intuitive to use. You simply point the flashlight in front of you and press the button. Instead of shining a bright light, the flashlight vibrates to let you know if the way ahead is clear. This way the user can more easily navigate around in the dark without the risk of being seen or waking up people in the area.

This reminds us of project Tacit, which used two of these ultrasonic sensors mounted on a fingerless glove.

Filed under: Arduino Hacks

Hackaday Prize Entry: Circular Knitting Machines

อังคาร, 06/30/2015 - 12:00

Deep in the recesses of a few enterprising hackerspaces, you’ll find old electronic knitting machines modified for use with modern computers. They’re cool, and you can knit colorful designs, but all of these machines are ultimately based on old equipment, and you’ll have a hard time building one for yourself.

For their entry to the Hackaday Prize, [Mar] and [Varvara] is building a knitting machine from scratch. Not only is it a 3D printed knitting machine anyone can build given enough time and plastic, but this machine is a circular knitting machine, something no commercial offering has yet managed.

We saw [Mar] and [Varvara]’s Circular Knitic last January, but this project has quite the pedigree. They originally started on their quest for a modern knitting machine by giving a new brain to old Brother machines. This was an incredible advancement compared to earlier Brother knitting machine hacks; before, everyone was emulating a floppy drive on a computer to push data to the machine. The original Knitic build did away with the old electronics completely, replacing it with a homebrew Arduino shield.

While the Circular Knitic isn’t completely 3D printed, you can make one in just about any reasonably equipped shop. It’s a great example of a project that’s complex and can be replicated by just about anyone, and a perfect example of a project for The Hackaday Prize.

Check out the video of the Circular Knitic below.

The 2015 Hackaday Prize is sponsored by:

Filed under: The Hackaday Prize

Semi-Automatic Bed Leveling Your 3D Printer

อังคาร, 06/30/2015 - 09:00

Two of the most important prerequisites for successful 3D printing is making sure the bed is level and correctly setting the Z=0 height. Getting both of these right almost guarantees great adhesion since the first print layer is not only at the right distance from the build platform but also at a consistent distance for the entire bottom surface of the part.

Manual bed leveling is tedious, requiring the user to move the print nozzle to different points around the build platform, adjust some screws and make sure the nozzle is a piece-of-paper’s thickness higher than the platform. If you want to get complicated, there is an automatic option that probes the build platform and makes height corrections in the software. The probes come in several flavors, two common methods being a deployed mechanical switch (usually mounted to a servo) or force sensors under the build platform that sense when the nozzle touches the build platform. This method also requires some fancy firmware finesse to get working correctly.

[Jonas] posted a video showing the semi-automatic bed leveling capability of his printer. The build platform is held a bit high by springs that surround each of the 3 screws that support the bed assembly. The nozzle is moved directly over one of the 3 screws and then moved down until it noticeably presses on the build platform, compressing the support spring. A thumb wheel is then tightened at that location, locking the bed in place. The same process is performed for the other 2 support points. The result is a perfectly level build surface. Check the video out after the break to see just how quick this procedure is!

We’ve seen a somewhat similar concept that uses a clever gimbal and lock system under the bed.

Filed under: 3d Printer hacks

THP Community Voting: Results & A New Round

อังคาร, 06/30/2015 - 07:00

Last Friday we wrapped up a round of community voting for The Hackaday Prize. The theme? Most Likely To Save The Planet. Now it’s time for some results:

The projects voted Most Likely To Save The Planet by the Hackaday.io community are, in order:

Congratulations to everyone who has a project that was voted up to the top. Even though these rounds of community voting don’t decided which projects make it into the Hackaday Prize semifinals, you’ve earned the respect of your peers and a nifty Hackaday Prize t-shirt.

Since NIRGM – Non-Invasive NIR Glucose Meter won last week, we’re moving down the list to #11 and awarding SciPlo a Hackaday Prize t-shirt as well.

A New Round Of Voting!

This week, we’re asking the Hackaday.io community to vote for the most Amazingly Engineered project entered into the Hackaday Prize. To entice everyone to vote, I’m going to pick a random Hackaday.io user next Friday around 22:00 UTC. If that person has voted, they get a $1000 gift card for the Hackaday Store. If that person has not voted, I’ll be giving a few prizes away to people who have voted. Last week, we gave away a SmartMatrix, an Analog Stepper Gauge, and a Simon Says kit. We’ll probably change that up this week; I don’t know what it will be, but someone who votes will get something. Imagine; giving away stuff just for clicking a button. How magnanimous can we get?

As with every community voting update, it is requested that you vote. If you need a nudge to understand how this works, here’s a video tutorial on how to vote.

Filed under: The Hackaday Prize

Hope it’s real: 3D Printing Houses with Bricks

อังคาร, 06/30/2015 - 06:01

You’ve just got to go with the hype on this one, because it’s obviously not ready for prime time yet. But a few days ago murmurs started circling the net that an Australian inventor had developed a robot capable of building complicated structure from brick all by itself.

Before you go off your rocker… we’re definitely not calling this real. It’s a proof of concept at best, but that doesn’t prevent us from getting excited. How long have you been waiting for robots that can build entire structures on our behalf? We were excited at the prospect of extruding walls of concrete. But this is more like LEGO buildings in the real world. The beast cuts brick to length, conveys each brick along the telescoping arm, and butters them as it lays them in place. At least that’s what the rendered video after the break shows.

We’re hearing about this now because FastBrick Robotics, the company [Mark Pivac] founded and has spent ten years developing the Hadrian project at, was just sold to a company called DMY Capital Limited. Of course they’re going to want to get some press out of the sale.

There is an image of the brick feeder on an existing excavator that frankly looks photoshopped. And some real images like the one seen here and another of the “print head” holding some bricks. But it’s enough to think there’s potential here.

The idea is that the base of the robot is fixed with the arm long enough to reach any part of the structure being built. Precise positioning is achieved by a fixed marker in a different position from the robot. The head triangulates its position using laser range-finding with the marker (having said that we now assume there needs to be more than one marker).

So what do you think? Are we ever going to see this incredibly complicated bucket of awesome producing structures in our neighborhood which the Big Bad Wolf simply cannot blow down?

[Thanks Mark via News.com.au]

Filed under: cnc hacks, home hacks, robots hacks

Etching PCBs With A 3D Printer

อังคาร, 06/30/2015 - 03:00

There are dozens of circuit board printers out there that lay down traces of conductive ink and ask you to glue down components to a fragile circuit board. This is a far cry from the old way of making PCBs, but these printers are going gangbusters, cashing in on the recent popularity of hardware startups and rapid prototyping.

People who think deeply about a problem are few and far between, but lucky for us [Arvid] is one of them. He’s come up with a way of creating PCBs with any 3D printer and steel rod. The results are better than anything you could make with a circuit board printer, and the technique is very, very cheap.

[Arvid] is using the traditional method of etching away copper, just some ferric chloride and a bit of time. How he’s masking the copper that shouldn’t be etched away is a unique process we haven’t seen before. He’s simply covering a piece of copper clad board with permanent marker, and scribing the parts he wants to be etched with a sharp steel rod attached to a 3D printer.

The G code for the printer was generated by FlatCAM, a piece of software made specifically for cutting PCBs with a mill. [Arvid]’s technique works so well that spindles and mills aren’t needed; only a sufficiently sharp instrument to scrape away permanent marker.

Thanks [Hassi] for sending this one in.

Filed under: 3d Printer hacks

The Spirit of Hackaday Shines in Shenzhen

อังคาร, 06/30/2015 - 00:01

Hackaday loves to spread the message of the hardware hacking lifestyle. That’s only possible where there are hardware hackers willing to spend their time getting together to talk the future of the hardware industry, and to celebrate where we are now. We’re honored that you came out en masse for our Shenzhen Workshop and Meetup!

Zero to Product

[Matt Berggren] has presented his Zero to Product  workshop a few times now as part of our Hackaday Prize Worldwide series. This spring that included Los Angeles, San Francisco, and ten days ago it was Shezhen, China.

We partnered with MakerCamp, a week-long initiative that pulled in people from all over China to build a Makerspace inside of a shipping container. Successful in their work, the program then hosted workshops. The one caveat, Shenzhen in June is a hot and sticky affair. Luckly our friends at Seeed Studio were kind enough to open their climate-controlled doors to us. The day-long workshop explored circuit board design, using Cadsoft Eagle as the EDA software to lay out a development board for the popular ESP8266 module.

The language barrier between English and Mandarin is a formidable one. It was really fascinating to see all of the people at the workshop pull together to help sidestep any translation roadblocks that popped up along the way. Knowledge sharing really does trump any barriers when we all work together. Check out the Workshop album for more images.

A Hot Summer Meetup

You haven’t experienced a Maker Faire until you drop by a Hackaday Meetup. We’ve been holding these on the Saturday Evening of Bay Area Maker Faire for the last two years and made it a priority with our attendance at the Shenzhen Maker Faire this year. Through various connections, [Sophi] connected with [Joe Finkenbinder]. He is founder of Bionic Brew in Shenzhen, and a talented craft brewer who has worked to establish craft breweries all over China.

[Joe] suggested NYPD Pizza, a hip eatery in a brand-new yet unopened complex not too far from Nanshan district. This couldn’t have been more perfect! The food was fantastic, [Joe] was able to bring and serve his excellent brews, and the establishment offered plenty of indoor and outdoor areas for the huge crowd that arrived.

We estimate an attendance of nearly 200 hackers with a great variety of backgrounds that made for fascinating conversations at every turn. I was excited to see [Bunnie] and [Akiba] who came along with a group of MIT Media Lab students who were in Shenzhen learning about the manufacturing process. The program sets up each stage of taking a design to production, with a few pre-staged shortcuts to ensure this can be done in a matter of weeks instead of months (think mold-making).

[Ian Lesnet] and the Hacker Camp crew were on hand. We had celebrated the end of their camp with them a few nights before (here’s some extra pictures from that event) and were happy to see them in attendance. Most of the MakerCamp crew made it out as well, this being the last night of their own event. As is our practice, we had been inviting people all day long at Maker Faire as we met them. There were far too many to list in attendance, but [Thomas] from Pebble, [Kevin] of Arduboy fame, [Natalie] brought some LED-illuminated wearables, the WindowsOnDevices crew from Microsoft, our friend [Holly] from NYC Resistor, and of course [Chris] and [Zoe] from Seeed Studio were just a few mentionables at the gathering.

I noted the indoor area already, which was a great way to cool off in the air conditioning. But it wasn’t long before people ditched shoes and socks and waded into the reflection pool. Holding down an outdoor booth in 88F/80% humidity all day, then partying in weather nearly the same made this a necessity. It felt like paradise.

Hitting the Booth on Sunday

I asked a few people and it seems there is no bar-time in Shenzhen. I didn’t head back until about 4am and I wasn’t the last one. Thanks to the Microsoft crew in helping flag down cabs at that time of night! My shift at the booth was a 9am start so it was a short sleep, but the crowds the next day made it a ton of fun!

Our booth was based on the Logic Noise series that [Elliot Williams] has been writing. We had parts, breadboards, powered speakers, and simplified schematics (similar to Fritzing) on hand so anyone could try their hand building a simple oscillator. There’s something magical about seeing the “guts” of a simple synthesizer splayed out like that. The kids were drawn to it and a few of them spent so much time playing with the circuits we sent the gear home with them.

Surprisingly the most-asked question was “what are you selling?”. It took some explaining but it was universally appreciated that we want people to be excited about electronics and to make learning a part of who they are. We were really lucky to have friends of Hackaday stop by and help out. [Holly Hudson] brought goodies and helped staff the booth. [Sprite_TM] — hacker extraordinaire and 2014 Hackaday Prize Judge — helped with circuit building for more than an hour. And 2015 Hackaday Prize Judge [Akiba] stopped by as well. On Sunday we were especially stretched thin as [Sophi] was giving a talk and some of us wanted to be there to hear it! [Chris] from Seeed Studio saved the day by donating a few hours from his busy schedule. Thank you all!

We’ll post more on the Maker Faire itself this week. A big thank you to everyone who attended our Zero to Product workshop and the Hackaday Meetup. We’re grateful to Hackaday’s parent company — Supplyframe — and to the 2015 Hackaday Prize sponsors listed below for making this trip to China and these events possible. Thank you!

The 2015 Hackaday Prize is sponsored by:
Filed under: cons, Featured, The Hackaday Prize

True Random Number Generator for a True Hacker

จันทร์, 06/29/2015 - 21:01

How can you generate random bits? Some people think it’s not easy, others will tell you that it’s pretty damn hard, and then there are those who wonder if it is possible at all. Of course, it is easy to create a very long pseudorandom sequence in software, but even the best PRNG (Pseudorandom Number Generator) needs a good random seed, as we don’t want to get the same sequence each time we switch on the unit, do we? That’s why we need a TRNG (True Random Number Generator), but that requires special hardware.

Some high-end microprocessors are equipped with an internal hardware TRNG, but it is, unfortunately, not true for most low-cost microcontrollers. There are a couple of tricks hackers use to compensate. They usually start the internal free running counter and fetch its contents when some external event occurs (user presses a button, or so). This works, but not without disadvantages. First, there is the danger of “locking” those two events, as a timer period may be some derivative of input scan routine timing. Second, the free running time (between switching on and the moment the unit requests a random number) is often too short, resulting in the seed being too close to the sequence start, and thus predictable. In some cases even, there is no external input before the unit needs a random seed!

Despite what has already been discussed, microcontrollers do have a source of true randomness inside them. While it might not be good enough for crypto applications, it still generates high enough entropy for amusement games, simulations, art gadgets, etc.

Uninitialized RAM

Hackers often make use of hardware resources beyond their initial means. Here we will use volatile RAM, not as a memory unit, but as a source of entropy.

When power is applied to the MCU, its internal volatile RAM has unknown contents. Each flip-flop will be preset to a 0 or 1 state – a consequence of the imperfection of internal circuits, power supply glitches, surrounding current flow, or thermal (or even quantum) noise. That’s why the content of RAM is different each time it is powered on.

A few years ago, Intel came up with a new way of generating true random bits, using a tuned flip-flop which was forced to a metastable state, and then released to a stable 0 or 1 state at 3 MHz rate. They announced that it will be embedded in a new generation of processors.

We don’t have tuned flip-flops in the MCU, but we have a lot of flip-flops and we can expect some of them to act as tuned. How many flip-flops do we really need to create a good random number using volatile RAM content? It surely depends on MCU RAM performance, so we should go through with some experiments to see how many bits are unpredictable after powering on the MCU. This instability occurs only in flip-flops which are highly symmetric, with well balanced transistors. We need those unpredictable bits to harvest entropy, so we should use as much data as we have – the whole data memory, before it is initialized to some known values. We don’t have control lines which could force RAM flip-flops to a metastable state, so we can use it only once – after powering on, and before initializing RAM.


Let’s see the contents of a typical uninitialized MCU RAM. The following picture represents an initial state of one part (20480 bits) of data memory in PIC18F2525 MCU. There are 256 bits (32 bytes) in each row. The ones are red, and the zeros are yellow.

Obviously, there are less 1’s than 0’s in this MCU RAM, but it doesn’t really matter. There are two other matters of interest here: first, will this pattern be different if we use other MCUs (even from the same production line), and how many bits will be changed after the next power on, with the same MCU?

You probably guessed the answer to the first question – yes, each MCU has a completely different initial RAM pattern. The second question is more important, and the answer is that not many bits are different (unpredictable) after every power on. Yet there are enough to generate several random bytes.

Here is an experimental result of switching off and on PIC18F2525 twice. Gray pixels are both times read as 1’s, white are both 0’s, red ones are “0, then 1″ and blue ones are “1, then 0″.

After some experimenting, you could see that generally the same bits in one MCU are unpredictable after switching on. They came from “good” flip-flops and they represent our source of entropy. I tested Microchip’s PIC18 and PIC24E MCUs only (the results are listed below), but any other MCU should act in a similar fashion. Examples shown here are generated with short Vdd rise time (high slew rate), as the on-off switch was between DC supply and the MCU. If you switch the primary side of the power supply which has a low slew rate, you will notice some patterns in memory contents, but somehow the number of unstable bits will actually increase.


So, if you need a few random bytes (for PRNG seed or some magic number), you can use uninitialized RAM contents to generate them. You have to create a special routine, which will XOR (or ADD MOD 256) every byte in some block of uninitialized RAM to generate the first random byte, then the next block for the next byte, and so on. For instance, if your MCU contains 4K of RAM (like PIC18F2525, if you include SFR area), and you need a 32-bit seed, you can split RAM into four 1024-byte blocks and use them to generate four random bytes. Even if small parts of some blocks are already initialized (SFRs or variables for a routine loop), it should not affect the global entropy significantly. I used this technique about a decade ago for LED curtains, which simulated a waterfall in a casino. I built a lot of single chip MCU controllers for that project, and each of them was dimming 256 addressable LEDs. The trick with RAM random seed and 32-bit PRNG created beautiful chaos with a minimum of hardware.

You can also add more scrambling later, for instance you can call your PRNG routine from an existing timing loop (instead of NOP looping), so it will be invoked, supposedly, a random number of times until your program asks for PRNG output. This principle would not create a good random number sequence if used alone, but it can not cause the TRNG performance degradation, as the entropy can only grow.

The major limitation of this approach is that it can’t be used if there is battery backup, or if SLEEP mode is used instead of the ON-OFF switch. However, for some less sensitive applications (like digital arts or amusement games), you still have the long PRNG sequence to cover the period until battery replacement and a new Reset, when the seed will be randomized. You can also let the peripheral counter run in sleep mode and use it later in PRNG seed scrambling, supposing that the extra current in sleep mode does not affect battery life significantly.

We have to keep in mind that RAM contents must be uninitialized and used as-is, immediately after power up. It is also recommended to avoid high capacity Vdd decoupling, as CMOS RAM retention voltage can be pretty low. The worst case scenario is if you switch off the unit for a very short period of time, so that the voltage at the decoupling capacitors drops enough to activate Brown-Out Reset, but not to scramble the RAM contents. Luckily, it is very unlikely that the contents of RAM will ever be exactly the same, as there is always some “housekeeping” part of RAM (or at least MCU registers) which will be affected by program flow. Additional safety can be achieved by a multi-byte freerunning binary counter in RAM, even if the program doesn’t need it and never reads its state.

There are a few design approaches which you can use to enhance the quality of random numbers harvested from the volatile RAM. Never initialize the whole RAM with zeros or any other content, but only the necessary portion. If you don’t use sleep mode (but switch Vdd off instead), then don’t use too high decoupling capacity, or at least use an extra resistor in parallel with MCU supply. It will increase the supply current, but not by too much. Even 5% of total MCU supply current through this resistor will be enough to prevent voltage locking, when Vdd drops so that Idd is close to zero, or even when some external component sources current to the MCU (a beautiful example is described in The Mystery Of Zombie Ram article) . This resistor guarantees that RAM will not remember anything from its previous “reincarnations”, even if MCU was in sleep mode before switching power off.

Searching the Web for similar ideas and experiences, I stumbled upon a discussion with the topic Why don’t we use CPU/RAM-usage for “true” random generation. The author of the idea was heavily criticized, mostly because he suggested using initialized RAM for crypto applications. I also found the patent US5214423, which is based on a similar idea (used to reduce the possibility of repeated bus access collisions). Such patent applications scare every design engineer, as it makes the design process look like walking through a mine field – you never know when you might get sued for your ideas. The good news is that the legal status of this patent is “expired due to failure to pay maintenance fee”, so, hopefully, I have nothing to worry about – at least this time.

Experimental Units

The first experimental results encouraged me to build some units which use uninitialized RAM contents to create permanent random data stream. So I named the described idea (using uninitialized RAM contents for seed creation) “zero concept”, and then built three units to test three new concepts.

  1. Two PIC18F2525s with 8-bit one-way parallel communication, supported by simple handshaking. Slave MCU generates 16 random bytes, each of them based on 248 bytes of uninitialized internal Data RAM. Master MCU (shown in the middle above) receives those bytes and sends them to a desktop PC through the RS232 port. After receiving a 16-byte string, master CPU uses the PNP transistor to power off the slave MCU for 200 ms, which will supposedly create new random contents of RAM (according to my experiments, the “Zombie Ram” effect in 8-bit PIC MCUs takes place if the unit was switched off for less than 85 ms). Then the whole process is repeated 625,000 times, for a total of 10 MB of binary data, needed for randomness tests. It takes about 50 hours (the average rate is 56 bytes/sec).
  2. For the second test the same master MCU is used, but this time the slave is a 16-bit MCU 24EP512GP202. All MCUs are on the same proto board (that’s why they are on the same schematic diagram), and the program in the master MCU decides which slave MCU will be used. The left one is significantly faster (70 MIPS vs. 4 MIPS) and has much more internal Data RAM (48 K instead of 4 K bytes). One string of random data contains 192 bytes, so the 10 Mbyte file was created in 5.5 hours.
  3. And finally, only one MCU is used (24EP256GP710A) with 4 Mbytes of external SRAM (CY62177EV30). I had hardware leftovers from some old project, otherwise I would have used the low cost I2C SRAM and a small MCU. SRAM is powered off-on, and then read in a similar manner. The only advantage is high amount of RAM which resulted in high speed, so it took only 19 minutes for a 10 Mbyte file. It could be much faster, but the RS232 port is too slow to keep up with the fast random data stream creation.
Randomness Tests

Two batteries of tests were used, Diehard and ENT. The first concept (with two 18F2525s) had an excellent result – all 15 Diehard and 6 ENT tests passed! The remaining two concepts passed all Diehard tests, but failed one ENT test, which is the most sensitive indicator of randomness, roughly defined as “rate at which Chi square distribution would be randomly exceeded”. The required rate is between 10% and 90% (ideally 50%), but most TRNGs and PRNGs fall flat on this test, showing less than 0.01% or more than 99.99%. Fourmilab published an example of a well rated commercial TRNG which uses radioactive decay events – the ENT page linked above puts that hardware at 40.98%.

I am not a mathematician, but during the experiments I had a feeling that passing all Diehard tests should be quite easy (I don’t know why design engineers are afraid of it), as well as getting good values on almost all of the ENT tests – but this one is a nightmare! It fluctuates significantly during file growth, and tends to stabilize as the file becomes quite large, but even with 10 Mbyte files it is still not stable enough. This test is so sensitive that it is extremely hard to get values which are not saturated below 0.01% or above 99.99%, so even if it fluctuates somewhere between, it’s good news.

The first test run for my first concept gave a surprisingly good rating of 47.47%! The other two concepts failed (<0.01%), but I still had a secret weapon, called whitening transformation. Every hardware TRNG has some kind of a randomness extractor (mainly implemented in software), to minimize the bias and enhance the uniformity of data distribution. The simplest way to do this is to merge somehow (e.g. XOR) raw random data from the hardware TRNG with a software PRNG. So I added a simple 32-bit linear congruential PRNG routine to the MCU firmware (for concepts 2 and 3 only) – even though it might not seem like the best of ideas, it got the job done, as all results were perfectly in range. Here are ENT test results:

Entropy source

1. (8-bit MCU raw data)

2. (16-bit MCU with PRNG support)

3. (ext RAM with PRNG support)

Entropy (bits/byte)




Compression reduced the size by




Chi square distribution randomly would be exceeded at




Arithmetic mean value (127.5 = random)




Error for Monte Carlo Pi value




Serial correlation coefficient (0.0 = uncorrelated)




Diehard test results require much more presentation room, you can find them at www.voja.rs/rndtests.htm, together with binary files which are generated in this experiment and all source files in PIC’s assembly language.


At the end, all tested projects passed all Diehard and ENT tests. Even the commercial TRNGs (including the very expensive models) sometimes fail tests, and those $10 DIY units passed all of them!

It is important to keep in mind that this principle is based on undocumented characteristics of microcontrollers, and that it is impossible to reach the degree of safety required for crypto-grade applications. So, what  about our high score? Well, at the very least, we proved that the uninitialized RAM can offer high quality random numbers, and that we can use it for seed generation in a lot of MCU applications. It’s simple, it’s free, it takes no extra room on the PCB and it consumes no extra current.

For those that want a random seed without building their own hardware, check out [Elliot’s] article on the NIST Randomness Beacon.

[Illustration by Bob Zivkovic]

​​Voja Antonic works as a freelance microcontroller engineer in Belgrade. His first microprocessor projects, based on Z80, date back to 1977, just a few years after the appearance of the first Intel’s 4004. He assembled the firmware manually, by pen and paper. In 1983, he published his original DIY microcomputer project called Galaksija, which was built by around 8000 enthusiasts in the former Yugoslavia. To date he has published more than 50 projects, mostly based on microcontrollers, and released all of them in the public domain.

Filed under: Featured, Microcontrollers, security hacks, slider

MapleMaker 3D Printer is As Printable as They Get

จันทร์, 06/29/2015 - 18:01

The term RepRap is fairly common and gets thrown around too often when generally talking about DIY 3D Printers. We must remember that the intent of the RepRap project “…is about making self-replicating machines…” and of course “…making them freely available for the benefit of everyone…“.

[MiniMadRyan] has recently designed a printer that could be considered the embodiment of the RepRap philosophy. He’s calling it the MapleMaker Mini V2. An extremely high percentage of the parts required to build this printer are, in fact, printable themselves. The frame pieces are printed, all of which can be printed on the printer thanks to the 6x8x6 inches print volume. The overall design is aesthetically pleasing, resembling that of a Lulzbot Mini.

The MapleMaker Mini V2 is self-replicating. The other part of the RepRap goal is to be free to the community. The design files are available on YouMagine and the assembly manual is better than those provided by most commercial companies. So if you’re looking to build a printer, be sure to add this one to your short list!


Filed under: 3d Printer hacks

Easy Way To Listen To Cube Sats

จันทร์, 06/29/2015 - 15:01

[Bill Meara] has discovered an easy way to listen to amateur “cube-sat” satellites using a cheap SDR Dongle.

The DVB-T SDR Dongle comes in at a whopping thirteen bucks, and the highly sophisticated antenna (pdf) is made from a bit of copper wire and uses aluminum wire for the ground plane.

Once he had everything hooked up, [Bill] went to the Heavens Above website to see when satellites would be passing over him. He was able to lock onto the Prism Satellite, and then a couple other cube-sats that were launched from Russia and Istanbul.

While listening to the Japanese FO-29 satellite at 470 MHz, the Doppler Shift was noticeable ,verifying that he was indeed tuned in to a device in low Earth orbit. Be sure to check out his blog for more details, not to mention the video below where you can hear the Doppler Shift for yourself.

Filed under: radio hacks

Hackaday Prize Entry: An SD Card Arduino

จันทร์, 06/29/2015 - 12:00

About a year ago, Intel announced they’d be launching a new platform stuffed into an SD card. Imagine – an entire computer packaged into an SD card, with nine whole pins for power and I/O. Cooler heads prevailed, the Intel Edison was launched, but the idea stuck; why can’t you fit an Arduino in an SD card?

[kodera2t] found out there’s no real reason why you can’t put a small microcontroller inside an SD card. For his Hackaday Prize entry, he created the SDuino, and it’s exactly what it says on the tin: an ATMega328p stuffed into a microSD adapter.

Unlike the other microcontroller stuffed in an SD card platform — the Electric Imp, [kodera] is, for the most part, respecting the standard pinout for SD cards. The MISO and MOSI signals are reversed, of course, one of the grounds on the SD pinout is tied to an analog input pin on the microcontroller, and the chip select on the SD pinout is ignored completely. Other than that, it’s the closest you’re going to get to an SD card with a microcontroller.

The 2015 Hackaday Prize is sponsored by:
Filed under: The Hackaday Prize

Electric Lawn Mower Converted to RC Control

จันทร์, 06/29/2015 - 09:01

Not too many people like pushing a lawn mower around the yard, but unfortunately, it is a necessary chore. Anti-push-mower advocate [imadethis2014] decided to (as his moniker suggests) make a solution to his pushing-problem. He was a fan of radio controlled devices so it made sense to convert his mower to RC!

The mower itself is powered by an off the shelf battery and has a 21-inch deck. The stock wheels and handle were removed and replaced with a new extruded aluminum frame. Out back are a pair of used electric wheelchair motors sourced from eBay. These drive motors are mounted to the new frame via a pair of aluminum brackets that [imadethis2014] designed and cut out on his Shakepoko CNC machine. Since both rear drive wheels work independent of each other, a pair of swiveling casters up front allow the mower to turn.

A large car-sized battery box houses the two smaller wheel chair batteries as well as the motor control and RC electronics. Check out the video after the break, the mower seems to do fairly well. [imadethis2014] admits he needs some new wheels as the current ones don’t get a lot of traction on the grass. He’s also thinking of adding GPS for automated mowing but isn’t quite there yet.


Filed under: home hacks

Hackaday Links: June 28, 2015

จันทร์, 06/29/2015 - 06:00

The iBookGuy is using CPU heatsinks to cool microwave dinners. It’s an old Pentium II heatsink and a modern fan, cobbled together into a device that can quickly and effectively cool down a microwave dinner. I have several heatsinks from some old Xeon servers in my kitchen, but I don’t use them to cool food; I use them to defrost food. It’s very effective, and now I need to get some data on how effective it is.

[juangarcia] is working on a 3D printable PipBoy – the one in the upcoming Fallout 4. The extra special edition of Fallout 4 include a PipBoy that works with your cellphone, but if you want one before November, 3D printing is the way to go.

[Collin] over at Adafruit is teaching Oscilloscope Basics. Note the use of the square wave output to teach how to use the controls. Also note the old-school DS1052E; the Rigol 1054Z is now the de facto ‘My First Oscilloscope’

[Donovan] has one of those V212 toy quadcopters. The remote has a switch that controls a bunch of lights on the quad. This switch can be repurposed to control a small camera. All it takes is some wire, an optocoupler, and a bit of solder. Very cool. Video here.

I go to a lot of events where hackers, devs, and engineers spend hours banging away on their laptops. The most popular brand? Apple. The second most popular brand for savvy consumers of electronics? Lenovo, specifically ThinkPad X- and T-series laptops (W-series are too big, and do you really need a workstation graphics card for writing some node app?). They’re great computers, classic works of design, and now there might be a ThinkPad Classic. With a blue Enter key, 7-row keyboard, a multi-color logo, ThinkLights, a bunch of status LEDs, and that weird rubberized paint, it’s a modern realization of what makes a ThinkPad great. Go comment on that Lenovo blog post; the designer is actually listening. Now if we could just get a retina display in a MacBook Air (the one with ports), or get manufacturers to stop shipping displays with worse than 1080 resolution…

Need a fan guard? Know OpenSCAD? Good. Now you have all the fan guards you could ever want. Thanks [fridgefire] for sending this one in.

Filed under: Hackaday Columns, Hackaday links

What You See Is What You (Laser) Cut

จันทร์, 06/29/2015 - 03:00

WYSIWYG editors revolutionized content management systems, will WYSIWYC interfaces do the same for laser cutters? Unlikely, but we still appreciate the concepts shown here. Chalkaat uses computer vision to trace lines drawn in ink with the cutting power of a laser.

At its core, you simply draw on your work piece with a colored marker and the camera system will ensure the laser traces this line exactly. There is even a proof of concept here for different behavior based on different line color, and the technique is not limited to white paper but can also identify and cut printed materials.

This is a spin on [Anirudh’s] first version which used computer vision with a projector to create a virtual interface for a laser cutter. This time around we can think of a few different uses for this. The obvious is the ability for anyone to use a laser cutter by drawing their designs by hand. Imagine introducing grade-school children to this type of technology by having them draw paper puppets and scenery in advance and have it cut in shop class for use in art projects.

A red arrow indicates cut line, but a pink arrow is used for indicating positioning on a work piece. The example shows a design from a cellphone etched next to a positioning marker. But we could see this used to position expensive things (like a Macbook) for etching. We also think the red marker could be used to make slight adjustments to cut pieces by scribing a work piece with the marker and having the laser cut it away.

This concept is a product of [Nitesh Kadyan] and [Anirudh Sharma] at the Fluid Interfaces group at the MIT Media Lab and is something we could see being built into future laser cutter models. What do you think?

Filed under: laser hacks

3D Printing Binaural Microphones

จันทร์, 06/29/2015 - 00:00

Binaural audio is probably the coolest thing you can listen to with a pair of headphones. Instead of just a single microphone, binaural recordings use two microphones, set inside an analog for a human head, to replicate exactly what you would hear if you were there.

The only way to record binaural audio is with fake plastic ears attached to a dummy head. Most of the famous microphone manufacturers have something like this, but with a 3D printer, anything is possible. [Carlos] created his own binaural microphone using a 3D printer and went through the trouble of creating a few audio demos. The results are weird, like [Carlos] is whispering into your ear.

The ears used in this microphone setup are taken from a Thingiverse project by [Jonathan March]. This model did not properly model the ear canal,and didn’t have any way to mask the sound from ear to ear; this is why the professional models also include a head. [Carlos] fixed these shortcomings and created a few 3D models that accurately model the human ear and head.

There’s also a simple stereo microphone amplifier for this project that is designed to fit right between the ears. This amplifier was designed in KiCAD, and the PCB is single sided. It’s not quite simple enough to assemble on a piece of stripboard, but [Carlos] did manage to manufacture it on some copper clad board in his mill.

The results? It sounds awesome. [Carlos] put together a demo of his microphone, link below, and it only works if you’re wearing headphones.

Filed under: 3d Printer hacks

Maker Faire Kansas City: Coming To Grips With The Mechanics Of Dexterity

อาทิตย์, 06/28/2015 - 21:00

There is always a great variety of things to see and experience at the Kansas City Maker Faire. This is the fifth year for the event which is held at historic Union Station, a beautiful art deco train depot from a bygone era. With a multitude of booths and exhibits across two floors and a vast outdoor area, there is something for pretty much everyone. Often times, the interesting things are mobile conversation-starting creations. When we saw [Dan] walking around with a giant wooden contraption on his arm, we knew we must find out more about it.

The impetus for [Dan]’s project was his desire to pick up a soda can using a mechanical grip. He now believes this to have been a lofty goal, given the weight of a full can of the stuff. This prosthetic hand is made from wooden finger segments that are connected by small, continuous hinges. Each of [Dan]’s gloved fingers curls around a metal ring to control that digit’s large wooden analog. On the inside of the hand, sections of paracord run underneath strategically placed eye bolts on each finger segment and are tied off at the fingertips. A second set of eye bolts on the back of the hand anchor the network of rubber bands that provide resistance. Although he made it look easy to open and close the hand, [Dan] said that it’s pretty heavy to lug around and somewhat strenuous to use. Next time, he’ll probably go with foam or 3D-printed pieces.

Filed under: cons

2D Printed Tachometer For A Lathe

อาทิตย์, 06/28/2015 - 18:00

If you ever wanted a reason to have DC lighting pointed at the spinny part of your mill and lathe, [Bill] tells a great story. One day, he noticed the teeth on his lathe chuck would change color – red, then blue, then red. His conclusion was the fluorescent lights above his workbench was flashing, as fluorescent lights normally do.

Imagine if the teeth on [Bill]’s chuck weren’t painted. They would appear stationary. That’s usually a bad thing when one of the risks of using a lathe is ‘descalping.’ Buy an LED or incandescent work light for your shop.

This unique effect of blinking lights got [Bill] thinking, though. Could these fluorescent lights be used as a strobe light? Could it measure the RPM of the lathe?

And so began [Bill]’s quest for a 2D printed lathe tachometer. The first attempt was to wrap a piece of paper printed with evenly space numbers around the chuck. This did not work. The flash from his fluorescent bulb was too long, and the numbers were just a blur. He moved on to a maximum-contrast pattern those of us who had a ‘DJ phase’ might recognize immediately.

By printing out a piece of paper with alternating black and white bands, [Bill] was able to read off the RPM of his chuck with ease. That’s after he realized fluorescent lights blink twice per cycle, or 120 times a second. If you have a 3″ mini-lathe, [Bill] put the relevant files up, ready to be taped to a chuck.

Filed under: tool hacks

Wirelessly Weighing Plants with the ESP8266

อาทิตย์, 06/28/2015 - 15:01

There’s a good number of hacks, and commercial products, for telling you when a plant needs watering. Most of them use an ADC to measure the resistance in the soil. As the soil’s moisture content drops, the resistance increases. High impedance, dead plant.

[Dani]’s Thirsdee takes a different approach to plant health monitoring. Instead of measuring resistance, it simply weighs the plant. As the soil dries up, it gets lighter. By measuring the change in weight, the amount of water in the pot can be estimated.

Thirsdee uses a load cell to measure the weight. It’s read using an HX711 ADC, which is controlled by a NodeMCU. This development board is based on the ESP8266 chip. Since Thirsdee has WiFi, it can push notifications to your phone and log data on ThingSpeak. If you’re looking at the plant, an OLED shows you the current status of the plant. For us viewing from home, we can see a graph of [Dani]’s plant drying out in real time.

[Dani] provides us with a list of suppliers for the parts, and all the source code on Github.

Filed under: home hacks

Hackaday Prize Entry: Saving Water with the Vinduino

อาทิตย์, 06/28/2015 - 12:00

[Reinier van der Lee] owns a vineyard in southern California – a state that is in a bit of a water crisis. [Reinier van der Lee] also owns an arduino and a soldering iron. He put together a project the reduces his water usage by 25%, and has moved it to open source land. It’s called the Vinduino.

Its operation is straight forward. You put a water sensor in the dirt. You turn on the water. When the water hits the sensor, you turn the water off. This was not, however, the most efficient method. The problem is by the time the sensor goes off, the soil is saturated to the point that the plant cannot take it all up, and water is wasted.

The problem was solved by using three sensors. The lowest most sensor is placed below the roots. So it should never go off. If it does, the plant is not taking in all the water, and you can reduce the output. The two sensors above it monitor the water as it transitions through the soil, so it knows when to decrease the water amount and watering cycle times.

Be sure to check out the project details. All code and build files are available on his github under the GNU General Public License 3.0

The 2015 Hackaday Prize is sponsored by:
Filed under: Arduino Hacks, green hacks