Pontis MP3 player

My first MP3 player was the very first Rio PMP 300, with whopping 32MB (note; megabytes, not gigabytes!) of memory. Even at lousy 128kbs it couldn't hold even single full CD's worth of music. Also it had to be connected to PC via parallel port, which always was a pain in the behind, especially since it's PC software pretty much sucked. Nevertheless it was infinitely better than portable cassette or CD players.

Come to think of it, I'm not sure what happened to my Rio actually. It might still be around somewhere, or maybe I've ditched it. I'm mildly interested on seeing what's inside it, although I'm pretty sure it offers no surprises (and most likely has been dissected to death multiple times already).

Later I have had several players, but I'm quite sure that the one I've used most is Pontis SP600 (I think this was the exact model). It had some internal memory and CF (CompactFlash) and SD card slots. The main reason for longevity was that it was pretty much best audio book player (for me) I had used so far - for example iPod required audiobooks to be in AAC format, which in my opinion was and simply is simply absurd and braindead requirement. Granted, overall Pontis was not that great, as you couldn't listen to, say, music and then continue with the book from where you left off, but as I used mine as audio book player exclusively, that was no issue.

Digging through drawers I happened to find it now, and since it's pretty much retired I decided to see what was inside (aside the CF card which still had last audiobook I listened on it)

Pontis used single AA battery (accepting also rechargeables which I used the most). I'm not sure what was the promised playback time but I remember always carrying at least two spare rechargeable NiMH batteries when going for longer walk or (bicycle) drive as current battery way too often became suddenly empty (and sometimes my first spare was already empty, d'oh...). Battery going empty shouldn't be a problem, but annoyingly when that happened the player didn't store the position within current file before turning off -- so you had to fast forward a long time (as the fast forward worked at rate of 10s per second or so). That is, unless if you hadn't paused every now and then (letting player turn itself off for inactivity, thus storing current location). And yet I consider this lesser PITA than dealing with mess of iTunes and AAC.

Remembering this frustration (and some discussion lately about a certain battery booster gadget) at eevblog I wanted to see how voltage Pontis could use and was pleasantly surprised. Pontis would only turn off when battery voltage dropped below 0.8 volts, using pretty much all juice that you could have in one. It wouldn't start up below 1.0 volts but I don't think that as a problem -- at that point battery is already fairly low so there's not much listening left anyway before change.

Since the point of turning off is that low, I actually suspect that player has some subtle bug in their low battery detection system that causes its regulator to turn off before the main MCU ever gets notified of the situation. Not very nice, and situation that I would have expected them to test and handle properly.

Current consumption was quite high though - at 1.6 volts it used 250mA when playing audio, and at 0.8 volts consumption was at 440mA. With these figures you'd be happy to get six hours of play time from you typical cheap AA battery, which I think is fairly close to my experience.

When off it still used about 50 microamps; while not a great figure, I consider it acceptable, especially considering it's age - quick search suggests this was released around 2004 or so.

Rear of the player. All screws holding it together were nicely accessible and after taking out card slot cover (orange plastic) it opened easily enough.

Circuit board on topside. Nothing too fancy. The display module is mounted on plastic stands, underneath there wasn't anything too interesting. On right side there's wheel/button (underneath PCB) and buttons.

One point of note is nice battery terminal attachment. Sorry for not having larger picture of those, but essentially there is a slot in the PCB at the contact point, through which the terminal is pressed and soldered in place. Way more rugged than your typical surface mount terminal.

I couldn't find any layer markings on PCB, and trying to see layer stack from edge wasn't easy either. I'd guess either 4- or 6-layer board; packing this much stuff that densely on 2-layer board might not be impossible, but it would be damn difficult. Even if this looks like highly integrated and packed solution, compared to current offerings this is actually very loosely packed PCB.

On bottom side there's main MCU TMS320Vc5416 a DSP processor that runs at 3,3 volts. Remember I said that player works with single AA battery? That is handled by boost converter near the battery using MAX1701. On quick glance the chip does have low battery signal, but somehow that isn't handled properly - or maybe it only activates when battery is already too low for safe power off.

Next to MCU is a flash chip. I don't remember if player had internal memory or if that is for software. Around the board there are also several 74-series chips; shift registers, multiplexers and such, most likely to make up limited pin numbers on MCU (flash and display both need fairly large amount of I/O)

USB interface has now-obsolete four-pin mini-B connector. USB communication goes through PCIUSBD12 chip so the main processor doesn't have to care about that. Actually, back then MCUs with built-in USB weren't that easy to get, especially if you wanted low(ish) power consumption, so this setup actually makes sense.

So nothing very surprising here really. Moving on...

Fixing a stuck Canon lens

(last time I had problems with this glass was when lens protector did its job)

I've been using my Canon EF-S 17-85mm lens (with image stabilizer) as my primary general purpose lens for a long time now. It wasn't cheap (if I recall correctly, around 800eur) but it has served me well. If you want to look for drawbacks, it is a bit large and heavy, but its usefulness as "good enough for almost any situation" (yet not perfect for any, really) glass overweighs that my far.

Lately zoom started "sticking". First it could be persuaded to loosen with some wiggling of zoom but lately it grew bad enough to be practically permanently at one position. Time to see what could be done. And apparently my google-fu was strong enough as first link was to video for fixing this very issue.

So, to work.

And all the photos that have this lens pictured are taken with Canon's 50mm EF lens. Really cheap (around 100 eur when I bought it years ago) but damn is it great - that is the lens I to use for most of the product shots I take. Still, photos taken here are taken with camera held in hands and with relatively bad lighting so blurriness and general lack of focus can be expected.

Flat flex cables, flat flex cables everywhere! You'll need to be extremely careful with those, as breaking them accidentally is very easy and repairing them is just about impossible.

That said, I have to marvel the system design of these lenses. All the electronics is on this single board, connected to motors and so on via those flex cables. One might wonder why they chose to use total of 4 different types flex connectors here (one at upper right opened by pulling small tabs on sides of flex out; two below it by opening "lever" type holder and rest are friction-locked; you'll just push the flex cable in it.

My guess would be that many of these flexes and connectors date back to earlier models; when some features were later added (like stabilization) they just added new type flex and suitable (cheapest?) connector for it, using older flexes/connectors for older features.

Other side of said board. Since there are inductors on board I'd guess there's switching regulator (or multiple regulators) on board, but none of the chips I looked are easily found on net, most being Canon's ASICs (except H-bridge motor driver, for focusing motor I guess) . No surprises there, really, and I wasn't feeling too adventurous so I returned to repair quite soon.

After some disassembly the culprit was reached. Three screws around the inner body had come loose, preventing normal operation of zoom mechanism. Tighten them and all works properly again. And then add some suitable glue (like loctite) to make sure they don't get loose again.

Note the small hair just above upside "85", lower and left from the indicated screw. When you got two dogs their hair is everywhere even when the dogs themselves aren't around. I had to remove several hairs from the lens body during the process, and I expect some are still in there - inner structures aren't sealed (even when lens is fully assembled, although it is relatively closed package then) so dust and hairs can get in way too easily. Not to mention this kind of projects.

First quick test photo after assembly. Everything still works, excellent! Some pars were yet to be replaced as you can see.

And all that remains now is to replace the protector glass. So about two hours of work saved me the cost of a new lens. Time well spent.

It's in A Safe Place

Well, damn. You know the drill - you get something expensive that you need only occasionally, so after use you put in A Safe Place. And then forget where that safe place is.

As it happens, the thing I put in A Safe Place this time happens to be my Photoshop CS4 package (along with DVD and product key) that I'd need now to install it again after I changed hard disk to my computer. So far I feel like I've looked everywhere and found nothing. Stupid of me not making a copy of those for safekeeping when I got them originally anyway...

While losing them might be a reason to upgrade to newer version for some people, two major things work against that;
1) It's damn expensive, and
2) Photoshop apparently is no longer available as standalone installation, there's only this "Creative Cloud" crap and there's annual extortion involved (yes, I'm pissed off enough to use that word now) -- every year you'll have to cough up more dough to keep using your paid-for software, which brings me back to point 1;
1) It's damn expensive over and over again.

Up yours, Adobe, I'd rather switch to Gimp for good if I can't find my copy of CS4.

And no, Elements doesn't cut it, I've tested it and idiots at Adobe changed every single keyboard shortcut from full Photoshop - if I have to re-learn the interface anyway, I'll pick the free one, TYMV. Also as I need image editors only for maybe ten hours a month or so the annual pricing gets way too expensive per hour.

Oh well, back to digging though every drawer and cabinet, again...

Edit, the next day: Finally found the damn packet, in same place as last time. I already had looked there but guess I somehow missed it the first time...

Wonder how that was done...

Like so many in my generation I was drawn to programming by games. No surprise there, really, since this was back at the dawn of home computers when Commodore 64, Sinclair Spectrum, MSX and others ruled the market (and later Amiga and Atari ST, and even later PCs). Despite being so simple these simple computers could produce wonderful graphics and sound (well, most of them at least...), so no wonder that many curious minds were drawn to them. They were all so simple to start with since they all came with some kind of Basic interpreter, yet so difficult to master since that would require delving into depths of assembly and mysteries of their respective chipsets.

But the games... While I had some attempts earlier, I think first game I really wanted to imitate was Ultima V (PC version) that I borrowed from a friend (and then immediately had to crack myself since I had to return the original disks quite soon - another introduction there...). At this point I already had only very rudimentary undertanding of basic of programming (with GW-Basic) and of the mysteries of graphics hardware but I tried. Somehow I still managed to get rid of the disk-based copy protection and finish the game, yet I didn't get very far making a copy of the game itself.

Attempts in creating something like Ultima still were my first real steps into world of programming, despite eventual failure. It didn't take long to grow out of basic and move on to Turbo Pascal (I did eventually release some simple games made with it too). And then later C/C++.

At some point (during Pascal years) I saw Second Reality. Back then I didn't have sufficient knowledge to understand how effects were made, but that didn't stop me from trying (and failing miserably of course, but that's how you learn --  "Damn, another way how you don't  do that...")

I really started learning C++ when I took my first real programming job, after first year in university. As so often happens, being full-time programmer tends to make hobby programming less fun so all side projects (including games) were kinda pushed aside for time being. And there they were for a long time. Never completely forgotten, though, I always had ideas. Like playing World of Warcraft made me wonder how to build server infrastructure for such a game (client? bah, not that interesting (to me), really). I have long documents on ideas and infrastructure needed. All unproven of course, without client there really is no point (and of course more important than the client would be interesting world to see via said client! Not that I don't have ideas, it's the creation of that world that is the problem -- lore, places, people and so on... Enormous amount of work.)

Not that I had to abandon all game-related ideas I had. Many of those ideas were built as minor parts of some work project or other (like some simple spheres that rotate and fade away while doing firmware upgrade on one product - one colleague told me that they had some fun watching it the first time, guessing how much work I put into them. I didn't have heart to tell them that it took maybe 30 minutes total, and it was mostly kind of side effect when first experimenting with the display module used on that product), but games they weren't.

But 3D, that has been an interest of mine for along time. Before entering workforce I did some experimental projects with DirectX 7 (that ought to tell you how old these projects were) and OpenGL (1.1 or so). Only now I have picked up enough interest again, and since I have -- shall we say -- philosophical objection on unportability of DirectX the OpenGL was quite natual choice.

At this point OpenGL was already on version 4 and I had absolutely no idea how the current graphics hardware worked -- all I knew was old fixed-function pipeline. I was used to throwing glBegins, glTriangles and all those around so I wasn't willing to let go of them -- mostly because I had so much already built on those, so I jumped on to OpenGL 2 that allowed some kind of hybrid approach - both data buffers drawn by hardware and old fixed function pipeline drawing on same frame buffer.

I admit now that this was a mistake that cost me a lot of wasted time, I should've jumped straight to modern OpenGL (3.3+), but ... well, you know how it is. You have something ready and aren't willing to give up and rewrite everything that easily.

It didn't take me long to run into a wall that way - I wanted to do something that the API just couldn't do, not with GL2. So after some more research I found out that OpenGL 3 supports what I need. Great. Except none of the old, so familiar, so easy fixed-function pipeline stuff would no longer work at all. Less great, as much of my editors were build on ability to control everything triangle by triangle and line by line; you know, hide something, highlight something and so on. 

So what can I do but bite the bullet. Rewrite everything. That part was not fun and took a lot of effort, but now I have everything up and running on OpenGL 3.3. (and no, I'm not too happy about different manufacturers GLSL compilers, but I did choose my poison...)

So back to the Second Reality I mentioned earlier. Looking at it now the effects there are (with perspective given by my current knowledge) fairly simple. Granted, doing all that with old hardware would take a lot of effort and micro-optimization, but still the principles are clear.

And the same curiosity that drove me back then still is there. As I am now a bit more familar with modern graphics hardware and many of the effects are done I find myself often wondering on the details when playing. How did they do this or that, or managed to do that effect there, or how to make that effect the fast enough.

Does this take away enjoyment? No. But it still is kinda funny to find myself trying to figure out how they did nice appreance of Geralt's armor or peasant's tunic during some of the long conversations.
  
Then I catch myself and smile. And think that might be something I'd like to use in my next project - which I am actually actively (well, kinda, hour a day or so) working on now.