Official TEPCO video: https://www4.tepco.co.jp/en/news/library/archive-e.html?vide...

Reference manual for the video: https://www.tepco.co.jp/en/hd/decommission/information/newsr...

Investigation details: https://www.tepco.co.jp/en/hd/decommission/information/newsr...

> The drones did not carry dosimeters to measure radiation because they had to be lightweight and maneuverable

Weird claim. Devices such as RadiaCode 101 - 103 are highly portable and can also do gamma spectrometry with fantastic to its size quality. Yes, it's not a "proper" calibrated dosemeter, but it's much better than nothingness of claim about a necessity of being "lightweight and maneuverable".

Yeah, a small GM tube (which is probably all you would want in a high field) would weigh very little, and could be read with a relatively simple circuit.

However, reading the associated reference, apparently they're using a "relay snake-like robot" to provide communications to the drone - and it is equipped with the ability to take dose measurements.

"3.6 roentgen: not great, not terrible"

  The drones did not carry dosimeters to measure radiation because they had to be lightweight and maneuverable

You can probably measure the radiation from the noise seen in the camera images.

Why is this flagged? It may not be the best article, but this is interesting news and comments.

Because it's the Daily Mail, which is an awful rag. A lot of people will flag anything from there. There are much better sources for this video.

Seems like they could use something like GammaPix from https://www.imageinsightinc.com/ with their existing drone's CCD camera to estimate radiation levels.

I wonder how the radiation affects things like ESC motor timing, communication protocols, the cou inside the drone flight computer etc.

It comes out as bit flips in memory and noise on communication lines. There are many mitigations. State machines that recover from "impossible" to reach paths, redundancies like calculating the same thing more than once, checksumming/error correcting codes, repeatedly setting a state that "should" not need to be changed.

But also lots of things don't matter. Like if your ESC hiccups for a millisecond or gives a blip too much power no one cares because there are no long term consequences. Like the extra noise in the video feed, ok it's there but of no actual consequence.

The important parts are long term stored variables and ensuring that state is maintained or can recover.

The surface area of things that really matter which are vulnerable to radiation is really quite small, the rest has either 0 effect or manifests as very survivable noise.

Source: ran the flight computer team on a student satellite competition long ago.

Were there problems with CPU state that caused crashes? A bit flip on the stack could easily trigger a memory fault.

We never launched so it was all theoretical. We never got to the point of actual radiation testing, this is done but a very advanced kind of thing to do, for example we did go to a Lockheed Martin location a few times to, test our GPS receiver which had its restrictions removed and would work in orbit. (when configured with the right firmware this had ITAR restrictions, was considered munitions, students from certain countries couldn't participate) They also had facilities for environmental testing: heat, cold, vibration, vacuum, etc. The two hardest parts of designing a satellite are attaching to the rocket and surviving launch and managing your temperature in orbit.

I don't remember all of the details of the OS level things we didn't have control of for the different OS options out there, we were just going to use Linux though, it was a viable option. One of the things you do is have a really simple hardware watchdog which will just reboot everything if it stops receiving the right health indications for exactly the case of difficult to recover faults.

I once heard that things like NOP slides[0] are sometimes used in radioactive environments just in case jumps are off due to bit flips.

[0] https://en.wikipedia.org/wiki/NOP_slide

That only helps if your flips are in the low bits though right? And naively I'd expect bit flips to be uniformly distributed through the address bits