Finally, a bit more news!

[netcat]

One thing I do feel relatively strongly about is there should be ZERO emphasis on a new cpu board or whatever until the current orders are fulfilled. That would be wrong.

 

[elw3]

We should always talk about that tho.
Weve seen parts getting out of stock suddenly.
Also the Pandora had a cpu upgrade mid production. By a drop in, but still.
So keeping the topic hot is smart.

 

[Librelism]

I'd hardly call where we're at mid production though. This is barely produced. If switching to another part is necessary because ED actually can't buy them any more then so be it, but if it's not a 100% needed change to get remaining orders done then it shouldn't even be considered. Any other ideas for changes can be discussed as part of a Pyra 2 project separate from this.

 

[elw3]

New cases, new modem. Changes are already done. I dont see the point of the complain.
Due to the pure time it took to bring this baby to life it just makes sense to question the parts being used regularly.
As time passes there WILL be a better AND cheaper cpu for this project for certain, then it would be stupid to cling to the old.
Not saying i want to see it produced just yet either. But talking about it is always good and informative.

 

[Djoga'Ro]

Who's to say you cannot work on the sequel in parallel? So, whenever ED's waiting on others, he still mustn't think about or - god forbid - work on the the next step? Cardinal sin or something like that?

 

[netcat]

Yes - getting distracted is a cardinal sin of delivery.

 

[Librelism]

Who's to say you cannot work on the sequel in parallel? So, whenever ED's waiting on others, he still mustn't think about or - god forbid - work on the the next step? Cardinal sin or something like that?

"I'm considering a Pyra 2 in parallel and all future revisions will be exclusive to that" is not the vibe I'm getting when I read ED saying "If I had 200k I would redesign a completely new case for the Pyra." To me that reads like more work that would delay existing orders for the Pyra 1 from being finished that is not actually necessary. What about using 200k to hire more staff to assemble every remaining Pyra order with the current design as soon as possible? Things like this should be #1 priority when it comes to putting any more money into the Pyra in my opinion.

 

[elw3]

If you have anything like a pyra 2 in mind you catastrophically failed to understand what the pyra is.

 

[matzesu]

The big concept of the Pyra was that you don’t need a new Handheld anymore , only upgrade CPU Boards

 

[Librelism]

I'm not saying "Pyra 2" would/should be incompatible as upgrades for existing Pyras. My point is: Lock down current orders to a final design and stick with it until they're shipped. Anything else can be for those who already have theirs looking for new upgrades or those willing to wait any longer to order an upgraded version. If it's not being done to finish orders ASAP then it's not worth doing yet. I'd rather have any Pyra with older I/O and a deprecated CPU than having to wait another 6 years for one with USB-C and a more modular case. I'll order those parts later for an outdated Pyra after all.

 

[Djoga'Ro]

Yes - getting distracted is a cardinal sin of delivery.

Distracted from what? I wrote "whenever ED's waiting on others". I.e. time periods in which he cannot work on assembly/delivery.

I'm not saying "Pyra 2" would/should be incompatible as upgrades for existing Pyras. My point is: Lock down current orders to a final design and stick with it until they're shipped. Anything else can be for those who already have theirs looking for new upgrades or those willing to wait any longer to order an upgraded version. If it's not being done to finish orders ASAP then it's not worth doing yet. I'd rather have any Pyra with older I/O and a deprecated CPU than having to wait another 6 years for one with USB-C and a more modular case. I'll order those parts later for an outdated Pyra after all.

ED often enough pointed out, money makes the wheels turn faster. What he was saying now, with enough money he'd have better (in terms of upgradability and assembility) cases designed quickly to then churn out Pyras at a fast pace. "Enough money" here not merely meaning enough to do it at all, but indeed enough to make it happen quickly, which is not the same. And it's a big IF, unless you're about to send 200k his way.

 

[LogicalUnit]

Let me know:
Would you prefer it if I stop working on the project, call it dead and file for bankruptcy because I can't pay back all the preorders - or if I continue to work on it, deliver units as good as possible, send out refunds if customers request it (or they use the voucher for something else) and pay back all liabilities, even though it takes a long time.

My expectation was that seven years after placing my preorder, I would have a Pyra in my hands.

Yes, I knew there was risk. Yes, it was my decision to pay in bitcoin. Yes, a few Pyras have shipped, so it's not completely vapourware. Let me change my assessment from "vapourware" to "in development hell".

We paid you money because we thought you could deliver a product. I am upset because you are not taking responsibility for the lack of progress. Infrequent updates where you say "things have gone wrong, but I'm still doing stuff -- please keep waiting" is simply not good enough.

ED, you need to have a very honest conversation with us about exactly WHEN you think you can fulfill remaining preorders. You need to set a deadline, or else admit you cannot deliver. You cannot keep extending the project indefinitely. I genuinely want you to succeed, and I want a Pyra in my hands that I can use and show to my friends. But I have come to the conclusion that if this were possible, you would have done it by now.

The obvious problem is manpower. You simply don't have the human resources this project requires. You need to raise some capital, hire some engineers, and devote more of your own time to this thing.

TL;DR You cannot keep asking us to wait.

 

[elw3]

I am upset because you are not taking responsibility for the lack of progress.

I just died a little inside.
ED is too nice to ever tell it like that, but, shut the fuck up.
All you do is complaining and then completely ignore responses to that, which took a wasted amount of time to write.
If you cant deal with the simple fact that running such project is just unpredictable then just leave.

 

[ClockworkCoder]

ED, you need to have a very honest conversation with us about exactly WHEN you think you can fulfill remaining preorders

He has been extremely detailed, and blunt, as to why he cannot give firm deadlines.

You have to make the decision yourself, and there is plenty of history to go from to base that on, as to whether you push for a refund, or wait it out.

If love to see a predicted timeline of production events myself, but over the last seven years I've learned why this is not possible; with a tightly stretched budget, and priorities on working hard to fund that, it's a real challenge of absolute determination and endurance on ED's part, and it's testament to him that it is even a possibility that the rest of the Pyrae may still be delivered.

Practically anyone else in the same situation would have given up and cut their losses years ago.

 

[PowerGod]

@LogicalUnit : The choice is just Pyra or not Pyra, it's simple.
If you want this device you have to wait, if you don't want to wait then you will never own this device.
How much important is for you ?

There are other similar things on the DragonBox store that you can get using the preorder voucher you made for the Pyra, if those devices are good for you, you will be happy, and we'll have one less person in line for the Pyra.

Just don't ask to stop a running project about a unique device in the world because it's slow, there are people who wants this because they think that there are still no better alternatives around.

 

[Alphasys]

Ed, thank you for your hard work, making this project happen. I wish I wasn't 800 km away from you. I have plenty "free time", and would love to help you assemble the Pyrae, for just some food and a corner to sleep in. Not kidding. If I could, I'd be at your doorstep right now, offering my help.

On the software side of things, you're having a bit of a "chicken or egg" situation. I'm sure that there are multiple software developers within the community that could do work on the OS and other supporting software. But without any hardware to actually test these solutions on, that avenue is not open. Once there are a good number of Pyrae out there in the wild, the community can finally step up and produce some solutions to the current software problems. Yet, the Pyra works, albeit with sub-optimal software solutions so far. But as you said yourself, it's just software, so it can be fixed. Just needs fixers with actual hardware to test their fixes on. So don't worry too much about the software side of things. It's always going to be an ongoing upgrade path. Software development is just like that.

At any rate, I'd rather have an actual Pyra in my hands that I can work with, than having tot wait for someone to come up with a "better" software solution by their own lonesome self, which I see happening right now. A community of a thousand people can come up with solutions way faster than a few singular developers. One of the big selling points of the Pyra is, that every thing is open. The hardware and the software. So there's no secretive back-chamber coding that needs to happen. Leverage the community to come up with solutions. Which means, that even though there are some flaws, produce and send out these Pyrae as soon as possible.

 

[netcat]

It's an open vapour ecosystem

 

[oskda]

My expectation was that seven years after placing my preorder, I would have a Pyra in my hands.

Yes, I knew there was risk. Yes, it was my decision to pay in bitcoin. Yes, a few Pyras have shipped, so it's not completely vapourware. Let me change my assessment from "vapourware" to "in development hell".

We paid you money because we thought you could deliver a product. I am upset because you are not taking responsibility for the lack of progress. Infrequent updates where you say "things have gone wrong, but I'm still doing stuff -- please keep waiting" is simply not good enough.

ED, you need to have a very honest conversation with us about exactly WHEN you think you can fulfill remaining preorders. You need to set a deadline, or else admit you cannot deliver. You cannot keep extending the project indefinitely. I genuinely want you to succeed, and I want a Pyra in my hands that I can use and show to my friends. But I have come to the conclusion that if this were possible, you would have done it by now.

The obvious problem is manpower. You simply don't have the human resources this project requires. You need to raise some capital, hire some engineers, and devote more of your own time to this thing.

TL;DR You cannot keep asking us to wait.

Have you read previous messages from ED in this thread? I think you haven't because he has answered cearly most questions you ask.

Note this:

• He could fill bankrupt for Pyra project (and this project is bankrupt) but he doesn't want to do so, and he continues shipping Pyra machines losing money on each.
• He can't ship them faster because he need to compensate loss with other sells form his shop.
• ¿How is he going to raise capital and hire engineers, etc if this is bankrupt and losing money on each Pyra he ships?

On other side (this is my point of view) now you can't raise a crowdfunding campaign: 1st/ Who would trust on it after a lot of years delay; All crowdfunding news would emphasize that bad experience with deadlines after years waiting. 2nd/ It would raise funds mainly for new orders/model, but it wouldn't solve problem for existing paid orders. 3th/ How much money would he need to ask for a Pyra 2 to make it attractive today to more people and cover previos Pyra order loss (so you can ship Pyra 2 to those old orders)? I think it would be too much to attract new backers.

 

[oskda]

The i.MX 8M is not the Plus - though (my bad), I also didn't mean thr Plus but the normal i.MX8, which is the only interesting one regarding the CPU (as it has two Cortex A72).
The A53 has 2.3 DMIPS/MHz, the Cortex A15 has 3.4 DMIPS/MHz.

Both the A53 in the i.MX 8M and the A15 in the OMAP5 are clocked with a max of 1.5GHz.

That means one core in the i.MX 8M can run 3450 DMIPS, whereas one core in the OMAP5 can do 5100 DMIPs.
So in single core use (which is important for emulation needs) the OMAP5 is a lot faster than the i.MX 8M.

Both cores combined, the OMAP5 has 10200 DMIPS and the i.MX 8M has 13800 DMIPS using all four cores.

So yes, in single core performance, the OMAP5 is faster and all cores combined, it's not that much slower than the i.MX8M.

It doesn't really make sense working on a new CPU board that does not offer much improvement compared to the one we have.

The i.MX8 would've been interesting - but that's the one that needs a huge heatsink.
But yeah, that one has two additional Cortex A72 cores on top of the ones that the i.MX8M has - and these have at least 6.3 DMIPS/Mhz, so the i.MX8 is A LOT faster than the i.MX8M or the OMAP5.
(a single core A72 with 1.5GHz would be at least 9450 DMIPs, but usually even higher, so up to three times as fast as the A53 in the 8M...)

I did those DMIPS/MHz calculations a lot of time ago in "Future CPU" threads. You are right with numbers, but this is not about numbers but about support and functionality of CPU.

It is more important to have more DMIPS or to have better support, new kernels, drivers, proper sleep/suspend mode, less heat inside?

NXP i.MX 8M has less performance using only one core but:

1/ It is 64-bit. I suspect you can't compare DMIPS from 32 bit to 64 bit CPU (of course if you are using 64-bit mode. Note these modes on ARM are separated, i.e. it is not like on Intel x86 where each ISA extending from x to 2x bits add up more instructions to the set mixing all them; on ARM 64 bit is a new ISA different and incompatible from 32 bit old ISA, you can't mix code, CPU is on 32 bit or on 64 bit mode and run very different software on each side).

2/ Do you remember the headache it was to support 4GB because that is the theoretical limit for a 32 bit system. No problem on 64 bit CPU mode.

3/ With all cores it is a bit faster but more efficient.

4/ Sleep/suspend mode is a MUST on a pocket computer. I have a lot of pocket computers since 80's and all of them were great on suspend lasting a lot of time on a charge or battery, some of them months, a few even more than a year. Even my Android smartphone if suspended (instant on but wifi/etc off) last a month. In a pocket computer (this is not only a console but a pocket computer) that factor is a must: it is needed it to be instantly on and ready from suspend when you pick up form your pocket. Even 14 hours (when Nikolaus finish on AESS) is ridiculous: you can pick up from your pocket to use it and... no battery :O

I know this is hard/bug problem with OMAP5 (mostly used on automotive industry where suspend is not required), and there is no solution for it.

5/ I have said it before: support, drivers, less blobs, long term support. Those are key point, points NXP i.MX 8M can fulfill, while Rockchip can't. You have been clear about it: «[TI OMAP5] receives updates in mainline Linux kernel - whereas with other vendors (like Rockchip, for example), there's no real support at all. Once they release the SoC, they release a kernel and that's basically it. While the community tries to support modern kernels as well, not everything does work yet, so you would be stuck with an older kernel here as well, no difference.»

There is sense working on a new CPU board if offer much improvement on mentioned aspects. I see them much more important than raw performance.

When Librem 5 and MNT choose that NXP SOC they did for those reasons: good support, LTS and long term availability.

 

[Letalis Sonus]

4/ Even my Android smartphone if suspended (instant on but wifi/etc off) last a month.

Spoiler: That ain't suspend, the CPU is still running and reacting on peripheral interrupts. The ARM architecture does not implement an actual suspend mode. You can't just turn the CPU off, instead you tell it to wait for the next interrupt or other event to happen, which means that the power consumption on its lowest power mode largely depends on how well you manage to reduce the interrupt load from peripherals by making sure they're powered down when not needed as well. Turning off the CPU always requires a full boot sequence afterwards - unlike the ACPI- and UEFI-assisted suspend mode on x86 platforms, which causes a whole lot of issues if not done properly instead of just using more power.