Mark's 20 Percent Time

I'm reporting on Friday, not Thursday, this week because of the holiday. I get Friday off for free, so I thought I'd swap my days around and not have to burn PTO this week.

A bit of follow up on the hard drive situation. Short version: It's toast. I've tried all kinds of necromancy: Logic board swap with a known good drive, firmware upgrades, the Seagate "testing" tools... ...I guess that's about it. The problem is that the drive is not recognized by the BIOS, which eliminates the vast majority of the tools I could possibly use. I had high hopes for the logic board swap, but several forums confirm that the logic boards contain calibration information that are specific to the spindle with which it was shipped, meaning that even if I had two identical working drives, swapping logic boards wouldn't work. So far, I haven't found a way to get the logic board to re-calibrate with the new spindle; I suspect this is something that must happen at the factory.

Reading up more on the symptoms, it appears this is a common problem with the Seagate drives. On some boot, it just decides to lock up hard and not communicate with anything, and there doesn't appear to be any way to get it back. Seagate accepts that its a dead drive and will replace under warranty, but that doesn't get you your data back.

So, I'm frelled. Hundreds of GB of Music, TV shows, projects, source code, taxes, etc... Lost...

The one remaining hope I have is if I can find at least three of the four drives that were in the RAID array from which this data was copied. I'm not sure I haven't already wiped the data on those drives, so I may be totally screwed. But its worth a shot.

So, yeah. That brings us up to now. I've purchased a whole new system: Intel Atom 230 based low power mother board, 1GB of DDR2-5300 RAM, 2x Western Digital Caviar Black 1TB drives to be put in a RAID-1 mirror. Using my old Antec power supply and _REALLY_ old rack mount case, and a DVD-ROM drive I had laying around, this will be the new server... ...at least, it will be once I get a CentOS v5.3 x86_64 DVD ISO downloaded and burnt.

The eventual goal is to put a 12vDC solar panel or two on the roof and use them to charge a 12vDC battery to provide an off-grid battery backed 12vDC system to run my radio gear. With one of these 12vDC ATX power supplies, I could also put the file server on this 12vDC system. The LinkSys WRT54GL router and NetGear 10/100 switch already run on 12vDC, so those are no-brainers. Eventually I'll have all my network and radio gear off grid running on "free" power. (That mini-box site I linked to also has a 250W wide input ATX power supply that might work with my desktop. Pulling this much power from the 12vDC system would require either a second solar panel (they're about 150W each) or hooking up a 12vDC battery charger to run when the voltage gets low.

Anyway... In the mean time, I'm debating what I'm going to do. I'm thinking of setting up my half-rack (really, a 6' 2 post rack that's been cut in half) and mounting all the 12vDC gear I already have: battery, power supplies, radio gear.. Then also mounting the new server and running AC to it for the time being. Alternatively, I could also work on the C code for my analog clock project. Decisions, decisions, decisions...

More later today after I've, ya know, actually done something...

Previously, on Mark's 20% Time Blog...

I've purchased a whole new system: Intel Atom 230 based low power mother board, 1GB of DDR2-5300 RAM, 2x Western Digital Caviar Black 1TB drives to be put in a RAID-1 mirror. Using my old Antec power supply and _REALLY_ old rack mount case, and a DVD-ROM drive I had laying around, this will be the new server... ...at least, it will be once I get a CentOS v5.3 x86_64 DVD ISO downloaded and burnt.

So, yeah. I got that DVD burned and have been trying to install an OS on my server. As soon as CentOS tries to detect the hard drives, it starts generating ATA subsystem errors. This happens no matter what hard drive I use (either of the new Western Digital drives I just bought, or the Seagate ES.2 I'm borrowing from work), whether I swap the RAM, whether I use CentOS 5.3 x86_64 or CentOS 5.0 i386 (the two ISOs I had laying around)... About the only things I haven't swapped out are the CPU/MB, power supply, and the chassis. I've posted a couple questions to the CentOS Forums with more details of the problems I'm having. Googling doesn't show anyone else having problems with my motherboard and installing CentOS, except the network driver which is a known issue and past where I'm stuck now.

I've burned the whole morning on this and I'm quite frustrated. So, to save my sanity, I'm going to turn my attention to something else. Next post.

So, for the rest of the day, I think I'm going to spend more time on my Seebeck clock project. I've gotten the PWM working using the ATmega8515, the chip that came with my development board. But I really want to be using the ATmega168 which has different timers and what-not. So I think I'm going to spend today porting the code to the ATmega168.

I have the chip working on a high precision 32.768kHz crystal. The PWMs are 8 bit, meaning they can produce a voltage between GND and VCC in 256 steps. The meters only take .1vDC to swing full scale (1mA with a 100ohm coil) so the plan is to use a voltage divider to scale it so that 0 to 240 will do full scale on the meter, meaning that I need the clock to tick 4 times a second (240 ticks / 60 seconds = 4 ticks per second). 4 ticks a second means a tick ever 8192 clock cycles, or conveniently every 32 roll-overs of the PWM counter which will conveniently trigger an interrupt if configured to do so.

This is the next step: configuring the timer roll-over interrupt to "tick" my clock for me. Hopefully, I'll be able to get all of this done today.

- I've successfully ported my code to the ATmega168. Mainly just involved changing a bunch of register names for the Timer control stuff, and adjusting what pins the PWM output is on.

- The ATmega168 has two 8 bit timers (TC0 and TC2) and a 16 bit timer (TC1). All three timers have 2 PWM modules available. I ended up using TC0 and TC2 for the three PWMs (with one to spare!) and am using TC1 as a clock tick source; by having a 16 bit counter, I can actually count 8192 clock cycles for every tick instead of counting 256 clock cycles 32 times for every tick.

- Started looking into interrupts and ISRs with avr-gcc. By the time I got to writing code, I had to take Cindy to a doctor's appointment and haven't made it back yet. This is what I'll work on next time I get a chance.

All things considered, I'm very happy with how this is all going. Once I get the hang of things, I think I'm going to like programming micro controllers in C instead of assembly. :-D For now, it's time for bed. G'night everyone. Be good humans.

-Mark

- Figured out interrupts: avr-gcc makes them TRIVIAL. Thanks guys for making such a fantastic little compiler.

So, yeah. Moved the entire loop into the ISR and put a "while (1) {sleep_mode()}" in main(). As long as I can keep the ISR under 8192 cycles (the number of cycles between interrupts), I'm golden. This should not be a problem, even with the inefficiencies of C.

- Added three buttons:
- Calibrate: Sends all meters to full scale
- Minutes: increment the minutes hand
- Hours: increment the hours hand

The calibrate button is required to adjust the 10-turn pots feeding the meters. Turn the device off, set the zero point using the adjustment on the front of the meter. Turn it on, hit the calibrate, and adjust the pots for full scale. Then you're off and running.

- Somewhere along the way, I accidentally programmed the chip to use the low frequency crystal, but didn't remove the CKDIV8 bit, meaning that the chip was running at (32.768kHz / 8 =) 4.092kHz. The in-circuit programmer needs to write at at-least 5kHz, and must be at most 1/4 the clock rate (1.024kHz). You see a problem forming here? I thought I bricked my chip. Then I did a bit of Googling and found out that the high voltage parallel programming modes don't depend on the system clock, and that my STK-500 supports the high voltage parallel programming mode. After about 30 minutes of doing what Real Geeks do: try stuff without reading any documentation, then giving up and reading the manual, I had it running in no time. My chip is un-bricked, and running at the correct speed of 32.768kHz now. The other bonus is that 32.768kHz / 4 > 5kHz, so I can still do in-circuit programming, which makes me happy.

So, I now have the chip up and running at the same level of functionality as the Propeller version, but this one will run at 1.8vDC, 32.768kHz, probably on the order of 100uA or less, and with a more precise oscillator. The next step is to build up a bread board with the hardware and hook it up to some meters. (Right now, I'm still just looking at LEDs of varying levels of brightness on the development board.)

I've drawn up a quick schematic for what I'm planning. The 1k fixed resistor and 5k 10-turn potentiometer are sized to be able to provide 1mA to a meter for a variety of system voltages, but still provide a reasonable current limit in case someone takes the pot and cranks it all the way down. With a 10-turn, it should be plenty precise. For my planned VCC of 1.8vDC and a "full scale" value on the PWM of 240 (out of 255), an impedance of 1687ohms will give 1mA. The meters are 100ohms, and the fixed resistor is 1k, meaning the pot will need to be set to about 500 to 600ohms, plenty far from the 0 point to be cleanly adjustable.

TODO: Order a few parts from Digikey. I don't have any 10-turn 5k pots on hand, and I'm probably running low on 1kOhm. And I'm pretty sure I don't have any push buttons.

I've put my Seebeck Clock project on-hold for the time being while I get prepped for the hardware demo I'm giving at DefCon in a bit over a week for Project: Codename Curious George.

I _WAS_ planning on bringing a small ITX system with dual Ethernets for the monitoring device, but honestly I _REALLY_ don't feel like lugging along a full sized system, monitor and keyboard to DefCon. I'd really rather just use a laptop with a second Ethernet port, but the only PCMCIA Ethernet card I have doesn't appear to be working. I've put my feelers out looking for loaner cards, so we'll see if that pans out. (While writing this post, I've already gotten two people who think they can help me, so that's good.)

As a "just in case," I'm going ahead and setting up a diskless system on a CF card to send with coworkers who are driving to DefCon (I'm flying out a lot earlier for BlackHat.)

So, yeah. Project: Codename Curious George. I'm just shy of a week away from giving my SkyTalk at DefCon on the subject, and lets be honest, this is probably the last time I'll post here before then. I think it's about time to let this Monkey out of the bag.

The real name of the project is EtherSniff. The codename came from this image:

In short, it's a method for passively sniffing the traffic of an established Ethernet network link. Picture there's an Ethernet cable running through the drop ceiling above your desk, or along the wall near by, any place you have physical access to it that won't be noticed. Let's say you wanted to monitor the traffic going through that link for some reason (white-hat reason, I'm sure...) I've figured out how to do that without being noticed.

Here are the slides for my talk at DefCon that provide a lot more detail.

I'll do my best to post next Saturday (August 1st, not July 25) and report on how the talk went. But between now and then, I'm likely to be quiet here as I'll be at BlackHat learning how to break into Xen systems!

Oh. It's not a _TECH_ project perse, but over at my other blog, I've made a new batch of root beer. It doesn't scratch the same itch as my tech projects, so it doesn't qualify as a 20% time project, but I thought you might be interested anyway.

That's it for now. Thanks for reading! -Mark