Sustainable clothing with Rapanui and Raspberry Pi

via Raspberry Pi

New to the Raspberry Pi Store, Cambridge: T-shirts made using Raspberry Pis in Rapanui’s sustainable factory.

Oli Wilkin – our Glorious Retail Guru, to give him his formal title – has been hard at work this year bringing the Raspberry Pi Store, Cambridge, to life. Open since February, the store continues to evolve as it introduces our credit card-sized computer to a high-street audience. Oli and the store team are always talking to customers, exploring new ideas, and making changes. Here’s Oli on the latest development: Rapanui clothing, made sustainably with the help of Raspberry Pis.

Rapanui 2

Subscribe to our YouTube channel: Help us reach a wider audience by translating our video content: Buy a Raspberry Pi from one of our Approved Resellers: Find out more about the #RaspberryPi Foundation: Raspberry Pi Code Club UK Code Club International CoderDojo Check out our free online training courses: Find your local Raspberry Jam event: Work through our free online projects: Do you have a question about your Raspberry Pi?


Brothers Mart and Rob started bespoke clothing company Rapanui in a garden shed on the Isle of Wight, with an initial investment of £200 (about $257 US). Ten years later, Rapanui has grown to a fully fledged factory providing over 100 jobs. Their vision to create a sustainable clothing brand has seen them increase Rapanui’s offering from T-shirts to a much wider range of clothing, including jumpers, socks, and jackets. Another reason we like them a lot is that the factory uses over 100 Raspberry Pis with a wide variety of functions.

Rapanui’s early early days weres not without their challenges. Mart and Rob found early on that every improvement in sustainability came with a price tag. They realised that they could use technology to help keep costs down without cutting corners:

Along the way, we needed a real low-cost option for us to be able to get computing in and around the place. Someone said,
“Oh, you should check out Raspberry Pi.”
“What’s that?”
“It’s a computer, and costs twenty quid or something, and it’s the size of a credit card.”
“OK – that can’t be true!”

We got one, and it just blew our mind, because there’s no limit to what we could do with it.
– Mart

The Raspberry Pis are supporting things like productivity improvements, order tracking, workload prioritisation, and smart lighting. All employees are encouraged to try coding when they start working for Rapanui, and they’re empowered to change their workplace to make it smarter and more efficient.

As Mart explains,

In the world today, there’s a lot of issues around environment and sustainability, which feel like compromises – you want to do your bit, but it costs more. What this kind of technology allows us to do is make things cost less because you can create these massive efficiencies through technology, and that’s what enables you to be able to afford the things that you want to do with sustainability, without having to compromise on price.

Circular economy

All of the organic cotton that Rapanui uses is fully traced from India to the Isle of Wight, where it is turned into amazing quality branded items for their customers. Once a garment has come to the end of its life, a customer can simply scan the QR code on the inside label, and this QR code generates a Freepost address. This allows the customer to send their item back to Rapanui for a webshop credit, thus creating a circular economy.

Raspberry Pi + Rapanui

All of this makes us very pleased to be working with Rapanui to print the T-shirts you buy in the Raspberry Pi store.

Rapanui – from workshop to store

Subscribe to our YouTube channel: Help us reach a wider audience by translating our video content: Buy a Raspberry Pi from one of our Approved Resellers: Find out more about the #RaspberryPi Foundation: Raspberry Pi Code Club UK Code Club International CoderDojo Check out our free online training courses: Find your local Raspberry Jam event: Work through our free online projects: Do you have a question about your Raspberry Pi?

We have started with our Raspberry Pi 4 T-shirt, and others will follow. Our hope is that all our T-shirts will be fully sustainable and better for you, our customers.

The post Sustainable clothing with Rapanui and Raspberry Pi appeared first on Raspberry Pi.

Arduino on GitHub Actions

via Arduino Blog

This post is from Massimiliano Pippi, Senior Software Engineer at Arduino.

GitHub Actions is the name of the SDLC (Software Development Life Cycle) system introduced by GitHub about a year ago, currently in public beta and now approaching the general availability status. When you read SDLC, think about some sort of CI/CD system that’s generic enough to let you define a sequence of operations not necessarily limited to build, test, and deploy code: GitHub Actions can help you automate processes in code reviews, issue triaging, and repository management.

GitHub Actions have been part of the tools we use at Arduino for a while now; helping us solve a wide range of problems from automating workflows within our backend infrastructure, to managing the release process of our open source software. In the spirit of giving back to the community, we started publishing some of the Actions we developed internally so that they can be used right ahead from any GitHub account that’s been granted access to the public beta of GitHub Actions, and eventually in any GitHub repository.

Our Actions are available from this repository and there’s one in particular we think the Arduino community will be happy to have – it’s called setup-arduino-cli and under the hood it takes all the steps necessary to have the `arduino-cli` binary available in a Workflow.  This means that in any step of your Workflow you can leverage the long list of features of the Arduino CLI.

# This is the name of the workflow, visible on GitHub UI.
name: test
# Here we tell GitHub to run the workflow when a commit
# is pushed or a Pull Request is opened.
on: [push, pull_request]
# This is the list of jobs that will be run concurrently.
# Since we use a build matrix, the actual number of jobs
# started depends on how many configurations the matrix
# will produce.
  # This is the name of the job - can be whatever.
    # Here we tell GitHub that the jobs must be determined
    # dynamically depending on a matrix configuration.
        # The matrix will produce one job for each configuration
        # parameter of type arduino-platform, in this case a
        # total of 2.
        arduino-platform: ["arduino:samd", "arduino:avr"]
        # This is usually optional but we need to statically define the
        # FQBN of the boards we want to test for each platform. In the
        # future the CLI might automatically detect and download the core
        # needed to compile against a certain FQBN, at that point the
        # following include section will be useless.
          # This works like this: when the platform is "arduino:samd", the
          # variable fqbn is set to "arduino:samd:nano_33_iot".
          - arduino-platform: "arduino:samd"
            fqbn: "arduino:samd:nano_33_iot"
          - arduino-platform: "arduino:avr"
            fqbn: "arduino:avr:uno"
    # This is the platform GitHub will use to run our workflow, we
    # pick Windows for no particular reason.
    runs-on: windows-latest
    # This is the list of steps this job will run.
      # First of all, we clone the repo using the checkout action.
      - name: Checkout
        uses: actions/checkout@master
      # We use the arduino/setup-arduino-cli action to install and
      # configure the Arduino CLI on the system.
      - name: Setup Arduino CLI
        uses: arduino/setup-arduino-cli@v1.0.0
      # We then install the platform, which one will be determined
      # dynamically by the build matrix.
      - name: Install platform
        run: |
          arduino-cli core update-index
          arduino-cli core install ${{ matrix.arduino-platform }}
      # Finally, we compile the sketch, using the FQBN that was set
      # in the build matrix.
      - name: Compile Sketch
        run: arduino-cli compile --fqbn ${{ matrix.fqbn }} ./blink


Let’s say you keep your sketches in a GitHub repository, and you want to be sure that every time you push a git commit or you merge a pull request, the sketches compile correctly on certain boards you own, for example a Nano 33 IoT and a Uno. To keep the configuration at minimum, we can use a “build matrix”, so that GitHub will start a different job for each one of the platforms we list in the matrix, without the need to configure them explicitly.

You can find a working example here:

You can find more info and docs for the Action on the GitHub Marketplace: if you like it, please leave us a star!
We’re eager to hear your feedback, feel free to hit the Action repository and open an issue should you find any problem, or a feature request in case you want more from the action.

ATTiny85 Pulse oximeter with photoplethysmogram (PPG) display

via Dangerous Prototypes

tinyPulsePPG, an ATTiny85 Pulse Oximeter with Photoplethysmogram (PPG) display by Jeff Magee:

This project implemented on an ATTiny85 displays a moving Photoplethysmogram together with pulse rate and estimates of SpO2 – blood oxygen percentage. It uses an SSD1306 128×32 OLED display and a Max30102 sensor. It is emphasised that this should not be used for medical purposes. The computation of SpO2 is very approximate and not calibrated in any way. The project is an exercise in software and hardware parsimony.

Project info on GitHub.

Current meter based on ESP-12E and LTC4150

via Dangerous Prototypes

Victor Chew made a simple current meter based on ESP-12E, LTC-4150 and SSD1306 OLED module that measure the average current draw of a variable load accurately:

The meter is powered by the micro-USB port on the ESP-12E. I soldered header pins onto the IN and OUT terminals of the LTC-4150. The whole idea is that one could plug the source battery into the IN terminals, and plug the circuit to be tested into the OUT terminals, press the “Reset” (RST) button on the ESP-12E, and it will start measuring the average current draw of the circuit.

Project info at Source code can be found on GitHub.

Creating Artemis

via SparkFun: Commerce Blog

For years SparkFun was wary of getting a product fully FCC certified. The process always seemed unknown and prohibitively expensive. We've written about the FCC requirements for products and hobby projects the past, but with the development of the SparkFun Edge and the creation of Artemis it was clear that it was time to venture into uncharted territory.

We hope you can learn a little something from us. This will be a three-part series covering the creation of the Artemis SMD module, getting an RF shield made (twice), and going through the FCC certification process. Stay tuned for the rest of the series.

Creating Artemis

Back in October 2018, we were introduced to the folks at TensorFlow to do a low-power board with the new Apollo3 from Ambiq. After a quick scan of the datasheet it was obvious this IC was as challenging as it was exciting! One MB of flash, nearly 400k of RAM and exceptionally low power made us start dreaming of the possibilities beyond the old Uno. At the same time, an 81-ball BGA with 0.5mm pitch meant we'd have to up our PCB game.

Bottom of Apollo3 showing ball grid array

81-Ball Grid Array with 0.5mm pitch

The project was nicknamed SparkFun Edge (the whole computing on the edge thing) and we dove into getting to know this new IC. The Apollo3 is a straightforward microcontroller but the density of the balls made routing a design far more interesting.

Basic 8 mil trace space PCB routing

The BNO080 breakout is a good example of SparkFun designs.

Most SparkFun designs can be done with rather large trace/space requirements (8 mil trace/space) with small-ish vias (12 mil) on two layers. These specs are very common and make for very low cost PCB fabrication. To even begin to route the Apollo3 we reduced the trace thickness to 5 mil, the vias down to 6 mil and used a four layer board, but it was still impossible to get to the inner balls. Let’s talk about some of the challenges and solutions.

Via beside BGA pads showing DRC errors

We first started by placing the vias adjacent to the ball. As shown above, the vias were still massive compared to the balls. The annular ring of the via is too close to the neighboring pads, causing DRC errors. Because of the 0.5mm pitch on the Apollo3 we would have to use a 3 mil-sized (0.003”) via in order to not have the annular ring be within 6 mil of a neighboring pad. This sized via is solidly in the territory of expensive laser drilling, which can be prohibitively expensive. So the first PCB trick for 0.5mm pitch BGAs is called via on pad. This is a method to allow the placement of vias directly under a ball.

Via placed under BGA

A via is placed directly on the pad where the ball will be soldered.

Normally, vias are not placed directly on an SMD pad because the solder paste tends to wick down into the hole during reflow, reducing the solder available to the pad and leading to unreliable connections. Fab houses are aware of this so, as an alternative to costly laser drilling, they have developed via-in-pad, which is a succinct term for drilling a very small via, plating the hole, back-filling the hole with conductive epoxy, then plating and polishing the fill so that it forms a flat, solid pad.

PCB with epoxy filled vias vs masked hole

On the left you can see the original Edge with its filled vias. Note how the vias appear flat. There are vias inside of many of the BGA dots as well. On the right is the ATECC508A Crypto breakout. You can see the ‘dimples’ on the PCB where the mask dips into the vias. Those vias are empty and cheap to produce.

Eagle routing showing vias blocking trace paths

Trace route blocked by annular rings

Via-in-pad allowed us to route directly down to a lower layer, but again we were foiled because the traces couldn't fit between the vias on adjacent pads. We could get down, but we couldn’t get out. The next trick is blind vias.

PCB stackup showing how blind vs buried vias work

Blind vias on the left. Buried vias on the right.

Blind vias basically means vias that don't go through the entire board (they are ‘blind’ to the opposite side of the board). Buried vias are limited to inside layers and do not protrude to the outer layers. These types of vias require the individual layers to be drilled, then precisely aligned and laminated to the next layer, then holes are plated, then the next layer is added and the process is repeated. Euro Circuits has a great writeup of the process and the challenges associated with the different types. While tricky and more expensive to produce, blind and buried vias are often necessary for compact designs such as the Apollo3.

Eagle traces drawn with buried vias

In the above image, Eagle shows which layers are connected by the via with text on the via. One-two means layers 1 and 2 are connected. One-16 means layers 1-2-15-16 are connected.

It’s a bit trippy the first time you do it, but you can see in the above image the AD13 trace has a via going from layer 1 to 2 (blind) and continues on layer 2 (mid layer pink-ish). The D15 trace has a via that goes from layer 1 to 16 (through) and continues on layer 16 (bottom layer blue). Using blind vias, we can finally begin to route out the inner balls to the rest of the circuit.

Buried via shown directly on top of another buried via

It gets even weirder when you have vias on vias. Shown above, there are two vias on top of each other. We have AD33 coming in from the top of the image (red) and going into a 1-2 via and exiting the bottom of the image (pink-ish). D26 enters from the right of the image (blue), goes into a 15-16 via and exits the left of the image (yellow). Because the vias are blind (and are insulated by the core FR4), they can be stacked on top of each other.

After much tweaking and price checking, we used the following specs to route the Edge:

  • Min Trace Size: 0.004” (0.1mm)
  • Min Drill: 0.006” (0.15mm)
  • Annular Ring: 3 mil
  • Min Trace to Pad Spacing: 4 mil

Can PCB fab houses go smaller than this? Certainly, but the costs go up exponentially. Let’s call the above numbers “very tight” PCB specs, and they cost a lot more than the very low cost PCBs that are available from the likes of PCBWay, PCBUniverse, JLCPCB, etc. Over time these specs will probably get even better for cheaper, but today, this seems to be the soft spot right before the “ludicrous” specs of laser drilling, 6+ layer stackups, and a combination of buried and blind vias.

Four layers of routing around the Apollo3 on the SparkFun Edge

The routing in and around the Apollo3 IC on the SparkFun Edge

Once all these advanced techniques were enabled within Eagle, the routing of the Edge proceeded like any other design but with a lot more staring. It's amazing how foreign viewing four layers with not-through-vias felt and how, after two days of futzing around (and dreaming of vias), the brain remaps a bit and it gets easier to see how things are connected. While these methods are common in High Density Interconnect (HDI) PCBs that make up a huge chunk of modern electronics, this type of routing and PCB design was new and exciting at SparkFun.

SparkFun Edge

The SparkFun Edge with Apollo3

We were able to deliver the Edge on time and (nearly) on budget for Google's TensorFlow conference. What pained me was that we needed the "very tight" specs for a few square millimeters around the Apollo3; the rest of the board was trivial and could be routed with regular 8 mil trace/space but (of course) we had to pay for the entire PCB. The Edge is relatively large, so the cost of PCB rivaled the cost of the main IC. In addition, the lead time for this type of advanced PCB meant the Edge would suffer from long lead times due to the boards taking time to fabricate. Any changes we wanted to make to the PCB would cost many months and hundreds of dollars to test.

But what if we could create an SMD module that had the Apollo3 inside? We could move all the complexity of the crazy back-filled blind vias and four-layer routing into a smaller module that (hopefully) would stay static. We could simply plop this "known good" block onto a design and not have to worry about PCB lead times. The Edge could move to a two-layer PCB, making it far easier to revise and add features. We could even design additional carrier boards for this "known good" Apollo3 block. And wait, couldn't we sell this module to other companies so they could use the Apollo3 as well? Oh! And…

The ideas kept coming. It was obvious we needed to design a compact SMD module, deal with RF shielding, go through FCC and port the entire Arduino core over to the Apollo3. Just a few challenges! But all new and exciting ones.

How to Design an SMD Module

Don't forget that Artemis is an open source hardware design. You can download the Eagle files here and checkout and even modify the design yourself!

The layout of Artemis in Eagle

The internal layout of Artemis

To create the Artemis, we were lucky to start from a known good design, the SparkFun Edge. We knew how to wire the Apollo3 and make it work. Now we just had to compact it into a one-sided board. We first started by looking at all the SMD modules we could find.

The pads on most SMD modules can be grouped into two basic groups: castellated and buried.

Castellated modules soldered to PCB showing large pin landings

Two modules with castellated pins: Thing Plus - XBee3 on left, BlueSMiRF on the right.

Castellated pads are easy to solder and easy to inspect. The problem is that you're really limited by the number of pads you can expose. On a module with an onboard antenna, you’re limited to three edges. In most modules it's a dozen, perhaps 20 pins that are exposed to the user.

Two boards with modules showing buried pins

Two modules with buried pins: SparkFun NB-IoT Shield on left, nRF52840 Mini Breakout on the right.

Buried pads are located under the module and cannot be seen from the top or sides of the module. These types of pads would be harder for the end user to inspect and rework, but it dramatically increased the number of GPIOs and features we could breakout of the Apollo3. Buried pads are not new or even necessarily hard to solder - it just takes good solder stenciling and a good reflow profile. Most new, very small modules are using buried pads for obvious reasons.

The Apollo3 is fantastic in that it has 50 GPIOs with tons of peripherals! We briefly considered a module with castellated pins but quickly decided we wanted to break out as much of the power of the Apollo3 as possible, which meant we needed to go to buried pads located on the bottom of the device.

Learn from others! After inspecting a few different modules with buried pads, it became clear that staggering the pads would allow for larger pads to be more closely stacked while permitting 8 mil traces to enter/exit the device.

Artemis footprint implemented on the RedBoard showing thick traces going in and out

This is what the footprint for the final Artemis module looks like as implemented on the RedBoard Artemis. We could have designed the pads to be very skinny and stacked them next to each other, but this leads to challenging stenciling and potential bridging. The staggered pads mean the pads can be made larger while closely packed, and without fear of solder paste bridging between pads. This makes the stenciling and reflow process for the final assembly much easier. Wider pads means the traces going in and out of the module can be made larger, which leads to lower cost PCBs for the end user. The Artemis can be routed with 8 mil trace/space and 15 mil vias. Staggered pads meant we could make this incredibly new and cutting edge tech available to anyone by routing with super cheap and easy PCB tolerances.

With the staggering of pads in mind, we had to decide which balls on the Apollo3 to break out and how to do it.

Pad map of the Apollo3

Pad map of the Apollo3

I now know this table by heart. We wanted to break out all 50 GPIOs if possible, and we tried. But it became obvious, after many puzzling attempts, that a few balls would have to be left unconnected. But which ones? Only 10 of the 50 pins are ADC capable, so those were seen as most valuable. Next were PWM pins. There are 32 pins on the Apollo3 that are PWM capable, so those were given additional value. There are two UARTs, six I2C and six SPI ports on the Apollo3. The trick is that these peripherals can be assigned to a variety of different pads. And on the outside chance users wanted to use the SecureCard, PDM or I2S capabilities of the IC, we wanted to be sure to break out those pads and make the maximum number of flexible pins available.

Unrouted pads on Apollo3

Bon voyage 30 and 46!

A few days of pad valuations and test routing ensued. In the end we had to say goodbye to pads 30 and 46. While 30 has PWM, it became nearly mechanically impossible to break out this inner ball without additional PCB layers. Pad 46 was lovely, but just didn’t have enough peripherals to make it worth going to a six-layer board to break it out.

Layers of the Artemis module

Here are the four layers that make up the Artemis. It looks so simple, but took multiple rounds of protos (remember those long leads times?) and quite a bit of work to get to this stage. But as the first modules began to run "Hello world" blink programs, we started to get very excited at SparkFun. This can be done!

Grouping of Pads

Names of pads on Artemis

Names of pads on Artemis

If you look closely at the pads on the Artemis, you’ll notice that the pad names seem randomly placed: pad D42 is next to D3, is next to D36, etc. This pains my soul. I really wanted to arrange the pads in sequential order - this would make it easier for the user to navigate the routing of peripherals - but in the end it became untenable. We arranged the pads in the order that made routing most possible. If you’ve ever wondered why a given module has what looks to be completely random pin arrangements, this is why: keeping logical arrangement of pins often gives way to keeping size down.

BOM Beating

Bare Artemis Module

Original Artemis Engineering version that shipped without RF shield

As the Artemis design was coming together, every component on the board was reviewed and vetted for cost and supply chain concerns. It was clear that we would be competing in an already cluttered space of WiFi (thanks ESP8266!) and various Bluetooth modules. The race to the bottom has been going on for years, so we would need to keep our overall BOM costs as low as possible to stay competitive in the market. The Apollo3 has a large number of advantages over WiFi and regular, higher-power Bluetooth modules, but we had to be careful picking out the various components.

Finding a super low cost component is obvious, but if you can’t get that part for 10 months then who cares about cost? And you’ve heard that saying, "penny wise but pound foolish," we experience this all the time with suppliers who either disappear or required 17 steps before they will ship an order. Be careful trying to reduce the cost of a button by $0.02; you may end up adding $0.20 when you factor in the overhead of a crummy supplier.

Additionally, once a device has been tested and certified it is a Herculean task to change out a component along the RF path (the most sensitive being the antenna). The biggest choice was the RF antenna. We decided to go low cost (but not lowest) with a well known manufacturer that was responsive and seemed to have plenty of stock available from a variety of sources.

With the primary layout complete, we moved on to designing an RF shield that would mate with the module...but that's a story for next time.

comments | comment feed

James Bruton’s 512 LED DJ helmet adds more glow to his Performance Robots show

via Arduino Blog

If you’ve ever thought that your musical performance needed more LEDs, then James Bruton’s DJ helmet may be just the thing for you.

The YouTuber’s wearable device is built on the base of a protective face shield, substituting in a 3D-printed support for an 8×32 LED matrix, as well as four smaller 8×8 LED matrices arranged above and below the main section.

The 512 LEDs are powered using a portable LiPo battery and a 10A power regulator. Control is via an Arduino Mega, which is connected to an RJ45 jack that enables it to work with DMX lighting data. 

The result is a spectacular display, shown off nicely in an electronic concert (with his barcode guitar) starting at around 8:20 in the video below!