Close
0%
0%

ZeroPhone - a Raspberry Pi smartphone

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

Public Chat
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 editions:


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

Features:

  • 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:

Licensing:

#pyLCI fork used for ZeroPhone is licensed under Apache License

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


Original project...

Read more »

ZeroPhone-PCBs-gamma.zip

Latest PCB revision

Zip Archive - 12.32 MB - 10/21/2017 at 14:00

Download

  • 1 × This list is provided for the reference, for sourcing see https://wiki.zerophone.org/index.php/Sourcing_ZeroPhone_parts
  • 5 × Transistors and FETs 2x BC847B, 3x IRLML6401
  • 2 × Diodes 1x 1N4148, 1x SS14
  • 1 × ATMega328P TQFP-32 package, harvestable from an Arduino Pro Mini
  • 1 × 16MHz crystal for ATMega HC-49 or CSTCE, harvestable from an Arduino Pro Mini

View all 27 components

  • 3D design files now available!

    Arsenijs12/30/2018 at 00:10 7 comments

    Hi! So, about the ZeroPhone cases.

    This is one of the most popular questions, on par with the "3G connectivity", "flat battery" and "touchscreen" ones. I'm not the kind of person that'd be good at 3D design, but, thankfully, plenty of people in this community are. During these 2 years, I had a task of making the 3D model of ZeroPhone PCBs - so that people could make a case around it. I kept putting it off, and when I did have time to work on it, it wasn't successful - one of the most important things delaying me was waiting for KiCad 5, with proper STEP support (since VRML support in CAD packages universally sucks, as I've come to understand).

    Finally, we have a 3D model of the ZeroPhone, specifically, the Delta revision:

    It's taken a lot of work - thankfully, early in the project's beginning phase, @Dillon has helped with a lot of 3D models, designing some from scratch and sourcing others from open sources, so I'm immensely thankful for that. Current 3D model also has a lot of Grabcad material - distribution rights of which is questionable, I admit, so here's a list of all the stuff we need to replace. You can download the STEP here, and the STL here.

    Meanwhile. if you want some kind of reference design, here's a downloadable case design for ZeroPhone Gamma by @Ninjalicious  - albeit bulky, it's a viable way to make a case that actually works and holds up, one that's also snap-fit but provides all the vital openings for ZeroPhone hardware. Personally, I'm interested in some kind of lasercut design, but not for the practicality of it - I just like lasercut things =) Before the crowdfunding, if nobody steps up and designs an open-source case, I'll design one myself - to make sure we have something to offer during the crowdfunding.

    Also, I've had multiple suggestions from people, about making a ZP version in a case for a bulky phone, like the Motorola DynaTAC or this one. I can't say I'd be interested in such a case, but if I were to add, say, a FreeCalypso modem board (a 90x50mm PCB), this is exactly what I'd be looking for! With all the ways that you can expand on your ZeroPhone, I'm sure there's a lot of interesting stuff you could ram into such a phone - i.e. an expanded battery pack or a bigger screen, or maybe a Geiger counter and a high-power WiFi antenna... Why not all of that? =D


    Any information that's provided in this article may and will become outdated. Refer to the ZeroPhone Wiki page on 3D designs for the most up-to-date information.

  • Why is self-assembly important, and why use Chinese breakouts?

    Arsenijs12/05/2018 at 16:26 1 comment

    I've been asked these questions a lot. Mostly by people who were wondering why I need to battle with and work around problems of Chinese breakouts instead of laying out all the bits and pieces on the breakout board, and why I just wouldn't put the 2G modem/charger/DC-DC on the back board, with all the benefits it would bring. There are multiple facets to these two questions - they're closely related, and I'll be answering both of them at the same time.

    Typical starting point for self-assembly on more complicated OSHW projects

    First and foremost, what does self-assembly-capability even mean for ZeroPhone? At the moment, you can assemble your own ZeroPhone independently - without any help from me, without buying parts from me or even contacting me in any way. I do provide advice in case something's unclear or there's a problem, I do sell parts, and I do link people that would like to sell some parts (i.e. PCBs) with people that would like to buy parts - but it's all optional, I publish info on assembly, there's more and more tutorials, guidelines, and videos as time goes on. This isn't really something that a lot of projects do, it requires additional effort and insight, but it's doable.

    Read more »

  • Delta-B released!

    Arsenijs10/26/2018 at 23:59 0 comments

    Hi! Here's a long overdue worklog about a new revision that was released two months ago =D It's called Delta-B, the only changes from Delta are bugfixes; this time that's actually true - not like Gamma=>Delta which was planned to be like a bugfix-only revision, but had to get lots of additions.

    Read more »

  • New app - avrdude

    Arsenijs07/01/2018 at 22:20 0 comments

    This month, I've been working on an avrdude app - an app that uses avrdude to program AVR microcontrollers. It's now finished, with 500 LOC in the app itself and 800 more in the associated libraries. You might be surprised - why this and not something else, like a messenger app? Here are the reasons:

    • At the time, I had a small gig that involved programming 50 ATMega-based boards. So, after working with avrdude for quite a while, I was quite sick of it and wanted to automate it away - and also wanted to make sure there's a straightforward way to burn popular bootloaders to ATMega-based boards, which is a big part of this app. Now, I don't need to be summoned anywhere to program a new batch of boards - I can just give that person a ZPUI-enabled device with a user-friendly interface.
    • ZPUI needed a helper class to run long-term processes and parse their output - which is something that avrdude app would need, so after I wrote it, it only made sense to write an app around it. Such a class will be necessary for anybody who would want to write a wrapper to run any command-line tool and see what it outputs in real-time - be it ffmpeg or mjpg-streamer (which I plan to add for single-click video streaming), an interactive CLI script that needs your password, another microcontroller flasher or just a long-winded script that you want to monitor, there's now a way to wrap it in a developer-friendly object you can use to get output, send output and terminate the process at a whim (surprisingly, something that I still haven't found a proper Python library for).
    • I wanted to understand whether there's something that ZPUI lacks - it's something you can only see while you're programming a large app like this, and given that I'm the only person working on ZPUI and controlling its direction, it's crucial for me to check every once in a while if there's something that could be added to ZPUI. As a result of this work, I've added a lot of new functions, and more different ways to use the existing ones.
    • Also, I wanted to test out the recent ZPUI additions - like context switching, canvas system and class-based apps, and write a large app that uses all these things in a way that others can then refer to. While I was writing this app, I uncovered plenty of bugs and inconsistencies, which were promptly fixed.
    • Last but not least, writing large apps gives me the experience I can use to advise others on writing large apps - for now, nobody but me has this kind of experience, which is necessary to help people writing large apps that actually work.

    The end result is an Atmel MCU programming app that can backup and restore firmware from/to the MCU, flash arbitrary .hex files and bootloaders. For now, I've only tested it with usbasp programmers, but linux SPI device and other programmer support will be coming soon. I've used it a lot already, and it's even more useful given that I'm now working on several AVR-powered ZeroPhone mod boards (so, a simple way for users to update the mod board firmware is needed). It also has pinout information and the most crucial settings available, as well as some user-friendliness related features. In addition to that, there's a lot of bugfixes, improvements, new ideas for improving ZPUI and insights into problems that ZPUI has.

    One large problem that I now understand ZPUI has - lack of some kind of markup system for UI design. Essentially, when you're trying to draw your own UI, you need to calculate position of each element on the screen, requiring plenty of math (and extra variables) if you don't want parts of your UI to overlap/disappear. When it comes to text, the situation is even worse - as of now, it's pretty much impossible to properly word-wrap arbitrary text on a screen, for example. What do we do about it? I have no idea yet, and that's something I'll need to address sooner or later, unless I want ZeroPhone to be infamous for ugly apps... or not scaling further than the small display...

    Read more »

  • Delta boards released!

    Arsenijs05/24/2018 at 00:40 2 comments

    The new revision, ZeroPhone Delta, is out. I've been using a Gamma ZeroPhone for quite some time now, and it needs some bugfixes. Specifically, I:

    • Fixed a mechanical weak spot where a row on the keypad would break due to lack of structural support
    • Fixed tantalum capacitor footprints - now they're more solderable
    • Fxed the problem where traces on the 18650 board would get exposed to the back board (and short things together) due to soldermask scraping off the back board when scratched by the back board through-hole pins
    • Flipped the 3G modem upside down, making the routing significantly easier
    • Reorganized the SPI (side) expansion header footprint, changing it to use 12-pin headers (easier to source)
    • Reorganized the I2C expansion header to be compatible with the Raspberry Pi I2C pinout, allowing to connect existing I2C RPi expansion boards to ZeroPhone
    • Reorganized the IR (top) expansion header - now it's safe to plug expansion boards in reverse
    • Audio buffer, vibromotor and keypad backlight circuits are now powered from VSYS
    • Flipped the DC-DC power FET so it's no longer necessary to solder it flipped
    • Flipped the charger board - now it's easier to solder it, as well as swap and test
    • Made the Pi Zero pads on the back board oval - making them stronger (for rework purposes)
    • Changed the 4-pin GSM audio header into a 6-pin one - for easier sourcing
    • Improved the microphone footprint on the front board
    • Made fiducials smaller - mostly I needed more space for routing
    • Improved the switchable display header - the jumper pads are now smaller, and through-hole part of it is covered by soldermask on the front of the board (to avoid displays shorting to it)
    • Made the surface-mount crystal resonator pads on the front board larger, in attempt to make the resonator hand-solderable
    • Added traces to the MCP23017 footprint in an attempt to make it more reworkable

    Here's what I added:

    • Inductors in series with GSM microphone traces - for noise filtering
    • Assembly instructions/guidelines on front, back and keypad boards
    • Usage instructions on the 18650 board
    • Expansion header pinouts on the back board
    • A comparator - detecting charger&USB undervoltage and charger board overheating
    • A circuit that'd allow sensing whether the "power switch override" button is pressed while still eping the phone switched on
    • An UART buffer - not connecting the GSM UART to the Pi UART until a GPIO is asserted
    • UART testpoints near the charger board outline - to allow for a charging+UART board to be made
    • Serial number fields on front, back and keypad boards
    • An audio amplifier for the GSM speaker (unfortunately, it's a TI part - I'll be looking for a substitute)
    • An I2C EEPROM to GPIO0 and GPIO1 to the back board - to make the back board work as a Pi HAT in software
    • Better power filtering for the GSM modem power
    • A "connect 5V DC-DC to the charger input when the DC-DC is powered off" circuit
    • 3.5mm jack audio filtering to remove GSM noise
    • ATMega UART header reverse polarity protection
    • A fuse to the 18650 board between two batteries, to avoid problems when people insert batteries in reverse, or batteries with different levels of charge
    • Finally designed the first solution to attach the GSM speaker

    I also removed a lot of things that didn't prove themselves useful:

    • The RTC footprint - proved to be unnecessary and incomplete, and was taking a lot of PCB real estate
    • The GND-BATT- jumper - wasn't useful
    • The capacitor footprint in parallel with BATT+ and BATT- - wasn't useful
    • The MPU9050-compatible footprint - wasn't useful enough compared to the PCB real estate
    • The second USB socket (facing the board center) - wasn't useful
    • The RST and TV-OUT pad connections - weren't useful (though having a way to bring them back later would be cool, maybe add a pad for a surface-mount pin header?)

    OSHPark links: 18650 board, back board, front board, keypad board and speaker adapter


    Some of these points (like silkscreen additions) could be explained further, but I'll show them off once I receive the...

    Read more »

  • Some ZeroPhone problems I'll be fixing

    Arsenijs02/15/2018 at 09:26 7 comments

    Even though I've put a lot of work optimising ZeroPhone for everyday usage, self-assembly and manufacturing, there still are things we can do better in the next revision. Let's go through them, so that you can see the final changes I need to make to the boards, and things I need to figure out before the crowdfunding!

    This list is a result of me carrying a ZeroPhone with me through this year - and, therefore, fixing these problems will make sure your ZeroPhone lives as long as possible and is not merely some kind of gimmick that dies after a couple of months. Most of these problems are either fixable or have workarounds - if they didn't, I wouldn't have had been able to assemble the Gamma PCBs. However, they will be problematic for new people, so I have to make sure to eliminate as much of those problems as possible for the next version - to properly achieve the ZeroPhone "self-assembly" goal, making the assembly "as easy as possible" and not just "possible".

    Charging and protection boards


    We use popular modules from China for the ZeroPhone battery charging and protection. I had problems with the way those modules had to be soldered on the back board - it wasn't straightforward, and it wasn't easy to get done. So, I've flipped the footprint - now it's compatible with more module types, and it's much easier to solder the modules on - the board layout also became much more straightforward, since power traces used to be crossed and now they aren't! The component side of the modules is now exposed to the outside of the phone, though - I'll have to make sure this doesn't cause problems, such as short-circuits (possibly, release a 3D-printable cover).

    In addition, there were stability problems with a new version of these modules. Beta boards were using an earlier version:


    For Gamma boards, however, I used slightly different modules, a newer version  - I ordered them by mistake, so I quickly changed the footprint to fit the new modules in order to avoid ordering the older ones. 

    That turned out to be a bad idea - the newer modules seem to not function as well as the previous, some of them randomly fail (luckily, they fail safe). It happened to some of my ZeroPhones, and it also happened to some of the ZeroPhones that I sent out (which resulted in the person having to send it back, for me to repair, and that's something I'd really like to avoid). That's not acceptable - if the module is broken, ZeroPhone cannot operate from the battery at all - or it switches off randomly, which is even more annoying. Fortunately, the new, flipped footprint allows for all kinds of modules, so it should be easier to find a suitable board now!

    During the manufacturing, we'll need to find a way to either find a reliable source for these modules, or to manufacture our own (I've already reverse-engineered the schematics and the PCB, thankfully, and I'm asking for manufacturing quotes) - as a backup plan in case the commercial modules are no longer suitable for us. I've also tried understanding the problem by comparing "old" and "new" modules - I've checked the schematic and it's the same (the boards are slightly different, but the changes are minimal), so my guess is that the "new" modules are using cheaper components, which causes the failures. But, just in case, I'm going to see if there's a way for us to source these boards reliably.

    Reworkability


    It turned out that current ZeroPhone PCBs might have some problems while doing repairs - traces breaking, pads being lifted etc. Generally, it will only happen to low-quality PCBs - but it's hard to make sure the PCBs you're ordering are of sufficiently high quality (and if you're ordering from a place like DirtyPCBs, it's likely your PCBs won't be good enough to survive overheating). This is bad, since it makes ZeroPhone less repairable - in the end, I have two back boards and one front board that are unusable because too many pads got lifted, and I also have some more that need...

    Read more »

  • ZeroPhone block diagram

    Arsenijs12/25/2017 at 11:17 2 comments

    Merry Christmas everybody! I'm going through the ZeroPhone project files, and here's something that I haven't yet posted - by @Morning.Star:

  • Writing a 2048 game for a ZeroPhone

    Arsenijs12/10/2017 at 04:21 1 comment

    Today, I was watching my wife play 2048, and I remembered about all the fun I had with this game myself, back when it was popular. While I don't recall ever getting past 512, I did spend a lot of time and I liked it. So, ZeroPhone can fit 8 lines of text on the screen, and 2048 needs a 4x4 playing field - seems like a perfect match!

    I found some Python code on GitHub that seems to be a great fit - it's cleanly split into logic and GUI parts, and logic does not depend on the GUI in any way, so can be re-used easily. Now that's a great design, if you ask me =) Reading further into it, it seems to be somebody's programming assignment, and I have to say that it was very helpful of that person to put it on GitHub!

    So, let's reuse the logic part, and build our own UI for the game!

    Read more »

  • ZeroPhone uses: streaming audio from desktop to headphones

    Arsenijs11/13/2017 at 06:43 0 comments

    Do you ever feel tethered to your computer because you're wearing headphones, and you can't go away from it because you can't use your speakers for whatever reason? This is for you.

    I often found myself in this situation. Sometimes I'm listening to podcasts, and I want to get up from my desk and grab something from other room, but the speakers aren't loud enough. Sometimes people around are sleeping and I don't want to wake them up, but I also can't carry my laptop with me just because I like the track I just found on YouTube. 

    One of ZeroPhone plans is enabling hands-free applications, using audio for things like notifications (of course, only the most important ones, and the ones you want to hear.) Naturally, I'll be using it a lot  - I'm the "headphones" kind of person, and I know there are plenty of ZeroPhone notifications I'll want to hear about immediately when they happen. Now, what if I want to listen to a podcast, should I unplug headphones from my ZeroPhone and not hear the notifications? The most obvious idea is using the ZeroPhone as an audio receiver, and stream audio from my laptop to ZeroPhone, so that notifications could be overlayed, and I wouldn't find myself re-plugging the headphones all the time.

    So, the setup is like this: I want to stream all audio from my Windows laptop to my ZeroPhone, which sits in my pocket, receives the audio stream and plays it back to my headphones. If my laptop ran Linux, I could just use pulseaudio network streaming capabilities and be done with it. As it's Windows, though, I needed to find something that would work on Windows and would be more user-friendly than using a long command-line copy-pasted from Stackoverflow.

    Read more »

  • An in-depth explanation of a simple GPIO app

    Arsenijs11/08/2017 at 04:09 0 comments

    For Hackaday Prize video, I made some simple ZPUI apps (some of them were mockups, though). One of them was reading an external flame sensor and displaying pictures on the screen depending on whether the sensor detected flame or not. I had to do this in a rush, and I ended up adding some basic, but very useful, functions to ZPUI (though I did have to clean them up quite a bit before I could merge them into official ZPUI version =) ). 

    What's the algorithm of this app?

    Set up the GPIO
    In a loop, read from the GPIO pin
    If pin has logic low on it:
        display picture of fire
    Else:
        display picture of fire crossed out

    The app is, therefore, very short. So, let's go through it thoroughly, explaining it in as much detail as possible!

    Read more »

View all 50 project logs

  • 1
    Step 1

    Instructions are under construction

    Sorry for any inconvenience =) It takes time to make them as good as I want them to be.

  • 2
    Source the PCBs

    You can use OSHPark, DirtyPCBs, Elecrow or some other PCB manufacturing service to order PCBs. Grab the latest release from GitHub, order the PCBs and wait for them to arrive! More detailed instructions are available here

  • 3
    Source the components

    The full list of components (with links to places where to source them) is still being compiled here. Meanwhile, you can use this Google doc as a reference - I'm also making my calculations for larger-scale manufacturing runs of ZeroPhones there.

View all 10 instructions

Enjoy this project?

Share

Discussions

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 - https://hackaday.io/project/19035/log/57132! 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

Ember Leona wrote 03/31/2017 at 22:54 point

WOW.

  Are you sure? yes | no

alasdair wrote 03/21/2017 at 14:24 point

Really looking forward to your CrowdSupply campaign and the success of this.

Have you had a thought about a permissions system (if required), lets face it the permission system on *droid is bollocks?

Also are there (respected) hardware crypto modules (that are affordable) which could be incorporated - obviously not at the $50 mark you are aiming for?

  Are you sure? yes | no

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

What's wrong with the permission system on Android? I recall two problems - granularity (seems to be improved recently) and the fact that you couldn't just deny the app some of the permissions is asked for (IIRC got fixed in 5.0 and later). I'm not much of an Android guy, so would be interesting to hear your take on this =)

  Are you sure? yes | no

alasdair wrote 04/11/2017 at 23:21 point

You pretty much hit the nail on the head there however I still noticed issues on 5.0+ (not sure about latest) in that a) not all permissions asked for in the app were toggleable b) some were there that hadnt been asked for. There still seemed to be issues with granularity and inconsistencies with what ws requested upon installation and what you were able to selectively permission once installed (assuming the app had not already abused any of those permissions between installation and toggling). I hope that makes sense. Sorry to hear you needed to take on another project I am sure you will be swamped when you launch the crowdfunding for this.

  Are you sure? yes | no

adam.klotblixt wrote 03/08/2017 at 16:40 point

A very nice project, looking forward to see the future updates.

One feature I look forward to is WIFI-hotspot, so that this phone could be the ONLY data access point, and all my other commercial pads and smartphones talk through it, with the possibility to REALLY be sure what data comes through. A true portable router of sorts. 3G or better is of course nicer and surely in the path.

Please, make sure the phone audio can be recorded properly, ideally into separated stereo (left: caller, right:callee). Many smartphones are really bad at sound-mixing and audio-paths.

And I also see a great potential to be able to use ANY size battery for this phone! Imagine having a phone that has the potential to dock several size batteries. Mmm...

  Are you sure? yes | no

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

Will keep the audio advice in mind. As of now, GSM audio and Pi Zero are not interconnected, but I'm already adding a way to connect an add-on board to output/input audio data to GSM modem. With the setup that I'm thinking about, recording audio into any combination of channels would be a matter of software.

We'll get to having WiFi hotspot app sooner or later =) Also, I've already experimented with batteries - as long as it's 1s and Li-Ion (the usual kind of chemistry), you should be able to just power it from that without any modifications or addons. I've used a 450mAh battery for a while, then got tired with low battery life (there are no significant optimizations for battery power in ZeroPhone software yet) and upgraded it to 2x18650 in parallel - I figure it now has about 4000mAh of battery, and it does get me through a day of listening to music non-stop =)

  Are you sure? yes | no

Arsenijs wrote 02/28/2017 at 17:30 point

I ordered two of those, expect my review in a week or two =)

  Are you sure? yes | no

Craig Hissett wrote 02/15/2017 at 13:17 point

Received my kit buddy - thank you so much!

As soon as my screen arrives I'll get this bad boy assembled and start having some fun!

:-)

  Are you sure? yes | no

Arsenijs wrote 02/15/2017 at 13:20 point

Nice! Thank you for notifying, I will get to preparing the SD card images tomorrow =)

You can actually assemble everything without the display - if you have some free time, the display can easily be soldered last.

  Are you sure? yes | no

Craig Hissett wrote 02/15/2017 at 13:33 point

Awesome sauce! Thanks mate!

  Are you sure? yes | no

kunstenaar wrote 02/15/2017 at 12:24 point

Just fyi:

https://blog.rosenzweig.io/blobless-linux-on-the-pi.html

Sounds we getting closer to 'bloblessness'... Have a good read. ;)

  Are you sure? yes | no

Arsenijs wrote 02/15/2017 at 15:45 point

It was a very educational read, indeed! Wondering if it'll ever get usable - maybe, with all the interest to both this and the ZeroPhone project, it will =)

  Are you sure? yes | no

Samurai wrote 02/13/2017 at 16:38 point

How long did it take for you to build this marvelous nerdy great thing?
I wonder if I wonna do the same...

  Are you sure? yes | no

Arsenijs wrote 02/14/2017 at 12:15 point

About two months of work since I've started it, and many more to come =) As for the "assembling it from the kit" - shouldn't take more than an evening of drinking beer&soldering.

  Are you sure? yes | no

kamathln wrote 02/13/2017 at 05:15 point

HI, 

I feel a couple of jog dials would be an awesome usabiity enhancement. Adjusting volumes, scrolling though menus, file lists etc., will be a breeze.

  Are you sure? yes | no

Arsenijs wrote 02/13/2017 at 09:58 point

Hi! I had a very early Sony-Ericsson phone with a side jog dial, it was awesome =) I won't be including that in the mass-produced version (they're hard to source), but it can be a keypad PCB mod (I've added 5 pins to the keypad PCB that have I2C, so would be very easy to implement jog dial readouts with a small MCU). Thank you for the idea!

  Are you sure? yes | no

Hacker404 wrote 02/13/2017 at 00:00 point

Hi, it's RÖB, you mentioned the new 4G/LTE modules on a HAD article. Thanks for the heads up. 

When I started my M2M / IoT project I just ordered some 2G modules from China as I didn't know 2G was being phased out here. 

I see you have used a SIM800, I have one in transit and I also have a SIM900 in a COMSAT 1.1 Arduino shield. 

These are three band. I know it's a long shot but is it at all possible to get these to use a 3G band for HTTP traffic. I wonder if they can be re-flashed, if someone has written the code.

  Are you sure? yes | no

Arsenijs wrote 02/13/2017 at 09:54 point

Hi! Nice to hear from you, was seeing your comments on the blog from time to time, didn't know you also had an .io page =)

So, 2G has disappeared in Australia? Or is it just some carriers and other will follow soon?

You think it'd be possible to make a 2G module firmware that'd make it work on 3G? I don't understand enough of 2G/3G/those modules' capabilities, but I do know that Simcom isn't helpful about SDKs (read: you're not getting any). To be fair, I don't have any first-hand experience with this and have only heard about it from my colleagues, but if that's true, making any kind of GSM module firmware fixes is going to be tricky for sure.

  Are you sure? yes | no

Hacker404 wrote 02/13/2017 at 10:23 point

We basically have three mobile carries here. One killed 2G on the first of January and from memory the other two will be killing 2G by mid year. 

From what I understand from the application notes for SIMCom modules, they have an embedded micro-controller that you run LUA code on. I assume the same micro handles the protocols and could (possibly) use the 3G band if it had the right code unless there was some hardware limitation that I am not aware of. I don't have enough data or the ability to reverse engineer the modules like the SIM900 or SIM800 to do this though. 

Obviously it's better for the company to sell new modules anyway so they wont be releasing a firmware update. 

Anyway - love this project and it good that there is so much interest. 

Some link about Australian mobiles - 

https://www.whistleout.com.au/MobilePhones/Guides/Will-my-phone-work-in-Australia-carrier-network-frequencies

http://whirlpool.net.au/wiki/Mobile_Phone_Frequencies

  Are you sure? yes | no

Samurai wrote 02/12/2017 at 11:15 point

A new cool thing!
Its freacking!
Does it have the potentiallity to be mass producted?

  Are you sure? yes | no

Arsenijs wrote 02/13/2017 at 09:59 point

Hi! Yes, I plan to crowdfund some mass-production, follow the updates, I'll tell more about it in a month =)

  Are you sure? yes | no

Samurai wrote 02/13/2017 at 16:35 point

Happy to hear that!
Sure! I follow the project eagerly. ^__^
I want to do smth like you did but with a little difference.
I wish you the best,my friend...

  Are you sure? yes | no

Reinhardt wrote 02/11/2017 at 10:44 point

Wow, that's great!

  Are you sure? yes | no

Krokofant wrote 01/27/2017 at 14:23 point

I've been pointed to this by the Linux Action Show podcast and I am really excited by the project.

I think I am not able to contribute at this stage, but I hope to get my hands on a revision 1.0 kit  when it's ready. 

If/when the base apps are materializing I would like to help with translation to german language if you can use that.

  Are you sure? yes | no

Arsenijs wrote 01/28/2017 at 00:52 point

Hi! I'm happy to hear you're willing to help (and Linux Action Show is awesome, I'm honored to see my project reviewed by these guys!). I'll ping you once I'll be making kits, and once more when I'll implement translation support in the phone's applications (basic apps will definitely materialize, it's just a question of "when" now, I'm laying the groundwork next week =) )

  Are you sure? yes | no

jackie wrote 01/27/2017 at 09:17 point

Could we possibly get a list of stuff that i set in stone and we can buy today if we want to build one later when everything is finished?

Thanks!

  Are you sure? yes | no

Arsenijs wrote 01/28/2017 at 00:12 point

Hi! This is my goal, I just need to make new PCBs and test them, then I absolutely can and will set stuff in stone =) I'll ping you when I'll have everything ready, would love to hear your feedback!

  Are you sure? yes | no

s.stevenson.1992 wrote 01/24/2017 at 23:41 point

Can you offer any advice for someone trying to make one out of salvaged parts? I have an old Alcatel gathering dust and it has the perfect form factor, comfortable keys and a tiny screen (which I am not entirely set on but I need to get it working first anyway).
I was hoping to build off your project and add the Zero4U USB hub and then get the case 3D printed locally from a modified version of the existing case.

  Are you sure? yes | no

Arsenijs wrote 01/26/2017 at 02:20 point

Hi! If you want to build off my project, check the GitHub repo - I'm going to soon release beta boards as soon as I release them, it'd be a great starting point (it is already). See the schematics, you can get insights into how it works, see what features you need and do not need and don't be shy to ask for advice =) The project is not even v1.0 yet, but there's already plenty to start from. As for more detailed advice, I'll go comment on your project now.

  Are you sure? yes | no

Ninjalicious wrote 01/18/2017 at 16:10 point

Love this project! Direly needed by hacker community, small cheap phones built on modular components!

  Are you sure? yes | no

Tisham Dhar wrote 01/17/2017 at 01:46 point

The ESP8266 sticking out on the side looks a bit odd. You may be better served in space by using the ESP8285 based module such as this: https://www.itead.cc/psf-a85.html which has a UFL connecter and can attach a big antenna for network scanning and such.

  Are you sure? yes | no

Arsenijs wrote 01/17/2017 at 02:36 point

It sticks out because I was designing it in a haste, it'll be fixed in the next revision. I see that ESP8285 does support SDIO but it's easier to source ESP8266-12E so I'll stick to that to make sure it's easy for anybody to assemble what I'm making =) After all, it's open-source so anybody can just mod a board, send them to a boardhouse and assemble their own phone. However, the base version has to be as accessible as possible - that includes using accessible ESPs instead of maybe more suitable ones. Anyway, hanks for the suggestion - I was wondering whether ESP8285 would support SDIO mode, and you made me check, it;s a good food for thought =)

  Are you sure? yes | no

Roy Dom wrote 01/16/2017 at 21:12 point

qwerty keyboard attachment maybe? 

  Are you sure? yes | no

Arsenijs wrote 01/17/2017 at 02:37 point

Yes, though I won't be focusing on that for now - working on a new board revision =)

  Are you sure? yes | no

Roy Dom wrote 01/17/2017 at 17:48 point

This would be amazing with ad hoc  on a small mesh network as a handheld messenger. free sms for a small team , like a next gen pager.

  Are you sure? yes | no

Arsenijs wrote 01/18/2017 at 15:09 point

Indeed - and it would be easy to make software for this! I'll think about an attachment like this, though I'll need to think about the ergonomics - the screen is small and not sideways. It's possible I'll make a Xbox ChatPad attachment - wrote Python drivers for it some time ago, should be easy enough =)

  Are you sure? yes | no

Arsenijs wrote 01/15/2017 at 11:11 point

@Drew DeVault Just so you know - the mounting and placement of components will change at least a couple of times even until I release a ready-working first revision, and I'm not 100% sure I won't need to make at least one fundamental change that could mess up a design. 

What I'm saying is - I absolutely can and want to send you a prototype, I appreciate the eagerness to help and the project would benefit from that massively. I'm just saying so you know to expect changes of requirements if you're to start at this point of development (and so other people interested know this). If you still want to start now, PM me here or email me (crimier at yandex ru) so we can work out the details.

  Are you sure? yes | no

Craig Hissett wrote 01/14/2017 at 09:01 point

I love this already. It's the perfect format for a portable, all-in-one pyLCI device - exactly what I'm after!

  Are you sure? yes | no

Arsenijs wrote 01/14/2017 at 09:19 point

I can send you partly-assembled prototype boards (you'll need your own display and Pi Zero) - if you're willing to cover the postage fees from Latvia =)

  Are you sure? yes | no

Craig Hissett wrote 01/14/2017 at 10:24 point

You absolute hero!

  Are you sure? yes | no

Drew DeVault wrote 01/14/2017 at 18:38 point

Can I get in on this? I'd be interested in starting designs for a 3D printable enclosure.

  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