Hi,
I think my latest unit is supposed to have all fixes, so I was surprised to still have some of the fallowing issues. I though my old unit was faulty, but now it looks some of the problems may be actual design issues.
- the LCD is flickering at many brightness levels (same as older unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras. - the wifi is extremely slow on my unit, tens of kB/s while the phone does at least 1MB/s on the same router on the n (5GHz) band. On a different b/g router it does 200-300kB/s and at least works (older unit doesn't work at all there). - the speakers make a disturbing loud crack while DE is loading (same as older unit). No idea what's going on there, trying to play a boot sound? I've turned down and muted everything in audio mixers and it still does it. Ended up disabling everything audio related in dts just to get rid of this. - shoulder buttons are barely usable (tend to get stuck pressed) - there are periodic sata errors in dmesg ("exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen"), don't know what it means, and I don't have anything connected - still no signs of life from OTG port, but it's charging at least - lid switch isn't working (old unit too) - touchscreen is unusable on the edges. With dead nubs it makes some UI elements inoperable - (broken board?) nubs are never responding. On older board, they die after some time (devices on the bus stop responding) - (broken board?) noticeably draining the battery while off (older unit doesn't do this)
confirmed fixes: - USB squeek is gone - write protect works on SD2 now - wifi now works on b/g, but very slow on b/g/n - keypad is a lot better
Gražvydas
On Sun, 2018-10-14 at 02:57 +0300, Grazvydas Ignotas wrote:
Hi,
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
The frequency is set WAY too low right now, same for the keyboard LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
To my knowledge, this is the driver: http://www.ti.com/product/TPS61041/technicaldocuments
It supports switching up to 1MHz, which should be enough for a flicker- free backlight (it's also especially created for PDAs and Smartphones, so it should work)
- the wifi is extremely slow on my unit, tens of kB/s while the phone
does at least 1MB/s on the same router on the n (5GHz) band. On a different b/g router it does 200-300kB/s and at least works (older unit doesn't work at all there).
With the freezes I had, I couldn't test it yet - but will do so ASAP. According to the measurements, the antenna connection is fine... not sure if this could be a software issue...?
- the speakers make a disturbing loud crack while DE is loading (same
as older unit). No idea what's going on there, trying to play a boot sound? I've turned down and muted everything in audio mixers and it still does it. Ended up disabling everything audio related in dts just to get rid of this.
Sound is not working at all at the current kernel and as aTc never had speakers in his unit, even on older kernels (where audio wasn't broken at least), it was never properly implemented in the OS setup. I never had anything else except for crackling speakers here. The Audio Test I was running was form a test OS done by Nikolaus. He at least created a script which was able to play sound from the speakers.
Audio is still a software hell right now. ABE is not yet working with newer kernels and for some reason the setup is that channel 1 and 2 output on the headset and 3 and 4 on the speakers.
This is one of the biggest software-work still left, I guess :/
- shoulder buttons are barely usable (tend to get stuck pressed)
The case is not a final one. I'll tweak the buttons together with the new company once we've switched the molds. One of the CEOs is an avid gamer himself, so he knows how shoulder buttons should work (something FormAction doesn't have a clue with).
So yes, that's to be expected with the current version.
- there are periodic sata errors in dmesg ("exception Emask 0x10 SAct
0x0 SErr 0x4040000 action 0xe frozen"), don't know what it means, and I don't have anything connected
No idea about that :)
- still no signs of life from OTG port, but it's charging at least
Beware: The charging is a bit broken as well right now! The driver for some reason always sets the limit to 0.5A as soon as I connect a USB cable. Even setting it back manually to 2A doesn't work. It only works fine in U-Boot.
The driver was a quick hack by Nikolaus, as there wasn't an existing one. He is working on it and made some improvements but something is still wrong (most likely has something to do with VBUS detection).
About OTG: AFAIR there was still a software bug which is fixed as far as I know (it was discussed on the mailing list a few weeks ago), but I don't think that's implemented in our setup yet.
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one? It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
AFAIK, Nikolaus tested the switch manually with a magnet, so it SHOULD work.
- touchscreen is unusable on the edges. With dead nubs it makes some
UI elements inoperable
Ah - damn. That means I accidentally put in one of the older screens which I didn't approve. They weren't marked in any way, so I probably mixed them up with the final ones :(
- (broken board?) nubs are never responding. On older board, they die
after some time (devices on the bus stop responding)
Yes, probably broken, as they work fine on the other boards I have here. Interesting though that they stopped working on an older board - never seen that before!
- (broken board?) noticeably draining the battery while off (older
unit doesn't do this)
I'll recheck, but I think that didn't happen here.
Well, the biggest issue is: I was never able to thouroughly test all the hardware / boards I have here, as the software wasn't finished. And with these frezes, I couldn't work on the automated testing script (similar to the one we have on the Pandora).
So while Nikolaus made low-level tests to confirm the hardware is working when the PCB is properly produced, I couldn't test the PCBs I've got here yet. The one I sent to you was completely untested as well.
I'll now try to finish the testing scripts ASAP so I can test all the units and give feedback to Global Components. It's very important we tell them what the failures on the PCBs are, so they can check these issues and make sure they won't happen in mass production.
On Sun, Oct 14, 2018 at 4:53 AM Michael Mrozek EvilDragon@openpandora.org wrote:
On Sun, 2018-10-14 at 02:57 +0300, Grazvydas Ignotas wrote:
Hi,
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
The frequency is set WAY too low right now, same for the keyboard LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
It says 12000000 which is 12ms period/83Hz I suppose. Any idea how/why the current value was chosen?
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
On Mo, 2018-10-15 at 01:26 +0300, Grazvydas Ignotas wrote:
Hi,
The frequency is set WAY too low right now, same for the keyboard
LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
It says 12000000 which is 12ms period/83Hz I suppose. Any idea how/why the current value was chosen?
https://patchwork.kernel.org/patch/9313259/
Matthijs complained about that as well and Nikolaus doesn't see the flickering (I know not everyone does) :)
Matthijs already looked it up back then and it seems that usually, 175Hz is used.
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
Okay, that might be the reason. Well, the first prototype didn't even have a magnet installed - and for the second one, I bought a few that fit well as a test, but there are stronger ones available as well.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
Ah, great, you added that. Thanks :)
Am 15.10.2018 um 00:26 schrieb Grazvydas Ignotas notasas@gmail.com:
On Sun, Oct 14, 2018 at 4:53 AM Michael Mrozek EvilDragon@openpandora.org wrote:
On Sun, 2018-10-14 at 02:57 +0300, Grazvydas Ignotas wrote:
Hi,
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
The frequency is set WAY too low right now, same for the keyboard LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
It says 12000000 which is 12ms period/83Hz I suppose. Any idea how/why the current value was chosen?
1/50 is too slow and makes flicker visible to everybody. higher values have the problem that the converter does not reach 100% of the theoretically possible maximum brightness the closer it comes to 1/500. If you go beyond ca. 1/150 you will already notice that.
This is an interaction between PWM and the DC/DC converter which needs ca 1ms to start to illuminate the panel.
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
I tested with evtest.
BR, Nikolaus
Am Montag, den 15.10.2018, 11:37 +0200 schrieb H. Nikolaus Schaller:
Hi,
The frequency is set WAY too low right now, same for the keyboard LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
It says 12000000 which is 12ms period/83Hz I suppose. Any idea how/why the current value was chosen?
1/50 is too slow and makes flicker visible to everybody. higher values have the problem that the converter does not reach 100% of the theoretically possible maximum brightness the closer it comes to 1/500. If you go beyond ca. 1/150 you will already notice that.
Well, I do notice flickering up to 120Hz on CRTs, so it should still be higher than 82Hz :)
I think the "common" 175Hz that normal monitors use, should be good.
This is an interaction between PWM and the DC/DC converter which needs ca 1ms to start to illuminate the panel.
Well, is it theoretically possible to change the frequency based on brightness? With maximum brightness, even with 83Hz, flickering is barely visible (I guess because the LEDs also have some fall-off time), but with lower brightness, it gets worse.
So maybe for full brightness 100Hz so that we reach full possible brightness and for various lower brightness values higher frequencies.
I'm happy to test different values and deliver the perfect frequency values depending on the brightness.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
I tested with evtest.
Okay, if that is confirmed to be working, I'll use it as test as well.
On Mo, 2018-10-15 at 11:37 +0200, H. Nikolaus Schaller wrote:
I now wanted to check the lid switch with evtest.
evtest shows the following devices on our OS:
/dev/input/event0: user-button /dev/input/event1: pyra-gpio-keys@1 /dev/input/event2: pyra-gpio-keys@2 /dev/input/event3: palmas_pwron /dev/input/event4: tca8418 /dev/input/event5: TSC2007 Touchscreen /dev/input/event6: nub0 /dev/input/event7: nub1 /dev/input/event8: accelerometer-iio-input-bridge /dev/input/event9: twl6040:vibrator /dev/input/event10: pyraInput keyboard /dev/input/event11: pyraInput Gamepad /dev/input/event12: pyraInput Mouse
Which one do I use for the lid switch?
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
I tested with evtest.
On Di, 2018-10-23 at 01:50 +0200, Michael Mrozek wrote:
Thanks to aTcs help, I know it's event2.
However, I was not able to trigger the switch with a magnet as well. I can test it on a few more units, but as we already have a few where it's not working, I doubt this will make a difference.
@Nikolaus: Could you check the switch still works fine with your latest prototype?
Could this be a misconfiguration in the board file?
On Mo, 2018-10-15 at 11:37 +0200, H. Nikolaus Schaller wrote:
I now wanted to check the lid switch with evtest.
evtest shows the following devices on our OS:
/dev/input/event0: user-button /dev/input/event1: pyra-gpio-keys@1 /dev/input/event2: pyra-gpio-keys@2 /dev/input/event3: palmas_pwron /dev/input/event4: tca8418 /dev/input/event5: TSC2007 Touchscreen /dev/input/event6: nub0 /dev/input/event7: nub1 /dev/input/event8: accelerometer-iio-input-bridge /dev/input/event9: twl6040:vibrator /dev/input/event10: pyraInput keyboard /dev/input/event11: pyraInput Gamepad /dev/input/event12: pyraInput Mouse
Which one do I use for the lid switch?
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
I tested with evtest.
Am 23.10.2018 um 02:10 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Di, 2018-10-23 at 01:50 +0200, Michael Mrozek wrote:
Thanks to aTcs help, I know it's event2.
Beware: the mapping of event numbers is not stable. It depends on random sequence how drivers are loaded. The correct way to map them by udev rules to stable file names:
http://git.goldelico.com/?p=letux-kernel.git;a=blob;f=Letux/etc/udev/rules.d...
Alternatively you have to scan /sys/class/input for a device name and take the event number shown there.
something like
function findinput () { for i in /sys/class/input/input* do if [ "$(cat $i/name)" = "$1" ] then echo $i/event* return fi done }
Maybe we should also add proper udev rules for the lid sensor event to map it to /dev/input/lid.
However, I was not able to trigger the switch with a magnet as well. I can test it on a few more units, but as we already have a few where it's not working, I doubt this will make a difference.
@Nikolaus: Could you check the switch still works fine with your latest prototype?
I have tried with
evtest --query /dev/input/event2 EV_SW 0 && echo on || echo off
but also no success.
Could this be a misconfiguration in the board file?
Yes. There may something have become broken (pull-up/down?). I will evaluate.
On Mo, 2018-10-15 at 11:37 +0200, H. Nikolaus Schaller wrote:
I now wanted to check the lid switch with evtest.
evtest shows the following devices on our OS:
/dev/input/event0: user-button /dev/input/event1: pyra-gpio-keys@1 /dev/input/event2: pyra-gpio-keys@2
^^^ maybe we should define better names...
/dev/input/event3: palmas_pwron /dev/input/event4: tca8418 /dev/input/event5: TSC2007 Touchscreen /dev/input/event6: nub0 /dev/input/event7: nub1 /dev/input/event8: accelerometer-iio-input-bridge /dev/input/event9: twl6040:vibrator /dev/input/event10: pyraInput keyboard /dev/input/event11: pyraInput Gamepad /dev/input/event12: pyraInput Mouse
Which one do I use for the lid switch?
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one?
Just closing the lid. I don't have any magnets handy for testing.
It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
You can use evtest, pyra_test_inputs should also support it.
I tested with evtest.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Hi,
Am 14.10.2018 um 03:53 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Sun, 2018-10-14 at 02:57 +0300, Grazvydas Ignotas wrote:
Hi,
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
WHat I have sometimes observed is that the backlight intensity depends on whether USB is plugged in or the system operates from battery. This means it might depend a little on VSYS fluctuations. Especially since the VSYS going to the display board through the tiny display cable traces have a quite high resistance.
I am not sure if I have some older display cable prototypes or the latest ones. But I have planned for long time (but never done) to look at the PWM signal and backlight voltage on the display board by oscilloscope if there is e.g. some jitter.
The frequency is set WAY too low right now, same for the keyboard LEDs. It can be set in the pyra-mainboard-v5.0.dtsi. You can find it searching for "pwm-backlight".
To my knowledge, this is the driver: http://www.ti.com/product/TPS61041/technicaldocuments
It supports switching up to 1MHz, which should be enough for a flicker- free backlight (it's also especially created for PDAs and Smartphones, so it should work)
- the wifi is extremely slow on my unit, tens of kB/s while the phone
does at least 1MB/s on the same router on the n (5GHz) band. On a different b/g router it does 200-300kB/s and at least works (older unit doesn't work at all there).
With the freezes I had, I couldn't test it yet - but will do so ASAP. According to the measurements, the antenna connection is fine... not sure if this could be a software issue...?
I have not made speed tests but shold probably do so... What is the best debian command line tool for doing that?
- the speakers make a disturbing loud crack while DE is loading (same
as older unit). No idea what's going on there, trying to play a boot sound? I've turned down and muted everything in audio mixers and it still does it. Ended up disabling everything audio related in dts just to get rid of this.
Sound is not working at all at the current kernel and as aTc never had speakers in his unit, even on older kernels (where audio wasn't broken at least), it was never properly implemented in the OS setup. I never had anything else except for crackling speakers here. The Audio Test I was running was form a test OS done by Nikolaus. He at least created a script which was able to play sound from the speakers.
Audio is still a software hell right now.
Yes, it is quite broken...
ABE is not yet working with newer kernels and for some reason the setup is that channel 1 and 2 output on the headset and 3 and 4 on the speakers.
This is one of the biggest software-work still left, I guess :/
- shoulder buttons are barely usable (tend to get stuck pressed)
The case is not a final one. I'll tweak the buttons together with the new company once we've switched the molds. One of the CEOs is an avid gamer himself, so he knows how shoulder buttons should work (something FormAction doesn't have a clue with).
So yes, that's to be expected with the current version.
- there are periodic sata errors in dmesg ("exception Emask 0x10 SAct
0x0 SErr 0x4040000 action 0xe frozen"), don't know what it means, and I don't have anything connected
No idea about that :)
I also haven't seen this. Maybe a false trigger of the SATA controller that it thinks there is a drive connected but gets no response. There is some fully automatic detection.
- still no signs of life from OTG port, but it's charging at least
Beware: The charging is a bit broken as well right now! The driver for some reason always sets the limit to 0.5A as soon as I connect a USB cable. Even setting it back manually to 2A doesn't work.
That is what Idon't understand from the data sheet or the driver. Manual setting should always override the automatic power supply detection. Unless it is triggered again.
Question: what is the console log when pluggingin/unplugging the cable? It should report some r8=and r9=values in addition to telling that the input_current_limit increases to 2A.
It only works fine in U-Boot.
The driver was a quick hack by Nikolaus, as there wasn't an existing one. He is working on it and made some improvements but something is still wrong (most likely has something to do with VBUS detection).
This has been fixed in the latest one. VBUS detection seems to be reliable now.
About OTG: AFAIR there was still a software bug which is fixed as far as I know (it was discussed on the mailing list a few weeks ago), but I don't think that's implemented in our setup yet.
Yes, it now works on OMAP5EVM and some older prototype having a hardware fix that is also on the newer boards. I have only one of the newer boards but can't boot or run it reliably yet.
- lid switch isn't working (old unit too)
Okay, this is something we need to check. Have you tried triggering the lid switch with the lid magnet or with an external one? It could be the magnet in the lid is too weak - but I had no idea how I could test the lid switch, so couldn't check that.
AFAIK, Nikolaus tested the switch manually with a magnet, so it SHOULD work.
- touchscreen is unusable on the edges. With dead nubs it makes some
UI elements inoperable
Ah - damn. That means I accidentally put in one of the older screens which I didn't approve. They weren't marked in any way, so I probably mixed them up with the final ones :(
- (broken board?) nubs are never responding. On older board, they die
after some time (devices on the bus stop responding)
Yes, probably broken, as they work fine on the other boards I have here. Interesting though that they stopped working on an older board - never seen that before!
- (broken board?) noticeably draining the battery while off (older
unit doesn't do this)
Do you have a rough estimate how fast it drains? This could help to exclude some components.
BR, Nikolaus
I'll recheck, but I think that didn't happen here.
Well, the biggest issue is: I was never able to thouroughly test all the hardware / boards I have here, as the software wasn't finished. And with these frezes, I couldn't work on the automated testing script (similar to the one we have on the Pandora).
So while Nikolaus made low-level tests to confirm the hardware is working when the PCB is properly produced, I couldn't test the PCBs I've got here yet. The one I sent to you was completely untested as well.
I'll now try to finish the testing scripts ASAP so I can test all the units and give feedback to Global Components. It's very important we tell them what the failures on the PCBs are, so they can check these issues and make sure they won't happen in mass production.
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Montag, den 15.10.2018, 11:33 +0200 schrieb H. Nikolaus Schaller:
Hi,
the LCD is flickering at many brightness levels (same as older unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
WHat I have sometimes observed is that the backlight intensity depends on whether USB is plugged in or the system operates from battery. This means it might depend a little on VSYS fluctuations. Especially since the VSYS going to the display board through the tiny display cable traces have a quite high resistance.
Isn't the voltage for the PWM stabilized by the PALMAS as well? So it should be unaffected by whatever the source voltage is...?
I am not sure if I have some older display cable prototypes or the latest ones. But I have planned for long time (but never done) to look at the PWM signal and backlight voltage on the display board by oscilloscope if there is e.g. some jitter.
Except for the VERY first run, the prototype cables haven't changed regarding resistance, so that shouldn't be an issue.
However, as reported, if you send the heartbeat to the LEDs in the backside, the backlight visibly flickers. My guess is that the fast on / off has some affect on the ground plane so the PWM isn't fast enough to compensate with that.
As NO one wants to have a heartbeat or similar on the Logo LEDs, I don't have a problem with that, and as long as you simply have it illuminated in one color, the flickering doesn't occur.
With the freezes I had, I couldn't test it yet - but will do so ASAP. According to the measurements, the antenna connection is fine... not sure if this could be a software issue...?
I have not made speed tests but shold probably do so... What is the best debian command line tool for doing that?
Probably just use the usual wpa-supplicant / ifconfig-commands to connect to your Wifi and then use wget to download a huge file from your server.
- still no signs of life from OTG port, but it's charging at least
Beware: The charging is a bit broken as well right now! The driver for some reason always sets the limit to 0.5A as soon as I connect a USB cable. Even setting it back manually to 2A doesn't work.
That is what Idon't understand from the data sheet or the driver. Manual setting should always override the automatic power supply detection. Unless it is triggered again.
I will do various tests and report back.
Question: what is the console log when pluggingin/unplugging the cable? It should report some r8=and r9=values in addition to telling that the input_current_limit increases to 2A.
I'll send you the log.
It only works fine in U-Boot. The driver was a quick hack by Nikolaus, as there wasn't an existing one. He is working on it and made some improvements but something is still wrong (most likely has something to do with VBUS detection).
This has been fixed in the latest one. VBUS detection seems to be reliable now.
In your U-Boot? I don't think we've got it implemented in our U-Boot yet.
Am 15.10.2018 um 15:43 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Montag, den 15.10.2018, 11:33 +0200 schrieb H. Nikolaus Schaller:
Hi,
the LCD is flickering at many brightness levels (same as older unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
That's not a hardware issue, it's a software setup of the PWM. Some don't see it, but it's annoying for me as well.
WHat I have sometimes observed is that the backlight intensity depends on whether USB is plugged in or the system operates from battery. This means it might depend a little on VSYS fluctuations. Especially since the VSYS going to the display board through the tiny display cable traces have a quite high resistance.
Isn't the voltage for the PWM stabilized by the PALMAS as well?
No, it is the VSYS input voltage for efficiency reasons. If we would provide some Palmas voltage to the display inverter, we would loose 5-10% energy.
So it should be unaffected by whatever the source voltage is...?
I am not sure if I have some older display cable prototypes or the latest ones. But I have planned for long time (but never done) to look at the PWM signal and backlight voltage on the display board by oscilloscope if there is e.g. some jitter.
Except for the VERY first run, the prototype cables haven't changed regarding resistance, so that shouldn't be an issue.
However, as reported, if you send the heartbeat to the LEDs in the backside, the backlight visibly flickers. My guess is that the fast on / off has some affect on the ground plane so the PWM isn't fast enough to compensate with that.
As NO one wants to have a heartbeat or similar on the Logo LEDs, I don't have a problem with that, and as long as you simply have it illuminated in one color, the flickering doesn't occur.
With the freezes I had, I couldn't test it yet - but will do so ASAP. According to the measurements, the antenna connection is fine... not sure if this could be a software issue...?
I have not made speed tests but shold probably do so... What is the best debian command line tool for doing that?
Probably just use the usual wpa-supplicant / ifconfig-commands to connect to your Wifi and then use wget to download a huge file from your server.
- still no signs of life from OTG port, but it's charging at least
Beware: The charging is a bit broken as well right now! The driver for some reason always sets the limit to 0.5A as soon as I connect a USB cable. Even setting it back manually to 2A doesn't work.
That is what Idon't understand from the data sheet or the driver. Manual setting should always override the automatic power supply detection. Unless it is triggered again.
I will do various tests and report back.
Question: what is the console log when pluggingin/unplugging the cable? It should report some r8=and r9=values in addition to telling that the input_current_limit increases to 2A.
I'll send you the log.
Thanks!
It only works fine in U-Boot. The driver was a quick hack by Nikolaus, as there wasn't an existing one. He is working on it and made some improvements but something is still wrong (most likely has something to do with VBUS detection).
This has been fixed in the latest one. VBUS detection seems to be reliable now.
In your U-Boot? I don't think we've got it implemented in our U-Boot yet.
No, in kernel. U-Boot does no detection at all, except checking for battery presence. So as long as you run in U-Boot console mode there is only the automatic charging detection/handling of the bq24297.
BR, Nikolaus
Am Mon, 15 Oct 2018 16:16:23 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Isn't the voltage for the PWM stabilized by the PALMAS as well?
No, it is the VSYS input voltage for efficiency reasons. If we would provide some Palmas voltage to the display inverter, we would loose 5-10% energy.
Ah, I see. That makes sense.
In your U-Boot? I don't think we've got it implemented in our U-Boot yet.
No, in kernel. U-Boot does no detection at all, except checking for battery presence. So as long as you run in U-Boot console mode there is only the automatic charging detection/handling of the bq24297.
Which kernel version? Already in 4.18 or only in 4.19?
Hi,
Am 15.10.2018 um 18:38 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 15 Oct 2018 16:16:23 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Isn't the voltage for the PWM stabilized by the PALMAS as well?
No, it is the VSYS input voltage for efficiency reasons. If we would provide some Palmas voltage to the display inverter, we would loose 5-10% energy.
Ah, I see. That makes sense.
In your U-Boot? I don't think we've got it implemented in our U-Boot yet.
No, in kernel. U-Boot does no detection at all, except checking for battery presence. So as long as you run in U-Boot console mode there is only the automatic charging detection/handling of the bq24297.
Which kernel version? Already in 4.18 or only in 4.19?
I think I have backported it to 4.18.11:
http://download.goldelico.com/letux-kernel/letux-4.18.11/src/CHANGES
BR, Nikolaus
On 10/15/18 11:33 AM, H. Nikolaus Schaller wrote:
- (broken board?) noticeably draining the battery while off (older
unit doesn't do this)
Do you have a rough estimate how fast it drains? This could help to exclude some components.
My board also has this, and it's a slightly older 2gb one. It drains the battery from 100% to 0% in about a day.
I can do some more accurate timing if you want.
The method used to shut down the pyra doesn't seem to make any difference (software poweroff or holding the power button for 8+seconds).
Am Mon, 15 Oct 2018 18:02:30 +0200 hat aTc atc@k-n-p.org geschrieben:
It could be related to one of my findings: Some of the produced PCBs we have here use more power when running and even use power without the CPU board connected.
I think it was 2 or 3 out of 20 I tested.
I've tested them with USB only, but of course, if they use a bit of power, they will drain the battery as well.
It sounded like something GC needs to XRay and check (once I've got all the boards tested).
On 10/15/18 11:33 AM, H. Nikolaus Schaller wrote:
- (broken board?) noticeably draining the battery while off (older
unit doesn't do this)
Do you have a rough estimate how fast it drains? This could help to exclude some components.
My board also has this, and it's a slightly older 2gb one. It drains the battery from 100% to 0% in about a day.
I can do some more accurate timing if you want.
The method used to shut down the pyra doesn't seem to make any difference (software poweroff or holding the power button for 8+seconds). _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 10/15/18 6:37 PM, Michael Mrozek wrote:
Am Mon, 15 Oct 2018 18:02:30 +0200 hat aTc atc@k-n-p.org geschrieben:
Do you have a rough estimate how fast it drains? This could help to exclude some components.
I can do some more accurate timing if you want.
Here are three bqdump274 outputs over a 4 hour period. I first charged the battery to 100%, then shut it off, removing the usb cable and holding the powerbutton. Then powered it back on a few hours later to quickly run bqdump274 and shut it down again using the same method.
=============================================================================== 20:10 , after 00 minutes
CONTROL_STATUS: 008c voltages ok for Qmax: no Ra table updates are disabled: yes constant-power model: yes in SLEEP mode: no entry into HIBERNATE: no initialization is complete: yes resistance has been updated: no Qmax has updated: no board calibration routine: no Coulomb Counter Auto-Calibration: no in calibration mode: no SEALED: no Watchdog Reset: no enabled for SHUTDOWN: no DEVICE_TYPE: 0421 FW_VERSION: 0109 DM_CODE: 0000 CHEM_ID: 0128 Flags: 00a8 Discharging detected: no StateOfCharge() <= SOCF: no StateOfCharge() <= SOC1: no Battery insertion detected: yes in CONFIG UPDATE mode: no POR or RESET occurred: yes OCV measurement is performed: yes Fast charging allowed: no Full charge is detected: no Under-Temperature condition: no Over-Temperature condition: no Temperature: 0bea 31.9C Voltage: 0f54 3924mV NominalAvailableCapacity: 04e3 1251mAh FullAvailableCapacity: 04e3 1251mAh RemainingCapacity: 0612 1554mAh FullChargeCapacity: 0612 1554mAh AverageCurrent: 0355 853mA StandbyCurrent: fffd -3mA MaxLoadCurrent: fee2 -286mA Undocumented16: 053c 1340mAh? AveragePower: 0d13 3347mW Undocumented1a: 0000 0 StateOfCharge: 0064 100% InternalTemperature: 0bea 31.9C StateOfHealth: 015a 90% (instant) Undocumented22: ff73 -141 Undocumented22: ff73 -141 Undocumented24: 0ed1 3793 Undocumented26: 035b 859 RemainingCapacityUnfiltered: 04ba 1210mAh RemainingCapacityFiltered: 0612 1554mAh FullChargeCapacityUnfiltered: 04ba 1210mAh FullChargeCapacityFiltered: 0612 1554mAh StateOfChargeUnfiltered: 0064 100% OpConfig: 25f8 DesignCapacity: 053c 1340mAh Undocumented64: a5 165 Undocumented66: 1d70 7536 Undocumented68: 0360 864 Undocumented6a: 0617 1559 Undocumented6c: fc81 -895 Undocumented6e: 0222 546 Undocumented7a: f6c0 -2368 Undocumented7c: 0f53 3923 Undocumented7e: 0bea 3050
Data Memory: Over Temp: 0226 55.0C Under Temp: 0000 0.0C Temp Hys: 32 5.0C TCA Set: 63 99% TCA Clear: 5f 95% Update Status: 00 Reserve Cap: 0000 0mAh Load Select/Mode: 81 Q Invalid MaxV: 0edb 3803mV Q Invalid MinV: 0ea8 3752mV Design Capacity: 053c 1340mAh Design Energy: 1360 4960mWh Default Design Cap: 053c 1340mAh Terminate Voltage: 0c80 3200mV Taper Rate: 0064 100Hr/10 Taper Voltage: 1004 4100mV Sleep Current: 00ac 172mA V at Chg Term: 105e 4190mV
===============================================================================
23:14 , after 184 minutes
CONTROL_STATUS: 008c voltages ok for Qmax: no Ra table updates are disabled: yes constant-power model: yes in SLEEP mode: no entry into HIBERNATE: no initialization is complete: yes resistance has been updated: no Qmax has updated: no board calibration routine: no Coulomb Counter Auto-Calibration: no in calibration mode: no SEALED: no Watchdog Reset: no enabled for SHUTDOWN: no DEVICE_TYPE: 0421 FW_VERSION: 0109 DM_CODE: 0000 CHEM_ID: 0128 Flags: 01a8 Discharging detected: no StateOfCharge() <= SOCF: no StateOfCharge() <= SOC1: no Battery insertion detected: yes in CONFIG UPDATE mode: no POR or RESET occurred: yes OCV measurement is performed: yes Fast charging allowed: yes Full charge is detected: no Under-Temperature condition: no Over-Temperature condition: no Temperature: 0bb9 27.0C Voltage: 0f29 3881mV NominalAvailableCapacity: 04b9 1209mAh FullAvailableCapacity: 04e1 1249mAh RemainingCapacity: 0490 1168mAh FullChargeCapacity: 05d2 1490mAh AverageCurrent: 0394 916mA StandbyCurrent: fffd -3mA MaxLoadCurrent: fdde -546mA Undocumented16: 053c 1340mAh? AveragePower: 0de3 3555mW Undocumented1a: 056a 1386 StateOfCharge: 004f 79% InternalTemperature: 0bb9 27.0C StateOfHealth: 015a 90% (instant) Undocumented22: ff73 -141 Undocumented22: ff73 -141 Undocumented24: 0ed1 3793 Undocumented26: 0399 921 RemainingCapacityUnfiltered: 04a3 1187mAh RemainingCapacityFiltered: 0490 1168mAh FullChargeCapacityUnfiltered: 04cb 1227mAh FullChargeCapacityFiltered: 05d2 1490mAh StateOfChargeUnfiltered: 0061 97% OpConfig: 25f8 DesignCapacity: 053c 1340mAh Undocumented64: a5 165 Undocumented66: 1d70 7536 Undocumented68: 0380 896 Undocumented6a: 04a3 1187 Undocumented6c: fe09 -503 Undocumented6e: 021f 543 Undocumented7a: f642 -2494 Undocumented7c: 0f28 3880 Undocumented7e: 0bb9 3001
Data Memory: Over Temp: 0226 55.0C Under Temp: 0000 0.0C Temp Hys: 32 5.0C TCA Set: 63 99% TCA Clear: 5f 95% Update Status: 00 Reserve Cap: 0000 0mAh Load Select/Mode: 81 Q Invalid MaxV: 0edb 3803mV Q Invalid MinV: 0ea8 3752mV Design Capacity: 053c 1340mAh Design Energy: 1360 4960mWh Default Design Cap: 053c 1340mAh Terminate Voltage: 0c80 3200mV Taper Rate: 0064 100Hr/10 Taper Voltage: 1004 4100mV Sleep Current: 00ac 172mA V at Chg Term: 105e 4190mV
===============================================================================
00:20 , after 250 minutes
CONTROL_STATUS: 008c voltages ok for Qmax: no Ra table updates are disabled: yes constant-power model: yes in SLEEP mode: no entry into HIBERNATE: no initialization is complete: yes resistance has been updated: no Qmax has updated: no board calibration routine: no Coulomb Counter Auto-Calibration: no in calibration mode: no SEALED: no Watchdog Reset: no enabled for SHUTDOWN: no DEVICE_TYPE: 0421 FW_VERSION: 0109 DM_CODE: 0000 CHEM_ID: 0128 Flags: 01a8 Discharging detected: no StateOfCharge() <= SOCF: no StateOfCharge() <= SOC1: no Battery insertion detected: yes in CONFIG UPDATE mode: no POR or RESET occurred: yes OCV measurement is performed: yes Fast charging allowed: yes Full charge is detected: no Under-Temperature condition: no Over-Temperature condition: no Temperature: 0bb4 26.5C Voltage: 0f1c 3868mV NominalAvailableCapacity: 0434 1076mAh FullAvailableCapacity: 04e1 1249mAh RemainingCapacity: 040d 1037mAh FullChargeCapacity: 05a0 1440mAh AverageCurrent: 0383 899mA StandbyCurrent: fffd -3mA MaxLoadCurrent: fdde -546mA Undocumented16: 053c 1340mAh? AveragePower: 0d95 3477mW Undocumented1a: 0bc5 3013 StateOfCharge: 0049 73% InternalTemperature: 0bb4 26.5C StateOfHealth: 025a 90% (initial) Undocumented22: ff73 -141 Undocumented22: ff73 -141 Undocumented24: 0ed1 3793 Undocumented26: 0376 886 RemainingCapacityUnfiltered: 0416 1046mAh RemainingCapacityFiltered: 040d 1037mAh FullChargeCapacityUnfiltered: 04c3 1219mAh FullChargeCapacityFiltered: 05a0 1440mAh StateOfChargeUnfiltered: 0056 86% OpConfig: 25f8 DesignCapacity: 053c 1340mAh Undocumented64: a5 165 Undocumented66: 1d70 7536 Undocumented68: 0380 896 Undocumented6a: 0416 1046 Undocumented6c: fe8e -370 Undocumented6e: 021f 543 Undocumented7a: f676 -2442 Undocumented7c: 0f1c 3868 Undocumented7e: 0bb4 2996
Data Memory: Over Temp: 0226 55.0C Under Temp: 0000 0.0C Temp Hys: 32 5.0C TCA Set: 63 99% TCA Clear: 5f 95% Update Status: 00 Reserve Cap: 0000 0mAh Load Select/Mode: 81 Q Invalid MaxV: 0edb 3803mV Q Invalid MinV: 0ea8 3752mV Design Capacity: 053c 1340mAh Design Energy: 1360 4960mWh Default Design Cap: 053c 1340mAh Terminate Voltage: 0c80 3200mV Taper Rate: 0064 100Hr/10 Taper Voltage: 1004 4100mV Sleep Current: 00ac 172mA V at Chg Term: 105e 4190mV
On 10/16/18 12:30 AM, aTc wrote:
On 10/15/18 6:37 PM, Michael Mrozek wrote:
Am Mon, 15 Oct 2018 18:02:30 +0200 hat aTc atc@k-n-p.org geschrieben:
Do you have a rough estimate how fast it drains? This could help to exclude some components.
I can do some more accurate timing if you want.
and one more
8:43 , after 753 minutes:
CONTROL_STATUS: 008c voltages ok for Qmax: no Ra table updates are disabled: yes constant-power model: yes in SLEEP mode: no entry into HIBERNATE: no initialization is complete: yes resistance has been updated: no Qmax has updated: no board calibration routine: no Coulomb Counter Auto-Calibration: no in calibration mode: no SEALED: no Watchdog Reset: no enabled for SHUTDOWN: no DEVICE_TYPE: 0421 FW_VERSION: 0109 DM_CODE: 0000 CHEM_ID: 0128 Flags: 01ac Discharging detected: no StateOfCharge() <= SOCF: no StateOfCharge() <= SOC1: yes Battery insertion detected: yes in CONFIG UPDATE mode: no POR or RESET occurred: yes OCV measurement is performed: yes Fast charging allowed: yes Full charge is detected: no Under-Temperature condition: no Over-Temperature condition: no Temperature: 0ba2 24.7C Voltage: 0efb 3835mV NominalAvailableCapacity: 0117 279mAh FullAvailableCapacity: 04dc 1244mAh RemainingCapacity: 0073 115mAh FullChargeCapacity: 0585 1413mAh AverageCurrent: 03e8 1000mA StandbyCurrent: fffd -3mA MaxLoadCurrent: fdde -546mA Undocumented16: 053c 1340mAh? AveragePower: 0efb 3835mW Undocumented1a: 31d4 12756 StateOfCharge: 0009 9% InternalTemperature: 0ba2 24.7C StateOfHealth: 025a 90% (initial) Undocumented22: ff73 -141 Undocumented22: ff73 -141 Undocumented24: 0ed1 3793 Undocumented26: 03ea 1002 RemainingCapacityUnfiltered: 00f8 248mAh RemainingCapacityFiltered: 0073 115mAh FullChargeCapacityUnfiltered: 04bd 1213mAh FullChargeCapacityFiltered: 0585 1413mAh StateOfChargeUnfiltered: 0015 21% OpConfig: 25f8 DesignCapacity: 053c 1340mAh Undocumented64: a5 165 Undocumented66: 1d70 7536 Undocumented68: 03c0 960 Undocumented6a: 00f8 248 Undocumented6c: 01ab 427 Undocumented6e: 021a 538 Undocumented7a: f577 -2697 Undocumented7c: 0efa 3834 Undocumented7e: 0ba2 2978
Data Memory: Over Temp: 0226 55.0C Under Temp: 0000 0.0C Temp Hys: 32 5.0C TCA Set: 63 99% TCA Clear: 5f 95% Update Status: 00 Reserve Cap: 0000 0mAh Load Select/Mode: 81 Q Invalid MaxV: 0edb 3803mV Q Invalid MinV: 0ea8 3752mV Design Capacity: 053c 1340mAh Design Energy: 1360 4960mWh Default Design Cap: 053c 1340mAh Terminate Voltage: 0c80 3200mV Taper Rate: 0064 100Hr/10 Taper Voltage: 1004 4100mV Sleep Current: 00ac 172mA V at Chg Term: 105e 4190mV
Hi, many thanks for these values!
I suspect the battery is neither full nor empty at 100% or 0%... So it might be the fuel gauge chip is telling nonsense.
But my guess may be quite wrong...
So let me ask more to understand the scenario:
How long did you charge? Until the bq24297 tells it stops charging and the red power LED gets off? Or when the fuel gauge tells 100%?
How long did you discharge powered off? I.e. how was the 1 day estimate derived: is it until the Pyra did no longer boot again or until the fuel gauge tells 0%?
BTW: it seems to be easier to do cat /sys/class/power_supply/*/uevent to get an overview of all the charging/battery subsystem settings.
This script is quite good to monitor what is going on during charging and discharging (of course not with device turned off :):
http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=Letux/root/batt;...
BR and thanks, Nikolaus
Am 16.10.2018 um 08:53 schrieb aTc atc@k-n-p.org:
On 10/16/18 12:30 AM, aTc wrote:
On 10/15/18 6:37 PM, Michael Mrozek wrote:
Am Mon, 15 Oct 2018 18:02:30 +0200 hat aTc atc@k-n-p.org geschrieben:
Do you have a rough estimate how fast it drains? This could help to exclude some components.
I can do some more accurate timing if you want.
and one more
8:43 , after 753 minutes:
CONTROL_STATUS: 008c voltages ok for Qmax: no Ra table updates are disabled: yes constant-power model: yes in SLEEP mode: no entry into HIBERNATE: no initialization is complete: yes resistance has been updated: no Qmax has updated: no board calibration routine: no Coulomb Counter Auto-Calibration: no in calibration mode: no SEALED: no Watchdog Reset: no enabled for SHUTDOWN: no DEVICE_TYPE: 0421 FW_VERSION: 0109 DM_CODE: 0000 CHEM_ID: 0128 Flags: 01ac Discharging detected: no StateOfCharge() <= SOCF: no StateOfCharge() <= SOC1: yes Battery insertion detected: yes in CONFIG UPDATE mode: no POR or RESET occurred: yes OCV measurement is performed: yes Fast charging allowed: yes Full charge is detected: no Under-Temperature condition: no Over-Temperature condition: no Temperature: 0ba2 24.7C Voltage: 0efb 3835mV
^^^ a battery with 3.835V is more than 30% full
NominalAvailableCapacity: 0117 279mAh FullAvailableCapacity: 04dc 1244mAh RemainingCapacity: 0073 115mAh FullChargeCapacity: 0585 1413mAh
^^^ the bq24271 driver sould update this from device tree to 6000mAh.
AverageCurrent: 03e8 1000mA StandbyCurrent: fffd -3mA MaxLoadCurrent: fdde -546mA Undocumented16: 053c 1340mAh? AveragePower: 0efb 3835mW Undocumented1a: 31d4 12756 StateOfCharge: 0009 9%
a battery with 9% should have approx. 3.3V.
InternalTemperature: 0ba2 24.7C StateOfHealth: 025a 90% (initial) Undocumented22: ff73 -141 Undocumented22: ff73 -141 Undocumented24: 0ed1 3793 Undocumented26: 03ea 1002 RemainingCapacityUnfiltered: 00f8 248mAh RemainingCapacityFiltered: 0073 115mAh FullChargeCapacityUnfiltered: 04bd 1213mAh FullChargeCapacityFiltered: 0585 1413mAh StateOfChargeUnfiltered: 0015 21% OpConfig: 25f8 DesignCapacity: 053c 1340mAh
^^^ the bq24271 driver sould update this from device tree to 6000mAh. No idea why it didn't.
Undocumented64: a5 165 Undocumented66: 1d70 7536 Undocumented68: 03c0 960 Undocumented6a: 00f8 248 Undocumented6c: 01ab 427 Undocumented6e: 021a 538 Undocumented7a: f577 -2697 Undocumented7c: 0efa 3834 Undocumented7e: 0ba2 2978
Data Memory: Over Temp: 0226 55.0C Under Temp: 0000 0.0C Temp Hys: 32 5.0C TCA Set: 63 99% TCA Clear: 5f 95% Update Status: 00 Reserve Cap: 0000 0mAh Load Select/Mode: 81 Q Invalid MaxV: 0edb 3803mV Q Invalid MinV: 0ea8 3752mV Design Capacity: 053c 1340mAh Design Energy: 1360 4960mWh Default Design Cap: 053c 1340mAh Terminate Voltage: 0c80 3200mV Taper Rate: 0064 100Hr/10 Taper Voltage: 1004 4100mV Sleep Current: 00ac 172mA V at Chg Term: 105e 4190mV _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 15.10.2018 um 18:02 schrieb aTc atc@k-n-p.org:
On 10/15/18 11:33 AM, H. Nikolaus Schaller wrote:
- (broken board?) noticeably draining the battery while off (older
unit doesn't do this)
Do you have a rough estimate how fast it drains? This could help to exclude some components.
My board also has this, and it's a slightly older 2gb one. It drains the battery from 100% to 0% in about a day.
Oops. That would be 6000mAh in 24h = 250 mA...
This would also be ca. 875mW - something that should clearly be visible in a thermo camera.
No idea what can draw that much when Palmas is powered off.
Well, there are consumers on VSYS which could become active with Palmas off: * HOST ports - but they need a short circuit at the 5V output to draw that much * 3G/4G modem - should not need more than 10mA if it remains on unplanned * Headset multiplexer - hm... * WiFi module - has a separate power enable controlled by the OMAP5 (pulled low if OMAP5 is powered off) * Keyboard backlight - is a PWM from OMAP5 * display board - should also be turned off if there is no control from OMAP5 * DC/DC converters for SD cards
So it is difficult to say without directly measuring a board. Maybe ED has one where he identifies this effect. And can look at it through a thermo camera.
I can do some more accurate timing if you want.
The method used to shut down the pyra doesn't seem to make any difference (software poweroff or holding the power button for 8+seconds).
Both just shut off the Palmas but not necessarily other components.
BR, Nikolaus
Hi,
On 10/14/18 1:57 AM, Grazvydas Ignotas wrote:
Hi,
I think my latest unit is supposed to have all fixes, so I was surprised to still have some of the fallowing issues. I though my old unit was faulty, but now it looks some of the problems may be actual design issues.
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
This is because of the PWM Display. The darker it is, the more it's flickering.
- touchscreen is unusable on the edges. With dead nubs it makes some
UI elements inoperable
Interesting. Mine is a little harder on the edges but I can use it. And my Display does not sit perfectly in the housing, so it moves a little when pressing the edges. What do you mean with unusabe. Does it not react, is it too hard to press or does it click elsewhere on the screen?
- (broken board?) nubs are never responding. On older board, they die
after some time (devices on the bus stop responding)
Must be broken. On my Prototype the nubs are fine for over a year now. I can't
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Best Wishes Nino
On Sun, Oct 14, 2018 at 8:43 AM Nino Bock askarus@openpandora.org wrote:
Hi,
On 10/14/18 1:57 AM, Grazvydas Ignotas wrote:
Hi,
I think my latest unit is supposed to have all fixes, so I was surprised to still have some of the fallowing issues. I though my old unit was faulty, but now it looks some of the problems may be actual design issues.
- the LCD is flickering at many brightness levels (same as older
unit). It depends on lighting conditions how much it disturbs, but I can always see it and just can't stand it. There is no flickering on full brightness, and it's almost invisible on the lowest levels, but all others are unusable for me. FWIW I don't see flickering on any brightness level on my pandoras.
This is because of the PWM Display. The darker it is, the more it's flickering.
- touchscreen is unusable on the edges. With dead nubs it makes some
UI elements inoperable
Interesting. Mine is a little harder on the edges but I can use it. And my Display does not sit perfectly in the housing, so it moves a little when pressing the edges. What do you mean with unusabe. Does it not react, is it too hard to press or does it click elsewhere on the screen?
Most often clicks elsewhere, several centimeters to the screen center direction. With a lot of force the cursor goes close to the desired location, but by then it has already "clicked" something unwanted some distance away.
Gražvydas
-
aTc -
Grazvydas Ignotas -
H. Nikolaus Schaller -
Michael Mrozek -
Nino Bock