ZeroPhone - a Raspberry Pi smartphone

Pi Zero-based open-source mobile phone (that you can assemble for 50$ in parts)

Similar projects worth following
This is a mobile phone that:

- First and foremost, will be a well-working reliable phone
- Is as open-source as possible *while also being cheap*
- Can be assembled and repaired independently
- Is easy to get parts for
- Doesn't have apps with privacy concerns
- Allows to write your own apps in Python

It costs about 50$ in parts, and all the parts are available on eBay/TaoBao/etc, most of the phone can be assembled with just a soldering iron. User interface is written using Python
and is being morphed into a lightweight phone-tailored UI framework.

A crowdfunded manufacturing run is expected in a month - kits will be available, as well as a small batch of fully-assembled phones. Subscribe to newsletter below!

Subscribe to the project newsletter - to get weekly news and be notified about crowdfunding!

Read previous newsletter editions

Latest newsletter edition:

  • Modern phones are getting more and more complicated and hardware-packed. Unfortunately, that means they're becoming less modifiable and repairable.
  • Phones are getting more and more integrated. Unfortunately, that means more and more possibilities for manufacturers to lock them down without allowing us to modify them.
  • More and more software&hardware is kept closed-sourced. That means it's harder to learn, experiment and customize your phone.

The factors I've listed (integration, complexity and closed-source) are necessary in the world we're living in, with all the advances in engineering, competition between companies, as well as laws in different countries.

However, what if we could have a phone free from those constraints?

So, ZeroPhone project was born. Nowadays, we should be able to assemble a phone from easily available parts, using cheap boards that run Linux, and we should be able to adjust it to our needs - unlike as it is with modern phones, when we have to adjust ourselves to suit the workflow that the phone offers. With ZeroPhone, hackers can finally have smartphones that are going to work for them and not against them, people with special needs will be able to have to have custom-tailored phones, and people that want to protect their privacy will have a phone that respects that.

Technical challenges are: developing PCBs that'd be reasonably feature-packed, but with easily sourceable components that could be soldered without special tools, as well as developing mobile phone software that'd be open, high-quality and highly modifiable to suit any needs people might have. However, much bigger challenges are - building a community of people experimenting with ZeroPhone platform, keeping ZeroPhone open-source and independent of any harmful influences, and experimenting with new ways of integrating smartphones in our lives without having to lose privacy in return.


  • Raspberry Pi Zero in a PCB sandwich
  • No proprietary connectors, hard-to-get parts or chips that are tricky to solder
  • All the specifications for making this phone yourself will be available
  • Python as the main language for developing apps (aiming to add other languages later)
  • UI toolkit that makes app development quicker and easier
  • Numeric keypad, 1.3" 128x64 monochrome OLED screen (also supports other screens)
  • 2G modem for phone functions, can be replaced with a 3G modem
  • WiFi (using an ESP8266), HDMI and audio outputs, a free full-sized USB host port and a MicroUSB port for charging
  • GPIO expansion headers for hardware addons and customization
  • RGB LED and vibromotor - for notifications

ZeroPhone Wiki

Interesting articles:


#pyLCI fork used for ZeroPhone is licensed under Apache License

ZeroPhone PCB files and keypad controller firmware are licensed under GPL v3

Original project description and FAQ (January 2019)

  • Sending out ZeroPhones; assembly experience

    Arsenijs2 days ago 0 comments

    ...I've sent out 3 ZeroPhones before this week, just sent out three more packages and, if I'm lucky, will send out 2 more tomorrow or the day after. These phones are for case designers and other contributors - I'm not yet sending them out to reviewers, simply because it's a tad too early for that. SirCmpwn joined our IRC and expressed interest in working on alternative UI implementations - so I remembered I have just the thing:

    This is pretty much the ZeroPhone front board, without GSM audio parts- it can simply plug on top of a Pi Zero (it's best if Zero is in some kind of case). It's good for developing UI and apps, working on ATMega firmware, as well as just using it as a simple interface for your Pi - with the screen, buttons and audio jack, what's not to love? So, for application development, if I have to send somebody a ZeroPhone and I don't have back board part or a Pi Zero, I can just send this board to allow to start development and then, later, send the rest! I wonder if people will be interested in these during the crowdfunding.

    So, I've been assembling and testing these phones - what I've learned, experienced and started doing differently?

    Read more »

  • Challenge: Zero W Bluetooth problem

    Arsenijs6 days ago 0 comments

      BCM2835 has two UART interfaces available - one "stable-frequency reliable UART" and one "unstable-frequency not-so-reliable UART". Currently, ZeroPhone re-maps the "stable frequency UART" to the GSM modem, because GSM has a higher priority in the project. Bluetooth, in turn, is re-mapped to the "unstable UART" - and that's where it stops working, I didn't really look further, though here's something that looks like a solution. 

      Can you help with getting Bluetooth to work in the basic configuration, as it is? Instructions:

      1. Get a Pi Zero W or a Raspberry Pi 3, upload Raspbian on SD card, boot it and log in
      2. Add one line in /boot/config.txt: dtoverlay=pi3-miniuart-bt
      3. Reboot, check that "hcitool dev" doesn't list any Bluetooth adapters anymore
      4. See how Bluetooth can be brought back to life, and somehow assess how reliable it is.
      5. Write instructions, which are to be included on ZeroPhone Wiki.

      The stakes are, undoubtedly, high, and rewards consist of some Latvian chocolate mailed to people that help the most =) Performance and compatibility tests with various Bluetooth devices (ideally, audio output devices and streaming music to them) and any other insights will be highly appreciated.

  • Mod boards and expansion ports

    Arsenijs6 days ago 4 comments

    ZeroPhone, apart from being an open hardware&software smartphone, is hackable and, therefore, has a couple of unused hardware interfaces - like SPI, I2C and I2S. They can be used for electronics tinkering, reverse-engineering and adding features - but what better purpose there could be for them, if not having optional hardware additions to ZeroPhone?

    So, first additions have been attempted with ZeroPhone Gamma version - I've designed three boards - one audio filter board (I later found that the power regulator I picked was too noisy), one SPI flash chip board (where I've accidentally miswired the pinout, so it wasn't usable and would burn flash chips inserted into it), and one ATMega programming board (which should work, but didn't have enough silkscreen markings or documentation to actually be useful). For the next version, I'm working on 15 different mod boards, and I'll add some more later- they'll likely be offered as addons during the crowdfunding. Let's see what some of these mods can offer!

    Read more »

  • How to actually make money from ZeroPhones? (a.k.a business plan)

    Arsenijs07/24/2017 at 13:02 0 comments

    So, Hackaday Prize Best Product category requirements require a "business plan" - I have one hour till the deadline when it needs to be published ;-) But, incidentally, profitability is what I've been thinking this year - even though I love working on this, sometimes I still have to get distracted to side projects just to pay bills and buy hardware I need for this project (and there are always some unexpected expenses, like me spilling tea on my laptop last month). Making and selling hardware is the usual way for open-source hardware&software projects to bring some revenue. However, I imagine that with ZeroPhone, it's going to be a little more tricky than that.

    See, ZeroPhone software is open-source, hardware is open-source, parts are really easy to get - there's literally nothing stopping somebody from copying this project if it becomes popular enough, and selling hardware on their own. Furthermore, people are encouraged to assemble their own ZeroPhones - this is kind of the whole point of this project! 

    So, when there's reasearch and development to be funded, there are contests/giveaways/bug bounties to be organized - how to get money for those, when the project's IP is open-source? 

    The most likely starting point for me will be selling ZeroPhone boards with SMD components already on, as well as ZeroPhone kits. For many people, SMD components are still out-of-reach in terms of skill (though, in most cases, it's just that they haven't tried ;-P ). As SMD assembly is much easier for manufacturing, selling PCBs with SMD parts already on would be pretty a low-hanging fruit in business terms. As for kits - this is maybe the most obvious idea, and I might just start first experiments with this one in a couple of weeks =)

    However, as I already mentioned in some worklogs, judging by the survey responses, it seems like most people won't self-assemble ZeroPhones, but instead would like to buy pre-assembled ones. It's perfectly reasonable, and I should have expected this kind of statistic before - though I'm still figuring out how it'll work with the whole "manufacturing" thing. So, that's one source of revenue - ZeroPhone assembly services. While $50 is OK as BOM cost, it certainly doesn't cover assembly and testing, when it's done by somebody else. 

    Then, mod boards. ZeroPhone is extensible, it has extension ports, for which you can develop ZeroPhone add-on boards - for example, my favourite is a SPI flash programming add-on. Of course, you can still use a breadboard and some jumper wires, but just inserting a PCB into a socket is so much quicker and easier. The mod boards are supposed to be open-source, of course, but, in contrast to the ZeroPhone itself, they're not meant to be easy to assemble, or have easy-to-source components - mod boards are not essential to functioning of the phone, after all. So, you can have a mod board with an I2S microphone that absolutely needs reflow soldering with some low-temperature solder, or a mod board with an obscure IR transmitter/receiver, or even some BGA chips, and you are free to sell them to an existing market of ZeroPhone users that want this or that capability for their ZeroPhone - like, an Ethernet socket =)

    Also, there's the "production-optimized ZeroPhones" idea. Basically, a version of ZeroPhone that's optimized for manufacturing instead of self-assembly - and, as a side effect, is smaller, consumes less power, has some additional functionality and might even cost less - but, more importantly, it's much easier to assemble and test those. Granted, they'll be less repairable - but still repairable (being fully open-source), and hardware will likely remain modular, though unlikely in a way that current ZeroPhones are. So, if assembly of ZeroPhones will be too hard of a task for large-scale assembly, this will be the option to pursue.


    Read more »

  • Developing a simple UPnP/SSDP scan app

    Arsenijs07/21/2017 at 22:10 0 comments

    I'm sorry for the lack of code highlighting, especially given that it's crucial in this worklog. It seems to be some kind of glitch - I hope it'll get fixed soon.

    Sometimes, I find interesting articles that explain various network security concepts in a simple way. This week, I've found an article (in Russian, but the part that the snippet is based on is available in English) about UPnP and botnets, with some Python code snippets - and I've decided to build an app around those snippets. As I've built it now, I'm going to describe my app writing workflow - while I still remember it =)

    First, SSH into my ZeroPhone and try this snippet (from the article in Russian):

    #!/usr/bin/env python2
    import socket  
    import sys
    dst = ""  
    if len(sys.argv) > 1:  
        dst = sys.argv[1]
    st = "upnp:rootdevice"  
    if len(sys.argv) > 2:  
        st = sys.argv[2]
    msg = [  
        'M-SEARCH * HTTP/1.1',
        'ST:%s' % (st,),
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)  
    s.sendto('\r\n'.join(msg), (dst, 1900) )
    while True:  
            data, addr = s.recvfrom(32*1024)
        except socket.timeout:
        print "[+] %s\n%s" % (addr, data)

     It works and prints stuff! Furthermore, it can be tweaked - the most tweakable value seems to be the timeout value, as that's effectively how long the "scanning" part will be running. Let's convert it into a simple app!

    Read more »

  • Hardware worklog: display problems understood

    Arsenijs07/18/2017 at 03:25 10 comments

    When I was sourcing parts off Taobao, I ordered wrong display breakouts. They looked just like the ones I was supposed to buy, with two small differences - GND was swapped with VCC, and pin header had RST instead of CS. First problem caused me to burned a panel or two, second problem made me waste a week or two of my time. Here's how it goes:

    The ZeroPhone has expansion ports. In particular, there's a 13-pin expansion port on the side, with SPI-0 port on 4 of them. SPI is a really popular communication standard, you can use it to re-program BIOS chips, ATMega/ATTiny/other Atmel chips, show things on LCD/OLED/E-Ink displays, communicate with SD cards, RFID readers, thermocouple amplifiers, GPIO expanders... I have designed two mod boards for this exact headers, and I wanted to include them in the package sent to reviewers and contributors - because I believe it's important to show that ZeroPhone also has tools that make hardware experimentation easier.

    SPI uses the CS pin to signal, which peripheral it currently wants to communicate to. SPI-0 on the Pi has 2 CS lines - one goes to the display header, another goes to the expansion header. If, however, the display doesn't have the CS line exposed, then there's no way to signal to the display that it's not supposed to receive information at this point when, for example, there's an RFID reader on the expansion port. The result will be, at best, garbage shown on the display - at worst, the display might interpret commands sent to RFID reader as commands for the display, and it might even damage the display.

    So, just re-wiring the breakouts, swapping RST with CS, should be easy? After lots of broken panels and wasted time, I understood this wouldn't be the case.

    Read more »

  • Project state - boards to be tested, Hackaday Prize, project plans

    Arsenijs06/21/2017 at 06:31 2 comments

    A new version of ZeroPhone is being in-field tested right now, and the batch of 20 ZeroPhones is almost built - I'll be testing it now.

    Boards in stacks of 5. I ran out of some passives to finish the boards in the bottom left corner, but I'll have them tomorrow.

    The boards pictured are already checked visually, no visible soldering bridges or misplaced components (there were a lot of those). Now they just need some THT stuff attached - that will need lots of human intervention, but I've found some people that can help with it, tomorrow and the day after =) Also, hey, at least I seem to have all the THT parts I need and don't need to run around sourcing them.

    Read more »

  • Project state - assembling ZeroPhones!

    Arsenijs05/28/2017 at 17:20 2 comments

    So, I got the Gamma boards, panelized, 22 front&keypad board panels and 24 back&18650 board panels, all from DirtyPCBs:

    I also got lots of passives and actives, headphone jacks, all that, it seems I have all the parts necessary for ZeroPhone assembly. BTW, if you want to learn to panelize the boards like this, I got a tutorial for you =)

    Read more »

  • On volatility of Chinese breakouts; "production-ready" ZeroPhones

    Arsenijs05/28/2017 at 16:15 1 comment

      As I mentioned earlier, ZeroPhone is basically a PCB sandwich. Now, ZeroPhone consists of three custom boards, a Pi Zero and 5 Chinese breakouts:

      1. ESP-12 board
      2. SIM800-based modem board
      3. 1.3" OLED breakout
      4. Li-Ion charging circuit
      5. Step-up DC-DC board (generates 5V for USB port)

      All of these boards, except (very popular) ESP-12 breakouts, can change. Reasons are - Chinese optimize those breakouts all the time (decreasing BOM count and/or PCB size), want to add features to innovate (consequently, to raise price), and, I think, sometimes just copy the pinouts and board outlines from one another, re-tracing the board.

      For example, here are photos of different Arduino Pro Mini clone PCBs I have:

      Some of them don't look different, but the traces are all routed differently, and some differences are easy to spot from this photo - such as holes changing places. And that's only what I have currently, I've used and seen much more different boards.

      They went through these revisions in a couple of years, and it was mostly moving components around, but pinouts also changed - mostly A4-A7 pins. If you're designing a shield for Pro Minis (for easier assembly and user-friendliness) and it uses I2C, tough luck with sourcing boards.

    Read more »

  • Hardware switches and new discoveries ("paranoia worklog")

    Arsenijs05/24/2017 at 05:07 0 comments

    Let's talk about hardware switches, advertising profiles and side-channel leaks. ZeroPhone is different from many smartphones in that the GSM baseband is separate from the CPU, so there's no proprietary code running on the CPU that comes from the GSM modem manufacturer. The communications happen through UART and are controlled by and directed through open-source software.

    I sometimes got questions about hardware switches. It's a niche but nice feature - not only it's the ultimate power consumption decreasing mechanism, it's also a way to ensure the radio-enabled components can't work when you absolutely don't want them to work - for privacy and safety. ZeroPhone is using off-the-shelf GSM modules - and they have an inner CPU which runs some kind of firmware, and that firmware running on the modem can make it transmit, even though you might not be telling it to transmit. We can implement software kill switches, but maybe the software itself is going to have bugs? The simplest and most powerful "just make sure it's off" hack is cutting the VCC line to the modem, ensuring it doesn't work at all and thus doesn't have the ability to transmit when you want it turned off.

    One more reason for that - what if the GSM modem firmware is malicious? We don't know, SimCom doesn't provide much of source code and SDKs, and one of the modem batches they send out could be programmed with a firmware that's slightly different from the widely-used firmware, with some *extra features*. Can we *trust* the modem? No, not really.

    Read more »

View all 32 project logs

Enjoy this project?



dinu wrote 09/09/2017 at 02:46 point

Great piece of work, thanks for sharing.

  Are you sure? yes | no

Magnus Westin wrote 09/02/2017 at 05:42 point

I tried to make a donation using your paypal link, but got this error from paypal:
This recipient accepts PayPal payments only through their website. To complete this payment, please go to their website and follow their instructions, or email the recipient for instructions.

  Are you sure? yes | no

Arsenijs wrote 09/06/2017 at 01:23 point

The new link is - I'll tell about the problem that happened in one of the next newsletters =)

  Are you sure? yes | no

Arnaldo Pirrone wrote 08/11/2017 at 10:50 point

Hi, does it makes sense redesigning the modem board to use a simcomm SIM7600C module or equivalent which supports LTE? Considering that GSM/2G is being dismissed more and more and the fact that the ZeroPhone might also be a great pocket modem device (like huawei pocket modems) i'd assume yes. I don't know if it would be cost effective, though.

  Are you sure? yes | no

Arsenijs wrote 08/13/2017 at 08:49 point

Right now, I'm trying to find time to finish the adapter board for SIM5320 that I've started =) It's 3G, and shouldn't require too much additional hardware, so that should be OK for now - 3G doesn't seem to be dismiss-able in the next couple of years.

  Are you sure? yes | no

Blecky wrote 08/09/2017 at 05:12 point

Have you considered a Nokia style case for this at all?

  Are you sure? yes | no

Arsenijs wrote 08/13/2017 at 08:47 point

I have, just that the PCBs will definitely need to be redesigned. There's #Nokia 3210 Retro Fit Board project - I'm watching it closely, check it out, too, it's great!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 08/06/2017 at 23:05 point

Description page : January 2019 ??

  Are you sure? yes | no

Arsenijs wrote 08/13/2017 at 08:46 point

Yep - I have quite a backlog of work, and while this is a priority, it's not as important as, say, finally getting a couple of ZeroPhones assembled to be shipped =) I'm hoping to move this to ZeroPhone Wiki, eventually.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 08/13/2017 at 10:16 point

I can't wait !

  Are you sure? yes | no

Mis012 wrote 08/01/2017 at 11:03 point

Hi :)
I had this idea myself, but not enough skills to pull it off.
What you did looks really cool :) This is something In would 100% implement, because it's the right way to do it (and possible with pi zero - why not take advantage of that?) :
I hope you like this idea. ^
Also, not sure how much you like your current display, but the cheapest NICE display I found on ebay is this:
not from this seller, there were cheaper ones last time I looked. there is python code available  somewhere to use these, or fbtft (which I would use, combined with a simple C framebuffer library, you basically just make your own). The display(/driver)-specific source file I found in mainline staging, interestingly enough. The nice thing is, a lot of languages can use c libraries. It should be gpu-independent, unless you use mirroring for hardware accelaration. Hope you consider this :)

P.S disclaimer: I hate python syntax, I rather learnt C

  Are you sure? yes | no

Arsenijs wrote 08/03/2017 at 05:11 point

Thank you for the tips! The appnote is interesting, might be a base for one of future mod boards. Those displays are nice, alright, but the breakouts are too big for the top margin of 10cm that I'm limited by - the keypad board is 6cm high, so there's 4cm for both speaker and the display, so this display doesn't quite fit =( Also, by now, there are multiple breakouts for this display, all with different pinouts - and this is a problem for me. But yeah, I'd definitely use fbtft with that display, too (yes, fbtft has now moved to the kernel). So - noted, and future revisions might use this display =)

  Are you sure? yes | no

Mis012 wrote 08/18/2017 at 10:30 point

I'm not sure if you understand what I mean, but it is supposed to be the only usb port - charging + connecting to pc + OTG. If you don't use it, you have 1 micro usb for charging, one for data (and if you use full size for data, you kill off the usb slave function, and a lot of people seem to like OTG functioning properly (unique to zero/W)). You could make a full-size usb mod board, if that's really possible with mod boards, so you don't need OTG cable. for reference.

I'm glad you like the display idea :)

Also, considering this form factor cannot easily use android apps, I would suggest this instead, for a little retro feel: It should be easy to map it to the buttons on the phone (once the java part has sources available, or you can wait for a config implementation). Alternatively, you can use hex editing to change the keycodes, but it took me half a day to figure that out.

  Are you sure? yes | no

Arsenijs wrote 08/26/2017 at 21:09 point

My decision for now is to not use the slave functionality. However, I might just add an easy-to-use addon that'll allow for it. The guideline for me is having "a standalone portable minicomputer", and in that light it totally makes sense to have a full-size USB port. So, current arrangement eliminates the need for any special cables - for example, out of the box, you can plug in a USB 3G modem, connect the phone to charger and make a hotspot (last part is not yet available in software, but I'll work on it). For OTG, simultaneous charging&USB requires a cable that has some kind of resistor between GND and ID pins, and it's much harder to find a cable that actually works (though, it seems, EOMA68 crowdfunding campaign has found a source, for example). 

Nevertheless, connecting the OTG pin from the Pi to the back board, adding a charger&boost IC and a MicroUSB socket is possible (with a small back board redesign and a small add-on board with a MicroUSB socket), I just don't feel like it's the right decision for most of ZeroPhones. Instead, for now, I'll make an (optional) mod board that'll add a USB-UART on the LiIon charger board, as suggested recently - so the charging socket will actually be a charging+console socket, somewhat of a "developer edition". BTW, will you yourself be interested in a MicroUSB ZeroPhone? If so, I'll put it in my list of "things that people might want that I'll have to keep in mind when designing PCBs".

The J2ME thing looks promising - though I don't think it'll be useful until there's a color display, but once it's there, I'm guessing it could look great =)

  Are you sure? yes | no

Mis012 wrote 08/28/2017 at 09:32 point


I've been gifted an android phone quiet recently, so I'm not looking for new phone at the moment. If I did, I would like USB slave functionality, trough OTG or not. Of course a hardware 3-switch (data+id) for the A port would be more handy than needing an otg cable, that I can understand.

Another thing I'd love to do, would this be my project, would be an X session JUST over Miracast. Probably with XMonad or something similar, custom key shortcuts, and maybe some menu on the device display. Not sure how well it'd work with phone keyboard text typing. But it would be an amazing way of accomplishing convergence or how it's called. But it would highly depend on the usability.

Also, in my country (czech republic), the 3G infrastructure was never really built, so 4G has WAY better signal coverage..

  Are you sure? yes | no

Arsenijs wrote 09/06/2017 at 20:00 point

Hi! I've been thinking about OTG, and it's very likely the slave mode could actually work in the current hardware configuration (no mods required), I just need a USB male-to-male cable to test it sometime soon =)

I've heard that Miracast driver support is subpar. Which is very sad, since I myself have been looking at wireless display technology and haven't yet found a decent solution. Let's see what the future brings to us!

3G: weird. Oh well, we'll certainly get a 4G modem eventually, anyway.

  Are you sure? yes | no

afshaan4 wrote 07/24/2017 at 08:30 point

awesome project 

i'm definitely building one for myself

  Are you sure? yes | no

GNUtoo wrote 07/23/2017 at 19:14 point

Your project seems to be interesting as:
- As I understand it doesn't use the raspberry pi GPU or
doesn't need to as it uses an SPI display.
- It focus on a minimal and manageable set of functionalities.
- The electronics seem to be assembled in a solid way.

I've some suggestions:
- The Raspberry pi uses a non-free firmware to boot,
but that might be avoidable by using rpi-open-firmware[1]
and adding the missing to make it usable on your hardware.
This will enable privacy conscientious people to use it.
- Make it robust and usable for everybody that have limited
uses cases: not everybody needs a smartphone. Even a
feature phone would work fine.
Also many people would expect or wish to have something
that works out of the box (so non-technical people, or
technical people without much time would be able to use it)
and that works in a robust way(like you don't miss phone calls,
or the phone doesn't break when it rains or travels in your
- Take advantage of the freedom if time permits:
- Make it compatible with Android applications like silence
or Jitsi on GNU/Linux to be able to encrypt calls and SMS.

Robustness suggestions:
- Make a case that is as reliable as the ones on common
- Beware of microSD: According to Andrew 'bunnie' Huang[2]:
"Ultimately, however, every card I’ve encountered
eventually corrupts the filesystem after enough cycles,
it’s just a matter of how long."



  Are you sure? yes | no

Arsenijs wrote 07/25/2017 at 04:16 point

Hi! Great points here, and I've been thinking through them already for quite some time! In a way, this does still use the GPU - it's used by Raspberry Pi in many ways, including pre-Linux bootup, framebuffer, some peripherals IIRC, so it's not as simple as that. Focusing on minimal&manageable set of functionalities is, indeed, what I'm trying to do, at least try to keep myself to it - it's hard to hold back from writing small apps for fun sometimes =) The solidness of electronics is still something I'm currently testing and improving - and it did recently go through 12 days of uptime with no problems, uptime is kind of a "high score" thing for me (but I do have to charge it every night to keep it up).

AFAIK the open-firmware is still lacking quite some peripheral support, but, yes, I've already bookmarked some interesting links about it, and I'm planning to give it a try soon. Maybe there could be a community effort to motivate the developers financially, but then, I'm not sure that the developers consider it to be something they'd be glad to get money for to work on.

Agreed on the robustness. Speaking about it, and cases, a case is going to be developed - there are quite some problems when the phone is out of the case, such as display panel's edges breaking enough to make the image on the display unreadable =( Not to mention that lint from my jeans' pockets is collecting inside the phone by now ;-{

All of the code I'm working with is free, I'm taking advantage of free&open-source software as much as possible at this point - however, I'm sure there are still non-free parts in Raspbian, and I'm not a fan of "not install non-free stuff by default if it's necessary" approach - though I understand it and am moving towards conditions where it's a choice you can make while keeping the user experience the same. Also, unfortunately, it's hard for me to imagine compatibility with Android apps - I perceive it to be quite fundamental of a task, given that ZeroPhone currently runs Raspbian, and the screen doesn't allow for that, either. I'm not saying that the compatibility would be impossible, but I'm sure it'll be tricky. and I'm not well-versed to implement that.

Having encountered SD card corruption myself, I agree. It seems we'll need a good backup app for ZeroPhone - now that gets me thinking... =)

  Are you sure? yes | no

Arsenijs wrote 07/18/2017 at 03:40 point

Hi! So, I've been testing a ZeroPhone with a Zero W for a month now. Well, it works - I was a little afraid about DC-DC not quite capable of delivering enough juice to everything, but it does seem to work as well as it does on the Zero. The two problems are: the WiFi antenna reception is not that great (could be normal for the Zero W, could be decreased from normal due to all the metal around the antenna - I'll have to put Zero W and Zero-based ZeroPhones next to each other and check), and Bluetooth is not accessible out-of-box - I figure it's because the DT overlay I'm using to remap stable UART back to GSM is not quite enough and there are some configuration files which need changes made (I just didn't have the time to dig further). Other than that, there don't seem to be any problems =)

  Are you sure? yes | no

elvestal wrote 07/06/2017 at 11:50 point

Can we get this ones with 3G and swedish keyboard? I want 3.. no 5. To start with. Better fire up that emulator and start building a lot of great apps

  Are you sure? yes | no

Arsenijs wrote 07/16/2017 at 17:27 point

Hi! Damn, no notifications again =( The 3G upgrade is in the works this week. As for the Swedish keyboard - I'll be looking into getting Unicode fonts on the display, then we'll be able to have all kinds of input (and localisation) languages on ZeroPhone =)
If you'll have any questions about app development (like, ways to do things, tips etc.), come to our IRC - #ZeroPhone on freenode,

  Are you sure? yes | no

elvestal wrote 07/17/2017 at 16:24 point

This is nice, I would love to get the required hardware for building 8-10 phones on our next maker-space meetup, a perfect way to spend a saturday in Sweden

  Are you sure? yes | no

Arsenijs wrote 07/17/2017 at 23:54 point

This sounds great! It's likely going to run you about 500$ in hardware, and I can walk you through the "ordering parts" process if you'd like me to - I'd be happy to compile a "sourcing parts" page for the Wiki, at last =)

  Are you sure? yes | no

elvestal wrote 07/18/2017 at 04:26 point

Thank you that would be terrific. I hope we will be able to take it from there, otherwise I guess we'll just have to buy you a ticket. ;)

  Are you sure? yes | no

Arsenijs wrote 07/22/2017 at 22:10 point

Sent you a PM, do check =)

  Are you sure? yes | no

Tindie wrote 06/30/2017 at 21:14 point

We'd love to see this on Tindie :)

  Are you sure? yes | no

Arsenijs wrote 07/18/2017 at 03:43 point

Eventually, I'm going to sell it on Tindie - but this is likely going to be after the crowdfunding =)

  Are you sure? yes | no

oshpark wrote 06/24/2017 at 19:02 point

Great project!  Are there shared project pages for the boards that were made with us?  Thanks, Drew

  Are you sure? yes | no

Arsenijs wrote 06/24/2017 at 19:13 point

Hi! Of course, that's the least I could do for you, I'm very thankful for your help when I was working on the beta version! The current version OSHPark shared links can be found in this blog post: , I'll be sharing new versions upon each board release. Once I'll make a ZeroPhone Wiki page on sourcing ZeroPhone components, I'll also add the OSHPark links there.

  Are you sure? yes | no

oshpark wrote 06/24/2017 at 19:22 point

Great, thanks!

  Are you sure? yes | no

dj butansky wrote 06/22/2017 at 16:36 point

Looks great.

Since you are in the game could you give an opinion on how hard a POCSAG pager module would be to add to this?  It has been done with RTL-SDR on the N900 but an integrated and low power receiver/decoder makes it an everyday user's option to be radio silent and untracked unless we want to power up the modem and connect to the mobile phone network.  I discussed this with RMS and he would consider finally acquiring a FOSS mobile phone like this if it respected the user's privacy rather than the power of the state and profitability of the mobile network company.

  Are you sure? yes | no

Arsenijs wrote 06/24/2017 at 10:10 point

Hi! Do you have some specific POGSAC module in mind? It seems some of them use RS232, and we could definitely communicate over that. BTW, I even have 3 or 4 Motorola pagers in my collection of old tech - though when pagers were all the rage, I was too young to have one =) Do you have some info on the RTL-SDR&N900 usage? (seems like it's receive-only)

I think that RMS would be not pleased by the fact that there's still proprietary firmware on the Pi Zero, basically, the whole GPU-that-launches-CPU thing. Once we have a BeagleBone CPU module, however, I think it'll be OK =)

  Are you sure? yes | no

dj butansky wrote 06/24/2017 at 17:48 point

I am a N900 user still, so obviously not as pure as our prophet.  The RTL-SDR used the regular Linux SDR tools and a customized UI gqrx, I dont recall the decoder for pagers, Morse, etc; but the RTL TV dongle literally ran hot in the fragile USB port, not feasible because of the wasted electricity.  I dont have any pagers anymore in my junk collection but yes when talking to Joerg from the opemnoko/GDC project about a radio-silent but listening pager mode; so he came up with the hacker buss during the design phase for the Neo900, a GTA-4mod for the N900 form factor.  The hacker-buss POCSAG module was never actually designed that I know of but he spoke of there still being RS232 interface easy to PCB hardware around.

  Are you sure? yes | no

Arsenijs wrote 06/24/2017 at 19:24 point

The RTL-SDR kind of decoding has to use lots of CPU power, too, so the RTL-SDR wouldn't be the only thing running hot.

Check this out: - Products.htm This is literally the first result when searching for "POGSAC module", and I can't find the price but the hardware seems OK. Any info on this?

Also, how do you test the module? Are there still pager networks in some countries? Because I think Latvia has long abandoned the thing - but I can re-check if necessary.

Haven't received a notification about your comment, weird =(

  Are you sure? yes | no

Arsenijs wrote 07/22/2017 at 22:11 point

Hi! So, any POGSAC info? I'm trying to understand what the testing setup will look like.

  Are you sure? yes | no

dj butansky wrote 07/23/2017 at 07:40 point

For power savings POCSAG pagers use an IC, I played with RTL-SDR but that is like trying to power a hotplate from a USB port.  

FM RX IC->decoder IC->serial out to ???.  
Sadly I do not know the best packaged silicon solutions to suggest to you but below are two good primers on the whole system with amateur radio DIY paging network from start to finish.

if you are an IEEE this should have the design info, I cant read the whole thing though, no login.

here is an example decoder IC datasheet, just add a radio rx IC.

Sadly most info for hacking is for use with RTL-SDR our cheap unexpected RF deus ex machina.
But RTL dongles burn furious power vs a dedicated IC.
I remember getting a month out of my Motorola numeric pager in the 90s, it might be easiest to hot air harvest components from a old pager or cut some traces and patch the PCB to a breadboard, read the datasheets, and plug into the serial lines since you seem to have mastered SM PCB awesomeness.
I can look further for datasheets etc, just let me know; remembering I am a kludge of a hack who only really has the powers of soldering, reading English, and perhaps a principled paranoia against technology enabling a tracking society.

  Are you sure? yes | no

gir wrote 06/20/2017 at 22:13 point

congrats! I'm _so_ looking forward for this project getting finalized! Arsenijs - you earned your 1k$!

  Are you sure? yes | no

Arsenijs wrote 06/24/2017 at 10:02 point

Thank you! I hope that you'll continue to make great stuff and inspire others by your great projects, too! =)

  Are you sure? yes | no

Youlian Troyanov wrote 05/31/2017 at 14:40 point

how long until it's on crowd supply? also could you make it maximally modular? i would like to use parts of your design with a completely different arm board, for example, an allwinner one, like chip. using a different arm board could make the whole thing significantly cheaper.

  Are you sure? yes | no

Arsenijs wrote 06/24/2017 at 10:00 point

Sorry, for some reason I didn't get an email notification about your comment =( I'm still delayed by the prototype batch, but now I'm building a testing jig to test the parts - then, after fixing all issues found during testing and sending the phones out, the campaign can start =) 

Currently, modularity is more of a side effect, but, due to the fact ZeroPhone consists of separate PCBs, it's indeed possible to re-use them and replace them - for example, you could swap in a different keypad board. However, the processor board is to be stacked with the front and back boards in the current configurations, so unless you want to re-design the front and back boards, you'll need to design a new CPU board with the same pinout and more or less the same form factor as the Pi Zero does. Oh, and you definitely could re-use the schematics =)

I'm curious - which boards do you want to use? I'll be planning for some compatibility with other boards in the next ZeroPhone versions, so knowing about what you want to use would be very helpful because I could plan it in in earlier stages and maybe figure out some problems I wouldn't figure out otherwise,

  Are you sure? yes | no

Radu Motisan wrote 05/23/2017 at 14:28 point

this was on my todo list as well

  Are you sure? yes | no

Arsenijs wrote 05/23/2017 at 15:01 point

Hey, join the project if you feel like helping =)

  Are you sure? yes | no

Andrew Pam wrote 05/04/2017 at 17:12 point

2G mobile has already been switched off in Australia, so this won't be useful without at least a 3G modem.

  Are you sure? yes | no

Arsenijs wrote 05/14/2017 at 01:24 point

Yes, that's sad. The new version is soon to be in the works, I'm currently consulting people about component choice because a part of the back board needs to be redesigned for a bigger modem.

  Are you sure? yes | no

Ramon Schepers wrote 04/15/2017 at 21:16 point

i see you are using the pi zero (w), though i wonder why though.
i mean:
1: the pi zero has high power consumption unlike a stm32l4 (for example), so you can use a smaller battery as well
2: if you want to shrink down to a thinner device, you'd need a custom pi zero pcb (including bga package soldering!)
3: the size of a pi zero ain't optimal for a phone-like device.
4: do you really need a pi zero (with it's half gb of ram) for a (dumb?)phone?
5: the pi zero does not have a ADC built in* by default, so if you want the call audio go trough the pi, you'd need to hack a adc in first

note: this is not meant offensively at all, just curious why you did these design choices :)

* = if i am right

  Are you sure? yes | no

Ramon Schepers wrote 04/15/2017 at 21:17 point

i forgot to mention though: i had a similar idea for quite a while by now :)

  Are you sure? yes | no

Ricardo Ferro wrote 04/15/2017 at 23:46 point

make one with stm3214 , that thing has ultra low power at 8 nA!

  Are you sure? yes | no

Arsenijs wrote 04/15/2017 at 22:28 point

Well, it's not "just a DIY phone", and it's not evena  dumbphone, there are enough of those =) It's a Linux-based smartphone, which re-uses all the wonderful software available for Linux, and it's also based on Raspberry Pi - a platform that many people are familiar with. When it comes to "just dumbphones", yes, you can make one with an AVR or an STM, and you'd learn a lot on the way, but it won't have as much potential than a Linux-based phone will - and you'd never out-compete Chinese dumbphones on price!

In general, it's more like a platform for developing whatever you want that could be based on a smartphone. Therefore, it needs to be as much high-level as possible - that's why user-exposed parts are mostly in Python, not a lower-level language =) It's so powerful in terms of capabilities, you can easily use this phone to develop software for itself - and if that means I'd need a bigger battery, I'll just attach a bigger battery. Yes, the size is not the best, the pinouts aren't the best - but then, hardly everything always fits perfectly. Shrinking down would be a problem, but see the #RPi Zero WiFi-Enabled Hardware Password Manager - it's pretty damn small, I have one and I don't see why you'd actually want to make a phone that's even smaller than that =D

*yeah, there's no ADC, but I'm using an ATMega328P on one of the boards, it takes care of all my ADC/PWM needs.

  Are you sure? yes | no

kunstenaar wrote 04/17/2017 at 18:22 point

Did you have the time to measure, how the Zero W behaves...?

Other options to provide options for lower power consumption? Things like this?: (see also comments there) (you need to scroll down a bit to come to 'Initial Adventures in Power Reduction') (the question what you can achieve with cpufreq, but I do not know its current status on RPi, and if such 'tricks' work) 

  Are you sure? yes | no

Rishaldy Prisly wrote 04/30/2017 at 20:32 point


  Are you sure? yes | no

Louis Pearson wrote 04/14/2017 at 05:27 point

I am really intrigued by the possibilities of this project! Definitely interested in getting one when the crowd supply campaign starts :)

In a possible future iteration, might you consider using a EOMA68 ( It isn't quite there yet, but it would make this device even more repairable! Just thought I'd let you know about it.

  Are you sure? yes | no

Arsenijs wrote 04/15/2017 at 22:10 point

May I interest you in a survey? =D

I'm following their campaign, it seems they're close to having the computer cards manufactured (IIRC last time I got an email update, they were smuggling PCBs and components across the border =D ). Once I'll get through this whole manufacturing thing, and will have enough software (by the end of this year, at least), I'll be looking at making a touchscreen ZeroPhone, or perhaps a tablet, and this is where EOMA68 will be one of my likely picks =) Thank you for the tip!

  Are you sure? yes | no

Louis Pearson wrote 04/16/2017 at 05:47 point

You're welcome! =) 

I posted this project on the mailing list and the possibility of using an EOMA68 for something like this and lkcl (the creator) seems to like the idea of making a phone using a computer card. He did point out that the EOMA68 might be a little to big to be practical, and actually wants to make a smaller version called EOMA54 for something like that. Here's a link to the concept he has for it:

Looking forward to the crowd supply campaign - I'll try my hardest to support you on there. Looking forward to trying my hand at developing software for the ZeroPhone.

  Are you sure? yes | no

Arsenijs wrote 05/24/2017 at 03:25 point

If you're interested in ZeroPhone software development and you have some ideas in mind, you can play with the UI emulator already:

  Are you sure? yes | no

Louis Pearson wrote 05/25/2017 at 04:22 point

Sweet! I'll check that out. Actually, I have a raspberry pi 3 and a oled screen available, so I might try using that for testing. Keep up the good work! :)

  Are you sure? yes | no

kunstenaar wrote 04/05/2017 at 06:57 point

Update pls... :)

  Are you sure? yes | no

Arsenijs wrote 04/11/2017 at 21:39 point

Done -! Sorry, had to freelance a bit =)

  Are you sure? yes | no

Arsenijs wrote 04/30/2017 at 18:37 point

Hi! About your links on power saving - thank you! I've already read through all of them by now, and my power saving plans include assembling a ZeroPhone, cutting its power traces that lead to different components and inserting voltage&current measurement sensors in between, then experimenting with various clock rates, peripheral power saving modes and other software tweaks. I really want to discover new things about Raspberry Pi power saving, since, well, all those available solutions can get you up to some point, but no further, and I don't want to blindly turn features off without actually knowing what causes what level of power consumption and how exactly things could be tweaked for maximum power saving/usability ratio.

EDIT: and no, I didn't yet have the time to measure Zero W power consumption, but that's mainly because I don't expect many surprises, and for now I'm concentrating on other things - but I'll get to it sooner or later =)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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