Random Sequence

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 =

I didn't think it was possible, but recently I came across this YouTube video and its associated blog post (in Japanese, which I was able to understand thanks to Google Translate): Here's a diagram to contrast the pulses sent to the clock lines to turn the clock backwards, versus driving it forward: As you can see, during the first time step, instead of sending a single positive or negative pulse, you send a short pulse, wait a little, then send a longer pulse in the opposite direction. Then in the next time step, a mirror image of the pulses in the previous time step is sent. The duration of the pulses has to be experimentally determined for different clock motions. For example, I was able to use this follow code to move the second hand on my clock in a reverse motion reliably: int tickpin = 25 ; void rtick () { digitalWrite(tickpin, HIGH); delay( 10 ); digitalWrite(tickpin, LOW); delay( 10 ); tickpin = (tickpin == 25 ? 27 : 25 ); digitalWrite(tickpin, HIGH)

Tired of losing ECU and radio memory when I replace the car battery myself, I followed the instructions in this video and made my own ODBII memory saver. The gadget is extremely simple to make. I ordered the ODBII plug and A23 battery holder. The diode could be any small signal diode that you have around the toolbox (I am using 1N4148). Then simply solder: Battery holder GND => pins 4, 5 on OBDII Battery holder VCC => diode (+) Diode (-) => pin 16 on OBDII That's it. Stuff the battery holder into the empty part of the shell and reassemble. I didn't even bother to screw the shell together. You can check by inserting a battery and measuring the voltage across pin 4/5 and pin 16. It should be around 12.6V (for a fresh A23 battery) - 0.4V ~= 12.2V. Anything above 11V should work well enough to keep the ECU and radio memory while inserted. To use, first insert the memory saver into the OBDII port in the car. Then remove the car battery and perform the battery replacement. F

I noticed recently that there is a ESP32 D1 Mini board with a CH9102X UART, so I bought one to try. The CH9102X appears to be a Chinese clone of the CP2102 . Unfortunately, I couldn't get it to work. Connected via USB, and at a baudrate of 115200bps, I could only successfully upload a program 2/10 times. Other times, I get the " Failed to connect to ESP32: Timed out waiting for packet header ". I could program it without issue by plugging it into the FTDI programmer. It could deal with an upload speed of 912600bps 100% of the time. I found this webpage that talks about fixing the timeout error by adding a small capacitor between EN and GND , but I don't really have the need to try it because I am going to remove the UART module anyway for the ESPCLOCK4 project. Anyway, I will just stick with the CP2104 UART for future purchases. Update: I found that I could make it work by connecting GPIO0 to GND, and setting an upload speed of no greater than 115200. Terrible.