0x80 is just a null byte with odd parity. What she apparently missed is that this is bog-standard Bell 202 AFSK (1200 baud) with 7 data bits and odd parity, and the data is ASCII. By throwing away the top nybble, she was throwing away the parity bit and the top 3 bits of the ASCII encoding of decimal digits. The fact that it was a parity bit should've been pretty obvious, since the top nybble flips between 0x3x and 0xbx in the pattern that you'd expect for a parity bit.

You can decode it with off the shelf software, throw away the top bit, and get back mostly ASCII:

$ ./minimodem --rx 1200 -f ~/helicopter.wav | tr '\200-\377\r' '\000-\177\n'
### CARRIER 1200 @ 1200.0 Hz ###
  282 0002.3
#L N390374 W09432938YJ
#AL #NA 282 0002.3
#L N390374 W09432938YJ
#AL #NA 283 0002.3
#L N390372 W09432928YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
[...]

I'm actually surprised that she missed / didn't mention this, considering her experience with signals analysis and demodulation. This is pretty much as basic as telemetry data modulation gets! Then again, as a reverse engineer myself, sometimes we get caught up doing deep analysis of something that later turns out to be totally trivial :)

Meanwhile, I've been running the same Gentoo install for ~9 years now (having migrated through 5 different machines). Rolling upgrades are awesome.

(It would be >10 years, but I did have to reinstall early on to migrate from x86 to x86-64).

The MHz number on the box is the bandwidth, not the sample rate. The sample rate is measured in samples per second (GSps). A 100MHz scope is probably adequate for analog signals up to 100MHz. However, if you're debugging a digital signal, you want a scope that has 3x the bandwidth of your signal's base frequency or more, because square waves are composed of the base frequency and an infinite number of harmonics. If you only have bandwidth for the base frequency, your square wave will be distorted into a sine wave and you won't be able to accurately see ringing, glitching, and other artifacts.

I have a 1GSps, 100MHz scope. I wouldn't use it for serious digital signal debugging above 30MHz (which is 33x lower than the sample rate), due to the bandwidth constraint. It's adequate for seeing if stuff up to 100-150MHz is "there" though (and for reading the bits out if you just want to use it as a poor man's logic analyzer), just don't expect to diagnose signal integrity and timing issues at those speeds.

Low-speed 1.8V and high-speed 0.5V LVDS mode, 800MHz... a MIPI-DSI display? :-)

Or one of these (it also passes through USB 3.0, which is nice):
http://www.amazon.com/Centech-USB-Power-Meter/dp/B00DAR4ITE

This isn't new.

You can correct for chromatic aberration in software, to a varying degree. You can approximate it (so the aberration is ~1/3 of what it would normally be, by aligning the centers of the primary colors) for arbitrary inputs, e.g. a photograph captured with an imperfect lens (image editing software can do this). You can do it on the output side with perfect accuracy if you're displaying an image using three monochromatic light sources (e.g. a laser display), since the three wavelengths involved would then be distorted by three discrete amounts that are perfectly correctable. For RGB panels like LCDs and OLED displays the primaries aren't monochromatic, but they are more concentrated around the dominant wavelength than a natural light source with a uniform frequency distribution, so you get a result that's somewhere in between. This is what the Rift does to correct for chromatic aberration in software.

Uneven pixel density is only a problem if the pixel density at the sparsest point is too low. Today's displays already exceed visual acuity when viewed at a reasonable distance (e.g. a Nexus 10 or an iPad with a Retina display at a normal operation distance), though of course that is without covering a large fraction of the FOV. Give it a few more years and it'll only get better - once we have 8K phone-sized displays this will probably be a non-issue.

My general strategy for performing simple tasks like generating a barcode or merging PDF files is to just do a search on my distro's package manager and there's usually a tool to do what I want (although it sometimes takes a bit of guesswork to figure out what it would be called). I don't remember what I used last time I needed to generate a (non-QR) barcode, but Debian only has one package simply named "barcode" which can probably generate whatever type of barcodes you need (also, there's tons of websites that will do it for you as well). For merging PDFs, I believe I've previously used pdfshuffler, which works fine.

Excellent thesis and a most delightful dedication!

    A few salient points from this thesis, for the Slashdot crowd:
    - Accumulation: knowing what to keep and what to toss
    - Distribution: where/how to keep copies
    - Digital stewardship: maintaining objects isn't enough ... you must properly catalog things
    - Long term access means more than just saving bits ... they must be properly rendered

Convolved on this are problems with copyright, fair use, payment for archives, orphaned collections...

Then there's the cost of creating and maintaining a long term digital repository.
Librarians have done a terrific job with our printed archives. Who will become our digital librarians?

Obviously you were concerned enough to measure if there was any imminent danger

I wasn't concerned. I'm just a curious geek who happens to own a logging Geiger counter.

The issues is not radiation emitted, it's the radionuclides emitting them.

That is true. Ingesting radionuclides is definitely a much bigger problem than external exposure.

That's great but it's more likely that Japan now has very high concentration of radionuclides in very specific places in the ocean or land or sea, some of that area will be producing food. The likelihood of encountering in the food chain is now higher than the initial accident because the radionuclides have propagated further up the foodchain so if you ate food in Japan the likelihood of ingesting it has increased. The longer you stay there the more you will increase your chances of a permanent dose in your body, the more times you get one of those means the probability of some sort of cancer increases. A big problem for the locals, but not really a worry for you.

It's hard to get real data about these issues, as there is a ridiculous amount of fearmongering in the media. For example, there are plenty of articles talking about the spread of radiation in the Pacific Ocean from Fukushima to other countries, but a simple dilution argument shows that any claim of danger from that effect is nonsense - the ocean is ridiculously bigger than the quantity of radioactive water released, and even if you can measure the effect, it's going to be negligible in practice.

Locally produced food is another issue, and yes, the possibility for concerning contamination exists. Supposedly, food is tested in Japan, and the limits are stricter than in the US. Converting that into the probability that you will eat something that exceeds the limit (and by how much) is tricky. If you know of any serious studies attempting to calculate this, please do let me know.

FWIW, I do plan on moving to Japan in the not too distant future.

Interesting. I didn't stop at Fukushima station, but I went past it on the Shinkansen with my Onyx in the outer pocket of my backpack (obviously it won't be picking up any alpha radiation there, but still useful data). Looking closely at the logs it is possible that one spike correlates with roughly the time I'd have been in that area, though I really would have to check the times closely. The Onyx was set to log every 10 minutes so it's also possible that it just missed the interesting times. The peak readings were about 0.2uSv/h, and that wasn't near Fukushima. Tokyo averaged somewhere around 0.11 uSv/h, while Hakodate (where I stayed a couple of days) was around 0.07uSv/h.

Interestingly, my return flight hit 3.0uSv/h, higher than the first flight (I just dumped the last chunk of the log which I hadn't done yet).

These readings seem to be using the default calibration of the Onyx. I haven't delved into the details yet (the firmware is still WIP as far as I can tell), but AIUI they are supposed to come calibrated, so either the default calibration is spot on, or the firmware isn't using the calibration data, or my firmware upgrade wiped the calibration data, or the calibration data was never there. Either way, I assume the default conversion factor is good enough for rough measurements of background radiation.

Somewhat amusingly, he typoed the one relevant box in there - "Extra dose to Tokyo in weeks following Fukushima accident" should probably be 40uSv (not 40mSv) if he means per person (and even then it sounds a bit high), or be in the orange chart if he means the total dose delivered to all of Tokyo.

Using my Safecast Onyx (hi Safecast folks!) I measure ~0.32 uSv/h in Dublin, next to a granite wall (granite is everywhere around here, and naturally radioactive). The article speaks of of 0.484 uSv/h, not much higher than that. On an airplane at cruising altitude I get about 2.0uSv/h. At home I might see 0.08uSv/h, and in the middle of the street somewhere around 0.15uSv/h. *

I just visited japan and took the Safecast everywhere I went. At no point did it go significantly above what were normal background radiation readings in Dublin (not even when I was passing by Fukushima station, though admittedly that was on a high-speed train).

Radiation is everywhere. Unless you can identify the source as the Fukushima disaster, it might be perfectly normal. Even if the source is Fukushima, at low levels, at some point you have to stop worrying about it and realize that plenty of other places on Earth have higher naturally occurring background radiation.

* Rough numbers pulled from memory in CPM and converted to uSv/h using the conversion factor in the firmware source code, since my Onyx battery is dead at the moment. Take with a grain of salt.

Some 25 years ago, I was on booktour for Cuckoo's Egg. I visited Iowa City and spoke at Prairie Lights bookstore -- delightful people and a wonderful place! A haven for writers, readers, and hackers.

After my talk, I passed along a Klein bottle to an Iowa computer hacker who was fooling with unix. In turn, he gave me a Corn Grenade . I tossed it in my backpack, headed for my next stop, and next evening went to Ames Municipal Airport.

This was in pre-TSA days, but there was certainly airport security: the security guy at the Ames airport discovered the corn grenade in my carry on. Happily, he recognized what it was - a cool, brass, art sculpture which was completely inert. By that time into booktour, I was pretty inert. We chatted for a few minutes, and I took the commuter plane to Chicago.

I'd forgotten about my 3 pound brass friend when the plane landed at O'Hare. But the Chicago X-ray scanner found it, and all sorts of alarms went off. Natch, I was taken aside, given the third degree. Seems that corn grenades aren't recognized in the distant lands of northern Illinois. I had to explain all about corn grenades (and my book, and klein bottles...) Missed my flight, slept overnight in O'Hare, and wound up shipping the heavy lil' guy by UPS ground. Today, that brass ear of corn smiles at me from across my dining room, reminding me when I got hacked by a computer jock in Iowa City...