Failed and working projects, notes etc.
I found in my notes from 2017 a method to fix the header of a M4A file. Appartently I needed this back then to repair a file, and then forgot about the note. So here ya go:
ffmpeg -f aac -analyzeduration 100M -probesize 100M -i broken.m4a -c copy fixed.m4a
It is the second time that I have to fix this issue where the trigger fails to release the hammer.
Symptom: The lever is not closing completely and then you cannot pull the trigger.
Cause: There is a small piece of steel in the “roof” of the action that has come loose and slides forward.
Fix: Fix the steel insert in its place, now with a much stronger adhesive. I used Loctite 648 this time.
Okay, first you need to make everything super clean and free of grease. Then you sand the slot with some fine sanding paper first as another cleaning step and then you use a coarser sanding paper to roughen up the surface.
Next, clean the insert thoroughly and use fine sanding paper first, then coarser paper.
I chose for a stronger loctite this time, because I want to wait with more intrusive ways to affix this part. Have I noted that this part should never have come out in the first place? It’s not even noted in any parts list…
There, all fitted together and now I will give it plenty time to dry and cure. Was briefly pondering about heating it up, but that’s a bit of a weird thing to do with glue as you can also often use heat to undo glued together parts.
I’ll go try it out tomorrow with some beefy ammo. I bought CCI EX Stingers that will yeet the nope with 1640 feet per second. If that breaks the glue bond, I’ll have to figure out another way to affix the insert.
After cleaning out my Browning BL22 and replacing some springs, I experienced an issue with the lever on a regular basis. I took it apart again, checked everything, only to have it re-appear again.
Then I noticed that a small plate in the roof of the rifle’s action housing had come loose. After some investigating, I deduced that this was a part that should not move around. Especially since I discovered that I could visibly see the plate when the issue occurred and by pushing it back, I could resume shooting. Another pointer was, that this particular part does not occur in any parts list.
This is how it looks when the plate has moved then then causes a lockup:
So I decided to use some Loctite 242 to lock the plate in place and now time will have to tell whether this works or not.
The Koonlung K1S is a very nice dashcam, with GPS, emergency button and HD recording and everything is made quite small. The HD video has a bit of a low bit rate, but it’s still not bad.
That said, it became a piece of rubbish. No matter what kind of SD card is inserted, the software locks up and the whole device becomes useless.
I have tried all the versions of the firmware [⇓1]. I have tried to decompile the firmware [⇓2][⇓3]. Nothing worked, whatever I tried.
So the time has come to take the thing apart. It cannot be any more broken than it is now, so maybe it is a blown cap or something? It is not, by the first look. There seems to be a corroded button cell soldered onto the motherboard.
Alright. So what model is it? It’s not like you can just take it out and read what’s stamped onto it. Luckily I have a reference sheet in my archive that can be helpful. Hooray for being a data hoarder? >_>
The diameter is 4.8mm and the height is 2.0mm. The height is somewhat debatable as everything is small and kinda hard to reach. According to my datasheet, there are two candidates as a replacement battery:
As I want to get the exact battery, I grabbed a mini caliper and measured 1.65mm. There we go. It will be a SR416SW or anything compatible.
€5,46 has been paid for a set of 10 batteries because it was impossible to buy just one and now it is time to get the battery out.
More progress updates later!
[1] K1S-R158-50417-MPH – K1S-R179-50825 – K1S-R180-KPH – K1S-R180-MPH – K1S-R215-KPH
[2] k1s.bin_hlil – Type: Mapped, Platform: thumb2, Architecture: thumb2
[3] k1s.bin_hlil-arm7 – Type: Mapped, Platform: armv7, Architecture: armv7
[root@conrad ~]# apt-get autoremove Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up fuse (2.9.3-15+deb8u3) ... Creating fuse device... /run/udev or .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. chmod: cannot access '/dev/fuse': No such file or directory dpkg: error processing package fuse (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fuse E: Sub-process /usr/bin/dpkg returned an error code (1)
I have no idea why my fuse got bonked, but I simply made a folder named fuse in the dev folder and everything works as intended again.