Retrotechtacular: Breaking Atoms To Break The Ice

March 18, 2014 by Mike Szczys 20 Comments

retrotechtacular-lenin-nuclear-icebreaker

This documentary from 1959 gives a satisfyingly thorough look inside a nuclear powered icebreaking ship called Lenin. This actually set a couple of world’s-firsts: it was the first nuclear powered surface vessel and the first civilian vessel to be powered thusly.

The ship was built to clear shipping paths to the northern ports of Russia. Testing of both ice and models of the ship design point to the ability to break ice layers that are two meters thick. This requires a lot of power as ice-breakers generally use their hull shape and gravity to break the ice by driving up onto it to bend the ice to the breaking point. The Lenin achieved this power using its nuclear reactor to heat steam which drove electric generators. The energy produced drove three screws to power the vessel.

Of course this was back in the day when control panels were substantial, which you can get a peek at starting half-way through the twenty-minute film. This includes a demonstration of the ship’s network of radiation sensors which alert the control room, and sound a local alarm when they are triggered. During it’s 30-year operational life the vessel had a couple of accidents stemming from refueling operations. You can find more on that over at the Wikipedia page, but stick with us after the jump to see the vintage reel.

Continue reading “Retrotechtacular: Breaking Atoms To Break The Ice” →

Hackaday Links: March 16, 2014

March 16, 2014 by Mike Szczys 10 Comments

Tape decks are fertile hacking ground. In this offering from [Erich] the speed of the motor has been turned into a MIDI instrument. Drive it faster and the pitch rises, slower and it falls. There are all kinds of other magnetic tape hacks around here, this tape delay is a classic.

[Dbever] needed a reason to use a big 7-segment display module. He opened up the drill press at his Hackerspace, Pumping Station One, and added a sensor which shows the RPM of the drill on the display. Hackaday was lucky enough to be invited for a tour of the space last fall.

There’s a lot of hype about 3D printing… and rightly so since it’s the radest; which is even better than being “the most rad”. But if you don’t have access to one that shouldn’t stop you. Here’s an example of making robot parts using polymorph instead of 3D printing (or laser cutting) them.

If you’re living in the east-coast metroplex and are unable to travel to Maker Faire Bay Area this Spring you can still get in on some live hacking. Check out MassHack which takes place the same May weekend but in Boston instead of San Fran.

Blimps; not as cool as quadcopters but orders of magnitude less likely to go down in flames (as it were). Draw some inspiration for your own build from silent_runner. The graceful travel of these lighter-than-air-craft make for an interesting camera platform. Here’s a POV video inside of a church, and some shots from the ground while in the woods. [Thanks Oliver]

We try not to pimp crowd-funding campaigns just for the sake of getting them to the goal. But we hope you’ll agree that the Gamebuino we saw a few months back makes a strong argument for backers. Their Indiegogo for the Arduino-compatible handheld gaming rig is over half-way there after just a couple of days.

Developed On Hackaday: Security And Arduino Compatibility

March 16, 2014 by Mathieu Stephan 56 Comments

Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Hackaday 68k: Gluing Architecture Buffer Maps

March 13, 2014 by Brian Benchoff 24 Comments

It’s time for more blatant advertising for Hackaday Projects, the best project hosting site on the Internet. Did we tell you it’s collaborative? That you and your friends can work on projects together? Want more encouragement to join? How about a contest with prizes that include oscilloscopes, FPGA dev boards, soldering and rework stations, Beaglebones and Raspberries and Spark Cores? Oh my!

Oh. We’re also developing a retrocomputer to show off the features of Hackaday Projects. This is the latest update, showing off the architecture of the entire system, the memory map, and the logic glue and buffers. The plan for this project is to have it host another awesome Hackaday site, our retro version, a small off-shoot of the main Hackaday site that’s specifically designed to be loaded by computers built before 1993. There haven’t been many retro successes in the Hackaday tip line recently, so if you manage to get a vintage computer to pull the retro site up, snap a pic and send it in.

For those of you wanting to catch up on the Hackaday 68k project, here’s the Hackaday Projects page, and here’s all the front page updates. Click that ‘Read more…’ link for the update.

Continue reading “Hackaday 68k: Gluing Architecture Buffer Maps” →

Fail Of The Week: Unconnected Nets In KiCad

March 13, 2014 by Mike Szczys 15 Comments

fotw-unconnected-net

From the title and the image above you surely have already grasped this Fail of the Week. We’ve all been there. Design a board, send it to fab or etch it yourself, and come to find out you’ve missed a connection. Automatic checks in your software should prevent this, but when making small changes it’s easy to overlook running the checks again. This is exactly what [Clint] did with this board; leaving a net unconnected in the schematic, which made its way through to the board layout and into the OSHPark boards.

Okay, so fix it with jumper wire which is clearly what he did (white wire in the lower left image above). But since this is rev3 of his PCB it’s pretty upsetting that it happened. The meat and potatoes of the fail is the missing software feature that led to it. KiCad doesn’t have a pin swap tool in the board layout. Really? We use KiCad frequently and didn’t realize that the feature was missing. Needing to simplify his board layout, [Clint] went back to the schematic to swap some resistor network pins by hand. He pushed the change through the netlist and into the board layout, not realizing he had left an input gate unconnected.

A bit of searching proves that pin swapping may be coming to KiCad soon. It’s on the CERN roadmap of features they plan to add to the open source PCB layout software. We remember hearing about CERN’s plans quite a while ago, and thought we featured it but the only reference we could find is [Chris Gammell’s] comment on a post from back in December. It’s worth looking at their plans, these are all features that would make KiCad a juggernaut.

EDITORIAL NOTE: We’ll soon be out of story leads for this series. If you have enjoyed reading weekly about fails please write up your own failure and send us the link. Of course any documented fails you find around the internet should also be sent our way. Thanks!

Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Developed On Hackaday: Coding Conventions And GitHub Pull Requests

March 12, 2014 by Mathieu Stephan 100 Comments

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)

{

if (foo)

{

functionCall();

}

else

{

foo = 0;

anotherFunctionCall();

}

}

– 79 characters line length as a soft requirement

– 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.

Retrotechtacular: Shedding Light On Holograms

March 11, 2014 by Kristina Panos 10 Comments

This week’s Retrotechtacular is a 1972 introduction to holography produced by the fine folks at Encyclopædia Britannica. It details quite admirably what holograms are and how they’re made.

Holograms are quite different from photographs, though both are recorded on film. Holography is based on the additive effects of waves: two crests of equal amplitude create a larger crest, while a crest and a trough of equal amplitude cancel each other out, causing an interference effect. The video demonstrates the concept nicely with water ripples and explains that the same effect happens with sound waves and light waves.

Lasers are the key to the intense and spectrally pure light required for holography. Incandescent light consists of too many wavelengths to be effectively split into two identical light wave sources. To create a hologram, a laser is split with an optical device into two beams. One beam is focused directly on the object being recorded and is called the object beam. The second beam is directed away from the scene through a series of mirrors and shone directly onto a film emulsion.

The film records the interference between the waves of the two beams. It appears to be blank after development, but upon close inspection reveals stripes of light and dark. When the exposed film is placed in the path of only the reference beam, the interference patterns recorded on the film split the beam back into two, recreating the scene. With the aid of a screen for projection, the hologram can be seen showing the original object in 2D. Another big difference between photographs and holograms is that even a small portion of a hologram can reproduce the entire scene, but a piece of a photograph is just that.

Continue reading “Retrotechtacular: Shedding Light On Holograms” →