Please confirm your shipping address
If you selected a Dev Kit reward during the campaign you should have received an email from us last week to confirm your shipping address.
If you haven’t already – please follow the link in that email to confirm your address. If you didn’t receive an email or are unsure whether you have confirmed your address please reach out to us.
As it has been some time since the campaign finished, we want to be very confident that we are shipping your shiny new Dev Kit to the right address. So even if you recently updated your address, we ask that you confirm it one last time through the email from us. When the production Mark II’s are ready to ship, we will go through a similar process.
Once you receive your Dev Kit, there is some assembly required – that’s part of the fun!
If you want a sneak preview of what to expect, you can find those instructions here:
When doing a production run like this, it’s always a good idea to get a small number produced for testing before doing the entire batch. This month was a prime example of why that’s so important. TL;DR: We had to trash 290 bare PCBs due to using the wrong pad design for the mass production vs. hand-soldered process we had been using. The first ten worked fine with some hand-soldering rework, but that wasn’t practical for the full run. We are repeating the test process with the new PCBs and if they check out, the factory is ready to produce the remainder of the order within a few days.
If you’re not curious about the details of the mistake, you can skip this paragraph. When the first 10 PCBs were assembled it was identified that the pad lengths for the XMOS XVF3510 were too long. This is a quad-flat no-leads (QFN) integrated circuit. With shorter QFN leads, the solder balls up on the walls of the QFN better. With longer leads, the solder doesn’t climb the walls of the QFN as well. Previously these ICs were hand soldered, for which the longer leads work just fine (or better).
With the Dev Kits getting ready to ship, the team has been focused on improving the Mark II specific elements of the software. This includes drivers to interface with the new hardware, a new onboarding flow when you first boot the device, optimizing the Pantacor build process, and unfortunately spending more time than we’d like on upstream bugs in the Linux audio stack.
Presently there are a few issues in PortAudio that cause buffer overrun errors in certain circumstances. These were causing the Mark II microphone stream to completely fail. Not a good thing for a voice assistant. In the short term we’ve implemented some fixes and workarounds to reduce the chance of this occurring, and handling it more gracefully when it does. Some of the fixes for this are currently being reviewed for inclusion by Debian. However it may be some time before they trickle down through official channels, so we’re likely going to be using our own custom package for the time being.
Gez is the Director of Developer Relations at Mycroft. He comes from the land down under, has a strange love of crocodiles, and one day hopes to play the ukulele. If he’s not hanging out in our Community Chat and Forums, he is probably getting lost in the bush.