Random Sequence

This post is about making Singapore/Malaysia style bakkwa (肉干), or savory pork slices, at home. There are numerous recipes for this online, but none of them hit the mark for me. It took many attempts over several years, going through different recipes and techniques, before I put together a recipe that can be easily made at home, which I feel closely resembles the commercial product. Commercial products are priced upwards of $50/kg in Singapore, and even up to $100/kg when they are exported to places like Australia. Yet, making it at home only cost $10+/kg in terms of ingredients, so it is something that is definitely worthwhile making at home. Also the process for making it is not really complicated. First the main ingredient, pork. Most online recipe will use minced pork, but I like to use thinly sliced pork (1mm thickness). The texture of the final product is different. The former is softer, while the latter is more chewy. Both types are sold commercially: 切片 (sliced) and 碎肉 (minced

I have uploaded the final code for ESPCLOCK4 to GitHub . Full details and schematic at the repository. I have also created 2 prototypes, 20cm and 30cm clocks:  I am quite happy with this version. It is much easier to debug (by using a dev board with the UART intact during development, and switching to one with the UART removed to save power for production), and very straightforward to implement on a prototype board. It also uses very few external components, but is equally power efficient. Future enhancements will include: - Adding an external clock crystal to eliminate the RTC_SLOW_CLK drift. - Using C to write the ULP code. Assembly code is tedious and error-prone.

In a previous  post on planned obsolescence , I mentioned I replaced the rechargeable battery of a shaver that was meant to be sent to the landfill after the battery has expired. Well, the Eneloop that I soldered to it has run out of steam after about 3 years. So I 3D-printed a low profile AA battery holder for the shaver to make the job of replacing the battery much easier. Of course, it would have been much simpler if the product was designed with a proper battery compartment that you can just open in the first place, but that would not have pleased the bean counters, would it?

I guess this is a perfect example of how people get cynical of software updates after going through the routine for awhile. And this is coming from someone who enjoys solving technical problems when he is in the right mood! So recently, I started having some long-running software complain that it can't bind to a certain TCP port because "the port is already in use". I immediately pulled out my trusty CurrPorts and check out which mysterious program is hogging the port behind my back (yeah I could use netstat , but who has time to memorize all those command line arguments, right?) To my surprise, nothing, nadda. No one is using that port. Yet that port is mysteriously barred from use. It's like you suddenly cannot open the door to your home with your existing key. Incredibly frustrating. Anyway, after 2 whole days of research, I finally found the culprit. Apparently after a certain Windows update (1809 or 2004 from various sources, I didn't care to verify), Window

For more obvious cases eg. clock time is 12:05 and present time is 12:00, we don't have to think too hard to decide which direction to take the second hand to match up the two times. However, suppose the clock time is currently 12:00, and the present time is 6:00. We can move the second hand forward 8x, or backwards 4x. Which direction will result in quicker synchronization of the 2 times? For both directions, the number of seconds to traverse is 6 x 60 x 60 = 21600 seconds. If we take the forward direction, the time taken to traverse half the number of seconds i.e. 10800 is 1350 seconds. However, in that time, the present time would have advanced by the same amount, so the number of seconds left to traverse would be 10800 + 1350 = 12150 seconds. If we do this iteratively, we would find the total time required to achieve synchronization is 3085 seconds, with 4 seconds left to catch up. If we take the reverse direction, the time taken to traverse half would be 10800 / 4 = 2700 secon

One of the requirement of the ESPCLOCK project is to deal with persisting the clock time when the supply batteries run low, or when they are removed for battery change. For previous iterations of the project, a 0.47F supercap was attached to the ATtiny85 to keep it powered it long enough during a cut-off to write the clock time to flash memory. For the ESP32, I found out it is impossible to power the main processor with the supercap, even if WiFi is not activated. It is just too power hungry! However, it is able to keep the ULP powered for 5 to 6 minutes. I found this out by getting the ULP to toggle an output pin and monitoring the output with a logic analyzer. The 0.47F supercap is placed across the 3.3V and GND pins. Power is supplied via the 5V pin. When the supply is pulled, the ULP continues to produce output for a further 5 to 6 minutes. So the strategy I will adopt is this. The ULP will measure the supply voltage via a voltage divider. When the supply voltage drops below a cert

After playing around with things a bit, I find that I am able to run the clock forward at 8x speed (125ms/tick), but only able to do so reliably in reverse at 4x speed (250ms/tick). So here is the "torture test" I have devised. It fastforwards the clock for 60 ticks, then reverse the direction for another 60 ticks. At the end of it, the second hand should return to the original position. By running this in a loop for many hours, I can confirm that there is no slippage for a given set of parameters. The parameters for this particular clock (another $2 clock I picked up from KMart after I accidentally stepped on and broke the Ikea one) are: Forward : 32ms pulse (9ms on, 1ms off) Reverse : 12ms pulse, 12ms wait, 28ms pulse The high-level code to implement the above looks like this: void forward_tick () { for ( int i = 0 ; i < 32 ; i ++ ) { digitalWrite(tickpin, HIGH); delayMicroseconds( 900 ); digitalWrite(tickpin, LOW); delayMicroseconds( 100 ); } tickpin =