close-circle
Close

Explaining choices behind the project

A project log for ZeroPhone - a Raspberry Pi smartphone

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

Arsenijs 01/14/2017 at 01:006 Comments

Why develop something new when there are dumbphones and rootable smartphones available?

Three main factors are accessibility, innovation and openness of both hardware and software. It's that much easier to tinker with mobile phones and write all kinds of apps when you have a phone that's as modifiable as possible and is cheap. Besides, I have problems with the OS that seems obvious for open-source - Android (explained below).

For me, this project is a huge undertaking that, if done right, will influence the way we perceive mobile phones, help us in solving the privacy and security concerns we're currently facing, as well as allow us to develop better open-source GSM technology and power our mobile phone hacks. I believe this can change the world for the better - by enabling people to experiment with things that have become inseparable from us but are so far away from being open to experiments.

Besides, this is an open-source Linux-powered phone you can independently assemble for <50$ - that's pretty cool and alone deserves being brought to life!


But Raspberry Pi isn't fully open-source! Neither hardware schematics nor Gerbers for Pi Zero are available, and there are binary blobs that are necessary for the Pi to work! And we can't be sure that SIM800/ATMega doesn't have any backdoors!

No doubts, Raspberry Pi isn't fully open-sourced and open-hardware (though we might get there sooner or later, there are no guarantees). However, if you examine current single-board computers that can be bought for a reasonable price, Raspberry Pi has superior community support, price, availability, power consumption and, last but not least, hardware that's actually supported instead of simply being there with no software to back it up.

Moreover, the component choices were made to ensure the project has as much chances to succeed as possible. Want to hear more of the reasoning behind this? It's going to be explained in one more article soon.


I see a small display and a keypad. Where's my big touchscreen display?

Price, simplicity and ease of development. Touchscreen-enabled displays are pricier, take more GPIO (sometimes requiring too much pins or reserving some that would be typically required by other hardware present) and will consume more energy (the battery life is a concern worth working on already). Moreover, there are numerous lessons that we can learn from the existing keypad-enabled phones we've had.

Furthermore, developing an efficient UI for larger displays while keeping up with the demands of users can quickly become much harder than anticipated - for example, once this phone will have a big display, there'll be many users wanting to use native Linux apps, and most of them aren't optimised for touchscreen usage. While I'm not that concerned about any patents this might infringe on, the fact that most the patents for keypad phones are likely to have expired by now can help avoid patent trolls' attacks, which is unlikely to happen, but sure is a nice thing to be calm about.

I'll also remind you that it's possible to simply keep the Pi Zero and the back panel with modem and develop a touchscreen display front panel - this is open-source hardware! In the end, it will just be simpler for the project to start this way.



What about Android? There are fully open-sourced forks of it, many oriented on security features and many - on customizability!

That is true, however, let's start with the fact that porting Android to Pi Zero wasn't successful, even though there seemed to be some movement behind it. This alone makes this project much more difficult for me to tackle - especially given that Android seems to have mostly dropped support for ARM processors as old as a Zero has onboard.

Also, Android is a big complicated system. I want to make development easy even for those coming from a non-Java background. In the end product, I'm going to use lots of Python with C in places where performance matters. That means discarding the app ecosystem of Android, which is a bold move, but a necessary one - let's see why.

My main concern is that most apps, however simple they could be, aren't open-source - this is simply not something developers are used to in the Android world. You put the app out there, support it some, possibly, make money on the ads and/or sales - there's hardly ever an incentive to open-source an Android app, unless as a gesture of kindness from the developer. Theoretically, there's nothing wrong with that - however, there's a corellation between this and a huge market of apps that are bloated, collect too much private data or don't really work well (or all three simultaneously, such as infamous Facebook app). Add this to the fact that a keypad&small display phone can't make use of most of the apps touchscreens are for

After all, Android doesn't have any apps for the types of displays we're using - and by the time this project grows to be big enough to have a good touchscreen UI, there is even a possibility of having an Android emulation layer in Linux, which will be a nice addition that, unfortunately, isn't yet feasible. As for now - I'm sure we should get Snake on this! (if you're ready to help, PM me and I might just have a prototype board for you).


Hey, Python is slow!

Not slow (I have a UI project fully in Python that's very responsive) - and certainly not in the places it's going to be used for. It makes sense to use lower-level languages in segments of code which are visited very frequently or take a long time to be executed. Most of the code that runs a phone like this will be neither, and the readability benefit we get is an enormous contribution to making this project accessible for others to tinker with and build upon it. Let's also not forget the fact that Python is language of choice for most Raspberry Pi users using it for programming!

Simply put, it's much easier for a beginner to achieve his goals using a Python-powered phone as a base than it could be with C - and since this project is meant to be modified and improved upon, Python is the best choice you could make.

Also, since the architecture of UI framework won't be monolythic, it will be possible to port the app-facing side of UI framework to many different languages, enabling you to develop for this phone using your language of choice!

Discussions

Lars R. wrote 07/31/2017 at 10:39 point

What do you think about Orange Pi Zero Plus2 (includes WIFI, BT, connectors for mic/earphone)?

  Are you sure? yes | no

Arsenijs wrote 08/03/2017 at 06:03 point

I've looked at it IIRC, but, as now I've got enough things to concentrate on, I don't think I have the time to evaluate it - and I also have this stereotype of boards like these having bad software support, I know that chances are, this  board is no different =(

  Are you sure? yes | no

Lars R. wrote 07/31/2017 at 10:19 point

Regarding display:

Power consumption: A large touch display can typically be switched off. It only needs to be active during usage. A single button could activate the display. An LED can indicated messages and missed calls.

Price: A 320x480 touch display is approx. $10

Usability: The idea is indeed to run and show a desktop and to enable google map, gestures and other stuff (maybe even recognition of handwriting ;) .

Required IOs: Such a display runs SPI

Regarding PI Zero:

If you only have a small display and a very limited UI, why use a PI Zero in the first place? ESP8266 or ESP32 would be well suited for the job, even with Python.

  Are you sure? yes | no

Arsenijs wrote 08/03/2017 at 06:14 point

Yep, a large display can be switched off - but so is my small display =) Unfortunately, those larger display aren't as popular, and don't seem to be as standartized - I kind of want to be able to rely on the display being present on the market after a year, and those small OLEDs seem to be popular enough so far - the larger displays, however, seem to come and go.

In terms of usability, both small and large display require custom-tailored apps - it's just that larger display has more possibilities, indeed, but I'm not sure it'll actually get the amount of developers to actually get the apps that need the screen real estate, at least, not this year - that's why I'm postponing work on large screen ZeroPhone =)

IO: the larger the display, the slower is the refresh rate, so even though the displays run SPI, redraws will need more time and the UI will look more sluggish =(

Having the Pi Zero is about the power of Linux, at the moment =) While MicroPython is powerful, it's nowhere as good as allowing me to run Linux apps, for example, right now I have my default setup - tmux, mocp in one pane, playing music from the 20GB mp3 collection on the SD card), irssi in another pane, and I can also open nano and code the ZeroPhone UI code - on the ZeroPhone itself! So, while a ESP8266/ESP32 setup would work, in a way, it wouldn't give as much possibilities as I'm getting now.

  Are you sure? yes | no

Lars R. wrote 08/04/2017 at 14:09 point

A touch screen enables

. Running Linux applications natively

. Developing apps in QT

. Using the phone as a low-cost Linux tablet

A couple of frames per second should be sufficient.

  Are you sure? yes | no

Arsenijs wrote 08/15/2017 at 08:58 point

Running Linux applications - yes, indeed (talking about graphical applications, CLI applications run without any problems)- but not all of them are touch-optimised

Apps in QT - yes, agree. As about the Linux tablet, there are already projects that do this, and even though they're mostly one-offs (unlike my project), I'd rather finish this one first - then it will make sense to switch to something that will be able to work as a tablet =)

I wouldn't say that "couple of frames is sufficient" - there will be expectations, and people won't be happy about UIs being sluggish, and video playback being nonexistent, and video support is important..

BTW, check out NoodlePi! =)

  Are you sure? yes | no