Silicon Valley Redneck

They ain't gittin' me up in one o' them things!

The Hiller Aviation Museum has been on my "get around to" list since shortly after it opened.  Today was "get around to that one" day.

It's pretty interesting; got quite an assortment of vintage & reproduction aircraft and aeronautical oddities, 1850-present, and some hands-on stuff.  (I tried the Hiller Flying Platform simulator.  I think I landed on my head - couldn't tell which way was up.  I even managed to get the thing spinning, and the docent apparently hadn't seen that before - the original had vanes for correcting for spin, but the simulator apparently isn't meant to spin in the first place.)

Then there's this thing:

OK... what it actually seems to be is a sort of manned ducted fan flying-beer-can thingie.

What it looks like is a means of conveyance for a superhero who lives in the suburbs and commutes.  No, not The Abelian Grape, that other guy.

Further randomness: is "autogyro" Greek for "make your own darn sandwich"?

Closed packages, phooey!

So here I am, trying to bring up the receive side of this low-power RF link....

I know the transmitter is at least somewhat working, because if I force it into continuous transmit mode I see a correct result on the spectrum analyzer.

And now there's the receiver.  Well, a transceiver chip being used as a receiver.

Rather than muck about with trying to do initial bring-up on an AVR - and an ATtiny26 at that, utterly lacking any sort of console - I wired it up to an LPC2148 eval board, and hacked up a little program to run under AGROS and do stuff like initializing registers and polling for status.  Having printf available is kinda handy!

After some fiddling, I got it to come up on the right frequency, as determined by putting it in transmit mode.  Unfortunately, it appears to be severely modulated, sometimes... and sometimes it comes up clean.  Eh?  I suspect the VCO is wonky, but the VCO is entirely internal to the transceiver chip.

And then there's the receive path.  We all know how to bring up a receive path: apply a signal (for example, by turning on the previously brought up transmitter), and follow it through the IF and demodulator.  Here, though... the whole path is internal to the chip.  Can't put a scope probe on it.

Grumble, grumble... well, I guess the thing to do is get it to put out a clean signal, consistently, in transmit mode.  Once it does that, I'll know the VCO is working OK, and bringing up the receiver makes sense.  As things stand now, the receiver has hallucinations, and keeps claiming to be receiving (random-looking) data when there's no signal.

There's this to be said for the itty-bitty chip with everything in a tiny closed package, though: assuming I can get it to cooperate, the complete transceiver section, including crystal & filter/matching components, will fit (after footprint corrections) in a fingerprint-sized area.  Couldn't do that with the tech I was using a decade back.

Update: turns out it was something I could put a scope probe on.  I'd installed a wrong-value cap on the bypass pin of the on-chip voltage regulator, and the regulator was singing to itself.  Think that might make the VCO get a bit wonky?  (This wasn't the problem with the other copy of the hardware, which has the correct cap, didn't have a significant AC component at that node, and was showing similar-looking problems.  On the other hand, maybe I didn't have the register values right a couple of days ago, when I was working on that one.)

Anathema

I had the radio on for a while this morning, tuned to the news station.

It seemed like every minute, on the minute, someone mentioned the name of yesterday's mass murderer.

I agree with the Armorer: let his name not be spoken.

Let him be an unperson, his memory shunned by all.

In the mass media, of course, that won't happen.  His name (may it burn on the leaf pile of history) will be mentioned constantly.  His life story will be examined sympathetically, with much emphasis on "What could possibly have led him to do such a thing?"

And what message does this send to the unstable losers out there?

Hey there, loser!  Frustrated?  Not meeting your life goals?  Want some attention?  Here's what to do!

Just get yourself a gun like this one here - here's where you can buy one locally!  See how easy it is? - then find a large crowd of helpless victims at a place like this, or this, and start shooting!

For the next week, you'll be more important than Anna Nicole Smith, and maybe even Al Gore!

With the passage of time, you'll be better known than Rick Rescorla!

Go on, do it now - you know you want to!

Yeesh. The coverage is always the same.  And then people ask where these losers get the idea.

Why can't they mention the name of Liviu Librescu instead?

Update: via the Volokh Conspiracy, meet The Copycat Effect.

Mnemonic plague strikes again!

I know this has bitten me before, but I'd somehow managed to forget it.

On Motorola processors:

BLO    Branch if Lower (unsigned)
BHS    Branch if Higher or Same (unsigned)

On the AVR:

BRLO    Branch if Lower (unsigned)
BRSH    Branch if Same or Higher (unsigned)
BRHS    Branch if Half-carry Set

So... I had all these unsigned comparisons that were actually branching on half-carry instead of on >=.  Foo faddle!

Well, that would explain why my software PLL has been behaving so oddly.  Branches taken on an entirely spurious condition, forsooth!

Grrrr.

Once again, I appear to have rendered an AVR chip useless... and I think it's the usual failure mode.

The way I usually do this is by programming the part using AVR Studio, and forgetting to read the fuses before initiating the auto programming sequence.

AVR Studio has the wonderful bit of automation to take care of programming everything... except that the fuse bits have to be either set by hand or read back from the chip under manual control, each and every freakin' time the programming module is invoked.

You'd think an IDE like that would provide some handy way of including the required fuse settings in the source file, or at least setting them at the project level, but no.  That's user input to the programming utility, and the default value disables in-system programming.

Maybe I should be using AVRDUDE from the command line.

Anyway, my Tiny26 is sitting there running the last known-buggy version of my code, and refusing to go into programming mode so I can install the new version.  This is annoying enough with a DIP part, but this is a 32-pad MLF ("I hope he is half as scared as I!" - Tom Lehrer).  Probably as much of a hoot to remove as it was to solder in the first place....

Update: reworking the MLF wasn't all that much of a pain.  Unfortunately, the replacement didn't work either.  After much futzing around, I found a broken wire in the programming cable, so maybe the original part didn't have its fuses misprogrammed after all.

And now, back to debugging the firmware.  Software PLLs are such fun!

Busy, busy, busy...

I've been mostly immersed in work lately... got a prototype coming together on my lab bench, and sooner or later there will be a company to go with it.  Then, it seems, I may be making infomercials.  I'll be famous!

Yesterday I took a few hours to go wander around the Embedded Systems Conference, gathering information and schwag, and pestering vendors for automotive-temperature versions of their products.  No, I didn't bring any booth bunnies home for Easter.

So, not much time nor fit subject matter for blogging.  The current project on the bench is interesting but confidential.

Here's one goodie, though.  One bit of schwag is a fluorescent orange plastic bottle, which has every appearance (aside from the color) of being a water bottle.  It came with a warning label:

1. Hand wash only in warm soapy water before and after use.
2. Do not immerse or soak in water.
3. Bottle is not for a measuring device.  Amount marking are for approximation only.
4. Made in China.

Um.  #2 seems particularly odd.  Naturally, I promptly violated it, and the bottle didn't dissolve, nor did the universe implode (so far as I can tell).

Actually, I'm not sure the bottle is for water; it's marked "K7 DEVELOPER FOR JAVA."  I don't know if that's like "Flexicolor developer for C-41 process film," or what.  Does the Java development process involve liquids that need to be stored in tinted bottles?