Sometimes, awesomeness passes us by and we don’t notice it until a while later. This is from 2012, but it’s so friggin’ insane we just have to cover it even if it’s late. Yuri Suzuki is an installation artist who designed the Tube Map Radio and Denki Puzzles.
The Tube Map Radio is inspired by a diagram created by the original designer of the London Tube map, Harry Beck, which shows the lines and stations of the London Underground rail network as an annotated electrical circuit. Iconic landmarks on this map are represented by components relating to their functions, including a speaker where Speaker’s Corner sits, battery representing Battersea Power Station and Piccadilly Circus marked as Piccadilly Circuit. The work was commissioned by the Design Museum London, and the PCB layout was done by Masahiko Shindo (Shindo Denki Sekkei). The idea was to bring the electronics out of the “black box” and not just display it, but to have it laid out in a fashion that people could try to understand how it really works.
The other project called Denki Puzzles is equally remarkable. It’s a kit meant to teach electronics, using a set of snap-fit components. But instead of having all “bricks” or units of the same shape, the Denki Puzzles are a collection of printed circuit board pieces whose form indicate a particular function. Fit the pieces together as a sort of physical circuit diagram and you’ll be able to build working electronics. For example, the LED unit looks like a 8 pointed star, and the resistance unit looks like a resistance symbol. Check out some pictures and a video after the break
Amateur radio is the ultimate hacker’s hobby. You can design, build, and put on the air your own high power transceivers. And with this homemade gear you are able to reach out directly, not relying on any infrastructure whatsoever, to connect with people all over the world. It is a thrilling experience to communicate with that long distance station using equipment you created, where you know at that instant what every single transistor is doing as you key down the mic.
In a previous post I described how SSB radio equipment worked and provided an example of a single-band 20m SSB transceiver. In this post I will discuss a multi-band SSB transceiver, an entire homemade amateur station including amplifiers, and conclude with software defined radio (SDR) that you can make in one weekend.
10m and 6m Dual-Band SSB
My second SSB transceiver was dual-band spanning both 6m and 10m wavelengths. I built this radio as part of the ARRL ‘home brew challenge 3′. This followed the same block diagrams as those shown in the previous post except that the two frequency bands of interest spanned one whole octave at 28 MHz and 54 MHz, resulting in additional switching and a wider bandwidth VFO.
Similar fabrication techniques were used, resulting in an old-school appearance.
Schematics and details are found in the full article in March 2013 QST, and design notes here. The interesting thing about this radio is that its VFO, power amplifier, and front-end cover all HF bands up to the VHF band 2m. This radio could quite easily be made into an all-band radio if the filters were built-out.
An Entire Station!
The most impressive home built station I’ve ever seen was by Mark Mandelkern, K5AM. Mark published details of all this gear in QEX magazine back in the late 1990s and early 2000s, with schematics, block diagrams, and more are available here.
In Mark’s Own Words
“All the gear was newly designed and built from scratch. But I was not about to reinvent the superheterodyne. Each project begins with a thorough study of the handbooks and relevant magazine articles. I glean ideas from all previous builders, to whom many thanks are due. Design means selecting and choosing the best ideas which will help produce the intended results. Individual circuits are described in the handbooks; the real design work is to combine them into a complete functioning unit. Getting a whole station built in a finite interval of time meant using mostly tried-and-true methods, and setting to work without trying to invent a new circuit for each stage.”
Others who have made their own multi and single-band SSB transceivers:
And others suggest searching on YouTube for on-air demos of some of these radios or post in the comments section.
Phasing SSB and Software Defined Radio
There are other methods to implement SSB equipment, including direct-conversion using phasing (either digital or analog). In this architecture, an I/Q image rejection mixer is used to mix up (for transmit) or down (for receive) to directly modulate or demodulate SSB signals. The back end after the IQ mixer can be implemented with either op-amps or digitization. This is one of the common architectures for early SSB transmitters and today this is the preferred architecture for entry-level software defined radio (SDR) receivers and transmitters.
Software Defined Radio (SDR)
SDR might be a great option for those of you who are more interested in building a kit or writing code instead of building a scratch-built design. In many cases the software is already written. And let’s face it, SDR is the future of radio by pushing what was previously analog circuitry into the digital domain, which trades CPU cycles for reductions in analog circuit complexity.
The best performing software-defined (or DSP) receivers use a hybrid architecture mixing the best practices of analog design with an SDR back-end (sometimes known as a ‘roofing filter‘). This provides the high-dynamic range architecture of an analog radio with the flexibility of a software defined radio. This is why the Elecraft K3 is a top performing radio (it is also available as a kit).
The only way to get started is to build something. Start small, check out the QRP community, try making a single-conversion receiver, try an entry-level SDR, and finally move up to something with a crystal IF filter. Borrow and scale circuits from books such as these:
Or leverage complete ICs and modules like those from Mini-Circuits. There is nothing like making that first long distance contact on radio gear you created from scratch.
My cousin, Juliet Hurley, MBA, MSF, MAC for type editing this post.
Author Bio Gregory L. Charvat only operates radio equipment he builds from scratch, is the author of Small and Short-Range Radar Systems, co-founder of Hyperfine Research Inc., Butterfly Network Inc. (both of which are 4catalyzer companies), visiting research scientist at Camera Culture Group Massachusetts Institute of Technology Media Lab, editor of the Gregory L. Charvat Series on Practical Approaches to Electrical Engineering, and guest commentator on CNN, CBS, Sky News, and others. He was a technical staff member at MIT Lincoln Laboratory where his work on through-wall radar won best paper at the 2010 MSS Tri-Services Radar Symposium and is an MIT Office of the Provost 2011 research highlight. He has taught short radar courses at MIT where his Build a Small Radar course was the top-ranked MIT professional education course in 2011 and has become widely adopted by other universities, laboratories, and private organizations. Starting at an Early Age, Greg developed numerous radar systems, rail SAR imaging sensors, phased-array radar systems; holds several patents; and has developed many other sensors and radio and audio equipment. He has authored numerous publications and has received press for his work. Greg earned a Ph.D in electrical engineering in 2007, an MSEE in 2003, and a BSEE in 2002 from Michigan State University, and is a senior member of the IEEE where he serves on the steering committee for the 2010, 2013, and 2016 IEEE International Symposium on Phased Array Systems and Technology and chaired the IEEE AP-S Boston Chapter from 2010-2011.
I’ve known James for roughly a year now. He is a hugely successful and experienced teacher whose opinion I have sought on regular occasions. We also seem to keep bumping into him at Computing education events like the CAS Conference, and PyconUK as well as at community events like Piwars. It seemed like we were destined to work together!
I have always enjoyed tinkering with technology and understanding exactly what’s going on under the surface. To learn more, I studied Computer Science at university, and graduated with first class honours. This enhanced my passion for the subject, and I worked at IBM for a while. I initially trained as a maths teacher, but within a term I was leading an ICT department in a middle school, and offering training to non-specialists. Most recently I worked at Soham Village College as lead teacher for Computing. I am very excited about the introduction of Computing to KS3 and 4, and enjoy testing and developing projects with students. My current interests and projects include: using Raspberry Pi in the classroom, Minecraft Pi, Sonic Pi and High Altitude Ballooning. Looking forward to working on the weather station and getting more schools involved with Pi in the sky!
As part of the Foundation’s Education Team, James will be writing educational resources for the website (especially schemes of work for teachers of KS4), as well as continuing to assist with Picademies and other outreach. James has the best case I’ve ever seen for all his Raspberry Pi bits and bobs, and as soon as I saw it I knew he would fit in around here.
Yesterday we received some figures which confirmed something we’ve suspected for a few weeks now: we’ve sold over five million Raspberry Pis.
The Pi has gone from absolutely nothing just under three years ago, to becoming the fastest-selling British computer. (We still have Sir Alan Sugar to beat on total sales numbers – if you include the PCW word processor in the figures, Amstrad sold 8 million computers between 1984 and 1997.)
We roll this picture out every time we have a sales update: this is the first batch of Raspberry Pis we ever had made, around this time three years ago. There are 2000 original Raspberry Pis in this pallet. That’s 0.04% of all the Raspberry Pis that are currently out there. (Every individual Pi in this pallet now has 2500 siblings.)
There were so few Pis in this first production run that Eben and I were able to stick them in our car and drive them to RS and Farnell’s headquarters.
Three years ago today, I was sitting at my kitchen table stuffing stickers into envelopes (we were selling them for a pound a throw to raise the money we needed to kick off the original round of manufacture). Today, I’m sitting in an office with nineteen other people, and if I’m quite honest, we’re not quite sure how we got so far so fast. It definitely feels good, though.
The ESP-01 module based on the ESP8266 is all the rage with IoT folks at the moment – and why not. For about 5 bucks, it can’t be beat on price for the features it offers. The one thing that such radios do a lot is suck power. So, it’s no surprise that ways to cut down on the juice that this device consumes is top priority for many people. [Tim] figured out a simple hardware hack to get the ESP-01 to go to deep sleep, effectively reducing its current draw to 78uA – low enough to allow battery powered deployment.
While [Tim] was working on understanding the ESP8266 tool chain (NodeMCU firmware > Lua interpreter > ESPlorer IDE), he realized that some essential pins weren’t accessible on the ESP-01 module. [Tim] built a Dev board on perf board that let him access these pins and also added some frills while at it. We’re guessing he (or someone else) will come up with a proper PCB to make things easier. But the real hack is on the ESP-01 module itself. [Tim] needed to hardwire the ‘post-sleep-reset-pin’ on the MCU to the Reset terminal. That, and also pry off the indicator LED’s with a screw driver! That sounds a bit drastic, and we’d recommend pulling out your soldering iron instead. If you’re one of the unlucky one’s to receive the “magic smoke” releasing ESP8266 modules, then you don’t need the LED anyway.
Buy a computing device nowadays, and you’re probably getting something that knows x86 or an ARM. There’s more than one architecture out there for general purpose computing with dual-core MIPS boards available and some very strange silicon that’s making its way into dev boards. lowRISC is the latest endeavour from a few notable silicon designers, able to run Linux ‘well’ and adding a few novel security features that haven’t yet been put together this way before.
There are two interesting features that make the lowRISC notable. The first is tagged memory. This has been used before in older, weirder computers as a sort of metadata for memory. Basically, a few bits of each memory address tag each memory address as executable/non-executable, serve as memory watchpoints, garbage collection, and a lock on every word. New instructions are added to the ISA, allowing these tags to be manipulated, watched, and monitored to prevent the most common single security problem: buffer overflows. It’s an extremely interesting application of tagged memory, and something that isn’t really found in a modern architecture.
The second neat feature of the lowRISC are the minions. These are programmable devices tied to the processor’s I/O that work a lot like a Zynq SOC or the PRU inside the BeagleBone. Basically, they’re used for programmable I/O, implementing SPI/I2C/I2S/SDIO in software, offloading work from the main core, and devices that require very precise timing.
The current goal of the lowRISC team is to develop the hardware on an FPGA, releasing some beta silicon in a year’s time. The first complete chip will be an embedded SOC, hopefully release sometime around late 2016 or early 2017. The ultimate goal is an SOC with a GPU that would be used in mobile phones, set-top boxes, and Raspi and BeagleBone-like dev boards. There are enough people on the team, including [Robert Mullins] and [Alex Bradbury] of the University of Cambridge and the Raspberry Pi, researchers at UC Berkeley, and [Bunnie Huang].
It’s a project still in its infancy, but the features these people are going after are very interesting, and something that just isn’t being done with other platforms.
If you’re into mechanical devices or Fourier series (or both!), you’ve got some serious YouTubing to do.
[The Engineer Guy] has posted up a series of four videos (Introduction, Synthesis, Analysis, and Operation) that demonstrate the operation and theory behind a 100-year-old machine that does Fourier analysis and synthesis with gears, cams, rocker-arms, and springs.
In Synthesis, [The Engineer Guy] explains how the machine creates an arbitrary waveform from its twenty Fourier components. In retrospect, if you’re up on your Fourier synthesis, it’s pretty obvious. Gears turn at precise ratios to each other to create the relative frequencies, and circles turning trace out sine or cosine waves easily enough. But the mechanical spring-weighted summation mechanism blew our mind, and watching the machine do its thing is mesmerizing.
In Analysis everything runs in reverse. [The Engineer Guy] sets some sample points — a square wave — into the machine and it spits out the Fourier coefficients. If you don’t have a good intuitive feel for the duality implied by Fourier analysis and synthesis, go through the video from 1:50 to 2:20 again. For good measure, [The Engineer Guy] then puts the resulting coefficient estimates back into the machine, and you get to watch a bunch of gears and springs churn out a pretty good square wave. Truly amazing.
The fact that the machine was designed by [Albert Michelson], of Michelson-Morley experiment fame, adds some star power. [The Engineer Guy] is selling a book documenting the machine, and his video about the book is probably worth your time as well. And if you still haven’t gotten enough sine-wavey goodness, watch the bonus track where he runs the machine in slow-mo: pure mechano-mathematical hotness!
A few days ago we learned chip maker FTDI was doing some rather shady things with a new driver released on Windows Update. The new driver worked perfectly for real FTDI chips, but for counterfeit chips – and there are a lot of them – the USB PID was set to 0, rendering them inoperable with any computer. Now, a few days later, we know exactly what happened, and FTDI is backing down; the driver has been removed from Windows Update, and an updated driver will be released next week. A PC won’t be able to communicate with a counterfeit chip with the new driver, but at least it won’t soft-brick the chip.
Microsoft has since released a statement and rolled back two versions of the FTDI driver to prevent counterfeit chips from being bricked. The affected versions of the FTDI driver are 2.11.0 and 2.12.0, released on August 26, 2014. The latest version of the driver that does not have this chip bricking functionality is 22.214.171.124, released on January 27th. If you’re affected by the latest driver, rolling back the driver through the Device Manager to 126.96.36.199 will prevent counterfeit chips from being bricked. You might want to find a copy of the 2.10.0 driver; this will likely be the last version of the FTDI driver to work with counterfeit chips.
Thanks to the efforts of [marcan] over on the EEVblog forums, we know exactly how the earlier FTDI driver worked to brick counterfeit devices:
[marcan] disassembled the FTDI driver and found the source of the brick and some clever coding. The coding exploits differences found in the silicon of counterfeit chips compared to the legit ones. In the small snippet of code decompiled by [marcan], the FTDI driver does nothing for legit chips, but writes 0 and value to make the EEPROM checksum match to counterfeit chips. It’s an extremely clever bit of code, but also clear evidence FTDI is intentionally bricking counterfeit devices.
A new FTDI driver, presumably one that will tell you a chip is fake without bricking it, will be released next week. While not an ideal outcome for everyone, at least the problem of drivers intentionally bricking devices is behind us.
The FTDI FT232 chip is found in thousands of electronic baubles, from Arduinos to test equipment, and more than a few bits of consumer electronics. It’s a simple chip, converting USB to a serial port, but very useful and probably one of the most cloned pieces of silicon on Earth. Thanks to a recent Windows update, all those fake FTDI chips are at risk of being bricked. This isn’t a case where fake FTDI chips won’t work if plugged into a machine running the newest FTDI driver; the latest driver bricks the fake chips, rendering them inoperable with any computer.
Reports of problems with FTDI chips surfaced early this month, with an explanation of the behavior showing up in an EEVblog forum thread. The new driver for these chips from FTDI, delivered through a recent Windows update, reprograms the USB PID to 0, something Windows, Linux, and OS X don’t like. This renders the chip inaccessible from any OS, effectively bricking any device that happens to have one of these fake FTDI serial chips.
Because the FTDI USB to UART chip is so incredibly common, the market is flooded with clones and counterfeits. it’s very hard to tell the difference between the real and fake versions by looking at the package, but a look at the silicon reveals vast differences. The new driver for the FT232 exploits these differences, reprogramming it so it won’t work with existing drivers. It’s a bold strategy to cut down on silicon counterfeiters on the part of FTDI. A reasonable company would go after the manufacturers of fake chips, not the consumers who are most likely unaware they have a fake chip.
The workaround for this driver update is to download the FT232 config tool from the FTDI website on a WinXP or Linux box, change the PID of the fake chip, and never using the new driver on a modern Windows system. There will surely be an automated tool to fix these chips automatically, but until then, take a good look at what Windows Update is installing – it’s very hard to tell if your devices have a fake FTDI chip by just looking at them.
At the start of September, a film crew from CNBC came to visit Cambridge. They spent some time with us at Pi Towers, and came to the Cambridge Jam the next day to talk to some of the kids there who use the Raspberry Pi. They produced two short videos, both full of footage from the Jam and our office – see how many familiar faces you can spot!
In the two years since we launched the current Raspberry Pi Model B, we’ve often talked about our intention to do one more hardware revision to incorporate the numerous small improvements people have been asking for. This isn’t a “Raspberry Pi 2″, but rather the final evolution of the original Raspberry Pi. Today, I’m very pleased to be able to announce the immediate availability, at $35 – it’s still the same price, of what we’re calling the Raspberry Pi Model B+.
You’re a handsome devil. What’s your name? (Click to enlarge!)
The Model B+ uses the same BCM2835 application processor as the Model B. It runs the same software, and still has 512MB RAM; but James and the team have made the following key improvements:
More GPIO. The GPIO header has grown to 40 pins, while retaining the same pinout for the first 26 pins as the Model B.
More USB. We now have 4 USB 2.0 ports, compared to 2 on the Model B, and better hotplug and overcurrent behaviour.
Micro SD. The old friction-fit SD card socket has been replaced with a much nicer push-push micro SD version.
Lower power consumption. By replacing linear regulators with switching ones we’ve reduced power consumption by between 0.5W and 1W.
Better audio. The audio circuit incorporates a dedicated low-noise power supply.
Neater form factor. We’ve aligned the USB connectors with the board edge, moved composite video onto the 3.5mm jack, and added four squarely-placed mounting holes.
If you’re interested in precise measurements, or want to find out what the new GPIO does, check out the diagrams below.
Mechanical specs: you’ll want to look at these if you’re building cases or other housing. Click to enlarge.
GPIO diagram – there’s a lot more to play with now! Click to enlarge.
We think you’re going to love Model B+, but to ensure continuity of supply for our industrial customers we’ll be keeping Model B in production for as long as there’s demand for it.
It has been a while since we kept you informed about the current state of the Mooltipass project. Well, several days ago we finally received the PCBs we got produced at Seeedstudio. Keep in mind that this first version (shown in the picture above) is only meant to check that the chosen components can suit our needs while our mechanical contributors work on their designs. Moreover, we may add empty footprints for our readers that may want to hack the device.
After a few hours of soldering and a few days of coding, we finally got a basic firmware running. The OLED screen is easily readable and has an amazing contrast (the picture doesn’t do it justice). So far we checked all basic functionalities of the on-board components and it’ll still take a few days/weeks to be certain that we can settle with them. We are therefore starting to ship a few platforms to the firmware developers that want to work on the core functions of the Mooltipass. So if you’re an experienced C developer and have some spare time, you may get onboard by contacting me at mathieu[at]hackaday[dot]com or by joining the Mooltipass Google Group.
In a few days we will publish the designs that our mechanical guys came up with and we’ll ask you to let us know which ones are your favorites. Depending on how things will go, we may produce PCBs for several of them to select our final design based on user experience and ease of use. We look forward to hearing your feedback in the comments section below!
Carrie Anne wasn’t our only new starter on Monday: we’ve also welcomed Dave Honess to the team. Dave will be familiar to many of you as Davespice from our forums, where he’s one of our moderators; he’s also been helping me moderate the comments on this blog for a year or so now, and he’s a mod on the Freenode #raspberrypi IRC channel. Dave writes for The MagPi (as Davespice), and he’s behind the porting and uploading of lots of the retro games you’ll see at the Pi Store. Here he is in situ at Pi Towers.
Dave’s an archaeologist by training, as well as a software developer; he’s also been working with the Pi as a private tutor, and he’s a STEM Ambassador. He’s joining us to work on a mixture of project management (fortunately for Dave, that’s much more exciting than it sounds), creating educational resources, outreach, and polishing the educational software stack. We’re extremely glad to have him, and we’re running out of desks.
Back in 2011 one of my old work colleagues brought in an old Spectrum BASIC book, and we had a discussion about how great that era of programming was. We then flipped to the back, found Frogger, and tried to type it into an emulator; we were rusty. Not long after that I found the first blog post about the Raspberry Pi at the BBC by Rory Cellan Jones. I remember thinking it was going to be massive back then, and signed up to the website soon after. I’m glad to say I was right – it has been massive – and I am very happy and excited to have landed a job here. I am going to be working on creating educational materials for the Raspberry Pi and helping with various outreach projects the foundation is working on.
A few of you will know me from IRC and the forums, but for those of you who don’t, you can have a quick glance at my original Introduce Yourself post from when I joined the community here.
Dave is very unfortunate, because he’s ended up sitting next to me. We commiserate about the seating plan and congratulate you on your new job, Dave – welcome on board!
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.
We’re pretty sure that most of our readers already know it by now, but we’ll tell you anyway: the Hackaday community (writers and readers) is currently developing an offline password keeper. In the first post of our first DoH series, we introduced the project and called for contributors. In the comments section, we received very interesting feedback as well as many feature suggestions that we detailed in our second write-up. Finally, we organized a poll that allowed everyone to vote on the project’s name.
The results came in: the project’s name will be mooltipass. We originally had thought of ‘multipass’ but [asheets] informed us that Apple and Canon had both applied for this trademark. [Omegacs] then suggested ‘mooltipass’ as an alternative, which we loved even more. A few days ago we set up a google group which is already very active.
An often under-estimated side of a community driven project is its infrastructure and management. (How) can you manage dozens of motivated individuals from all over the globe to work on a common project? How can you keep the community informed of its latest developments?
As the Hackaday community is very comfortable with online tools, we chose:
github to disseminate the mooltipass resources to the public, and for firmware/software development as well
dropbox to share quickly-changing mechanical design files
trello to discuss specific topics and relate our current progress
google groups for general discussion
Github was the obvious choice given that it is one of the most used online repositories out there. It allows contributors to keep track of the file changes and ensures they have the latest version of the mooltipass project. Given the mechanical development process is quite different from developing firmware, contributors in charge of the case design opted for Dropbox. Here is an overview of the Trello board we setup:
Trello was suggested by [Zach] (thanks!). It is free, very easy to understand and convenient for project management (from what we can see at the moment). We took the habit of having our development related discussions in a dedicated mailing list, then move the specific points to Trello.
Unfortunately the firmware guys have still to wait for the first prototypes to arrive to start coding. Next week on Hackaday we’ll detail the first version of the hardware, currently being reviewed in our google group. Depending on the feedback we get, the v2 may be very different. It’s still not too late if you want to get involved in the project (if you aren’t a firmware developer!), so you can contact us at mathieu[at]hackaday[dot]com.