The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Tag: Improvements

Making the world a better place, one piece at a time

  • Xiaomi Dafang Hacks: Hostname for OSD and Filename

    The config/hostname.conf file (found under /system/sdcard/when the camera is running) file defines the camera’s name:

    Cam4

    That file overrides the contents of the usual etc/hostname.conf file, somewhat to my surprise, which remains the default Ingenic-uc1_1.

    The bin/hostname utility returns the hostname:

    [root@Cam4 ~]# which hostname
    /bin/hostname
    [root@Cam4 ~]# hostname
    Cam4

    You can automagically get the hostname in the on-screen display by modifying the OSD formatting variable in config/osd.conf:

    OSD="$(/bin/hostname) %Y-%m-%d %H:%M:%S"

    Which works because the main OSD script sources the config file to set the variable:

    Xiaomi Dafang - 15-04-2019_13.26.18
    Xiaomi Dafang – 15-04-2019_13.26.18

    It’s also helpful (at least for my purposes) to add the hostname to the image filenames. A one-line tweak in the scripts/detectionOn.sh script does the trick:

    snapshot_filename=$(/bin/hostname)_$(date "$snapshot_pattern")

    Which produces names along these lines:

    -rwxr-xr-x  1 ed   root 246K Apr 23  2019 Cam4_2019-04-23_17.51.02.jpg*
    

    Having source code makes simple changes like this … simple!

  • Fluorescent Ballast Caps: FAIL

    After converting another fluorescent shoplight into an LED fixture, I tested its capacitors:

    Fluorescent ballast capacitors - one failed
    Fluorescent ballast capacitors – one failed

    The ESR02 reports one as a 4.8 µF capacitor, the other as a “defective part” with a 4 kΩ resistance. Having a cap fail by turning into a resistor is surprising; I’m more surprised it didn’t simply burn up.

    They’re visually indistinguishable, of course.

  • Samsung EVO Pro 32 GB MicroSD Cards

    Installing the Xiaomi Dafang Hacks firmware requires an MicroSD card in each camera and, my previous stock having run low, four more just arrived:

    Samsung EVO Plus - 32 GB MicroSD
    Samsung EVO Plus – 32 GB MicroSD

    Prices have collapsed to the point where known-good (all four passed f3probe testing) cards direct from Samsung (as opposed to Amazon’s “commingled inventory” counterfeit situation) now cost $12-ish each with free shipping.

    After I finish fiddling with the first camera, I’ll copy its card onto these four, unique-ify the IP addresses / hostnames /suchlike, and bring ’em all online.

  • Xiaomi Dafang Hacks: Motion Detection

    Given a camera running Xiaomi Dafang Hacks software, you can set up motion-triggered image capture and save the images either locally or on an FTP server. The latter makes sense, as it automatically plunks the images where they’re more generally available.

    Define the FTP server parameters in config/motion.conf:

    # Configure FTP snapshots and videos
    ftp_snapshot=true
    ftp_video=false
    ftp_video_duration=10
    ftp_host="192.168.1.10"
    ftp_port=21
    ftp_username="ftp-user-id"
    ftp_password="secret-password"
    ftp_stills_dir="Cam4"
    ftp_videos_dir="Cam4"

    The FTP server should have the Cam4 directory in place and shared for read-write access before attempting to plunk files therein. Ahem.

    The camera’s Services menu leads to the motion configuration page:

    Xiaomi Dafang - Motion Settings page
    Xiaomi Dafang – Motion Settings page

    Limiting the detection region to the lower-left corner cuts out all the waving-in-the-breeze foliage in the yard, while covering the driveway. High sensitivity detects squirrel-sized objects in the foreground, although your mileage will certainly differ.

    The camera seems rate-limited at 5 s/image, which may come from FTP transfer overhead; I don’t know if the code includes a built-in delay or if it just works like that. The NAS drive requires upwards of 7 s to spin up if it hasn’t been used for a while, but afterwards the transfers don’t take that long.

    Mounting the NAS drive’s CIFS shared directory from my desktop PC works as before:

    sudo mount -v -o rw,credentials=/root/.nas-id,vers=1.0,uid=ed -t cifs //192.168.1.10/Cam4 /mnt/part

    Then view / edit / delete images as needed:

    Xiaomi Dafang - IR motion capture - 15-04-2019_20.02.06
    Xiaomi Dafang – IR motion capture – 15-04-2019_20.02.06

    The camera has built-in IR LEDs, but they’re nowhere near powerful enough to illuminate the entire yard.

    Motion detection works better in daylight:

    Xiaomi Dafang - Daylight motion capture - 16-04-2019_09.53.51
    Xiaomi Dafang – Daylight motion capture – 16-04-2019_09.53.51

    Unlike the original Wyze firmware, the Xiaomi Dafang Hacks firmware & software keep all the images & metadata within my network and under my control.

  • Xiaomi Dafang Hacks: Timelapse Images

    With the Wyze and Xiamoi Dafang cameras running the Xiaomi-Dafang Hacks firmware and software, I tried the timelapse functions on the yard camera.

    The config/timelapse.conf file:

    # Interval between snaps, in seconds
    TIMELAPSE_INTERVAL=10
    # Duration of the script should run, in minutes, set to 0 for unlimited
    TIMELAPSE_DURATION=60
    # Save dir config
    SAVE_DIR_PER_DAY=1
    # Enable compression
    COMPRESSION_QUALITY=100

    The images, named along the lines of 13-04-2019_191810_001.jpg, appear in the DCIM/timelapse directory, tucked into daily directories with names like 2019-04-13, a mismatch obviously in need of tweaking. There’s also a time_lapse directory which seems like cruft from an earlier revision; you can configure the target directory in scripts/timelapse.sh.

    Start the script manually or from a crontab entry, wait until it’s done, then transfer the images to somewhere more convenient with a Bash one-liner:

    find /system/sdcard/DCIM/timelapse/ -name \*jpg -exec curl -s -n -T {} ftp://192.168.1.10/Timelapse/ \; 

    The -s silences all curl output; omit it until you’re sure the lashup works as you expect. I always forget the backslash before the semicolon terminating the -exec command.

    The -n pulls the userID and password from the ~/.netrc file you previously set up for manual ftp sessions:

    machine 192.168.1.10
    login ftp-user-id
    password secret-password

    The IP address corresponds to my ancient NAS drive; your mileage may vary.

    From my desktop box, mount the NAS drive:

    sudo mount -t cifs -o "credentials=/root/.nas-id,vers=1.0,uid=ed" "//nasty/Timelapse" /mnt/part

    The drive’s credentials aren’t particularly secret, but tucking them into /root/.nas-id means you could automount the drive with no hassle. The NAS drive requires the oldest possible CIFS version, of course.

    Then view the pix:

    Xiaomi Dafang - 15-04-2019_13.26.18
    Xiaomi Dafang – 15-04-2019_13.26.18

    You could set up the camera as an NFS share, but having all the cameras deposit their pix in a common location seems more convenient, particularly after I get around to automating the image transfer. Regrettably, the NAS drive doesn’t support subdirectories.

  • Anker MicroSD Card Adapter Speeds

    According to its description, the Anker USB 3.0 card reader can handle both a MicroSD and a standard SD card at once:

    Simultaneously read and write on two cards to save yourself the effort of constant unplugging and re-plugging.

    Which looks like this:

    Anker USB Reader - dual card
    Anker USB Reader – dual card

    After you get used to inserting the SD card downside-up, it fits perfectly. The Kapton tape on the MicroSD card eases extraction from the still finger-dent-less M20 camera mount on the back of my Tour Easy ‘bent.

    Plugged into a USB 3.0 port, my file extractor script chugs along at 25.9 MB/s, taking about 18 minutes to transfer 28 GB of video data.

    Splurging another eleven bucks for a second reader produces this setup:

    Anker USB Reader - single card
    Anker USB Reader – single card

    After plugging both readers into adjacent USB 3.0 ports, the script transfers files at 46.6 MB/s and copies 28 GB in 10 minutes.

    So, yes, the reader can handle two cards at once, but at half the speed.

    Not life-changing, but it shows why I like measurements so much …

  • Multiprocess Book-on-CD Ripping

    The most recent iteration of ripping a book-on-CD to bits suitable for a small MP3 player begins by defining the metadata:

    author="Whoever Wrote It"
    title="Whatever It May Be About"

    Set up a suitable directory for the MP3 files, with a subdirectory for the WAV files direct from the CD:

    mkdir "$author - $title"
    cd "$author - $title"
    mkdir waves

    Then unleash cdparanoia on each disk, but with its error checking dialed back to a minimum because most errors don’t produce much audible damage:

    d=01 ; cdparanoia -v -Y --never-skip=1 -B "1-" waves/D$d.wav ; eject cdrom

    In some cases, however, a nasty gouge (the previous owners being careless, alas) can jam cdparanoia midway through a track, so I fetch all the remaining tracks:

    d=10 ; cdparanoia -v -Y --never-skip=1 -B "6-" waves/D$d.wav

    Sometimes re-cleaning the disc and re-reading the offending track produces a better outcome:

    d=10 ; cdparanoia -v -Y --never-skip=1 -B "5-5" waves/D$d.wav

    With all the WAV files collected, I now know how to unleash multiple lame conversions for all the tracks on each disc:

    for d in {01..12} ; do for t in {01..19} ; do if [[ -f waves/track$t.D$d.wav ]] ; then lame --silent --preset tape --tt "D${d}:T${t}" --ta "$author" --tl "$title" --tn $t --tg "Audio Book" --add-id3v2 waves/track${t}.D${d}.wav D${d}-T${t}.mp3  & fi ; done ; wait ; done

    The disc and track ranges correspond to notes written on paper while ripping the CDs, there being no automagic way to collect the information.

    That may be easier to read with the control structures spread out:

    for d in {01..12}
     do for t in {01..19}
      do if [[ -f waves/track$t.D$d.wav ]]
       then
        lame --silent --preset tape --tt "D${d}:T${t}" --ta "$author" --tl "$title" --tn $t --tg "Audio Book" --add-id3v2 waves/track${t}.D${d}.wav D${d}-T${t}.mp3  &
       fi
      done
     wait
    done

    Affixing an ampersand (&) to the lame command drops it into the background, where it runs as CPU time becomes available. The wait after the first loop stalls until all of the lame instances for each CD finish.

    The kernel scheduler manages to keep the GUI responsive while a four-core CPU makes short work of the entire CD.

    When it’s all done, transfer the MP3 files to the player:

    cd ..
    sudo mount -o uid=ed /dev/sde1 /mnt/part
    rsync -vrtu --progress --exclude="waves" "$author - $title"  /mnt/part/Music
    sync
    sudo umount /mnt/part

    Fetching commands from history eliminates the need to remember all that, but now it’s written down where I can find it for the next desktop box.

    Life is good!