Canon iP4200 Printer - Failure & Repair...

 

  I bought my Canon iP4200 printer around 2007-08, a replacement for another Canon, the BJC-80 model.  The BJC is still in a box somewhere, sans a working print-head.  Its two main issues when working, were both head-related;

    1) Poor print resolution, thus unsuitable for printing photos.

    2) Replacement ink-cartridge cost.

 Enter the iP4200.  This was streets ahead of the BJC in almost every respect.  Its resolution was fantastic for the time, and super-cheap ink-refills were readily available from the get-go - what wasn't there to like!

 My brother had earlier bought the same model and had introduced me to it when it would no longer turn on.  The fix proved quick & simple -  a rectifier diode in the slot-in PSU module (a nice feature, I thought at the time!) had failed.

 Brief as this introduction to the iP4200 was, it was all the incentive needed for me to fork out for the same model when the BJC finally gave up the ghost.  It's been 16 years since the purchase, and I've never had a problem with it.  The print-head is still the original one, with no bad/blocked nozzles.  Yes, one excellent printer - until a few days ago anyway!

 After sitting unused for several months, when switched on, I found that the middle button's yellow light would flash eleven times, in a cyclical manner, and little else.  It turned out that according to Canon, this signified Error 5110: a 'Carriage Lift Mechanism Error'.  Fault-codes aside, there seems to be a real dearth of repair information for any Canon printer available online, never mind the stodgy old iP4200. That, or 'Google Search' continues to deteriorate.  [Note: after the fact/repair, I found that an actual service manual exists for the iP4200, which appears quite instructive, and which I'll link to here].

 So, with no pointers to get me started, I opted for just opening it up and having a look around.  Alas, nothing obvious seemed amiss.  So there it lay for a day, its innards exposed to all & sundry.  And the Sun!  In this environment, I accidentally discovered that when exposed to bright sunshine, the printer would work normally!  Long story short, I soon tracked down the faulty component, the 'Carriage Lift Sensor' (CN401).  Composed of both a light-source & light-detector, only the source-part had failed - and the reason, that with sufficient sunshine present, the light-detector side would trigger normally!  After fruitlessly searching online for a vendor of what was probably a long-obsolete part, rather than junk an otherwise perfectly good printer, I resolved to 'MacGyver' a solution if at all possible.

 Since I presumed that the employed light-source in question, was infrared, I figured the light-detector would be similarly oriented - a problem, as I possessed no IR LEDs of any description.  Testing with what I had available, namely, Red, Green, Yellow & White LEDs, I was elated to discover that pretty much any type would trigger the light-detector.  The only real considerations were that of, size, (very limited space is available), and power-limiting, (enough to trigger, but not to tax the original supply circuitry).  While the White LEDs seemed the most efficient, its 'size' excluded it from consideration, so limited my options to Red, Green or Yellow LEDs.  Surprisingly, the Red light triggered the most reliably, while drawing the least current - a paltry 1-2mA, using a 1k current limiting resistor.

 As can probably be seen from the photos, the LED is positioned alongside the original sensor and must be 'aimed' at the light-detector on the other side in order to effect the greatest illumination possible.

Bluetooth Headsets Battery-life Longevity...

     Damn, 1st post of 2023 but almost half way into March already - where does the time go!

    Anyway, this will be a quick-one, more an observation really.  I have a penchant for bitching about BT pairing performance, particularly with Linux, and imo, with good reason.  I have three BT headsets, and they've all exhibited problems connecting reliably.  I list them here by date of purchase;

    MPow Phantom.

    Silvercrest SKHK 40 C1.

    Anker Life Q30.

     I've already posted about the Anker headset, and how flabbergasted I was on testing it, to discover its extraordinarily long run-time - namely, over 77hrs of use on a single charge, whereas, its official expected runtime is 60hrs.  This recently got me thinking about the other two headset's run-times, so I decided that some tests were in order.

    Specifically, after making sure each headset's battery was completely exhausted, each was charged and used 'normally', ie. staggered-usage, listening to ebooks/music/podcasts etc. for periods of around 4 to 10hrs on consecutive days, noting the times, and at a comfortable listening volume, until they powered themselves off.  It should be superfluous to add that even though all three have a 3.5mm input jack for corded usage, all listening was done over Bluetooth.

    I did this twice for the Mpow, bought on Amazon in 2015, so it's the oldest and has received the most abuse.  It also has the oldest BT version - v4.0.  I was staggered to note times of 25hrs & 27hrs runtime from it, particularly since its stated runtime-usage is listed at just 10-12hrs max.

    The Silvercrest was Aldi/Lidl derived, at least 4 years old and has received moderate usage.  I haven't been able to find an official expected-runtime for it, but was equally impressed to discover that it provided a listening time of 32hrs before powering itself off.

    So my question, how are my listening-times so much greater than what's claimed, even by the manufacturers themselves?  The ancient Mpow for example, still has more than twice their claimed runtime, despite having already provided at least several hundreds of hours of usage.  At a guess, it would appear that there is some kind of 'regenerative' process in operation, where, when left to sit overnight, their Li-Ion batteries somehow partially recharge themselves.  Whatever the reason, I'm fascinated by the whole thing and might investigate this further.

NaturalReader 9 running on Linux Wine...

  The installation of Mint 17.3 Rosa, (Trusty), 64-bit, on an adjacent partition got me wondering if there were any performance improvements to be had when running Windoze app$ on Linux Wine 64-bit.  I was particularly interested to see how NaturalReader 9 fared.  As I've alluded to in past posts, I bought NR 6.6 way back in 2007 and qualified for upgrades up to NR 9 - or until I didn't - the NR download-link just went dead on me!

 My opinion of NR has always been, at best, luke-warm.  NR is basically a poorly implemented front-end for the AT&T text-to-speech engine.  An apples-to-oranges comparison might be with one of my favourite M$ apps, Wavepad, which similarly, is a front-end for the excellent 'ffmpeg' command-line media tool.  Except that Wavepad is an order of magnitude better programmed!  NR's annoyances I've already commented on in the past, but to its credit, when running on a Windows box, all of the options available on the 'Standard' version (which I bought), do work.

 Which is not the case with Linux Wine.  In fact, NR 6.6 was the only NR I ever managed to get running with Wine, and barely at that.  It would load, and I could play back audio from text in its editor.  Occasionally, it would allow me to save small text-to-audio files as WAV's but never as compressed mp3 or ogg files.  NR 9 on the other hand proved a complete disaster.  I never even managed to get it to install & run, so  was limited to running it on a Windows computer, or from within Virtualbox - both tedious affairs.  So, that's literally 15 years of masochistic involvement with NR & Linux Wine I've endured thus far!

 Fast-forward to today.  While trying to formulate yet another plan to get NR 9 running on Wine, I happened across online, the 'ppa' of a more recent version of Wine, v1.8 versus the ancient v1.62 I've been using for more than a decade.  Up until that 'discovery', I had always assumed that given Mint 17.3's EOL status, newer ppa's had long ago gone off-line - apparently not!  That revelation was followed in short order by yet another find - an even more recent Wine ppa that included 'Trusty' support, this time sporting version 4.0!!!  Within the space of 30min, I had Wine 4 installed and the fun began.

 Or more of the same, take your pick.  On the one hand, NR 9 for the first time, installed & ran.  On the other, the same problem that had blighted NR 6.6, was present with NR 9 as well - it could not detect any 'voices', so no audio play-back was possible!  When initially installed, this horrible software assumes that all of the essentials it requires to operate, were previously installed.  It is only when the program is run, that it realises its mistake, and issues the vague warning about the 'missing voices', but nothing specific that might help correct the issue.

 The dilemma I've faced for more than a decade is, what exactly needs to be installed in order to enable these damn voices?

 This is where I finally made some progress.  'SpeechSDK', a M$ library installable through 'Winetricks', was always conspicuous as a requirement.  And with NR 6.6, once installed, it usually provided the missing voices - though not always - it was temperamental!  But the voices were always missing with NR 9.  After hours of searching, I made the enlightening discovery that 'SpeechSDK' was a '32-bit-only' package - only supporting 32-bit OS's up to WinXP.  Yet, despite this, it would still install on a Wine's 64-bit emulation of a 64-bit Windows OS - it just wouldn't work!  Maddening!!!  The next 'solution' I learnt, was to create a new 32-bit Wine 'Profile', set the OS type as say, Win XP, install SpeechSDK followed by NR 9, and everything would 'just work'.  Except it didn't...

 When it was appearing that installing Mint 17.3 64-bit had been a huge mistake, I eventually hit on a Winetricks-provided solution that worked.

1)    Through 'Wine Configure', set 'Windows version' as 'Windows 2000'.

2)    Create a 32-bit Wine Profile.

3)    Remove 'Mono' if installed (otherwise prevents NET 2.0 install).

4)    Install NET 2.0 (otherwise NR crashes during install).

5)    Install Richedit 3.0 (otherwise manual file-splits painfully slow).

6)    Install SpeechSDK.

7)    Install NR 9.

 Sorted!  'sapi' it turns out was Microsoft's answer to voices for 64-bit machines and is a tiny part of a relatively massive 550MB Service Pack Upgrade for Win7.  On the face of it, this shouldn't work either,  given we're working with a 32-bit Wine Profile, but it does.  All of this of course would have been unnecessary had the crappy NR software checked for missing libraries at installation time and provided what was missing.

 But alas, there's no happy endings where NR is concerned.  I found that with NR 9, I still cannot save converted audio files as mp3, and for the most part, as ogg files either - specifically, with 'normal' settings selected, ogg encoding doesn't work, but with an 'Advanced settings/Customize' option that encodes a stereo ogg-file, encoding works.  This however, is unsatisfactory for 2 reasons; 1) the TTS engine can only produce monaural speech files, and 2) encoding as stereo will double the size of the ogg file that's produced - so my audio-book archives would be twice the size necessary.  What does now seem to work properly is saving as WAV files.  I've just created an entire audio-book this way without a hitch.

 After spending further hours of searching for a solution to the mp3/ogg dilemma, I've come to the conclusion that there isn't one.  NR uses the standard 'lame_enc.dll' for its mp3 encoding.  Apart from it being a relatively ancient single-thread encode version, it works perfectly when run natively on Windows.  It just won't run at all on Wine.  I can only conclude that the idiot(s) that programmed NR, are passing parameters to the encoder dlls in a non-standard way.  'foobar2000', the excellent & free M$ media player employs the same encoders and it works perfectly.  To pour salt in the wound, I recently came across another piece of TTS software - TextAloud.  As luck would have it, this works perfectly - it includes & installs if necessary, the M$ TTS 'voices', so that playback, encoding etc. 'just works', out of the box.  Coming across this 15 years ago (had it existed) would have made my life so much easier.

Edit:

 I should have guessed that the somewhat ebullient tone of this post would prove fleeting & short-lived.  I presumed that the results above, other more up-to-date Linux distros, would also inherit - but this has proven not to be the case.

  Having tried & failed to get Chrome Remote Desktop working properly with ANY of the distros I have installed on various computers, I stumbled across another remote access piece of software from https://www.dwservice.net (DWS) that works fantastically on everything I've been able to try it with, namely Windoze, Linux & Raspberry, but it also works with Mac and a couple of others I can't remember.  Unfortunately, with Linux, it's a newish 64-bit OS only affair, but the performance of DWS convinced me that it was worth the effort of installing Mint 21.1 64-bit on my old laptop workhorse.  I may actually review this here at some stage, but for now, suffice it to say that it performed better than I expected it to, and DWS worked perfectly with it.

  Mint 21.1 'seemed' to work so well, I decided to install all of the 'essentials' I rely on, and this obviously included Natural Reader 9.  So imagine my disgust when after installing Wine 6 from the repositories, NR9 refused to run without crashing.  Indeed, it sometimes refused to even install, and despite trying everything possible, going as far as installing a pre-6 version binary of Wine, I'm back to square-one, with none of the above working with Wine 6.  Sickening.

 The fairly lengthy period of time I've spent trying (again) to crack this problem has only managed to highlight glaring problems with Mint 21.1 itself, the most damning of which are frequent system lock-ups - along the lines of 'kernel-panic' errors - and for no obvious reason.  In one instance, the power-off button itself had no effect, removal of the laptop's battery being the only solution to restart the OS.

 So, all in all, a demoralising experience.  NR9 when coupled with Wine is still the shitiest piece of software I've ever come across, and Mint 21.1 just doesn't make the grade as a permanent replacement for Mint 17.3 - so a double-whammy!

Edit1:

  I've edited the above 'How-to' slightly, casting aside 'sapi', and reverted back to using just 'SpeechSDK'.  Technically, while 'sapi' was a replacement for SpeechSDK, developed in readiness of the switch-over from 32 to 64-bit OS's (Win7 64-bit and up) it also works fine with the 32-bit version of Win7.  Since most M$ apps that I use worked fine running on Wine 4.0, I built a 4.0 binary from the Wine 4.0 source but on Mint 21.1 64-bit, fully expecting the same apps to run perfectly on it.  They didn't!  In fact, all that would run were parts of Wine itself, such as 'winecfg' & 'wine uninstall' - no Windows app would run!  After a bit of reading, I learned that Wine relies almost exclusively on 32-bit libraries in order to run Windows apps.  Given that practically all Linux OS's are now 64-bit in nature, this complicates matters out of all proportion - for a usable Wine setup, you have to somehow build it on a 64-bit system, but using 32-bit libraries!  According to the online How-to's, 'chroot' & 'lxc' are the two most viable options.  I've tried & failed using the 'lxc' method - I managed to create the 'lxc-container' ok, but couldn't for the life of me get it to 'Start'.  But even if I had succeeded in this 'first-step' of creating a build-container environment, I then have to locate all of the essential 32-bit Wine libraries.  The crazy thing is that there is no step-by-step information on how to do all of this online, that I've been able to find anyway.  So right now, I'm done with it.

 What I did manage to do was build from source, Wine 4.0 on my old 32-bit Trusty (pun intended) setup and have uploaded the binary to Google-drive, with the link provided here.  Remarkably, 'ogg' encoding now works perfectly!  This 'success'  prompted me to spend loads of more time trying to get 'mp3' encoding to work as well - unfortunately, all for naught.  Out of boredom, I also tried installing this on Mint 21.1 64-bit - knowing 'full-well' that it wouldn't allow it - but install it did, and without issue!  What it didn't do was run Windows apps or give any indication that Wine had even installed!!!  I felt like I was being toyed with...

 As the saying goes;

     "Those whom the Gods want to destroy, they first make mad". 

 Edit2:

    Yep, NR is proving to be the gift that keeps on giving.  I decided to set up a fresh Mint 17.3 32-bit on another PC, complete with NR.  Following the above list in order to get it going, I found it didn't work!!!  The issue turned out to be that the version of 'winetricks' used is of over-riding importance - I'm including it here for completeness.  Whatever magic this version manifests, it appears to be a necessary ingredient in getting this crap to run with voices enabled!  Although above I include creating a new Wine profile as a necessary step, it isn't really, so can be left out.

Aldi/Lidl LED Bulbs...

 Quick post this.  In the Incandescent Era, the replacing of light bulbs was expected & understood - metal glowing white-hot for months on end, could only be expected to end in a flash, right?  Then along came LED bulbs, whose longevity & efficiency, we were assured would deliver us from perpetual bulb-changing.

 Well, it appears that the Aldi & Lidl supermarkets around here didn't get the memo, cos' they keep flogging crap to me.  I bought & installed a handful of lightbulbs about a year ago, and in the past month, have had three of them fail, all within days of one another.  The cynic in me suggests that it's more likely to be a case of 'planned obsolescence' than the Bulb-god calling his children home.  They're not running hot either, the usual excuse that's trotted out.  So how can a bulb just warm to the touch, not last much longer then an incandescent that you could cook your dinner on?

 But for the fact that I possess an LED bulb that was bought 10-12 years ago, I'd be inclined to take their claimed longevity as a whole, with a pinch of salt.  [Edit: I tell a lie, just recalled and photo-snapped a second ancient but-still-working LED bulb that's in my possession,  and interestingly, both use identical LEDs]. Nevertheless, lots of the claims made by LED bulb manufacturers, rarely seem to be borne out in practice, in my experience anyway.

 Below are pics of the batch of Lidl bulbs that I bought, and that are failing as if to order.  Included as well is a pic[s] of the only [2] Chinese bulb[s], out of about a dozen, all from different manufacturers, that I got 10+ years ago.  The first has been running 6-10 hours, day in & day out, since I bought it.  The other, a low-lumens affair, also produces that horrible white-light, so has seen more limited usage - yet still orders of magnitude more than the 'Livarnolux' crap that Aldi/Lidl sold to me.

Edit1:

 With 3 blown bulbs knocking about & time to kill, I decided that a little investigatory work to determine the nature of the failures might be in order.  Although the symptoms leading up to each bulbs demise weren't identical, I figured that each must have had a common thread.  The first oddity I came across was that although physically identical, one of the bulbs weighed over THREE times that of the others (see pic) - so, being the piggy in the middle, marked it out as the first victim. [Oops, though all are made by Livarnolux, and look identical, this one has a different model number.  It is also rated at 12W, the others are 9.5W].

 

 

 Removing the globe itself was trivial, getting at its entrails proved anything but.  First discovery was that the LED's themselves appeared to be in perfect condition - this was always the weakest link in all of the half-dozen or so LED bulbs I've tried repairing in the past, the burned-out LED normally being easily discernible.

 

 With the LED module removed, the source of the extra weight was apparent - a big hunk of metal, clearly meant as a means of removing excess heat from the LED's.  This also suggests that this 'version_2-kludge' was an attempt to rectify a problem with a prior version - one that obviously failed!  But what they lacked in competence, they made up for in craftiness, attempting to ensure that no one else could fix it either - by encasing the entirety of the electronics in soft plastic!!! (see pic).

 

 

 Needless to say, removing it proved a real chore, first, just getting the PCB from the bulb's plastic housing without breaking stuff, next, having to chip away at the 'sarcophagus' encasing the electronics, and all without damaging components.  But endeavour to persevere I did, and after about 2 hours, had something that I could at least attempt fault-finding on.

 

 It didn't take long to trouble-shoot either, seeing as there's not that many components involved.  It turned out to be that an electrolytic capacitor had failed - 22uF in name only, was now just 4-and-change.  Replacing this with something half-way similar, had it up and running again (see pic).

 

 Of course, there's no putting the genie back in the bottle with this bulb, as I damn near had to destroy it to 'fix' it.  Note above that the measurements were made with only 60VAC applied.  This was partly because that was blinding enough, and partly because the electrolytic I replaced was rated at 50v versus the 63v of the blown one.  And also, when I wound it up to 100VAC for more than 10 seconds, something started to smoke - always a bad sign!  [Hmmm, further tinkering revealed that the 'smoke' was a result of the circuit hitting a 'dis-resonance' of sorts at specific voltages.  Increasing the AC voltage gradually via the auto-transformer as I did, above 60v, the current would increase rapidly, causing a current-limiting resistor to whimper.  However, jack the voltage right up above the 'un-sweet spot', or even straight to 240v mains potential, and everything ends up smelling of roses, the circuit being perfectly behaved (see pic).  Measured efficiency is only 75% for this 12w bulb - that's a whole 3 watts going abegging.  I'd have expected better from a deliberately expendable design such as this]. 

 

 With the failure of an electrolytic in a LED bulb, it gets you thinking.  By their very makeup, electrolytic capacitors WILL fail in time, it's guaranteed.  Google throws up numbers, that between 1,000 & 10,000 hours use, you should expect failure.  There is no way any of my blown bulbs had 10,000 hours of use.  I doubt the longest-lived had more than 5,000 hours, and I'm sure that one had less than 1,000 hours of light use.  And when they fail, it's not the LEDs that die, it's a shitty component that the text books will cheerfully tell you, is bound to fail!  Were they to use tantalum capacitors, Google talks about them lasting 20+ years.  Which will never happen, not in the 'throw-away society' we live in.  It just grinds my gears that a consumer item with fractional energy bills, is deliberately designed to last no longer than the incandescents it replaced. 

Edit2:

 Having some time to kill, I decided to investigate another of my dead Aldi/Lidl bulbs.

 Though the failed bulbs may look identical, this one shows that they are anything but.  This design screams 'CHEEAAAPPPP', a bean-counter's wet-dream - there's almost nothing in it!!!

  On the one hand, there's elegance in its simplicity.  The PCB is comprised of a current-limiting resistor, a bridge-rectifier and a reservoir capacitor, that's it!  This high voltage DC (300V approx) is applied directly to the equally-simple LED panel, made up of LEDs, a current regulating I.C, and a handful of resistors.  All of the LEDs are paired, connected in parallel, then each successive pair connected in series.  Given that 300VDC is powering this string of LEDs, they are atypical LEDs, having large voltage drops, which curiously, are not the same - the first LED-pair's voltage-drop is around 15v, the next pair in the string is around 30v, which continues similarly to the end of the string.

 This is also the Achilles heel of the bulb - one faulty LED-pair and you're in the dark!  Although none of the LEDs are visibly damaged, when I apply the turn-on voltage to some of the pairs, their brightness changes erratically.  I guess designing LEDs with such high voltage-drops is still in the development stage!

 On the other hand, there's nothing fixable with a design such as this.  The other bulb pictured above is a delight in comparison.  Hell, this bulb has only half the LEDs, but the same Lumens-rating.  True, it has a marginally lower power-rating (9.5W versus 12W) but the LEDs must still run much hotter, especially when you consider how flimsy the aluminum heat-sink used is - one-third the weight, remember!!!

 I'm not surprised that a version_2 was called for. 

Kosan Clip-on Butane Regulators...

 It's that time of year, when the central heating alone just doesn't cut it.  So off I go, buy a new canister of gas, wheel out the much-despised Kingavon, only to discover that another Kosan gas regulator has decided to quit on me!

 Yep, that's three now, and at this rate, I'll be averaging one per canister.  And I'm not even joking, this is only the second gas refill with the last regulator Calor sent me (gratis) - so it literally lasted just one canister!!!

 In the hope of getting some traction with Calor, I recorded a short video, which is linked to above, of what I'm seeing with a full gas canister fitted.  Not so much with getting another free regulator from them - I think they're lumbered with honouring the 5-year warranty on the last one they forced me into buying - but getting someone there to at least consider changing regulator suppliers.  These Kosangas regulators are garbage.

 So bad in fact, that I finally decided to bite the bullet and try and figure out what's causing all these failures.  Given the dearth of findable information available online about any of this, but faulty regulators aplenty, the only viable option was to try opening one up and having a looksie.

 These regulators are definitely designed as 'non-serviceable' items, but with a little finesse, along with a junior hacksaw, I soon got to look at its innards.  There really isn't much in them, basically a spring-loaded diaphragm that controls a gas inlet valve.  Unfortunately, its 'non-serviceable' nature also extends to the guts of the device, and I was unable to gain access to the inlet valve itself, as the white nylon control arm's pivot pin is of the interference-fit-mounted variety.  Though it's probably not obvious in the photos, the whole of the inside is covered in an oily residue, which I initially figured was gas-derived, but now I'm not so sure.  Maybe it's there by design, a gas-seal for the diaphragm for example.  The one thing that did stand out though, concerns what I've labelled the white nylon control arm.  It is controlled by the diaphragm, which is itself controlled by the gas pressure.  I found the control arm relatively easy to jam in the closed position, which prevents any gas from entering.  This is exacerbated by the unnecessary close tolerances employed in its construction, with barely 0.2mm clearance between it and the central metal nubbin that it swings about.  Thankfully, being nylon, so almost impossible to break easily, it was relatively easy to stress each of its arms enough, that it touching the sides during its travel, was no longer an issue.

 So, is this a 'fix'?  I don't think so.  Of the three regulators, the oldest two were completely useless, and allowed no gas at all through.  The 'new' one is already almost unusable, so appears to be following the same path of getting permanently choked off.  I'm left concluding that either the gas inlet design is inherently flawed, or the oily residue that builds up, eventually blocks the inlet, or at least locks the control arm in the valve-closed position.

 But while it may not be a 'fix', and definitely not a permanent solution, right now, the broken regulator is working again!  It's back together, everything held in place with electrical insulation tape, and 2-3 bars burning bright.  But in the few hours it's been running, it appears that it may be showing signs that the gas may be slowly getting choked off.  Time will tell...

If nothing else, it's been interesting.  Next step, contact Calor about a new & safer solution.  Unfortunately, I'm pretty sure it's going to be another of these Kosan travesties.  To head off that eventuality, I've recently discovered an old-type clip-on regulator that will be interesting to test.  As of now, I'm of the opinion that Calor has 1000's of these faulty (in-time) regulators and is knowingly flogging them to its customers.

 

Edit:

 I've been playing with the old Kosangas regulator I mentioned above for a day or two, and things are looking good.

...well, maybe not the regulator itself, which clearly has seen better days, but the prospect of a resolution may be in the offing!  Yeah, despite its age, it's still working perfectly.  Bear in mind, while the brand-spanking new-design Kosan regulators also worked perfectly in the beginning - all 3 of them - they all effectively died after just a couple of gas-refills.  Whereas, this old Kosan(gas) design is still going strong, no doubt, having had already regulated a lot of gas in its day.

 I videoed the old regulator in operation here.  However the flame-colours look completely washed out in 'normal' artificial light, don't know why.  Suffice it to say, the old regulator performed admirably.

Alkaline Vs NiMH Battery Comparison...

  One of my first blog posts here, nearly 10 years ago now, questioned the veracity of Alkaline battery manufacturer's claims.  I suggested at the time that us rustics were being fed a line of baloney regarding both Alkaline battery capacities & their oft-touted performance under heavy loads.  I also hinted back then that I'd test the claims, 'when time allowed'.  Well, here it is, Testing...

  First a note about my setup.  Above are the 3 electronic-loads that I have at my disposal. The 'green' one, my first purchase, is capable of providing 60W of loading, whereas the other 2 'black' ZKE loads manage only 30W.  This disadvantage is offset by the fact that the green load's minimum voltage/current settings are 1V/200mA, whereas the ZKE loads are 0.1V/50mA - therefore much more useful for lower voltage/current testing.  Unfortunately to their detriment,  the ZKE load's firmware sucks!  While the green load, during test, will cycle the display continuously, at 1 second intervals, between instantaneous, voltage, Amp-hours and Watt-hours, the ZKE loads must be switched manually to see what's going on - a real handicap when batteries are electrically connected via neo-magnets as you see here, as one's curiosity, followed by the slightest nudge to the test apparatus, can result in an intermittent disconnection, and a ruined test.  Maddening, when you're say, 30+ hours into a battery test - as happened with me here, as well as many times in the past!  Another huge plus for the green load is that when a test completes successfully, the results will be saved to non-volatile memory, which will then survive even complete power failure, and will be restored on power-up and can be stepped through manually by the user.

  Hardware-wise, the ZKE loads are also sub-standard.  While both load-types are fan-cooled, only the green tester uses variable fan-speed cooling, dependent on the applied load - unbelievably, the ZKE load's fan will ramp up to full speed and remain there, irrespective of the load being provided, for the entirety of the test.  In fact, when I got the first ZKE load, I presumed it was faulty because of this.  What was much more worrying however, was that even during a 30W test, the fan speed would vary erratically, going from full speed to on occasion, stopping entirely!  Thinking that this was down to a firmware bug, I sent a video (link here) of this behaviour to the Seller (and manufacturer) of the electronic load, and got another one sent to me, gratis - the only reason I have 2 of them!  I was not impressed on powering up the replacement to discover that the 'full-speed always' thing was the rule, not the exception!  The final insult was delivered not more than 200 hours later (test-wise), when the fan on the replacement load also failed!  Evidentially, the manufacturer opted for the cheapest fans possible, which employ dirt-cheap 'sleeve bearings', and from what I've read, are a complete no-no for fans that need to be mounted horizontally.   What's particularly perplexing is that as I type this, the exact same ZKE load is for sale on Aliexpress for between $40-$50 - that's literally twice what I paid for my one, 4-5 years ago.  Whereas the identical green load is also available on Aliexpress right now, but for between $18-$20 - exactly what I paid for it 5-6 years ago!  Makes no sense.  But (as always) I digress...

Batteries in play.

Alkaline Aldi Activ Energy (AA, AAA) - all well-within their expiry dates.

Nickel Metal Hydride battery: Panasonic Eneloop Pro (AA)

Generic 'Tronic' NIMH Aldi Rechargable (AAA)

  First off, I did an apples-to-apples comparison between the loads in order to convince myself that the (suspect) ZKE load's test-results were accurate (see pic).  I checked both load-types using the same Aldi Tronic AAA NiMH battery, and employing the same voltage cut-off/current settings.  In practice, I did a lot more than this, comparing both Eneloop & Eneloop Pro AA batteries, but the AA/AAA results will suffice here.  The Cut-off voltage used was the 'non-standard' (for NiMH) 1.0V and Load-currents of both 200mA & 500mA gave results that didn't vary appreciably between electronic loads.  These tests were enough for me to warrant proceeding, sacrificing a few Alkalines in the interest of curiosity, if not science.

  Given the relatively huge 200mA 'lowest' current that can be set with the green load, coupled with its 'above-standard' test-complete voltage of 1V, I decided to confine all my testing to the ZKE load.

 

  My first test of an Alkaline AA @ 200mA with a cut-off voltage of 0.9v resulted in a tested capacity of just over 2000mAh, which I found disappointing, and reckoned the poor result was down to what I considered the large (for Alkalines) current draw.  This test also highlighted a[nother?] firmware bug in the ZKE - notice above how the mAh and mWh readings for the Alkaline AA test are identical, though try as I might, I have been unable to reproduce the problem!  Anyway, to test my Current hypothesis, a second alkaline AA was tested, this time at a much higher 500mA current draw.  Confirmation however wasn't forthcoming, as the battery performed surprisingly well, indicative perhaps that alkalines aren't as awful under load as I had presumed.  Unsurprisingly, it delivered marginally less than battery 1's 2000mAh.  I then decided to test a third at the minimum-allowable 50mA current-draw, a decision that proved to be bone-headed, as this quadrupled the test-time to about 40 hours.  Three-quarters of the way through, I 'nudged' my test setup while checking the current values, resulting in one prematurely terminated test.  Grrrr, infuriating.

Finally, some Aldi/Lidl AAA battery testing.

 As can be seen below, the old, well-used NiMH battery outperformed the new, unused Alkaline by an appreciable margin, itself a surprise, given my past experience with 'Tronic' batteries - basically, they've never provided their claimed capacities, even when new (1000mAh in this instance), generally deteriorating rapidly over time, before failing entirely.

 So, what have I learned from this?  First off, the capacities of 'one-shot' alkaline batteries do not seem to appreciably exceed that of 'quality' NiMH batteries.  In fact, they may not even approach Premier NiMH battery capacities - my Eneloop Pro batteries, ordered through Aliexpress, to me, have always seemed 'suspect' - they have NEVER been seen to provide their stated Minimum capacities, namely 2500mAh, all 4 instead managing just marginally over 2000mAh.  Whereas my Standard Eneloop batteries, ordered through Amazon, performed to specification from the get-go, delivering (when new) the advertised minimum capacity of 1900mAh.  But I've whined on about this in an earlier post, so 'nuff said!

 Before this, I figured alkaline's 'edge' must be in their higher 'nominal' voltage - 1.5v versus NiMH's 1.2v.  Surely, I thought, this 20% higher voltage would deliver 20% higher capacities, when measured in mWh.  Not the case as far as I can see from the testing that I've done.  In fact, this higher-voltage 'advantage' would seem to me an artificial one, imposed on us by the battery & electronics manufacturers.  A good example of electronic goods that almost demand alkalines are cheap LED torches.  With LED's fixed voltage-drop, NiMH batteries manage to provide only a fraction of 'useful light' time that their alkaline compatriots provide - despite still retaining much of their initial charge 'when the lights go out!".

 Summing up.  I'm more convinced than ever that alkaline batteries are a rip-off, and in no way represent value for money.  This is particularly evident when it comes to powering heavy loads - something that manufacturers often cite as being their forte, particularly around Christmas time.  Even were we to agree that one alkaline costs perhaps a fifth that of its NiMH compatriot, itself unlikely, their 'one-shot' nature would still see NiMH outlast them by at least 100 times.  In fact, the only true advantage alkalines appear to have over NiMH batteries is 'shelf-life', ie. the ability to retain charge, unused, over extended periods of time.  But even this advantage has seen continuous erosion as 'quality' batteries like Panasonic's Eneloop continue to improve - I think the newest generation retain more than 90% of their charge after a year.  Add to that, appliances like smoke-detectors, where alkalines were always the de-facto choice, must be seeing a decline in their use.  For example, I've got a few powered by both alkaline and NiMH 9v batteries, Soshines in the latter case.  The NiMH batteries seem to last just as long as the alkalines - so why continue to waste money in what to me seems to be a defunct technology?  One thing's certain, if we continue to buy them, the manufacturers will continue to churn them out.

Anker Soundcore Life Q30 Headphones...

  I bought these 'over-ear' headphones 9-10 months ago on Aliexpress, and they weren't cheap, costing $86 back then - right now they're selling for $98.  Up until a few days ago, I was an Anker fan-boy.  They performed admirably, being comfortable to wear, had a long battery life, great sound and effective noise cancelling.  Basically, as advertised - what wasn't there to like! - and my positive review on Aliexpress reflected this.

  However, a few days ago, I discovered a design flaw that has left me feeling rather peevish.  Two plastic 'clips', used to help couple the headband to the earpieces, have cracked, with chunks after falling off & now lost (see pics).  Having treated these headphones with 'kid-gloves' ever since I got them, I'm certain that it's not down to physical abuse.  The fact that the clips on both sides have cracks & pieces missing, is all the proof I need to show that it's a design issue.  Being a  mere 6mm, they can be seen to visibly flex whenever the earpieces are separated when being placed on head.  They are in no way strong enough to endure this for long -  I guarantee that anyone buying these, will experience the same problem in short order.

  I tried updating my Aliexpress review, only to discover that it's no longer there!  I've raised this point already in another post, the fact that Aliexpress Sellers (apparently) can just pull & resubmit their advert, wiping all customer reviews in the process.  Not only does this render the review process from the Buyer's perspective, pointless, it also forms a 'rinse & repeat' haven for Sellers of shoddy goods - place ad & sell until such time as negative reviews effect your profits, then pull ad, resubmit and repeat!  Shouldn't be allowed.  In contrast, Amazon purchases, a decade old, can still be edited by the Buyer.

  The only upside here is that I noticed the problem before either of the clips snapped off completely, so had the opportunity to apply a fix - basically, just a couple of miniature black cable-ties, tightened and secured with B7000 adhesive (see pic).  Not too hideous in appearance, with the added advantage that they 'point the way' when matching ear-to-earpiece.

  Incidentally, the B7000 is another recent Aliexpress purchase, that is not living up to the advertising.  It's not awful - turns out it's basically just a watery Evostick/Bostick-type glue, with a rather clever applicator, so easy to apply accurately.

  By the way, the Q30's claimed 60hrs(ANC Off) / 40hrs(ANC On) usage between charges is horseshit.  True, it lasts quite a bit, but you'd never see 60 hours.  It turns out that the ANC, while effective, is not spectacular, so a bit of a gimmick as far as I'm concerned.  As a result, I almost never have ANC (Active Noise Cancelling) switched on.  Same for  'Transparent' mode, which gives a bit of a boost to the external audio, so would impact the run-time as well.  Seeing as I'm posting this, I'll probably do a run-time test on the headphones and post my results here before long.  An easy claim to test would be Anker's 4hrs from a 5min charge.  Stay tuned.

Update.

 Looks like I'll be eating crow again.  Runtime tests complete and I must admit, I'm gob-smacked.  As a preliminary, while listening to music, audio-books, etc. I ran the Anker headphones until they powered off, then waited 24hrs, and did the same again - just to make sure that its battery had no significant charge remaining.

 First test was the easy one - Determine the listening time possible from a 5min charge.  Seeing as the Ankers don't come with a charger, the one I used had dual 2.1A USB outputs, which is a far greater charging current than the Ankers require (measured Max Current was 0.61A).   Being finicky, I regulated the charge-time precisely, using an electronic switch to switch the charger on/off - resulting in a charging period that was accurate to 1sec.

5min charge: ran for 3hrs 57 minutes.

 Wow, just 3min off the claimed 4hr listening time - I was impressed!  But it got even better;

Listening timed-sessions from fully-charged.

Session 1; 5hrs.
Session 2; 5hrs.
Session 3; 3hrs 10min.
Session 4; 5hrs 30min.
Session 5; 8hrs.
Session 6; 9hrs.
Session 7; 6hrs.
Session 8; 2hrs.
Session 9; 6hrs.
Session 10; 6hrs.
Session 11; 4hrs.
Session 12; 3hrs 30min.
Session 13; 5hrs.
Session 14; 5hrs.
Session 15; 4hrs.

Total time: 77hrs 10min.

 That I certainly did not expect, that's one extraordinary amount of listening-time between charges!!!

 Edit. 

 A quick update to highlight a MAJOR problem with the Anker headphones.  As can be seen from the photos below, the padding on both ear-pieces have split along the join-seams, exposing the foam inside.  These are critical, non-replaceable items.  Although I only have pics of the latest padding failure, its companion had split in a similar manner, but thanks to 'Super Glue', I caught it early, and it is at least usable again.  This time round, the split was more extensive, and after the photo-shoot below, was compounded when I tried repairing the damage - it split a full 180 degrees!  As a result, the final 'repair' is a bit of a mess, lots of glue evident, so it will probably be uncomfortable to wear.

 As it happens, identical 'splitting' occurred with the MPow headphones, though being smaller, proved infinitely easier to glue.

 So riddle me this, what good are headphones that are comfortable to wear, with superb battery life, have excellent sound & user options - but have cheap, irreplaceable ear-pads that WILL fail in a relatively short amount of time?

 Yep, not feeling so good about this purchase now.  Thank God for Super Glue though.  Without it, repairing this type of damage would be nigh impossible.