Zombie Plop

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

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

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.

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.

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 (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 pager, Peek 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.

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.

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...

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.