arm7-labrador3-oscilloscope board being fabricated

2008-04-25 by mzandrew

After a month or so of scrambling to redesign the oscilloscope, it is finally at the board house being fabricated. The board ended up being 2 layers and 99.5mm X 79.5mm. The 6mil spacing, 6mil width and 15mil minimum hole size ended up being a necessity (the last board I did was 8mil/8mil/20mil).

The oscilloscope is battery (rechargable LiPoly) or usb powered, has 2 channels of input (DC coupled only), has a 128×124 pixel color OLED display. The AtoD converter is called a “labrador3″ or just “lab3,” and it is an ASIC that was designed for use in ANITA, an antarctic neutrino detector experiment. It has 9 channels and holds 260 samples per channel in a switched capacitor array that can run at up to 3.7GSa/s. When a trigger comes, it converts all samples to digital values with 2340 parallel Wilkinson analog to digital converters (each one is a comparator + a 12 bit latch). The advantage of this way of doing it is the high-speed sampling using relatively low-power. The disadvantage of is that it can’t sample data continuously.

The input impedance of this scope is 1MOhm. The analog bandwidth is a big unknown at this point. The lab3 can sample billions of times per second, but I’ve never designed RF circuits before, so this first attempt will probably only be useful at a much much lower sampling speed. The input amplifier has a bandwidth of about 700MHz, and my sloppy, space-constrained board routing will undoubtedly limit that much further. My professor gave me the freedom to do whatever I wanted for the input stage (he suggested a different method for adding the 1.25V which I ignored) and for the routing, so I can’t blame anyone but me when it doesn’t work. The people in the IDLab did give me several pieces of advice for all this, so if it does work, credit will have to be shared with them.

The main reason to have anything but a resistive divider on the front-end of the oscilloscope is that the lab3 can only digitize voltages between 0.5V and 2.0V. In the neutrino detector experiment, the input was ac coupled and then a 1.25V DC bias voltage was set up on the input to the lab3, so there was no problem. In a general-purpose oscilloscope, however, one frequently wants to see the DC offset of a given signal, so the choice was made to make the input DC-coupled and use a summing amplifier to add 1.25V to the (attenuated) signal, knowing that that would severely constrain the analog bandwidth of the scope.

The input stage is high-impedance (4 sets of 4MOhm resistive dividers in parallel going into a 4to1 multiplexer) and has schottky protection diode pairs that limit the voltage going into the multiplexer to about +-(0.75V+the diode’s forward voltage), so a relatively high-voltage input should not destroy the device, since the current that develops through the high resistance is very small (~71uA for a 177V input signal across a 2.5MOhm resistor, the top of one of the resistive dividers). The IV curve for the schottkys that I picked doesn’t even show anything below 10,000uA and the forward voltage in that case is 0.24V, so the input to the multiplexer should never see more than +-1V.

At this point (3 weeks before I need to give a presentation on this project and hopefully show it in a functioning state), I still have to come up with a parts list (which is mostly complete), email it to the appropriate people in the IDLab to get the parts purchase ordered and then just wait about a week for the board and parts to come in, then scramble to get it soldered together, taking care at each step to see that each DC-DC converter and the input amplifier stages output the appropriate voltages before soldering down the delicate ICs.

After that’s done, and assuming it works, the rest is writing software to control the lab3 and DACs and to display the data and do some bandwidth & slew-rate testing before the presentation. Easy as pie. Three weeks to go? No problem. :) Remind me I said that in about 2.5 weeks.

edit 2008-04-25 9:21pm HST: Just FYI, there are 771 SMD pads on the top, 196 SMD pads on the bottom and 392 holes to be drilled, total and the board is ~12 square inches. For comparison, last semester’s board was ~4 square inches had 256 SMD pads on the top, none on the bottom and 126 holes drilled through.

GPL’d clock software released

2007-12-13 by mzandrew

As promised, the software is released under the GPL (v3) at http://arm7-oled-clock.googlecode.com/ (only available in a subversion repository right now).

A slight flaw was detected in the hardware design (schematics and pcb) in the last week that made it not work, so rather than release something that is known not working, I’m gonna fix it and then release. There is an easy workaround for the flaw, but no sense anyone printing boards that don’t work as-is. So the hardware design files are coming soon. Stay tuned.

presentation today

2007-12-12 by mzandrew

I gave a short presentation on my project today in class.

I took a picture of the face from an analog watch I have and had my clock display the picture behind the hands:
image2007-12-12s50-00188-small.jpeg
Yes, the “3″ is a slightly modified version of the “8.”

a word of warning

2007-12-08 by mzandrew

Don’t plug a 7.5V battery into a device with a maximum 5.5V tolerant dc-dc converter and a maximum 6V tolerant capacitor.

the printed circuit board works! (sort of)

2007-12-08 by mzandrew

After a day of wondering why the microcontroller + crystal didn’t oscillate at all, it was discovered that the 4 pin crystal was wired backwards (4321 instead of 1234). Two methods of fixing this were attempted (rotating the part 90 degrees and shifting the part on the circuit were both found to connect the two leads that were crystal to the microcontroller’s xin and xout). Both failed. It is unknown why. Guesses include using the wrong capacitance crystal, or blowing up the oscillator inside the microcontroller in some way. My vote’s on the latter at the very least since the prototype used a crystal with the internal oscillator and worked fine since September until two days ago but doesn’t oscillate anymore with a crystal.

Then, after a couple days of worrying about why the crystal didn’t work, full-size oscillators were aquired instead because that’s all that could be found locally (parts kit + electronics supply store). Both the prototype and the circuit board now function with external oscillators. The circuit board looks a little funny with such a large, non-surface mount part hot-glued to it. Not really as elegant as I wanted, but it works.

The vectorboard pictured below is just for the temporary jtag header for programming.

Inelegant:
image2007-12-08s50-00134-small.jpeg

but functional:
image2007-12-08s50-00146-small.jpeg

the arm7-oled-clock pcb arrived!

2007-12-04 by mzandrew

front:
image2007-12-04s50-00109thumbnail.jpeg

back:
image2007-12-04s50-00111thumbnail.jpeg

Here’s what it looks like populated (click for full-size):
image2007-12-04s50-00105thumbnail.jpeg

image2007-12-04s50-00106thumbnail.jpeg

arm7-oled-clock

2007-12-01 by mzandrew

Tonight, I got two things done. The first I named “vectored calls,” where I can have the clock display a completely different face based on the mode selected with a rotary encoder. The second is that now it displays latin numbers around the clock hands instead of just dots. See the pictures below.

As it was earlier today, with dots (red=hour, blue=minute, green=second):
arm7-oled-clock-2007-12-01-circle-lines-cropped.jpg

After I did the numbers thing (I think my 9 is a little wonky):
arm7-oled-clock-2007-12-01-circle-lines-with-numbers-cropped.jpg

And here’s a pic of the whole circuit board along with it just drawing the ends of the hands:
arm7-oled-clock-2007-12-01-whole-thing-circles-with-numbers-small.jpg

Note that I was able to take the pictures in quick succession because the vectored calls let me select the different display modes just by turning the knob (yes, I retook the last one a half-hour later).

arm7-oled-clock pcb

2007-11-16 by mzandrew

I finished off the design of the printed circuit board for my clock. Sent it off this morning to get manufactured ($35 for two). Here’s hoping that it works!

Here’s a rendered pic of what the front will look like:

arm7-oled-clock-rev00-small

custom Gibson SG mza

2007-11-08 by mzandrew

My roommate has Guitar Hero and he jammed too much on the whammy bar of his guitar hero controller, so he threw it away. I recycled it and made it wireless with a $14 wireless ps2 controller from Ross’s and gave it to my girlfriend for her 19th birthday. I’m 23, so age/2+7 doesn’t present a problem…

Before I started, I thought it would be simple enough. Remove the unnecessary plastic parts from the wireless controller and solder the wires from the buttons in the guitar to the wireless controller button pads. Here’s all the parts in a wireless ps2 controller:
wireless controller parts
As it turns out, there’s two problems:

The first problem is that Guitar Hero I and Guitar Hero II will both let you use a regular controller to play the game, but the buttons you use to do different things are different for the two games. For me, this meant that I had to have a GH1 and a GH2 mode, and have the actual fret buttons connect to different pads on the wireless controller based on which mode it was in. So it has 8 pnp transistors to do this (4 of the fret buttons had to be switched, 1 of them happened to correspond to controller buttons that for each game weren’t used in the other game, so it was okay to have them both down at once). Because of the mode switch and the transistors, I was able to work around this quirk.

The second problem is that Guitar Hero II treats a ps2 controller differently from how it treats a ps1 controller.
If you have a ps1 controller and you hold down the left d-pad button when you plug the controller in (or turn on the ps2), Guitar Hero I will treat it as a guitar, so you press the fret buttons whenever and strum with the up and down buttons on the d-pad. Otherwise (if the left d-pad button isn’t held down or you’re using Guitar Hero II), it requires that you press the frets down exactly when needed and this pressing of the fret buttons is the effective strum. The wireless guitar that I built still suffers from this deficiency - there’s no workaround, so Guitar Hero II doesn’t behave the same as it does with a wired guitar.

Here’s a picture of the wireless controller board with attached wires:
wireless controller board + wires

As for the broken whammy bar, my roommate threw away some of the parts for it after he disassembled it to try to fix it, so two features needed to be reimplemented:

The first was that the whammy bar base in a functioning guitar hero controller rotates on a split axle, so there’s a post on either side of a plastic piece and the plastic piece rotates when you move the whammy bar. One side of the split axle was missing. I don’t know what the original looked like. I re-implemented this with two layers of vector board and a bolt and nut and some .025″ metal wire-wrap posts and a lot of hot glue. This part works fine (although having a slightly larger bolt would have been better). Here’s a pic:
axle

The second thing was the spring that returns the whammy bar to the upright position when you let go of it. I still had the spring, but whatever it went between was long gone and/or broken. To remedy this, I put a bar of vector board across two of the four plastic posts this whole assembly fits between (and tapped the two posts and screwed the vector board in) and drilled a hole in the white plastic whammy base and just inserted the spring between them. The new whammy bar is more stiff than on the original controller.
spring

The wireless controller came with rechargeable batteries and a charging cable to connect between the thing you plug in to the ps2 to receive the wireless transmission and the controller. So I just kept that part and added a matched jack & plug to where the original wired controller wire came out. When not charging, you can unplug it right at the base of the guitar. For when the rechargeables die, I put in a switch inside it to switch between NiMH mode and alkaline mode (which just determines whether it tries to charge the attached batteries) and included a two AA battery holder with the same connector that the rechargeables use.

I wired all the switches and lights to the top of the neck and drilled holes where the tuning post nubs were and mounted everything there. There’s a power switch, a charge light, a power/connecting light and a GH1/GH2 mode switch.
switches and lights

The only other upgrade, besides the wirelessness was that I replaced the two strum buttons under the strum bar with quieter versions. With the regular guitar, the loudest thing is the strum button. And I mean louder than the music. It’s all you hear unless your tv is at full volume. I found some quieter buttons at the local electronics shop that were about the right size and were less than a dollar each and mounted them on a piece of vector board. I had to add some spacers to get the strum distance right, but other than that, it was a straight replacement and it worked well.

This project took me 8 days (worth of nights and weekends) from buying the wireless controller to shipping it off to my girlfriend.

Here’s some pictures of the insides:
whole guitar
neck
body

Here’s the finished product:
guitar

And here’s the parts from the wireless controller that weren’t used:
unused controller parts

Other than all that, it works, and it is a solid guitar.

a blog about electronics

2007-10-02 by mzandrew

Finally! A blog that’s devoted to something nerd-centric on the internet. It’s about time!

I’m taking a class in electronics this semester. There’s a final project we have to complete, so I’ll track the progress of that here, as well as write about other things related to electronics.

arm7-oled-clock

For my final project, I decided to make a clock based on an arm7 microcontroller from atmel (an at91sam7s64) using a 128×128 pixel full-color oled display as the output. I wanted to do this for several reasons:

  • The choice of the arm7 was so that I could learn a new microcontroller that had higher performance than I was used to (motorola hc05, zilog z8). This one can do about 55 MIPS (although there’s a mandatory wait state if running code from flash instead of from sram, so it’s somewhere around 30 MIPS in that case).
  • The choice of an oled display was because it was fairly low-cost ($37 in single quantities), easy to interface to and is lower power than an lcd in the case that only a few of the pixels are on (because there’s no backlight on an oled display).

tools

I made it a fairly simple project (it is just a clock after all) so that I could determine whether it was straightforward to get a development platform setup on linux to assemble, compile, link and program the arm7 using freely available software. In this regard, it has turned out well. Here are the tools that I’m using right now to get the prototype working:

  • the gnu assembler
  • the gnu c compiler
  • the gnu linker
  • gnu make
  • openocd (to program the device over jtag as well as for simple debugging)
  • sam_I_am (to program the device over usb as well as for simple debugging)

current status

At this stage, I have a bunch of stuff written in assembly language. It does the following:

  • sets up the microcontroller
  • sets up the display
  • reads the voltage from a light-to-voltage sensor (TSL250) and sets the display’s brightness accordingly (dark in a dark room, bright in full sunlight)
  • displays a simple pattern on the display

Right now, I’m working on getting the time out of a real-time clock (over spi).

rant

The hardware designs will be released under a creative commons license so that anyone can take the design and make one (or improve upon the design it and make one) for themselves. The license will be BY-NC-SA (attribution, non-commercial, share-alike). This means the following:

  • attribution = You are free to distribute copies of my designs, but if you do, you have to give me credit. If you make a clock from my designs, you have to credit me for the hardware design.
  • non-commercial = You can’t sell my designs. You can’t sell clocks based on my designs. That is, unless you get an alternate license from me (and give me some of the money).
  • share-alike = You are free to make modifications to my designs, but if you do, and you share the result with others, you have to give them the same rights as I’m giving you. This means you can’t take it and modify it slightly and say it’s copyright you and then charge people for it. This share-alike clause also relates to distributing unmodified versions of my designs.

For more information, see this.

The software will be released under the gnu general public license (I’m not sure which version yet, either 2 or 3). This means you are free to take the software and use it or sell it (and you can keep your money this time) or you can modify it and then use it or sell it. Either case is only under the condition that you give others the same rights you got. See this for details.

Both of these licenses rely on copyright law as it stands right now in the united states. If you don’t like my terms, that’s fine, you didn’t sign anything, but nothing else gives you the right to copy my work (except fair-use; but that’s more of a defensible position than a right, now isn’t it?).

The difference between the non-commercial part of the license for the hardware design and the sell-it-as-much-as-you-want part of the software license has to deal with economies of scale. It addresses the problem that can occur if I design hardware and software for a widget and start making and selling them for fun and profit. It costs almost nothing to distribute every copy of a piece of software. It costs real money to make hardware, and the costs drop dramatically if you make a lot of something at one time versus just making a few of something.
If big company A takes my software and sells clocks with my software, that’s fine because they designed their own hardware and if they modify my software, they have to share their modifications with everyone because they’re distributing it with their hardware or as a download. This benefits everyone involved. If I let them copy my hardware design for commercial purposes, they can put me out of business because big company A can make 1000 at a time and undersell me because I can only make 10 at a time. Disallowing the commercial use of my hardware design prevents them from selling an identical product (hardware and software) for much less than I ever could, driving me out of business making and selling something I designed in its entirety.
Now, that’s a fine point, you might say, but if they’re selling clocks based on their own design with my software, they can still run me out of business. Ah. But that’s already happening, right? I don’t make clocks yet (and don’t really plan to, but there’s no sense in not planning ahead) and big company A already sells clocks for $5. I’m not trying to displace big business, I just don’t want them to profit on ruining me.

The parts of this blog and associated materials relevant to the arm7-oled-clock will also be licensed under the cc by-nc-sa license.

…end rant…