Daughter Boards

Note: For an up to date list of daughterboards, have a look here.


What's an electronics project without an attempt at modularity? As part of our project goals, we want a phone that can be easily modified and expanded, but still remains something you could actually use every day. How do we balance those requirements?

We played with a few different concepts like:

  • add a connector on the phone and a cable to bring signals out to a separate dev board
  • put 2 rows of headers on the back of the phone, enabling Arduino style shields.

In the end, we decided we liked a different concept: make the back of the phone a PCB.


  • add-on boards (Daughter Boards in our terminology) require no connectors or soldering
  • different daughter boards can be made for different stages of the design process: breadboarding, perf board, adapters to different dev boards, or footprints for designing custom circuitry on the PCB itself.

Implementation Details

First, we need to get the signals out to where they can be used. For this, we use some pogo (spring pin) headers mounted on the phone motherboard:

Spring Pin Breakouts
Spring Pin Breakouts

Pogo pins are nice because they are tolerant of mechanical mis-alignment, and they can also withstand many cycles.

Next, we make a PCB shaped to fit in the back of the phone, and add some pads that mate with the pogo pins. This has an additional benefit of needing zero connector cost for each daughter board. The photo below shows the back side of a daughterboard with the mating pads near the pogo pins.

Daughterboard Connection
Daughterboard Connection

Finally, the daughterboard can route the signals out to any custom circuitry you like. In this case we've made a prototyping tool for breadboarding circuits. If you were making something more permanent you might try to keep most of the components inside the phone. Or if you don't need any extra circuitry and want a smooth back surface, the PCB can be replaced with a plain panel. Or even a clear one if you're like us and think the stuff inside is the interesting part.

WiPhone With Development Board
WiPhone With Development Board

We think this is a pretty cool way to expand the capabilities of the phone and still keep the packaging clean enough to carry a WiPhone around as a daily driver. We're already working on some pretty interesting expansion boards, and we'd also like to hear what ideas other people come up with. People have mentioned LoRA, cellular radios, USB host ports... do you have any suggestions?

1 comment

  • Ed

    I would love to see a couple hooks in the code…
    One, a place to insert a bitstream from an external voice codec. Preferably that would be a function for the transmit audio stream than expects a length, a byte to indicate codec type/bitrate and array of bytes (unsigned char) simply returns the number of bytes, codec type/rate and an array of bytes ….no code but a place where I can insert code and send it to a serial or spi port. Receive function would be the same. The number of bytes sent should not necessarily equal the original stream and the call media setup should use the returned function values rather than original values (to signal codec type, you could send zer bytes of payload but set the codec/rate.

    Additionally a similar loopbacl function to pass signaling through to start/stop codec would be great.

    If there’s a second function to more easily handle the codec type negotiations, please add a similar bypass to it, and maintain a table of inbuilt delays from codecs if you need it for echo canceller setup.

    I would like to be able to add things like an DVSI codec or a codec2 board, and maybe even a separated crypto processor. Or codec plus crypto processor.

    The functions I’m suggesting would probably be helpful for debugging anyway.

    A sample use case would be to set the codec type to linear PCM on the TX function and have it send the bytes to a (multiplexed) serial port, but receive back a codec2 bitstream or an AMBE+2 bitstream to send through the network. The receive function would receive the codec2 or AMBE+2 from the remote party, but be returned linear PCM data to play on the speaker.

    When there’s code to see I can probably give a more specific set of prototype functions.

    In fact, if those functions are put in a separate .c and header file, one could link in a replacement library requiring no changes to the files the linker builds the executable from. A clean hack would minimize the need to fork code later.

    Put more simply, I’d much rather focus on building the open source bolt ons for what I wanted to do specially, let someone else focus on cellular module add on, and give everyone every reason to start with your “chassis”

Leave a comment

Please note, comments must be approved before they are published