[Sergiu1337]

Cool, waiting for it .

Have a great weekend too!

Posted via CB10

[eywong]

Uh, this is unexpected. I'm currently trying to reproduce this bug.

Updated description:
Disconnected charger at 6:35 AM and closed BaSA. Launched BaSA at 8:46 AM and reconnected charger. Where did BaSA get that date and time?

I repeated my scenario this morning (at different times). I got the same, anomalous date and time. It is visible beneath the "import data" window. Also, no difference whether I import data or I defer import.

BaSA 0.9.0.2
Z10STL100-3/10.2.1.2228

[QtHelex]

Okay, it seems to getting there from the Headless Module (without importing since this value gets stored directly in the BaSA database) - but the User Interface part of BaSA itself doesn't overwrite this value. So the next time the app gets closed and reopened it shows again the value which was tracked from the headless module.

At least these are my current conclusions. I need to test a little bit more but I would say: good find, thank you

[bobo616]

Any update on why the latest update submitted on the 20th still isn't showing in BlackBerry world?

Posted via CB10

[QtHelex]

Any update on why the latest update submitted on the 20th still isn't showing in BlackBerry world?

There are sadly since the beginning of the year extreme long testing times for Headless Apps... at some apps more, at some less... I'm not sure why. Each update of my app Turbo Reader goes thru testing within 2 days, my Headless app ClipMan needs between 3 and 10 days and the last update for BaSA needed 6 days, the two updates before full 3 weeks. The next update (0.9.1) is waiting since the 20th of March for approval.
No success by contacting the developer support or by talking to a BlackBerry Developer Evangelists face to face. The Evangelist were also chanceless and got the same "brainless" text block reply as I got: headless apps will go thru rigorous performance testing before a approval.
Even for minimal bugfixes and when there were not a single Byte changed at the headless part of the app.

So, we have sadly to wait and see...

To make it worse, the amount of spare time went over here the past weeks nearly to zero or below, but I'm already working on this personal issue.

[bobo616]

Ok thanks for the update. I hope the personal issue improves. I didn't realise you made turbo reader as I love that app.

Posted via CB10

[QtHelex]

Ok thanks for the update. I hope the personal issue improves.

Thanks.

I didn't realise you made turbo reader as I love that app.

Great, I hope you have already left a good review at BlackBerry World.

[bobo616]

Thanks.


Great, I hope you have already left a good review at BlackBerry World.

Already done :-)

[eywong]

Can anyone explain this battery behavior. (See the timeline in the attached BaSA graphs.)

I fully charged the battery. I then unplugged the charger and I rebooted the phone. The battery level dropped from 100% to 59%. I rebooted several times. I pulled the battery once. I tried three different chargers. After I replugged the charger and left it plugged, the level remained at 59% and then it shot up to 100%.


Several hours after I unplugged the charger:

Z10STL100-3/10.2.1.2947
4500mAH battery

Update: I repeated the use case, 24 hours later. The battery level dropped from 100% to 92%. (I observed past reboots consumed 5% to 10% battery.)

[QtHelex]

Thanks a lot for the detailed posting. I haven't seen such a behaviour so far.

Z10STL100-3/10.2.1.2947
4500mAH battery

I guess we have here the root for the issue you have. The charger electronic in your Z10 is attuned to the original battery which has a lot less capacity. So my guess is that the electronic doesn't detect correctly the current % value and the charging process stops for the electronic suddenly as soon as the battery notifies "I'm fully charged" and the % value jumps to 100% as a logical result of a fully charged battery.

Update: I repeated the use case, 24 hours later. The battery level dropped from 100% to 92%. (I observed past reboots consumed 5% to 10% battery.)

This could be good news for you. Maybe the charger electronic is somehow learning how the big battery behaves. Or have you the big one already since ages? In this case it may be just by accident sometimes better, sometimes worse.

Could you post the outcome of the 3rd time you full charge the device and redo the procedute you described above?

[eywong]

Maybe the charger electronic is somehow learning how the big battery behaves. Or have you the big one already since ages?

The big battery is in service 24/7 since 8 Mar. (Maybe my phone is a slow learner. ) I have not "confused" my phone by swapping batteries..
Usual charge cycle: Charge to 100% while I sleep, unplug phone after I awake, and then I use it during the day. I might briefly plug it to my PC's USB during the day to transfer files, but I try to drain the battery until its level drops below 20% before I put it back on the main charger (spec output of 1.8 A).

So my guess is that the electronic doesn't detect correctly the current % value and the charging process stops for the electronic suddenly as soon as the battery notifies "I'm fully charged"

You may be correct. I consistently observe 100% indication by both BaSA and native Device Monitor, concurrent with BaSA notification of 100%. However, I now have a case of BaSA notification of 100%, but 100% seemingly is not yet achieved. (Not implying any BaSA error here.) See snap shots. (Disregard fully charged date/time, which may be incorrect with BaSA 0.9.0.2.)
Still charging ...

BaSA notification in Hub says 100% full, but the stats indicate that it is not fully charged.


Side note: BaSA and Device Monitor predict the exact same "time until full." However, their predictions of "time until empty" differ greatly at times, which may be due to their differing prediction methods/algorithms.

Update: here is a graph of the latest "full" charge.

Notice, however, the battery gets "fuller" when I leave the charger plugged: Average current = 0; average power = 0.


Conclusion: initially false notification of 100% battery level during charging; trickle charge tops up the battery to actual 100%. Maybe BaSA could notify the phone's user of this condition?

[eywong]

Here is my latest set of BaSA graphs of charging my phone's battery. They provide no new info from the previous sets. It is a cleaner charging scenario: hands-off from plugged to charger until unplugged from charger.

[QtHelex]

Thanks a lot for the detailed postings and the screenshots. I guess we have here indeed a small compatibility issue with the bigger battery whereas the last few screenshots are looking good in my opinion. I have myself often jumps from 98% to 100% within a second with the original battery.
The current and voltage values the charging electronic gets as a result of the chemical processes in the battery are just not that accurate.

May I ask how long your average stand by time is with the big battery?

[eywong]

The next update (0.9.1) is waiting since the 20th of March for approval.

BaSA 0.9.1.1 became available to me in BBW just today.

May I ask how long your average stand by time is with the big battery?

Just after the battery is fully charged, BaSA predicts 17 hours and Device Monitor predicts 13 hours. When I perform my usual activities on the phone, the battery level drops to 20% in about 14 hours.

[QtHelex]

BaSA 0.9.1.1 became available to me in BBW just today.

Yes, and here is the changelog:

• added a new setting to automatically import the Headless data at application startup

• added a new setting to display also the battery power chart at the active frame

Just a fast posting because I'm currently in a hurry. I will try to get back in touch with you tomorrow with some details about your difference for the estimate stand up time. Have a good night.

[eywong]

Here is an interesting new symptom on my phone (Z10STL100-3/10.2.1.2947) with 4500 mAH battery:
This graph shows normal activity during the day. At the time of the snap (about 01:43), it was also the end of my day, so I plugged the charger.

After several hours on the charger, the battery apparently attained 100% charge level at 03:55. Look at the graph of the last four hours of charging. (This snap was taken about 07:29.)

I unplugged the charger at 07:30. (This snap was taken about 08:38.)

And yet another snap about 12:54.

Conclusion: A single, erroneous report of 15% level (should have been 100%) confused the BaSA graph.

[QtHelex]

Conclusion: A single, erroneous report of 15% level (should have been 100%) confused the BaSA graph.

Yes, strange and totally unexpected. I also never seen such a 15% drop with the original battery. Because of this BaSA has issues drawing the graph the moment it happened.
The same issues has BaSA in case you're changing the time and date of your device. The drawing is optimized for performance in power and speed. In my opinion the most important aspect, it shouldn't drain the battery itself, but in cases unexpected "errors" in the tracked data appears it is unable to detect and filter those.
A decision which was made at one of the first concept charts for the graph drawing engine.

[QtHelex]

Just after the battery is fully charged, BaSA predicts 17 hours and Device Monitor predicts 13 hours. When I perform my usual activities on the phone, the battery level drops to 20% in about 14 hours.

Ah, I've totally forgetten to getting back in touch with you with more details and a reasoning why there is such a big difference. Regarding the "time to empty" calculation, I have no idea why the Device Monitor delivers here a different result. I'm doing this calculation not myself, it is a system internal function provided by BlackBerry:
https://developer.blackberry.com/nat..._to_empty.html

Sadly the calculation doesn't work very well. I guess because of this BlackBerry has created a new one for the Device Monitor. I have sadly no idea why they haven't simply changed or fixed the calculation at the battery.h function and used this one instead of creating a new one. At least the new one seems to work more accurate. But for the most cases it doesn't calculate exactly enough how long the battery may last. At least here it changes too often how I'm using my device. Sometimes I have it in my pocket for hours and just from one moment to the other I'm writing 20 or 30 BBM messages in 1 hour and put the device back in my pocket. The calculation algorythm can't know when and if I will use the device havily or not. So it is for me more accurate to look at the battery chart, see how steep the graph is from situation to situation and to watch carfully the power graph. This way I can gauge if it may last until I arrive at home with my current usage or if I should try to use it more carefully.

At least for me is the own expirience a lot more accurate compared to the plain time value.

[eywong]

I just installed BaSA version 0.9.2.1 from BlackBerry World.
Z10STL100-3/10.2.1.2947

Update: I just discovered "Device Monitor" in the overflow menu. A handy feature!

[QtHelex]

I just installed BaSA version 0.9.2.1 from BlackBerry World.
Z10STL100-3/10.2.1.2947

Yes, only a small bugfix release, not really worth a changelog. The next one with some new useful features is already in testing for BlackBerry World approval... but since headless apps are getting tested extensively this may need again some time.

Update: I just discovered "Device Monitor" in the overflow menu. A handy feature!

Thanks. I thought so, too. A good addition to get also information down to application level whereas BaSA performs a lot better on device and overall data.

[eywong]

Okay, it seems to getting there from the Headless Module (without importing since this value gets stored directly in the BaSA database) - but the User Interface part of BaSA itself doesn't overwrite this value. So the next time the app gets closed and reopened it shows again the value which was tracked from the headless module.

The issue seems to be resolved in version 0.9.2.1.

[eywong]

With version 0.9.2.1, I perceive slightly longer delays in switching from the minimized view to the 18h History Diagram.
For example, after I minimized BaSA, the Active Frame displayed

Two to three seconds later, the Active Frame then displayed

The first time I ran 0.9.2.1, I thought there might be a new BaSA feature because the History Diagram did not come up at all. After I closed and relaunched BaSA, it then behaved as I expected, except for this longer delay in switching to the History Diagram.
Also, after I reboot my phone, it can take five to six seconds for the very first switch. After that, switches seem to "settle" at 2 to 3 seconds.
I am not saying that anything needs to be fixed. Just reporting my observations and (mis)perceptions.
Z10STL100-3/10.2.1.2947

[Dave XII]

@dev can you add an option to save settings? This could be helpful if one decides to un-/reinstall your app.

Posted via CB10

[QtHelex]

@dev can you add an option to save settings? This could be helpful if one decides to un-/reinstall your app.

I have a export to *.csv at my 2-do-list. But nothing for the settings so far and I'm not sure about the import.
Is a export of the settings really that important?
For the data itself also for the import of exported data I see a clear demand. But really for the settings, too?

[Dave XII]

I have a export to *.csv at my 2-do-list. But nothing for the settings so far and I'm not sure about the import.
Is a export of the settings really that important?
For the data itself also for the import of exported data I see a clear demand. But really for the settings, too?

I didn't know about the complexity involved. For sure data export is more important.

Posted via CB10