My Vibe-Coding Venture...

    My introduction to a hands-on, AI experience, was provided by Ollama.  After the initial excitement of being able to communicate via the keyboard, with what was for all intents, a font of unlimited knowledge, hallucinations excepted, its limitations became apparent.  It's purely text-based, able to offer thought-provoking prose on a vast number of subjects, but not much else.  True, you can tell the LLM operating behind the scenes to do some coding for you, but you cannot submit your own code, or anything else for that matter.  There are add-ons are available, WebUI, being one example - a bad one in this instance, as it relies on Docker, so I never went down that road!

    Enter Unsloth Desktop.  This looked a far more rewarding LLM front-end, offering microphone input, coding (sand-boxed execution), Thinking, and most important, the ability to upload files!  Whereas Ollama is Terminal-based, Unsloth features a sleek GUI interface.  Those are the highlights, it's all uphill from here...

    ...and it's mostly down to my crummy hardware, which took ages to figure out!  From the get-go, it crashed constantly.  Ask a handful of questions, and by the tenth one, it'd freeze up.  I've only just discovered, within the last day or so, the underlying cause - yep, my hardware!  But thanks to Unsloth's comprehensive configurability setup, a fix was discovered - change the 'Compute back-end' from Vulkan to CPU, yes, that easy!  The downside is that a working LLM consumes significantly more power, from 80W up to 110W.  But no more crashes, which is the main consideration!

    Enter Vibe-coding.  With Unsloth finally running reliably, I figured it was time to check out this vibe-coding lark.  I wasn't expecting much to be honest, mainly because of the hardware situation (Intel 13th gen, i7, 16 core), which severely limits what LLM's qualify.  I had already tried a 27B parameter Qwen model, Qwen3.8-28B-GGUF, but it had proven unusably slow.  I ended up with the sickly runt of the litter, Gemma4-E2B-it-GGUF, chosen by Unsloth as the 'best-hope' choice that my meager hardware could handle.

    Which proved a disaster.  The token throughput proved pretty decent, about 5-6 per/sec, so usable for the small task I proposed - "vibe-code me a Linux app that could download the icecast stream directory, segregate them into user-selectable, Ogg, mp3 & Aac categories, before finally, playing a random stream from the selected category.  Easy-peezy, or so I thought!  The light-weight LLM proved hopeless - the number of times it came up with lines like, "this is the final, final version, guaranteed to work", almost had me screaming!  It would take one step forward, producing executable code, only to back-pedal and produce an unusable mess at the next attempt.  It was also about the time I started looking for pointers from Gemini 3.6 Flash.

    The first piece of advice I was given was that if I was looking for an easy vibe-coding starter experience, that starting by basing a media player on the SLD2 media player library, was not the way to go.  While it hadn't been my choice, I held my tongue, and told Gemini to carry on and tell me more!  And it was all downhill from then on!  It also was decided that it was going to be a terminal-based player, so not snazzy, but usable nonetheless.  The difference between these two LLM's is like the difference between night & day.  Gemma4 for instance, managed (at most) to successfully download the icecast stream directory, but it could go no further, mostly down to SDL2 issues.  Give the code produced by Gemma to Gemini, and Gemini could flawlessly edit it for further development.  Whereas every time I tried the opposite, Gemma would get hopelessly muddled.  Long story short, Gemini had a working player up & running in short order.  

    Gemini also is a pleasure to instruct, Gemma4 is a nightmare.  I kept waiting for Gemini to tell me that if I wanted any more coding done, I'd need to start buying tokens but it hasn't happened (yet), not even a prompt.  I had tried the free version of Claude a while back and the "Sign up for tokens to continue" command occurred after just a few questions, never mind coding an app.  Another thing that surprised me about Gemini was its self-introspection, its readiness to admit, without prompting, when it had been hallucinating.

    So overall, a pleasurable first vibe-coding experience.  You would need to be a real vibe-coding aficionado to try coding something complex, on a local setup with a slow computer - which, where LLM's are concerned, applies to about 95% of the hardware out there - the online, Gemini 3.6 Flash, is blazingly fast, and it still took 'us' hours to code this small application.  Despite Gemini's coding prowess, while it invariably produces executable code, it often takes it a couple of attempts to get something to work as requested - but these are super-fast revisions, and usually include an explanation on why the prior attempt failed, so insightful into the bargain.

    I still think of LLM's as some kind of magic - how 'predicting the next word' algorithms can do stuff like this will always be beyond me.   If anyone wants to see my first vibe-coded app in operation, you can download it from here.  Hint, preset your terminal's Row/Columns to 80/28, place the icecast_player10 executable in your home directory, and create a launcher script with your text editor, such as;

        #!/bin/bash

        cd ~/
        ./icecast_player10

    Save to your Desktop/Home directory/wherever, as 'ice_player', then make it executable;

        chmod +x ~/icecast_player10

That's it.  When ice_player is double-clicked, select the 'Run in terminal' option, and you're ready to be rocked!  

Edit:

    I've spent the last week (well, it feels like a week, a couple of days in actuality) trying & failing to get to grips with 'Vibe-coding' with small 'Coder' LLMs.  After receiving what seemed like glowing endorsements from Gemini, I first tried a 'tiny' 3B parameter Qwen model.  This was an absolute disaster.  I set it the task of adding a volume control to the existing Icecast code.  Not only did it fail to do so, it also failed to produce code that would compile.   I then asked it to scan the code it had just coded, for errors - it found loads.  Thing is, after giving them the once-over, Gemini concluded that these were all hallucinated, meaningless drivel, and despite his earlier prognostications, this was in fact typical of small Coder-type, low-parameter models!  Cowed, but not broken, I then decided that the Qwen2.5-Coder7B model was the way to go - a jump up from the 3B parameter model.

    Given how awful the 3B model has been, I wasn't expecting much, and was eventually proven right, but not before being tantalised with the possibility of progress.  The 7B model produced code that compiled - a huge advance in my eyes!  But it simultaneously broke code that had already worked (no audio) and was powerless to rectify the problem.  I eventually turned to DeepSeek on Android to provide a solution.  DeepSeek, like Gemini wasn't into 'trash-talking' these smaller, less-capable models either, stating that the bug could be easily missed by a seasoned human programmer, never mind 'another' low-brow LLM model - and again, to its credit, the buggy code compiled without errors.  So, while the subtle missing audio bug was resolved (in seconds!) by a much more capable LLM, I was gob-smacked to find on compiling the code, that the actual task set - the ability to alter the volume - didn't work either!  Sickening, so I moved on...

    But, as my hopes weren't yet dashed, I set '7B' a much simpler task - redirect all program generated user-messages to one particular area in the terminal window. 

    This proved a nightmare, and highlighted one of the most infuriating aspects of these less-capable LLMs - what passes to a human as a perfectly understandable request, is more or less, 'gobbledygook' to a low-IQ LLM.   For instance, I found the below request, perfectly reasonable...

    "Find attached file icecast_player11_Claude.cpp. Modify the code as follows; 1. Cache the message written to row 3, column 1 (user-feedback line) at startup, after the attempted refresh of icecast_dir.xml, and restore its contents whenever alternate user-feedback has been displayed there." 

  ...but it didn't have a clue!   Asking Claude how that request should be presented to my 'special' friend, it spat back the following;

 "You are editing a C++ program. The full source file is provided below. TASK Add a "user-feedback line cache" to the program. Make only the change described here. Do not refactor, rename, or reformat anything else. 

BACKGROUND The program has a user-feedback line on screen at row 3, column 1. Messages are written to that line during normal operation. 

REQUIRED BEHAVIOUR 

1. Add a global std::string variable named feedbackCache.

2. At startup, AFTER the attempted refresh/download of icecast_dir.xml has finished (whether it succeeded or failed), read whatever message was written to row 3, column 1 by that step and store it in feedbackCache.

3. Whenever any other code displays a different message on row 3, column 1, that message is temporary. After it has been shown, restore the line by re-displaying the contents of feedbackCache.

4. Implement this with two small helper functions: void saveFeedbackLine(const std::string& msg); void restoreFeedbackLine(); restoreFeedbackLine() must clear row 3 first, then print feedbackCache at row 3, column 1.

5. Do not cache the temporary messages themselves. Only the startup message is cached. 

CONSTRAINTS - Keep the existing coding style, includes, and function names. - Do not change any logic outside the places needed for this feature. - Do not remove or rewrite existing comments. 

OUTPUT FORMAT - First, list every place in the code where row 3, column 1 is written to. - Then show each modified function in full, with changed lines marked by a comment: // CHANGED - Then show any new functions or variables in full. - Do not output the entire file unless I ask for it. SOURCE FILE (icecast_player11_Claude.cpp): <paste the full contents of the file here>"

    The bizarre thing was, it worked!!!  By which I mean, it started producing code.  But, code that actually worked? - God no!!!  I eventually threw in the towel and asked Claude to do it for me - which it did, in about 30secs.  It also worked perfectly, first time, and is playing as I type!

    My takeaway from all of this? - online LLMs rock, but only when they're free, whereas, local model LLM's running on underpowered hardware are only a thing if you are a glutton for punishment!  I've learnt my lesson anyway!

    I'll attach the final, final version of icecast_player here.  Bare in mind that the Icecast streams directory server(s) frequently go down for extended periods, but as long as you have a 'populated' copy of 'icecast_dir.xml', you'll have plenty (13,000+) streams to listen to. 

 

Liitokala Li-ion 9V Repair...

    A fast bob & weave to what the odds predict will probably be my last successful repair before I return to my usual form of breaking stuff.   This little diversion involves a Liitokala 9V battery, and a poor wiring decision, made way back in the mists of time, that came back to haunt me.  The batteries in question were being used in my old detector, and as can be seen below, multiple batteries are needed to power this beastie.

 

 Two are used, in series, to power most of the electronics, while the third, labelled 'S' in the above pic, powers the speaker.  This somewhat complicated wiring setup needed to be routed appropriately, which is what the piece of vero-board, screwed to the battery compartment, aids in doing.  This setup worked perfectly for decades.  But if you look closely, you may notice that the three battery power leads are routed behind, and clamped in place, with the sliver of vero-board, courtesy of a few screws.  Also visible are the multiple soldered vero-board connections, that keep everything civilised.  What is not visible or obvious is that many of these soldered wires protrude through the holes, to the other side of the board.  Although all were trimmed, one, coupled with the clamping effect of the board, and in the fullness of time, still managed to skewer one of the battery leads, forming an intermittent dead short.

    But back to the battery.   Below is the battery PCB, with a replacement transistor fitted (bottom right) - that didn't work!  The original transistor had its identifier code burnt off of it (see pic), so I was working in the dark, and with limited options - all of my 'replacement parts' coming from scrap PCBs.

  

        Fortunately, I got lucky and found a transistor (pic below) that worked!

    More or less anyway.  The On-resistance of the transistor seems to be a bit higher than the original, which results in more of a voltage drop under load (0.2 - 0.3V @ 200mA tested) but still better than a sharp stick to the eye.  I also checked the Li-ion battery capacity, with & without the Boost circuitry;

        Repaired Battery voltage: 4.16V, no Boost - Capacity: 1080mAh

        Repaired Battery voltage: 8.6V, Boosted - Capacity: 350mAh

Interestingly, a capacity comparison between the 'Good' and the 'Repaired' battery, using mAh and Wh's, produced the following;

        Good Battery Capacity: 360mAh and 3.24Wh

        Repaired Battery Capacity: 350mAh and 2.98Wh

Which are close enough to make it a job well done!   Incidentally,  the measured, (1080mAh) versus the stated (1100mAh, by Liitoala)  are satisfyingly close, especially since these batteries have had a fair bit of use.  Of course, stating battery capacity in mAh's for Li-ion (boosted) 9V batteries is completely misleading, which of course, is the point!

Magnum Metal Detector Repair...

    I seem to have been having a run of repair-successes lately, so I figured I'd have (another) shot at a problem that has bested me for over 40 years.  Seriously.

    I may have already mentioned the issue in a previous post, it involved the Magnum Metal Detector's 'pin-pointing' function.  In use, when a metal object is detected while sweeping an area with the detector, the 'auto-tune' will tune out the 'find', zero the meter, and mute the audible find-signal, but only when the head remains stationary over the object - exactly as it should, there's nothing wrong with the auto-tuning!  However, in order to make pin-pointing more accurate, auto-tuning can be disabled, with a push & hold of the pin-point button.

    Thing is, even when I built the detector, the pin-point function never worked 100% - it was closer to 90, then 80%, then getting progressively worse as the decades passed.  What would happen was that, after a detection, and with the pinpoint button pressed & held, the meter would slowly start to swing from zero to fully negative, say, over the course of about 10 seconds.  The faster it would swing negative, the more useless it became.  This negative voltage-swing direction (labelled 'BAD' on the meter) also meant that the 'object-detected' tone, was instantly cut off - whereas a positive-swing (labelled 'GOOD'), retains the, 'object-detected' tone.  Without a tone-signal while trying to pin-point a find, the pinpoint function is practically useless.

    I started off by consulting with my current A.I, LLM of choice, Gemini.  I explained the issue and was advised to brush down the PCB board containing the responsible circuitry with isopropyl alcohol, which I considered a, too 'lo-tech', even insulting, suggestion - implying perhaps that something that trivial, hadn't already occurred to me.  But, try it I did, and no, it didn't work - but it appeared to have improved things marginally.  I then started wondering if the alcohol, running up the legs of the 2N3819 FET, that enables/disables the auto-tune circuitry, could somehow be responsible for the perceived improvement?  Removed from the circuit, it was apparent that time hadn't been kind to the FET in question - its legs once bright & shiny appearance, had become tired & tarnished looking, so much so, that they proved impossible to tin with solder.  So, rather than keep messing, I went searching for a replacement.

    All I managed to find was about half a dozen, genuine, yet equally tired looking  2N3819's, all likely bought at the same time in the distant past.  These proved equally hard to tin with solder, so I was reduced to scraping 40 years worth of grime off of them with a scalpel blade.  Back in-circuit, the replacement seemed to be performing a little better, than the first 'little better' of the original.  It was then I tried cleaning off the underside of the FET - where the legs enter into the transistor's plastic body - and the result was profound, almost a religious experience!!!  Pushing & holding the pinpoint button now, leads to practically no negative voltage drift, no matter how long it's held for (within reason).  The way it was always meant to perform, but never did.

    While all of this was resolving itself,  I happened upon another bizarre problem.  At fault was the shielded wire, that connects the upper PCB to the female socket in the case, that in turn accepts the male plug, that connects to the detector's head.  One of its wires had gone open-circuit.  This 'intermittent break had almost driven me to distraction in the past, exhibiting itself as wild swings of the meter, accompanied by the associated 'beeps' - I had presumed that it was down to circuit instability caused by aging components!  The break wasn't near either end of the wire either, where one would expect a wire to break, but right in the very middle!  Despite my best efforts, I managed to destroy the cable while trying to locate its break-point, and as I (understandably) no longer had any of the specified cable left, I opted for what was to hand, namely a bit of ribbon-cable.  And it seems to work just as well with this!  This turned out to be a huge discovery/fix as far as stability in use was concerned.

    The only other excitement I had with the detector, concerned a poor wiring decision, again, made in the 80's, that resulted in the death of one of my Liitokala Li-ion 9V batteries, as well as a few drained alkalines, before I figured out what was happening - inadvertent short!  On the plus side, though the Liitokala did suffer a fried transistor, I managed to get it up & running again.  I'll probably leave that 'repair-success' for another post. 

Edit.

    Well, that was a short-lived 'victory' (about 2 weeks) - yep, it's back at it again, and I'm clueless as to why!  I've been playing with the idea that it may be humidity-related, but that's just me grasping at straws.  Grrrr.

Edit1.

    Just thought I'd post a short video of the problem at hand.  Specifically, when the 'pin-point' button is pressed, the meter's needle should remain at the zero midpoint, not shoot off for the 'Bad' side.  The real irony is that it has never been this bad - 'pegging' the meter in about a second!  Before I 'fixed it', it would saunter towards the Bad side, taking perhaps five seconds to get 80% of the way, before running out of steam.  I uploaded the same video to Gemini LLM, in the hope it could provide a real circuit-fix that could be spliced into the existing circuitry.  Here's hoping...

 

Dominox Propane Torch Head Repair.

 

    I got this on Amazon, coming on a year ago, right around the time that I was heavily invested in getting my car back on the road, after a timing chain slip.  As an earlier post here testifies, right about when I had all of the heavy lifting done, I stupidly destroyed the auxiliary belt tensioner.   I managed to get a secondhand replacement on eBay, but figured, as a penance, I'd also try repairing the broken one.

    Hence, the torch head purchase, as well as a tube of aluminium welding rods, also from Amazon.  That was also as far as I got, repair-wise - after all, the car was fixed, which was all the incentive I needed to do nothing!

    But it turned out that the torch I had bought for the job, needed a fix as well, specifically, the igniter didn't work.  I posted the below video as part of my review on Amazon, highlighting the problem.  Prior to purchase, I had noted on Amazon's reviews, that this was a reoccurring problem.  I was also aware that it was a Chinese copy of a 'Western-branded' torch - therefore about a quarter of the cost - so worth the gamble...

 

    ...but which didn't pay off!  So, there it lay for a year, until a day or so ago, when I finally had a look at it.  It may have been cheap, but it's a very nice (copy of the original) design.  The 'fix' was surprisingly easy; whoever assembled the unit was to blame - they neglected to thread the igniter-wire through the 'retaining spring', which keeps it centered in the torch barrel, preventing the ignition spark from shorting to ground.  Once done, the igniter works perfectly - no doubt as well as the torch costing 4 times the price, I'd wager!

    The Igniter's re-assembly sequence can be seen in the below pics.

Dominox Torch

 

Igniter assembly sequence

Igniter-wire centered

Igniter-wire displaced

   

 

Mastech HY3005F-3 Bench Power Supply Repair.

    Over the last two decades, I must have acquired at least a couple of thousand Euros worth of electronics test equipment.  Collecting test equipment, most like-minded individuals would consider understandable, after all, who doesn't like tinkering.  But measuring equipment without components to measure stuff off of, is of no use to a tinkerer, so add to that a few thousand more Euros worth of components to the bill of acquired goodies - while knowing all the while that 99% of them I will never use!  But, as the saying goes, "possession is nine-tenths of the law", and I'd rather possess, when the possession is needed - never mind that most of the unused possessions will eventually end up in a skip at some time in the future.

    Case in point, is the Mastech Bench PSU.  This was bought 10-15 years ago as a replacement, after I had smoked a beloved, though less-capable supply, with high voltage, and which I had 'liberated' from an employer in the distant past.  The Mastech performed well for years.  After a while, I would notice that the displayed voltage would fluctuate a bit, but no biggie.  Over a year or two, that observance became an irritant, then quickly became an annoyance, the voltage jitter increasing in lockstep to my temperament.  I remember at the time, trawling through Reddit, searching for a solution.  On the plus side, I learned that the Mastech - one of a handful of names that it was known by - all in all, was seen by most, as fairly reliable.  Jittery voltage displays was noted however, along with the consensus that either reservoir electrolytics or the voltage pots, needed replacing.

    In my head, I poo-poo'ed the potentiometer solution, mainly because on my PSU, both supplies fluctuated badly, despite, by my reckoning, the right-hand side having been the main work-horse, the left having had sparse usage.  So caps it was, I decided, and promptly ordered some.  But, as an afterthought, I added a bag of assorted pots to the BOM, just in case...

    And there both lay, gathering dust, for the best part of two years - enough time, that I had even forgotten about having ordered the pots!  By this time, the voltage fluctuations had gotten so bad, that I had grown fearful of damaging circuits I was powering it with.  The capacitor-swap was the first thing I tried, and that proved to have zero effect.  I was chuffed to discover, on rummaging around my boxes of components, the bag of pots I had ordered.  Long story short, the potentiometers proved to have been the culprits!  Once replaced, both supplies returned to being fluctuation-free - RESULT!

    Wee!

Frankenstein Fruit

     Possibly my shortest post ever!  I bought these 'fun-sized pears' over a month ago in Lidl.  While not quite 'as green as grass', they were damn close, but I figured, that I could wait a week or two, for them to mature.

    And wait, and wait...  As can be seen, at least one month on, ripe they aint!  There was 7 in the bag originally, and yesterday, selecting the most succulent, I took a bite.  The verdict, medium sweet, but still way too hard, and by no means 'succulent'.

    My question, why are completely inedible fruit like these for sale, and most importantly, what are they doing to these pears to slow their maturation?  It's unnatural to see a bag of pears, placed in an open window (therefore, plenty of sunshine), for this amount of time, to remain green like this.

    It might be interesting to track the above pear's ripening, so I'll try and resist the urge to go chomping on them, till they begin to resemble something edible - the pear, top-right, is likely to be the first contender.  Time will tell. 

26 Days Later.

    The above pic is all that is left of the bag of pears in question, 26 days on from when the 1st photo was taken.   One has ripened somewhat, but as of about 5 days ago, it was still too hard to bite into - and in truth, it has become more wizened than ripe.  I'm just after cutting it into chunks in the hope that the birds will find a use for it.

    In actuality, since the first post, I have already scoffed another bag of these pears, same brand/seller, while waiting for these to metamorphise (seems like a new word, that - think I'll claim it!) into something edible.  They rapidly ripened in to genuinely succulent pears, whereas, as can be seen, the Frankenstein pear that's left, is still bordering on rock-hard, and almost as green as it was over 2 months ago - makes me wonder/worry about what kind of alchemy/chemistry they use to extend shelf life. 

  

    Edit:

    Eleven days on, and some more observations on another bag of frankenstein fruit that is misbehaving (see pic. above).  On the face of it, these pears look promising, for something that's been allowed to ripen for about 3 weeks, going by their colour anyway!  Unfortunately, they appear to have decided to rot rather than ripen.  Two pears from the bag had developed huge blemishes, well on their way to spoiling, so were chopped up and fed to the numerous crows around here.  But despite all of the pears now being a healthy ripe colour, they are all still rock-hard, way too hard for my poor old teeth to attempt gnawing at.

    Lidl  seems to have gotten the message as well, or at least, they no longer had them for sale when I visited them today.  

Li-ion Battery musings...

    

 I bought a Medion GPS navigator just shy of two decades ago.  Back then, when paper roadmaps were still a thing, and smart-phones as we've come to know them, still a dream, dashboard navigators were regarded as the ultimate in chic for the in-touch motorist - to my mind anyway!

    The navigation software it came with was functional, but it wasn't long before I found a 'hacked' version of a much more capable application online - whose name escapes me at the moment, more on that, later.  Not only did the flash-image file I found, contain new navigation software, it also included dozens of other s/w applications, so much so that you are left wondering how so much could be crammed onto such a puny device.

    Fast-forward a decade or so.  While driving, the unit had become unusable without being plugged into the cigarette lighter, as it would power off after just a few minutes.  This also meant it was completely useless as an aid while out walking, something I often used to advantage.  Sourcing a new battery proved easy, even though the batteries themself are 'custom items', coming complete with an attached power lead, that sported one of the smaller PCB connectors.  This meant that (if memory serves!) while not expensive, it wasn't cheap either.  But it worked, which was all that mattered. 

    However, time had moved on, and it wasn't long after that I got my very first proper 'smart-phone', complete with all the bells-and-whistles, which obviously included GPS navigation.  As a result, the Medion Navigator had been consigned to a 'Surplus to Requirements' box, and has been gathering dust for the last 6-7 years.

    I came across it recently, and feeling nostalgic, set it up in the car - only to find that it no longer worked!  It had all the signs of a failing battery.  It wouldn't take a charge via its mini-USB connector.  However, I found that when I removed the battery from the unit, and charged it 'manually', from my power supply, it charged normally.  What does not work, sometimes, or not at all, is the touch-screen!  Charge the battery 'externally', plug it into the navigator, switch it on, and the touch-screen is fine.  Play with it for while, and after about 30 minutes the touch-screen starts to malfunction again.  Right now, it's not working at all, and the reason I'm not listing the upgraded navigation software.

    So, although my Navigator seems to be on its last legs, I discovered something unexpected while charging the, now quite old, battery.  As can be seen, the battery is rated at 750mAh capacity.  But when I charge it to capacity and discharge it on an electronic load, to measure its capacity, I find that the battery provides significantly more than 750mAh.

 

    Charged to capacity from 4.2V @ 300mA, (Discharged to 3.0V); 

    Discharging @ 100mA => Measured Capacity = 1087mAh

    Discharging @ 150mA => Measured Capacity = 1047mAh

    Discharging @ 200mA => Measured Capacity = 1061mAh

 

    Frankly, this surprised me.  That's 25% more capacity than is advertised.  And while the battery is not the problem here, a quick check online shows that Amazon is still selling these batteries.  So at least others, feeling nostalgic, may have the means of coaxing a few more years out of these old tried & trusted navigators.