Self-Monitoring, Analysis and Reporting Technology.
That’s a backronym if I’ve ever heard one.
Basically, my laptop’s hard drive is dead.
Self-Monitoring, Analysis and Reporting Technology.
That’s a backronym if I’ve ever heard one.
Basically, my laptop’s hard drive is dead.
So, my attempt at make home-brew etchant before was a miserable failure, but I think I’ve found the solution:
Hehe…get it?
When you feel like doing some really rapid prototyping and don’t want to wait around for a board to come in the mail, you usually have to print a board of your own. I’ve done this a number of times (the original bullet counter was a home-printed board).
The whole process has a number of steps (which I will be going into in another post), but one of them involves printing an acid-resistant substance on a copper sheet and dissolving the un-coated copper in an acid. As I have mentioned earlier, I had some really crummy ferric chloride acid that didn’t do a very good job of etching my boards. I would usually end up sitting around for an hour or so waiting for it to etch only to have the etchant start to eat under my etch-resist while other free portions were still un-dissolved.
Ferric chloride is also kind of pricey, so I decided to try my hand at some home-brew etchant. I found a recipe online that calls for just two ingredients:
Muriatic Acid (HCL) and Hydrogen Peroxide (H2O2)
When I was at the rock gym last week, one of the staff members had some gloves with blinking LEDs in the finger tips and was dancing around like an idiot. A friend of mine was jealous and said in passing “you should invent something for me to swing around so I can go to a rave.”
Continue reading
So, I finally figured out what the deal was with my accelerometer needing to be asked twice what the value was.
As it turns out, I wasn’t actually giving the chip time to reply. I thought the micro would automatically handle receiving the data value, so I all I had to do was send the ACK at the end. In fact, the command that sends the ACK actually tells the micro controller to wait until the entire data byte has been transmitted, and then transmits the ACK.
So, when I was storing the value before sending the ACK, I was storing the value that I originally had in the register (the address of the accelerometer chip) and then waiting for the data and finally sending the ACK. Now, I’ve changed it so that it waits for the data and sends the ACK before storing the data value in the register.
How did I figure all of this out? With an O-scope! I simply modified my code so that it would give me a voltage spike on one of the output pins while it was reading the data from the register. What I noticed was that it was spiking before it was supposed to. Here’s an example of what I mean:
So, you haven’t seen an update out of me in a while. This is because I’ve been struggling over the past week with getting my clock to return accurate, or at least consistently inaccurate results.
So, it turns out that clock crystals need a “load capacitance” between each of their two pins and ground. I’m not entirely certain what these capacitors even do, but I do know that they are critical to keeping good time.
That nixie tube clock that I made originally had a clock crystal in it that had no load capacitors. This resulted in it being inaccurate.
I have a clock!
So today was something of a downer.