New Life for Old Tablets

As a techie, I have collected a number of tablets over the years.  There's a couple of very senior Pandigital Novels (Android 1.5), a middle-aged Kobo monochrome e-reader with wi-fi (non-functional due to an auto update from Kobo that was buggy, but apparently recoverable, when I have time...), a 7 inch Chinese tablet ("Diverseway MID7007" )running Android V4.2.2, and my main tablet, a 2012-era Samsung Galaxy Tab 10.1 .  (not counting the cast off older smartphones I have accumulated, a few of which run early Android versions, and some early iPhones...)

Fig 1- About Page of my Samsung Galaxy Tab 10.1, Pre Update

Google Crashes Tablets...
However, earlier this year, the Galaxy started to show frequent crash error messages from various Google Play apps, and the Google Browser would crash often on websites with complex page components (CBC.CA was a big problem, but far from the only one).  The Firefox Browser also had a lot of trouble with complex pages.  This was making the tablet unpleasant to use for news feeds, and other uses.

So began my search for a fix.  The tablet has reasonable hardware (ArmV7 dual core 32b cpu, 1Ghz, 722MB reported RAM (likely an actual 1GB..?) , 32GB internal storage), good display, wifi, bluetooth, various sensors, GPS and excellent battery life.  The OS was at Android V4.0.4 (ICS), Samsung's last official update for this tablet model.

Emphasis on Due Diligence Research...
Some online reading identified:
1- a lot of activity noted on multiple websites, regarding Android updates for this model.  Much discussion around updates from V3 and V4.0 to:  V4.1, 4.2, 4.4, 5.0, 5.1, and even a bit of work on  V6 and V7!  Multiple sources / groups identified as involved, but most common references are to:  the Android Open Source Project (AOSP), a fork called AOKP, and the CyanogenMod CM series of Android updates.  The CyanogenMod CM series became LineAge OS series last year.  The LineAge OS series officially doesn't list any updates going back more than a few years.
2- The likely cause of Google Apps failures (google's upgrades to NEON instruction set, with no support for older cpu sets), and some likely strategies to overcome this (rollback to earlier Google apps versions, ways to prevent auto-updates, and apparently kernel? updates to simulate the NEON instruction set components otherwise missing.)
3- safe and effective procedures to perform the OS update, using tools like TWRP, CWM, Odin3...

Fig 2- AOSP Android 5.1.1 Lollipop Update Thread

The Direction Forward...
So the direction forward seemed clear.  I elected to update to an Unofficial AOSP-based Android 5.1.1 Lollipop, using TWRP and Odin3.  There is a huge amount of discussion available about this update, esp. on the xda-developers website.  This work was done / led by senior developer "decatf", for whom I have incredible respect, given not only the excellence of his work, but his extensive involvement and support of those who asked for help along the way to using his work.  Many thanks!

The First Success...
Although I have extensive background in small computing hardware and software, this class of update flashing for Android devices was new to me.  I elected to start with one of the Pandigital Novels, since no big deal if I bricked it!  There is also extensive discussion of updates for this device, including Pandigital's interesting use of variations in Models to identify regional sales areas of the same device.  It's important to know what exact model you are going to update, and most of the discussion evolved around US model #s, rather than the Canadian model # on the device I have.  But this soon got clarified, and I was able to identify a likely update candidate, and successfully update one of my Black PDNs from V1.5 to V2.1 !.  There are a few glitches, as yet unresolved, that prevent reliable operation of the Google Browser, but the likely cause is too little space in the OS partitions.  It's a known problem, with some documented fixes, so when there is time, I may look into this further, but not a priority now.  Otherwise, a very useful update, using xda-developer "terminander" 's V2.1 update, as documented on the thread "Android 2.1 on the original BPDN --- coming to a channel near you".  Again, many thanks!

Onward...
So, on to the real goal, that of updating my Galaxy Tab.  Gathering the selected components was straightforward.  It is important to use a correct Samsung USB Driver to communicate between Odin3 on my W10 PC, and the tablet, in it's Download mode.  I had installed an old version of Samsung Kies some years ago in support of an early cell phone, and forgot about it.  Installing the latest Samsung USB driver package seemed to cause some problems with Odin, but the underlying cause was never clear.  After multiple uninstalls, and re-installs of a couple of versions of the Driver, and lots of Reboots, and some analysis of my USB subsytem with the marvelous USB TreeView utility (part of the MS Driver Dev Kit, and supported and improved by Uwe Sieber), I was able to see the tablet's download connection in Odin!

The Samsung standard Download / Recovery Tool is useful and deceptively simple.  So simple, in fact, that no-one really bothers to clearly and correctly describe how to invoke it, and cause it to actually begin a USB download!!  After some twiddling and references to the many partial notes online about how to get the actual download to begin, wondering all the time if this was a USB driver issue, things finally came together, and the TWRP Recovery Utility (twrp2870-20150814-p4wifi.zip) began to download and install, with no further issues.

Fig 3- TWRP Running on my Galaxy Tab, Prior to Backup, and Updates.

Everything else was easy from this point on!  Be sure to use decatf's update to the AOSP 5.1.1 ROM file, from 20171009 . It worked great for me.  I also installed the Google Play program set in p75xx-gapps-L-7-17-15.zip, with no problems.
I now have an updated Galaxy Tab 10.1, running well, without the problems I had before, and with some additional capabilities, such as overclocking, I have yet to explore.
The updated Android has a different look to it, wrt V4.0.4 .  It is very familiar, since it tends to match the appearance of my Nexus 5 smartphone,  which runs Android V6.0.1 !

Fig 4- Galaxy Running 5.1.1 - Home Screen, Post Update

Fig 5- Galaxy About Page, Post Update.

3D Printing Example...

I acquired a Prusa i3 type 3D Printer kit late last year from ElectronicGeek.com (EG) (Montreal; great printer, good price compared to eBay import for same printer, and great customer service from EG, btw!) The printer works reasonably well as built; the learning curve for solving the problems that occasionally appear is not trivial, but I am making progress.

We decided to use PLA only until we have a very good reason to use something else. Although I have a heated aluminum bed that works well, it is not needed for PLA work so far. I use blue painters tape (from Home Depot) to cover the bed, and get mostly good adhesion, as long as I change the tape frequently (no more than half a dozen prints in the same place, otherwise adhesion starts to become unacceptable).

A recent print that turned out well, was a case for my recently acquired Electronic Device Tester. This device, the LCR-T3-H, is a very versatile Arduino-based tester that handles many different types of 2 and 3 terminal, active and passive components. I've included some photos of several types of components being tested. The particular device I bought is based on a public domain design that is very well documented here: https://www.mikrocontroller.net/articles/AVR_Transistortester .

The case I built is described on Thingiverse here: http://www.thingiverse.com/thing:694790 .

This design was straightforward to print in PLA (despite a small amount of warping from insufficient bed sticking). The pcb is a tight fit, and the display panel backlight connections stick out a small amount past the edge of the pcb, requiring that a small section of the side wall of the case be cut out to allow the pcb to fit in the case. Still works very well.

Top view of case, shows startup info. 

Back view, base removed. ATMEGA386 smt chip, 8MHz crystal, not much else!

Back of case is a tight fit, screws not really needed. Print looks good...

Testing a Cap. One button operation, auto power off, tests battery on power up.

Inductor test.  But very small inductance looks like a Resister...

PNP xistor. also does FETs, SCRs, Diodes, etc. SMT parts too.

3D Printing: First Object Success!!

As much as I would like to build one of these printers, just because it's neat, we thought we should learn more about process and uses first. A couple of visits to the HPL MakerSpace convinced us to start there. So I decided to print a solar panel holder for Roz' Little Library (to charge the batteries that run it's computer, of course!). Several days of learning and working with TinkerCAD design tool produced a very nice design, so I registered with the Library, and scheduled a couple of hours last night on one of their MakerBot Replicator 3D Printers. We are very pleased with the outcome, and will certainly try more. Total print time: 1 hour 45 minutes. Total cost: $1.90 .

The TinkerCad Design image

Printed frame with solar panel and wiring installed.

Printing underway, on the MakerBot Replicator+ at the HPL MakerSpace. Frame is printed upside down.

Arduino on Battery...

I've thoroughly enjoyed learning about, and using, small Arduino microcomputers.
My collection includes Nano's (5V, 16MHz, USB, Volt Reg, 328P, china clones) and Micro Pro's (both 3.3V and 5V versions, china clones).

But it is important to find applications for them.  A Little Library became an interest in our family when the grandkids discovered one in their neighbourhood, so we are soon to have one on our lawn.  It seemed reasonable to add a little light to the library to make it easier to use in the evenings, so a small battery powered, solar panel charged light was obtained for this purpose.  Seemed an excellent device; the lamp looks good, offers the equivalent of a 15W bulb at about 150mA, and has an 800mAh LiIon cell to run it.  The included little solar panel (3 x 5 inch) was naked, but a simple 3D printed holder took care of that (another story...)

But the light needed to come on only when the little doors to the library are open, and it is probably a good idea to add a little timer to check if the doors are left open, and turn off the the light to save the battery.  And we don't need to turn on the light if it is daylight outside, right?  And, since we added those little door switches, we should probably keep track of how busy our Little Library is...  And maybe we should report some this data, along with monitoring the battery charging and voltage, somewhere more convenient, perhaps with a radio data link....  So now we have progressed a long way from the little power switch that comes with the original light system...

Wow!! An excellent application for a little Arduino and a few other goodies!!

The interesting catch here is that the Little Library sits at the edge of the street, far away from the usual power sources.  But an Arduino doesn't use much power, and the solar panel should keep that little battery charged; it says so right in the marketing literature.  So we proceeded to build a little interface, to hold a Nano, and some interface circuitry to read switches and voltages, and control the light, and connect to a nice little data radio system running at 2.4GHz. We also added a couple of voltage regulators; a 5V Booster to ensure 5V to the Nano, and a 3.3V regulator to ensure good voltage to the radio.  We got most everything working, then thought it might be useful to take some measurements.  It's not wise to run a LiIon cell down too low, after all...

Well, the electronics I added, minus the radio, draws about 40mA, and if the sun isn't out, the solar panel only supplies about 5mA charge current!!  And the lamp isn't even on yet!!  More work needs to be done!

There is a lot of information available online concerning the use of the Atmel 328P low power, or Sleep modes, and a number of very good Arduino IDE Libraries exist to make it easy to use them.  One confusing aspect of some of the Sleep modes seems to be how long it takes for the 328P uC to Wake Up after being in Sleep mode.  Not a lot of info available, and what there is seems unclear.  Suggestions range from a uS to 65mS+!!!.  Since I am running some contact debounce and voltage filtering logic on a time base presently set to 5mS, It is important to know what is really happening. So I did a little testing, to determine this, and also to see what power savings were possible with my Nano, even though the USB and V Regulator chips have no sleep mode.

The test routine I used is very simple:

#include <Sleep_n0m1.h>
//  Test startup delay for various sleep modes.
// Use Sleep_n0m1  to provide 15mS sleep periods, set, then reset an output bit, then loop.
// measure sleep interval with scope...
Sleep sleep;
unsigned long sleepTime; //how long you want the arduino to sleep
void setup() {
   sleepTime = 15; //set sleep time in ms, max sleep time is 49.7 days
    pinMode(6, OUTPUT);  // pulse to monitor sleep time.
    digitalWrite(6, 0);  // ensure bit is off to start   
}
void loop() {
/* modes of sleep
   SLEEP_MODE_IDLE
   SLEEP_MODE_ADC
   SLEEP_MODE_PWR_SAVE
   SLEEP_MODE_EXT_STANDBY
   SLEEP_MODE_STANDBY
   SLEEP_MODE_PWR_DOWN
   */
  sleep.pwrDownMode(); //set sleep mode
  sleep.sleepDelay(sleepTime); //sleep for: sleepTime  (use delay(15) instead when not sleeping)
//  sleep ends here.  Pulse output bit quickly (about 4uS)
digitalWrite(6, 1);
digitalWrite(6, 0);
}

With this and my scope (Hantek 6022BE DSO), and a meter to measure current draw to the Nano, I got some very interesting results, which might be of use to others:

Sleep Mode:                Loop Time:    mA @ 5V:     mA @ 4.2V
None [use Delay(19)]   19.0mS            21.6                13.5
Idle                               19.0mS           13.7                  8.4
Standby                        18.9mS            7.0                   5.4
Power Down                 19.9mS           6.6                   5.1

Notes:
- Loop time differences of 18.9 vs 19.0 prob. due to accuracy of cursor readings on my DSO
- Power Down mode saves a bit more power, but adds 1.0mS to wake up times
- supply V = 4.2V was also tested, to estimate savings on direct LiIon cell voltage
- Loop time was unchanged when supply V changed.
- using a nominal sleep duration of 15mS on this particular Nano results in almost 19mS of actual sleep time. Since my reading suggests that other sleep mode wake up times, due to hardware, are very very small, this must be due to a substantially different WDT oscillator frequency, which was not affected by supply V.
- the data above suggests that the 328P in the Nano is configured for a "Full Swing Crystal Oscillator Clock", which prevents the CPU from running for 16K clock cycles after startup of the oscillator.  At 16MHz, this will be about 1mS, the added amount in the Power Down sleep mode.
- the no sleep mode case used a Delay function, set to match the sleep loop times, instead of a Sleep function.

A Mini Pro, running at 3.3V would allow additional savings, prob. under 1mA average consumption.  However, since my Library electronics includes a socket for a Nano, and the Mini Pro pinout is substantially different from a Nano, I will operate with the Nano, at 4.2V for a while.  If an additional power savings is needed, I can rewire the electronics to accept a Mini Pro.  I can also remove the 5V Booster (uses about 3mA idling, not included in these measurements ), and look at shutting off the 3.3V Regulator (another 3mA idling), if needed.

Hopefully real world edge of road install tests will show much higher solar panel charge currents on average, and worst case, sufficient to provide enough charge during the day to run the electronics for a 24 hr period...

Now back to my code rewrites, since the millisecond function, and the Bounce2 and SimpleTimer Libraries that depend on it, will no longer work in the Low Power Sleep World...

MS Mail confusion...

Email is an important part of our ability to communicate, stay in touch, do business, and more.  So it would seem that MS would provide stable, functional email clients for it's Windows OS, no?  Although I am comfortable with Linux and Android variants (among others), my everyday desktop PC is Windows based.  I am a fan of client email apps, partly to allow me some control over storage and back-up of enduring email threads.  Maybe it's my IT background, but I don't have complete confidence in "the cloud" to look after the security and privacy of everything.

In the beginning of my GUI-based email experience, there was Outlook Express.  A reasonable email client, and worked in a similar manner to the work-based full Outlook.  It ran for a long time, but then there was warnings of EOL, and occasional problems, and new problems, and many encouragements from MS to switch.  The client du jour was Windows Live Mail.  After some checking and testing, I switched.  Eventually, it worked in an acceptable manner, although not without lots of issues along the way.  But it had been stable for several years, and we had learned to get along.

Wash rinse, repeat...  Troubles started to appear with Live email.  Lost emails, synch problems, strange freezes, the need to restart the app, or the OS...  The warnings about EOL started to appear.  The switch to WIN10 didn't help.  The many encouragements from MS to switch again began, this time to Windows Mail, included with WIN10.  I resisted the approach for a while, but finally decided anything would be better than the Live Email problems.  So after doing some due diligence on this new Mail program, I switched....

Initially, it looked like just another learning curve.  What was wrong with the last mail user interface, that MS decided I had to experience a completely different one, not intuitive at all?  And, btw, what happened to that local storage method I liked so much?  Seems the only easy solution (??) was to move all those local nicely categorized emails back out to an email server!!

So I gradually got used to doing things the 'new' way, and we developed a moderately comfortable existence.

Then I discovered "Auto Capitalization"!!!  (something sent as all lower case, that needed to be used that way, got Capitalized!)  wtf?  I didn't ask for this, no other email client ever did this, and, afaik, there is no way to turn it off!!  (the suggestions in various blogs don't work, and a LOT of people are asking how....)

MS, you need to step up your act a bit here...