Joris La Cancellera

Poto-Siril

2024-10-15T17:12:00-05:00

Rain Alarm for Astrophotography proto 3 - Siren Alarm

2023-12-01T14:00:00-06:00

You’re reading part 3 of the Rain Alarm for Astrophotography series; part 1 is available here 👋 and part 2 here 👋.

The sound of silence

Part of the project is to wake the amateur astronomer up when it starts raining 🌧️. Or when we lose the communication with the rain sensor.
We will naturally embed a siren alarm in the base station to do that!

In this sound alarm prototype, I did not have a clear idea of what I was aiming for: a simple beep sound? 8-bit music? MP3/WAV music or ringtone? I was also unsure about the technical implications, so I explored many options. I must admit that I got a bit lost and undecided during the journey.

Indeed, we have a lot of options to produce a sound with electronics, each with its own pros and cons. Let’s look at them.

Buzzers vs Speakers

It seems we have two primary hardware components to produce a sound for us:

Piezoelectric buzzers: Quite cheap and easy to use, but they produce a very annoying sound. That’s the usual beep sound you hear very often on “non-media” electronic devices. They are divided into 2 sub-categories:
- Active buzzers: You just need to power them to produce a fixed-pitch sound, thanks to an internal oscillator.
- Passive buzzers: You need to supply an AC signal to produce a sound, and the pitch is affected by the frequency of that signal.

Speakers: They produce a much more pleasant sound, but they require more hardware to drive them correctly (an amplifier at minimal, we will get back to this later). They need an AC signal.

Architecture setups

Having said that, we have plenty of solutions when it comes to the integration:

Active Buzzer: This is the simplest solution. It’s as easy as turning a LED ON. Though, I really don’t want a fixed tone ringing.
Passive Buzzer + PWM Modulation⭐: Slightly more complex than above but still fairly simple: we’re using LEDC (LED control) with the ESP32 to generate a PWM signal to control the pitch. A small capacitor can more or less smooth the squared signal into an AC shape to fine-tune the sound. Sometimes science is more art than science, Morty.
Speaker + Internal ESP32 DAC (digital-analog converter): The idea here is to use the ESP32’s internal DAC to produce a modulated sinusoidal waveform. The DAC is an 8-bit one, which will be okay for Chiptune but not ideal for regular 16-32 bit music. However, the output of the DAC cannot be used to drive a speaker directly because a speaker requires 4-8 Watts of power (that’s 1A in our 3.3V logic circuit!🚒). Therefore, an amplifier is needed in between to “repeat” the logic circuit signal with higher power. The core issue I have with this design is that it looks intimidating code-wise, as the music sampling rate will depend on the CPU clock frequency. This means that we would need to isolate a part of the ESP32 resources (perhaps using interrupt timers?) for the music, while still dealing with radio communication, etc. This solution is too low-level for me. The discovery of the Mozzi library later confirmed my doubts even further.
Speaker + External DAC: We can use an external DAC (16-Bit) to produce better sound. The DAC will still need to be connected to an amplifier to drive the speaker, but it’s common to see the two functions bundled together. That’s the case with the MAX98357A I’ve tried. We connect this dude to the ESP32 via the I2S (Inter-IC Sound) protocol. Unlike the previous method, playing a sound is easier on the software side as we deal with highly abstracted libraries. During my tests, I couldn’t achieve this without adding an SD card reader to stream the music from. In another attempt, I would improve this to stream from the ESP32 flash memory or just accept the SD card reader, enabling everyone to customize the alarm sound.
Speaker + PWM Modulation: This was a silly idea I had, thinking I could replace a passive buzzer with a speaker. It turns out this would work, but an amplifier is needed.

Exploration results

Now that we have a good overview of the options, we can break the results as follows:

Option	Can do	Complexity	Cost	Reliability	Bill of materials
Active Buzzer	Monotone melody	+	+	+++	buzzer
Passive Buzzer + PWM Modulation	Monophony melody	+	+	+++	buzzer
Speaker + Internal ESP32 DAC	Monophony melody	+++	++	+	speaker + amplifier
Speaker + External DAC (+ SD Card Reader)	Everything 🥯	++ / (+++)	+++	++ / (+)	speaker + amplifier + DAC (+SD card reader)
Speaker + PWM Modulation	Monophony melody	++	++	++	speaker + amplifier

The use of a speaker introduces a lot of extras. I haven’t even scratched the surface of the software challenges, such as storing the music files and bundling extra libraries into the build. If using an SD Card is absolutely unavoidable, that would mean having two SPI devices (the SD card reader and the LoRa module, from part 2), necessitating sharing the SPI bus. My board has a second SPI bus, but it seems unusable to me: one of the pins must be at 0V at boot time 🤦‍♀️, a requirement I discovered when failing to boot.

Reflecting on our product values (simplicity, reliability…), it becomes clear that a pragmatic decision is to opt for a Passive Buzzer + PWM Modulation design.

Protoyping the sound alarm

The Passive Buzzer + PWM Modulation and Speaker + External DAC + SD Card Reader architectures are demonstrated in the following video. 🔊🔊🔊

To view this video, please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

The buzzer chiptune looks really good. On the other hand, you can notice that the speaker volume isn’t stable, I don’t know why at this point but it’s not a power delivery issue.

Schematic

From here, we really see the difference in terms of complexity between the two architectures.

Take away

We’ve learned a few things:

The Passive Buzzer + PWM Modulation is the best option for our use case. The sound is loud enough, and the quality is certainly adequate for chiptune sounds. It enables us to create distinctly different sounds for each type of alarm (rain or communication lost), unlike the Active Buzzer.
We spent a considerable amount of time exploring this, but it was fun. I mean, this is an alarm you’re best off never hearing throughout the entire product lifecycle, so we could have omitted the idea of using speakers from the start.

Next step

We have two more things to prototype:

Temperature and Humidity sensors for the rain sensor module.
A screen 📺 for the base station should follow as well.

Then, it will be about integrating all of these components together. 🏆

Source code

Passive Buzzer + PWM Modulation

Speaker + External DAC + SD Card Reader

Rain Alarm for Astrophotography proto 2 - Wireless Communication

2023-10-24T16:03:00-05:00

You’re reading part 2 of the Rain Alarm for Astrophotography series; part 1 is available here 👋.

The need for radio communication

As previously discussed, we intend for the rain sensor device to remain outdoors alongside the unattended astrophotography equipment, in anticipation of rain showers 🌧️. Additionally, the base station will be located indoors so that the alarm can be heard within the house.

We want the two devices to reach each other from a distance of 50-100 meters, with some walls in between.

What radio communication technology?

There, we have some options:

WiFi: There are two approaches to consider. Both devices connect to the same home network, or one device—likely the base station—acts as an access point for the other to connect to. While I have full coverage in my own garden, I got to point out that the garden is not particularly long, and I bought an expensive dedicated WiFi router to get that coverage. WiFi won’t be a viable option for our plug and play product.
Bluetooth: Quite famous for IoT. What makes it promising are reports suggesting that BLE 5.0 could achieve a transmission distance of 200 meters outdoors and 40 meters indoors. I won’t eliminate this option just yet.
Zigbee: I love the Zigbee tech, but it’s not suitable for this type of project. Designed for mesh networks, it’s not optimized for long-range, 1-to-1 communication.
Cellular: That’s a solid option but I don’t want to go there to stay low tech.
LoRa⭐: This is IoT centered, low power, long distance (from 1 to 10km!), and quite low level to tune the bandwidth/range tradeoff. The modules are not too expensive and versatile: they support many other radio modulations, such as FSK. 👉 This appears to be the best choice.

Hardware

The microcontroller

Proto 1 was built with an Arduino Uno (ATmega328P microcontroller). This was the only hardware available around me at that time and it did the job very well. For this second prototype, I’m looking for something smaller, that I can embed in a box, aiming to stick to the same microcontroller for the rest of the project.

Every Raspberry pi like boards are out of the question, as I don’t want a full computer here.

I considered using an Arduino Nano and ended up wasting two nights fighting with a cheap knockoff. I was surprised to discover that the low-cost suppliers not only produce bad-quality clones (Arduino being open source), but also cut costs by replacing some expensive components, like the serial-usb converter CP2102 for some shittier alternative, like the CH340. So yeah, I struggled with Windows 11 automatically updating the driver, which then made the OS stop recognizing the board with the latest driver version. Plus, whenever I connected the second board, it made the first one disconnect. Super annoying!
The genuine-official Arduino Nano cost 20€, that I need twice for my project: 50 euros with the shipping. This is a quite expensive material if I want to make a product out of this.

I went for a pair of ESP32 microcontroller (ESP32 Wroom 32E) from uPesy.fr. Yup, made right here in France 🇫🇷🥖!
I also migrated from the Arduino IDE to platformIO for the coding experience. Things are getting serious here.

From left to right: Arduino Uno, Arduino Nano & ESP32.

The radio module

The ESP32 comes with built-in WiFi and Bluetooth, but it lacks LoRa support. So, we’ll need a separate chip to handle LoRa. I chose the XL1278-SMT, which is based on Semtech’s sx1278. This module runs on 3.3v for both power and logic levels, just like the ESP32 board hopefully. That’s different from Arduino boards, which operate at 5v.

This tiny evil thing has 1.27mm pin headers that I had to bridge to 2.54mm pin headers for my breadboard.

Protoyping the radio communication

For this prototype, I’ve set up a button that toggles the ESP32’s built-in blue LEDs when pressed. The transmitter board on the left uses direct electrical wiring to control the LED, while the receiver board on the right gets the button status via LoRa and acts accordingly.

To view this video, please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

This is amusing, as there’s no security in place right now. Who knows, someone might think I’m sending out Morse code messages!

Schematic

Both the ESP32 and the XL1278-SMT LoRa module connect in the same way on both circuits, using the SPI bus. The uPesy board features a tiny blue LED, D1, connected to the GPIO2 output.
I’m using a switch, labeled SW1, to simulate a rain trigger. The switch is connected to the ESP32 board via GPIO15, configured as INPUT_PULLUP. The board comes with a built-in pull-up resistor, so there’s no need for an external one 💝.
When you press the switch SW1, it changes the state of the rain sensor’s LED, labeled D1. The base station’s LED follows the switch state as well thanks to the wireless com.
Lastly, I needed a capacitor C1 to stabilise the boot of the XL1278-SMT module on the transmitter side, due to some voltage fluctuation issues.

Take away

We’ve learn a few things:

The ESP32 is looking pretty solid, it’s safe to assume this will be the board I will use for the final product.
LoRa rocks too in terms of range and reliability. I was able to reach 200 meters of coverage with a 100% stable transmission between my house and outside on the street, with countless walls in between. That’s very good considering having not fine tuned anything and the poor PCB antenna, and I don’t even need more than that.

Next step

Next on the agenda: speakers for the base station.

There’s a bunch of tweaks to make on this prototype, like:

Switching the ESP32 to deep sleep to kill the Bluetooth and WiFi, dropping from 200mA to 20mA (easy).
Leveraging ESP32 timers so we don’t have to poll the switch or blast LoRa packets at CPU clock speed (medium-level stuff).
Getting the LoRa module into sleep mode and wake up when needed (tricky).
Secure the LoRa communication (medium-level stuff).
Buy the proper version of the LoRa to comply with EU regulation.

Part 3 is available here 👋.

Source code

Rain Sensor Transmitter

Base Station Receiver

RAfA (Rain Alarm for Astrophotography)

2023-09-01T18:00:00-05:00

RAfA (Rain Alarm for Astrophotography) is a plug-and-play system designed for amateur astronomers. It allows them to leave their astrophotography equipment running outside overnight, knowing that they will be notified in case of any unexpected rain.

More to come soon!

I’m hosting a series of blog posts about the project:

Rain Alarm for Astrophotography proto 1 - Rain Sensor

27 August 2023 astrophotography DIY electronics

Rain Alarm for Astrophotography proto 2 - Wireless Communication

24 October 2023 astrophotography DIY electronics

Rain Alarm for Astrophotography proto 3 - Siren Alarm

01 December 2023 astrophotography DIY electronics

Rain Alarm for Astrophotography proto 1 - Rain Sensor

2023-08-27T07:53:00-05:00

So, asking around and searching online, there is no evidence of a ready-to-buy rain alarm that would fit for astrophotography.
I’m going to build one.

Need context

Deep-sky astrophotography involves capturing images of deep-sky objects (DSOs) such as galaxies, nebulae, and star clusters.
You’ll need to accumulate hours of exposure time and process the data to reveal this faint and ancient light from deep space.

Messier 51, or the Whirlpool Galaxy, with 60 x 60 seconds of lights data on a small refracting telescope 72ED.

Astrophotography is all about hauling your pricey gear into your yard, maybe on a random Tuesday night because the sky and moon are playing nice, even though you’re clocking in the next morning. You spend an hour getting everything up and running, and there nothing to do anymore as it runs on its own: at this point, you just want to go back inside and sleep.

But what happens if the forecast is poor and it rains overnight?

I interviewed several astrophotographers, and they either said they rely on hope or joked about taking sleep aids to sleep.
Personally, I relied on some rain alert mobile apps, but a week of evaluation showed they can still produce false positives and negatives. Additionally, the app may be draining my phone’s battery so the phone kills it first.

I’ll take my chance with a DIY rain alarm.

Scoping the project

As a dad, the struggle isn’t foreign to me at all—it’s pretty much identical to having a snoozing infant. You’re torn between catching some sleep and making sure your baby is okay.

👉 And you invest in a baby monitor.

That’s exactly what I want to do: create a baby monitor for astrophotography.

Early specs

We’re going to build a device with the same characteristics that led me to choose my baby monitor:

Plug and play and self-sufficient: no need to connect to a computer or mobile phone.
No third dependencies: No mobile app, no Cloud (the device will not be dead because of f-word software obsolescence).
Fair wireless range: No WiFi, No Bluetooh.
Minimal to no configuration.
Outstanding reliability.

There will be a rain sensor and the base station, both communicating via radio. If it rains, the base station will sound an alarm. That’s it.

Protoyping the rain sensor

For that, I’m using an Arduino Uno that I already have, along with a rain sensor module that I’ve purchased specifically for this project.

And here we go with the first prototype:

To view this video, please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Schematic

The rain sensor PCB (roundish PCB in the video) in connected to the rain sensor module circuit. The more water on the PCB, the more you reduce its electrical resistance.
The rain sensor module circuit uses an Op-Amp (Operational Amplifier) Circuit LM393 to convert the analog output of the rain sensor PCB to a digital output. Water on the rain sensor PCB will increase the voltage on the Op-Amp Input 5 on this design, and Output 7 will return 0v or 5v depending on the threshold set by the potentiometer RV1. The circuit also provides the original analog output, which allows you to sidestep the digital conversion process entirely. I purchased this along with the rain sensor PCB, but I’m not sure it’s worth using it. That’s what the prototype is for.
The Arduino Uno and surrounding circuitry interfaces with both the digital and analog outputs from the rain sensor module circuit. The digital signal from the sensor links up with the D8 pin on the Arduino Uno. This pin reads the signal as either HIGH or LOW, triggering the D4 LED to switch ON or OFF accordingly. The analog signal feeds into the A0 pin on the Arduino Uno. This pin interprets the analog signal as a numerical value ranging from 0 to 1023. The D3 LED has voltage applied to it based on the numerical value, which influences the brightness of the LED.

Take away

We’ve learn a few things:

It’s fun.
Blogging about the prototype triples the amount of work required.
The core feature is working: the rain sensor PCB is able to detect rain in a reliable way.
The analog output experiences slight fluctuations, especially when the PCB is wet. However, this is not a concern for our use case, as our primary goal is to detect raindrops.
The Op-Amp circuit and its digital output appear to be unnecessary, which is good news. This eliminates both the cost and the uncertainty associated with the resistive potentiometer settings. We can simply rebuild the Ohm’s law design with the 10k resistor (R1 in the schematic) and handle the threshold via software. We might also need to reintroduce a capacitor (C 104 in the schematic) to the rain sensor PCB pins. My suspicion is that it may only be essential for the LM393 Op-Amp circuit.
I’m all for more software and less hardware 🙃.

Next step

We’ll prototype the radio communication between the rain sensor and the base station.

Part 2 is available here 👋.

Source code

Managing a Plex server with media files hosted on a remote NAS

2023-08-19T17:04:00-05:00

At home, I’ve got this NAS server taking care of all my media goodies. It’s a Synology DS414j. If you are a connoisseur, you probably already know it consists of 4-bay drive. Released in 2014, and the “j” stands for low-cost. Featuring 512MB of RAM and a dual core CPU clocked at 1.2GHz, it’s sufficient for “typical NAS chores”, even still today. But toss in a Plex server, and it’s a whole different ball game 😁.

I host the Plex server, among other things, on another machine as a conscientious hobbist. We’re talking about an Intel NUC with an 8th gen i5 CPU and 32GB of RAM. It’s powerful, small, quiet, and easy on the electricity bill. There’s just one minor challenge: The movies & series data remain in the NAS!

Mounting over NFS

There is absolutely no chance I’m transferring the 4TB volume from the NAS to the NUC server—physically speaking. So I opt for a local network mount, especially since my local network setup boasts a gigabit link between them.

Swiftly, I configure the NFS sharing permissions in the Synology OS, and write an fstab entry to mount the NAS volume on the Plex server host machine. And it’s been running smoothly ever since.

The issue

Well, there’s a hitch in the plan, otherwise, why would I bother writing this blog post?

This setup falls flat whenever the NUC server reboots. 💩😵

Checking the logs, Plex starts before the completion of the NFS mount, causing all movies and series to be marked as unavailable.

I was cleaning my NAS at the same time (Shrek 2 > 1 >> 4 >>>>>> 3).

It’s kinda fun; Plex actually handles it just fine if the NFS mount drops for a minute and then reconnects. I’ve witnessed it a couple of times! Because I have a WiFi 6 mesh connecting the two devices—it’s not the smartest setup, but I have my reasons that logic can’t explain.

However, during the boot sequence, Plex just flags the files as unavailable and calls it a day ¯\(ツ)/¯. Sure, the NFS mount completes a few seconds later, but Plex remains oblivious. Every time the machine reboots—whether it’s me or Ubuntu’s unattended-upgrades doing it—I have to SSH into the machine and restart Plex to set things right.

At some point, I really wanted to fix this. Let’s walk through a few resolution attempts and how I eventually solved this issue (spoiler: it’s both funny and stupid).

Tech context

Let’s cut to the chase, but some details are essential for what follows.

Plex runs via Docker + docker-compose on an Ubuntu host.
- The Docker container’s restart-policy is set to unless-stopped, so it boots right after the systemd docker.service.
The media folder is mounted using both fstab and NFS.

Initial investigation

systemd runs the nfs.mount service before docker.service according to the dependencies and logs. Yet, googling around, the nfs.mount is not blocking the boot sequence. It better be, because an unreachable remote host could take a minute to timeout. And I confirmed it, booting the machine with the NAS turned off, the boot duration remains unaffected.

The NFS mount command takes around 1 second. Sometimes faster, and Plex actually manages to boot up just fine—let’s say it happens 1 in 10 times.

We’ve clearly got ourselves a race condition.

1st try: Delay the start of the docker service

I try to solve the race condition by delaying the docker.service. I’m fine with this idea.

nano /lib/systemd/system/docker.service

Yeah I’m using nano—I don’t take my sysadmin hat too seriously.

...
[Service]
Type=notify

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# My attempt to delay the docker service.
ExecStartPre=-/bin/sleep 180
...

I add a sleep before the execution of the docker service with ExecStartPre, a hefty 180 seconds, just to make sure the change is noticeable. And this move was ridiculous: I just put a sleep in the boot sequence. Plex starts later, and so does the fstab mounting. However, it seems to show that fstab mounts my volume AFTER the docker service has initialized.

2nd try: Tweak the systemd dependencies

If I can’t delay the boot of Plex over the fstab jobs, may I adapt the boot order instead?

systemd After option defines the dependencies, that’s exactly what we need.

So I try to add another dependency following this StackExchange thread set-systemd-service-to-execute-after-fstab-mount.

# This command is used to find out the service name generated out of the fstab entry.
systemctl list-units --type=mount | grep nas
#> srv-plex-data-nas-media.mount
nano /lib/systemd/system/docker.service

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service containerd.service srv-plex-data-nas-media.mount # Adding my systemctl `unit` here.
Wants=network-online.target
Requires=docker.socket
...

And, I don’t see any improvement 😭. At this point, I shelved the subject for a few months.

3rd try: Delay the Plex container boot from the docker-compose

I ended up looking at several things to hack around the Docker or docker-compose layers.

Is there a way to delay container startup to support dependant services with a longer startup time -> messy, no clear solution.
docker-compose-wait -> nice but not scoped for mount!
- And it has this issue: What about wait for existence of a file?-> damn, that’s what I need, but too lazy to code it. UPDATE: LOL, this was implemented later on, in mid 2021. Did I draft this in early 2021 and only finish writing it two years later? Maybe.
Docker Compose Healthcheck -> Awesome, as long as everything is dockerized, and my fstab part is not.

4th and final try: Mount the NFS volume via docker-compose

And then, I was like:

Why didn’t this cross my mind? Why don’t I mount the NFS volume via docker-compose? Could it actually be that easy?

TLDR: It works perfectly. And having everything wrapped up in a single docker-compose.yml file is a dream come true because I hate to sysadmin mess with my machines.

Tracking the WhatsApp habits of 5000 random Smartphones

2021-04-16T14:34:00-05:00

In the previous blog post, we have seen that this is quite simple to hack the WhatsApp online status of a contact. A simple Online or last seen yesterday at 19:00 insight can be reverse engineered to leak phone habits at a couple of seconds accuracy.

There is an even more silly thing not mentioned yet: You can track any mobile phone ! So let’s play and scale to track 5000 random numbers.

Like previously, I am sharing the source code as a PROOF OF CONCEPT. You can jump straight to the end if you are more curious about the results than by the technical stuff I’m about to resume. We are reusing the previous code with Node.js, Puppeteer & Grafana.

My Friends, My contacts

WhatsApp reads the phone contacts and lets you chat with the ones also enrolled. As a result, we can openly register a random phone as a contact to find him on WhatsApp.

While there is no consent around adding a number to your phone contacts list, WhatsApp protects users by proposing a consent to reply or report as spam at the first message interaction. It helps fighting bots for sure. Surprisingly, it doesn’t cover the Last Seen status.

Outch, why am I seeing this last seen data?

As seen previously, there is a privacy setting to prevent this. By default to Everyone and nobody configures it.

WhatsApp disables the Last Seen feature in both direction if you don’t want to share yours

Playing around with 5000 contacts

Now, I wonder how far we can go with this weakness. I don’t want to track individuals and won’t ask for the consent of 5000 persons like I could during the first hack.

So I will try to challenge the stuff, compute a couple of anonymous statistics and drop the data. Let’s scale and track 5000 phones.

Generating 5000 contacts

To scale a proof-of-concept with 5000 contacts, I need to register 5000 contacts on my phone! And I won’t do it by hand.
To do this, I browse to my google account from the desktop website, head to the Contacts page to find a button labeled import a CSV ❤️.

The documentation looks super messy and too big. I skip it and export my pre-existing contacts to see the data model. And the data model is complex for real. After a couple of tries, I manage to import a couple of contact with the least amount of fields filled possible.

Name,Given Name,Additional Name,Family Name,Yomi Name,Given Name Yomi,Additional Name Yomi,Family Name Yomi,Name Prefix,Name Suffix,Initials,Nickname,Short Name,Maiden Name,Birthday,Gender,Location,Billing Information,Directory Server,Mileage,Occupation,Hobby,Sensitivity,Priority,Subject,Notes,Language,Photo,Group Membership,Phone 1 - Type,Phone 1 - Value
ContactA,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Mobile,06 01 02 03 04
ContactB,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Mobile,06 01 02 03 05
ContactC,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Mobile,06 01 02 03 06

Additional Name Yomi ❓

In case you are more used to CSVs in Excel…

So I code a script to generate the CSV of 5000 contacts right away⬇️.

A bunch of 5000 French numbers

And I import it to Gmail.

Why the hell this is so easy, Google, are you mad?

Finally, I check that my phone syncs them (my poor phone took one entire hour to sync, might not handle 5k more contacts).

Data acquisition

I modify my code made before to loop through the imported-unknown 5000 contacts and I hit run.

I leave my crawler for a couple of days (6 days straight with a dumb code! Seriously, there is no security in there). And here is a lovely data viz in the Grafana dashboard reused from the previous work.

With an initial sample of 100 contacts. Each ‘drops to 0’ indicates that the given contact checked his Smartphone

We can also test if a phone number is registered on WhatsApp by querying the app, as presented in the screenshot below.

Conclusion

I could manage to keep up scanning 5000 phones during a continuous month with an average web scraping code.

WhatsApp is clearly not checking and preventing abuse of this functionality. I could manage to use 15 000 times the search engine to retrieve the last seen data in one single web session.
I scraped a 112k records dataset for the study.

My exploration shows we can:

Find out if a phone number is(was) registered on WhatsApp
- If a phone number is(was) valid and assigned in the telephony network
Retrieve the user WhatsApp profile picture (a big format version is extractable)
Retrieve the last seen data itself

From the 5000 contacts, it is essential to point out that I don’t know how many numbers are valid;
I used the French 06xxxxxxxx range (or 00336xxxxxxxx www) which came into saturation 10 years ago (So was introduced the 07xxxxxxxx range at that time). We could maybe suppose at least 80% of valid phone numbers.

Here is a viz of users grouped by last seen date to give a sight about WhatsApp usage. I gathered the data around the first week of February.

The drop from 1357 active users during the last month to 281 in the last week is quite significant and could be linked to the shit storm that WhatsApp had during late December 2020. I’m somewhat not inspired to mine the data further. I guess this is it. Thanks for reading.

Messenger, Signal & Telegram (bonus)

(Facebook) Messenger doesn’t use phone contact numbers to find users as they rely on Facebook accounts. A completely different design as it is a social network and less of a mobile VOIP service. I expect many similar hacks and data acquisition to do around Messenger. But that’s another case, for later?

Signal and Telegram are more similar to WhatsApp in their way of handling contacts. However, they don’t leak so much.

Telegram last seen data is less available publicly and is vague like within a month. The search engine was not leaking to estimate the number of users during my study. But it seems this is now possible as I am writing this six weeks later. I’m pissed off a little bit.

For Signal, there is no last seen functionality at all; This is clean. But counting the users was simple. Signal features a {x} is on Signal! notification when a contact has joined. It helps to monitor users’ conversion to signal.

94 users out of 5000 were on Signal at day 1, and 1-2 newcomers every day during the following days. Nobody uses Signal in France, Elon Musk had a reduced influence apparently.

Yes, it’s a picture. Trackers free

3D print of a Bahtinov filter

2021-01-14T15:57:00-06:00

Optical Focus

When you take photos, you need to focus.
So when I go out the night to do astrophotography, I also need to focus 🙃.

No need to say, my collected data is shit when I don’t do it properly. Shooting stars do not give room for mistakes, even tiny ones.

And I struggle so hard to focus with manual lenses for astro (the autofocus does not work in such darky situations! Thus, I shoot with 60s-90s lenses from the URSS with a 2015 camera; So no autofocus anyway).

One would say

“Leave the old stuff, buy a real tube, equatorial mount & motorized focuser stuff”. –Michmich

Yet, I’m not considering switching my 5kg backpack for a 25kg rolling case.

And this night, I discovered the Bahtinov mask!

Bahtinov

The Bahtinov mask creates a diffraction pattern when put in front of a lens.

Source: Wikipedia

The super awesome thing about it is that the visual artifact tells you which direction you need to roll the focus ring to sharpen the picture.

I want one.

Making one

Pain in the ass; The filter is tricky. It mainly depends on the camera focal length. And it would be cool to have the correct diameter for lenses.

Won’t buy one, time to 3D print mine!

I love the open-source world. My 3D printer is fully open source. The Bahtinov might be. My first exploration led me straight to the marvelous thingiverse. And especially here: Bahtinov Mask For Samyang 135mm Lens ⬇️.

And just like that, I downloaded Openscad, forked the project & tweaked it.

OpenSCAD, the source code and the rendering

3D Printing

Like always, I struggle so hard to scale my prints when size matter (what are you thinking?). So I first print the object upside down to print the ring first, kill the print, check the diameter with my lens & adjust.

Took me six shots to get the expected inner diameter. Does my printer suck?

Asked for 75mm, got 74.65m. This is too tight 😐

To view this video, please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

Closing

I made my DIY Bahtinov mask in 4 hours, almost including this blog writing (nope at all).
OpenSCAD kinda blew my mind: code, variable, versioning; that’s promising! Blender will stick to arts.

I own a coffee to dakloifarwa for the openSCAD source code!

Hold on, this is an animated gif

You are still here? Bonus!

Let’s code my first real OpenSCAD code -> I need a lens cap!

I printed it with wood, so fancy.
Reach this print at thingiverse.

Hack the WhatsApp status to track contacts

2020-04-01T12:00:00-05:00

WhatsApp shares your contacts’ status with you.

TL;DR: You can protect yourself from this hack by changing your account privacy settings. By default, WhatsApp shares your status with others.
Since nobody is changing settings nowadays, this hack works almost all the time.

DISCLAIMER: This is a proof of concept to raise awareness and a bit of a technical challenge before anything else. Don't use my source code provided to track someone, don't be a dick ❤️.

WhatsApp in Android

Exploit the feature

I want to exploit this feature to track users (for science). My first question is: How does this feature works?

To make things up, I am using https://web.whatsapp.com/ in my laptop web browser instead of my Android Smartphone. So I’ll deal with regular web reverse engineering to get this exploit done. I skip Android app reverse engineering for another time.

I pick a friend of mine’s phone and look at how his status behaves on my side.

Initially, the status is offline, and in this case, WhatsApp gives you an absolute date, last seen 16/03/2020 at 15:40.

I’m unlocking the friend’s phone and opening an app (not WhatsApp), doing that for a minute, nothing on my side.
Ok; Now switching to WhatsApp. The status has changed to online 10 seconds later. I didn’t go to the conversations I am sharing with this phone/contact to verify that the status transmits without this condition.

The online status remains until you leave WhatsApp or shut off the screen on the targeted phone.
And then, it reverts to a new last seen date once offline again.

So to summarize the thing:

We won’t be able to track someone using his phone globally (hopefully!)
But we can track the WhatsApp usage of anyone we have in our contacts
The info leaked are last seen date and the live online status per contact
We can expect to have at least a minute of accuracy for the last seen date
And the online status shows up once WhatsApp is in the foreground for at least 5-10 seconds

Technical analysis

I’m opening the Firefox debugger (Proudly using Firefox again !) to see how the front of WhatsApp web is fetching the coveted data.

The front uses a web socket communication to gather the data in real-time, somewhat every 10-15 seconds.

If we look carefully, the front seems to poke the server every ~15 seconds with ?,, and most of the time follows a reply of !{timestamp}. A kind of keep-alive stuff. Not interesting for us.

The server pushes another kind of message to the front when the status of the contact changes.

The id value I partially cover in black is the phone number, type is the available/unavailable flag, t is the timestamp of our last seen date. The whole payload is encapsulated in a Presence object, easy to recognize.
The timestamp is matching what we read in the UI.

using https://www.epochconverter.com/

Limitations

To receive the presence events from the server via the web socket com, we (the front) subscribe to a specific phone number (id). It is triggered when we select another conversation/contact with the web interface.

So, in this conception, we only receive the active contact’s presence events. In other words, we can only track one contact at a time in the web socket connection. Too bad for us!

WhatsApp also prevents us from opening several concurrent instances (of the same cookies). So we can’t open two web-socket channels altogether. It would have been too easy!

And finally, this one-WhatsApp-web-session-at-a-time behavior still applies when trying two independent sessions (not the same cookies). A new session will trigger the older one to close, and especially at the web-socket layer.

Another expected limitation, the validity of our session is limited in time. Mine will expire the 22/10/2020, in 6 months+. It’s odd to retrieve this info on the front side like this. I might be misinterpreting this one.

Naïve implementation

Now that we’ve defined what is the status feature of WhatsApp and how it could be misused to track users, it is time to code something. We also looked at the technical implementation and for a possible easy-security-flaw.

We could re-code the web socket communication exchange to retrieve the status data, but this will be complex. Too complex if we can only track one contact at a time. I will start with high-level techno and accept the current known limitations and see where it goes.

My idea is to see where we can go with cheap hacking work before doing advanced things.

I’ll decompose the proof of concept into three steps:

Gather the data
Store the data (easy)
Visualize the data (easy, but challengy for me)

I’ll scrape the data using Node.js and Puppeteer; Puppeteer allows us to control a browser and interact the same way a user would do with the mouse and keyboard. It avoids doing complex reverse engineering at the web socket level, and that’s why I picked that up. I’m more used to Selenium + C#. This is my first puppeteer experiment, so be kind to me.

We got the core stuff in 38 lines of code.

To continue, we need to parse the last seen today at 13:15 format into a proper date format. To do that, I’m using the so-wonderful chrono-node npm package.

Finally, I implement a loop in the code to scan the status constantly and store it into InfluxDB 2.0.
InfluxDB is a time-series database. That’s perfect for our use case.

I will derive the last seen date into an offline since UInteger. It will be the seconds counter since the last seen date.
offline since will value 0 when the status is online.
Deriving our data is turning our event-based data into time-series data. This design fits better for InfluxDB and especially for Grafana whose will display our data. And that’s stateless; I like that.

To store the data into InfluxDB 2.0, I’m using the Node.js client with the line protocol format of InfluxDB.

measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
--------------- --------------- --------------------- -------------------
       |               |                  |                    |
  Measurement       Tag set           Field set            Timestamp

The data stored looks like this:

status,contactName=Toto offlineSince=8275u 1465839830100400200
status,contactName=Toto offlineSince=8280u 1465839830100400200
status,contactName=Toto offlineSince=0u 1465839830100400200
status,contactName=Tata offlineSince=0u 1465839830100400200
------ ---------------  ----------------- -------------------
  |            |                |                  |
Measurement Tag set         Field set          Timestamp

The code implementation:

There is an edge case I want to handle: Sometimes, the status does not display at all in WhatsApp.
In this case, we won’t enter a offlineSince measure into the database because we don’t have one. Instead, we will log a statusAvailable measure (being 0 or 1) each time we scan the status.

We now connect Grafana to InfluxDB and create a dashboard to monitor our acquisition. And voilà, let it run.

You can find the source code of this proof of concept here.
We will try to improve this hack later, for another blog entry someday!

Update

You can found the next episode here in which we scale this work to track 5000 Smartphones.

Shiny Tiny RPG - Game Dev using Shiny Stats

2020-01-12T14:30:00-06:00

Intro

The development steps for Shiny Stats, my Unity Asset product, are nearly over.
After roughly 2 years of work, quite not regular though, there are still plenty of things to do such as documentation and… marketing !

Marketing today will be about making a game demonstrator to show off Shiny Stats awesomeness. Let’s go.

Demo game

Having a playable demo to convince developers to adopt (to buy!) Shiny Stats will definitively help. The older-version-of-me didn’t see this coming back in 2017 when I did the initial planning. I told myself that screenshots with a lot of data charts would do the job as communication material. This was very pragmatic, but I realize today that this will not advertise Shiny Stats the right way. Shiny Stats is not about mathematics, it’s about improving game developers productivity so they can focus on what matters.

Shiny Stats aims to give game makers a ready-to-use utility to add stats and leveling mechanisms into their games. It is a wide subject, a complex one, and a lot of game uses these mechanisms. This is the kind of asset I would have bought while making Caatacombb in 2015 because this was very long to implement from scratch.

My demo should showcase a mini RPG example because this genre covers all the Shiny Stats possibilities thus this is my key audience I want to focus on. And I’ll have to be careful with the communication to make it clear that the Unity Asset also fits for non-RPG games, such as Tower Defense games for instance.

This game demo will be shipped with the Shiny Stats Unity Asset and I don’t want to bother game developers with a heavy demo. So I won’t reuse any official Unity demo code and assets. Unity’s demos are also a bit over complex for my need. That is exactly why I can’t also reuse my Caatacombb game assets either! So we’ll kinda make the game from scratch.

Making a Game

Name it

Ok, we are about to make a game here. Almost there. First, let’s pick a name for this demo-game: Shiny Tiny RPG.
That’s cute, it reminds Shiny Stats, and has the RPG tag in it, this will be our tiny RPG game featuring Shiny Stats.

Game Design

Minimalist as fuck. A bit like Realm of the Mad God but with 3D tech.

We will follow that quote for the whole game conception.

Realm of the Mad God

Few good things to remember:

I am willing to spend 30 hours of work max
- And have fun making it
The game demo
- Cover all Shiny Stats features
- Is interesting to play
- Reusable for marketing & documentation

Some Technical requirements:

As small as possible since it will be shipped with Shiny Stats
- No external dependencies
- Reduced use of binaries (Will I need textures?)
Scripts code must be naïve, beginner-friendly and not optimized to enhance readability
Running & playable in WebGL

Shiny Stats configuration

Wooh, we start the game conception with the Shiny Stats config.
I am cherry picking a bit into World Of Warcraft’s vocabulary since it was one of the most played MMORPG game ever.

Attributes:

Stamina
Strength
Intellect
Agility

Classes:

Warrior
Paladin
Rogue
Wizard
Cleric

Stats:

Health Points
Mana Points
Attack Power
Spell Power
Attack Speed
Walking Speed

Extra Stats:

Experience - Amount of experience points to gather in order to level up
Experience Drop - Amount of experience points to drop on entity death

Level and Experience:

Level 1 to 20
Use the built-in Experience System of Shiny Stats

Stat	Affected by (Attribute)
Health Points	Stamina
Mana Points	Intellect
Attack Power	Strength
Spell Power	Intellect
Attack Speed	Agility
Walking Speed	Agility

Class	Health Points (Stamina)	Mana Points (Intellect)	Attack Power (Strength)	Spell Power (Intellect)	Attack Speed (Agility)	Walking Speed (Agility)	Sum
Warrior	++	+	+++	+	++	+	10
Paladin	+++	++	++	++	++	+	11
Rogue	+	+	++	++	+++	+++	12
Wizard	+	+++	+	+++	+	+	9
Cleric	++	+++	+	++	+	+	10

Gameplay

We will set up a small map where live some enemies to defeat and one ultimate boss. The game idea is that the player has to climb levels by killing enemies to improve its power in order to be strong enough to defeat the boss.
The enemies will be scattered on the map, from level 1 to 19. The boss will be level 20.

The player starts the game by choosing his class. He can change his class whenever he wants, without loosing his progression - Not typical, but this is convenient for the demo purpose.

Character movements will be with the keyboard arrows (WASD).

There are two type of attack:

regular hit - Gives physical damage (using attack power stat). Trigger with mouse LEFT click
special skill - Depends on the class, and cost mana. Trigger with mouse RIGHT click

Class	Skill	Description
All	Attack	Regular attack using Attack Power
Warrior	Fatal Strike	150% regular attack damage
Paladin	Holy Strike	100% regular attack damage, the damage dealt are returned as Health Points
Rogue	Backstab	75% chance to deal 100% regular attack damage, 25% chance to deal 500% regular attack damage
Wizard	Flame Strike	Use Spell Power instead of Attack Power to deal damage
Cleric	Self Heal	Use Spell Power to heal himself, no damage dealt to enemies

Time to dev

Map

I’ve setup two materials for the environment, one for the floor and one for the walls.

To create the map, we only use Cube meshes. We use a 1x1x1 cube as a reference to scale the map properly. In our need, the map will be quite big to put a lot of empty space between the enemies, with walls to limit the zone and guide the player. It will look like a closed dungeon, in a cheap way.

That’s already during this map conception that we need to define the enemies’ level distribution inside the map and the inner combat challenge. So we need to define the meta now, at least on paper.

Difficulty to defeat	Enemy lvl 1-4	Enemy lvl 5-9	Enemy lvl 10-14	Enemy lvl 15-19	Boss (lvl 20)
Player level 1-4	medium	hard	-	-	-
Player level 5-9	easy	medium	hard	-	-
Player level 10-14	-	easy	medium	hard	-
Player level 15-19	-	-	easy	medium	hard
Player level 20	-	-	-	easy	medium

Map conception with enemies placement

Characters

Similar to the map, we will only use primary meshes mixed together instead of doing ‘real’ 3D models.

Character modeling using 1 sphere & 2 cylinders

We create 6 characters: 5 playable classes (player and enemies) and one boss.

Animation

We create a set of 2 attack animations for each class using the standard Unity animation system with an animator controller, which allows us to record keyframes on the go and use a state machine animator for the logic.
Dead easy, but far from producing awesome motions.

Shiny Stats

We will quickly setup the stats mechanisms thanks to Shiny Stats.

I create a new empty GameObject, and attach the ShinyStats script on it. Let’s configure it with setting we have specified so far.

Then, I attach the ShinyStatsEntity script to the 6 characters and setup their respective classes.

Class configuration

I convert the [+ - +++] range we’ve designed before into real values.

Reference
in Shiny Stats

Class	Stamina	Strength	Intellect	Agility	Sum
Warrior	10	15	5	7	37
Paladin	15	6	9	7	37
Rogue	5	8	9	15	37
Wizard	7	5	18	7	37
Cleric	12	5	13	7	37

Classes configured in the Shiny Stats Unity asset

Stats configuration

Experiences stats

The Experience and Experience Drop stats will be the easiest stats to configure. We will use arbitrary values for each level so it requires a single kill to level up from 1 to 2 and increase the difficulty gradually so there is ~10 enemies to grind at level 19 to reach 20.

Reference
in Shiny Stats

Level(s)	Experience Drop (on enemy’s death)	Experience (required to level up the player)	Expected kills to level up
1-4	80 + Level x 10	100	1 - 2 enemies
5-9	80 + Level x 10	250	2 - 4 enemies
10-14	80 + Level x 10	500	3 - 6 enemies
15-18	80 + Level x 10	1000	5 - 6 enemies
19	80 + Level x 10	2000	10 - 11 enemies
20	1500 (the boss)	-	-

Experience stat configured in the Shiny Stats Unity asset

Walking Speed stat

Walking speed will marginally increase with the level, but is extremely influenced by the initial Agility attribute of the character. The Rogue will walk way faster than other classes.
The funny mechanism that I certainly want to introduce is that the player won’t be able to outrun a rogue enemy (unless the player picked Rogue too).

\(Walking Speed = 20 + Agility + Level / 10\)

Shiny Stats preview for the Rogue class

Shiny Stats preview for the Wizard class

Shiny Stats stat configuration

Health and Mana stats

We will also use a linear function for Health and Mana to increase constantly over the levels. Unlike the walking speed, the Health and Mana will be mainly influenced by the level.

\(Health Points = 20 + Stamina + Stamina * (Level - 1) / 4\)

\(Mana Points = Intellect + Intellect * (Level - 1) / 2\)

Attack & Spell stats

The remaining stats will use logarithms-like functions so the level affects them less and less. The mechanics I want to introduce is that the Health points will increase more than the Attack Power, Spell Power and Attack Speed in the top levels, to extend the combats duration in the end game.

\(Attack Power = Strength / 5 + Strength * log(Level, 10)\)

\(Spell Power = Intellect / 5 + Intellect * log(Level, 10)\)

The attack speed case

The Attack Speed is way more connected into the game and might mess around the animations and the experience overall. To be fair, I didn’t plan very well for attack speed variation in the gameplay. So we will leave this as a constant in Shiny Stats.

\(Attack Speed = 0.2\)

This will be the minimum, constant, period of time in seconds between two consecutive attacks regardless the class and level.

UIs

With a reduced amount of UI panels, we can keep the game really tiny and still showing off a lot of stats… from Shiny Stats.

UI panels state machine

C# scripts

Player Movement

We will use the CharacterController component from Unity to handle the player’s movements. The initial code, without the extra game management logic and Shiny Stats, looks like the code below.

using UnityEngine;

public class PlayerMovement : MonoBehaviour
{
    private CharacterController CharacterController;

    private void Awake()
    {
        CharacterController = GetComponent<CharacterController>();
    }

    void FixedUpdate()
    {
        var moveHorizontal = Input.GetAxisRaw("Horizontal");
        var moveVertical = Input.GetAxisRaw("Vertical");
        var movement = new Vector3(moveHorizontal, 0F, moveVertical).normalized;

        CharacterController.Move(movement * Time.fixedDeltaTime * 0.2F);
        if (movement != Vector3.zero)
            transform.rotation = Quaternion.Lerp(transform.rotation, Quaternion.LookRotation(movement), 0.5F);
    }
}

Health System

The health system will cover the characters life and death.
We reload the scene to restart the game when the player dies. When this script is attached to an enemy, it will give experience points to the player on death.

using ShinyStatsn;  // Enable ShinyStats.
using UnityEngine;
using UnityEngine.SceneManagement;

[RequireComponent(typeof(ShinyStatsEntity))]
public class HealthSystem : MonoBehaviour
{
    public double MaxValue;
    public double CurrentValue;

    private ShinyStatsEntity ShinyStatsEntity;

    private void Awake()
    {
        ShinyStatsEntity = GetComponent<ShinyStatsEntity>();
        // Subscribe to the OnLevelChanged event.
        ShinyStatsEntity.OnLevelChanged += ShinyStatsEntity_OnLevelChanged;
    }

    /// <summary>
    /// Callback from ShinyStatsEntity when the Level change.
    /// </summary>
    private void ShinyStatsEntity_OnLevelChanged(object sender, EventArgsInt e)
    {
        MaxValue = ShinyStatsEntity.EvaluateStat("Health Points");
        CurrentValue = MaxValue; // Reset to 100% HP on level up.
    }

    /// <summary>
    /// Handle the damage dealt by another entity.
    /// Negative values are perceived as heal.
    /// </summary>
    /// <param name="value"></param>
    public void ReceiveDamage(double value)
    {
        CurrentValue = CurrentValue - value;

        if (CurrentValue < 0)
        {
            var tag = gameObject.tag;

            Destroy(gameObject);
            if (tag == "Player")
                SceneManager.LoadScene(SceneManager.GetActiveScene().name); // Reset the game on player death.
            else
            {
                // Drop experience to the player on enemy death.
                var player = FindObjectOfType<ShinyTinyRPGManager>().GetPlayerGo();
                var expDrop = (int)ShinyStatsEntity.EvaluateStat("Experience Drop");
                player.GetComponent<ShinyStatsEntity>().AddExp(expDrop);
            }
        }
    }
}

We can also add a passive health regen that we always have in RPG games.

...
private void FixedUpdate()
{
    // Regen of the Health Points over the time.
    if (CurrentValue < MaxValue)
        CurrentValue += Time.deltaTime;
}
...

CharacterSheet UI script

A last script good to share is the character sheet panel code.

We adopted a stateless design that solves the ShinyStatsEntity reference on its own when possible. Indeed, the player can change its character at any moment, breaking references due to GameOject.Destroy() and GameObject.Instanciate() actions I am using. There are many ways to get over this, but this design is modular and maintainable.

using ShinyStatsn;
using UnityEngine;
using UnityEngine.UI;

public class CharacterSheetUI : MonoBehaviour
{
    public Text Subtitle; // Set in the Inspector.
    public Text[] AttributesValue; // Set in the Inspector.
    public Text[] StatsValue; // Set in the Inspector.
    public Text SpecialSkill; // Set in the Inspector.

    private ShinyStatsEntity ShinyStatsEntity;

    private void FixedUpdate()
    {
        if (ShinyStatsEntity == null)
        {
            var go = GameObject.FindWithTag("Player");
            if (go != null)
                ShinyStatsEntity = go.GetComponent<ShinyStatsEntity>();
        }

        if (ShinyStatsEntity == null)
            return;

        subtitle.text = ShinyStatsEntity.ClassSelected.label + " Lv. " + ShinyStatsEntity.CurrentLevel;

        AttributesValue[0].text = ShinyStatsEntity.GetAttribute("Stamina").ToString("0.#");
        AttributesValue[1].text = ShinyStatsEntity.GetAttribute("Strength").ToString("0.#");
        AttributesValue[2].text = ShinyStatsEntity.GetAttribute("Intellect").ToString("0.#");
        AttributesValue[3].text = ShinyStatsEntity.GetAttribute("Agility").ToString("0.#");

        StatsValue[0].text = ShinyStatsEntity.EvaluateStat("Health Points").ToString("0.#");
        StatsValue[1].text = ShinyStatsEntity.EvaluateStat("Mana Points").ToString("0.#");
        StatsValue[2].text = ShinyStatsEntity.EvaluateStat("Attack Power").ToString("0.#");
        StatsValue[3].text = ShinyStatsEntity.EvaluateStat("Spell Power").ToString("0.#");
        StatsValue[4].text = ShinyStatsEntity.EvaluateStat("Attack Speed").ToString("0.#");
        StatsValue[5].text = ShinyStatsEntity.EvaluateStat("Walking Speed").ToString("0.#");
    }
}

An performance improvement is possible: register to the OnLevelChanged event to catch updates instead of looping in the FixedUpdate loop.

Final result

Try the demo (from the Shiny Stats website)

Character Sheet panel

Class Selection panel

Game panel

Joris La Cancellera

Poto-Siril

Rain Alarm for Astrophotography proto 3 - Siren Alarm

The sound of silence

Buzzers vs Speakers

Architecture setups

Exploration results

Protoyping the sound alarm

Schematic

Take away

Next step

Source code

Passive Buzzer + PWM Modulation

Speaker + External DAC + SD Card Reader

Rain Alarm for Astrophotography proto 2 - Wireless Communication

The need for radio communication

What radio communication technology?

Hardware

The microcontroller

The radio module

Protoyping the radio communication

Schematic

Take away

Next step

Source code

Rain Sensor Transmitter

Base Station Receiver

RAfA (Rain Alarm for Astrophotography)

Rain Alarm for Astrophotography proto 1 - Rain Sensor

Rain Alarm for Astrophotography proto 2 - Wireless Communication

Rain Alarm for Astrophotography proto 3 - Siren Alarm

Rain Alarm for Astrophotography proto 1 - Rain Sensor

Need context

Scoping the project

Early specs

Protoyping the rain sensor

Schematic

Take away

Next step

Source code

Managing a Plex server with media files hosted on a remote NAS

Mounting over NFS

The issue

Tech context

Initial investigation

1st try: Delay the start of the docker service

2nd try: Tweak the systemd dependencies

3rd try: Delay the Plex container boot from the docker-compose

4th and final try: Mount the NFS volume via docker-compose

Tracking the WhatsApp habits of 5000 random Smartphones

My Friends, My contacts

Playing around with 5000 contacts

Generating 5000 contacts

Data acquisition

Conclusion

Messenger, Signal & Telegram (bonus)

3D print of a Bahtinov filter

Optical Focus

Bahtinov

Making one

3D Printing

Closing

You are still here? Bonus!

Hack the WhatsApp status to track contacts

DISCLAIMER: This is a proof of concept to raise awareness and a bit of a technical challenge before anything else. Don't use my source code provided to track someone, don't be a dick ❤️.

Exploit the feature

Technical analysis

Limitations

Naïve implementation

Update

Shiny Tiny RPG - Game Dev using Shiny Stats

Intro

Demo game

Making a Game

Name it

Game Design

Shiny Stats configuration

Meta

Gameplay

Time to dev