[{"content":"","date":"14 February 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"Almost exactly 9 years ago, I launched this blog on WordPress. And today, the time finally came for a change.\nBack then, WordPress felt like a great solution. Everything was easy to click together. You didn’t have to think too much about the underlying mechanics — just install, configure a theme, and start writing.\nOver time, though, it started to bother me.\nWhat annoys me most today is how much infrastructure you need just to host a simple blog:\nA web server with PHP support A database (MariaDB) And, of course, WordPress itself Maintaining all of that has become unnecessary overhead for me. Updating WordPress is time I’d much rather spend on other projects and interests. And as we all know, an unpatched WordPress installation is asking for trouble.\nWhy increase your attack surface if a simple blog can be fully static?\nSome time ago, the idea of using Hugo started forming in my head. I had read about it earlier — I think someone on Debian Planet mentioned migrating to it. The idea stuck with me.\nAnd today was finally the day — I made the migration.\nA big help along the way was the wp2hugo project:\nhttps://github.com/ashishb/wp2hugo\nThe process went surprisingly smoothly. Most importantly, I didn’t have to manually wrestle with exporting and importing everything into Hugo — the script handled the dirty work for me. What remained was polishing things up and making sure everything looked right.\nI also considered Astro, but it felt like overkill for my needs. Hugo turned out to be a perfect fit. It has great themes, and best of all, I can write in Markdown — which I’ve grown very fond of since using GitHub.\nAnother big plus: clean, simple code that lives in git.\nA new post is just a new .md file.\nThat’s beautiful.\nNo database blobs. No hidden magic. Just files.\n","date":"14 February 2026","externalUrl":null,"permalink":"/2026/02/hello-hugo/","section":"Posts","summary":"","title":"Hello hugo!","type":"posts"},{"content":"","date":"14 February 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"14 February 2026","externalUrl":null,"permalink":"/","section":"skyboo.net","summary":"","title":"skyboo.net","type":"page"},{"content":"","date":"14 February 2026","externalUrl":null,"permalink":"/categories/uncategorized/","section":"Categories","summary":"","title":"Uncategorized","type":"categories"},{"content":"Since I’ve always enjoyed tinkering with retro hardware (and partly out of nostalgia), I decided to revisit something I last did back in 2009 - building OpenWrt from source.\nI still have a few old SparkLAN WX-7800A / Tonze AW-6660 devices lying around, which I once hacked to run Linux ( my old page about it). They’re based on Atheros AR5312 (MIPS 4Kc V0.9).\nThe only things I had left were the old kernel image and an NFS root directory. Back then, I used to boot the kernel over TFTP and mount the root filesystem via NFS - much more convenient than flashing and dealing with limited onboard storage.\nFrom the kernel banner I learned that I had been using OpenWrt Kamikaze (bleeding edge, r14600).\nFortunately, the official OpenWrt repository still preserves the old SVN history (massive respect to the maintainers for that!).\nSo locally, it boiled down to:\ngit clone git://git.openwrt.org/openwrt/openwrt.git cd openwrt git log | grep \u0026#34;SVN-Revision: 14600\u0026#34; git checkout 26754768121227b2fb8ee44809192aaa032e7816 That gave me the exact tree from 2009.\nOf course, trying to build it directly on a modern Linux system would almost certainly fail miserably - so I needed an environment from that era.\nHere’s where ChatGPT came in handy - it pointed out that around the same time (mid-2009), Debian Lenny was the current stable release. I wondered if I could somehow run such an ancient Debian inside Docker\u0026hellip; and surprisingly, yes! There’s a great image available called debian/eol.\nI fired up a container like this (on my modern x86_64 host):\ndocker run -it --name openwrt-lenny --platform linux/386 -v \u0026#34;$(pwd)\u0026#34;:/work debian/eol:lenny bash (The --platform linux/386 flag was crucial - without it, Bash would just crash.)\nInside the container, it felt like stepping back in time:\napt-get update apt-get install build-essential libz-dev ncurses-dev gawk bison unzip python wget subversion automake autoconf flex git-core Then I created a regular user, switched to it, and ran:\ncd /work make menuconfig # selected Atheros CPU make V=99 Of course, there were still a few bumps along the way. The build system pointed to old source URLs, but thankfully OpenWrt used mirrors even back then, so most packages still downloaded fine. For the few that didn’t (like binutils), I manually grabbed the correct versions from the web and dropped them into the dl/ directory.\nI also had to remove a few patches that no longer applied cleanly:\ndeleted: package/libpcap/patches/104-no_rej_files.patch deleted: package/libpcap/patches/105-space_optimization.patch deleted: toolchain/binutils/patches/2.17/500-avr32.patch deleted: toolchain/binutils/patches/2.17/501-avr32-fix-pool-alignment.patch The final hurdle was a failing patch in libpcap called wlan_filtering.patch.\nI didn’t want to waste too much time debugging it, so I used a quick hack:\ncp /dev/null build_dir/target-mips_uClibc-0.9.29/libpcap-0.9.8/wlan_filtering.patch chattr +i build_dir/target-mips_uClibc-0.9.29/libpcap-0.9.8/wlan_filtering.patch make -i # interrupt, then resume make V=99 And… it worked!\nI successfully built a 2009-era OpenWrt system on a modern Linux host, cleanly and neatly, thanks to Docker - without polluting my main system with old dependencies.\nLong live Docker, Debian EOL images, and all the folks who keep these old OpenWrt sources alive! 🧡\n","date":"13 November 2025","externalUrl":null,"permalink":"/2025/11/how-to-compile-a-16-year-old-openwrt-on-a-modern-linux-system/","section":"Posts","summary":"","title":"How to Compile a 16-Year-Old OpenWrt on a Modern Linux System","type":"posts"},{"content":"This article is about:\nProblems with concurrent Bluetooth and WiFi on Raspberry Pi Zero 2 W Connecting USB-ethernet dongle and making the static MAC address Configuring NFS-boot 1. Concurrent Bluetooth and WiFi on a Pi Zero 2 W # As wrote in previous article I am trying to make use of Pi Zero and BT dongle at the same time. Generally it is working quite OK but in some corner cases the Bluetooth and WiFi communication is interfering and I have problems at that time.\nI isolated the problem: the problem occurs only when I am trying to connect to a Bluetooth dongle which is not in range. It is reproducible. As you may know the dongle is in the car\u0026rsquo;s OBD port. When the car leaves the garage I am constantly trying to connect it in regular intervals and for some short period the WiFi communication (tested eg. on ping) is lost. It is about 1% of total time (BT dongle connection reattempts every 100s). I can see that about 2-3 pings are lost; it is looking exactly like this:\n64 bytes from pizero (192.168.1.37): icmp_seq=583 ttl=64 time=1.31 ms 64 bytes from pizero (192.168.1.37): icmp_seq=584 ttl=64 time=1.07 ms 64 bytes from pizero (192.168.1.37): icmp_seq=585 ttl=64 time=1.11 ms 64 bytes from pizero (192.168.1.37): icmp_seq=586 ttl=64 time=1.08 ms no answer yet for icmp_seq=587 64 bytes from pizero (192.168.1.37): icmp_seq=588 ttl=64 time=725 ms no answer yet for icmp_seq=589 no answer yet for icmp_seq=590 64 bytes from pizero (192.168.1.37): icmp_seq=589 ttl=64 time=2085 ms 64 bytes from pizero (192.168.1.37): icmp_seq=590 ttl=64 time=1085 ms 64 bytes from pizero (192.168.1.37): icmp_seq=591 ttl=64 time=73.2 ms 64 bytes from pizero (192.168.1.37): icmp_seq=592 ttl=64 time=1.00 ms I know this is not the end of the world, but I prefer to have a stable link, so I just took out from the shelf an old USB-ethernet dongle I had there:\nIt is visible in Linux in lsusb as:\nBus 001 Device 002: ID 0b95:772a ASIX Electronics Corp. AX88772A Fast Ethernet\n2. Connecting the dongle # I\u0026rsquo;ve connected the dongle and here is the dmesg for it:\n[ 3.479462] usb 1-1: New USB device found, idVendor=0b95, idProduct=772a, bcdDevice= 0.01 [ 3.483454] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.485325] usb 1-1: Product: AX88772 [ 3.487181] usb 1-1: Manufacturer: ASIX Elec. Corp. [ 3.488987] usb 1-1: SerialNumber: 000001 [ 4.147977] asix 1-1:1.0 (unnamed net_device) (uninitialized): PHY [usb-001:002:10] driver [Asix Electronics AX88772A] (irq=POLL) [ 4.155176] Asix Electronics AX88772A usb-001:002:10: attached PHY driver (mii_bus:phy_addr=usb-001:002:10, irq=POLL) [ 4.159839] asix 1-1:1.0 eth0: register \u0026#39;asix\u0026#39; at usb-3f980000.usb-1, ASIX AX88772 USB 2.0 Ethernet, 72:a8:99:7d:61:27 [ 4.164147] usbcore: registered new interface driver asix [ 4.905092] asix 1-1:1.0 eth0: configuring for phy/internal link mode [ 7.045241] asix 1-1:1.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx I tested it for a while and it seems that this connection seems to be perfect stable comparing to the WiFi of course. Here on this list:\nhttps://elinux.org/RPi_USB_Ethernet_adapters\nThis chip is also listed in some other brand and marked as working stable.\nI connected it directly to the Pi Zero\u0026rsquo;s USB-OTG port without any USB hub.\nThe main problem with simultaneous Bluetooth and WiFi is gone. No connectivity problems using a LAN cable at all :)\nMAC address problem # The card has one problem though: it doesn\u0026rsquo;t have a valid MAC address in the EPROM/configuration.\nIn regular Linux there was no problem for this as I just put two files for systemd-networkd:\n/etc/systemd/network/50-usb.link:\n[Match] Driver=asix [Link] Name=ethusb0 MACAddress=XX:XX:XX:XX:XX:XX /etc/systemd/network/60-usb.network:\n[Match] Name=ethusb0 [Network] DHCP=ipv4 \u0026hellip; but here in Raspberry Pi i wanted to boot via NFS and so the constant MAC address is a must.\nUnfortunately a kernel patch for setting the MAC for NFS-boot was rejected (for the same reason as mine patch for setting MTU) telling us that \u0026ldquo;why you are not using initramfs\u0026rdquo;. Maybe because for some reason the NFS-boot is still there in linux and initramfs is just another layer which could be omitted in some scenarios?\nOK, so the only solution for me was to create a proper initramfs image for the Pi.\nPreparing initramfs with initramfs-tools # First I\u0026rsquo;ve added those two lines to /etc/initramfs-tools/modules:\nasix ax88796b So the ethernet modules get\u0026rsquo;s loaded during early boot.\nThen I\u0026rsquo;ve created a file:\n/etc/initramfs-tools/scripts/init-premount/asix\nWith the contents:\n#!/bin/sh PREREQ=\u0026#34;\u0026#34; prereqs() { echo \u0026#34;$PREREQ\u0026#34; } case $1 in prereqs) prereqs exit 0 ;; esac . /scripts/functions INTERFACE=\u0026#34;eth0\u0026#34; MAC=\u0026#34;00:0e:c6:XX:XX:XX\u0026#34; log_begin_msg \u0026#34;MAC address re-configuration...\u0026#34; ip link set dev $INTERFACE address $MAC configure_networking Finally made it executable:\nchmod +x asix\nIn some tutorials (probably for older Raspberry Pi OS-es) I saw instructions, that you need to copy the resulting initrd image to the SD card\u0026rsquo;s boot partition and also make a change in boot/config.txt like this:\ninitramfs initrd.img followkernel\nIn my case however it seems it is done automatically. The image is copied, and the config.txt has this:\n# Automatically load initramfs files, if found auto_initramfs=1 To sum it up: fortunately it was as easy as:\n# update-initramfs -u -k $(uname -r) update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v8\nAnd this is sufficient to boot with this new initramfs image.\nRelated helpful articles/manuals: # https://manpages.ubuntu.com/manpages/xenial/man8/initramfs-tools.8.html https://github.com/ralsina/zero-nfsroot https://dev.webonomic.nl/how-to-run-or-boot-raspbian-on-a-raspberry-pi-zero-without-an-sd-card http://retinal.dehy.de/docs/doku.php?id=technotes:raspberryrootnfs 3. NFS-root # I think it should work as in other methods (so passing an ip=... to the kernel commandline, adjusting fstab, etc). I didn\u0026rsquo;t do it yet, but I will write something here only if I encounter some problems.\n","date":"7 March 2024","externalUrl":null,"permalink":"/2024/03/raspberry-pi-zero-2-w-and-a-usb-ethernet-dongle/","section":"Posts","summary":"","title":"Raspberry Pi Zero 2 W and a USB-ethernet dongle","type":"posts"},{"content":"","date":"27 February 2024","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":" Intro # Recently I bought Raspberry Pi Zero 2 W for my electric car project:\nIt is very neat board with a good pricing. As I am lazy I didn\u0026rsquo;t even wanted to connect keyboard and HDMI (or UART) - I just wanted to be able to connect to it remotely using ssh. It was all, what I needed. I thought that preparing an official SD card with Raspberry Pi OS for headless boot will be piece of cake.\nOh\u0026hellip; I was wrong :)\nTL;DR # This article is about manually preparing a headless SD card image. If you\u0026rsquo;re not familiar with below stuff/commands I recommend to use a tool called Raspberry Pi Imager (read last paragraph below).\nCurrent state # I know that this article may be outdated soon as Raspberry are changing software (and distros regularly), so I only want to say that the following tutorial was written 27.02.2024 and the version/sha of the Raspberry Pi OS which I am referring to (and downloaded) is:\n9ce5e2c8c6c7637cd2227fdaaf0e34633e6ebedf05f1c88e00f833cbb644db4b 2023-12-11-raspios-bookworm-arm64-lite.img.xz\nRelease date: December 5th 2023\nPreparing SD card # Saving an image was the easiest part: I\u0026rsquo;ve fetched the official Raspberry Pi OS Lite from official site, checked the SHA256 checksum and dd it on SD card.\nThen I followed some tutorials and yt films. As the result I mounted the boot partition, and created an empty ssh file on it. This should enable automatic start of the ssh service. I also added specially crafted wpa_supplicant.conf with my WiFi settings.\nSSH and WiFi connection # As according to the tutorials that was all, so I unmounted the card and booted the Pi. Unfortunately looking inside my Access Point, I didn\u0026rsquo;t see any connection attempts at all.\nI\u0026rsquo;ve re-plugged the card back to my computer and I saw that the file ssh is gone (this is OK - and just means that it enabled the ssh), but the wpa_supplicant.conf file was still there\u0026hellip;\nAnd here starts the long story about inserting the SD into computer, trying some additional changes (like a country setting), putting it back into Pi, waiting, and so on, and so on\u0026hellip;\nFinally when I was damn sure that the wpa_supplicant.conf should be OK i just used this file in the laptop and \u0026hellip; it was working fine!\nThis leads me to googling more \u0026hellip; and I finally found this thread. My problem was that the tutorials was outdated (for the previous bullseye release, while I have bookworm). As the result, I realized that instead of wpa_supplicant I have to create a NetworkManager WiFi profile file (sic!).\nI\u0026rsquo;ve created the file with the following content:\n[connection] id=MYSSID uuid=11111111-2222-3333-4444-555555555555 type=wifi interface-name=wlan0 autoconnect=true [wifi] mode=infrastructure ssid=MYSSID [wifi-security] auth-alg=open key-mgmt=wpa-psk psk=MYWIFIPASSWORD [ipv4] method=auto [ipv6] method=auto UUID is just unique ID and should be generated from some wide-available generators (or just leaved as above if you\u0026rsquo;re lazy ;) ).\nThe file needs to be named same as the SSID of the network (following above: MYSSID.nmconnection) and placed in: /etc/NetworkManager/system-connections of the system partition. Additionally it has to be chmod-ed to 600 and owned by root.\nBut this was not enough! I had to create a firstrun.sh file, place it in /boot/firmware of the system partition (the second one with the system, not boot) and make it executable ( +x).\nThe file has the following contents:\n#!/bin/bash # Stripped back version of the Bookworm firstrun.sh generated by the Raspberry Pi Imager # also calls raspi-config to set Wifi country, which in turn calls iw on Bookworm set +e rfkill unblock wifi for filename in /var/lib/systemd/rfkill/*:wlan ; do echo 0 \u0026gt; $filename done raspi-config nonint do_wifi_country GB # edited to remove a bug in rpi-imager that is a hangover from Bullseye # rm -f /boot/firstrun.sh rm -f /boot/firmware/firstrun.sh exit 0 Without this file the WiFi will not start/work (tested ;))\nAfter all these above steps, I was finally able to see a new connection on the AP and a new DHCP entry on the server! :)\nSo I was good to go. Work done! Now I was able to log in with SSH and wide-known user pi and password raspberry, right? :)\nNot so fast\u0026hellip; :D\nUser # It quickly turned out, that similar as with changing the wpa_supplicant to NetworkManager, the bookworm also got rid the default pi user. If I want to create specific user (side note: which I wanted because I forgot, that I could just add the public key and not messing with this, but this is another story), I had to create it with special file. Shorting the article:\n\\[...\\] create a file called userconf or userconf.txt in the boot partition of the SD card\nThis file should contain a single line of text, consisting of username:encrypted-password\nPassword can be generated with:\necho 'mypassword' | openssl passwd -6 -stdin\nAfter this, a user was created indeed and finally I was able to remotely login via SSH!\nThe easy way # At the end I have to mention that if you use Raspberry Pi Imager then all this stuff can be configured with this tool. But this is a GUI tool (QT if I remember correctly) and of course it has to be installed separately.\n","date":"27 February 2024","externalUrl":null,"permalink":"/2024/02/preparing-headless-sd-card-for-raspberry-pi-zero-2-w-without-raspberry-pi-imager/","section":"Posts","summary":"","title":"Preparing headless SD card for Raspberry Pi Zero 2 W without Raspberry Pi Imager","type":"posts"},{"content":"","date":"27 February 2024","externalUrl":null,"permalink":"/tags/raspberrypi/","section":"Tags","summary":"","title":"Raspberrypi","type":"tags"},{"content":"","date":"27 February 2024","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"8 February 2024","externalUrl":null,"permalink":"/tags/1wire/","section":"Tags","summary":"","title":"1wire","type":"tags"},{"content":"","date":"8 February 2024","externalUrl":null,"permalink":"/tags/esp32/","section":"Tags","summary":"","title":"Esp32","type":"tags"},{"content":"","date":"8 February 2024","externalUrl":null,"permalink":"/tags/jsn-sr04t/","section":"Tags","summary":"","title":"Jsn-Sr04t","type":"tags"},{"content":" TL;DR # This lengthy post is about designing and deploying my new ESP32 rust project (for the first time in my life) and all its struggles. It is using the ultrasonic sensor for liquid level monitoring.\nHistory (previous setup) # Long story short my house still cannot be connected to the sewerage system, so I had to use dedicated tank (cesspool) for domestic sewage.\nOf course, I would like to know what is the liquid level inside. Because all my house is wired with 1-wire so my first approach was to just add three float switches-based sensors on different levels (low/medium/high) inside the tank:\nThis setup was working for about seven years. The general setup was OK but there was one design problem: I\u0026rsquo;ve put the junction box inside the tank. During that time I had one problem: the liquid gets into the junction box, because (despite my efforts), it was not properly sealed. Even when the cesspool was finally pumped out, I still had incorrect reading (as sensors were active).\nFinally, because I cannot get inside the junction box again (corroded screws), I\u0026rsquo;ve drilled a small hole on the bottom of the box and the water leaks out. But the problem has started since then: over next years the reading was sometimes troublesome. The levels was flip-flopping in some specific circumstances (especially when there was high humidity weather conditions). And because the junction box was inside and without easy access, I realized that I need to build something better\u0026hellip;\nThe plan # I know that the environment inside the tank is harsh, and I also wanted to have something better, with much better accuracy. I knew some ultrasonic sensors for Arduino (like HC-SR04):\n\u0026hellip; but it was too big and cannot be placed inside. During my research I found some nice project by Pablo Cruz Lemini: https://pablocruz.io/water-level-monitor/\nThe sensor was waterproof and only the sensor was inside, and the electronics could be outside. This is what I wanted :)\nFinally, I ordered the ESP32 (for the first time ever) and JSN-SR04T (main board + one sensor).\nResearch # Regarding the software/examples, I was inspired mainly by those three projects:\nhttps://github.com/martinius96/hladinomer-studna-scripty https://github.com/pantaluna/esp32_jsnsr04t_using_lib https://github.com/portfedh/WaterLevelSensorMQTT Here I want to thank all the authors for inspiration and sharing hardware schematics and the code :)\nRegarding the firmware: recently I am a Rust fan, so if there would be some possibility to write the software in Rust, it would be a huge benefit for me. I hoped that migrating the C code to Rust should be possible. I started googling and it seems that there is some Rust community around Espressif chips: https://github.com/esp-rs\nI could choose an IDF-based HAL with Rust std support, or some more bare-metal no_std, called esp-hal.\nFirstly, I was planning battery-based system but after contacting Pablo ( pablocruz.io) I changed my mind and decided that I will power the ESP from the regular power adapter. Regarding communication, I decided that WiFi will be just fine, and also found a esp-wifi project for this.\nOverall, the Espressif-Rust community is great and really helpful. For the start I recommend this clip:\nDevelopment and desktop testing # Unfortunately (as I supposed) the start was not really easy. All problems are now solved but this is a quick recap of problems I encountered during this phase:\nFirst of all I had a problems with programming the ESP32 under Linux using the dedicated espflash utility: https://github.com/esp-rs/espflash/issues/394#issuecomment-1646554985. I had to use patched version which includes PR#387. Finally, this problem was fixed (at the end of my developing phase).\nThis way I was able to make and run a \u0026lsquo;Hello world\u0026rsquo; app. Next I added a WiFi support; a bjoernQ\u0026rsquo;s Demo of Rust on ESP32 (no RTOS) with MQTT and adafruit.io for temperature logging was also helpful.\nRegarding the hardware and wiring: I have version 3 of the JSN-SR04T module with dedicated main board and external sensor:\n1. The Rev 3.0 as we have here and older Rev 2.0 of this module are stated to be 3.3V compatible as well as 5V. We have found 3.3V operation to be spotty at best in our testing, so if using with a 3.3V MCU, it is recommended to operate the module at 5V and use level shifting for the logic lines going to the MCU.\nhttps://protosupplies.com/product/jsn-sr04t-v3-0-waterproof-ultrasonic-range-finder/\nUltrasonic sensor is powered from 5V, while the ESP32 data pins designed for 3.3V. So I needed to add a voltage divider. I looked at several schematics and I ended up with similar wiring as here: https://apollolabsblog.hashnode.dev/esp32-embedded-rust-at-the-hal-timer-ultrasonic-distance-measurement\nI contacted the author because initially he also doesn\u0026rsquo;t place the divider there, but now the schematic is updated.\nThen I wired up the ultrasonic sensor on a beagle board and started to measuring the time frames which are needed to correctly compute distance. First I was doing the measurement in single thread, it was working fine, but I knew that when I add other tasks (eg. WiFi support) then the async/await would be a good solution for this. An embassy project comes with help, besides, I could use calculation based on intervals: eg. waiting for a rising/falling edge of a pin in an async task.\nThis is the function I was using at a time for measuring the distance:\nWhen I added all the WiFi stack (and also raised the clock to 240MHz, which is required) the whole ESP becomes really unstable. It was working for several minutes max. Moreover, the async code which I was using messed a little with the timings and distance calculation, so it is has visible drift.\nI reported this problem in esp-wifi#226\nFortunately the sensor has several working modes. I was using the default one, in short: I was starting the process using the TRIGGER pin and calculating how long the ECHO pin is up. The distance is then calculated using specified formula (look above in the sample code), so this time was crucial - as this directly influences the calculated distance. And this was not as reliable as before (when only this single task was running on the ESP).\nI\u0026rsquo;ve got this readings:\nDistance = 47.2cm Distance = 47.3cm Distance = 47.2cm Distance = 47.2cm Distance = 47.4cm Distance = 50.8cm Distance = 47.2cm Distance = 47.3cm Distance = 47.2cm Distance = 47.5cm\nSometimes it was differing even some centimeters (sic!) while I didn\u0026rsquo;t touch the sensor at all.\nFortunately the AJ-SR04M module I am using has other working modes. It can eg. send UART data like a serial device using the same ECHO pin. I started considering to testing other working modes.\nIt can work with 5 modes. Default is 0 - this is the trigger and echo. Modes can be changed by changing the R19 resistor value. By default on R19 there are empty pads (open):\nI also read, that sometimes, the firmware is not able to change modes (or not all modes are available) so to make first test I shorted the resistor pads (0 Ohms).\nThis way I changed the mode to Mode 5 which is really nice because the ultrasonic sensor is doing the whole measurement itself (which is perfect every time) and it is sending the final value to ESP. I was not sure whether this will work, but\u0026hellip; finally I\u0026rsquo;ve got this:\nGap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm Gap=478mm\n…. and still the same value when I don\u0026rsquo;t touch the probe! :)\nI don\u0026rsquo;t need to say that I really like this approach, as it seems, that the measurement is really stable and done by the sensor itself, not in ESP which is vulnerable to some \u0026ldquo;time drifting\u0026rdquo;.\nMode 5 I was using is outputting an ASCII text: \u0026ldquo;Gap=\u0026hellip;\u0026rdquo;. It was OK for testing but finally there is also Mode 4 which I preferred most, as this is a binary format and also a simple CRC byte is added.\nI ordered some resistors pack including a 47k Ohm SMD resistor (as I don\u0026rsquo;t have that), to be able to enable Mode 4. Finally, I soldered it in place:\n\u0026hellip; and adapted the code for using the binary UART instead of ASCII.\nLong-run testing # In the meantime I was doing reliability tests and it turns out, that there are is some nasty bug. I opened a esp-hal discussion#762 asking about it.\nThe problem appears after longer time period, eg. after several days of work.\nThe internal ESP buffer pointer was bad at some point, so I was trying to figure out why…\nAfter a weeks of testing (including oscilloscope testing to be sure that there are valid data on the wire) and thanks to Björn Quentin\u0026rsquo;s help, I was finally able to make a patch for this problem.\nMoving to \u0026ldquo;production\u0026rdquo; environment ;) # I enabled the internal watchdog timer in the code and decided that this is the time to test it in target location :)\nFirst I had the sensor on top but floating on wire - as you can see the graph was drifting from 79 to 58cm:\nNext day I glued it there with a silicone, and I was thinking that it is working better (after the vertical blue dotted-line on the above graph).\nBut at the end of the day I realized that I constantly have about 58cm!\nI was filling the tank the whole day so this was impossible!\nI went there and measured the distance to the liquid. I realized that it was measuring the initial distance (look below) only!\nAs the last resort I moved the sensor much more down just above the liquid (without any obstacles in-between). The sketch (sorry for the quality) is showing this:\nThis leads to more realistic data and this distance graph:\nAnd now some more recent photos how it looks:\nFinal # The hardware part is almost done for me (I only need to properly run the power cable, as you can see on the above photos, this is currently temporary solution).\nI will try to share the final source code on my github, but first I need to clean it up, as it is currently with a lot of commented/disabled stuff, etc.\nIt is now working for several months and the software part is really reliable (I am also monitoring ESP uptime). Nevertheless, during that time I had two outages. The problem seems the same in both cases:\nUnder some environmental/weather circumstances (probably related to dew point) the water is condensing on the top/ceiling of the tank like here:\n\u0026hellip; thus also the sensor gets wet. This is leading to this on the graph:\nThe solution is: open the cover and manually wipe off the drops from the sensor, then it is working back again. Unfortunately I didn\u0026rsquo;t find better solution for this. I only hope that this will be rare problem.\nThat\u0026rsquo;s all, thank your for your time :)\n","date":"8 February 2024","externalUrl":null,"permalink":"/2024/02/monitoring-cesspool-level-using-esp32-and-jsn-sr04t-ultrasonic-sensor/","section":"Posts","summary":"","title":"Monitoring cesspool level using ESP32 and JSN-SR04T ultrasonic sensor","type":"posts"},{"content":"","date":"8 February 2024","externalUrl":null,"permalink":"/tags/rust/","section":"Tags","summary":"","title":"Rust","type":"tags"},{"content":"","date":"8 February 2024","externalUrl":null,"permalink":"/tags/ultrasonic/","section":"Tags","summary":"","title":"Ultrasonic","type":"tags"},{"content":"","date":"1 July 2023","externalUrl":null,"permalink":"/tags/firmware/","section":"Tags","summary":"","title":"Firmware","type":"tags"},{"content":"","date":"1 July 2023","externalUrl":null,"permalink":"/tags/gardena/","section":"Tags","summary":"","title":"Gardena","type":"tags"},{"content":" Introduction # I own the Gardena SILENO minimo 250m2 robotic lawnmower:\nIt\u0026rsquo;s working very well for about two years so far. I am really happy that I don\u0026rsquo;t need to use petrol lawn mower anymore, and I just forgot to think about this task, which is really cool!\nThis model has only a BLE (Bluetooth Low Energy) connectivity (I\u0026rsquo;m using Android app).\nWhen I installed the mower for the first time, to use the mentioned application I had to create an account using the e-mail. Afterwards (probably because of GDPR) a new Gardena application was released, and my account was removed from their servers (because it was totally unnecessary to use the app).\nIn this season I observed, that the application works slower. I had problems with connecting to the mower, I had to be very near to establish the connection. Often I also had to \u0026ldquo;wake it\u0026rdquo; - pushing some button or power-cycle the mower itself. What was more frustrating: I lost the ability to obtain the mower error log. It was working on the first app version, which I was using, but after update it just stopped working. I also cannot obtain information about mower firmware version.\nThe mower has an USB-B port for the firmware upgrade, so finally I head up to Gardena support and try to find whether there is any new firmware available. Unfortunately I was not sure (it was even hard to guess from the page). I just decided to give it a try.\nThis official Gardena software update page is telling that only a Windows 10 or Mac OS are supported when upgrading. Because I am only using Linux, I started with an e-mail to Gardena support asking if they have some Linux upgrade tool available for the process. As you may expect - they just ignored my email (I only got some automatic response in German).\nI tried to run the upgrade tool (I\u0026rsquo;d rather call it a suite - as the installer is really heavy) under Windows 7 but the installer don\u0026rsquo;t start (as it\u0026rsquo;s stated on the site).\nInstalling Windows 10 on KVM # After some consideration the only way to upgrade it, was to install a Windows 10 on my Debian box using the KVM/QEMU which I prefer for virtualization over virt-manager.\nHere I have to thank Raphael for his great tutorial about doing this installation:\nhttps://raphtlw.medium.com/how-to-set-up-a-kvm-qemu-windows-10-vm-ca1789411760\nI tend to use a \u0026ldquo;pure\u0026rdquo; KVM, so after converting the whole virt-manager stuff, my Windows installation commandline ended with the following:\nkvm \\ -m 4G \\ -smp 4 \\ -net nic \\ -net user,hostfwd=tcp::3389-:3389 \\ -usbdevice tablet \\ -drive file=/home/kvm/win10/win10.img,media=disk,index=0,format=qcow2,if=virtio \\ -drive file=/home/kvm/win10/Win10_22H2_EnglishInternational_x64v1.iso,index=0,media=cdrom \\ -drive file=/home/kvm/win10/virtio-win-0.1.229.iso,index=1,media=cdrom \\ -vga qxl \\ -spice port=5900,addr=192.168.0.2,disable-ticketing \\ -boot once=d Firmware update process # Now I was ready to download and install the Gardena update suite.\nI connected the mower using USB cable and nothing happened, so I powered it up, and it shows up in dmesg as:\n[Fri Jun 30 19:14:19 2023] usb 1-6: new full-speed USB device number 39 using xhci_hcd [Fri Jun 30 19:14:19 2023] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [Fri Jun 30 19:14:19 2023] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Fri Jun 30 19:14:19 2023] usb 1-6: Product: Husqvarna Automower FS [Fri Jun 30 19:14:19 2023] usb 1-6: Manufacturer: Husqvarna AB [Fri Jun 30 19:14:19 2023] usb 1-6: SerialNumber: xxxxxxxxxxxx [Fri Jun 30 19:14:19 2023] cdc_acm 1-6:1.0: ttyACM0: USB ACM device [Fri Jun 30 19:14:19 2023] usbcore: registered new interface driver cdc_acm [Fri Jun 30 19:14:19 2023] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters \u0026hellip; so the mover act as an USB ACM device (STMicroelectronics according to this site?).\nFirst I was trying to pass the whole USB device to the virtual machine using:\n-usb -device usb-host,hostbus=1,hostaddr=39 but this was not working as expected - nothing shows up in windows (maybe the hostaddr is not the device number?)\nFinally I decided to pass it according this StackExchange post, so I replaced the above method with this:\n-chardev serial,path=/dev/ttyACM1,id=acm \\ -usb -device usb-serial,chardev=acm This finally helps and Windows detected new device (and requests for a reboot). During the reboot the mower went into sleep and disconnected:\n[Fri Jun 30 19:26:41 2023] usb 1-6: USB disconnect, device number 41 I had to do it one more time, keeping in mind, that the mower is going to sleep if nothing is initiating transmission for some period of time.\nFinally the upgrade suite has detected the mower and tells me that a \u0026ldquo;New software is available\u0026rdquo;, yay!\nSo i clicked \u0026ldquo;Update firmware\u0026rdquo;.\nIt downloads it from the internet, and started the process. The \u0026ldquo;Stage 1\u0026rdquo; went OK to the end, and during the \u0026ldquo;Stage 2\u0026rdquo; it stops on about 20-30%. I look into host system logs and I\u0026rsquo;ve got:\n[Fri Jun 30 19:30:41 2023] usb 1-6: USB disconnect, device number 42 [Fri Jun 30 19:30:51 2023] usb 1-6: new full-speed USB device number 43 using xhci_hcd [Fri Jun 30 19:31:36 2023] usb 1-6: new full-speed USB device number 44 using xhci_hcd [Fri Jun 30 19:31:36 2023] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [Fri Jun 30 19:31:36 2023] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Fri Jun 30 19:31:36 2023] usb 1-6: Product: Husqvarna Automower FS [Fri Jun 30 19:31:36 2023] usb 1-6: Manufacturer: Husqvarna AB [Fri Jun 30 19:31:36 2023] usb 1-6: SerialNumber: xxxxxxxxxxxx [Fri Jun 30 19:31:36 2023] cdc_acm 1-6:1.0: ttyACM0: USB ACM device Oops! Not good. The result is that it started the upgrade but the process is probably rebooting the mower leading to showing as a new ttyACM0 instead of previous ttyACM1 which was held and passed to VM.\nFinally the application of course failed with: \u0026ldquo;Programming failed, please try again\u0026rdquo;.\nAfter some time I can see, that the mower restarts two more times:\n[Fri Jun 30 19:31:46 2023] usb 1-6: USB disconnect, device number 44 [Fri Jun 30 19:31:50 2023] usb 1-6: new full-speed USB device number 45 using xhci_hcd [Fri Jun 30 19:31:51 2023] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [Fri Jun 30 19:31:51 2023] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Fri Jun 30 19:31:51 2023] usb 1-6: Product: Husqvarna Automower FS [Fri Jun 30 19:31:51 2023] usb 1-6: Manufacturer: Husqvarna AB [Fri Jun 30 19:31:51 2023] usb 1-6: SerialNumber: xxxxxxxxxxxx [Fri Jun 30 19:31:51 2023] cdc_acm 1-6:1.0: ttyACM0: USB ACM device [Fri Jun 30 19:34:55 2023] usb 1-6: USB disconnect, device number 45 [Fri Jun 30 19:36:06 2023] usb 1-6: new full-speed USB device number 46 using xhci_hcd [Fri Jun 30 19:36:06 2023] usb 1-6: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [Fri Jun 30 19:36:06 2023] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Fri Jun 30 19:36:06 2023] usb 1-6: Product: Husqvarna Automower FS [Fri Jun 30 19:36:06 2023] usb 1-6: Manufacturer: Husqvarna AB [Fri Jun 30 19:36:06 2023] usb 1-6: SerialNumber: xxxxxxxxxxxx [Fri Jun 30 19:36:06 2023] cdc_acm 1-6:1.0: ttyACM0: USB ACM device \u0026hellip; so it was not looking good, I was expecting a bricked device in the worst case :(\nThe moment of truth # I started the Android Gardena app and trying to connect to the mower using Bluetooth\u0026hellip; It seems everything was working properly. I even had the software version showing and even the error log is working back again!\nI connected it again and started the update suite, it tells me that the mower \u0026ldquo;Software is up to date\u0026rdquo;.\nResults # I was watching the youtube videos about upgrading and it seems that it has about six stages when doing an upgrade (it probably depends on model?):\nIn my case it stops on Stage #2. Overall I am not even sure if everything was updated. The good news is that the mower is working even better then before: I have access to the error log, software version, and the most important: I can see that the Bluetooth connectivity is working much better. I can connect to the mower even from inside the house (it was nearly impossible before) and the communication seems to be more stable then before.\nPost analyze # I was trying to search if the application stored some upgrade log on the guest machine. I didn\u0026rsquo;t find it, but instead I found this interesting things:\nThe main application:\nThis look like a .NET/WPF application.\nThere is also a AppData dir which is maybe even more interesting:\nI believe this is the firmware bundle, which was downloaded for my mower. Inside are even some README.md files. One of those has the following contents:\ninstallercore # The installercore package is mainained by, and any changes should be applied by, the platform team.\nThese scripts are highly shared between- and used by all installer-type bundles.\nAny change in these scripts will affect the whole G4-platform and stretches further than update-packages.\nAmong others this affects:\nAutoCheck bundles AMProduction (mower production in factory) Consumer Upgrade Tool (update at home) FOTA-bundles Please create a Jira for requested changes/features and send it to the platform team. # or this one:\nTIF Test Framework # This directory contains modules for use with TIF-bundles.\nWhen a bundle is genereated using, a subdirectory will be added to the ZIP-file called framework.\nThis directory will contain all files herein.\nUsing the basic example located in TIF/Scripts/IntegrationTests/basic_example with createTestBundle.py would generate a bundle ZIP with the following contents:\nMyBundle.zip |- index.json |- basic_example.py |- framework |- __init__.py |- README.md |- \u0026lt;other files from this directory\u0026gt; Using the Test Framework # NOTE: If using a TifApp or other tifBase-tool which does not support import of TIF-builtins in python scripts, see the DEPRECATED section at the end of this document.\nWith an updated tifBase, you can simply import whichever part of the framework you need.\nThere is also the \u0026hellip;\\AppData\\Local\\ConsumerProgramming\\Firmware\\1c72ca5a-b0a5-42f2-8cac-03b9feb7a449.zip\\SwPkg\\index.json with this content:\n{ \u0026#34;Configurations\u0026#34;: [ { \u0026#34;Version\u0026#34;: \u0026#34;P005-SystemCfg_32.3\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;P005-SystemCfg_32.3\u0026#34; } ], \u0026#34;Softwares\u0026#34;: [ { \u0026#34;Type\u0026#34;: \u0026#34;Installer\u0026#34;, \u0026#34;NodeType\u0026#34;: 40, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;40.74_Main-Installer-P005_50.2\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;40.74_Main-Installer-P005_50.2\u0026#34;, \u0026#34;ConfigFileName\u0026#34;: \u0026#34;40.74_Main-Installer-P005_50.2_ConfigArea\u0026#34;, \u0026#34;ConfigExtFlashFileName\u0026#34;: \u0026#34;40.74_Main-Installer-P005_50.2_ConfigAreaExtFlash\u0026#34; }, { \u0026#34;Type\u0026#34;: \u0026#34;Boot\u0026#34;, \u0026#34;NodeType\u0026#34;: 40, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;40.104_Main-Boot-P005_50.2\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;40.104_Main-Boot-P005_50.2\u0026#34;, \u0026#34;LoaderVersion\u0026#34;: \u0026#34;40.104_Main-Boot-P005_50.2\u0026#34;, \u0026#34;LoaderFileName\u0026#34;: \u0026#34;40.44_Main-Loader-P005_50.2\u0026#34; }, { \u0026#34;Type\u0026#34;: \u0026#34;Application\u0026#34;, \u0026#34;NodeType\u0026#34;: 40, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;40.5_Main-App-P005_50.2\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;40.5_Main-App-P005_50.2\u0026#34;, \u0026#34;ConfigFileName\u0026#34;: \u0026#34;40.5_Main-App-P005_50.2_ConfigArea\u0026#34; }, { \u0026#34;Type\u0026#34;: \u0026#34;Sub\u0026#34;, \u0026#34;NodeType\u0026#34;: 40, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;40.50_Sub-App_6.15\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;40.50_Sub-App_6.15\u0026#34; }, { \u0026#34;Type\u0026#34;: \u0026#34;Boot\u0026#34;, \u0026#34;NodeType\u0026#34;: 37, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;37.101_BLE-Boot_32.9\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;37.101_BLE-Boot-HVHMI_32.9\u0026#34;, \u0026#34;LoaderVersion\u0026#34;: \u0026#34;37.101_BLE-Boot_32.9\u0026#34;, \u0026#34;LoaderFileName\u0026#34;: \u0026#34;37.41_BLE-Loader-HVHMI_32.9\u0026#34; }, { \u0026#34;Type\u0026#34;: \u0026#34;Application\u0026#34;, \u0026#34;NodeType\u0026#34;: 37, \u0026#34;BoardType\u0026#34;: \u0026#34;20.15\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;37.3_BLE-App-Peripheral_32.11\u0026#34;, \u0026#34;FileName\u0026#34;: \u0026#34;37.3_BLE-App-Peripheral-HVHMI_32.11\u0026#34;, \u0026#34;ConfigFileName\u0026#34;: \u0026#34;37.3_BLE-App-Peripheral-HVHMI_32.11_ConfigArea\u0026#34; } ], \u0026#34;Name\u0026#34;: \u0026#34;P005G-SwPkg\u0026#34;, \u0026#34;Version\u0026#34;: \u0026#34;5995762-04C_P005G-SwPkg_50.3\u0026#34;, \u0026#34;ReleaseEvent\u0026#34;: \u0026#34;50\u0026#34;, \u0026#34;articleNumber\u0026#34;: \u0026#34;5995762-04C\u0026#34; } So this all seems to be some specific \u0026ldquo;bundle\u0026rdquo; made by some framework/third party ( \u0026lsquo;backend url\u0026rsquo; I found is: https://consumerbundlestorage.azurewebsites.net/). There are plenty of JSON and Python files, so for the moment I was hoping to run it from linux but I also found exe which could be problematic to run under linux. There is also a firmware itself (eg. bin and hex files).\nThe question remains if those stages progress bars were for the above flashing \u0026ldquo;parts\u0026rdquo; (Installer, Boot, Application, Sub, etc.) - or if it programs it all only at the beginning, and then the mower is only rebooting/flashing it \u0026ldquo;locally\u0026rdquo; by parts\u0026hellip;\nI am still unsure if I updated only the very first part (main program?) or all segments. Probably I would not know this, until the next firmware will be released (if any) or if I force somehow to \u0026ldquo;re-upgrade\u0026rdquo; this - this however is a risky task and I would like to have this mower running instead of having a bricked one ;)\n","date":"1 July 2023","externalUrl":null,"permalink":"/2023/07/gardena-sileno-minimo-250-story-about-firmware-upgrade-using-linux/","section":"Posts","summary":"","title":"Gardena SILENO minimo 250: story about firmware upgrade using Linux","type":"posts"},{"content":"","date":"1 July 2023","externalUrl":null,"permalink":"/tags/minimo/","section":"Tags","summary":"","title":"Minimo","type":"tags"},{"content":"","date":"1 July 2023","externalUrl":null,"permalink":"/tags/sileno/","section":"Tags","summary":"","title":"Sileno","type":"tags"},{"content":"","date":"1 July 2023","externalUrl":null,"permalink":"/tags/upgrade/","section":"Tags","summary":"","title":"Upgrade","type":"tags"},{"content":"","date":"8 February 2022","externalUrl":null,"permalink":"/tags/huawei/","section":"Tags","summary":"","title":"Huawei","type":"tags"},{"content":" Intro # I want to share what I found out regarding monitoring Huawei SUN2000 inverter using a Modbus/TCP method during my half-year journey with this inverter.\nLet\u0026rsquo;s start with some basics first:\nThe inverter has internal WiFi access point built-in on its mother board. The main purpose for this is surely the initial configuration by an installer.\nMy inverter also comes with a bundled USB dongle called SDongleA-05 / WLAN-FE:\nMain purpose of this dongle is to connect to Huawei\u0026rsquo;s FusionSolar cloud service and feed the data using internet connection. It is handling an ethernet cable connection or a WiFi to your home router.\nMonitoring the device # The FusionSolar cloud service is not bad, but I was hoping to connect to the device itself to be able to collect live parameters and plot it on Grafana (even when FusionSolar is offline).\nHopefully the inverter has the ability to expose the data using a Modbus protocol. There are three choices I am aware of:\nDedicated RS-485 connection from the inverter Internal WiFi USB dongle (WiFi/Ethernet) I have the ethernet cable routed to my inverter mounting place so a natural way of connecting it was using a dongle. Initially the dongle was not exposing the Modbus/TCP port, I had to upgrade a firmware. After the upgrade the 502 TCP port was open for communication (note: you need to explicitly enable this port on newest inverter/dongle firmware combinations).\nFinally I was able to monitor my device using this #3 method.\nProblems # More I was using the dongle, the more I was annoyed about the quality of the measurements. First of all reading a complete set of parameters took even roughly 20 seconds!\nMainly the reading was errorless, but overall when looking at a whole day, I noticed some significant error rate, especially in the early morning. Looking at the logs the following was not unusual picture:\nOverall, I was not happy with all this. I was even thinking that maybe the inverter itself is the one to blame (doing some daily tasks).\nAdditionally when there was a upgrade time of a FusionSolar infrastructure and a downtime for the service, the dongle has even more problems:\nI think it is configured that when there is no connection it is automatically rebooting itself in some specified time-intervals (probably to recover connection). I don\u0026rsquo;t need to say that every such a reboot is a gap in data collection :(\nAfter some longer period testing new inverter and dongle firmware versions and waiting for Huawei to eventually fix this\u0026hellip; I finally get tired of looking at the errors and returned to the roots: using a #2 method: connecting using internal WiFi (note: the inverter is currently using a new port 6607 instead of 502).\nResults # Despite the additional hardware (access point) near the inverter I am really impressed for new connection method comparing the old one. First of all the complete set of parameters are read in roughly 5 seconds instead of 20!\nI think that the following graph is self-explanatory:\nMoreover - my error log is totally clear!!! I have no lags/retries when reading the inverter data during whole day.\nConclusion # If you have a choice and want fast, stable and reliable TCP Modbus connection to the inverter use method #2 (internal WiFi).\nAs the RS-485 (method #1) is the industry standard, I believe it is also fast and reliable (but I don\u0026rsquo;t have a chance to test it myself yet).\nIf you are OK with the timings and don\u0026rsquo;t want to mess with additional WiFi client configuration - use an USB Dongle, but keep in mind that it is not the best, fast and reliable Modbus connection available. I think this is because the Dongle was designed with FusionSolar in mind and the Modbus is just an added feature (sadly with Huawei\u0026rsquo;s low priority).\n","date":"8 February 2022","externalUrl":null,"permalink":"/2022/02/huawei-sun2000-why-using-a-usb-dongle-for-monitoring-is-not-a-good-idea/","section":"Posts","summary":"","title":"Huawei SUN2000: why using a USB dongle for monitoring is not a good idea","type":"posts"},{"content":"","date":"8 February 2022","externalUrl":null,"permalink":"/tags/inverter/","section":"Tags","summary":"","title":"Inverter","type":"tags"},{"content":"","date":"8 February 2022","externalUrl":null,"permalink":"/tags/sun2000/","section":"Tags","summary":"","title":"Sun2000","type":"tags"},{"content":"","date":"16 September 2021","externalUrl":null,"permalink":"/tags/fusionsolar/","section":"Tags","summary":"","title":"Fusionsolar","type":"tags"},{"content":"FusionSolar is a Huawei platform for monitoring solar inverters, but it also have a interface for firmware upgrade.\nNote: This is probably only possible if you have the installer account.\nThis post describes how I did a firmware upgrade in the USB dongle of the SUN2000 inverter.\nLogin to FusionSolar and select Plants/Upgrade Management from the top menu:\nYou will see a new screen with all management requests. You need to add a new request. Click a blue \u0026quot; Add\u0026quot; button in the top right corner of the screen and you\u0026rsquo;ll see a new window:\nIn this window you need to select \u0026quot; Now\u0026quot; and fill all required fields - all needs to be filled - in above case I selected my USB dongle. The \u0026quot; Target version\u0026quot; is the desired firmware version which you want to upload to the device.\nAfter clicking OK the request is added to the list and the dongle is starting to upgrade. You can live see the upgrade progress:\nAfter the upload process is finished, the service shows the \u0026quot; Delayed\u0026quot; status - this is normal and it means, that the device is scheduled for reboot. Stay tuned, and after the reboot happened the following status is displayed:\nUpgrade process is now finished.\nIf you for some reason want to reset a device by yourself, then you can do so from Device Management, just select a device you want to manage and click its name, as shown below:\nThen from the Device Details page you can find a \u0026quot; Reset\u0026quot; button which you can use:\nAfter confirmation the device should reset (reboot in case of dongle).\n","date":"16 September 2021","externalUrl":null,"permalink":"/2021/09/how-to-do-a-firmware-upgrade-using-fusionsolar/","section":"Posts","summary":"","title":"How to do a firmware upgrade using FusionSolar","type":"posts"},{"content":"","date":"30 July 2021","externalUrl":null,"permalink":"/tags/ddwrt/","section":"Tags","summary":"","title":"Ddwrt","type":"tags"},{"content":"","date":"30 July 2021","externalUrl":null,"permalink":"/tags/hard/","section":"Tags","summary":"","title":"Hard","type":"tags"},{"content":" Intro # The Huawei SUN2000 inverter has a build-in/internal WiFi interface (SSID beggining with SUN2000-) which is exposing a Modbus TCP port (502). Using this connection you can obtain inverter data in the realtime and eg. collect it for your own purposes.\nHuawei Smart Dongle-WLAN-FE is also able to expose this Modbus TCP connection but for the time of writing this post - the firmware with this capability is only available upon e-mail request from the Huawei\u0026rsquo;s support.\nIf you for some reason want to connect to the Huawei SUN2000 inverter \u0026ldquo;the old/classic\u0026rdquo; way using the internal WiFi, and moreover you want to do it using DD-WRT then this article may be useful to you.\nThe hardware # For my testing purposes I have a spare TP-LINK TL-WR740N wireless router which I was planing to use to connect to the inverter\u0026hellip;\nIt has the ability to setup a port forwarding:\nThe SUN2000 internal WiFi act as a separate network with it\u0026rsquo;s own DHCP server. It was probably planned for initial configuration from the smartphone in mind. You cannot just bridge the WiFi into your home network. Moreover only one WiFi client is able to use the inverter at the same time.\nI thought that it will be sufficient to connect to the inverter and setup a TCP port 502 forwarding to be able to connect to the inverter from my LAN using this TP-LINK router.\nIt was not so easy!\nFirst of all the inverter seems to talk only to a client which was asking for a DHCP address, and furthermore it is not answering to other routed host addresses, it probably also has a TTL detection.\nSo even when I was successfully connected to the inverter (and ping from the router to inverter was working fine) the port forwarding method from the official software was not working.\nI decided to search for some alternative software and DD-WRT comes to my mind first as the quick and easy solution. Fortunately the router is supported and has a the following wiki page:\nhttps://wiki.dd-wrt.com/wiki/index.php/TP-LINK_TL-WR740N\nAccording to the above it should work with mine, which has the following hardware and software revisions:\nFew moments later I have a working DD-WRT in my TP-LINK :)\nTip: I had to disable the DHCP server on the LAN interface because it is enabled by default.\nInitial configuration # I needed to connect to the inverter as a WiFi client and obtain an address from a DHCP, so I set a WAN port to the wlan0:\nIn the Wireless/Basic menu I set the Wireless Mode to Client and entered the SSID of the inverter:\nIn the Wireless/Security menu I set the following security options:\nDefault password is Changeme as you can see in the above image, but I strong urge you to change it for the security reasons.\nThen in Setup/Basic Setup I selected \u0026lsquo;Automatic configuration - DHCP\u0026rsquo; for the WAN Connection Type.\nAfter this config the router was able to connect to the inverter which was visible here in the Status/Wireless:\nAnd also in the Status/WAN, where I can see an address obtained from SUN2000 internal DHCP server:\nI also set the Operating Mode as Router in the Setup/Advanced Routing:\nThe next step was to configure NAT for the 502 TCP port to be able to connect from the LAN to the inverter. The DD-WRT web interface also has the port forwarding setup similar as the original software:\nBut it was not working for the same reasons as described above\u0026hellip;\nFinal configuration # Fortunately the router can be accessed from SSH or Telnet and the iptables command is available :)\nWith this in mind it was very easy to create a two NAT rules from the CLI:\nSo I\u0026rsquo;ve typed:\niptables -I PREROUTING -t nat -p tcp -d 10.0.0.250 --dport 502 -j DNAT --to-destination 192.168.200.1:502 iptables -I POSTROUTING -t nat -d 192.168.200.1 -s 10/8 -p tcp --dport 502 -j SNAT --to 192.168.200.100 The POSTROUTING/SNAT rule is the most important as it \u0026ldquo;fools\u0026rdquo; inverter that the routed packets comes from the DD-WRT\u0026rsquo;s IP address.\nOf course the above is assuming that the router is configured with 10.0.0.250 address in the LAN and the WAN address of the inverter is 192.168.200.1.\nNow my connection to the inverter is working perfectly fine from my linux host which is collecting inverter data via hard:\n","date":"30 July 2021","externalUrl":null,"permalink":"/2021/07/how-to-connect-to-sun2000-from-dd-wrt/","section":"Posts","summary":"","title":"How to connect to SUN2000 from DD-WRT","type":"posts"},{"content":"","date":"30 July 2021","externalUrl":null,"permalink":"/tags/tplink/","section":"Tags","summary":"","title":"Tplink","type":"tags"},{"content":"If you want a simple and reliable solution for monitoring SUN2000 inverter and only collecting parameters to InfluxDB database I\u0026rsquo;ve added a support for this inverter in my hard.\nThe daemon is written in Rust and doesn\u0026rsquo;t need any special python/perl dependencies to work.\nThe SUN2000 can expose RS-485 data via internal WiFi interface or even (with newest firmware) via Smart Dongle-WLAN-FE.\nAll interfaces are well described here in this post:\nhttps://community.home-assistant.io/t/integration-solar-inverter-huawei-2000l/132350/136\nIf you build the hard, the following minimal config is needed to connect to inverter and pass the data to the InfluxDB:\n\\[general\\] log=/var/log/hard.log influxdb_url=http://127.0.0.1:8086 disable_postgres=1 disable_onewire=1 disable_webserver=1\n\\[sun2000\\] host=192.168.200.1:502\n","date":"25 June 2021","externalUrl":null,"permalink":"/2021/06/huawei-sun2000-monitoring/","section":"Posts","summary":"","title":"Huawei SUN2000 monitoring","type":"posts"},{"content":"","date":"25 June 2021","externalUrl":null,"permalink":"/tags/influxdb/","section":"Tags","summary":"","title":"Influxdb","type":"tags"},{"content":" The story begins\u0026hellip; # The day after April Fools\u0026rsquo; Day 2020 was not a funny day for me :(\nThat day my sleep was interrupted by a constant beep from the garage several minutes after 5 in the morning. I woke up from bed and go through complete blackout to the inverter.\nThere was only an annoying beep in my ears and a failure red diode with error code 09 on the front of the inverter. I also smelled a fried semicondutor in the air\u0026hellip; First thing which comes to my mind was that maybe there was some overload so I stupidly tried to start the inverter up for several times, I also discovered that main overcurrent protection for the AC-input was triggered down.\nBefore I shut all things down I only did this photo:\nThen I disconnected the inverter and created a bypass to have the power back on all devices\u0026hellip;\nVisual inspection # I removed the inverter from the wall and take out the cover. And this is what I saw:\nFrom the visual inspection I could see that the MOSFETs was broken and also some traces + resistors was also broken on the bottom of the main board.\nI decided to start googling if someone has similar failure and one of the first link was the AEVA Forums which was known to me.\nThere is a inverter repair topic which I read from the first to last post:\nPIP inverter repairs and hardware modifications\nMy main source of information was the above thread and also a service manual PDF for similar inverter. There was some differences but mainly it was very similar to mine.\nI am dropping this manual here for the reference:\nCopy_of_PIP-HS_MS_4-5KVA_new_Service_manual_201506A.pdf\nDiagnosis # My inverter all the time was running at about 25-30% load, no PV attached ever. It blow out almost 5 years from production date. The environment is hard: during summertime it is hot in the garage and parking a hot car doesn\u0026rsquo;t help either. Besides my electronic hardware, my fridge, freezer and water pumps (during winter) was also connected to the inverter output.\nNevertheless after some discussion it seems that the main problems was the drying out capacitors which could not filter out some spikes at some point and this can lead to broke the MOSFETs.\nThe plan and repair # Firstly my plan was to change the MOSFETs - the service manual advices to replace all MOSFETs even if only some was broken. There was also two resistors which I need to replace.\nAfter additional measurements it turns out that also two of the IGBT was broken (QB2 and QD2):\nTo sum it all, here is the complete list what I\u0026rsquo;ve replaced in my case:\n4x 4200uF/35V capacitors, replacement: EKZN500ELL332MM40S 16x IRFB3206 MOSFETs, replacement: IRFB3206PBF 1x SMD 200 Ohm resistor (in the MOSFET driver), replacement 1x SMD 10 Ohm resistor (in the MOSFET driver), replacement 2x GP4063D IGBTs, replacement: chinese clone from ebay Thanks God, so far it is working fine\u0026hellip;\nBig thanks to weber and coulomb from the AEVA Forums!\n","date":"12 July 2020","externalUrl":null,"permalink":"/2020/07/my-skymax-inverter-died/","section":"Posts","summary":"","title":"My Skymax inverter died...","type":"posts"},{"content":"","date":"12 July 2020","externalUrl":null,"permalink":"/tags/repair/","section":"Tags","summary":"","title":"Repair","type":"tags"},{"content":"","date":"23 April 2020","externalUrl":null,"permalink":"/tags/chieftec/","section":"Tags","summary":"","title":"Chieftec","type":"tags"},{"content":"During revive the retro computer I discovered a problem with a Chieftec power supply:\nAfter powering it up it is emitting high frequency noise, mainboard is not starting after pushing the power button.\nI connected the multimeter and measured the STB (standby) line (violet color in ATX connector) which has to be +5V. The result is around 500mV.\nAfter searching on forums:\nhttps://www.elektroda.pl/rtvforum/topic1259803.html\nhttps://www.elektroda.pl/rtvforum/topic1925712.html\nhttps://www.elektroda.pl/rtvforum/topic1098695.html\nhttps://www.elektroda.pl/rtvforum/topic3043926.html\nhttps://www.elektroda.pl/rtvforum/topic968105.html\nhttps://www.elektroda.pl/rtvforum/topic860735.html\nI\u0026rsquo;ve obtained information about similar problems and the schematic for this power supply:\nsirtec_chieftec_hpc-360-302_sch Download\nIt turn out that there is surely a problem with capacitors. I started with replacing two 3300uF/6.3V near the 3.3V line which was leaked (C13 and C15). Here are the new ones:\nNext I replaced the main cause of the whole problem: 22uF/50V capacitor marked as C34. After removing, I measured the capacity and it was dropped to 18uF, which is sufficient to raise the problem. I replaced it with same capacity but 100V, and also a little higher in diameter so I have to raise it a little on the legs:\nSoldering was a little problematic because it has a wire from another element in the same hole.\nAfter all this I was trying to power it up but unfortunately nothing changed :(\nIt was still generating this noise and standby line was not +5V.\nAfter further investigation it turns out that there is a protecting 5.6V zener diode (D14) which is the last resort for protecting the main board. I\u0026rsquo;ve unsolder one leg to check the diode for sure:\n\u0026hellip; and indeed that was a problem :)\nI could also see a little overheat under that diode which was not visible before:\nFinally I\u0026rsquo;ve replaced this zener diode with the other I have:\nAnd finally after powering it up I can see +5V on standby line and no more noise!!! :)\nPower supply is working properly!\nHere are all elements I\u0026rsquo;ve replaced:\n","date":"23 April 2020","externalUrl":null,"permalink":"/2020/04/chieftec-hpc-360-302-df-repair/","section":"Posts","summary":"","title":"Chieftec HPC-360-302 DF repair","type":"posts"},{"content":"","date":"15 March 2019","externalUrl":null,"permalink":"/tags/jlcpcb/","section":"Tags","summary":"","title":"Jlcpcb","type":"tags"},{"content":"Hello,\nAs you\u0026rsquo;ve probably seen (if you read my blog), my previous bus master was ugly, small and uncomfortable to use.\nIt was the high time to make something new\u0026hellip; :)\nConnecting 1-wire buses should be as easy as connecting a LAN cable to the switch. As all my 1-wire buses are wired using the ethernet cables, so I decided to use the 8P8C ( wrongly referred as RJ-45) connectors.\nMy plan was to take some old ethernet switch, remove its PCB and create my own to fit perfectly instead of the original one. After quick research I\u0026rsquo;ve decided to use the old Planet switch for this purpose ;)\nIt has a reliable, compact size metal case which I like very much.\nI only had to modify it a little (using a Dremel) to suit my needs.\nAt the beginning I was planning to make the PCB myself with home thermal-transfer method, but over a designing time I\u0026rsquo;ve change my mind :)\nFor the first time I decided to try a JLCPCB prototype manufacturer. It was a great decision! First of all because the quality of the boards cannot even be compared with a home-made PCBs, secondly because It would be really hard if not impossible (with reasonable size and look) to fit it all on one-sided PCB. The minimum at JLCPCB is a two layer board. Finally - the price was really great and acceptable - even including the shipping cost to the Europe!\nBefore you ask: this is not a sponsored article! :)\nMy bus connectors has to provide additional lines with voltages then only 1-wire bus data and ground. I needed to provide power for my PIR sensors and slave devices (I am not using a parasite power). As a result - I found and decided to use a 1WRJ45 standard for wires in 8P8C.\nAs an additional precaution I\u0026rsquo;ve also added a DS9503P ESD protection diodes to each channel of my DS2482-800 chip. I didn\u0026rsquo;t have this before.\nAlso for the first time I was using a KiCad EDA for designing the whole PCB. KiCad and its community is great! I also contributed a new footprint for the RJHSE5380-08 Amphenol connector because it was missing in the library.\nIt should be now available for everyone using KiCad :)\nI had a problem with following the tutorials on the official JLCPCB pages regarding the export settings. The settings which are provided on the images are in conflict with the video tutorial linking on the same page. Examples? Look:\nAs a result I just decided to leave the settings as default and only removed the unnecessary layers. For the reference, I\u0026rsquo;ve set it like this:\nFortunately I have no issues with the manufactured board with the above settings! :)\nYou\u0026rsquo;re probably curious how it all look like at the end. Here are the pictures:\n","date":"15 March 2019","externalUrl":null,"permalink":"/2019/03/jlcpcb-and-my-new-1-wire-bus-master-project/","section":"Posts","summary":"","title":"JLCPCB and my new 1-wire bus master project","type":"posts"},{"content":"","date":"15 March 2019","externalUrl":null,"permalink":"/tags/pcb/","section":"Tags","summary":"","title":"Pcb","type":"tags"},{"content":"","date":"11 March 2019","externalUrl":null,"permalink":"/tags/pulseview/","section":"Tags","summary":"","title":"Pulseview","type":"tags"},{"content":"","date":"11 March 2019","externalUrl":null,"permalink":"/tags/rigol/","section":"Tags","summary":"","title":"Rigol","type":"tags"},{"content":"","date":"11 March 2019","externalUrl":null,"permalink":"/tags/sigrok/","section":"Tags","summary":"","title":"Sigrok","type":"tags"},{"content":"Hi,\nI recently bought a new Rigol DS1074Z which is a great oscilloscope for hobbyist. The feature to price factor was really great and it also has a quite nice reviews, so I decided to give it a try :)\nQuick hardware overview # It is a 4 channel oscilloscope with 100 MHz bandwidth, 1 GSa/s and 24 Mpts memory depth. Depending on your need you may use the scope independently or connect it to computer for further processing.\nBecause the scope itself doesn\u0026rsquo;t have a build in one wire decoder and I want to decode one wire stuff so I was planning to use a PulseView from a sigrok suite.\nThe scope has a possibility to use the USB connection using bundled cable or use the ethernet port. I choosed the second because of flexibility.\nOf course I am not using Windows, so I was only taking into account a linux and opensource software to control this scope.\nI was certain that using the scope which has a supported status in sigrok will be easy cake, but as it happen often - it is at the time of writing this post - not quite true\u0026hellip;\nFirst problem is that memory acquisition to sigrok is not working, while Live waveforms has a too weak resolution to be able to decode a 1-wire.\nI\u0026rsquo;ve reported the problem to sigrok bugzilla.\nBecause directly using a sigrok was a no-go, so I just search for different software which is able to control the scope and specifically obtain a wavefrom from my its memory.\nIn the following text you\u0026rsquo;ll find my way to achieve this goal\u0026hellip;\nObtaining memory waveform data # First I\u0026rsquo;ve set a Memory Depth to 24M of sampled symbols:\nNext I\u0026rsquo;ve triggered a one wire sequence and noted the sample rate (it will be important later). In this example it is 250MSa/s.\nAfter a quick googling I found a nice tool: DSRemote written by Teuniz.\nI\u0026rsquo;ve compiled and installed it. After starting you can see the main screen:\nThe scope by default is obtaining the address from a DHCP server when starting or plugging in the LAN cable. After this you may configure IP address in the Settings and then connect to the scope:\nAfter connecting - the tool is constantly (with specified interval) obtaining the main waveform from oscilloscope screen:\nThe resolution is rather only for preview purposes and if you want to analyze the data you need to acquire the full wave data. Click the save menu and select Wave Inspector:\nNow the full-resolution waveform is downloaded from the scope:\nAfter downloading a new Wave Inspector window will appear. You can analyze the waveform or save it to external file. As the only way of exporting was the EDF format, which is rather exotic one (at least for me), so I\u0026rsquo;ve added a support for a RAW binary file output:\nAfter saving the file in RAW binary format you will be able to use the PulseView\u0026hellip; :)\nPulseView 1-Wire analyse # A PulseView is a excellent open-source tool for software signal analyzing!\nIf you start it for the first time you can see the demo session:\nTo create a new session click on the white square:\nTo import the data file in this new new session you need to click on arrow on the right of the Open icon:\nNow select Import RAW analog data without header option and point the file you saved from DSRemote.\nSaved file has a constant value of saved samples and it has only a binary data. You need to set additional information to have a proper data and its timing after load.\nIn our case we set the memory depth to 24M. Each sample is saved as 16 bit big-endian signed value. And as we noted the memory depth and sample rate at the beginning (after data are triggered) then we need to set the following parameters of RAW file:\nClick OK and PulseView will load the data:\nAs the data is a analog waveform you need to convert it to logical to be able to do protocol decoding. Click on yellow CH1 source name and set conversion to logic via schmitt-trigger:\nThe schmitt-trigger is a must because of fluctuations of raw analog data which can cause problems without this conversion type.\nNow the last part - adding a decoder. Click Add low-level, non-stacked protocol decoder and select 1-Wire link layer:\nThe decoder is not associated without any logical data at the beginning, so you need to click on it and select CH1:\nNow we can see the 1-Wire protocol data, but it is a link layer so we see a Reset/Presence pulses and decoded bits only.\nNow you can add a so-called Stack Decoder on top of 1-Wire link layer:\nSelect 1-Wire network layer and Voila!\nWe finally have a decoded one wire data:\nThat\u0026rsquo;s all for now! Enjoy and have fun! :)\n","date":"11 March 2019","externalUrl":null,"permalink":"/2019/03/using-rigol-ds1074z-oscilloscope-under-linux-and-pulseview/","section":"Posts","summary":"","title":"Using Rigol DS1074Z oscilloscope under Linux and PulseView","type":"posts"},{"content":"Hi! Recently I was playing with using my HID device differently then usual: I used the libusb library. Instead opening a raw file /dev/hidraw1, I used libusb_open_device_with_vid_pid(). Everything was working properly, then it was a time to go back using the hidraw file\u0026hellip; but wait: where is my hidraw1 device?\nIt seems it was gone since I opened it with libusb:\n# ll /dev/hidraw* crw------- 1 root 0 247, 0 Oct 19 18:49 /dev/hidraw0 crw------- 1 root 0 247, 2 Jan 1 1970 /dev/hidraw2 crw------- 1 root 0 247, 3 Jan 1 1970 /dev/hidraw3 As you can see - hidraw1 is missing.\nFortunately I found a solution to this issue which I am now sharing here (also for me). When I typed lsusb -t to list all my devices I\u0026rsquo;ve got:\n# lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 4: Dev 9, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 3: Dev 123, If 1, Class=CDC Data, Driver=cdc_acm, 12M |__ Port 3: Dev 123, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 123, If 0, Class=Communications, Driver=cdc_acm, 12M |__ Port 4: Dev 8, If 0, Class=Human Interface Device, Driver=usbfs, 1.5M The device which I want back is in the last line. Note the Driver=usbfs. This is the key part - the device is bound to usbfs driver instead of usbhid. I had to unbind the device from usbfs driver and bind back to usbhid. To do it I entered /sys/bus/usb/drivers/usbfs and typed:\n/sys/bus/usb/drivers/usbfs # ls -la total 0 drwxr-xr-x 2 root 0 0 Oct 23 18:35 . drwxr-xr-x 9 root 0 0 Oct 23 18:35 .. lrwxrwxrwx 1 root 0 0 Oct 23 18:42 1-1.3.4:1.0 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4:1.0 --w------- 1 root 0 4096 Oct 23 18:42 bind lrwxrwxrwx 1 root 0 0 Oct 23 18:42 module -\u0026gt; ../../../../module/usbcore -rw-r--r-- 1 root 0 4096 Oct 23 18:42 new_id -rw-r--r-- 1 root 0 4096 Oct 23 18:42 remove_id --w------- 1 root 0 4096 Oct 23 18:42 uevent --w------- 1 root 0 4096 Oct 23 18:42 unbind As you can see the device \u0026ldquo;1-1.3.4:1.0\u0026rdquo; (you can correlate this path with lsusb -t) is listed here (bound). I typed:\n/sys/bus/usb/drivers/usbfs # echo -n \u0026#34;1-1.3.4:1.0\u0026#34; \u0026gt; unbind sh: write error: No such device Despite this error when I looked again the device is not bind there anymore:\n/sys/bus/usb/drivers/usbfs # ls -la total 0 drwxr-xr-x 2 root 0 0 Oct 23 18:35 . drwxr-xr-x 9 root 0 0 Oct 23 18:35 .. --w------- 1 root 0 4096 Oct 23 18:42 bind lrwxrwxrwx 1 root 0 0 Oct 23 18:42 module -\u0026gt; ../../../../module/usbcore -rw-r--r-- 1 root 0 4096 Oct 23 18:42 new_id -rw-r--r-- 1 root 0 4096 Oct 23 18:42 remove_id --w------- 1 root 0 4096 Oct 23 18:42 uevent --w------- 1 root 0 4096 Oct 23 18:44 unbind Now it was a time to bound it to usbhid (first typing cd ../usbhid):\n/sys/bus/usb/drivers/usbhid # ll total 0 drwxr-xr-x 2 root 0 0 Oct 23 18:35 . drwxr-xr-x 9 root 0 0 Oct 23 18:35 .. lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.2.4.4:1.0 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2.4/1-1.3.2.4.4/1-1.3.2.4.4:1.0 lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.2.4.4:1.1 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2.4/1-1.3.2.4.4/1-1.3.2.4.4:1.1 lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.3:1.2 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.2 --w------- 1 root 0 4096 Oct 23 18:35 bind lrwxrwxrwx 1 root 0 0 Oct 23 18:35 module -\u0026gt; ../../../../module/usbhid -rw-r--r-- 1 root 0 4096 Oct 23 18:35 new_id -rw-r--r-- 1 root 0 4096 Oct 23 18:35 remove_id --w------- 1 root 0 4096 Oct 23 18:35 uevent --w------- 1 root 0 4096 Oct 23 18:35 unbind /sys/bus/usb/drivers/usbhid # echo -n \u0026#34;1-1.3.4:1.0\u0026#34; \u0026gt; bind /sys/bus/usb/drivers/usbhid # ll total 0 drwxr-xr-x 2 root 0 0 Oct 23 18:35 . drwxr-xr-x 9 root 0 0 Oct 23 18:35 .. lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.2.4.4:1.0 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2.4/1-1.3.2.4.4/1-1.3.2.4.4:1.0 lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.2.4.4:1.1 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2.4/1-1.3.2.4.4/1-1.3.2.4.4:1.1 lrwxrwxrwx 1 root 0 0 Oct 23 18:35 1-1.3.3:1.2 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.2 lrwxrwxrwx 1 root 0 0 Oct 23 18:45 1-1.3.4:1.0 -\u0026gt; ../../../../devices/platform/soc/20980000.usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4:1.0 --w------- 1 root 0 4096 Oct 23 18:45 bind lrwxrwxrwx 1 root 0 0 Oct 23 18:35 module -\u0026gt; ../../../../module/usbhid -rw-r--r-- 1 root 0 4096 Oct 23 18:35 new_id -rw-r--r-- 1 root 0 4096 Oct 23 18:35 remove_id --w------- 1 root 0 4096 Oct 23 18:35 uevent --w------- 1 root 0 4096 Oct 23 18:35 unbind And I\u0026rsquo;ve got back my missing hidraw1 device:\n~ # ll /dev/hidraw* crw------- 1 root 0 247, 0 Oct 19 18:49 /dev/hidraw0 crw------- 1 root 0 247, 1 Oct 23 18:45 /dev/hidraw1 crw------- 1 root 0 247, 2 Jan 1 1970 /dev/hidraw2 crw------- 1 root 0 247, 3 Jan 1 1970 /dev/hidraw3 The driver change is also confirmed in \u0026rsquo; lsusb -t':\n# lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 4: Dev 9, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 3: Dev 123, If 1, Class=CDC Data, Driver=cdc_acm, 12M |__ Port 3: Dev 123, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 123, If 0, Class=Communications, Driver=cdc_acm, 12M |__ Port 4: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M ","date":"23 October 2018","externalUrl":null,"permalink":"/2018/10/binding-unbinding-usb-drivers-a-k-a-who-stole-my-hidraw1-device-file/","section":"Posts","summary":"","title":"binding/unbinding usb drivers a.k.a. who stole my hidraw1 device file","type":"posts"},{"content":"Hi! As I sometimes have odd behavior with my Raspberry Pi (the USB/LAN is stopping working, while the whole raspberry does still work), I had to find out the method to debug this specific problem. Connecting HDMI display and a keyboard in place where I have it running would be problematic (besides - the USB keyboard also may not work if there are indeed USB problems), so a obvious choice was the UART connection in the Raspberry. In such cases I am generally soldering own connection to my old MAX3232 unit. This time I decided to buy dedicated board on ebay. Nowadays it is very cheap, universal (5V/3.3V jumper) and has dedicated PIN header for easy wiring. Last but not least - it also has a nice power/activity LEDs which are very useful. So overall - this was great advantages over my test board and it has the original FTDI chip! :)\nI ordered this one from ebay: I connected it to my Raspberry like this: The TX/RX lines has to be crossover-ed to make it working (FTDI module\u0026rsquo;s RX to Raspberry\u0026rsquo;s TX and vice versa). Don\u0026rsquo;t forget to set the voltage selection jumper to 3.3V to be compatible with Raspberry Pi signal levels.\nAfter physically connection I\u0026rsquo;ve make sure that my / boot/commandline.txt is properly configured. As of time of writing I have default values from the Raspbian which are:\nconsole=serial0,115200 console=tty1 This has to be sufficient to receive kernel debug logs over the serial connection.\nAfter realizing that the onboard connector is a Mini-USB, not a Micro-USB (yes, it matters ;) ) and after connecting the cable from my old Motorola RIZR Z8, I was ready for testing :) The FTDI device was successfully detected on my laptop and the /dev/ttyUSB0 was assigned. I\u0026rsquo;ve run the minicom like this:\nminicom -b 115200 -o -D /dev/ttyUSB0 And I was able to see the kernel logs when the Pi was booting up! So at least my RX line is working correctly :)\nAs my Raspberry is stripped down to fit in RAM, I had to manually enable getty on the serial connection to be able to use the serial port as a console terminal. For test I was trying to run it like this:\ngetty -L ttyAMA0 115200 vt100 -n -l /bin/sh But I\u0026rsquo;ve only got:\ngetty: setsid: Operation not permitted After googling for the similar problem I finally found this: https://unix.stackexchange.com/questions/196704/getty-start-from-command-line And this was the problem, I had to run it like this:\nsu root -c \u0026#34;getty -L ttyAMA0 115200 vt100 -n -l /bin/sh\u0026#34; Now I have a prompt on my serial connection. One step forward :)\nBut wait\u0026hellip; when I press enter/other characters in minicom - nothing happened\u0026hellip; The final solution was Ctrl-A, O ( cOnfigure minicom), and I had to disable Hardware Flow Control (F) Then all buffered characters was sent immediately :)\nConsole cable is now working in both directions, so I have a working debug solution for my RPi! :)\n","date":"30 May 2018","externalUrl":null,"permalink":"/2018/05/raspberry-pi-serial-console/","section":"Posts","summary":"","title":"Raspberry Pi's serial console","type":"posts"},{"content":"Hello. Yesterday I\u0026rsquo;ve updated the kernel on my RPi from 4.4.11+ to 4.14.31+. Unfortunately the i2c stopped working despite the module bcm2708_i2c loaded.\nTrying to add the ds2482 with command: echo ds2482 0x18 \u0026gt; /sys/bus/i2c/devices/i2c-1/new_device gives \u0026rsquo;no such file or directory\u0026rsquo; error.\nI reported this problem and have the answer 2h later! :) The problem was with the i2c module. It has changed. Moreover if old module was loaded (my case) it could interfere with the new one. Now a new module called i2c_bcm2835 have to be used instead. Note: the new module is not informing about the i2c initialization in the dmesg, like the old one. Keep this in mind if you\u0026rsquo;re playing with i2c on new raspbians and kernels :)\n","date":"1 April 2018","externalUrl":null,"permalink":"/2018/04/bcm2835_i2c-is-the-new-i2c-module-on-rpi-kernels/","section":"Posts","summary":"","title":"bcm2835_i2c is the new i2c module on RPi kernels","type":"posts"},{"content":"","date":"14 July 2017","externalUrl":null,"permalink":"/tags/grafana/","section":"Tags","summary":"","title":"Grafana","type":"tags"},{"content":" Camera overview # I have a cheap IP camera from Polish reseller ( ivel.com.pl). It is in fact a IP cam based on HiSilicon SOC. Manufacturer code is: LV-IP22IR40DVBL and it is available here.\nIn fact for this price the camera is quite nice. It has a solid aluminium outdoor case, the picture quality is great (even in night) because of the Sony Exmor CMOS; it has the ONVIF. So overall this is a nice piece of hardware. Only the software is not ideal (but when talking into account the price, it is understandable).\nThe camera has the following web interface:\nThe interface doesn\u0026rsquo;t allow to setup all camera parameters, so additional windows software was needed to configure it. I was using the \u0026ldquo;Golbong Software\u0026rdquo; to configure services, like NTP.\nThe problem # Last Tuesday after the camera maintenance reboot (oh yes: the camera is rebooting itself every week by default! As a programmer I hate this kind of workarounds. Why not making software reliable and got rid of all memory leaks?), the camera suddenly stopped working (and also doesn\u0026rsquo;t respond to ping). I thought that it may be a one-time problem, so I just simply cycled power, and it was working again.\nUnfortunately the same problem occurred again in about 10 hours. I was able to see this in grafana:\nThe first red line is the \u0026ldquo;maintenance reboot\u0026rdquo;, then the pings are raising and it freezes, the same problem occurred again in similar time. Generally the camera was working properly for about 10-11 hrs from startup/reboot.\nGetting shell :) # I was started to googling information about the camera software. Based on the version number, I was able to find two interested articles about similar cameras:\nhttp://marcusjenkins.com/hacking-cheap-ebay-ip-camera/ http://www.hkvstar.com/technology-news/china-ip-camera-configuration-firmware.html\nI found out that the camera has a \u0026ldquo;hidden\u0026rdquo; telnet debug service on TCP port 9527. After connecting to this port I\u0026rsquo;ve got a plenty of \u0026ldquo;garbage\u0026rdquo; on it:\n\u0026hellip; but at the end it was asking me for username and password. After providing the user and password (the same as for the web interface) I was able to do some nice things. There is a help command which shows available commands. Of course for me the most interesting was the \u0026ldquo;shell\u0026rdquo; command :)\nI typed it and got the shell, but there was some problem with EOL characters, so I followed the guide on some of the articles and typed:\ntelnetd -f This opened a regular telnet on port 23 on the device. So from another console I was able to telnet into it. Marcus Jenkins cracked a root password (xmhdipc) so logging to this device was really simple:\nSo I was able to monitor processes, free memory and connections. I was waiting for the next time when the camera again raises the ICMP responses, which clearly shows that it will freeze soon. When it happened I found out that killing the \u0026ldquo;Sofia\u0026rdquo; process makes the ping lowered back to normal (BTW: The debug messages which are in the debug port 9527 are from this Sofia process). Suddenly the camera has rebooted automatically and I\u0026rsquo;ve been disconnected. It was probably some watchdog. But I just know that the Sofia process has to be responsible for the problem.\nI also discovered the free memory before was 14804 and when the problem was occurring it was 11116. So for the first sight it looks like a memory leak or something similar to me.\nNext time I located the problem. The camera was connecting to some cloud services (vMEyeCloud) to china. And was also trying to obtain the public IP address via some service. It seems that last days the server response has to be changed somehow because I can see that I have a plenty of CLOSE_WAIT connections which was raising:\n# netstat -nap|grep CLOSE_WAIT tcp 2 0 192.168.0.12:41399 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41405 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41401 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41403 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41398 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41406 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41397 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41404 120.92.57.172:8086 CLOSE_WAIT 742/Sofia tcp 2 0 192.168.0.12:41400 120.92.57.172:8086 CLOSE_WAIT 742/Sofia [...] During the time when it was raising the ping responses, I had 457 such entries. Maybe not so big number, but it was enough for this SOC.\nThe resolution # The first thing which comes to my mind was to try to block the internet for this camera. So I did this \u0026hellip; and guess what? No more raising connection count. After waiting reasonable time I am now sure that it was the problem! The camera is not freezing anymore :)\nProbably the cloud services are also not working, but I am not using it. Besides it is now configured without internet access, which has to be done like this from beginning. Why it has to \u0026ldquo;spy\u0026rdquo; and connect to foreign servers? :)\n","date":"14 July 2017","externalUrl":null,"permalink":"/2017/07/how-to-hack-my-own-ip-camera/","section":"Posts","summary":"","title":"How to hack my own IP camera :)","type":"posts"},{"content":"Sometimes you need a very specific use case for your Raspberry Pi. The durability (and speed) of the SD card used in RPi may vary. Because of this I always tend to move Raspbian to an NFS share, and boot via NFS (root over NFS). This way I have the following advantages: 1. The SD card is only necessary to boot (single boot partition is sufficient) 2. Main root filesystem is on fast and durable NFS mount on the server 3. I am not limited by the SD card space in any way Doing the development/testing work is really nice this way.\nThe big disadvantage of this approach was the problems when the NFS server was gone for some reason. Generally the rpi was able to raise up after this and replace the NFS session (eg. after server reboot) with the following kernel messages:\nkernel: nfs: server \u0026lt;servername\u0026gt; not responding, still trying kernel: nfs: server \u0026lt;servername\u0026gt; OK But in some cases it was unable to do this and stucked:\nkernel: nfs: server \u0026lt;servername\u0026gt; not responding, still trying kernel: nfs: server \u0026lt;servername\u0026gt; not responding, timed out And in those cases a hard RaspberryPi reset was necessary to boot it up again.\nObviously in my automation use case I wanted the RPi to run independently and stable on its own. I did not want to put the whole system on the SD card, mainly due the SD durability and speed (and also limited storage space).\nSo I created a mixed solution, which I want to share below. It is a perfect one for me. My plan was to boot the system from the SD card via NFS (boot partition can be readonly - no writes to the SD card), then move only the necessary files to the RAM disk of the Raspberry Pi. And this is possible with pivot_root. :)\nKeep in mind that this method may be not suitable for some bigger projects with a lot of dependencies on external libraries. In my case the binary which I am running on the RPi is just a C++ program which is doing the automation, so it is really small and not depend on many external libraries (rather - the standard ones). It\u0026rsquo;s also important to know that the RAM usage on the RPi has to be monitored (at least after deploying) - more libraries and executables we put into RAM disk, less space is available to running programs. In my case of RPi model B rev 2.0 my RAM usage is about 11MB of the total 118MB available memory. OK, Let\u0026rsquo;s start from the beginning:\n1. Preparing the SD card # At the time I was doing the work the latest Raspbian version available was: 2016-05-27-raspbian-jessie-lite.img Of course I choosed the lite version because I don\u0026rsquo;t need a full distro. The rest of this \u0026ldquo;howto\u0026rdquo; is based on this specific version, but if nothing significant changed, I hope it should work with the recent versions as well :) Firstly I had to discover the partition list of downloaded SD card image:\n$ fdisk -l 2016-05-27-raspbian-jessie-lite.img Disk 2016-05-27-raspbian-jessie-lite.img: 1.3 GiB, 1387266048 bytes, 2709504 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6fcf21f3 Device Boot Start End Sectors Size Id Type 2016-05-27-raspbian-jessie-lite.img1 8192 137215 129024 63M c W95 FAT32 (LBA) 2016-05-27-raspbian-jessie-lite.img2 137216 2709503 2572288 1.2G 83 Linux So we have a boot partition started at sector 8192 and a root filesystem at sector 137216. To get the exact offset in bytes we have to multiply the sector number by sector size (512).\nI created a loop device for the boot partition:\nlosetup --offset 4194304 /dev/loop2 2016-05-27-raspbian-jessie-lite.img and mounted afterwards into raspbian_boot directory:\nmount /dev/loop2 ./raspbian_boot I have access to original boot files from Raspbian (raspbian_boot), so it was a time to prepare the target location for files. I found the old 16MB SD card (bundled with my canon camera) and since it should be sufficient for boot partition, I just gave it a try. Indeed, it was working properly, I just had to format the boot partition as FAT16, because there was not enough space for FAT32. After creating a target partition, I stripped the original Raspbian boot files to the really needed necessary ones for my Raspberry Pi model B. It was sufficient for me to copy the following files to my target boot partition: bcm2708-rpi-b.dtb bootcode.bin cmdline.txt config.txt kernel.img start.elf\nI edited the config.txt and enabled the i2c by commenting out the line:\ndtparam=i2c_arm=on Then I modified the original cmdline.txt and enabled NFS boot:\ndwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs ip=dhcp nfsroot=192.168.0.1:/exports/rpi,nfsvers=3,tcp elevator=deadline rootwait After unmouning, the SD card was ready to insert into Raspberry Pi.\n2. Preparing NFS share on server # Then I was able to mount the main filesystem from the raspbian image:\nlosetup --offset 70254592 /dev/loop2 2016-05-27-raspbian-jessie-lite.img mount /dev/loop2 ./raspbian_rootfs I copied all files to my local directory of the NFS export:\nrsync -xav raspbian_rootfs/ /exports/rpi/ and added the following line to the /etc/exports:\n/exports/rpi 192.168.0.4/32(rw,no_root_squash,async,no_subtree_check) and reloaded the exports with:\nexportfs -ra I also added in the /etc/fstab in the RPi rootfs the line:\n/dev/nfs / rootfs defaults while also commented out the original rootfs mount (/dev/mmcblk0p2)\nAt this stage a normal \u0026ldquo;full\u0026rdquo; Raspbian should be able to boot from NFS on the Raspberry Pi.\n3. Preparing to pivot_root # On the Raspberry, I\u0026rsquo;ve installed the dropbear and busybox-static packages:\napt install dropbear busybox-static After installation, all necessary files was in place. In the root NFS directory I created a three scripts for doing all necessary jobs:\nScript called root2ram.sh is for doing early work and pivot_root:\nIn cmdline.txt on the SD card I changed the initial script run on boot, appending: \u0026quot;-- \\root2ram.sh\u0026quot;. Full line after this change was:\ndwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs ip=dhcp nfsroot=192.168.0.1:/exports/rpi,nfsvers=3,tcp elevator=deadline rootwait -- /root2ram.sh When the rpi is doing the pivot_root switch it is launching the busybox. Busybox is in turn starting /etc/init.d/rcS which in my case has the following contents:\nThe last script is fs_prepare which is called from rcS. It is used for the necessary file copy for the new filesystem. You have to figure out yourself what libraries and binaries are necessary for your configuration ( ldd tool is your friend). In my case the file has the following contents:\nAfter all this steps - my Raspberry Pi successfuly booted from NFS to ramdisk. I am then able to umount the original NFS with this command:\numount /old_root And the RPi is still running fine :) I can ssh into it (it has the dropbear running) and it is working really fast, because the whole system is in RAM. When I needed to do some jobs (eg. compilation) on the \u0026ldquo;original\u0026rdquo; NFS system, then I am just mounting it with the following command:\nmount -t nfs -o nolock 192.168.0.1:/exports/rpi /old_root and then chroot into it:\nchroot /old_root /bin/bash Bonus: Running it under QEMU # You can also boot this NFS share under QEMU. This way you can test all changes before running it on the real RaspberryPi. To be able to run it, you need to install the qemu-system-arm package in your linux distro. You also need a modified kernel. In my case (for the above Raspbian version) I had to use a kernel named: kernel-qemu-4.4.11-jessie. Which at the time of writing is available for download from this github repo: https://github.com/dhruvvyas90/qemu-rpi-kernel\nIn the NFS share are though required some small changes: 1. in /etc/ld.so.preload you need to comment the line:\n/usr/lib/arm-linux-gnueabihf/libarmmem.so 2. in /etc/fstab disable all lines which are for mounting filesystems from SD card (line starting with: /dev/mmcblk0)\nAfter this changes you can run the emulator, eg. like this:\nqemu-system-arm -kernel kernel-qemu-4.4.11-jessie -cpu arm1176 -M versatilepb -append \u0026#34;root=/dev/nfs ip=10.0.2.15::10.0.2.1:255.255.255.0 nfsroot=10.0.2.2:/exports/rpi,nfsvers=3,tcp\u0026#34; -clock dynticks -redir tcp:8022::22 The rpi ssh port (22) is redirected to port 8022 on localhost (using a QEMU window as a terminal may be slow and not comfortable).\nHere you can find useful information about preparing the Raspberry Pi kernel for the QEMU: https://github.com/cantora/qemu-arm-rpi-kernel\n","date":"11 April 2017","externalUrl":null,"permalink":"/2017/04/rpi-creating-a-ram-disk-running-linux-environment-from-nfs-booted-raspbian/","section":"Posts","summary":"","title":"RPi: creating a RAM-disk running Linux environment from NFS booted Raspbian","type":"posts"},{"content":"I am using the SKYMAX Expert MEX 3K-24 inverter. In fact it is identical with Voltronic Power Axpert MEX 3K-24, it was just rebranded by a Polish company.\nIt is a 24 volts model, so I am using a two 12V 100Ah batteries connected in series (lead-acid automotive batteries): I hope it will work longer then the batteries for APC 1400VA UPS, which I had before (and had to buy and replace batteries very often). The model is not a hybrid one, which I\u0026rsquo;d love to have but for my purposes it is working really great so far. The inverter has an integrated USB connector, so there is a way to communicate with the device.\nThere is some creepy monitoring software called WatchPower, which is moreover written in Java: There is even also a console version of the management software which can be run on Linux, but it also need Java (JRE) :o Monitoring the inverter with this software on Raspberry Pi would be painful, so it was a time to discover how to do it the proper way ;)\nAfter plugging the USB to the Raspberry I\u0026rsquo;ve got in dmesg:\n[ 523.116132] usb 1-2: new low-speed USB device number 2 using uhci_hcd [ 523.329148] usb 1-2: New USB device found, idVendor=0665, idProduct=5161 [ 523.329160] usb 1-2: New USB device strings: Mfr=3, Product=1, SerialNumber=0 [ 525.073328] hidraw: raw HID events driver (C) Jiri Kosina [ 525.111176] usbcore: registered new interface driver usbhid [ 525.111184] usbhid: USB HID core driver [ 525.213484] hid-generic 0003:0665:5161.0001: hiddev0,hidraw0: USB HID v1.11 Device [HID 0665:5161] on usb-0000:00:1d.0-2/input0 So it is a HID device visible in lsusb as:\nBus 001 Device 002: ID 0665:5161 Cypress Semiconductor USB to Serial I sniffed with wireshark how the original program is talking to the device and I see that it is some pseudo-ASCII protocol. The commands generally starts with Q letter, ie: QPI, QSID, QPIRI, QDI, QPIGS and the responses started with the \u0026lsquo;(\u0026rsquo; mark, and the results like this:\n(230.1 49.9 230.1 49.9 0529 0483 020 393 27.03 000 100 0040 0000 000.0 00.00 00000 00010101 00 00 00000 110 At the end of the line is a two-byte CRC and new line character.\nI\u0026rsquo;ve entered some of the command into Google to get some information about this protocol. I have found great Australian and New Zealand forums with much information about the protocol and the hardware (maybe it\u0026rsquo;s more common at those markets). The most valuable for me was these two threads: infinisolar 3k Plus realtime values and logging PIP-4048MS and PIP-5048MS inverters\nBased on this information I was able to integrate the support for the inverter in my Raspberry Pi. There is no HID driver for the inverter, so I just used a generic device file: /dev/hidraw0.\nIn fact the most interesting commands for my constant monitoring was: QPIGS - status (input, output voltages, currents, load, etc.) QMOD - current mode (power-on, standby, line mode, battery mode, etc.)\nSo now instead of using the bloated Java software, I am just using simple and pure C code for monitoring the inverter on my RPi. I created a sample demo project on github, so you can have a look or test how to query the inverter: https://github.com/manio/skymax-demo\nAs usual I am providing some sample grafana plots, which I like very much in contrast to original software ;)\n","date":"23 March 2017","externalUrl":null,"permalink":"/2017/03/monitoring-voltronic-power-axpert-mex-inverter-under-linux/","section":"Posts","summary":"","title":"Monitoring Voltronic Power Axpert MEX inverter under Linux","type":"posts"},{"content":"In this post I want to share with you how I did the humidity measurement in my bathroom. Because I already have 1-Wire buses all over my house measuring temperatures (DS18B20), sensing my switches (DS2413) and controlling relays (DS2408), so logical step was to measure the humidity also using the 1-Wire bus. I used the Google and found out that a solution was available: http://rants.dyer.com.hk/rpi/humidity_1w.html Allan, here I want to thank you for your helpful article and support :)\nI also found similar projects using DS2438 here: http://www.phanderson.com/rh166/rh166.html http://archives.sensorsmag.com/articles/0501/34/main.shtml https://www.mrsoft.fi/humi.htm\nAs usual I examined all schematics, chosed the Allan\u0026rsquo;s one and customized it a bit: As you can see I decided to use a HIH-4000-003 instead of HIH-5030-001.\nI designed a very simple PCB: Using the toner transfer method I created and assembled the board:\nI connected all needed wires (GND, 1wire and +5V) and made first tests on my desk. I had to use OWFS (for the first time! ;) ), because there was no kernel module for DS2438 at that time. The DS2438 device was properly discovered on the bus, so I started to read a configuration register and measure some values. It was working correctly!\nFinally I installed the sensor in the target location, in my bathroom:\nTo be able to measure the real humidity in %RH, I have to obtain these values: - supply voltage (VDD) - A/D voltage from the HIH (VAD) - temperature (DS2438 has built-in temperature sensor) The formula is in the HIH-4000 series datasheet.\nThe last problem to solve was to obtain these values from DS2438 on my Raspberry Pi. I have customized Linux environment running on the Pi, so of course I will not run OWFS on it. Allan Dyer is sharing on his page a perl script which is doing the measurement using the generic rw sysfs file, but according to him, it is very slow (~26 seconds per single measurement). Obviously this was unacceptable in my application, so I just did what I was planning from the beginning: writing own kernel module for DS2438 :) At the time of writing this post, my patches are approved and waiting for next merge window to be upstreamed. If everything goes according to the plan, the module should be available in kernel 4.12.\nOne way or another, I am currently using this module on my Raspberry Pi. Measuring the voltages and temperature is as easy as reading the sysfs files. Then I am just calculating a real humidity value from the userspace:\nI am also clearing the IAD configuration bit to 0 (once at system start), because I don\u0026rsquo;t need the DS2438 to measure current A/D data and shadow it to the EEPROM (it is doing this by default).\nNow I am finally able to control the fan in my bathroom basing on the humidity value :) Watching the humidity in the Grafana is also nice thing to have: ","date":"11 March 2017","externalUrl":null,"permalink":"/2017/03/ds2438-based-1-wire-humidity-sensor/","section":"Posts","summary":"","title":"DS2438-based 1-Wire humidity sensor","type":"posts"},{"content":"I wanted to make my home automation to be cheap. Commercial solutions, like KNX was a way too expensive for me; besides creating own system gives great benefits like better knowledge about how it works, possibility to customize it to my needs (including software) and of course much fun :) So I just bought some 5V 8-channel relay boards on the eBay. Because it has 8 channels to control, so I used a DS2408 8-channel, programmable I/O 1-Wire chip. There was a kernel module for this chip (w1_ds2408). So the only thing left, was to design a small board for DS2408 which I could then connect to the 1-Wire bus:\nThe Vcc and GND is connected on the right side of the relay board. Because my DS2408 board is powered from the same power source as the relay board, so the GND is common. At idle state there is a logical \u0026ldquo;1\u0026rdquo; on all inputs - all relays are \u0026ldquo;off\u0026rdquo;. To switch \u0026ldquo;on\u0026rdquo; the relay, the DS2408 just pulls selected input to GND.\nFirstly I designed this board with the DS1811 power-on-reset circuit. It was working quite nice but only without load. When I was switching the relays with 230V of load, that was triggering the DS1811 power-on-reset chip and the DS2408 was resetting. I removed that DS1811 and inserted a 10K resistor between Vcc and the RSTZ pin instead (I wanted all relays to be \u0026ldquo;off\u0026rdquo; after powering on). I also added a 47uF electrolytic capacitor near the power input to suppress the noise. After that fixes, controlling the relays is now working stable :)\nEvery board has it\u0026rsquo;s unique address, so to control the relay board I just need to send a one-byte value to the module\u0026rsquo;s sysfs output file, for instance:\n/sys/bus/w1/devices/29-0000001137c7/output Every bit from that byte corresponds to specific relay of the relay board. Simple as that :)\n","date":"9 March 2017","externalUrl":null,"permalink":"/2017/03/controlling-relay-board-with-ds2408-over-1-wire/","section":"Posts","summary":"","title":"Controlling relay board with DS2408 over 1-Wire","type":"posts"},{"content":"This time - something not strictly related with electronics and home automation :) Ok - maybe a little - if you own intelligent weighing machine and want to connect it directly to your central computer ;)\nEvery week after weighing in, I had to save my results to: - Endomondo - MyFitnessPal - Grafana (local storage)\nIt was a little annoying to enter the same weight at those places. So I spent some time on this and created a simple bash script to take care of this :)\nIt is taking one argument, which is the weight, and then it does: - logging in to MyFitnessPal, saving the weight, logging out - saving the data to InfluxDB - starting a web browser with the grafana dashboard and results\nMy motivation dashboard in the Grafana looks like this: I didn\u0026rsquo;t cope with saving to Endomondo yet but I am providing you mentioned bash script which you may find useful:\nIf you have done automated Endomondo weight saving, let me know!\n","date":"8 March 2017","externalUrl":null,"permalink":"/2017/03/automate-my-weekly-weight-logging/","section":"Posts","summary":"","title":"Automate my weekly weight logging","type":"posts"},{"content":"","date":"8 March 2017","externalUrl":null,"permalink":"/tags/endomondo/","section":"Tags","summary":"","title":"Endomondo","type":"tags"},{"content":"","date":"8 March 2017","externalUrl":null,"permalink":"/tags/myfitnesspal/","section":"Tags","summary":"","title":"Myfitnesspal","type":"tags"},{"content":"","date":"3 March 2017","externalUrl":null,"permalink":"/tags/dedietrich/","section":"Tags","summary":"","title":"Dedietrich","type":"tags"},{"content":"When my boiler was properly detected and connected and I was sure that I can \u0026rsquo;talk\u0026rsquo; to it using the Recom protocol, I had to make the connection permanent and constantly query it from my Raspberry Pi.\nThe boiler has 5V TTL signal level and I have an F/UTP cable placed from RPi to the boiler, so I could do it via ethernet. I was considering the following options: - Arduino which act as a serial port server - integrated serial port server board, like USR IOT - ESP8266 - USB connection - build a dedicated PCB\nAdditional problem was, that I wanted to power it from the same ethernet line (like PoE). Because it is a gas boiler - I also wanted to have some kind of opto-isolation.\nI have to admit, that this time I was lazy and didn\u0026rsquo;t want to bother with preparing the PCB, soldering, etc :) So I started to consider the options left:\nESP8266 was a nice choice, but I\u0026rsquo;d probably also need a dedicated power line and WiFi on the other end near the Raspberry Pi (I have no integrated radio in my RPi).\nUSR IOT unfortunately doesn\u0026rsquo;t have (at that time) any module with 5V TTL logic (they are mainly using 3.3V on the board which I was taking into account). Neither have an optocoupler. They only have a 5V devices as RS232 or RS485 to Ethernet. So I\u0026rsquo;d need some additional level shifter and optocoupling. Converting from RS232 to RS485 was also not the way I like.\nFor Arduino I would need ethernet version or shield with PoE and making/buying an optocoupler for the serial connection. It was making it rather complex and expensive solution, not mentioning that I would also need to write and deploy a firmware for it (additional work hours).\nFinally I choose the USB connection. Why? Because it was the simplest to do and cheapest solution for me (not counting the USB hub) :) I ordered this three things:\ni-tec USB 2.0 Charging HUB, U2HUB412, a \u0026ldquo;pluggable\u0026rdquo; clone: MCP2200 USB-UART based Optically Isolated Serial Converter: USB Extension Ethernet RJ45 Cat5e/6 Cable LAN Adapter Extender Over Repeater Set: With the above set I am now able to directly talk to the DeDietrich boiler using a /dev/ttyACM0 serial device under Raspberry Pi.\nI created a small case for the PCB, mounted in on the wall and connected to the Raspberry Pi over the LAN extender:\nBy default the Recom application is querying the boiler every second. In my case I lowered the interval to 5 seconds, which is more appropriate for collecting the data in the long term.\nI created a sample demo project on github, so you can have a look or test how to query the boiler: https://github.com/manio/remeha-demo\nNow I am able to fill the InfluxDB with the boiler data and finally create a nice graphs from its work: This type of connection is only suitable for monitoring the boiler, and even set some parameters. The big downside is that I am still unable to set/force a temperature setpoint.\nTo have this possibility, I\u0026rsquo;d need to build the Opentherm Gateway. and connect it via OpenTherm connector between the boiler and the DeDietrich iSense controller. Maybe some day\u0026hellip; ;)\n","date":"3 March 2017","externalUrl":null,"permalink":"/2017/03/monitoring-dedietrich-from-linux/","section":"Posts","summary":"","title":"Monitoring DeDietrich from Linux","type":"posts"},{"content":"","date":"3 March 2017","externalUrl":null,"permalink":"/tags/remeha/","section":"Tags","summary":"","title":"Remeha","type":"tags"},{"content":"I have a DeDietrich MCR3 24/28MI boiler. Of course I was planning to obtain as much information as I could from it. I\u0026rsquo;d like to monitor its work and create some nice graphs ;) I found out quickly that the brand is in fact called also Remeha. I read in the manual that it has a \u0026lsquo;RS232\u0026rsquo; port. The \u0026ldquo;special cable\u0026rdquo; and software called \u0026ldquo;Recom\u0026rdquo; was needed to connect it to the laptop/PC. My boiler looks very similar to the Remeha Calenta. I also found interesting information on Robert Hekkers\u0026rsquo; blog, who was doing the same things: http://blog.hekkers.net/tag/remeha/\nI had to locate the serial port for communication. After opening the case up, I easily located it on the main board (it is called \u0026ldquo;PC\u0026rdquo; and it is next to \u0026ldquo;HMI\u0026rdquo; port). As described on Robert\u0026rsquo;s blog, it is the 4P4C connector. I decided to try connecting my laptop to this port first, to be sure that it is possible to communicate with it using the Recom software at all. Firstly I measured the voltages on the pins. Fortunately it was matching Robert\u0026rsquo;s description: +5V, GND and probably TX and RX. So far so good :) It is not a true RS232 signal levels, but a 5V TTL.\nI found my old development board with the MAX3232 on it, so I joined the schematics of MAX232 from: http://blog.hekkers.net/2010/10/03/monitoring-the-remeha-calenta/ and and 4P4C pin description from: http://blog.hekkers.net/2011/03/14/remeha-interface-revisited/ \u0026hellip; and soldered it all together.\nI gently connected it to the boiler and to the laptop via FTDI/USB dongle and started the Recom software to detect the boiler. Unfortunately - no luck, every time the software was unable to detect the boiler :( I even changed the dongle to the Prolific-based one, but with the same bad results.\nNext day, I reviewed my connections one more time. All seems correct for me. My last chance was swapping the TX/RX pins and\u0026hellip; it worked immediately! The boiler was finally detected! btw: my boiler is detected by Recom as \u0026ldquo;Tzerra Export\u0026rdquo;.\nSo the problem was with the misleading description (or the true meaning of the TX/RX signals). The problem is that a name TXD could mean a TXD pin of the boiler or a pin to which it has to be connected in the MAX232 :) In this case, Robert\u0026rsquo;s description of the TXD and RXD was not the boiler signals, but a pins, to which it has to be connected. I know, I know - the blog says that the lines has to be swapped in case of problems :)\nI lost a day because I was pretty sure about my TX/RX wiring, so for the reference, I am providing a correct pinout:\npin #kinddescription****to MAX232 pin1GNDground15: GND2RXboiller\u0026rsquo;s RX (input)9: R2 out3TXboiller\u0026rsquo;s TX (output)10: T2 in4VCC+5V16: VCC\n","date":"3 March 2017","externalUrl":null,"permalink":"/2017/03/connecting-dedietrich-mcr3-to-pc-via-serial-connection/","section":"Posts","summary":"","title":"Connecting DeDietrich MCR3 to PC via serial connection","type":"posts"},{"content":" Bit bangling # When I bought my brand new Raspberry Pi in 2012 (model B, version 2.0 with 512MB of RAM), then I needed a stable 1-wire bus for my home automation. Firstly I was testing it with w1-gpio kernel module which is emulating a 1-wire bus master using a bit-bangling (software) method:\nAs a result I had a plenty of errors when communicating with slave devices. Then I connected it with additional 101 meters of cable at the beginning of the bus:\nThe result was even worse: with 8 slaves I had about 1/3 communication errors, while with 22 sensors all of them was returning 0xFF as a read values. I also have to note that the CPU usage using this bit-bangling method was high.\nUsing dedicated 8 channel 1-Wire master (DS2482-800) The previous results shown that bit bangling method is not bad but only for several slaves and short connections. The Raspberry Pi has a hardware i2c bus - and this was what I was looking for, so my next step was testing dedicated i2c \u0026lt;-\u0026gt; 1-Wire bus master chip. I ordered the DS2482-800 and created a PCB with 8 buses:\nConnecting to the Raspberry Pi was as easy as connecting those four pins: DS2482-800****Raspberry Pi GPIO headerVCCPin 1 (3.3V)SDAPin 3 (SDA)SCLPin 5 (SCL)GNDPin 9 (GND) Before I connected it to the RPi, I unloaded the w1-gpio and typed:\nmodprobe i2c-bcm2708 as a result kernel dmesg shows this:\n[ 27.431490] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79) [ 27.556912] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) [ 44.040315] i2c /dev entries driver Important: read also this article.\nTo be sure I detected devices on i2c:\nroot@raspberrypi:~# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Correct - no device so far. Then I connected the DS2482-800 and redo the detection:\nroot@raspberrypi:~# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Great - a device on 0x18 address. Now I was ready to load the ds2482 module with:\nmodprobe ds2482 then I had to associate i2c device with this module typing:\necho ds2482 0x18 \u0026gt; /sys/bus/i2c/devices/i2c-1/new_device and in dmesg I\u0026rsquo;ve got:\n[ 1260.473311] i2c i2c-1: new_device: Instantiated device ds2482 at 0x18 As a result I\u0026rsquo;ve got 8 bus masters at: /sys/bus/w1/devices/w1_bus_masterX, where X is the bus number\nTo be able to use more slave devices I had to modprobe the wire module with max_slave_count parameter, like this:\nmodprobe wire max_slave_count=30 After I have the bus master working I did a test with two buses connected to the master using short cables:\nThe result was great - the CPU usage was nearly zero and no communication errors. It was a time to check this using longer cables: I connected several cables with a total length of 45.2m and 22 slave devices (mixed in the middle and also at the end of the bus):\nResults? None of communication errors! All was working really stable even with this bus length :)\nAfter all slaves on buses are detected, then it\u0026rsquo;s also worth (when you have static configuration) to disable scanning for new devices. It was locking communication with my slave devices on regular intervals and searching for new devices. I\u0026rsquo;ve disabled searching with the following commands:\necho 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master1/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master2/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master3/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master4/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master5/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master6/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master7/w1_master_search echo 0 \u0026gt; /sys/bus/w1/devices/w1_bus_master8/w1_master_search Conclusions # Maybe the conclusion was obvious to you - but for the record: If you are playing with 1-wire and use it for small amount of slave devices and with short length - a w1-gpio module and bit-bangling should be sufficient. If you will be using it with lengthy buses (maybe even more then single one) and more slave devices - better use a dedicated DS2482 i2c bus master for this :)\n","date":"28 February 2017","externalUrl":null,"permalink":"/2017/02/raspberry-pi-1wire-bus-master/","section":"Posts","summary":"","title":"Raspberry Pi 1-Wire tests, DS2482-800","type":"posts"},{"content":"For years I am using a great 5.1 speaker system: Cambridge SoundWorks DTT 3500. It was quite expensive at the time when I was buying it, but it is still playing really great nowadays. Of course it is not a top product for audiophiles, but the sound quality is totally sufficient as a 5.1 speakers to the Kodi media center in my living room. To be able to use it with my new PC, I had to switch my source from original Digital-DIN (Creative-only audio cards, like SB Live/Audigy) to more general and wide used: optical output of my Asus mainboard.\nUnfortunately when I switched to optical a new problem occured. The amplifier had to warm up before it was playing correctly. When I powered it up it was crackling and the Dolby Digital indicator LED was blinking. The playback settled down usually after about 3-5 minutes. When the amplifier was warmed up, cycling power doesn\u0026rsquo;t do any harm - it was ready for work. I was suspecting the capacitors.\nHappily google helps me a lot with this issue: I found this forum thread on Overclockers Forums: http://www.overclockers.com/forums/showthread.php/508585-DTT3500-needs-to-quot-warm-up-quot\nThis was it! The guys have identical problem and a cure for it! Under the Faraday cage three capacitors needs to be replaced. I decided to buy and replace those three capacitors.\nFirst I was searching for these capacitors at TME, but all of them was too high to fit under the Faraday cage (it has to be low profile, 7 mm max).\nFortunately the guys on the forum also provided a part numbers for some popular electronic online stores. After some basic research i decided to go with Farnell element14. I ordered the following capacitors: http://pl.farnell.com/jsp/search/productdetail.jsp?CMP=i-ddd7-00001003\u0026amp;sku=1901998 http://pl.farnell.com/jsp/search/productdetail.jsp?CMP=i-ddd7-00001003\u0026amp;sku=1902049 http://pl.farnell.com/jsp/search/productdetail.jsp?CMP=i-ddd7-00001003\u0026amp;sku=8766916\nThe shipment was really cheap: 16PLN (considering the package was from UK to Poland). And what was really cool: I have the package next day after placing the order!\nI was ready to start the process. The forum thread has many information, tips and photos which was really helpful. Nevertheless I will provide also mine photos from the work. Maybe you will also find it helpful if you are in the similar situation :)\nIncluding assembling, the whole work took me about 3-4 hrs. I was not disassembling the main volume knob so I had to be careful about a wire which was constantly connected to it. As I suspected, I had some small problems soldering out the Faraday cage. I was using a hot air tube for this but the board resisted much (and was also deforming a little when I was trying to pulling it out), but finally I\u0026rsquo;ve made it - it was also probably because some kind of glue on the soldering pads. The capacitor replacement was much nicer; soldering the cage back was the easiest task. As you can see on last photos I have another one capacitor leaked, but due to the fact that I was not prepared to replace this one - I just leave it untouched - so far without any harm in my case. I can also see that this capacitor is bad eg. here on the following pics:\nhttp://www.overclockers.com/forums/attachment.php?attachmentid=68204\u0026amp;stc=1\u0026amp;d=1222461534 http://www.overclockers.com/forums/attachment.php?attachmentid=170092\u0026amp;d=1445418199\n\u0026hellip; so this seems to be another general problem with this hardware.\nAfter reassembling and connecting back to speakers, there was a moment of truth. Fortunately - the operation went successfully - no crackling, Dolby Digital LED still green - all is working great!\nBefore, it was really annoying when I had to power it up, then go somewhere waiting until it stop crackling, go back and use it. Finally I can now power up my amplifier whenever I want and just start use it immediately! This is really awesome!\nBig thanks for guys from Overclocker Forums!\n","date":"27 February 2017","externalUrl":null,"permalink":"/2017/02/fixing-my-dtt3500/","section":"Posts","summary":"","title":"Fixing my DTT3500","type":"posts"},{"content":"Welcome to my blog!\nFor a long time this site was holding some static sub pages for my small projects. Finally I decided to move it to a wordpress because with ability to creating posts, tagging and commenting I think it will better suits my needs.\nI hope you enjoy the content. It will be mainly about electronics, Raspberry Pi, Linux and home-automation related things. From time to time I am going to post some stuff about things I\u0026rsquo;ve done or I am already doing. I think it may be valuable to you and even for me when I need to remind related things or schematics later.\nAll information on this page is only for education/information, be careful with all the electronic stuff. I am not responsible for any damages or problems you may encounter.\nHave fun! :)\n","date":"27 February 2017","externalUrl":null,"permalink":"/2017/02/hello-world/","section":"Posts","summary":"","title":"Hello world!","type":"posts"},{"content":"","externalUrl":null,"permalink":"/all/","section":"skyboo.net","summary":"archives","title":"All","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/search/","section":"skyboo.net","summary":"Search","title":"Search","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]