Input Devices
Using sensors to gather data.
Using sensors to gather data.
Measure something: add a sensor to a microcontroller board that you have designed and read it.
Probe an input device's analog levels and digital signals.
This week's group assignment was to probe an input device's analog levels and digital signals.
Led by Arthur and Rehana, we measured the
This week, I set out to experiment with sensors and designed two new boards.
For my final project, I'm currently planning to make a "smart" egg (affectionately known as Humpty Dumpty's Stunt Double"), that can communicate whether it breaks when dropped. That means I'll need to know the impact force of my "egg" hitting the ground, do I decided to create an accelerometer board.
I also set out to design, mill, and solder my own "devkit" breakout board, both to support this week's assignment and as a step toward my final project. This means a standalone board that contains a microcontroller and is laid out to keep as many of its pins available as possible, maximizing future utility.
A dev kit gives me much more freedom to explore different sensors without needing to redesign a brand new board each week. (Think of it as the core for further modular components. I would connect the main board into a usb adapter, and then plug a much smaller sensor breakout board into the main board. Thus, I can switch satellite boards out quite easily to play with different functionalities.)
This proved to be much more complex than I anticipated, but should be worth it in coming weeks!
In the end, I wound up with my own devkit / main board (first image below) and a cute little accelerometer (second image) that feeds real-time data through Arduino IDE in list or graph form. Even better: both boards worked on the first try--no need to resolder!
My smallest spiral for the week began with proof of concept for the accelerometer breakout board. TA Quentin (or as TA Leo calls him, "The Trespasser," helped me figure this out on Wednesday after class. He put together his own miniature board and made it work, showing me along the way how to use Arduino IDE in further depth and how to solder the tiniest component I've tackled so far.
Quentin's postivity, animation, and enthusiasm for figuring out new things--and even making mistakes, because they're "super interesting"--is contagious and enviable. I have decided to strive for a similar outlook going forward, (but no promises).
Testing Quentin's board: Quentin's design and evidence of its success are below. Because I didn't have a separate microcontroller board to power this one yet, we plugged it into a pico board on his computer--and it worked beautifully! As we moved the chip around, the data readouts on the computer (both in list and graph layout) reflected its movements in real time. Very cool.
One note, though: when I later set out to create my own version of this breakout board, we realized that it wouldn't actually work for the SAMD-21 microcontroller I ended up using. While the pico board Quentin had used contained an embedded pull-up resistor, the SAMD-21 chip did not. That meant I would need to add pull-up resistors to my design: specifically, one 10k resistor for each pin.
For the time being, I chose to take a break from the accelerometer board to focus on designing my own version of Quentin's useful SAMD-21 devkit. This would power both the accelerometer board and (hopefully) and future sensors I may choose to play with.
(Jump straight to Step #3 if you want to skip to the next chapter of accelerometer board development.)
With proof of concept for my accelerometer taken care of courtesty of Quentin, I shifted my focus toward creating a more versatile SAMD-21 board that I could use with a range of different satellite breakouts, (including the accelerometer).
This was inspired by TA Quentin's devkit, which he's documented beautifully here . (And check out his other projects while you're on his site--they're super cool!).
Remembering my workflow from Week #5 , I started by listing out the components I'd need.
I did make a few tweaks along the way, so here is the final component list I ended up using. (Note that I've listed each component followed by its footprint/part name, followed by any notes):
Along the way, I learned a new skill: sourcing and importing footprints for new components not in my current Eagle library.
Quentin's devkit used two 1x9 pin headers, which we didn't have in stock. So, I ended up aligning four 1x5 female pin headers instead (two sets of two, one for each side of the board). This means I effectively ended up with two 1x10 headers, and just connected the extra pins to ground.
However, didn't have the appropriate footprints for these in the fab library, nor did they show up in any of the other libraries I tried in Eagle. That meant I had to go searching, which led me to SnapEDA at Neil and TA Quentin's recommendation. SnapEDA has a huge repository of resources for various components.
Here's a link to the
1x5 female header footprint
I downloaded from SnapEDA, in case you need the same part.
Just click on the "download footprint" button below the image on that page, and then select "Eagle" (or KiCad or whatever you're using) from the dropdown menu. (You can also check out this page for a handy guide on how to add a footprint to Eagle:
https://support.snapeda.com/en/articles/2651508-how-to-import-into-eagle
.)
Once I finally got all of my components added into my schematic, it was time to net everything together.
Using Quentin's board for reference, I began linking things. I chose to connect everything with solid lines instead of using the name flag system. That way, I can trace my connections more easily.
With my nets drawn, the next step was to route the traces. That meant navigating over to the layout view for my board design.
As always, everything starts off stacked together in the bottom lefthand corner.
Once we move everything up onto the workable portion of the screen, it's a tangled mess of airwires. Thus, my first step was to position my components in as efficient a way as possible, paying attention to how their airwires interact.
Remember: airwires will automatically shift to the closest relevant connection point, which may not always be the most efficient path for actually any given trace if you encounter another trace in its path. Look for detours when this occurs.
I spent a very long time positioning and repositioning my components. Finally, TA Quentin advised me to just start routing. He pointed out that topology is really what matters here. Getting everything connected is the puzzle that needs to be solved; once the traces are actually routed, then we can focus on moving things around again.
Here's what I ended up with. Note that I did have to go back into my schematic to mirror and then rotate two of my female pin headers in order to better position things on my final board. (You can't do this for most components since you can't mirror the actual physical component--but the pin headers are mirrable/rotatable since they have no inherent characteristics preventing this).
As a last step in Eagle, I created a polygon outline around my board and exported PNGs for both the outline and traces. (Note that the holes are for little plastic pegs on the bottom of the mini usb connector to sit in). (I messed up here. I should have made the edge of my board flush with the edge of the USB mini port. The fact that I left a margin around my board became a problem down the line.)
Then I exported and milled using our trusty Roland SRM-20.
Note: I actually milled twice, since the endmill quite literally only scratched the surface of my copper the first time around instead of removing the top layer. I fixed this by making sure I held the endmill down more firmly when tightening its set screw after setting the z-axis the second time around. Both boards can be seen below.
Finally, I soldered!
I started with the SAMD-21 chip since it has so many tiny little pins (visible through a microscope below pre-solder), but found it manageable with patience and care. Then I added the other complex pieces (USB and 2x5 pinheader) before the LEDs, capacitors, and resistors. I generally enjoy soldering, and this was a fun challenge.
It came out nicely, with no solder bridges.
Last but not least: progamming. It was at this point that I discovered the issue with my board's outline. I didn't place the edge of my board close enough to the edge of my mini USB port. The excess board margin jutted out and prevented the mini USB cable from plugging into its port. We ultimately had to cut away a chunk of this margin in order to correct the problem. (Thanks, TA Dave!)
After this bit of (relatively minor) board surgery, I was able to successfully plug in the micro USB cord. I'd designed it so that a blue LED would light up when the board received power, and on it came. After bootloading the board, we then flashed it with a blink program to control the second (red) LED--and it began to blink.
Success! I now had my very own devkit.
Even better: Quenin said I had an impeccable soldering job! I'm so proud.
I also sent my file to Noy so she could adapt it to add a button, since Quentin's site didn't have a downloadable file for Eagle (just KiCad) and she wasn't exactly looking forward to (re)designing from scratch in the middle of the night. In turn, she ordered us Tasty Burger and Chinese.
With my devkit ready and waiting, my next step was to design my own version of an accelerometer breakout board. This would be a cute little board featuring (surprise, surprise) an accelerometer, but containing no microcontroller of its own. I would be able to plug it into my main devkit board using wires, and it would use that board's microcontroller. Then when I was done with it, I could disconnect it and put it away. Hooray for modularity!
Let's start with the basics: The accelerometer I decided to use (because it's what we had in the lab) is the ADXL343. This is a three-axis accelerometer, meaning it can measure movement (acceleration, specifically) on the x-, y- and z-axes.
SparkFun further explains that accelerometers sense "either static or dynamic forces of acceleration," where static forces include gravity while dynamic forces include vibrations and movement.
If I choose to later upgrade to a six-axis accelerometer, I will also be able to track orientation (rotation) of an object in addition to direction and acceleration.
DESIGNING IN EAGLE:
Step one for this was, as usual, to identify and add my necessary components. Here's a list of everything II ended up with in the final design (after swapping the headers late in the process):
Remember that Quentin's original accelerometer model wouldn't work for the SAMD-21 microcontroller because that chip doesn't have embedded pull-up resistors, meaning I had to add two 10k resistors during my design process. I also had to source a footprint for the accelerometer itself. I used the one for the ADXL345 since it was the same as for the ADXL 343.
After adding my necessary components into the design, I drew nets between them to map things out.
Then I shifted over to lay out my board and route the traces (always my least favorite part). Fortunately, there were far fewer components to wrestle around on a board as small and simple as this one, so it wasn't too bad.
Remembering Quentin's advice about topology, I only spent a few minutes positioning this time before starting to lay the traces themselves. I also switched the header pin positioning for ground and power part of the way through the process, since this helped me untangle my airwires and traces.
Then I shifted over to lay out my board and route the traces (always my least favorite part). Fortunately, there were far fewer components to wrestle around on a board as small and simple as this one, so it wasn't too bad.
Remembering Quentin's advice about topology, I only spent a few minutes positioning this time before starting to lay the traces themselves. I also switched the header pin positioning for ground and power part of the way through the process, since this helped me untangle my airwires and traces.
However, I did run into one snag: I had originally intended to use male header pins--which I knew we had in the lab because Quentin had used them on his model board--but I couldn't find a footprint for them that actually included through-holes in the bottom layer for the milling process. They all supplied just the pads themselves. Sadly, I still haven't solved this in a way that doesn't require Photoshop.
Instead of going that route, I spent way too long on Google and SnapEDA trying to find the appropriate footprint before ultimately giving up and switching to a female header instead. I eventually used the same one from my devkit board, mentioned in Step #2 above. (I wish I'd thought of this earlier instead of wasting so much time, but that ship has sailed.)
This decision also resulted in the following conversation:
-Noy: Is female-to-female okay?
-Leo: In some states.
-Noy and Claire: *momentary bewilderment over what different states the chip could be in...*
In our defense, it was the middle of the night, okay? We weren't thinking straight! In any case, here is the final design and its layers:
MILLING:
With my tracing done, my final board was ready to mill! I gave it an outline, exported its PNGs (remember that these have to be monochrome!), and settled in at the Roland.
Pro Tip: If you're replicating my process, it is vital at this point that you check the toolpath before milling. Because the pads for the accelerometer are so increrdibly tiny, they wanted to clump together instead of milling separately. The solution for this was to trick the machine by changing the tool diameter from the default 0.0156 down to 0.004.
With this updated setting, the milling process was quick and easy.
S OLDERING:
Despite being a small board with only a few components, soldering this was a challenge. This is because the accelerometer I used didn't have pins sticking out to the sides, nor did its pads on the board extend beyond the width of the sensor itself.
That meant there was no way to solder this conventionally. I had to use extreme precision, the heat gun, and some luck.
First, I flowed teeny tiny dots of solder onto the accelerometer's pads. (Truly only the tiniest amount--do not oversolder these!) Then, using tweezers, I tried my best to perfectly align the accelerometer over the pads. If I was misaligned or had too much solder, I would end up with solder bridges below the sensor that would cause my board to fail--and I wouldn't even be able to tell, since they'd be entirely hidden below the sensor.
Holding the accelerometer in place (and my breath), I then used the heat gun to reflow the solder I'd laid. I held it approximately 3-4 inches away from the board and used a gentle back-and-forth motion in order to try for even heating.
When I braced myself and finally took my tweezers away, the accelerometer stayed put. Success!
Note: I learned later that this is not a normal way to approach attaching this component, and most people fail. Instead of replicating my approach--which I actually quite enjoyed--you should just use solder paste. This will help the component you're placing stick to the board, meaning you don't need the tweezer olympics.
With the accelerometer in place, I added my other few components and ended up with a cute little breakout board to match my devkit.
With both my devkit and accelerometer breakout board finally done, it was time to put them both together!
This first meant cutting and stripping some wire to make my own connectors.
Then, I had to figure out which pins on my microcontroller to connect to, and how to wire everything together. I checked the data sheet for the ATSAMD-21 microcontroller, and then for the ADXL343 accelerometer .
I determined that I needed to connect pins 16 and 17 (physical pins #17 and #18, the data and clock respectively) from the SAMD-21 to the accelerometer. I used the green wire for data and the yellow wire for clock, with black being ground and red being power.
(Note that my images below are actually incorrect. My yellow and green wires as pictured are connected to the wrong pins on my devkit. I switched them to the correct pins after my first test failed.)
Then, I connected the whole thing to the computer using a mini USB cable.
I used Arduino IDE to program, referring to this incredibly helpful page from Adafruit (which I wish I'd found earlier, since it's also a useful reference for the wire hookups): https://learn.adafruit.com/adxl343-breakout-learning-guide/arduino.
I defined the relevant pins as noted below and added a delay of (50):
Then, I flashed the board with the new code.... and it worked!
I was able to open the Serial Monitor on Aduino IDE to get a scrolling list of numbers representing data collected from my accelerometer for the x- y- and z-axes as I waved around the accelerometer breakout board.
Then, I connected the whole thing to the computer using a mini USB cable.
Opening the Serial Plotter showed a graph of this data. It was exciting to see it respond in real time (or pretty close to it).
And... DONE!
This week was very long, but also exciting! I feel a bit closer to my final project, and also relieved that having made my own devkit should set me up for success in future weeks.
On to the next challenge!
created with
Website Builder .