Developed on Hackaday: First Version of the Hardware

The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the mooltipass (click to see the project description).

Next in our Developed on Hackaday series, we present the first version of our schematics. There’s already been a lot of discussions going on in our dedicated Google group, mainly about the project’s basic functionality. Because our firmware developers wanted to get to work, we decided to send the first version of our hardware into production a few days ago. Before going through the schematics, let’s review the required list of the mooltipass’s core components:

an easily-readable screen

a read-protected smart-card

large flash memory to store the encrypted passwords

an Arduino-compatible microcontroller with USB connectivity

We’ve been drowning in component suggestions from motivated hobbyists, so we figured we’d make the mooltipass v1 as simple as possible and then move from there. Given this device is developed on Hackaday, we also wanted future users to modify it, building completely new projects based around these main components. Keep reading for our schematics…

For the core of the platform, we opted for the ATmega32U4 from Atmel. It is the same microcontroller used in the Arduino Leonardo, allowing us to use the numerous libraries that have been developed for it. In the final schematics, we’ll add an expansion connector so users may connect additional peripherals (we may switch to a 4 layers PCB at this point). The microcontroller’s USB lines are protected from ESD by the IP4234CZ6 from NXP.

For encrypted passwords storage, we found the cheap 1Mbit AT45DB011D FLASH which also has 2/4/16Mbits pin compatible versions. If our beta testers find that 1Mbit is not enough, upgrading the mooltipass would be easy. A few readers may already know it, but when picking a flash memory, special attention should be paid to the minimum amount of data that can be erased in the chip. If the flash doesn’t have an internal buffer (like the one we selected does), the microcontroller must read a complete chunk of data, modify the relevant part and resend the modified chunk to the memory. Given the ATmega32U4 only has 2.5KBytes of RAM, this may have been problematic.

Finding a smart-card that could provide the desired security functions wasn’t the problem, but finding a supplier that could send us relatively low quantities (<1M) was. We did, however, find the quite old AT88SC102 from Atmel, a 1024bits read/write protected EEPROM. It can be sourced for less than a dollar and our security assessor didn’t object to this choice. It also uses an odd bus for communications (SPI-like with an open drain data line), which is why we used the N-Mosfet Q2.

A hot-topic in the Google group was the display choice. Although opinions were varied, we agreed on the core constraint that the chosen display should be at least 2.8″ and read easily under bright light. High resolution and RGB wasn’t necessarily required, so as a first try we’ve opted for the OLED display shown in the picture above (image taken from YouTube). After several weeks of looking for viable alternative OLED screens without any success, we’re currently considering making another mooltipass version with an IPS LCD. Moreover, the current unusual 3.12″ diagonal means we’ll need to have a custom-made resistive touch panel: the quotes we received for the capacitive ones were too expensive.

These components choices made the voltages electronics fairly simple. The whole solution is powered by the ~5V coming from the USB, and the ~3.3V required by both the flash and the display is provided by the ATmega32U4 internal LDO regulator (~55mA @ 3.0 to 3.6V). The +12V also needed by the display is generated by a $1 regulated charge pump DC-DC converter. If we had to use a conventional step-up, the component count (and cost) would be much higher. Notice that we put a P-MOSFET in series with the latter as the output voltage when the DC-DC is not working is not 0V but VCC (here +5V). We also used another P-MOSFET to switch the power supply going to the smart card.

We used two resistor networks R6&R7 (easier to solder) as voltage dividers to transform our 5V signals to 3.3V. Fortunately, the ATmega32U4 can receive LVTTL signals, so we don’t need level shifters to get the data coming from the 3.3v-powered flash memory.

That wraps up the mooltipass schematics overview. If you have any suggestions, you can contact the team in our dedicated Google group. Of course we’d love to hear general comments, please share them below.

I agree anonymous Vs. anonymous name calling can drag thing down. However while I would preferred thatYahoo groups or the hackaday forums had been used to create a forum I agree with the implication that discussion of details be kept at the the designated forum/group. First because good information will be scattered about multiple Hackaday articles. Second being the way comments to articles are threaded. When both are combined you will be left with a piss poor archive of the progression of the project. I understand there will be those who will balk at any requirement to register to register to follow or contribute to the project but I’m not sure why they should be allowed to dictate how others manage a project. Respectfully that’s my opinion.

The capacitance of MLCCs depends on many factors such as temperature, dc bias, ac amplitude, age, frequency and the phase of the moon. The most surprising one is DC bias, which means that you can have capacitors that are rated 25 V but only have about 5% of their capacitance at the rated voltage (e.g. CL10A106MA8NRNC). The 10 µF capacitor on the BOM is GRM21BR61C106KE15. It’s not always easy to find detailed datasheets for MLCCs, but Murata is pretty good about it and you actually get the datasheet linked from mouser (digikey only has a generic catalogue that isn’t very useful).

If you look at the DC bias curve, you’ll see that at a bias of -80% at 12 V, which specifically means that if you the voltage across the capacitor is the sum of a 12 V DC signal and a 0.5 Vrms AC signal of frequency 1 kHz, the measured capacitance is 2 µF.

Good explanation. I wish you would do a video where you go thru all those diagrams in a datasheet and just explain very detailed what it can tell about a part. Because I’m a bloody beginner and need people like you :D

Being that you only have 2.5K of SRAM available total, less after things are running due to the environment, all your graphics etc will need to be generated on the fly or loaded pre-fab from flash with no frame buffer. How graphical are you guys planning on going? With touch, graphics will be integral to the form and function of the device. Its conceivable you could use the on-board dataflash to store graphics, but you will probably need a larger part than 1 mBit if you want any room left for other stuff, especially if you use the grayscale functionality of that display!

I hope :). Current BoM price is around $28 without the touch panel ($20 for the oled… that’s why we’re still looking for other screens).
Since seeedstudio started to make 4 layers boards, we found that prices dropped quite a bit. Given the PCB shouldn’t be too big, we hope the price difference won’t be too big. I’m a bit worried about putting too many traces on the ground plane :/

Not sure about this particular controller, but be aware that most small LCD/OLED ctrls I’ve worked with supported WRITES ONLY when the serial/SPI-like interface was used. In order to get full normal R/W access to the embedded frame buffer, you’d have to use the 8-bit 8080 or 6800 parallel interfaces.

With a write-only FB you’ll need some shadowing in internal uC SRAM anyway, or always have to overwrite full bytes (e.g. two 4-bit or eight 1-bit pixels) instead of single-pixel updates.

The drawbacks of parallel i.f. are obvious: requires some 11-12 I/O-pins for the bus vs 3-4 for serial, but on the upside much higher bandwidth for display updates and often-desired R/W access to the external FB.

I know its nitpicky, but I really wish more people would attempt to compose their schematics as, well, actual schematics. This terrible style of just plopping down all the parts and then drawing little wires on each pin to merely attach a net name is about as non-schematic as possible.

That style is acceptable ff the parts in the schematic are drawn to represent their physical form, with the pins laid out in numerical order. But when the parts have been drawn logically (as they are in this schematic) then it only makes sense that the circuit should be actually drawn out, after all what was the point of re-arranging the pins in some logical manner?

The GitHub project suggested showing a QR code as an option. This is potentially insecure as some QR reader implementations send codes to third-party services to decode the QR rather than keeping everything local to a phone/device. On the other hand, there are some integrated bar code and QR readers that could work with this feature.

Okay, sounds cool. I’ve had such a thing for a while, but it’s composed of attiny2313 & 64KiB i2c EEPROM stuffed with VUSB stack, so time for a change.
I’ll be happy to help you out with a pam module.
Just one little suggestion:
Please, DO NOT make arduino libs a hardcoded dependency for your firmware code – make it just plain C, that you can later wrap into an arduino library or two for the *duino addicts out there.

With a community developed project like this, I would think it is likely that someone would try to sneak a backdoor into the development of the project. Perhaps someone (or many people) should review all code and hardware to try and spot security weaknesses hidden by community developers? Just an idea. I love the project though and wish I could contribute more at this time!