Pyra as full mobile phone replacement?

[levi]

It shouldn't require work from the Pyra team in the main to stay secure - most stuff that receives security notices is part of the debian distribution, so should just require a apt-get update and upgrade to patch at the user's end. Stuff like the recent libpng glitch could be baked into some dbps though, and might require the author of those to rerelease their thing (although that specific glitch probably doesn't require anyone to patch their version, since it only applies if you are able to modify the png file, not just display it)

 

[Kippykip]

I'd be happy to hold it awkwardly with lots of echo, compared to this old shitty flipphone I'm using at the moment.

 

[scippie]

I think this might be an important priority for the Pyra team, phone capabilities, because if they can definitively say 'phone capabilities' on the site then people might think of buying a Pyra over a new phone.

I don´t want to sound irritating or something like this, but I believe they made that kind of mistake with the Pandora too. They knew it had lots of potential but they never really worked out one of them so they could never sell it as "X replacement". The pandora does everything you want, but at the same time nothing because nobody really makes it that far, sometimes maybe even because of hardware limitations.

I am afraid that the same is happening to the Pyra. Lots of time and energy is put into building it towards perfection and one thing will again be forgotten: you can do lots with it, but it will never work as something they can really advertise it with. Inserting the components for 4G and connecting the pins so that it can get an interrupt when a call arrives is one thing, but ED (or someone in his team, or even me if he provides me with all the hardware) should really create a phone application that REALLY works so that hardware design flaws can be immediately removed.

Everybody in this topic is trying to tell me that the Pyra will not be handy as a phone, but I believe that for ME personally, it would be a great phone and if that's true for me, then it must be true for a lot of other people as well. And no, it won't run all the Android/IOS/WM apps out there, I don't care! And so don't a lot of people care about that.

For me, this will probably even make the difference between buying the thing and leaving this place forever as the Pandora is again rotting away on a shelf because it doesn't really provide me with enough features to actually use it.

 

[Silent-Hunter]

I don´t want to sound irritating or something like this, but I believe they made that kind of mistake with the Pandora too. They knew it had lots of potential but they never really worked out one of them so they could never sell it as "X replacement". The pandora does everything you want, but at the same time nothing because nobody really makes it that far, sometimes maybe even because of hardware limitations.

I am afraid that the same is happening to the Pyra. Lots of time and energy is put into building it towards perfection and one thing will again be forgotten: you can do lots with it, but it will never work as something they can really advertise it with. Inserting the components for 4G and connecting the pins so that it can get an interrupt when a call arrives is one thing, but ED (or someone in his team, or even me if he provides me with all the hardware) should really create a phone application that REALLY works so that hardware design flaws can be immediately removed.

Everybody in this topic is trying to tell me that the Pyra will not be handy as a phone, but I believe that for ME personally, it would be a great phone and if that's true for me, then it must be true for a lot of other people as well. And no, it won't run all the Android/IOS/WM apps out there, I don't care! And so don't a lot of people care about that.

For me, this will probably even make the difference between buying the thing and leaving this place forever as the Pandora is again rotting away on a shelf because it doesn't really provide me with enough features to actually use it.

Well there is working calling software for Linux, it just has to be ported. I have no doubt at all that that will happen!

 

[WizardStan]

should really create a phone application that REALLY works

There is software that really works, it's just not in any way user friendly. EvilDragon has said the hardware has been tested, calls have been made and answered via a serial terminal.
This is not the case of the DSP where the hardware existed and everyone was gung ho about using it but we literally could not because the interface didn't exist. The interface to use the cell module does exist, if you want to be a little hacker you can just load it up in minicom and send AT commands to your hearts content. All that's needed to be user friendly is a daemon and a fancy UI, and those already exist. I suspect that no one has done the necessary work yet because no one has the hardware and therefore the real desire to. There's a difference in motivation between wanting to do something in two months vs wanting to do something today.

 

[Silent-Hunter]

There is software that really works, it's just not in any way user friendly. EvilDragon has said the hardware has been tested, calls have been made and answered via a serial terminal.
This is not the case of the DSP where the hardware existed and everyone was gung ho about using it but we literally could not because the interface didn't exist. The interface to use the cell module does exist, if you want to be a little hacker you can just load it up in minicom and send AT commands to your hearts content. All that's needed to be user friendly is a daemon and a fancy UI, and those already exist. I suspect that no one has done the necessary work yet because no one has the hardware and therefore the real desire to. There's a difference in motivation between wanting to do something in two months vs wanting to do something today.

I have a question. Can minicom be made to 'ring' when an incoming call is coming? If so, I personally don't need any fancy software, and will be happy to simply leave the minicom interface open all the time.

 

[scippie]

There is software that really works, it's just not in any way user friendly. EvilDragon has said the hardware has been tested, calls have been made and answered via a serial terminal.
This is not the case of the DSP where the hardware existed and everyone was gung ho about using it but we literally could not because the interface didn't exist. The interface to use the cell module does exist, if you want to be a little hacker you can just load it up in minicom and send AT commands to your hearts content. All that's needed to be user friendly is a daemon and a fancy UI, and those already exist. I suspect that no one has done the necessary work yet because no one has the hardware and therefore the real desire to. There's a difference in motivation between wanting to do something in two months vs wanting to do something today.

You missed my point. I am talking about real usage. It's great that it works via a serial terminal, that means that the signals are OK. But there is much more to be tested. What if the Pyra releases and the real software to make calls is being Pyra-ised and we come to find out that there is an unbearable latency between what the modem receives and what is actually coming out of the speakers because ED forgot some specific stuff in the hardware design. This problem will come out too late and the Pyra will be useless for making phone calls whereas if it were tested earlier, ED could have resolved the problem before release. Or what if the serial terminal showed OK but it showed it after two seconds and ED didn't think about this maybe being a latency issue... As making a usable phone is much more than handling latency (it was just an example), I can imagine that there are many things that might be overlooked during design and simple testing to see if signals come through.

Not saying that ED is not doing a great job. He certainly is and I don't think I could do it better, probably the opposite, but this device has potential to be much more than a hacker's tool, and if he wants me to buy it, it must have some specific selling points that at this point are not proven.

A simple example: I have recently bought a wifi enabled camera doorbell. I can watch the image on my tablet/phone. I can even listen, take pictures, make video's and replay those video's. But when someone actually rings my doorbell, it takes up to 1 minute!!! before my phone starts making a noise. One minute can be enough for a delivery guy to leave. So I have returned this doorbell and asked for a refund. I am sure that some kind of designer has tested if the wifi signals were coming through to the right server and that the communication between the server and his test phone worked as well, but he certainly did not use this doorbell himself because then he would have known that it was useless for its actual selling point - being a doorbell.

EDIT: I actually also missed your point, sorry about that. If calls have been made with terminal commands, then this means that talking with someone has been proven to work. But it still doesn't prove that calls can be answered, that there are no too long timeouts, etc... so I keep my above point

 

[TrashyMG]

@scippie You are aware that this isn't the first phone device that Nikolaus has designed. The phone module is an all-in-one module and is essentially just a USB device and isn't that complicated to interface with. Many of the big software Devs in our community will have a chance to play with the Pyra for a while before the rest of us get a chance to see it. There is a good chance we may see a fairly polished application before final customer release. I know some uncertainty...

 

[scippie]

@scippie You are aware that this isn't the first phone device that Nikolaus has designed. The phone module is an all-in-one module and is essentially just a USB device and isn't that complicated to interface with. Many of the big software Devs in our community will have a chance to play with the Pyra for a while before the rest of us get a chance to see it. There is a good chance we may see a fairly polished application before final customer release. I know some uncertainty...

I wasn't aware. That's good news!
[doublepost=1484493524,1484493253][/doublepost]

@scippie You are aware that this isn't the first phone device that Nikolaus has designed. The phone module is an all-in-one module and is essentially just a USB device and isn't that complicated to interface with. Many of the big software Devs in our community will have a chance to play with the Pyra for a while before the rest of us get a chance to see it. There is a good chance we may see a fairly polished application before final customer release. I know some uncertainty...

But then, why does everyone in this topic try to tell me that it probably won't work?
Well maybe not literally, but that seems to be the global thought.

 

[TrashyMG]

But then, why does everyone in this topic try to tell me that it probably won't work?

Well I guess it still depends on the motivation of the initial team that gets the prototypes. They will have a lot on their plate and the phone software may be a low priority, however it's prob one of the easiest tasks to get done.

 

[Binky]

But then, why does everyone in this topic try to tell me that it probably won't work?

It's not that it won't work, its more that it won't well from day one.
If there were a slick phone UI that could be installed and would 'just work', then it'd be simple - but there isn't.
Given some time, someone in the community is going to get telephony working nicely, but there's no guarantee who or when. (which is why everyone on the forums speaks about it so cautiously)

The key difference between the Pyra and your IoT doorbell is that IoT devs like to write minimum quality software, ship the device, and forget about it, while the Pyra's software universe will mature, like fancy cheese.

 

[scippie]

It's not that it won't work, its more that it won't well from day one.
If there were a slick phone UI that could be installed and would 'just work', then it'd be simple - but there isn't.
Given some time, someone in the community is going to get telephony working nicely, but there's no guarantee who or when. (which is why everyone on the forums speaks about it so cautiously)

But I don't doubt these things, I never did. Some of my original questions have never been answered and that's where I have the doubts. For example, nobody seems to be able to answer this one: Like the pandora can be standby for days, will the pyra be standby for at least 24 hours and still be able to receive calls? I don't mind charging the Pyra on a daily basis, I do the same with my smartphone now, but I can't use the pyra as a full phone if I need to charge it every 4 hours. Not the stability or the state of the software makes that difference to me (as I said, I am willing to code myself to improve it), but if this would be the case, it makes the pyra useless as a phone and thus not interesting for me.

 

[TrashyMG]

Well I find the whole phone feature overrated myself.

 

[levi]

FWIW, I have no special knowledge, but I expect the initial solutions will only be able to receive calls in the top run mode (i.e. not in standby). I think someone would need to code up a kernel module that responds to interrupts from the modem for it still to be able to do it in non-run modes, and that might take some special knowledge that I don't possess and have no intent of learning myself.

 

[Silent-Hunter]

But I don't doubt these things, I never did. Some of my original questions have never been answered and that's where I have the doubts. For example, nobody seems to be able to answer this one: Like the pandora can be standby for days, will the pyra be standby for at least 24 hours and still be able to receive calls? I don't mind charging the Pyra on a daily basis, I do the same with my smartphone now, but I can't use the pyra as a full phone if I need to charge it every 4 hours. Not the stability or the state of the software makes that difference to me (as I said, I am willing to code myself to improve it), but if this would be the case, it makes the pyra useless as a phone and thus not interesting for me.

If it's anything like the Pandora, it won't really need standby, just closing the screen would cut the CPU speed and turn off the backlight, and I would think it would last more than 48 hours. But don't quote me on that.

 

[levi]

ISTR some update in the past changed the low power mode setting such that it only actually enters low power mode when it's on charge. If it's on battery, it'll actually enter some sort of standby mode. And it hasn't bothered setting the CPU speed for a while now, as the CPU is able to automatically scale its clock/OPP depending on what it needs to do, so if you're not running anything and the radios etc. are off, it's going to just be ticking over anyway.

Whether the pyra already has the same functionality, I don't know, but if not the first preorders might not get such stellar battery life at the very beginning. Hopefully experience with the OMAP3's run modes can be applied to the OMAP5 quite easily, but I can't really guess how long it'll be before battery life is good enough.

 

[Silent-Hunter]

ISTR some update in the past changed the low power mode setting such that it only actually enters low power mode when it's on charge. If it's on battery, it'll actually enter some sort of standby mode. And it hasn't bothered setting the CPU speed for a while now, as the CPU is able to automatically scale its clock/OPP depending on what it needs to do, so if you're not running anything and the radios etc. are off, it's going to just be ticking over anyway.

Whether the pyra already has the same functionality, I don't know, but if not the first preorders might not get such stellar battery life at the very beginning. Hopefully experience with the OMAP3's run modes can be applied to the OMAP5 quite easily, but I can't really guess how long it'll be before battery life is good enough.

Thanks for the info! I'm hoping the Pyra will have that stuff already, I would imagine the same settings should work since it's another OMAP.

 

[AndiTheBest]

When the Pyras are shipped, we can start a contest who will make the fanciest phone-application.
As I think qt development will be easier than on the Pandora (because of debian), I'm in!

 

[sulu]

Whoever already wants to get his hands dirty on telephony software for the Pyra could try to get FSO and SHR running stable on Debian Stretch/Sid. The issues I've encountered when testing those do not depend on actually having a modem available and should be generally architecture-independent.
So you should be able to do this on your x86 desktop computer or laptop.

 

[kabaiakh]

When the Pyras are shipped, we can start a contest who will make the fanciest phone-application.

AFAIK, what I really expect from my Pyra is the capacity to process incoming calls according to the caller's number.
Instead of simply make the device ring/vibrate/glow to notify me so I can answer an incoming call, some would be hanged up (like a firewall RECECT) or even better, would be linked to a local answering machine (knowing voicemails are stored at my carrier's annoys me, especially now that they tend to convert them to texts).
Another great feature suggested by my kid: automagically answer and send back received audio with some lag && echo (a kind of firewall DROP), simulating a calling issue in the hope of discouraging telemarketing centers to call me again to try to make me 'buy things I don't need with money I don't have to impress people I don't like'.