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.