We’re sure that many of Hackaday readers already know that one of the two main components of the Mooltipass project is a smart card, containing (among others) the AES-256 encryption key. Two weeks ago we asked if you’d be interested coming up with a design that will be printed on the final card. As usual, many people were eager to contribute and recently sent us a few suggestions. If you missed the call and would like to join in, it’s not too late! You may still send your CMYK vector image at mathieu[at]hackaday[dot]com by sunday. More detailed specifications may be found here.
In a few days we’ll also publish on Hackaday a project update, as we recently received the top and bottom PCBs for Olivier’s design. The low level libraries will soon be finished and hopefully a few days later we’ll be able to ship a few devices to developers and beta testers. We’re also still looking for contributors that may be interested in helping us to develop browser plugins.
The Mooltipass team would also like to thank our dear readers that gave us a skull on Hackaday projects!
Our offline password keeper project (aka Mooltipass) is quite lucky to have very active (and very competent) contributors. [Harlequin-tech] recently finished our OLED screen low level graphics library which (among others) supports RLE decompression, variable-width fonts and multiple bit depths for fonts & bitmaps. To make things easy, he also published a nice python script to automatically generate c header files from bitmap pictures and another one to export fonts.
[Miguel] finished the AES encryption/decryption schemes (using AES in CTR mode) and wrote an awesome readme which explains how everything works and how someone may check his code using several standardized tests. We highly encourage readers to make sure that we didn’t make any mistake, as it was one of you that suggested we migrate to CTR mode (thanks [mate]!).
On the hardware side, we launched into production the top & bottom PCBs for Olivier’s design. We’re also currently looking for someone that has many Arduino shields to make sure that they can be connected to the Mooltipass. A few days ago we successfully put the Arduino bootloader inside our microcontroller and made the official Arduino Ethernet shield work with it.
Finally, as you may have guessed from the picture above our dear smart card re-sellers can pretty much print anything on them (these are samples). If one of you is motivated to draw something, please contact me at mathieu[at]hackaday.com!
On a (way) more childish note, don’t hesitate to give a skull to the mooltipass on HaD projects so it may reclaim its rightful spot as “most skulled“.
At one point in history, blueprints were actually blue. Now, if you even see a dead tree version of plans or assemblages, they’re probably printed off with a plotter or large format printer. You can, however, make your own blueprints at home, as [Tyler] shows us in his Hackaday Project.
Back in the olden days, master drawings were traced onto large sheets of transparent film. These master prints were then laid over paper prepared with Potassium Ferricyanide and Ferric Ammonium Citrate to create an insoluble Prussian Blue background for the prints. Developing is easy – just expose the transparent positive and undeveloped paper to UV light, in the form of fluorescent bulbs or the sun.
[Tyler] began his blueprint creation process by getting a few design sketches of the RSI Aurora and Nautilus, editing them on a computer, and printing them out on transparency sheets. A solution of equal parts Potassium Ferricyanide and Ferric Ammonium Citrate were painted onto a piece of paper and allowed to dry. Exposing was a simple matter of laying the transparency over the undeveloped paper and setting it out in the sun for 20 minutes or so. After that, it’s a simple matter of washing off the unexposed chemicals and letting the newly created blueprint dry.
It’s a simple technique, but also very, very cool. Not exactly practical, given a plotter can spit out an architectural or assembly drawing of any building, vehicle, or device in a few minutes, but just the ticket for art pieces or extremely odd engineers.
Thanks [Sarah] for sending this in.
[Arthur] is teaching himself product development. Rather than create a few mock-up products, he’s taking the path of designing real devices he can use. His current device is a status light for automated software tests. We’ve seen test and GitHub status lights before, however this is the first one to integrate with an outside web service. The status light’s state is based upon output from CodeShip, an online continuous deployment test engine.
The electronic design is simple. An Electric Imp retrieves test status data from CodeShip. The Imp then sends the status data over two GPIO lines to an AdaFruit Trinket. The Trinket controls a NeoPixel ring. A green ring indicates all tests are passing. Purple means tests are in progress. A spinning red ring (of death) means one or more tests have failed. Power is supplied via a mini USB connector.
[Arthur] spent quite a bit of time on the mechanical design of the status light as well. All the parts are 3D printed. This allowed him to quickly go through several revisions of each part. We like the use of white PLA for a frosted effect on the top section of the light, as it diffuses the eye piercing glow from all those RGB LEDs. As a finishing touch, [Arthur] created a fake product page for his light. He doesn’t have any plans to sell it, but we hope he drops the source and STL files so we can create one of our own.
Continue reading “Status Light Tells You The Code is Borked Again”
[John] has managed to replace a broken turn signal PCB by scanning it and converting to Gerber format. [John] purchased a Triumph Spitfire with toggle switch wired up for turn signal control. The “official” replacement part worked better than the toggle switch, but it didn’t cancel after turning. He was able to get the original switch, only to find it had a hole completely burned through the phenolic board. This isn’t completely surprising, as Triumph used a Lucas Industries electrical system. As anyone who has owned a car with a Lucas “prince of darkness” electrical system will tell you, Lucas systems were not known for quality. A quick Google search brings up plenty of pages attesting to this.
Phenolic resin/paper was a common early PCB material. The FR-4 fiberglass boards most commonly used today could be considered descendants of FR-1 and FR-2 phenolic. (The FR in this case stands for Fiber Reinforced). The standardization worked in [John’s] favor, as his burned board was 31 mils thick, which is still a standard PCB thickness. Re-creating an odd sized board such as this isn’t a hard job. It would however mean spending quite a bit of time with a ruler and a caliper. Rather than spend all that time measuring and re-drawing, [John] scanned his PCB on a flatbed scanner. He used graph paper as a background to verify the image wasn’t being stretched or skewed.
[John] brought his scan into inkscape, and traced both the outline and copper areas. The outline and copper had to be exported as two separate files, so he added corner marks outside the board outline as fiducials. He then used pstoedit to convert inkscape’s eps output files to gEDA pcb format. The two files were rejoined in gEDA. From there [John] exported a Gerber, and ran it on his home PCB milling machine. The results look good. [John] plans to make another revision of the board from a professional PCB house with vias to hold the copper to the substrate.
Our tips line is blowing up again, this time directing us to Motorola’s Project Ara: a phone with modular components that plug into a base “endoskeleton.” If you missed the news coverage strewn across the web and you are doing a double-take, that’s because Project Ara is frighteningly similar to the (presumed vaporware) Phonebloks concept from a few weeks ago. Phonebloks was the subject of our last “Ask Hackaday” article, generating hundreds of comments ranging from those defending the concept to those furiously opposed to it.
There’s a conspiracy theory circulating that suggests Motorola released the Phonebloks concept as a viral marketing scheme to generate hype before revealing the official product line. We suspect it’s a bit less conniving. As [jorde] explained on Hacker News, an Israeli startup, Modu, had developed a similar modular cell phone several years ago, and Google bought the patents in May of 2011. A few months later, Google bought something else: Motorola. It seems likely that Project Ara is merely a resurrected and revised Modu, and Motorola conveniently announced it in the wake of Phonebloks’ popularity. Regardless, Motorola has announced that they have partnered with Phonebloks’ creator Dave Hakkens .
So what’s different? Phonebloks was met with cries of “vaporware!” and fervent arguments raising concerns about unavoidable hardware limitations. Motorola claims their goal is:
to do for hardware what the Android platform has done for software: create a vibrant third-party developer ecosystem, lower the barriers to entry, increase the pace of innovation, and substantially compress development timelines.
Unlike Project Ara, Phonebloks didn’t consider open-source hardware (Wayback Machine link), and Motorola makes an interesting argument here: that advances in 3D printing indicate an evolving “open hardware ecosystem,” and the next era of phone development may rest in the hands of your average hacker or a small startup company. Some speculate that the Ara will be similar to the relationship between a PC and its peripherals: Motorola provides the essential guts while giving you some slots for attaching additional components. Let us know in the comments what you think about Project Ara: is it just more vaporware, or a watered-down but plausible alternative to Phonebloks? And, perhaps most important: do you, as a hacker, want a phone that supports open hardware and lets you plug in “peripherals?” The Phonebloks website has since changed to reflect the partnership with Motorola, and includes a new video that you can watch below.
Continue reading “Ask Hackaday: Does Project Ara Solve the Phonebloks’ Problems?”
Our tips line is on fire with suggestions for us to cover the modular cell phone concept named Phonebloks. The phone’s designer states the problem as follows:
A phone only lasts a couple of years before it breaks or becomes obsolete. Although it’s often just one part which killed it we throw everything away since it’s almost impossible to repair or upgrade.
His solution is the above pictured phone, with modular components for each feature: wifi, camera, battery, etc. Rather than upgrade your entire phone, upgrade just the parts you need. A wave of followers have thrown their support behind this concept, and perhaps their hearts are in the right place hoping to reduce waste and cost. Behind the scenes here at Hackaday, however, the response has been a unanimous facepalm. The primary objection (other than design implausibilities) should be obvious: dividing the phone into exchangeable bits does not inherently reduce waste. Those bits have to go somewhere.
Now, don’t rush to the comments section to identify additional problems; there’s a juicy Reddit thread for that. Instead, we want to take the high road: Can we do better? Can we make a phone for the future that is less wasteful to produce, more easily recycled, and possibly upgradable? What would be included in its features, and how would we do it? Check out a video of the concept phone and tell us your alternatives after the break.
Continue reading “Ask Hackaday: Can we do better than Phonebloks?”