levi
Still fresh, damnit!
Yes, the pandora had options; to just blank the screen, or to send the unit into low power mode were amongst the options I recall. I can't remember right now what the default was.
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.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.
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.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.
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)Seriously though, will Pyrii have rumble? I need rumble for when I'm playing Smash64 and a DK uses his vB on the ground.
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)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.
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.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.
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'.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.
Unfortunately to be clear sometimes here you need to learn to speak nerd.
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.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 think I found a TI document that reference this bug: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).
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.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'.
You said I implied they were the same, I explained why I was actually explicit in them not being the same.You skipped over what I explained and decided to argue a completely separate point.
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.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.
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.I think I found a TI document that reference this bug:
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.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
I hope that removing the resistor won't attenuate the clock signal, or introduce signal noise/reflection
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 ?
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.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 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?
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.
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?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.