It all started when in search for a unique design twist almost three years ago I experimented with embedding through-hole components inside of the PCB itself. Researching this, I found that other than the slots that sometimes cost extra, there's nothing preventing me from achieving this with a standard manufacturing process. I then made the "engineer's emergency business card", which got a very positive response [Hackaday | HackerNews].
This response led me to create my first ever kit, "the tiny 'engineer superhero' emergency kit, first edition", spiced up with a tale of where an engineer might use it
It's meant to be an engineer's emergency kit. When all hope is lost, the MacGuyver engineer could snap out one of the components and save the day. Recall the countless times you desperately needed a 1 KOhm resistor to fix an amplifier at a party, only to see the person you were trying to impress slip away with an OCaml programmer? Never again with this little kit.
It's a functional circuit. When you apply voltage the LED turns on, and the solder wire bit is part of this circuit.
Another new 'thing' was gently laser etching a compressed cellulose sponge so that when wet expands to fit the tin the kit arrives in and can be used to clean a soldering iron as one is soldering.
This kit is special because — other than the in-circuit components, visuals, and sponge — it's the kit through which I learned a lot about kitting and selling kits. I felt that it would be great to send members of the Boldport Club the second edition of this kit, and in this way share this first experience that eventually led me to start the Club.
This 'second edition' comes in a black tin can and has new two-tone visuals. Next week I'll be sending these kits to Club members, and all of those who joined the Club by the cut-off date of April 9th will receive a second one as a gift for their support! Sign up here.
The sponges for this kit were supplied by our friends at Oomlout — who are also enthusiastic members and supporters of the Boldport Club. The PCBs were manufactured by Eurocircuits. And, as usual, the design is open source hardware, and is available at our GitHub repository. A full album of the kit is here.
The Boldport Club — a monthly subscription to electronics projects — has been very well received. We now have over 85 members, even before we shipped our first project! We're getting ready for delivering our first project to members: a tribute to Bob Pease and an electronics discovery kit based on his LM331 chip.
Bob Pease was an analogue design expert and technical writer of legendary status. He had the unique ability to communicate very technical topics in a relatable style, character, and authority, and thus becoming an educator to generations of engineers. One of Pease's most memorable sayings was 'My favorite programming language is... solder', which captures so much of our love for electronics and creating things with our minds and hands.
A couple of years ago, I designed a tribute to Pease, which was one of the first boards that I've created with PCBmodE. I've not sold the board widely — I only made 50 and most of them I gave away — but it was always a board that got attention. When I considered which of my designs should be the first to be sent to Boldport Club members, it had to be this one.
The schematic for the circuit is drawn on the back of the board for easy reference, and either through-hole or surface-mount components can be used (the kit only contains through-hole components, though).
It's a 'discovery kit' since you should figure out how to tweak the values of the components to do different things. You may need to use different components, and you're likely want to consult the datasheet for how the chip works. Maybe even connect it to a scope! Power can be applied through the USB connector or through the holes on the other side. There's even a handy ruler, and a keyring if you want to carry the board with you.
So here's the deal: we're shipping this project to members of the Boldport Club at the beginning of March. If you're not a member by then you won't get this project, as we don't repeat projects or send new members old projects (members can still buy old stock while it lasts, though). We're building a limited amount of this special project, so we suggest that you hurry :)
A quick update.
Boldport Club accepts memberships
After a few months of planning, we've opened the Boldport Club for people to join as members. For £49 you'll get three projects of our making; you know, the good stuff that we've been making for a while. We're very excited about the potential of the Club, and we hope that you'll join us, along with your friends and relatives ;)
Towards the end of November we released a new version of our website at http://boldport.com. We've got a new logo, and a better message. Please explore the website, and send anyone who could use 'electronics craftsmanship' our way.
PCBmodE version 4.0
PCBmodE is our own (open source software) circuit design tool with which we design all of our boards. Over the past few months we've implemented new features — most notably, support for multiple layers — and improved usability. Several boards at the repository are compatible with the new version and are a great place to start with the software.
FOSDEM (Free and Open Source Software Developers' European Meeting) is a large, free, gathering for open source software developers, happening next weekend in Brussels. I'll be speaking at the eda-devroom twice; once about PCBmodE and another about the future of EDA. If you'll be at FOSDEM, make sure to let me know and we'll arrange to meet.
Finally, the office move
Our place off of Borough High Street was great, but we needed more space. After a few weeks of searching, I've found what I think will be a great place to work from. It's at the Arch Collective, along-side a laser-cutting and model-making businesses. We're moving in tomorrow, and I'm looking forward to working at the new space. Feel free to come by and say hello!
It was a privilege and a pleasure to work with Mitch Feinberg, an accomplished still-life photographer with a long record of amazing work. Marie Claire US magazine commissioned photographs of luxury jewellery — Tiffany, Chopard, Bulgari, Cartier, Yurman, and Harry Winston — from Mitch.
Mitch conceived the idea of having large bespoke circuitboard designs as the backdrop for the jewellery, and a Web search led him to Boldport and me. It was serendipitous; the old Boldport website was not explicit about us doing this kind of work, but Mitch was acute at sensing that this is the exact kind of work I wanted to attract! Our custom tool, PCBmodE, allows us to achieve the visuals and designs like no other tool can, and we were just the right company for the job.
The six photographs below are the ones taken by Mitch and belong to himself and Marie Claire magazine. They cannot be used without their permission. Unfortunately, the Bulgari piece — my personal favourite! — did not make it to print.
Below are photographs that I took of the boards and of the magazine. Please ask for permission before use elsewhere. A full gallery of images is here.
The circuitboard designs were inspired by the jewellery piece that would be placed on them. It was an enjoyable creative process. Finally, some of the boards have LEDs. These are SMD LEDs that poke through a hole in the board. Their intensity is controlled by a potentiometer and power is supplied via a microUSB port.
And finally, my credit! :)
EDIT: A couple of my prototype sketches
If you haven't yet used a consumer-grade desktop '3D printer' you might still be under the illusion that they are going to 'change the world' as the hype used to promise. Someone once remarked to me about the dynamics of a hackerspace, "they come for the 3D printer but stay for the laser cutter". I certainly did, after fighting with the 3D printer that produced inconsistent, and poor, results, no matter how much effort I put into it. The next time I wanted the wonder of 3D printers I designed a model with OpenSCAD and sent it off to Shapeways and got my item in three different materials a week later. I saved a ton of faffing time, and money, that way. Then, if I wanted twenty, they would be the same quality and shape, and someone will be there to answer if they are not.
So on the heels of that hype arrived a slew of '3D' desktop circuit boards printers — Voxel8, Argentum, and Voltera to name some — which promise the same but for circuitry. The advantages, they say, are faster iteration of prototypes, extended material possibilities, and mechanical construction that isn't otherwise available.
It's easy and natural to get excited about these prospects. But there is only one case I can think of that a consumer-grade '3D' circuit printer justifies its cost: a hackerspace. Other than there, these machines are near useless.
How does a circuit bring-up work? We research the technologies and ICs that we may use. We'll read the datasheets and order evaluation and development kits to play with. If the circuit is simple we'll wire it up with a breadboard, cables, or an Arduino. There's no need for a custom circuit board at this stage. If the circuit is more complex, we'll need a board that can meet our needs -- this may be a 2-or-more-layer board with plated vias or a controlled impedance board with 0.5mm pitch devices. Crucially — and this is what those who promote these devices fail to mention — we want the prototype boards to be the same technology that your production unit. Otherwise, we may be doubling our work and spend more money.
"But you'll have to wait a week for the board to arrive!" It's called 'planning'. If an engineer cannot plan their project to fill their time between sending the boards out and waiting for them to arrive, then something's already wrong. There is so much more to do in a project to fill that time up. Save the two grand you'll spend on a printer you'd use twice for a 'quick-turn emergency fund'. Besides, PCB manufacturers are not sitting idle in the face of demand for quicker turns; most offer a day turn, and that should be good enough for prototypes in a bind. Or, find a local PCB manufacturer and save yourself some shipping time and money.
As for materials, I personally have worked with 'exotic' circuit materials that are production ready and well characterised. Even if I could produce novelty items with one of those printers that would look good on Twitter, how would I scale? How would I make them robust? I couldn't unless I re-do it with a different technology and have to go through a new learning process. As for new 'paradigm changing' constructions, I still haven't seen an example for this that isn't contrived.
In conclusion I'll say that these consumer-grade desktop circuit printers could have a loving home at hackerspaces for educational and fun one-off projects. But please don't buy into the hype that they are all that useful elsewhere.
You'd use two current-limiting resistors per LED as legs, rolled up wire or component leads as antennae, and ordinary or blinking 3/5/10mm LEDs for show. The back side has a CR2032 battery holder for power. The hardwear.io folks have manufactured the badges and my understanding is that they were well received.
I adapted the design for my own, and manufactured a few as well.
There are two 'solder-blob' jumpers that allow powering the buggy through the eyes (instead of from the battery, never both), which can also function as holes for attaching to a lanyard or worn as a necklace ;)
As usual, this board is open source hardware. Get the latest version of the board at the Boldport repo.
Until next time, 'buggy' says farewell
The 'Skarp Lazer Razor' has so far raised over $3.5 million on Kickstarter and still has twelve days to go. Its creators, the 'Skarpers', make claims about the development of a laser-based 'razor' that gives an irritation-free shave better and faster than a traditional razor; it's also, they claim, more environment friendly. To achieve the claimed properties of the product its creators must have overcome significant challenges in optics, miniaturisation, eye and skin safety, power, usability, etc.
The extraordinary claims made by the creators of Skarp are not backed by the extraordinary evidence they, and backers, deserve. What's presented to us as proof is a rendered animation, 3D printed handles, and a 'demo' that only raises more questions and doubt about the current state of the product
From all that I've seen so far the Skarpers have created a proof-of-concept that's equivalent -- in context of the challenges -- to wiring something on a breadboard. Oh, and they've obviously worked very hard on those lovely 3D printed handles!
To the criticism of technical feasibility, the Skarpers have argued that backers should rely on their and their advisors' reputation and background -- after all they are "men of science". For the lack of technical transparency, the Skarpers claim that they would lose their "advantage" if they reveal any further details.
In a critical view, neither of these arguments matter. Experts can be wrong or misled into endorsement and founders are often blind to obvious problems, and prone to wishful thinking. If there's concerns about intellectual property, they should have waited until they are covered, or found a way to demo without revealing too much. I also think that if one is sitting on such a proven, patent protected, revolution in technology, Kickstarter is an odd place to pander for cash in the first instance.
The arguments the Skarpers use here are, however, very effective as they both hide the project's real state and sound convincing to an non-critical audience.
The odd 18,000 backers are clearly non-critical. You don't need to be a laser engineer to know that there's an extreme, at best, wishful thinking here -- a delivery of such a complex product in six months (March 2016) is delusional. It cannot happen and it will not happen. This is particularly bothersome when the Skarpers say that
So they are either competent but intentionally misleading or they're incompetent. Either way it's a sure sign to walk away. I wasn't swayed by looking at the Skarpers' LinkedIn profiles either.
Reality demonstrated clearly that the majority of backers don't care about any of it. They want this fantasy product even if they never get it. Some are quite OK with that -- read the comments. So if the lottery is a tax on those poor at math, then Kickstarter is a tax on people who can't be bothered by the details. What's the harm?
The harm is for the rest of us! When this project fails to deliver -- at all or the Skarpers send out a brittle wire on a fancy handle that lasts three seconds -- it's us, the hardware developers that care about our craft, that ultimately pay the price. We'll be collectively and proverbially shat upon by the same "tech" media that blindly gave wind to that project. We'll be perceived as 'those engineers' who over-promise and under-deliver. This infuriates me.
We need to accept that Kickstarter has evolved into a lucrative scamming platform: a mechanism designed for little accountability and enforcement filled with a gullible audience with disposable income. Kickstarter is now damaging the reputation of 'hardware' far more than any of the good that it might have done in the past. I think that we've reached peak-Kickstarter, the point where the 'classic' crowdfunding funding model has 'jumped the Skarp', in a similar way that Fonzie jumped the shark for TV.
(Amusingly, I still hold some hope that this is a brilliantly executed social experiment, though I would find it hard to believe that it passed an ethical review board.)
In January 2014 I explained why I wouldn't be using the Open Source Hardware Logo on my boards in the future. Since then, unless a client wanted it on there, I ditched it completely.
If I recall, I got the impression at the time that people thought that I was a crank for having that opinion, but in light of the recent "Open Source Hardware Certification" initiative by the Open Source Hardware Association, I know that I was right to distance myself from being associated with that brand.
I feel that the "certification" proposal is misguided and pointless on many levels, and I find it hard to reconcile how otherwise well-meaning people have not realised this and scrapped the notion at conception.
Let's have a look. The proposal lists its primary goals
I assume that the 'public' are those who are not within the small community of people who already know how to check if a product is genuinely open source. I think that the OSHWA fails to appreciate two things here. Firstly, that the 'public' doesn't really care; it's nearly always the vocal voices within the OSHW community who complain -- rightfully on most accounts -- about the mislabelling and abuse of their view of OSHW. Secondly, that it is nearly impossible to educate the 'public' for brand awareness without massive amounts of money, particularly given the first point.
So, ultimately, there's no demand and no means for "certification".
This should be obvious, but you join the community simply by creating open-source hardware, not by being "certified" by self-proclaimed guardians of the practice, OSHWA or whoever else. I can't see any of this making it 'easier' anyway, quite the opposite -- any practical person would just not bother.
Since the basis of this initiative is flawed, the rest of the arguments in the proposal fall apart. But the OSHWA takes it a step further by assuming the role of an OSHW enforcer.
(This sound more like checking into a Big-Brother establishment for life than to the luxury beach hotel this concept is made out to seem.)
The expectation is that for apparently little practical benefit one would voluntarily submit to fines being levied on them if someone decided that they do not comply with their rules. Again, there are two problems here. Firstly, no reasonable person would accept these terms without a significant benefit (USB and BTLE certification, for example, actually provides a crucial technology -- there are no parallels here). Secondly, there is no practical way to enforce these fines worldwide. So the scheme will either fail because no one would buy into it, or fail because there will be no way to prevent abuse of the brand.
There's no doubt in my mind that the people behind these ideas mean well. I feel, however, that the motivation is less to do with concern for the 'community' and 'public' and more to do with reconciling the individual enthusiasm for open source hardware with the reality of people <del>benefiting</del> profiting commercially from your own work, which was given away gratis. It's a rotten feeling when that happens, but that's part of the deal. The licence is the license. If the realities of the license chosen are unbearable, then a different license should be used, or a different business/benefit-model be used. One can't both claim OSHW and then be picky about how it's being used.
OK, so I've let off some steam. Here's what I recommend for the OSHWA to actually do with the energy and enthusiasm they have after scrapping this certification idea. Create a place where the 'public' and 'community' can be easily educated about the signs of a genuine OSHW project, and its benefits. Provide a service for crowdfunding platforms and companies -- maybe even charge a fee -- for producing a report on products' 'openness'. Take the role of educators and enablers -- rather than be the 'enforcers' of 'compliance' violations by 'bad actors' -- and gain authority that way instead.
Jeremy intended for the board to be used to teach children and teenagers how to solder, and in doing so get them interested in electronics, hardware, software, and, eventually, optimising compilers. (This is a joke -- Jeremy's Embecosm is a leader in compiler optimisation.)
One is able to teach soldering on a single-sided board in a baggy from Maplin, but that won't be too engaging. There has to be more, something memorable and perhaps something familiar. It also has to be somewhat useful and playful so that it won't be thrown in a drawer and quickly forgotten.
My first set of concept designs resembled aliens and game-controllers -- engaging and familiar. Fairly early on I decided to use infrared transmit and receive as the primary interaction mechanism. This served two of the goals: it's cheap and can be easily explained using simple diagrams. Kids feel very comfortable with the concept of 'wireless' and so IR is one of the simplest ways to explain one of the many ways of 'wireless' communication. It is also relatively easy to follow code that controls the IR transmit and receive for those who want to dig in deeper. Generally, it's important to have people get a sense of achievement very early on, or they quickly lose interest.
I presented these concepts to Jeremy and we eventually decided that it's best to continue the ocean-themed designs (Shrimp, cuttlefish, etc.) I was tasked to find an ocean creature that has the right cartoonish shape to accommodate the physical requirements -- coin-cell battery and the long DIP package of the microntroller. After lots of image searches, I arrived to this concept design
250 of these lovely boards arrived yesterday, and were manufactured by Eurocircuits
The two small break-out boards house an LED and resistor in series, each. Those can be regular or IR LEDs, and the idea is for them to be used for playing with others, creating unique IR transmit patterns and communicating with other boards that are around in line-of-sight.
There are three holes for attaching the board to a garment or something else. All the micro's pins are broken out to headers so that several other 'peripherals' can be attached to the board.
Placing the battery holder on the top allows the circuit board to be flat on the bottom and more convenient as a 'wearable'. Using my solder-dome technique, you can get rid of those pointy solder joints that would stick to clothing.
In terms of the circuit design, there were a few challenges. The board was to be programmed using a 6-pin serial adaptor, which can supply 5V to the board. Since the 'seahorse' is normally battery-powered, this is problematic -- you don't ever want to have both power rails be connected at the same time. An additional problem was that a coin cell only provides 3V, not high enough for running the ATmega328 at 16MHz, which is the Arduino standard.
For cost reasons we chose to use two thin CR2016 stacked into a CR2032 battery holder. This gives us 6V, which we dropped to ~5V using a diode -- a component that was already in the design elsewhere. The 5V from the programmer is 'jumperable' using a fishy solder-blob jumper.
The current capacity of the CR2016 isn't that high, and the board won't run too long on two of them -- particularly with the LEDs on -- but we concluded that it's 'good enough'. A possible alternative is to use a battery holder that can house two CR2032 batteries.
All the headers' holes are staggered, so that pin headers can be plugged and unplugged without soldering them to the board. This is particularly convenient for programming, so you don't need to have the header there during normal operation. The holes can be used for attaching conductive thread, although care must be taken not to short the contacts -- again, this was a usability/functionality compromise -- other 'wearables', like the Lilypad, have large separated pads to avoid this problem.
Other than discussing hardware product-design, I found myself proposing to prospective clients an additional (or alternative) way for working together. This turned out to be quite popular.
At the time of contact, clients are usually looking for someone to realise their ideas, seek authoritative advice and guidance, or take their prototypes to the 'next level'. It's at that moment in the project where an 'architecture definition' is a crucial document to have, and I offer to help them create it.
I first ask clients to tell me what they want to achieve. I explicitly ask them to leave out how they think it could be achieved since that is -- potentially and hopefully -- my job. That's what the architecture definition document starts out with. It sets the tone without burdening the imagination with technicalities, freeing us to be creative with solutions. It's the framing shot.
We then work on an architectural diagram that encapsulates the interaction of all components of the system at a high-level. We also define all entities, along with their capabilities, purpose, and needs. Confusingly, we want to be specific and generic at the same time. For example, we might not know whether we'll use ZigBee or Bluetooth Low Energy (BTLE) at this point, so we might call that communication channel 'short range channel' or 'low power channel' -- this allows us to be flexible later on where we actually spec that comms channel. We may not know if the device is battery- or USB-powered, so we'll just say 'power source'.
This part of the document is important since here we give the reader -- and ourselves -- an overview of the system to come back to as a reference. This bit occasionally changes as the document fleshes out, but not by too much -- this is the foundation of the project, and changes here have a cascading impact on the rest of the document.
The next phase is dynamic and interactive. Here we spell out the possible ways for achieving the goals and functionality of the project. We might consider, for example, GSM as a communication channel, but indicate that this has power and connectivity implications. We may consider BTLE but note that bandwidth is very limited. We'll also discuss user-interface elements, such as the merits of a mechanical push-button versus a capacitive touch solution. We'll point out the merits of using a pre-packaged module compared to a complete OEM solution compared to the costs of a custom PCB. And what about certification?
This section changes a lot in the course of writing the document: what used to be an option may be stricken out because of a limitation, or cost. Or, a few positive considerations may tip over a solution to be the one that's the favourite. It's typical to have quite a few ping-pong rounds of edits between us and the client for this section.
In the process, many questions that must be -- at the least -- addressed invariably surface. These questions can be pretty tough for the client to answer. How do you choose, for example, between a non-replaceable rechargeable Li-Ion battery in an ultrasonically sealed case versus two replaceable AA batteries with their associated complexities of usability and an opening in the casework. We don't have to have the answers, but at least the questions and considerations are there. It can be overwhelming, but it's definitely good to have given these considerations a thought before the product has already been mostly designed!
At the the end we get a thought-out document that teased out a lot of detail. The client is now armed with a document that can be shown to an investor or design consultancy for a quotation. It empowers the client in future interactions about their product and allows the other party to quickly understand the project's goals and requirements.
most importantly, we found that the investment of time early on to create such a document saves a much more time later on the project!
Now, why would you hire Boldport for this job?
We bring a wealth of knowledge and experience to the process, and are able to advise and contribute way beyond the technical details. Other than experience in many technologies -- FPGAs, microcontrollers, BTLE, web, software development, manufacturing -- we're competent at advising on the security and privacy implications of your product. In authoring the architecture definition we also, of course, factor in cost, manufacturability, and usability considerations.
We work as if we're not the ones who are going to design the system -- and we may well not be. What you end up getting is different compared to what you'll get in a 'project proposal' from other consultancies, where they are naturally biased towards the solutions that they are already most familiar with. Those proposed technologies may not be the best for your product! We'll give you a document that you can take to these consultancies and have them justify why their solution may be better, instead of just taking their recommendations at face value.
Finally, we strive to give you value for your money. It's a great way to get to know us and how we work towards the success of your product. Writing a document like I described above typically takesone to three days. You'll get the document, of course, but also the benefit of knowing if we're the right choice for continuing to design your product. Also, be certain that if we feel that we do not have the expertise for completing your project in the best way possible, we'll tell you.
Finally, here's what Alex Nicholson from Sustainable Venture Development Partners said about a recent architecture definition project we've completed together
We engaged Boldport to support us with product development and to help us develop a technical specification. I was struck most by the creativity that went into the production of the specification, with nothing taken for granted. This, combined with punctuality in its delivery, made it a rewarding experience to work with Boldport. I hope to continue working with them in the future.
There are more testimonials here.
Please do get in touch if you think that an 'architecture definition document' could be useful to you.
The good folk of Open Bidouille Camp reached out to me a few months ago and asked if I could design a small badge for their workshops, as a tool for teaching people how to solder. As I usually do, I asked for a logo or some other material that I could use for inspiration as a starting point for a concept.
This is a two-tone design (white and light-blue above) on a dark background. That could be easily translated to a circuit-board. The OBC people preferred black soldermask, so that was a given design choice.
I decided to leave as much as I can as it is and to use the hexagons as a common theme: the outline (of course), LED pads, and battery holder pads.
But there's a more ominous way to assemble the board!
You might have been wondering why I created the crossbones gap in soldermask on the bottom side of the board. Scroll down. Carefully ;)
Now, with the battery holder facing down, we solder the LEDs and resistors on the bottom of the board.
Here's what it looks like from the front. Pretty tame.
WHOA. He's out to get you! HAR HAR.
This was a fun project, and shows what can be achieved with just a few components and a bit of thought into the design.
All our boards are designed using PCBmodE, an open source software we developed to create 'beautifully functional circuits' such as this OBC badge. The design itself is open source hardware, and can be found at Boldport's Github repository.
If you need a beautifully functional circuit designed, that's our speciality, so get in touch!
Someone over at the Electrical Engineering Stack Exchange asked about potential issues with 'via-in-pad' -- a via placed, well, in a pad. The advice is comprehensive, and the usual rule applies -- it's fine when you know what you're doing and willing to pay for the "extravagance".
I chimed in with advice I got from a senior engineer looking over my shoulder whilst I was laying out a fairly complex board: place vias in pads for mechanical SMD interface components. Doing this adds strength on the z-axis of the board for otherwise easy to lift connectors. Take, for example, an SMD USB connector and the torque that applies from the cable casing; you could use all the strengthening you can get to prevent that sucker from lifting off the board with your tracks! It won't be enough for production -- for that you'd need something else to keep a connector in place or use a throughole connector, or both -- but it's great for kits, etc.
If I have space on the bottom layer I'd either just use a standard via, replicate the pad, or even oversize it on the bottom layer. I also try my best to have the same amount of vias in all pads so that they won't tombstone or create uneven connections. If you're going to use via fasteners and not solder by hand, you'll have to factor the vias into account since they may create an uneven pad, and will syphon out the paste, so you may need to add more.
I called these things 'via fasteners' since 'via rivets' was already "taken". Does this technique have a more established name? Searching for answers I found another StackExchange question about this same technique! More good advice and precautions there.
Yesterday I've received the third edition of The Art of Electronics by Horowitz and Hill -- or 'the bible' for short. I've been drooling over it for hours; as an engineer it's the closest feeling to your favourite band releasing a new album. H&H are the engineering world's rock stars going on a triumphant world tour.
Going through the book I came across one of my favourite tiny logic circuits, the 'edge detect' (or 'single-pulse generator'), where a pulse the length of a single clock period is generated from an asynchronous, other clock domain, or possible 'noisy', source into a synchronous circuit. For FPGA design, I often use a similar circuit to debounce external inputs or for modules that expect a single pulse input signal -- reset, START, etc. -- and I'm uncertain that they will be. Below is H&H's version in Figure 10.75 (which immediately "offended" my FPGA-centric view... more on that later ;):
I'm certain that H&H had good reason to draw the circuit like they did, but I prefer to do away with the double inversion on the feedback.
We have two edge-triggered flip-flops, the second clocked by the synchronous clock and the other by the input signal (!) The output controls the reset input of the first flip-flop.
H&H challenge the reader to create a timing diagram
Note that even though it's not specified, the reset must be asynchronous, otherwise the circuit won't work. We could end it here, but I'm pretty sure that H&H were trying to tease out more insight from the reader.
Consider what happens at power-up when the state of the flip-flops are unknown (remember those pesky red 'unknown state' during behavioural simulation?) H&H say that this circuit is glitch-free. It is. But, we could get an unwanted pulse if the first flip-flop starts out in a high state and the second in low state (see right side of diagram above). This may or may not affect the functionality of your circuit; that depends on what it's 'driving'. This could keep you debugging your apparently random-failing circuit for days in the lab. What other potential issues did I miss?
Now, why was I "offended"? As an experienced FPGA designer, seeing a non-clock signal going to a clock input feels like a punch to the stomach (as it should!). It's a major no-no unless you really know what you're doing. This is because clocking resources are 'special' and are carefully crafted to deliver synchronous clock-edges to the entire 'clock tree' at the same time. They're not meant to be used for 'ordinary' signals -- 'local routing' exist for those -- even though it's possible to arm-twist the tools to do it. Implementing H&H's circuit as-is would generate a warning, or physical-synthesis would deal with it by 'understanding' what you 'mean' and re-jig the circuit to do the right thing, or re-route the input as a clock signal wasting a valuable resource. These outcomes are bad, bad, bad since the designer seems to get away with it and think that this practice is 'ok'. Besides, different tools would interpret the 'meaning' differently so you would be really pushing your luck with non-portable code, even between versions of the same tool. The tools should, ideally, produce an error and halt unless the designer presents a notarised note from a Registered Guru, such as Dave Vandenbout.
Here's the circuit I've been using for forever
Luckily, most FPGAs have a deterministic start-up state ('low' unless otherwise explicitly specified) so the unwanted start-up pulse won't happen. The asynchronous input signal still needs to be longer than the clock period to guarantee that it'd get caught (H&H's circuit has the advantage of not suffering from this problem). Here's the timing diagram
and one possible Verilog implementation
// edge detect module module edge_detect( input CLK, input RST, input IN, output OUT ); reg a, b; // the edge detect signal is (b AND (NOT a)) assign OUT = a & !b; always @(posedge CLK) begin // It's always good to have a reset condition, otherwise // the state of the register will show up as undertemined // in simulation ('x') if (RST == 1'b1) begin a <= 0; b <= 0; end else begin a <= IN; b <= a; end end endmodule
Please add your thoughts in the comments!
UPDATE 2015-04-08: Thanks to 'Lampshader' over on Reddit for pointing out that I was originally wrong in saying that H&H's circuit would miss a shorter-than-a-clock-period pulse on the input.
In 1714, the British took a very contemporary approach to solving the long-standing 'longitude problem' by offering a lucrative prize, through an Act of Parliament and administered by a special Board. Whilst the goal was worthy, the criteria for winning was not defined well enough to eliminate the influence of opinion, egos, and politics from a competition that was predominately about a scientific achievement.
John Harrison, a clockmaker and a prime contender for the prize, dedicated years to the problem. In a series of watches, each smaller and better than its predecessors, he pretty much reached the goals of the contest with the 'H4'. The Board, however, realised that a working 'prototype' isn't quite achieving the spirit of the prize -- a replicable, open, and, most importantly, scalable solution to the problem. Harrison was denied the prize despite meeting its technical criteria. Reluctantly, Harrison facilitated the replication by other watchmakers.
Harrison, now quite old, continued to work on H5, and being frustrated with the Board, went directly to the King to test the new device. The King was pleased and leaned on the Board; Harrison finally got a big chunk of money, but not the prize itself, or been officially the 'winner'.
That's a short summary of events, glossing over some details for brevity.
Taking something 'to production' -- yes, cue pretty much all hardware ukulele-themed Kickstarter campaigns -- is still a struggle 300 years on. Firstly, manufacturing something at scale requires very different skills than those required for prototyping. Secondly, prototyping can be very misleading because of how easy it is these days. This is why so many hardware crowdfunding campaigns fail to deliver, even if they are aware of the issues ahead.
Harrison was driven by finding a solution to a burning problem, not by manufacturing it at scale. He was probably naive about keeping the inner-workings a secret whilst still getting 'funding', although in some respects he was treated unfairly by the Board. Taking it 'to production' should probably have been a different prize altogether, as it required different skills than those possessed by a technical innovator.
Today, however, there should be no excuses. When you go Kickstartering and over-promise 5,000 working units to 3,000 people, you better be damn prepared, and deliver! This is one of the wrongs we're done by Kickstarter and their relatives. We're creating a development culture that's unprepared, sloppy, and ultimately disappointing. This doesn't affect only those who don't deliver, it rubs off on all of us in hardware development, who are trying to go about it more reasonably and realistically. It's hard as it is.
I've asked Eurocircuits -- who I've often used to make my circuits for the past couple of years -- if we could collaborate on experimenting with new techniques for PCB manufacturing. To my delight, Luc, Dirk, and their manufacturing team were very welcoming and excited about the idea and were great at producing samples. Their PCB manufacturing expertise is instrumental to the making of boards that are unique but that are also mass-manufacturable and affordable. This is our first experiment.
For a long time now, I've been wanting to create boards that have more than just a single soldermask colour. There is no technical reason that this cannot be done -- it's only a matter of fab willingness, and, of course, cost. The advantage of using soldermask over silkscreen, by the way, is twofold: better resolution, and better registration. (There's also no reason why multiple silkscreen colours can't be done.) Eurocircuits have been at the forefront of innovating in PCB ordering, and have also been offering clients the ability to add graphics to PCBs with their PCB PIXture feature. They add the graphics with soldermask, so they are familiar with a multi-pass soldermask process.
Of course I designed the circuit using our own PCBmodE. The circuit has five warm white LEDs on the bottom side of the board, and an SMD micro-USB connector footprint in the centre of each edge. The idea is that one could choose where to place the USB connector according to the intended use of the board. If it hangs on a wall, it would make sense to populate the connector on the bottom. If it's used as a coaster, side or top placement makes sense. When powered, the light from the LEDs reflects off the surface the board is on and shines through the FR4, gaps in copper, and soldermask.
The visual design is rather arbitrary, but is meant to create engaging structures and also see how well superimposed soldermask layers look like -- then we could have three colours!
OK, enough with the words!
The first variant is 'yellow'. It has black and white soldermask on the top and bottom with yellow silkscreen added on the top.
The second variant is 'red'. This one has white, black, and red soldermask (no silkscreen on the top) with an ENIG finish.
The sharp-eyed would have noticed that the black and white colours are 'dotted' -- this is the technique that Eurocircuits use for PIXture. The main difference from 'yellow', however, is the lack of copper around the text, so light goes through nearly the entire board. This lets the two blue-ish soldermask colours on the back create a very neat and colourful effect.
Which variant if your favourite?
To enclose the board, I've used the same 3mm acrylic pieces -- lovingly made by oomlaut -- that I use for the 'superhero' plaque, but with added spacers for the LEDs and USB connectors. If this plaque becomes a 'thing', an opaque acrylic shim may be a good addition to block the light from seeping through the sides.
Naturally, we love circuits at Boldport and Eurocircuits; this Valentine's Day we really made an effort to show it ;)
It turns out that a component on the new Raspberry Pi 2 is sensitive to high energy beams of a certain spectrum. This causes the RPi to 'hang' and require a hard reset -- here's an official response to the so-called "Xenon Death Flash" failure.
This failure mode is typically called a 'soft error', where no permanent damage is caused and the device will continue operating normally after a reset or a power-cycle. The culprit IC seems to be a switching regulator (U16 on the RPi) that supplies the main processor; the exact failure mechanism isn't clear yet, however. The fix is easy, just cover U16.
In the context of the RPi, this is a non-issue. A robust solution for this type of errors is within the realm of military-, space-, and medical-grade kit, where 'single event upsets' and soft errors are dealt with triple-modular redundancy and radiation hardening. The RPi, I'm certain, comes with a warning that it is not meant for such applications. Regardless, if you're expecting a beyond reasonable robustness from a $35 device that's optimised for cost, you're mad.
This failure is a humble reminder that hardware development is full of surprises. No matter how much you think about all the possible things that could go wrong, there will always be something unexpected that you will lose sleep over (either through worrying about it, and/or all-nighters debugging/fixing a problem so not to delay a launch). If you have a hardware engineer nearby, give them a hug!
There's no way that the RPi engineers could have seen this coming -- shout-out to James, one of the most talented engineers I know -- it's only come to light since the RPi is such a popular product, exposed by default, and people are obsessed with taking photos of it. Now, that's interesting! If it wasn't for the RPi, we might have never been aware of this potential issue. At Boldport, where we design circuits that are meant to be exposed, this is a highly valuable piece of information. In fact, I can dream up scenarios where this can be used as a clever feature! ;)
EDA is dead, and we're to blame.
EDA is dead. It's been dying for about 20 years now. Big EDA have given up on innovation and the 99% of their users that cannot buy "platinum" support. Their software is an out-dated patchwork that's occasionally given a botox injection in the form of a new set of Windows icons. Their interfaces look like a Dreamliner cockpit bolted onto a DC-10 frame. New features are underwhelming, few, and do not address real problems, like source-control, inefficient design processes, and usability.
The thing is that despite the talented engineers working on these tools, culturally and structurally, Big EDA are not capable of innovation, and we should stop expecting them to.
'Cloud' EDA tools such as Upverter, circuits.io and others are disappointing in that they have resisted the urge to innovate. Interfaces are largely the same as their desktop counterparts and the design process is the same. But it's in the 'cloud' and 'social', neither of which are exactly what we're craving. Sadly, these tools are engineered to get aquihired by Big EDA, not to get us to perform our work more effectively, or for disruptting our outmoded industry.
Open source EDA is nearly non-existent due to the tight grip of Big EDA. The KiCAD project, for example, admirable as it is, suffers from typical community-based development issues and its 'old' core. I wouldn't be surprised -- I don't keep track -- if most of the current work is dealing with historical artefacts and personalities, instead of accepting the fact that the software needs a reboot, a natural occurrence in any software development, and one that should be much more manageable in a project such as KiCAD compared to Big EDA tools.
EDA is dead because it is no longer fit for purpose. As unholy as it is, we engineers need to accept that software development has outdone us and we have to catch up. No more exchanging zip files, no more broken tools held together by custom scripts no-one can maintain, no more Digital Stockholm Syndrome, no more status quo. We're partly to blame for letting the situation deteriorate here.
The future is not EDA. People may still call it 'EDA', but it will be something else. It won't have any of that old, mouldy, ancient feel to it -- it will be fresh, fun, and different. I'm sure of it, because the path we're currently headed leads to a low point from which new innovative tools will emerge. If you're currently developing tools for engineers, I beg you to not accept the old ways and innovate in usability and the design process, not only in crunching numbers, and the obvious 'social', 'mobile', and 'cloud' buzz. I'm trying to do that with PCBmodE, and I can assure you that it's hard, but it may be worth it!
* I mostly talk about circuit design software here, but I know that it applies to all flavours of EDA. Prove me wrong.
One of the directions we're exploring at the moment is applying the concept of "beautifully functional circuits" to evaluation and development kits from IC and system companies. We think that it's prime time that existing boards evolve beyond the -- large, square, green, WindowsXP-CD-included, feature-creep-example, hard-to-use -- things that they are. We know that companies would like to have their boards stand out at shows, on-line, and in hardware hacking events. We know that companies would like to entice engineers to explore the unique capabilities of their products, and talk about them to their peers. We know that companies want to project innovation, modernity, and creativity. Applying all of these things to circuit boards is our speciality!
This week we will be at Electronica in Munich talking to companies about their needs and promoting the concept of form+function and how it applies to circuit boards. We'll be visiting stalls and would love to talk to anyone who is interested in our work. So please reach out, and also, kindly, help us spread the word.
PCBmodE was publicly released in January 2013. I've created many boards with the software, but it remained somewhat of a personal project for various reasons. Recently I've decided to make a few improvements which quickly escalated to a full re-write of the software. The code is now more object-oriented, readable, organised, and so hopefully more attractive to contributors and users. Most importantly, however, the usage of the code is much more documentation-friendly. There aren't any new features, but adding them would be much easier with this code.
PCBmodE version 3.0 is hosted on Github, whereas older versions were hosted on Bitbucket. The main reason for the move was to see if this influences contributor engagement and exposure; this is where Github clearly wins over Bitbucket. A minor, but important, reason for the move was the lack of two-factor authentication on Bitbucket. There's no excuse for not having 2FA by now. It makes me feel like something is broken under the hood, or at least in the decision-making process at Atlassian. Otherwise I have no complaints for Bitbucket; it's a solid service that also offers free private repos, which is great.
Documentation was seriously lacking up to now and I always sympathised with the plight of those who really wanted to use PCBmodE but had no resources to work with. The documentation for version 3.0 is now done with the popular Sphinx+ReadTheDocs combo, and found here. It's not complete, but it's a start.
Boards made for older versions of PCBmodE will not compatible with version 3.0. There's now a separate repository for boards made for version 3.0 and older boards will be migrated as needed, if at all. A good stating design is the 'hello-solder' board.
Finally, I've changed the license from Apache to MIT. I felt that an MIT is more familiar to developers and more appropriate for the project. It shouldn't make much of a difference for most people.
Oh, new PCBmodE logo!
I really hope that PCBmodE will experience more users and develop a healthy and productive community around it. Please help where you can and send feedback my way.