Random thoughts...
While developing an app for Android I've been using the newest navigation version from compose, 2.8.3. This allows for much more flexibility around defining routes, but it did throw up an issue that took a while to figure out. Bottom Navigation Bar Looking at the sample
After more experiments it became apparent that for current devices the bootloader has been locked down, so no amount of pressing the ESC key will enable you to gain access. Glitching It Plan B was to try the " glitch " method . This is much higher risk and more complicated,
Having started to add some Zigbee devices to the home automation mix, I have a version of one of the "standard" Tuya ethernet gateway models. This same board appears in devices from all sorts of companies. Router Zigbee is provided by a Tuya TYZS4-IPEX which has online
This is just a quick note to self :-) The profile used for the Build > Generate Signed App Bundle or APK in AndroidStudio needs to have the Debuggable option set to false or it will be rejected on upload with the rather unhelpful message The Android App Bundle was not
There is likely a better way to do this, but when asked to add a redirect catching some moved wordpress files in nginx , this was what I came up with. set $fix_redirect ""; if ($request_uri ~ '/wp-content/uploads(.*)') { set $fix_redirect $1; } if ($fix_redirect
It's been a long, long while since I last looked at doing any development for mobile devices. My experiences were all disappointing and negative. While I could get things to build, they always seemed to have issues and installing onto an actual device was a nightmare of versioning
After looking at a lot of decompiled code things started to make more sense... AES? The STM32L100RC doesn't have AES functionality builtin, but the SPIRIT1 does so when I came across an AES implementation contained with the code I was a little surprised. This turns out to be
Having the firmware image to decompile allowed me to find the settings for the radio. How close was I? Spirit Library? I had guessed that they may well be using the STM SPIRIT1 library and after some looking I found that this was the case. It took a little while
Before getting started I decided to grab the following binary data files from the device. Flash 0x08000000 - 0x08003FFF (256Kb) - flash.bin EEPROM 0x0808000 - 0x08081FFF (8Kb) - eeprom.bin SRAM 0x20000000-0x20007FFF (32Kb) - ram.bin System Memory 0x1ff00000-0x1FF01FFF (8Kb) - system_memory.bin Each was accessed using 8-bit data width. Suitably
After looking at the binary dump for the RF controller I realised that I needed to identify the processor I was dealing with.  From what I had read the flash image contains the bootloader followed by the code i was interested in. There may also be some data sections.
Having been trying to make sense of the broadcast packets from the heaters and controllers for a few days it became apparent that I wasn't making much progress. Some small pieces made sense and seemed to point to a structure, but there just wasn't enough to
Following on from last night I decided to try turning off all bar one of the heaters to see if the 3 different "signatures" I was seeing were related to the 3 heaters. Timing 21:41:42 DEBUG receiver - receive: messsage of 40 bytes 21:42:22 DEBUG
py-spirit1 I published the code I've been writing to github after refactoring it slightly to make it simpler to use and easier to expand from. There is still a lot missing but it's working for me and and as I delve further I will try
After connecting the SPIRIT1 board to the RaspberryPi it didn't take long to start reading data from the chip via SPI. This was just the first step and to be honest the following days saw me going back and forth trying to comprehend what was needed and how
Having received the SPIRIT1 development board (I bought a Nucleo-IDS01A4 ) I have been attempting to communicate via the SPI interface detailed in the datasheet. As I had a spare RaspberryPi 1 I'm using that as a starting point. Connecting? The MBed project has a very useful pinout