In my last post I talked a little about the process of picking an ARM microcontroller to start using. After doing some more research, I've decided for now to start using the STM32 line of chips. I don't really know how it stands on the technical merits vs the other similar lines; the thing I'm looking at the most is suitability for hobbyist usage. It looks like Freescale is pursuing the hobbyist market more actively, but from what I can make out it looks like the STM32 line of chips has been around longer, gathered some initial adoption, and now there's enough user-documentation to make it usable. A lot of the documentation is probably applicable to all Cortex-M3/M4's, but it's all written for the STM32's and that's what most people seem to be using. So I feel pretty good about going with the STM32 line for now -- I'll be sure to post once I make something with one.
Within the STM32 line, though, there are still a number of options; I've always been confused too why different chips within the same line are so non-portable with each other. Even within the same sub-line (ex STM32 F3) at the same speed and package, there will be multiple different chips as defined by having different datasheets. I also ran into this with the ATmegas -- even though they're "pin and software compatible", there are still a number of breaking differences between the different chips! I guess I had always hoped that picking a microcontroller within a line would be like selecting a CPU for your computer: you select the performance/price tradeoff you want and just buy it. But with microcontrollers I guess there's a bit more lock-in since you have to recompile things, change programmer settings, etc.
At first I was planning on going with a mid-range line of theirs, the STM32 F3, since that's the cheapest Cortex-M4. Turns out that the different between Cortex-M3's and M4's is pretty small: M4's contain more DSP functionality (multiplication and division operations), and an optional FPU (which is included in all STM32 M4's). It looks like the F3 is targeted at "mixed signal applications", since they have a bunch of ADCs including some high-precision SDADCs. I thought about moving down a line to the F1's, which are cheaper M3's that can have USB support, but in the end I decided to move up a line to their top-end F4's. Even a 168MHz chip only ends up being about $11; a fair bit more than the $3 for an ATmega328P, but once you consider the total cost of a one-off project, I think it'll end up being a pretty small expense.
My first intended use is to build a new JTAG adapter; my current one uses an ATmega328 and is limited to about 20KHz. My development platform project, which I keep on putting off finishing, uses a lot of CPLDs and will soon start using FPGAs as well, so JTAG programming time would be a nice thing to improve. Hopefully I'll have something to post about in a few weeks!
Pretty much all the electronics projects I've done so far have used AVR ATmega chips as the central microcontrollers. I've been meaning for a while to step-up into the world of ARM chips: it looks like you can get chips that are much more capable at just around the same price as an ATmega328P, but you can also get chips that are vastly more capable at slightly higher prices.
The problem I'm running into is that the ARM world is way more fragmented than the 8-bit microcontroller world, since ARM's business model is to license out their IP. So choosing a chip isn't just a question of choosing a processor core and performance tier, but also more-or-less investing in learning a specific company's chips and toolchains.
There are a couple prominent lines out there; in the "AVR replacement" range, it seems like the two ARM processor types to consider are the Cortex-M0+ and the Cortex-M4. The M0+ is, as suggested by the name, the lower end of the two, so I'm mostly restricting myself to looking at M4's. Within that category, there are still a lot:
And maybe more. Looking around at other hobbyist-type projects, the only ones I'm seeing pop up are the STM32 and the Kinetis lines. STM32 probably wins by raw count of number of times I've seen it. Kinetis has the potential advantage that Freescale makes the only hobbyist-available Cortex-A9 chips, ie that have a fast 1GHz+ core like in your phone. I'm not sure if that's enough reason to choose their lower line of offerings, but it at least signals to me that they're more invested in the DIY crowd. I've scanned through the datasheets for both the Kinetis and the STM32 and they both seem pretty reasonable; they both have a similar number of Google search results.
The development boards for these things are surprisingly cheap: $18 and $10 for the Kinetis and STM32, respectively. I bought both of them and I'll try to play around with them; if anyone has an experience with this or an opinion either way, I'd love to hear it!
I've never really understood Richard Stallman and what he fights for, but with this recent email of his to the gcc list (on a thread about the impact of the GPL vs the BSD licenses on the gcc vs clang projects, which is worth a read), I think I have a better idea. It starts very simply:
Non-free software is an injustice.
After reading that, I think I have a much better understanding of both him and free software debates like the one that email was on. I think this is a case of one side seeing the argument as a technical one, and the other seeing it as an ethical one. The best analogy I can think of is abortion: it doesn't matter how many stats might be true about abortion leading to better lives, if you believe abortion is murder, then there's no way that the benefits could justify it. Furthermore, it'd be pretty understandable to think that people suggesting murder have pretty troubled consciences. You'd be seeing the other people as saying "hey I think murder is ok, but to each his own right?" which is something that I hope you're not ok with.
In these cases it feels silly to try to reason with the side that sees it as an ethical problem, since to them it's inherently not about what is reasonable or not. I'm not trying to say that that makes them "unreasonable", just that that particular point is one to which they don't think reason applies. For instance, the "correct" reaction to A Modest Proposal is abhorrence, no matter how much "sense" it might make; it doesn't mean that you don't understand the need to fight hunger, just that you think eating babies isn't something that is in the class of things that can be justified.
I feel like whenever I realize this about a debate I relax a little, because there isn't much you can do: either you think there's an ethical problem or you don't. While the ethicists can debate on it, I feel like there isn't much grounds to say that one ethical stance (issue vs non-issue) is more justified than the other. I think the only thing to be done is what some hardcore FSF people are decrying as a "popularity contest", and to lay out the arguments for both sides and see how people feel. For example, conspiracy theorists might be able to come up with a theory that can't be refuted and claim that whether it happened isn't a popularity contest, but I think people might say something like "most reasonable people would not agree with that argument" or that "the general agreement is that it didn't happen"; I think the same kind of resolution-system applies to these debates.
Anyway, I don't believe that fetuses are people or that non-free software is an injustice; I'm happy to get the sense that popular sentiment is going in that direction as well, but so long as there are people who view the issues ethically, I don't think the debates are going anywhere.
As I've moved to smaller and smaller parts, I've spent more and more time inspecting small details of my boards. I've bought a couple things that I use for this purpose: a simple 10x loupe, a maybe 2-3x magnifying glass that I took from a helping-hands thingamajig that I don't use, and this magnification visor. That last one I use pretty regularly when I'm soldering, and has a flap that lets you choose between 1.5x and 3x which is pretty nice. The other two I use when inspective my work afterwards, since they're slightly nicer but require a free hand to use. I also use them to take pictures from my phone in order to increase the optical magnification.
The last thing that I've wanted, which I finally got, is a USB microscope. I caved when I saw this one for only $27 since that's "what the heck" money, and to my surprise it's relatively easy to use (even on Linux) and has decent quality. To get it working on Linux I had to install guvcview, which worked like a charm.
The microscope claims "20x-200x magnification", but it looks like the magnification is fixed at 20x and then I presume their software will do 10x magnification if you want. The stand that comes only gives you enough space to barely keep the microscope above a circuit board with its components; I did some testing, and it looks like the maximum focal length is about a foot, so it's capable of taking much wider pictures if you can somehow keep it steady. All the photos I took are at more-or-less maximum detail.
Here's a sample pic, of some hot-fixing I did on the board I was playing around with:
There were orginally four capacitors in a row here, but I took these two out and shorted them, and used some component leads to help the solder bridge the gap.
One thing that I check the most is the soldering quality on SMD parts. Here's a pic showing some of that:
Unfortunately I'm not sure that this works so well for that purpose; I'm not sure what the biggest issue is, whether it's the glare from the LED backlight, or maybe if it's just a limit of using a mono-microscope instead of a bi-microscope (not sure what the actual terms are), which limits the perception of depth. Here's a test with the backlight off, that I took to see if that reduced the glare:
I tried to not disturb the alignment, but it's basically impossible to keep the microscope exactly steady as you make any adjustments to it, such as changing the backlight power, or changing focus.
And lastly, a picture of where there was a fire:
For this picture I moved my lamp closer to the board and used that instead of the LED light, which I think gave a much nicer picture, though there is a big shadow from the microscope itself.
I'm not sure how much I'll be using this, but so far it's been fun.
I have a pretty simple-sounding circuit I want to build, but am surprisingly having quite a bit of difficulty finding any guidance about it on the internet (maybe I haven't found the right google term?). It's this: I want to provide a battery backup to a system, so that it can seamlessly switch between being plugged in and not. When plugged in, though, the battery should recharge. This is how any portable consumer device works, but surprisingly not how people seem to use batteries in the DIY space. So the question is, how exactly do you make the system switch between the battery and the charging-source?
The simplest, most straightforward way is to set up your charging circuit and then connect the load directly across the battery, like this:
When running on battery power, the battery will just feed the load; and when plugged in, the charger circuit should split its power between the load and recharging the battery. And if the load draws more than the recharger can provide, the battery should make up the difference. Maybe you should add a diode so that the battery voltage doesn't back-flow into the charger IC, but you get the idea.
But the question is, is this safe? It seems to me like it should be, but with lithium batteries I don't want to take anything for granted. Surprisingly, I haven't found any sources online saying whether it is or isn't. There are plenty of people who offer complicated schematics, and I can come up with explanations for why they might be better, but I haven't seen any explanations of why the easier option isn't sufficient. One reason the complicated options are better is, for example, is if you connect the input voltage directly across the load (and use a transistor to control whether the battery is connected to the load), this lets you use the full capacity of the charger for the battery, while still powering the load (in the simpler design, the charge current is split between the battery and the load, increasing charge times). This doesn't seem like a huge drawback for my use case, though, since recharging time isn't the most critical.
Maybe there is some issue that the charger will preferentially charge the battery instead of powering the load, though my feeling is that since the frontend of the load will be a voltage regulator, the regulator will try to make that not happen; in other words, the regulator should provide a much lower-impedance path than the battery (assuming the load is under-powered) which will take the vast majority of the current.
Anyway, if anyone knows more about whether this is done or not, please let me know, since I'm about to build a circuit like this!
Update: well, I don't really have any more answers, but one thing I think I've decided for myself is that I want to build an undervoltage-lockout circuit, which shuts off the power from the battery when the voltage gets too low. This is for the safety of the battery, since it will over-discharge itself, which is bad for the battery, and who knows it's probably unsafe too. Since I'm planning on having circuitry to disconnect the battery from the load in this situation, it seems like it won't be too difficult to update the "turn off" condition to also include "or if the USB adapter is plugged in".
I spent all yesterday dealing with some mistakes I had made in some boards; I thought I'd blog about it because 1) I spent time on it and want to feel like something came out of it :P, and 2) because I think it might be interesting to someone. Personally I find it very interesting to read about things that go wrong, since I think that that can give a better idea of how to accomplish something than just seeing a success story. When I first started out making circuit boards I had a vague idea of what kinds of things are important, but had no idea what that meant I should actually worry about, so as a result I ended up worrying about everything! Now, I'm starting to develop a sense of what types of things I tend to regret about my designs and I'm gradually getting more focused, but I definitely have a ways to go.
This post is about two specific circuit boards that I made multiple mistakes on, but I thought it'd be worth mentioning what things I normally don't like about my boards. The most common thing I run into is not knowing how to "design for manufacturability" (DFM); on every single board I find myself thinking that the board is obnoxiously hard to validate once it's assembled. Typically this means that I don't have test pads or labels for signals that end up being important; I've learned to always break out and label power nets, but I still find myself trying to touch my scope to the specific pin of a TSSOP part (the hardest part is looking at the screen while not shorting that pin to an adjacent one!). This is pretty clearly a balancing act; I could break out every single signal, or go back to through-hole parts, but at a cost to circuit bulkiness. One thing that I've found quite helpful is to expand the pads for almost all of the footprints I use, since the extra board space is negligible (it would usually be part of a route-out), and it helps a lot with hand-soldering or hand-testing. Anyway, these kinds of DFM things are probably what I think about the most now during the layout part of the design.
The second thing I end up running into is that after I have the board built, I wish that it worked differently or had additional features. Sometimes this can be addressed by leaving do-not-populate parts on the board, though at my typical quantity of 1 assembled board per design, I tend to just cut traces and green-wire when necessary. The second part -- wanting the design to have more features or be different in some other way -- I view as a natural part of any engineering process so I don't feel too bad when it comes up, but trying to make the board "feature-complete" is what I think about the most during the schematic part of the design.
Maybe interesting to know is what I don't worry about that much: I've never put too much thought into the routing of signals or power/ground nets (other than wanting to do it easily). As I've learned more about "grounding best practices", I've realized how far I am from them in all my board designs, but it hasn't seemed to affected any of them so far. This is probably due to the fairly small+simplistic designs plus the low max speeds (16MHz), but so far I've been able to avoid worrying about those kinds of things. That said, having good grounding (right now in the form of having *sufficient* grounding) is starting come up, and I suspect that these types of things will only be more important as I work my way into faster circuits.
Anyway, this was supposed to be a post about some mistakes I made; I don't consider the things I just mentioned to be "mistakes" since they're just things that I'll have to continually improve on. I've started to rush my board-design process, to both decrease the time I spend on it but also force myself to make some mistakes to see what they are, and here's what's come up:
Barely-salvaged: power distribution board
I'll talk about the setup more later, but I've changed my designs so that instead of each board having its own power input and regulation, I have some dedicated power distribution boards so that I only have to design + build that circuitry once. All good in theory, but this board has the privilege of being the first of mine to catch fire:
The fire wasn't really a mistake in the circuit board design, but more in my usage of the board. That large beige connector in the top-left is a 6-pin molex connector, of the kind that you might find inside your computer. I put this on there because I have an extra ATX power supply lying around and I thought this would be an easy way to get lots of DC power. So after I assembled the board, I plugged in the power supply and POOF a fire! I've had chips smoke in the past, but this was a legit orange flame with hissing and crackling. My dog, who usually sleeps under my workbench, immediately ran out of the room. I cut the power and things were fine, though there was some obvious damage to the board.
What happened? It turns out that there are two different 6-pin connectors on this (all?) power supplies, one for the motherboard and the rest for PCI-express boards. Well, I had just grabbed the first one I saw and plugged it into the board: it turns out that the CPU and PCI-express plugs are keyed compatibly, but have opposite polarity! So instead of feeding my 12V->3.3V regulator 12V, I was feeding it -12V, and that was the end of that. This might have been avoided if I had put a reverse-polarity-protection diode; the power supply is perfectly willing to put out enough current to fry any reasonably-sized diode, so I would have needed some sort of over-current protection as well.
I was actually able to get some use out of this particular board; I had to remove the charred regulator, but then I just fed the board 3.3V directly and then the 1.8V regulator (upper right) worked just fine. But there are a couple more problems with the board that you might be able to notice.
The first is the unpopulated barrel-jack socket in the bottom left. You can see that the silkscreen calls for a center-positive plug, but the 12V line goes to what is definitely *not* the center of the plug. This was a result of me misinterpreting the schematic symbol for the Eagle part I obtained (from SparkFun, like usual), and not double-checking the board layout to make sure it matched my expectation. I wasn't too bummed about it since this was just the backup way of getting power onto the board, with the ATX connector being the intended one. That being said, I think I would have rather had the barrel plug because that cable is much more flexible than the ATX power supply cable, which ends up more-or-less fixing the orientation of the board while I use it.
The second major problem with this board is the messed up oscillator, the silver box roughly in the middle of the board. For this one, this was a mistake in me reading the datasheet: for some reason I thought the Enable pin was active-low, when in fact it was active-high, so I in order to get it to work I had to cut some traces and green-wire.
I wasn't able to get the 12V circuitry working on the board that had the fire -- even after replacing the IC that caught on fire, the board didn't work correctly. At that point I decided that debugging a previously-on-fire board was probably a losing battle, so I ordered the parts to make another one, which now works quite well (barring the missing barrel plug socket):
Not recoverable but still interesting: jtag board
I'm using JTAG a fair bit in my current project, for which I built my own JTAG adapter. It was an interesting exercise to understand how the whole thing works, but the result is pretty messy:
It's a little tough to see from this picture, but the way this works is I have a USB connection from my laptop (grey cable coming in from the left), which connects to a CP2103 (USB<->UART chip) breakout board, which connects to an arduino-like board, which then connects to a breadboard where I'm doing level-shifting, which then connects down to the project itself (out of view). I've found the laptop->CP2103->atmega->breadboard toolchain to be quite good for prototyping and development, but it's getting cumbersome and involves quite a few wires. So, I decided to coalesce all of this into a single circuit board in order to make it easier to manage, and here's what I came up with:
As you can see, the through-hole components are unpopulated because I realized that the board wasn't going to work. This board has given me quite some trouble; here's the first run of it, can you spot the difference?
The problem was that I used the wrong footprint for the FT230X, the IC right next to the USB port. (Note: SOP != SSOP, not by a long shot.) I noticed the problem pretty quickly, but only after I had sent out the design to OSH Park for boards and OSH Stencils for a stencil. It was a pretty easy fix, so within a day I sent the new boards to OSH Park, but I forgot to have another stencil made! So yeah, there were a few issues through that process.
I actually managed to use the wrong stencil for the board with reasonable results. The only main problem was that the USB connector was completely misaligned and not connected; not sure if this was a result of the wrong stencil or a bad footprint or what (I used a generic micro-USB footprint, not the one suggested for this particular part). Re-soldering the USB socket was particularly hard because the FT230X, the TSSOP next to the connector, is so close that it was very difficult to fit the soldering iron or multimeter probe in there. (This kind of proximity issue is actually one of my most common ones, and I'm still not great at anticipating it.)
So I got the USB port resoldered, but then I noticed two problems with the ATmega part of the schematic: first, I had forgotten an ISP header to flash the code. For my existing jtag setup I had pre-programmed the chip with a bootloader, and since it was talking serial I could use the bootloader to load new versions. My normal approach is to use my ZIF-socket-programmer to burn the bootloader for DIP chips, but this is a QFP so I was out of luck. What I did instead was I soldered it to another project that uses the same footprint and does have an ISP header, then burnt the bootloader onto it, then removed it and resoldered it to the current board. This was actually all-for-naught, since I burned the wrong bootloader code onto it, so I actually soldered tiny leads onto the four relevant IC pins, and then connected that to the programmer, and flashed the correct bootloader.
Actually, I wasn't able to do that right away, since I noticed that I had messed up the ATmega crystal circuit. It's a very simple circuit and I guess I assumed that I knew it well enough to not look it up again, and so of course it ended up messed up. I had to do some more greenwiring, which included soldering some through-hole capacitors onto the back of the board. But after I did this, I plugged in the USB and saw the bootloader flash the LED!
In the midst of all of this, the USB connector came off. This micro-USB socket has only SMD pads, and is very space efficient, but is very hard to hand-solder (I was doing this with the wrong stencil so I didn't reflow this part). It actually left me in a pretty weird predicament since all the connections broke except for one, while the cable was still plugged in! Do I rip the last pad off, potentially lifting the pad? Do I use pliers to try to remove the socket from the cable without putting force on the board? (tried that and it didn't work) Or do I use my soldering iron to undo that last joint? I was pretty wary of doing that last one, since I learned the hard way that for my fancy Metcal soldering iron the soldering head is actually electrically hot, and Bad Things can happen if I use it on a live circuit. After I tried using pliers unsuccessfully (not possible to get a good hold while the board was still half-attached), I finally just resorted to using it and everything was fine.
After reattaching the USB socket, I was able to boot up my circuit and use the bootloader to flash my JTAG programmer! Everything was going great until I then connected the adapter to my JTAG circuit, at which point it promptly stopped working -- I don't even get the led flashes from the bootloader any more. I'll look into it more later, but for now I'm going to put my effort into designing v0.2 of this circuit. So at the end of the day, this circuit still isn't working, and I'm not sure it's worth investing the time to figure out why, because it lacks the breakouts to make the debugging easy.
On top of all of this, I broke one of my brand-new oscilloscope probes. I'm not 100% sure how it happened, but my guess is that it's from when I was using the heat gun to desolder the QFP ATmega multiple times, since I left the probe in that area. I learned my lesson and moved the scope to a safer part of my bench, away from the heating elements (plus also closer at hand, now that I'm learning how much I use the knobs). Luckily, 100MHz probes are only about $7 each, and the ones I bought even come with little tips to make it easier to grab IC pins.
This post ended up being less informative in the way I thought, but actually ended up being a pretty representative example of what it's like when I debug circuits. I'm sure that for anyone experienced with electronics, what I've said is extremely obvious, but I know that when I was starting out I had absolutely no idea what kinds of things I was going to encounter.
I guess this post is going to be the second in an unintentional two-part series on "things that I've spent an inordinate amount of time thinking about yet aren't the core of the electronics issues." The first was about how I've improved my organizational setup, and this one is about the process of buying an entry-level oscilloscope. I guess my hope is that it might be helpful for someone going through the same process; it's nothing fundamentally difficult about it (the different specs are well-defined and -described elsewhere), but it's certainly going to be the most exotic thing on my bench, and I found surprisingly little out there about how to actually make a choice.
My current setup
What I have currently is this oscilloscope that I bought from SparkFun (though it looks like it's sold by many other places as well), and for $60 it's actually quite handy and gets used a lot. That said, I've started to run into some limitations with it; the most obvious is that it is limited to about 1 megasamples/sec. That's my estimation based off an assumption of one data point per pixel it displays and the fact that the highest working resolution is 5us/div (they do let you go finer, but then the display stops working).
Does hitting that limitation a few times mean I should invest hundreds of dollars in a new scope? Well, there are definitely ways I can imagine a "real" oscilloscope being better and more useful (larger screen, knobs instead of all buttons), but that doesn't really mean much concretely to me, so I did some searching on the internet to try to figure it out.
Which was probably a bad idea, because the internet always seems to be full of people seeking validation for their purchases; I don't think I've ever seen a comment or blog post from someone who didn't buy something and then said that they agreed with their decision, or someone who said that they opted for the more expensive choice and then regretted it. Maybe this is an accurate portrayal and people are almost always happy buying things they want, but I think it has more to do with sample bias and the desire to justify any money spent. But it didn't really matter, because at this point I was hooked so I decided to look around.
After doing some searching, there seem to be a few options out there for someone looking to buy their first scope. In increasing order of cost:
- Don't buy one and use a multimeter
- Get a USB/"toy" oscilloscope
- Buy a used analog scope
- Buy a chinese digital scope
- Get something expensive
I did the first one (not buying anything) for a while, then did the second one when I got myself that $60 scope. I think maybe until a few years ago the "buy used" option might have been very good, but it looks like the prices for scopes have come down enough that that wasn't an attractive option for me.
For chinese scopes, it looks like the most popular manufacturer is Rigol. Their DS1052E (50MHz) model in particular seems extremely popular as an entry-level scope; hackers figured out that it was the same hardware as the higher-end DS1102E (100MHz) scope except for some firmware crippling, which they were able to remove. For a while Rigol tried updating the firmware to make it "unhackable" but of course that's not a winnable battle, and it looks like they've given up and decreased the price of the DS1102E to what the DS1052E used to be ($399) so it's now quite a good deal.
The DS1102E seems to be the cheapest reasonable scope out there, is the #1 seller on Amazon, and is the one that kept on coming up in every discussion I found, so it seems like a pretty good option.
Making the decision
I looked around for any suggestions that other people have, and true to form the internet is full of advice to go big or go home. In particular, I was curious about getting a "MSO", which is basically a scope with an integrated logic analyzer. Rigol offers a MSO version of the DS1102E, the DS1102D, for about twice the price. If you start considering that, though, there are a lot of other options in that price range, and a lot of people trying to convince you you have to spend even more money. A common argument goes along the lines of "if you're going to buy the more expensive item eventually, you might as well buy it now" -- you can see that kind of thing on this blog, which is pretty much the only other example I could find of someone walking through their decision to buy a scope.
In the past I've been pretty swayed by this kind of argument -- the logic seems unassailable: if you're going to buy it anyway, don't waste your time or money on something in between. But now I'm learning that this really isn't true: if you're having trouble with a decision like this, it's most likely because you don't know exactly what you want! So the initial purchase is an investment in knowing how to spend your later money better. So I decided to back from the $1k+ scopes and take stock again of why I wanted one -- I had started researching these on a whim and now I was being upsold quite high! In the end, I realized that the main reasons to buy a scope are 1) the upside seems decently high, since based on what other people are saying they use theirs for, it has a good chance of accelerating a interest that is currently time-constrained, and 2) I feel reasonably confident that I'll get some use out of it, since I've maintained my interest in electronics for a while.
I could go on and on about how I tried to evaluate those two points and how I've misjudged them in the past (just look at my camera equipment that got used only once), but I'm going to wrap it up here and say that I bought myself the DS1102E for $399 from Amazon (prime!), and feel good about it for now though I haven't received it yet.
And here it is! This is a picture of it measuring about 200mV+-200mV of ground bias across my circuit -- not very good! So far it's been very fun to play with, but we'll have to see about its long-term usefulness.
I don't have a particularly large or complex electronics setup, but that hasn't stopped me from searching for the "perfect" way to organize everything. I think I tend to obsess over my plan because 1) it's easy to feel like it's critically important, and 2) it's something that can be difficult to change. In software work I've really subscribed to the iterative approach to engineering, but for multiple reasons I have trouble applying it to electronics even though I feel like it should transfer. I think the first reason is that iteration often involves spending money, which feels more irreversible than spending time -- I'll talk about this more in my next post. The other reason is that iteration is more difficult when the work is physical, since you can't automate tasks anywhere near as easily.
Anyway, I recently changed how I think about organizing my parts, and since I agonized over it for a while I thought I'd post about it.
My previous organization scheme: part-based
When I started out buying electronics, I left everything in the bags they got shipped in, but this quickly became unreasonable. I started looking around for what other people do, and it seems like the most commonly-talked about strategy -- and also the one I had seen in the labs at college -- is to have drawer units where each drawer holds a different part. So, I dutifully set out and bought a couple of those units, and started stocking them with the beginnings of an electronics inventory:
One thing I quickly found was that I was buying a TON of different components. If I wanted to experiment with a different diode, does that mean it should get its own drawer even if I only have 10 of them? What about that single 555 timer that I bought in case I wanted to play with it? And even for bread-and-butter parts like resistors, should I have a different drawer for every single resistor value?
Eventually I came to the conclusion that the "one-part-per-drawer" system requires a decent quantity of each distinct part in order to make sense. So, the next thing I did was I bought a pack of coin envelopes, to serve as a means of subdividing parts within the drawers. Unfortunately the envelopes don't quite fit inside the drawers; for some I cram them in anyway, but for others I 3d-printed some boxes of the right size, and put ~20 envelopes in each:
This works great for the parts that I use in every project and need quick access to; I still use this scheme for resistors, capacitors, and leds. This also has the benefit that I can write more information on the envelope than was feasible to put on the drawer, so I can put the exact part number for later reference.
I thought this was about as well as I could do, until I found myself doing something quite different: I started buying parts for a project at a time, and until I was ready to start the project I would leave the parts in the shipping box. This was mostly out of laziness, but it made it much easier to gather the relevant parts when I finally was ready. I also noticed that I was still buying tons of new components; I tried to use ones I had bought before when I could, but each project usually used at least 5-10 new parts. These observations led to my new-and-much-improved system:
New scheme: project-based
The combination of 1) using new parts way more often than I anticipated, 2) noticing how much easier it is to start a project when all the relevant pieces are already together, and 3) running into the issue of not remembering why I had bought a certain part (which project was that particular regulator for? which projects did I decided an ATmega8 was ok and which ones are the ATmega328's for?), all led to me to adopt this system that I had already begun using.
So, what I'm doing now is I put all the materials for a project into a quart-sized ziploc bag, and then I put all those bags into a box under my desk. Actually, I'm working on a new project that has multiple sub-projects, so for those I put all the quart bags into a gallon bag which then went into the box. The choice of ziplocs and a cardboard box aren't final -- I'm using them because I didn't have to spend any money in order to test if I like the overall idea, but they're actually working quite well. Eventually I might buy some larger stacking bins that might be easier and more compact.
So far this has served me pretty well, especially since I realized that a project has more components than just the electronic ones I had set out to organize: for instance, the PCBs, stencils, and any assembled versions need to be kept track of as well. In the past I had separate places where I stacked all PCBs, or all stencils, or all built boards, which was fine when I had a total of five projects or so, but the new system makes it far easier to find the parts, and also find a home for things that used to not cleanly fall into one of the piles I had (ex: where should I put notes about a project?).
Long story short, I feel way better about my organization once I made the switch from placing similar parts together, to organizing everything by project. I'm not sure why I was so convinced that things had to be organized by part; this change might seem like a small deal, but trust me it makes a huge difference.
Today seems like a pretty good day to rag on bitcoin, so I thought I'd post about something I've been thinking about ever since I experimented with writing my own miner. Since the goal of that project was educational, I went through it in a way that most other people probably don't: I built a complete system (everything from the miner to the network interfaces) from scratch (no bitcoin-related libraries), which I think gave me some visibility into parts of Bitcoin that not many people see.
And what I discovered is how trivially hackable the system is right now. People talk about the security of the underlying crypto that's used, but any security person worth their salt knows that the security of an entire system is way more than the sum of the individual components. And in this case, the vulnerability I saw has to do with how people use Bitcoin and how the Bitcoin ecosystem is not secure.
To give a sense of the level of exploitability, I think the attack could be pulled off by a motivated individual, provided they are willing to let it be detectable+traceable. Defeating the traceability is most likely within the means of any reasonable government or cybercriminal organization, and making the attack undetectable is beyond my understanding but seems certainly within the means of a large government. I'm not familiar enough with Bitcoin to know what the most valuable targets are, but the attack I have in mind can give a varying amount of control over the blockchain, which I assume is the holy grail.
The easiness of the attack boils down to the fact that most of the Bitcoin ecosystem players don't use basic internet best practices, potentially due to an assumption that they are unnecessary because Bitcoin is "inherently secure". Implementing something to be part of the ecosystem made it very clear that certain aspects were vulnerable, which makes me think that people haven't paid too much attention to how everything is fitting together. Regardless, even if all ecosystem players adopted best practices, the security of the Bitcoin system would still rely on internet-level security measures, and thus is probably tamperable by the NSA.
The weakness stems from the fact that even though the underlying Bitcoin protocol is decentralized, the ecosystem services around it very much are not. I don't think this is a solvable problem within the Bitcoin ecosystem, since these services are naturally more valuable the more centralized they are, and thus everyone's incentive is to contribute to the centralization. It's my belief that for a cryptocurrency to be truly secure, it has to be designed with the entire ecosystem in mind; I don't think bolting on the necessary services is likely to be successful.
Can't make this up:
The smart fork that coaches you into healthier eating habits.
The HAPIfork is the world’s first smart fork. It’s an electronic fork that lights up and vibrates when you are eating too fast. As it takes 15-20 minutes to feel satisfied, by simply slowing down your pace while eating, you will consume fewer calories.
Pair with your smartphone or tablet over Bluetooth® to see your eating stats in real time.
Download the HAPIfork app for iOS or Android and connect it to your device via Bluetooth® to check:
- How long it took to eat your meal
- The number of "fork servings" (each time food is brought to the mouth) per minute
- A timer to help you pace your fork servings
- Actual intervals between fork servings
- Your success rate and overspeed ratio