What needs to be done before a Pyra prototype can be produced?

[Mr_Loon]

Hi ED, my understanding is that after recent progress from the case manufacturer, you're getting close to the stage where a Pyra prototype can be produced, could you give a quick summary of what we're waiting for before we can see a Pyra prototype.

I'm also curious as to whether the plan is to produce a prototype for each 'flavour' of the Pyra?

FWIW it seems to me like a very sensible idea to do so but I can also see that with a tight budget this might not be possible.

 

[EvilDragon]

Well, PCBs are already here and we also got a lot of LCD Cables and keymats (though they're older stiffer ones).

So ones we receive the cases, I can build prototypes.
2GB RAM units work fine, 4GB RAM units still freeze, but they can be assembled as well.

 

[Mr_Loon]

Cheers ED that's exactly what I hoped to hear.

Do you plan to build prototypes both the standard & mobile editions and both the US & EU mobile editions?

 

[levi]

Did you ever ask the prototype orderers whether they wanted an early prototype or one where most of the issues have been ironed out? We know Grench voted for the latter, but are some of the paid prototype users getting early prototypes, or will this round mainly be for devs so they can populate the repo* and find and fix mostly software or stability issues?

* Or make the repo to begin with. I guess an actual repo website might come later, as it did with the pandora, and posting stuff to personal sites and to the old file archive (forget the name) might do to begin with.

 

[EvilDragon]

Did you ever ask the prototype orderers whether they wanted an early prototype or one where most of the issues have been ironed out? We know Grench voted for the latter, but are some of the paid prototype users getting early prototypes, or will this round mainly be for devs so they can populate the repo* and find and fix mostly software or stability issues?

Everyone can get an almost working one (i.e with a stiffer keymat, etc.), as these things can easily be changed later if need be

However, they should run without any freeze first, which would mean 2GB RAM right now

* Or make the repo to begin with. I guess an actual repo website might come later, as it did with the pandora, and posting stuff to personal sites and to the old file archive (forget the name) might do to begin with.

Lalala... I'm not supposed to say anything...

 

[Mr_Loon]

However, they should run without any freeze first, which would mean 2GB RAM right now

Would it not make sense to send 4GB prototypes to people who might be able to diagnose the cause of the 4GB freeze, unless it has been confirmed that the freeze is due to a physical problem with the boards rather than a timing issue?

Guess it might help us to understand if we knew a bit more about the 4GB problem, i.e. When does the freeze occur? Immediately on boot, after a few seconds, seemingly at random? etc.

Still curious if the prototypes will be standard or mobile edition, ES or EU or a mixture of those?

 

[EvilDragon]

Would it not make sense to send 4GB prototypes to people who might be able to diagnose the cause of the 4GB freeze, unless it has been confirmed that the freeze is due to a physical problem with the boards rather than a timing issue?

A mixture of both. Juliano has not finished all simulations, but it seems the higher power usage of the 4GB RAM also mean more noise and that can be the issue already.
It could be this is already fixed with the optimized CPU boards (the ones for the mass production run), but until the simulations are finished (they simply take time), we can't confirm either.

Higher voltage would decrease the noise, and right now we're running the 4GB RAM with 1,35V whereas they can also run with 1,5V.

So within the next few days we should know whether the 4GB RAM has a hardware issue here and whether or not we can work around it with those 1,5V (it's a software configuration).

So as a summary, these are the current possibilities:

1. Hardware issue (too much noise) that's already fixed in the latest revision. Maybe raising the voltage fixes that in the current revision as well.
2. Hardware issue (too much noise) still on the optimized board... would need more capacitors, but there's on space on the CPU board. Maybe raising the voltage / changing timings fixes that (less noise).
3. Same as 2), but raising voltage / changing timings doesn't fix that: Worst case. It means we can't produce the 4GB RAM version, only the 2GB ones.
4. Not a hardware issue: In this case, something is wrong with the timings / setup and that can be fixed in software.

It doesn't make sense shipping out 4GB RAM-Version to others - as we already know what to check and it could mean I need to ship out 2GB versions afterwards if it's not fixable in software.

Guess it might help us to understand if we knew a bit more about the 4GB problem, i.e. When does the freeze occur? Immediately on boot, after a few seconds, seemingly at random? etc.

Randomly, usually within 20 minutes though.

Still curious if the prototypes will be standard or mobile edition, ES or EU or a mixture of those?

A mixture of those, forgot to reply to that question.

 

[Silent-Hunter]

@EvilDragon are you concerned about a lot of people cancelling if the 4GB version is not possible? I am.

 

[AnimatedFreak]

Hoping the 4GB issue get's solved. 4GB is about what I use on my desktop when doing casual computer work. So anything below that would be a bit of a disappointment for me. I wouldn't cancel tho but I could see why some would tbh.

 

[Mr_Loon]

@EvilDragon are you concerned about a lot of people cancelling if the 4GB version is not possible? I am.

Must admit this does concern me more than a little after pushing so strongly back in 2015 for tests to be done to determine the implications of offering a 4GB version, in an ideal world (money no object) this would of course have been done way before pre orders were taken. Sadly we don't live in an ideal world.

FWIW After hearing that the problem occurs 'Randomly, usually within 20 minutes' on non optimised boards it makes me much more confident there is no intrinsic issue with using 4GB. I'm basing that on general logic rather than any real expertise though....

 

[Silent-Hunter]

Hoping the 4GB issue get's solved. 4GB is about what I use on my desktop when doing casual computer work. So anything below that would be a bit of a disappointment for me. I wouldn't cancel tho but I could see why some would tbh.

The Pyra can probably do with 2GB what your desktop does with 4, so it shouldn't be a problem. If you use Windows on your desktop, there's no comparison.

 

[Grench]

Everyone can get an almost working one (i.e with a stiffer keymat, etc.), as these things can easily be changed later if need be

However, they should run without any freeze first, which would mean 2GB RAM right now

Lalala... I'm not supposed to say anything...

Stiff Keymat with a future replacement option available later - I'm good with that for my prototype.

The 4GB RAM was never an actual necessity for this project. I'm good with a stable 2GB unit for my prototype.

However, I DO need a US 4G module in it.

So, If you can assemble a running and stable 2GB US4G with a more or less working OS, I'll take it. However, I also realize that as #8 in the prototype-pre-order queue, I'm pretty much last in the prototype distribution line.

 

[EvilDragon]

So, If you can assemble a running and stable 2GB US4G with a more or less working OS, I'll take it. However, I also realize that as #8 in the prototype-pre-order queue, I'm pretty much last in the prototype distribution line.

Yep, can do that

 

[Pyramancer]

I'm optimistic that the 4 GB problem will be solved either through debugging the software settings or with the updated hardware.

It will, though, be quite a severe blow for me if it can't be fixed. I'm hoping to do with my Pyra what I currently do with my notebook/laptop on which I rarely have less than 2.5 GB of memory in use. (Yes, that's on GNU/Linux.)

One question: Do the logs show how much memory is in use when the system fails? Just randomly wondering if it happens when memory usage transitions above 2 GB.

 

[Grench]

Yep, can do that

So - I should look for a box from Germany arriving sometime late next week?

I know - never promise a timeline. Still - my Pyra may win the race Vs the keymat sample? Seems to still be in the running anyway.
[doublepost=1494607507,1494607223][/doublepost]

I'm optimistic that the 4 GB problem will be solved either through debugging the software settings or with the updated hardware.

It will, though, be quite a severe blow for me if it can't be fixed. I'm hoping to do with my Pyra what I currently do with my notebook/laptop on which I rarely have less than 2.5 GB of memory in use. (Yes, that's on GNU/Linux.)

One question: Do the logs show how much memory is in use when the system fails? Just randomly wondering if it happens when memory usage transitions above 2 GB.

Modern Linux installations use 'free' RAM to read/write cache the drives. RAM usage winds up being far in excess of what is needed by the running OS & programs. I have 48GB of RAM in my home desktop workstation running Debian Stretch. It is not uncommon for it to consume 30+GB of that RAM with disk caching. So, there is a very good chance that your machine is showing RAM usage far in excess of RAM required.

Actual testing done on actual dev boards using actual programs have shown that 2GB of RAM is plenty.

 

[Swordfish II]

I have 48GB of RAM in my home desktop workstation running Debian Stretch. It is not uncommon for it to consume 30+GB of that RAM with disk caching. So, there is a very good chance that your machine is showing RAM usage far in excess of RAM required.

And here I am with my Raspberry Pi 2 running a custom Raspbian as my primary desktop. (I do keep an old more powerful x86 for video editing and other stuff if needed) haha.

 

[Grench]

And here I am with my Raspberry Pi 2 running a custom Raspbian as my primary desktop. (I do keep an old more powerful x86 for video editing and other stuff if needed) haha.

Don't be too envious. My hardware is relatively old, but I've hotroded it a bit. Used server RAM is pretty cheap for 8+ year old workstations. That 48GB cost $120.

 

[Swordfish II]

Don't be too envious. My hardware is relatively old, but I've hotroded it a bit. Used server RAM is pretty cheap for 8+ year old workstations. That 48GB cost $120.

Might as well at that price (which was also the reason I went with the Pyra 4GB as opposed to the 2GB). I don't think I will ever fully utilize it, but seeing how I still regularly use tech from more than 10 years ago....it should give the Pyra a long, long life.

 

[Pyramancer]

Modern Linux installations use 'free' RAM to read/write cache the drives. RAM usage winds up being far in excess of what is needed by the running OS & programs. I have 48GB of RAM in my home desktop workstation running Debian Stretch. It is not uncommon for it to consume 30+GB of that RAM with disk caching. So, there is a very good chance that your machine is showing RAM usage far in excess of RAM required.

Hmm... The >2.5 GB of used memory was not counting the memory used for the cache, kernel buffers, or shared memory. (The usage for those varies tremendously; right now it is slightly more than 6 GB.)

This system came with only 2 GB and it was extremely slow under my typical usage -- swapping all the time. An upgrade to 12 GB solved that problem and now it is as fast as I need (except when building software or running simulations). Admittedly, in retrospect, 12 GB was overkill. 8 GB would have been plenty; 4 GB might have been enough.

A 2 GB Pyra will certainly be usable. But for my use cases, a 4 GB Pyra is what I need.

 

[EvilDragon]

Hmm, I just checked... I rarely hit 2GB RAM usage on my desktop system (ArchLinux).
It has 4GB RAM, which is more than enough than what I need