Just a quick heads up


His assumption was that I meant playing games on the Pyra while the Pyra was closed in one's pocket. And now you're saying that I cannot blame him for his assumption because it made sense. How exactly does it make more sense to play games on the Pyra while the Pyra is closed in one's pocket than to play games on the Pyra while the Pyra is open in one's hands while using the rumble feature as a cooler alternative for notification? If anything the senselessness of his assumption makes me blame him even more and is enough to report his post as a candidate for the wall-of-shame where everyone who's posts have been recorded will only receive Pyra's without rumble.
His assumption made sense because you implied that you were talking about when rumble was necessary by mentioning the pocket scenario in the same condition. Rumble isn't necessary when you are looking at the screen. Is it cool? For some people, yes. For others, no.

Also, what you're suggesting is like saying that the Pyra does not need sound because it's also possible to have music notes, sound waves, or some other representation of the sound display on the screen. The rumble feature is essential to the experience just like the sound is. It basically makes the Pyra 4-D. Imagine having on D removed from the screen and thus having a 1-D screen. Sure, it could still display representations of a 2-D screen but it would not be the same. It's not good enough without that extra D. Now we have 4 D's. We have width, height, time, and rumble — those are the 4 D's of 4-D gaming and he who masters them all will be the master of Pirii.
Rumble is hardly as important as sound is. Many people, in fact, dislike rumble and even turn it off in games whenever possible. And even then, there are many people who are fine w/ playing games w/o sound.

Seriously though, will Pyrii have rumble? I need rumble for when I'm playing Smash64 and a DK uses his vB on the ground.
If you were reading the posts by ED and hns, you should know that a potential solution is being tested. Additionally, they still would have rumble even if this issue could not be fixed. You just couldn't use rumble properly at the same time as you used sound. (Which I realize makes the feature pretty much dead in the water for gaming purposes, but would still allow you to use it for your pocket notifications scenario)

I hope not. If a device goes to sleep (which in my book means suspend to ram) the CPU should be switched off, which would mean that it can't respond to the modem telling it you've received a message or an incoming call. The situation's different I guess if you didn't opt for a cellular unit, but I think most of us opted for a cellular unit.
Actually, suspend-to-ram can be woken up by the modem. This is what PalmOS phones did all the time. It's suspend-to-disk that can't be woken up, although the Wake-On-Ring page on wikipedia suggests that maybe even suspend-to-disk (referred to as hibrenation on their article) can be woken by the modem as well... (source: https://en.wikipedia.org/wiki/Wake-on-ring)

-God Ginrai
 
Last edited:
His assumption made sense because you implied that you were talking about when rumble was necessary by mentioning the pocket scenario in the same condition.
I said it was for <condition1> and for <condition2>. I mentioned two separate conditions for when rumble is good. And because it was made explicit by the "for" that preceded the second condition that the second condition was a separate condition from the first condition there is no excuse for him to assume that the the two conditions were really two parts of one and the same condition.

In fact, the "for" is not even necessary because the second "when" is a separate reference to an instance of time and although it could refer to the same time as that which the first "when" refers to there's no implication that it does and if the only way for the sentence to make sense is if it does not then it's clear that the second "when" refers to a time that's different from the time that the first "when" refers to. So even without the second "for" he would still have had no excuse to assume that those times must be the same.
 
I said it was for <condition1> and for <condition2>. I mentioned two separate conditions for when rumble is good. And because it was made explicit by the "for" that preceded the second condition that the second condition was a separate condition from the first condition there is no excuse for him to assume that the the two conditions were really two parts of one and the same condition.
Yes, that is English. Unfortunately to be clear sometimes here you need to learn to speak nerd. I get a feeling a nerd would be happier if you'd written 'for this or for that' i.e. replace your 'and' by an 'or'.

Edit: In case that wasn't clear, that post should be read with a healthy dose of ;)-ism
 
Last edited:
I said it was for <condition1> and for <condition2>. I mentioned two separate conditions for when rumble is good. And because it was made explicit by the "for" that preceded the second condition that the second condition was a separate condition from the first condition there is no excuse for him to assume that the the two conditions were really two parts of one and the same condition.

In fact, the "for" is not even necessary because the second "when" is a separate reference to an instance of time and although it could refer to the same time as that which the first "when" refers to there's no implication that it does and if the only way for the sentence to make sense is if it does not then it's clear that the second "when" refers to a time that's different from the time that the first "when" refers to. So even without the second "for" he would still have had no excuse to assume that those times must be the same.
You skipped over what I explained and decided to argue a completely separate point. The fact of the matter is that your first conjunct poisoned the well allowing for cognitive bias to take over. If you truly meant for them to be wholly separate, you shouldn't have included them in the same sentence.

-God Ginrai
 
OMAP+TWL6040 use a protocol called McPDM but it is similar to SPI and I2S. Unfortunately we have not found any registers for inverting the clock out pin... If you are interested in the details, it is twl6040 erratum #8 "PDM Downlink Data Corrupted" in TI document SWCZ0007D from 2011 (it seems to be NDA only).
I think I found a TI document that reference this bug:

At first I thought it was related to noise on the clock line and adding an inverter was meant to buffer the signal and remove the noise, but reading this document again makes it clear that they mean that audio noise is a side effect of this bug xD

I hope that removing the resistor won't attenuate the clock signal, or introduce signal noise/reflection
 
Yes, that is English. Unfortunately to be clear sometimes here you need to learn to speak nerd. I get a feeling a nerd would be happier if you'd written 'for this or for that' i.e. replace your 'and' by an 'or'.
If I do it like that then the sentence becomes weaker because only one of the conditions would need to be valid. If it is good for this or for that then it can be good only for this or only for that. If it is good for this and for that then it must be good for both.
You skipped over what I explained and decided to argue a completely separate point.
You said I implied they were the same, I explained why I was actually explicit in them not being the same.

The fact of the matter is that your first conjunct poisoned the well allowing for cognitive bias to take over. If you truly meant for them to be wholly separate, you shouldn't have included them in the same sentence.
The sentence was fine. It says what I meant to say. If your cognitive bias prevents you from reading it correctly then you need more sentences like this so that you can practice. This is another example of when rumble could be handy; you could have a bot on the forums seek out these sentences for you and send them to your Pyra when it finds some. Your Pyra could then warn you through rumble that there is a new sentence to practice with.
 
I think I found a TI document that reference this bug:
Thanks for locating this! Yes, it is exactly this issue: "3.13 McPDM Downlink Data Corrupted With TWL604x". Was already present with omap4 and not only omap5.
At first I thought it was related to noise on the clock line and adding an inverter was meant to buffer the signal and remove the noise, but reading this document again makes it clear that they mean that audio noise is a side effect of this bug xD

I hope that removing the resistor won't attenuate the clock signal, or introduce signal noise/reflection
It is clock noise that disturbs and corrupts the PCM data stream and that is converted into audible noise by the digital analog converters. There may also be some feedback involved through power supply. This means if the rumble motor runs or loud audio is played the supply voltage inside of the twl6040 may fluctuate. And the decision point for clock edges may move into the critical range and data corruption occurs. And then the high level audio noise from the speakers keeps the clock in the critical range so that it only ends if you end and restart playing some sound. The inverter would move the clock edge away by one half clock cycle. Or a capacitor could make the clock edge slower and that moves it away. Or removing the resistor and the open wires behind makes the clock edge more precise.
 
One thing confused me a bit: when there is this bug, and it’s known from TI so they put it in the documents , why ditnt they fix it ?
And are selling the faulty Chips??

I don’t have a problem whit not having the hibernation mode...


Send from something, i guess ^^
 
@matzesu
ASIC production is extremly costly and time consuming. You have to change the VDHL files (high level description of the cpu). Then you may have to optimize the compiled results by hand, where parts like resistors etc. are placed. After this you have to produce masks for the UV machines and you may have to modify the machine configuration.

To produce a single medium size chip prototype, you have to pay something between 100k to 1 million Euros. And since the bug happens only in a few circumstances and can easily migated with a capacitor, it seems to be cheaper just to release an errata.
 
Ok, but now I’m much more confused:
Ditnt whe had 2 Bugs?
-vibrating and sound don’t work together
- hibernating mode..

Which one will get fixed by removing a electronic part from the board ?


Send from something, i guess ^^
 
Ok, but now I’m much more confused:
Ditnt whe had 2 Bugs?
-vibrating and sound don’t work together
- hibernating mode..

Which one will get fixed by removing a electronic part from the board ?

Removing the resistor seems to fix the vibrating and sound issue, from what I heard.

The lack of suspend and hibernation is not a bug as far as I know. It's just something we don't have software for. It's a complex kernel development. Maybe once people do it someone discovers some hardware bug preventing it, but, as far as I know, which isn't much, we still don't know anything that hints that there'll never be hibernation. It might eventually work, if people put the effort in the kernel.

There is another bug in the OMAP5432 that is lack of idle mode. If you put the CPU in the idle mode to keep it working at a minimum and save battery, then it sometimes crashes when speeding it back up. That seems unfixable, but that is not about hibernation or suspend, just idle mode. If I understand it correctly, idle mode is more power than suspend or hibernate, but still little power, and software-wise it is much more simple to obtain, besides the speed up when needed should be faster than resume, so it would have been good but it won't work on OMAP5432 (any device with OMAP5432, not just the Pyra).

[EDIT: I meant than when you suspend or hibernate you power off several hardware components (more in hibernate than suspend, but still a lot) and you also stop some of the clock signals that synchronize them. This saves power. When you resume you need to resynchronize clocks and repower up components and go to some of the boot up steps to get components in working order again, while making sure the system not only works, but gets back to the same point it was in when suspended or hibernated. Once you have all that programmed and tested in your linux kernel (and hopefully upstreamed) then you need to watch out if a new version of the kernel might have changed something that requires maintenance and retesting. But when you go to idle mode, the system more or less keeps working, just slower, so some energy is saved, but not so much as in hibernate. But it doesn't need to orchestrate all the partial power downs and ups and so on, so it is easier to program and it's more likely to keep working in new kernels with less maintenance.

With "the speed up when needed should be faster than resume" I mean that for the CPU it is also less work to do and therefore less time to transition idle -> normal speed than it is to transition from hibernated/suspended to resumed, so that transition from idle would be faster. If resuming is too slow you might not be able to reply in time to something else that is talking to you and some protocols might fail, so that might also be a reason to prefer idling.

It's a little like if the CPU were an athelete, then idling would be like stop running and start walking step by step, suspend would be like taking shoes and clothes off, putting a pyjama on, getting into a bed and having a nap, and hibernation would be like taking clothes and shoes off, saving them in their cupboards, putting on a pyjama, tidying a little bit, getting to bed and sleeping. The OMAP 5432 needs to keep running because if it tries to walk step by step it may sometimes fall over. So once it learns how to untie his shoes, he may be able to run and sleep, meanwhile it just runs.

But I'm not sure I understand all this and would be glad to be corrected.
]
 
Last edited:
Is it possible to be playing a game, close the lid and come back to it a couple of days later and resume play?Or will this bug prevent that?
 
Is it possible to be playing a game, close the lid and come back to it a couple of days later and resume play?Or will this bug prevent that?

I don't know. I'd say it is not possible yet, it might be in the future (with hibernation), but I'm not convinced that it would be possible now (without hibernation) even if the OMAP5432 didn't have the bug in idle mode.
I don't know if idle mode or even suspend would be enough to keep the system powered for 2 days. If we ever get hibernate and resume to work, you'll be able to do that even with the idle bug.

[EDIT: Of course I think both of us mean a locally played game. A network game can't generally be resumed because the server and the other players may not have the patience to wait 2 days for you to come back]
 
Last edited:
Is it possible to be playing a game, close the lid and come back to it a couple of days later and resume play?Or will this bug prevent that?
If we get hibernation, yes. But as of right now, I don't think so. At least not without plugging in, as no idle means more power usage.

Sent from my H3123 using Tapatalk
 
I seem the recall the shape was inspired by a taco one of the creators was eating.If the Pyra's lid is closed, isn't the default behavior to go to sleep?
b8xet5lfsht31.jpg
Guy on Reddit said:
I work with a bunch of Ex-Nokia people, and they tell me that the hardware designers of the N-Gage had the project forced on them, nobody wanted to do it, so their first design prototype they presented to management was one inspired by Goatse, thinking management would reject it because of how silly it is.
It passed.
It even has the ring.

Not the best sources, but it explains so much (awful controls, awkward phone calls and bad design overall) that it might not be an elaborate hoax.
 
Even my 3DS won't last two days if it's not plugged in to its charger. Even my Pandora would struggle to remain from the charger for that long, but would maybe just about manage it (though it'd be in desperate need of a charge when you next plug it in). The only battery charged device that will last longer is my phone, but that's uses a specially low power CPU. I don't have any gaming devices that will last that long.
 
Thanks for locating this! Yes, it is exactly this issue: "3.13 McPDM Downlink Data Corrupted With TWL604x". Was already present with omap4 and not only omap5.

It is clock noise that disturbs and corrupts the PCM data stream and that is converted into audible noise by the digital analog converters. There may also be some feedback involved through power supply. This means if the rumble motor runs or loud audio is played the supply voltage inside of the twl6040 may fluctuate. And the decision point for clock edges may move into the critical range and data corruption occurs. And then the high level audio noise from the speakers keeps the clock in the critical range so that it only ends if you end and restart playing some sound. The inverter would move the clock edge away by one half clock cycle. Or a capacitor could make the clock edge slower and that moves it away. Or removing the resistor and the open wires behind makes the clock edge more precise.
Sounds like a lot of speculation. Has any actual measurements been done? I understand that the actual clock signal is tricky to measure, but what about the power line (close to the twl6040) while the vibrator is running? If that's a problem, maybe it can be helped with better filtering or additional capacitors. Does the problem get worse at lower battery levels?

Maybe I should ask all these questions on the mailing list, and leave this thread for grammar discussions? xD
 
  • Like
Reactions: rSl
Back
Top