Author: fysu

This week I was mostly invested in experimenting with the mics because those are still not done and I think that’s more important than iterating on the casing.

After our presentation Monday, Prof Fedder met with us to look at the peak detector after the mic output because he thought our graphs looked different than what he expected. Turns out, it was the usual culprit of bad connection due to not soldering things because we didn’t want to make something permanent before we knew if it worked. (Ironically, we would still not know if things worked because the bad connection results in unstable results.) So after I soldered on some female header pins to go along with the male ones on the board, we got some much more stable results on the mic. This led to needing to double check the mic resistor values we used, as Katherine thought there wasn’t much difference between the 10k and 33k earlier, but now we can’t trust that because of the poor connection being a confounding variable.

She can probably tell you about those shenanigans more in her report, but the reason it matters to me is because the PCBs were expecting SMD resistors, so if the values in the PCB lab don’t match up with the ideal resistor values, then we were going to need to be creative in order to get that value. For example, the highest resistor value on the datasheet is 33k, but we only have 10k and 100k. In particular, I tried 2 approaches: stacking SMD resistors (three 100k resistors in parallel is about 33k) and soldering through-hole resistor legs to a SMD pad (can directly pick a 33k through-hole resistor). Theoretically, it’s also possible to do things like place the resistors in teepee style or Stonehenge style to be in series, but stacking them directly on top of each other was already a lot of work because of how small they were: they are easy to nudge out of alignment, and stick to the tweezers. Both the approaches I tried worked when tested with a multimeter! This is great because that means we don’t need to order new SMD resistors, which would take more time and delay us even more.

Funnily enough, we ended up not needing to stack resistors, because we discovered that the 100k seems to be more sensitive than the 33k in providing a larger range of values (which would be helpful for scaling/converting to dB). For 33k, the range was very small, around 50mV, but for the 100k we had about 300mV range.

So the next step was making the new PCBs. We are trying out the hard boards first to sanity check some things such as the new mic resistor value. This time, whoever made the stencil was clearly not doing their job properly, because the offsets between each of the 3 board strips were larger than the actual distance: basically, we could only align one strip at a time 🙁 This meant needing to pre-cut the boards before they went in the oven (otherwise, the stencil would smear previous solder paste when we tried to move on to soldering the next strip), which leads to the PCBs being smaller and later, which lead to the middle PCB flying off the rack and being a sad pile of unsoldered parts (the lights, capacitors, and one mic fell off before they could be soldered). Trying to spot-fix things with a heat gun didn’t work because the air would blast away all the other pieces out of alignment before the solder could melt. Next time, we will try to group all the PCBs nearer to each other so hopefully they will not be blown away. This may not be a problem with the flex PCB because the board strip can bend away from the stencil after solder paste is applied to avoid subsequent smearing, so we can keep the PCB in one piece in the oven. Another tidbit about the new boards: because of the Fusion360 grid snapping pain I mentioned a few weeks ago, the right mic of the board is a little bit closer to the LED pad than the left mic. Hypothetically, it should still be enough room to not interfere. Based on mic validation tests, the right mics of both boards didn’t respond to anything compared to the left mics. But we also only have 2 boards so far, so it could be due to small sample bias.

Unfortunately, even for the left mics, when we tried to recreate the large range we saw earlier with the new PCB it went back to being around 50mV, which is very sad. Not sure how much of this is due to the different testing environments, since the first room had a lot of background noise and the second room didn’t.

In terms of scheduling, the stuff I’m officially tasked with, which is casing construction and Arduino code integration, are still blocked from being finalized by the whole “things aren’t all working yet” that I’ve also been talking about for the past few weeks. I made a basic mock-up of the case already, but I can’t try sealing it yet because again we are still using the boards for testing, so it’s more convenient for the board not to be in the case for that part. So in reality I’ve just been continuing to help with trying to get the mics to work. For the next week, if the mic (and battery, beetle, bluetooth…etc) issues are resolved, then I will be making a lot more PCBs, presumably both flex and hard PCB just to be safe. And then I will finalize the casing structure with the board inside.

The two main things I’ve done since the last progress report are related to the PCB, case assembly, and testing.

First, I remembered that I have IDEATE access so I went to the physical computing lab to look at what they had. Happily, they have the fast-switching Zener diodes that we need, so we don’t need to order those anymore. They also have a variety of op-amps (which we thought were needed at the time) and Polulu boost converters so we don’t need to order any of those anymore, and I also took some buttons and switches. Then I also went to the PCB lab to count out the SMD resistors and capacitors to make sure we have enough of all our values. I labeled each strip since there’s no markings on the components themselves.

As a side quest, I also noticed that some of the header pin connections weren’t adequate (since the holes were still visible), so that made me wonder if that’s the reason the lights don’t work for all the boards. Especially since the lights are big enough and the soldering pads are far enough away that I can clearly see that SMD solder connections shouldn’t be the issue. After touching up the connections, we now have all the board’s lights working properly! Woohoo! That means the success of the boards only depends on mics, so by redoing the calculations, we’d need about 10 boards to be safe. Turns out the minimum number we can order is 15 so this will be fine (we bought enough Neopixels for about 28 boards so this will be fine ish, even with 2 designs which would be 30 boards total). I also took this opportunity to demonstrate how to solder to Katherine so she could try different resistor values for the mics (even electrical tape had a slightly sus connection, so soldering was necessary to properly test).

Next was redesigning the PCB to include the peak detector. For a while, we were debating whether we needed the op-amp. I preferred having as few components as possible since we were running low on space and it was going to be difficult to route things around such a large object. Prof Fedder also drew a simpler diagram where we only needed the “top half” of the peak detector, since we didn’t really care about enveloping the bottom-half of the signal, which further reduced the number of components in the original diagram by half. After Katherine did some simulations in Lspice, she confirmed that we don’t need the op-amp, thank goodness! That made my life easier. What didn’t make my life easier though, was Fusion 360 being weirdly different since the last time I designed it. For some reason, some components just didn’t snap to the same place in the grid as they did in the previous design, even though the grid granularity and components were the same. This was solved somewhat by rearranging the component order and then putting them back, or just sucking it up and saying “this slight difference shouldn’t affect the functionality” and moving on. Katherine did some calculations for the trace width resistance and ordered PCBs.

 

Cutting the plastic for the casing was also such a big pain! The tubing was decently easy to slice along the open edge, but the knife (and all other pointy objects I could find) were all not sharp/strong enough to puncture the tubing for cutting holes. I tried drilling to make the hole bigger, but the drill bit ends aren’t sharp enough to do much 🙁but it made the hole slightly larger so I could try fitting a small wire cutter in there to widen the hole. It took so long, and the hole ended up looking very jagged. Later, I realized that the battery couldn’t fit through the opening, even when squishing the pipe, and especially not if you need to add a PCB on top of that. So we’re not going to be using the tubing anymore.

The back-up option was the rectangular plastic wrap, which we’d need to measure and cut and glue together again. This is more work than being given a tube, but it gives more customization options (and the plastic is also much thinner). It has the same problem as the tubing where it’s pretty puncture-proof (this is pretty good for durability, but it’s a pain when we’re trying to make holes), but a helpful Techspark person showed how to use the hole-puncher, so we were able to make some holes where the mics would be. I also tried the method of just gluing the edges of the top and bottom pieces of the plastic together, and testing the durability from bending. It starts off ok, but it takes a lot of glue to seal it well, and over time the glue cracks and the edges start opening.

So for the next iteration I tried overlapping more surface area (thus, making the top piece of the casing much larger than the bottom piece). This time, I calculated how much I’d need for each piece instead of guesstimating. It’s hard to guess exactly how much I need because there are some variables that are hard to measure, such as the curve of the top piece. However, I think the sizing is all right because the height of the bracelet can be adjusted based on how much is overlapped with the bottom piece.

Prof Fedder also suggested that we need some netting to help protect the mics, so I found this plastic netting that we could use.

Originally, we planned to be done integrating (including the case) and onto testing by now, but of course that hasn’t happened. It’s hard to know if the casing design I have now will be greatly affected by having a flexible board instead, but I’ve discovered so many roadbumps in creating the casing that I think it’s important to keep going through the building process, even if it needs to be with a hard PCB. I aim to have a case finished by Wednesday (as in, the case is glued together, has the correct number of holes, and fits the battery and PCB with some room to spare). If the flex PCB arrives early enough, perhaps I will have time to test the fit and make adjustments before the next status report as well. I also plan to assemble the PCB with Lucy like last time, and also try to debug the button press.

Throughout this process, the way I’ve learned new things is through a few methods. Mainly, I try searching for tutorials (ex: on YouTube for PCB design like creating library components), and reading forums for how people have solved similar problems). In addition, I think an important method is knowing who’s an expert and consulting them for questions. The obvious one is our Prof and TA, but this also includes classmates (who are working on similar projects), and Techspark people (since they know what specialized tools are available and how to use them).

This week, I mostly worked on mic-related stuff, but also tried out the casing assembly.

For the casing, I gently placed the board into the tube to check the fit, which it did.

The tube is easily compressed, so even if the board is flexible, there should be enough room such that it won’t get caught on the walls from friction and buckle. If that doesn’t work, I still have the option of cutting some notches in the tube to expand it even more (probably needed some holes for the mics to work well too). For the ends, I think I can get away with not needing to laser cut acrylic stoppers and instead just press them into a line with enough hot glue and/or tying them down with the thread. The folding doesn’t quite close all the way because of the curve, so I cut a notch into the side to help it meet. You can see the pictures for a comparison.

The only thing I didn’t try was drilling holes into the tube, because I didn’t think of that idea (the box cutter knife I was using to cut the tube worked pretty well, but those are better for slits than holes). I can probably find a drill sometime soon to try it though.

I didn’t glue anything in because it’s probably best to have easier access to the boards while we’re testing the mics for now.

For the music session, we noticed that the number of samples printed to the CSV varied widely, from 1200 samples per second on the high end to about 800. Because of this, we started to think something weird was going on. After further research, such as refining the code to use ints instead of floats in case implicit float->int conversion was sus, since analogRead returns ints (so having a float output was useless).

Unfortunately, that was nowhere near the full problem: apparently Serial printouts are what significantly slow down the sampling, but how else would we know how fast it’s sampling at if we don’t have the printouts to show the timing? Katherine will explain more in her part of the report (continuous analog read).

Since we still can’t reliably get the mic to work, we are proceeding with having the peak detector added as a back up. We think it might be easier to have 2 types of boards made: one with the peak detector and one without, and ship them together to reduce cost. Prof Fedder since alternatively we can also have a jumper wire connection to switch between reading directly from the mic output and reading from the peak detector. Either way, that still means I have to design a new PCB and hope the components can be rearranged to still fit on the same size board (might have to increase the board side a little though).

According to the Gaant chart, I have to wait on other parts (like the mic and Bluetooth) to be done since I just have integration tasks left. However, the Gaant chart didn’t account for needing to significantly modify the PCB, so that’s going to be my focus for next week. Like this week, I’ll also probably still be working with Katherine to keep testing the mics, because we’re not sure how responsive they are still/what range of values we should be getting. For example, tapping seems to output in the thousands, while speaking is only in the tens/hundreds. This doesn’t feel quite right. (Which is why we also plan to make the modified PCB with the signal envelope detector as a backup.)

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours)

I solved a few problems mentioned in the previous status report.

1. Nothing prints in the Serial Monitor: in Arduino, go to Tools -> USB CDC On Boot “Enabled”. If “Disabled”, nothing prints.
2. Beetle connection isn’t recognized/won’t upload code: often, when I switch out a Beetle and/or data cable (we have 2 of each), the upload process will fail. Sometimes it fails because the port is grayed out and won’t allow you to connect, or sometimes it’ll say some Serial data error. Here are solutions I do to fix this:
   • Unplug/replug Beetle, restart Arduino/computer
   • Spam the Beetle buttons for boot/reset during compilation. You should hear the USB connect/disconnect sounds if your computer has those. It might not work the first time, but eventually you get the timing right and it’ll finally agree to upload. I usually do the blink test for this, since it’s pretty easy to tell if it worked. If the Arduino IDE says “upload successful”, but you still don’t see any light, click the reset button once (right button), and then the light should start blinking.
3. Lights not lighting up: at first we thought it was the Polulu boost converter not boosting our voltage to 5V correctly, because we triple checked all our connections and they looked correct. So the next solution was to find a 5V supply directly and skip the Polulu middle-man. Techspark has some of those, so after connecting the Beetle to common ground, as soon as the 5V probe touched the V_regulator pin I set up, we were treated to a glorious array of wonderful colors! They were bright and rainbow and all we could’ve ever hoped for!*

*We actually were hoping that all the boards would have working lights, but when we tested boards 3 and 4, there was no reaction from applying the 5V. It’s pretty strange, since the Neopixels are bigger and thus easier to place and solder correctly compared to the mics. We also placed all the Neopixels in the same orientation, so wrong connections shouldn’t be an issue. Our success rate for lights is 3 out of 5 boards, so 60%.

Turns out, it was just a poor connection issue with the Polulu, because if you press on the boost converter at a certain angle, the lights will turn on. We also transferred all our wiring to header pins/breadboard connections to be more stable instead of just floating around. We will be soldering it on for the final product, so that won’t be an issue. We’re just hesitant to solder things on now because things aren’t finalized and soldering is a pain to undo.

Light video

After that, we tested all the mics with Prof Fedder’s tutelage. He explained that the mics DC voltage was around half of our power supply of 3.3V (so about 1.1V). So we first use the oscilloscope to measure our mic output pins to see if we get anywhere in that range. (Unfortunately, we can’t check the mic pins directly because they’re SMD, and thus directly under the mic.) Once we have a confirmed reasonable voltage (the bad mics register voltage levels in the mV), we move on to AC voltage. The test here is to play a tone near the mic and test different distances: we should see the amplitude of the sine wave on the oscilloscope change accordingly. For the non-working mics, we just saw “noise”.

Since the mics are so tiny, it’s very hard to apply solder on them to balance between falling off from not enough solder, or shorting all the connections because the solder reflow was too much. During the PCB assembly, we tried 2 methods; on the left side (mostly likely) of each board, Lucy applied a bit of extra solder manually to help the mics stick better. On the right side, I set the mics with just the initial amount of solder that made it through the solder mask. Here are the results for the boards’ mics that made the cut.

1: both mics work

2: right mic only

3: right mic only

4: left mic only

5: neither

It looks like the right mic technique may have had a bit of a slight advantage over the left mic, but honestly since the sample size is so small I’m not sure we can derive statistical significance from this. The survival rate of mics is 50%, but if we want both mics to work, the survival rate drops to 20%.

Since LED survival rate is 60%, the overall board success rate would be 30% if optimistic, and 12% if not optimistic (multiplying the survival rates because “and” condition). So optimistically we’ll need to build 4 boards, and non optimistically, 10 (expected value math). Then we apply backup calculations by doubling these amounts to get 8 or 20 boards. They will probably all cost the same amount so it’s not much of a cost thing as it is more of a “we need to make sure we have enough of the other components”. For example, our LEDs deplete the fastest since there’s 6 per board. We used up 30 of them for the prototype boards, so we have 70 left in our pack. If we are optimistic, we would have enough if we built 8 boards, but not enough if we want to build 20 boards. Prof Fedder gave us more microphones and says he has many more, so that probably won’t be our limiting factor. We also grabbed a bunch of the SMD resistors and capacitors, and only use like, 2 per board so we should be good there too.

Then was the music recording session where, for the first time, we had both the professional decibel meter and our own DIY mics (uncalibrated). Hopefully, we would see some trends between them so we could have an idea of what kind of math is needed to calibrate our mics. I used board 1, since we established that both mics were supposed to work, and put the decibel meter and board right next to each other on the music stand in the middle between the piano and singer. Observations:

• FAST, Lo, dbA settings: during ambient noise, it’s pretty close (both in the 40’s), but when music starts, the professional mic picks up the noise way better than the board mics; think i spotted around 60 on the board mic when I moved it closer, which is still less than the 70s to 80s that the decibel meter says.
• FAST, Hi, dbC settings: ambient now around 60 on the decibel meter instead of 40, and music is around 80s to 90s. Board values still stay around the same range as last time though.
• Something a bit concerning: the left mic seems to be more sensitive and goes up to 60, but the right mic stays solidly at 48-49 the whole time, even though both of them are supposed to work and I assumed they’d be around the same sensitivity level? They have the same resistors at least. The left mic is closer to the singer, the right mic is closer to the piano, but that shouldn’t make that much of a difference? Maybe the decibel meter mic was nearer to the right mic which may affect things.

The code was sampling with delays at this point so we’d know the sampling frequency exactly. Later we just got rid of the delay to sample as fast as possible, and based on the timestamped CSV logs, it calculated about 1200 readings per second, which is abysmally slow compared to the range that singers and pianists use. So perhaps that’s why the mic readings were suffering from such a limited range/sensitivity during the music session. Katherine can tell you more about her plans for fixing this in her section.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Amazingly, I have actually finished all my tasks on time for once! I also have code that changes the color of lights based on mic readings. Since the mics are uncalibrated, the thresholds are bogus, but as a proof of concept, you can see the video in the team report where clapping changed the light color from yellow to red. We could add gradient colors to interpolate smoothly between the yellow and red (orange) through HSV conversions to show the user more precision in the readings instead of just “buckets”, but when we were testing, we noticed the lights were sometimes flashing between yellow and red so quickly that it looked orange already due to persistence of vision, so perhaps gradient is unnecessary and we can keep the code simple.

What deliverables do you hope to complete in the next week?

I can try physical fabrication of the bracelet with the hard PCB, just to have some practice. Perhaps I’ll run into surprise issues that I didn’t know were going to be a thing. In particular, since our plastic sheet got lost to the void, we only have plastic tubing right now, so I can experiment with how viable of an option that is or if we really need the plastic sheet instead. We can also test how much the mics are affected by being in plastic; although depending on how noisy the uncalibrated data is, I’m not sure if we’ll be able to derive meaningful results if testing uncalibrated.

The PCBs finally came in this week, so Lucy and I were able to assemble them in the PCB lab and hand solder on the rest.

A few takeaways: because everything is so small, the solder mask took a while to line up precisely, and we weren’t sure if there would be enough solder on the smallest component (microphones) to stick, but luckily it did. Another thing that was tricky was looking closely at the mics and LEDs since those have directionality in placing them. We are relatively sure we got the mics oriented correctly at least, since Katherine was able to get reasonable readings. LEDs deserve their own section later. Finally, we need to make sure not to run out of the SMD components like capacitors and resistors (took a bunch just in case), because apparently they’re not kept stocked and we’d have to order them, which causes delays. We could cut apart the PCB into each panel using scissors since it was thin and came with perforated marks.

Highlights of hand soldering include using tape to line up the headers relatively straight so the beetle will be able to fit properly. The single headers don’t have to be that straight because we were planning on wiring those connections.

I could now get started on trying to get the LEDs to work. At first, I tried to use the FastLED library since that’s what a bunch of example Neopixel projects on Adafruit’s website used. Unfortunately it led to a bunch of internal errors within the library itself, and everytime I fixed one, a new error would pop up. It was like playing whack-a-mole, except hitting things with a hammer would probably not solve the problem.

Next I tried the Adafruit Neopixel library since that was mentioned on the Neopixel page. That compiled fine, but then nothing happened. We tried checking the pins, debugging with print statements (nothing printed, not even in the setup() before any real code was run). Admittedly, our setup may not have been the most stable since we didn’t solder the battery/boost converter stuff yet (couldn’t find any solid core wires, which would’ve been more helpful), but I don’t think that should be the issue. In addition, we are relatively sure all of them are oriented correctly after consulting a pin out of the component online.

In other news, an ongoing conundrum has been how accurate our phones are for measuring dB. Previous data showed that each phone was relatively precise (Katherine consistently got the lowest readings and Lucy the highest), but I volunteered as tribute to formalize our findings with fun things such as box plots and outlier analysis and standard deviation!

For our recording session with the music students, we tried different variables to see how sensitive the mics are and how much specific placement really matters. Specifically, we tried trials where we lined up the phones in different orders, and for the last trial, we placed the phones as far away as possible (other side of the room).

Conclusions:

• no outliers, even with the very far away trial; it does skew the data ofc, and the box plots look more symmetrical without it
  • mostly avg and max was affected by this ^
  • std dev calculations not really affected, since everyone should be affected in about the same way
  • katherine’s avg didn’t change without the last trial because the last trial didn’t have the lowest value XD
• Lucy’s phone seemed most sensitive (largest drop) to being farther away
• Everyone’s std dev were within 2 db if ignoring the last trial

I didn’t expect the light debugging to be so difficult, especially since there’s a bunch of straightforward example code to try. That was supposed to be done by the end of this week, but I’ll try to have it done by Friday’s recording session instead, and perhaps we should meet with prof to ask for help.

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

In the previous status report, I assumed that the PCB would be at least delivered so we could at least check it out, but unfortunately that’s actually scheduled for next Tuesday. Thus, a lot of material items that I also wanted to do, such as assembling the PCB, trying out the LEDs…etc., were blocked. On the bright side, I was able to successfully set up my Arduino environment to connect with the Beetle (on-board LED blinking “Hello World” worked).

In the meantime, I’ve been working on compiling different projects’ uses of Neopixels (Adafruit has been particularly helpful). I don’t expect to be able to copy-paste code, of course, but being able to tweak existing code that I know is supposed to work should be easier to get working than writing from scratch. In addition, the multiple examples will help me understand the mandatory vs customizable components of the code. Here are the links I’ve been looking at:

• How To Control WS2812B Individually Addressable LEDs using Arduino goes over the anatomy of the LED strip, as well as has an example with connecting to Bluetooth to a web app to change the color of the lights.
• Overview | Gemma Color Touch Pendant Necklace | Adafruit Learning System necklace changes color based on touch (capacitive sensing); uses a calibration number in the code to adjust sensitivity, so perhaps we can try something similar when we are calibrating our mics
• Overview | Ursula’s Seashell Necklace | Adafruit Learning System a necklace that lights up by reacting to microphone signals. It also mentions calibration is necessary, but suggests manual hardware calibration rather than in the code (unfortunately we’re using a different mic that doesn’t have a screw to turn, but our equivalent is we can swap out different resistors to test out the gain). Finally, there are also some helpful debugging practices.
• Overview | Light-Up Costumes in Harsh Environments | Adafruit Learning System a mermaid costume, which is used underwater for cosplay. Of course, our system isn’t intended to be able to survive submersion, but it’s still helpful to know the kinds of design decisions made, such as minimizing wires at stress points, and how to connect wire ends securely.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Because we thought we’d have our PCB in this week instead of next week, all of the PCB assembly and testing of components had to be pushed as well. Our goal is to rapidly assemble the PCBs (ideally within a day or two of receiving them, depending on our schedule availability) so we can get to the coding, since I suspect we’ll probably run into errors there.

What deliverables do you hope to complete in the next week?

Since the PCB is expected to be in by then, I hope to be able to assemble all the components in the PCB lab, read up on the FastLED library that a bunch of the above projects used, and try some of their simple example code to make sure the PCB passes before trying to upload more complex code.

This week, I helped write the Design presentation, created a Solidworks model of the rough idea for how the components would look like, finalized ordering for plastic parts, and discussed more design decisions with the team.

The CAD model really helped cement some of our design decisions such as the configuration the lights would be placed (we decided in a row would look better than zig zag), and the exact spacing of parts (such as deciding the mics will go 1⁄4 and 3⁄4 of the way along the length for equidistance from the center). Because we’ll control all the Neopixels with 1 pin, this means that 1 side of the lights must be on the opposite side as where the pin is, so this will mean our PCB will have traces that travel under the microcontroller to get to the other side. This will probably be fine, since that is a design practice used in industry as well, and it won’t be traveling too far.

To finalize the size of the tubing, we chose ones with the thinnest walls because we’re still trying to minimize the size, but also I did some estimated calculations of choosing an inner diameter tubing that’s slightly smaller than the current width of the PCB. This is because we’re going to try changing the tube shape technique mentioned last week, so the compressed oval should have the dimensions we need. A final consideration that I can think of is to remember to cut some holes on the ends of the PCB so I can tie string to them to help pull the PCB through the tube, since that’ll probably be easier than pushing. Last resort for the tubing would be to cut it open and reseal, but that sounds like we might as well try the plastic sheet idea.

Finally, the idea of swapping batteries came up, so I had some ideas to add velcro to the plastic wrap surrounding it for more convenient access instead of permanently sealing it, but that remains to be seen when we interview our user group on Monday, as discussed in the team report.

Last week, I said I’d try to get to the PCB and Beetle, but unfortunately this week was pretty exhausting for all these deadlines for classes so I didn’t get to that (in addition, the Beetle didn’t get here in time early enough in the week to pick it up and start testing). PCB used to not be on the Gaant chart,and now it is. I would really like to have a PCB prototype done by the end of next week in order to utilize spring break “waiting time for shipping” effectively. The electronic prototyping with the Beetle was scheduled for next week anyways, so that’s still on track technically.

This week, I read some Beetle documentation, wrangled WordPress into displaying weekly reports properly, and made some more design decisions for the layout and materials/manufacturing.

First, I looked into finding polyester cord and cord locks. The reason I chose polyester is because I believe it would be less likely to fray other materials, and is also quite silky so it feels nice. In terms of size, I went with 3mm because it should be compatible with the cord lock size I chose (it has a small size and a simple mechanism), and seems decently thick enough to be strong.

• Amazon.com: INSPIRELLE 3mm Black Satin Cord Rattail Silk Cord Chinese Knot Thread for Jewelry Making, 50 Yards Spool
• Adjustable Cord Lock – Round Ball Style – Single Hole End Toggle for D – SpecialistID.com

Not only will the cord be used for adjustability, but I think it’s a decent way of protecting wires that connect the batteries as well (wrap/knot the thread around the wires, friendship bracelet style). Since this could be done last, it would be easier than putting tubing around the wires because that would need to be done before the soldering (unless you want to cut and reseal the tube, which is painful).

To attach the cord to the bracelet, I came up with using “stoppers” that fit the holes on the ends of the plastic tube, with a hole in the middle for the string to go through. Basically, it looks like a metal disk washer. The stoppers could be glued into place to help seal off the components from outside damage like dust/water, and a knot on the end/some glue can also prevent the cord from slipping through the hole.

Unfortunately, plastic tubing to protect the PCB was a lot more painful to find, which I will get into later.

My initial plan was to CAD model some designs so we can have a more concrete idea of what the bracelet will look like. Unfortunately, that requires some designs first, and drawing on paper is much faster, so see those sketches in the team report. The idea with those sketches was to aesthetically space out the lights such that there wouldn’t be a black hole where the microcontroller is, although it might be a bit hard to tell since they’re not drawn to scale. We’re also not sure what number of lights will be sufficient to not look empty, but also balance power usage. The reason the microcontroller is in the middle instead of the edge is to minimize the max length needed for the traces. Although if there are sufficient benefits to putting the microcontroller on the end, perhaps we will consider doing that instead.

Another annoyance is that the Beetle doesn’t have all the desired dimensions (the 25mm length doesn’t include all of the USB port, and no height listed), so we will just have to guesstimate in the CAD and PCB. At first, it seemed like the height of the PCB + components would only be about 5mm, which is great because many plastic tubes can be that size. Unfortunately, since tubes are circular, we also need to consider our width dimension, which is going to be about 30mm when accounting for some buffer room because of the length of the Beetle. We can’t rotate the Beetle to make the width “smaller”, because then the USB port would be hard to access for the user (perpendicular to the PCB board length is easier to reach, instead of being along the PCB length because of the angle the wire would have to bend to avoid other components). Finding a 25mm tube was a lot harder, and it’s also a bit of a waste of space in the height dimension. Bendable, oval tubes are also quite hard to find. So we have some options that we are going to experiment with and hopefully at least one of these prototypes will work:

1. Buy a smaller diameter plastic tube, and use heat and weights to smush into an oval shape. McMaster-Carr
2. Buy those plastic sheets that are used to cover tables, and cut out the correct shape, use hot glue to wrap into a tube shape. Amazon.com: NECAUX Custom Multisize 1.5mm Thick Clear PVC Table Cover Protector – 14 x 14 Inch Waterproof Crystal Soft Plastic Square Tabletop Protective Pad for End Table/Night Stand/Side Table, 2pcs : Home & Kitchen

Since we initially thought we didn’t need a PCB board and now we do, we will be designing that concurrently while waiting for the orders of the other parts to come in, so I don’t think we have encountered any “blocking” actions and can be relatively on schedule. If the other parts come by next week we can unit test/sanity check some things before we put it onto a PCB. I’m not sure if it would be ambitious to have a PCB ordered by spring break? That way we can use spring break to wait for the shipment.

For next week, I plan to:

• Design some CAD models of bracelet layout (they are going to be simplified boxes with guesstimated dimensions if I can’t get pre-made CAD of the objects)
• Try PCB prototypes if CAD goes well
• Read more Beetle documentation
  • If the beetle comes in I can start poking it with hello world and other sanity checks
• Think of more ideas for materials/prototyping/edge cases for how it’s built?