Had every intention of launching right back into those code-changes/experiments today... Instead, the first few hours spent making my hokey 12V/5V wiring less delicate. Here's a tip: drill + zipties. 

Also had a revelation... See, that 5V power supply was intended to drive the 'antPC' as well as peripherals (e.g. my old hard disk)... thus, all those high-power USB ports. And somewhere in there I had it in mind to use those ports to power my project[s] as well. Brilliant!

But reality set in... I don't really have any high-current USB cables to cut for power. Oh, those dollar-store cables claim to handle 2.1A, but have you seen how thin they are? It's prb 4V by the time it gets to the other end. Fine for charging a 3.7V battery, but probably not for powering a 5V floppy drive's motors.

So, then I dug around for long/thicker two-lead wires to wire right in to my 5V supply... and at the end of that I'd splice the 3.5in floppy power connector. Kinda hokey to have a special cable coming out of my PC for this particular project... But just as I started to cut the cord off a wallwart, I saw the most obvious answer.

A friggin' power-cable from an old ATX power-supply... yahknow, yellow, red, two blacks, several connectors for both 3.5in and 5.25in drive-bays. Yahknow, kinda like one might find attached to the power-supply inside their computer, and might use to power things connected to their computer, like... a floppy drive. So, now, the antPC has power for peripherals... like PCs do. And it's plenty long enough.

I can't tell yah just how much fight it took not to wire up that yellow wire, too. "I don't need it right now!" and "It'd be *easy* to do if I ever do." But, more importantly, I suppose, is that it'd be [relatively] unregulated, from a car circuit... 11.75V - 12.6V, when not charging... Those numbers aren't too bad, pretty sure I've seen the likes coming from ATX supplies... but 14.2 into a hard-disk with no backup, that's a little nerve-wracking. Better not connected, lest I forget.

Did I mention that this seemingly simple task of stabilizing my power situation wound up taking hours? Yeah, several paragraphs, here, just recalling.

...

And, one of the main reasons I undertook this 12V->5V endeavor several days ago, now, cropped up today... The [house] battery dropped too low for the inverter. My PC woulda suffered a power-outage, right in the midst of coding... but the 5V supply hung in there with plenty of time for a proper shutdown. YEAH!

...

And, yeah, I got a few hours' experimentation/coding in.

First experiment: remove varying data. Record the same value in every nibble on the track. An easy compromise from recoding to handle e.g. 2-value "nibbles", as described earlier, is to just record the value 0x0 or 0xf. DUH. and 4-value is just as easy, and so-forth.

So, writing all 16 values, one on each track, runs several experiments at once.

And... an interesting result: Silence and constant-brightness on the LED, as the track spins throughout the majority of each rotation... on every track... suggesting, possibly, the repeated values are being read the same. As expected. Possible.

However, equally-informative, maybe, is that the brightness of the LED changes seemingly randomly (and a slight popping-sound) once with each rotation. Plausibly right around the Index pulse.

Why?

Well, writing of PWM-nibbles is delayed until after the index pulse... and stopped as soon as it's detected. So, there's a brief space on every rotation, on every track, where there's random garbage from long ago. This garbage is unlikely to look much like a properly-formatted PWM-nibble... OTOH, it might slip through my limited detection-scheme. So, maybe a random value comes through there...

BUT, the proper nibbles are written everywhere else on the track, the same value. So, a slight blip near the index may be expected, but as soon as the proper nibbles are detected/read, the LED should show the read-back value as its brightness. 

Now, I let it rotate five times, and every time it seems to grab a different value and stick with it until the next rotation. If these values were *similar*, it could be chalked up to measurement-error, jitter, slight variances in the rotation speed, etc. mentioned/hypothesized in previous logs, which is what I was intending to look into. But, for the most part the apparently-read value seems to vary dramatically with each rotation. (On some tracks! I'll come back to this).

So, it would seem what's happening is that it manages to see something that looks like a PWM-nibble in, essentially, noise, and yet does *not* see the ones actually-written?! Otherwise, I'd expect some *slight* fluctuation in the LED brightness as the disk spins, but otherwise expect the brightness to be pretty much the same value across rotations.

Now, oddly, some tracks *do* seem to have this effect... But these tracks only seem to have a *dim* LED (so is that values near 0x0, or 0xf?)

I dunno. I think what I'm seeing on most tracks is a single value being [mis]read, and none of the others "making the cut." At this point more information would be tremendously helpful, so I think it's about time for UARTing. E.G. Each rotation spit out the number of nibbles detected.

Of course, this is all hypothesizing based on the idea that my nibbles are written as I intended, and readback, too. And there was the issue of processing overhead, where merely inserting a 'validCount++' could trip things up. WEEE!

Oh yeah, did I mention that I pretty much scrapped my pvts? That was a lotta work now in _duds/