Zombie Plop

The un-dead drop.

Similar projects worth following

The Zombie Plop (ZP) project is a radio-frequency dead drop messaging system and semi-permanent information repository.

It is primarily intended to provide short messaging services (not necessarily limited to 160 characters, but definitely limited in size - perhaps to 500 or 1000 characters) and secondarily to provide access to valuable information (such as that necessary to survival and societal reconstruction) in any situation where a communications infrastructure is not available or not practical. This could be due to terrain, post-apocalyptic conditions, natural disaster, or human interference with existing communications infrastructure. The project consists of a communications protocol; a flexible, time-insensitive networking infrastructure; and two categories of devices, "core" devices and "access" devices.

Any system or device that conforms to the communications protocol and provides the required resources (such as storage and re-transmission of messages) can act as a core device, and any system or device capable of connecting to a core device can be an access device. The core device will be a "from scratch" design using mostly COTS components, and the proof of concept access devices will be 1) a cell phone with BLE 4.0 and our app running on it, and 2) an MSP430 development kit.

The original specification for a core device has a large amount of persistent, reliable storage, multiple radio frequency communication channels, a high capacity, user-replaceable rechargeable battery and a small solar cell with charging circuit. Ideally, it will also have a port for external power and another for communication extension (for instance, broadcasting messages over shortwave radio or a low-quality audio-only PSTN call). It will fulfill the role of mailbox, and semi-permanent information storage. Core devices will also have a "courier" mode for mobile installations, and in such a mode will attempt to synchronize as much as possible with other core devices it finds, with service to access devices taking a lower priority.

Access devices provide, as is somewhat evident from the name, access to the services offered by core devices. They can be any form factor or device. The only true requirement is the ability to communicate with a core device over one of the available RF channels, although the utility of such a device is limited without some amount of storage, a screen and a keyboard.

This project is planned to be released under Creative Commons (CC-BY-SA 4.0) and MIT licensing, as appropriate. Licensing information will be available on individual resources as it applies to them.


AD Access Device. Synonymous with ZPA.
BLE Bluetooth Low Energy
CD Core Device. Synonymous with ZPC.
COTS Commercial Off The Shelf
GPS Global Positioning System
MCU Microcontroller [Unit]
MSP430 Texas Instruments MCU Family
PCB Printed Circuit Board
PSTN Public Switched Telephone Network
RF Radio Frequency
SoC System on Chip
ZP Zombie Plop. Abbreviation of the project name.
ZPA Zombie Plop Access [Device]. Refers to the "access" device in the project.
ZPC Zombie Plop Core [Device]. Refers to the "core" device in the project.
ZPN Zombie Plop Network. Refers to any collection of ZP devices forming a network.
ZPP Zombie Plop Protocol. Refers to the protocol used for communication among ZP devices

  • 1 × Texas Instruments CC430F6137 MCU and Sub 1GHz Transceiver 16-Bit Ultra-Low-Power MCU, 32KB Flash, 4KB RAM, CC1101 Radio, AES-128, 12Bit ADC, USCI, LCD driver
  • 1 × Nordic nRF8001 Bluetooth® low energy Connectivity IC
  • 2 × BLE Antenna
  • 1 × 433MHz Antenna
  • 1 × RFDuino BLE RFD22102 RFduino DIP

View all 13 components

  • Hackaday Prize

    t0x008/27/2014 at 00:38 0 comments

    The good thing about not being selected to continue to the semifinals of #TheHackadayPrize? No video requirements!

  • EMI

    t0x008/25/2014 at 10:48 0 comments

    All RF systems have to take interference into account. I'm not sure how much of an impact it will have on our design, but since I'll be laying out a PCB shortly, I want to get some sort of handle on the potential issues before wasting design effort and weeks of manufacturing time. So far, I've run across a couple very useful documents from TI, and will be researching further...

    PCB Design Guidelines for Reduced EMI
    RF Shielding: The Art and Science of Eliminating Interference
    Michael Ossman's RF Design Recommendations

  • Antenna Design

    t0x008/25/2014 at 04:14 0 comments

    A Bluetooth antenna is pretty easy to find and purchase, and many designs (like the Adafruit breakout we'll be using in the simpler version of the core device build) use an antenna printed on the PCB. A 433MHz antenna is even easier, as it is an amateur radio band in addition to being in the ISM band. However, purchasing an antenna is not always the right move, since they can be simple and inexpensive to build.

    I plan to try a commercial 1/4 wave monopole, a homemade coil loaded dipole, and possibly other DIY designs for the 433MHz antenna. For the Bluetooth antenna, I'm going to initially try a printed [on the PCB] antenna, but may switch to an external if the range is terrible.

  • PCB

    t0x008/25/2014 at 04:01 0 comments

    Eagle is the gold standard for PCB design software, but you definitely pay for what you get. 

    Since we're broke (we DID just get back from Vegas), I'm looking for a free alternative. KiCad and Fritzing are the two options to which I've narrowed the field, but  deciding which to use is probably best left to someone with experience designing PCBs. We do not have such  a person available.

    Instead of flipping a coin, I'm just going to build the PCB in both and at the end, I'm sure I'll have a favorite. Not the most efficient method, but pretty much guaranteed to work.

    Oshpark is the PCB manufacturer we'll be using, both due to their low cost and recommendations from many projects around the web.

  • Decisions, decisions (MCU selection)

    t0x008/20/2014 at 15:39 2 comments

    Well, this morning has been a long discussion about microcontrollers. There are several good options:

    • Arduino with the Adafruit BLE breakout board and a CC1200 transceiver
    • RFDuino with onboard BLE and a CC1200 transceiver
    • MSP430 SoC with onboard transceiver and the Adafruit BLE breakout board
    • MSP430 SoC with onboard transceiver and a Nordic nRF8001 on a custom board

    The MSP430 options will take significantly more time to design, since a custom PCB will have to be laid out, sent off for manufacturing, tested, etc. However, that's true even for the Arduino family chips, since the CC1200 needs a breakout board, and I haven't found any.

    If we use the Adafruit BLE board, we're limited to ASCII/UART transmission and reception, and I haven't seen detailed information on whether the peripheral has any control over the pairing process. Using the nRF8001 chip on our own board should give us complete control over the entire process and more options for data transmission but again, the tradeoff will be in development time.

    If we ditch the sub-1GHz transceiver portion of the project and use only an RFDuino, everything gets much easier...but nothing worth doing was ever easy, right?

    Since the system design document must be completed by the deadline tonight (in...15 hours and 11 minutes), we have to choose our components quickly. Compromise isn't a bad thing, but unless it achieves a goal it's pointless. Therefore, I've narrowed it down to two options:

    • RFDuino with onboard BLE, without an independent RF transceiver
    • MSP430 SoC with onboard transceiver and a Nordic nRF8001 on a custom PCB

    This project may seem on the surface to be about devices, but in reality it revolves around creating a distributed, fault tolerant messaging network. If we develop a functional, useful system design that others can build on, but our proof of concept devices are lacking in their implementation, that will not be a failure of the project as a whole, and leaves the door open for further development as time permits. (It may not seem like it today, but we do have day jobs)

    With that in mind, especially since the two options I have are both excellent options in some ways and challenging in others, I'm going to take the coward's way out and choose both. The system design document will incorporate both builds, and everything but the core system board will be the same for both devices (battery, power supply, case, solar panel, etc).

    The RFDuino build will almost certainly be completed first, but PCB design, layout and manufacturing for the MSP430 system will be concurrently worked. This makes a proof of concept device contingent only upon our coding chops, but still leaves the door open for a more full featured custom build if our hardware skills are up to the task and the manufacturing gods smile down on us.

  • Access Devices

    t0x008/20/2014 at 09:26 0 comments

    Access devices (AD) aren't fleshed out in much detail in the project description, because they can take many forms.

    One example might be someone who simply wants to communicate their current location through the ZP network. Their access device could be nothing more than a GPS receiver, MCU and RF transceiver. As they come into range of a core device, their AD would broadcast their identity, current location and a timestamp.

    A more likely use case would be individuals or groups wanting to communicate with other individuals or groups. For these people, a two-way pagerPeek or ZipIt form factor would make much more sense. They'd also be free to use their smart phone or a computer with either BLE 4.0 or the appropriate RF circuitry to communicate with the sub 1GHz transceiver.

    For this project, although we'd like to build some devices like the aforementioned examples, the focus will be on the core device, and on creating a system and protocol that can be extended by the community. For this reason, the access devices will be simple - a modern smartphone (Android or iPhone supporting BLE 4.0) running our app and a Texas Instruments MSP430 development kit. If time allows, we will attempt to create franken-devices that work with the ZP network from host devices such as the Peek Pronto, Zipit Z2, and Motorola Advisor or T900 text pagers.

    If you like this project, keep an eye out - we'll be discussing communications protocols and RF frequencies soon, and you can roll your own access device for whatever your use case may be.

  • The case of cases, or "solar cells need sun"

    t0x008/20/2014 at 08:50 0 comments

    I've been considering the project enclosure, and I really want to print the case for the ZPC ("Zombie Plop Core") device. I could use a windowed project box like this one from Hammond Manufacturing, but then there'll be all sorts of kludgy hacks to get the boards and components fixed and stable in the right position. However, printing the case precludes having a truly clear window for the solar cell, because clear ABS plastics yellow and turn translucent when printed, significantly reducing the amount of energy to hit the cell. The solar cell could be attached on the outside of the case, but this device is intended to be hardy and long lived - placing a fragile solar cell on the outside of the enclosure doesn't meet that design requirement.

    I think I'm going to try to get the best of both worlds - print a case with standoffs on top for the solar cell, and laser cut plexiglass or an equivalent material to affix over the cell (supported by the additional standoffs, not the cell) for impact protection. The case should also have large "ears" on the base that will allow it to be nailed or otherwise attached to a roof or wall with appropriate solar exposure.

  • Hardware Selection

    t0x008/20/2014 at 08:09 0 comments

    The hardware selection phase has begun. As with most development projects, we're balancing trade-offs. The Texas Instruments CC430 is ideal for this project, but we'd like to go with the most open and community friendly hardware design possible. The Parallax Propeller family would give us some hefty processing ability, especially with its multiple cores, but the timeline would suffer due to our lack of familiarity with the development environment. Arduino is an obvious choice, inexpensive and quite popular also. It's an open design, easy to develop on, and is ubiquitous in this community. This provides familiarity for anyone else wanting to develop for or extend this design and should make prototype design quick and as painless as possible. The downsides to Arduino include a slower MCU and no onboard wireless.

    At this point, development will move forward with an Arduino platform as the core of the project and a Bluetooth 4 Low Energy dev board from Adafruit. Unfortunately, we don't have enough information yet to make a permanent determination on whether that will be the final design. The initial hardware selection phase has effectively been a failure, although we have a lot more information to work with over the next few weeks...

  • Genesis

    t0x008/20/2014 at 06:18 0 comments

    The idea for this project originated during Defcon 22, when brainstorming for projects using the TI ez430 Chronos. The core concept is a realistic mesh network for communication in any situation lacking effective infrastructure.

View all 9 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates