• EEVblog #886 – Audi Lunar Quattro Moon Rover

    Dave talks to Karsten Becker from PT Scientists, head of electronics development for the Audi Quattro Lunar Rover that will land at the Apollo 17 landing site on the moon in 2017
    It is front runner in the Google Lunar X-Prize

    Forum HERE

    Be Sociable, Share!

      About EEVblog

      Check Also

      EEVblog #1047 – Solar Roadways FINALLY BUSTED! Colas Wattway

      Dave finally puts an end to the idea of Solar Roadways. We have the test ...

      • Pingback: EEVblog #886 – Audi Lunar Quattro Moon Rover | WTS Connects()

      • Pingback: EEVblog #886 – Audi Lunar Quattro Moon Rover | Contract Manufacturing Company()

      • BobC

        EEVblog is beyond awesome! To go from a centenarian hobbyist (what I want to be when I grow up) to a “hobbyist” lunar rover really sends home the message that electronics are everywhere and for everyone.

        I’ve worked on a couple of “almost-launched” low-budget missions (we lost our free ride both times). The trade-off beyond hardware and software is a particularly vital area, since the more hardware you need, the more rad-hard hardware you need. So the real goal was to design a system with as little rad-hard hardware as possible.

        We went with just a pair of 74K series rad-hard chips to implement the voting logic and clock sharing between three “rad-tolerant” microprocessors. To get away with this tiny amount of rad-hard hardware, we needed our software to be aware of when any microprocessor silicon had been “hit”. A cosmic ray hit typically does either/both of two things: Bits get flipped/stuck, or a conduction channel is made between a power rail and ground (or between different power rails – which is why we went with single-rail processors).

        Detection of any of the following conditions would cause a short 50ms power-down cycle for the affected processor(s):
        1. The voting logic detects one processor is repeatedly giving different answers than the other two.
        2. A processor’s watchdog timer expires before being restarted.
        3. High current is detected on any individual processor power rail.

        All the processors could be reset quite often when passing through high-radiation fields such as the Van Allen belts, the South Atlantic Anomaly (SAA), or the north/south poles. So the implicit requirement is that the software must be able to boot exceedingly quickly, including performing all startup diagnostics and getting the main application up and synced with the other processors.

        Conduction channels are the most hazardous kind of hit, since the power supply can quickly cause the Magic Black Smoke to be released. So the current monitor can cause a repeated 50ms resets to occur when needed, since some conduction channels can require hundreds of ms to “heal” (the time needed for ions in the silicon to recombine and become neutral).

        There are lots of other often-conflicting requirements that must be met to optimize hardware/software reliability in the presence of radiation. But nothing beats actual radiation testing to know if/when you got it right. And simulating space radiation on earth can be quite difficult. But this post is long enough: if anyone wants to hear more about radiation testing for space, just ask below.


      The EEVblog Store generally ships twice a week, on Tuesdays & Fridays, Sydney time. Dismiss