[Tinkerphones] DIY "Smart"-Phone

[H. Nikolaus Schaller]

Hi Paul,

> Am 19.01.2017 um 13:38 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Thursday 19. January 2017 06.24.35 H. Nikolaus Schaller wrote:
>> Hi,
>> someone notified me about this project:
>> 
>> https://hackaday.io/project/19035-zerophone-a-raspberry-pi-smartphone/log/5
>> 1839-project-description-and-frequently-asked-questions
>> 
>> What do you think?
> 
> That people are perhaps too obsessed with Raspberry Pi devices, even though 
> claims are made about Pi Zero availability involving a site which presumably 
> pays out a jackpot if all three vendor stock indicators show "in stock". 
> Currently, only one shows "in stock".
> 
> The Pi Zero may be cheap and relatively powerful but there appears to be some 
> more work required to replace the proprietary "firmware" with Free Software, 
> with such work apparently being done by the community, not officially. It's 
> also a product that exists on a seemingly discretionary basis, but I guess 
> that finding another single-board computer and reworking everything else is 
> all part of the "fun".
> 
> (I also get infuriated when people just point others to eBay for sourcing of 
> random components from random vendors.)

Yes, that is too much tinkering. It is not reproducible for others.

> 
> As for the device itself, I think it's an interesting take on older, simpler 
> phone designs, reminding me of my Nokia 5110 which I did dismantle (and then 
> reassemble) last year in order to take some photos.

Indeed it is a simple "feature phone" from 15 years ago.

Two or three years ago I read about a chinese GSM feature phone for 12 USD incl.
battery, power supply and packaging. It did consist just of a SoC with GSM baseband
glued on the display. Like in cheap pocket calculators.

Of course such things are just cheap. And completely closed.

> The Pi Zero might not add 
> too much to the device thickness, presumably being the middle board in the 
> second device in the picture showing four different things, despite the 
> pictures showing the Pi Zero separately in a bulky enclosure for no really 
> good reason.
> 
> I don't really understand why the ATmega328P is needed when the SoC might have 
> a chance of doing the keypad scanning, but perhaps that is an easier option 
> than doing lower-level things in Raspbian.

Maybe there are not enough gpios for the keyboard matrix.

> I'd also be concerned about power 
> consumption, mostly around the SoC, and what kind of batteries one might end 
> up using.

I think they glue a power-bank on the side :) In other words: they did not (yet) care about.

> There's far too much usage of Li-Poly pouches for everything in the 
> electronics hobbyist world that is arguably storing up trouble for everybody 
> down the line.
> 
> But it's nice that the designer is trying to do everything in the open and to 
> emphasise Free Software. And I like the way that the physical aspects of the 
> device like the keypad design are freely available. Such things are often 
> overlooked in favour of the more exciting SoC-related elements of a design, 
> but here there is an opportunity for people like me to learn from these 
> things.

Yes, that is the reason why I brought it to our attention that we all can learn
from it. Innovation is sharing ideas and information and bringing together previously
unrelated topics.

> 
> Anyway, I shouldn't be one to criticise given that I'm not at this level when 
> it comes to designing hardware. But I do think that more sustainable choices 
> could be made with regard to the SoC solution. I see that the Pyra employs a 
> modular approach with its own CPU board that could be used with devices such 
> as this, and I guess that one of the EOMA family of products would be aimed at 
> something like this as well. It would be interesting to see such avenues 
> pursued.

Well, maybe someone builds a "Pyra Phone" around the Pyra CPU boards.

I personally still have to deliver the GTA4A5 which is more challenging than
the A3 an A4 (because there is much less support around and the unexpected
production issue).

BR,
Nikolaus