The Absurd Notifier

It is the story of repurposing a broken Garmin watch into a desktop notification display. When focused on a computer task, don’t miss any notifications thanks to the absurdity of a desktop notifier.

Some time ago I struggle to make a small device displaying the phone notifications on a nice display. I tried with an ESP32 linked via Bluetooth to a custom app on my android phone. For example Mitchell Wong Ho made a nice project doing exactly that [link]. Unfortunately I didn’t manage to get reliable automatic re-connection after I got away with my phone.

Garmin makes very nice smart watches. And their phone application is full of features. You can have all the notifications you want on the watch’s display, and the connection is reliable. After detour from eBay, and I found a small Garmin vivosmart3 watch. The display is broken, but seems to still connect to a phone. And more importantly, it was very few euros.

The display of this watch is a monochrome OLED, 128×64 pixels. And here some of you might start to think of having a look on the data. To understand the data sent to the screen, I had to made a break-out board for the small smt connector. It was easy then to connect a logic analyzer. It is a SPI connection, so I started to program a PIC18F57K42 to forward the bytes to a serial port. Playing with some offsets reveals the image.

I have laying around some nice 128×64 VFD display I used for the Thermal printer project. Their connection is serial at 115200 bauds. So I programmed the PIC to act as slave SPI and Serial master, and put in form the data.

The display module is quite large, so I draw a case that looks like a 70’s TV set.

Remains 3D printing and stuff everything inside :

3D files and PIC program can be found here.

Thanks for reading!

A cute little single tube Nixie clock.

We are back to glowing neon plasma, with yet another clock. The aim is to make some presents to offer to the family, for the end of the year. I previously made a little 6 tubes clock, that was inspired by Dalibor’s Zen clock. Here I want to mimic his amazing single tube Bulb clock.

Tube choice

The smallest tube I have is a NEC LD-8007 (right), which I used for the 6 tube clock. However I’d rather keep it as a spare. I also have some LD-955a (center) and IN-16 (left), it is a good opportunity to use them.

Design constraints

In order to keep as much as possible the ratio of the original Bulb clock, the electronic board has to be rather compact.

For convenience, the power should come from a standard USB plug. I could use the same type of small high voltage power supply from NeonPixels. It is compact and a single digit does only require 1 to 2 mA. However we need to reach at least 170 Volts, so the components should be resized accordingly. Plus, I’d like to have a voltage measurement, with a cut-off threshold in order to not burn the components.

To keep track of the time, Real Time Clock [RTC] chips such as the DS3231 comes in handy boards with integrated back-up battery. So let’s use them directly.

The selection of the digit to light-up, or in other words the cathode to be grounded, can be achieved by using individual transistors. We will gain flexibility on the component placement compare to larger integrated circuits.

The micro-controller should then have sufficient IO to:

• Drive the high voltage step-up power supply.
• Acquire the output voltage and cut the HV drive if greater than 200V.
• Have two input for control buttons.
• Drive the 10 cathode transistors plus a decimal point.
• connect to the I2C port of the RTC.

After some cross check between Microchip PIC parametric search and the chips availability during this 2021 global shortage period, I decided to go with the PIC16F18346. It has just the right number of IO, and comes in a small 20 pins QFN package.

Making

After some tests on a proto board, it appears we can easily reach 200 Volts at few milliamperes. I selected a 10uH coil, ES1D fast diode and BSS87 mosfet. The switching frequency is 100KHz at 20% duty cycle.

Below on the left is the output voltage. It starts with the ramp-up until it reaches the striking voltage of 170V, then it stabilize at the sustain voltage of 130V.

The next step now is to start Kicad and draw the schematics:

The PCB was quite fun to draw. I started with a 4 layers design, not sure I could do it with 2 layers. I payed attention to isolate the high voltage parts and have large power tracks. Even if it will be hidden, I tried to keep the top layer ‘aesthetic’.

I ordered the board on OSHPark (oshpark.com/shared_projects/WM4Mp7db) and JLCPCB. JLC is really fast, literally 7 days between the file upload and the mailbox delivery, plus the boards are completely cut. While OSHpark is slower and board cuts need sanding, they have a really better silkscreen.

I draw the enclosure with Fusion360, and printed with a Prusa i3 MK3. It is a rather simple design and the board is hold in place by a circular clip.

Coding is done with MPLAB, and Code Composer is really convenient to setup all the peripherals. I have the high voltage power supply switching at 100KHz done by one PWM, another PWM at 500Hz for the brightness control, and a comparator measuring the high voltage versus a fix threshold. All of these going to an AND gate and drive the Mosfet. In addition I have the I2C peripheral for the RTC chip and a timer for the button features.

One button increases the hours with short press and increases the brightness with a long press. The second button does the same with the minutes and decreases the brightness with a long press.

About efficiency, of course this type of high voltage power supply is not the best. However, considering the small amount of power, it is not so bad.

When a digit is on at full (continuous) brightness, the current on the USB 5v is 61mA. Considering the current through the nixie tube is 1.25mA, the overall efficiency is around 60%. I think the large ground plane helps with the thermal dissipation, and the temperature of the coil stays below 30 degrees Celcius. Not to mention the digits are not lit continuously, there is dead time in the animation, where the switching is off.

Results

Sources and drawings are all available here : github.com/pierre-muth/solo-nixie

Neon Pixels

INS-1 / ИНC-1

Fortunately, these single dot tubes are still easy to find in large quantity and rather cheap. Made by Gazotron, it seems they buildup a large stock at that time. The INS-1 has the advantage to be small and produce a nice dot due to the lens-style front. Plus its striking voltage is maximum 100V, lower than regular Nixies.

At first I imagined 5×7 dot character modules, such as the TIL305, but bigger. While playing and trying to make a tiny and simple 5V to 100V step-up power supply, I realized how simple it can be. Here we just need to reach the striking voltage and only 0.5mA. As there is yet non uniformity in brightness between tubes, no strong voltage accuracy is needed. Without the signal generator, it is a diode and a coil, shorted to ground with a transistor at high frequency.

Then comes the idea to mimic the popular serial cascading LEDs, such as the WS2812 or SK6812, the so called Adafruit ‘NeoPixel’.

Neon Pixel

What I observed when I was empirically select the components is one key parameter to reach 100V is low resistance coil and mosfet. The voltage can be adjusted by choosing the pulse frequency and width.

I was happy to see that only few pulses are needed to reach 100V. This enables pwm for bulb brightness control directly by driving the transistor. It is achieved with a pulse frequency of 100KHz and a PWM of 500Hz.

This leads me to the microcontroller choice. The peripherals needed are SPI, PWM, Timer, NCO and logic cell. The cheapest with all these options seems to be the PIC16F15313.

I first have issues with the SPI daily chain propagation delays. The data takes some time to be clocked out from input to output. If we use the same clock line for all the devices, the data will quickly be out of phase in respect to the clock.

A workaround is to delay the clock as well on each devices, and have in one side a data and clock in signal, and on the other side a data and clock out signal. Fortunately, this PIC has 4 logic cells, so I can use one to delay the clock, like a line buffer. I was lucky that the logic cell delay is almost the same as the SPI logic.

The only problem remaining is the rise and fall edge detection, they are apparently slightly different. It results a kind of clock pulse stretching, a change on the duty-cycle. However I can deal with it. With a clock speed of 480KHz, the 384th device is still receiving a usable clock signal. 

Now that the prototype works, it is time for a PCB. The aim here is of course to have the smallest footprint, while keep connections at the opposite of the bulb.

I ordered the boards from OSHpark and JLCPCB. Both make very nice boards. OSHPark has the gold finish, and JLCPCB has the V-cut option, which is very convenient in my case.

Lets start the long journey of soldering, The 2020 lock down gave me plenty of time to solder the 384 boards, on which there is 11 components.

A matrix

Meanwhile, it is time to think about a usable display. I then made matrix blocks of 8×8 pixels.

And controlled by an ESP32. I got the first encouraging result.

I start to make a support as well. A simple aluminium plate with two 3D printed legs. I add several slots in order to choose the inclination. 

 

Coding

I’m using an ESP32, with the arduino framework, and the Platform.io IDE. The nice thing is I could extends the AdafruitGFX lib. So all the work of drawing, fonts etc, is yet done.

I added the notions of display size and buffer size. With a bigger buffer size, I can make easy scrolling by changing the coordinate of the view frame.

This Github repository contains the code and the schematics/PCB. 

Coupled with Andy Geppert Core Memory kit:

Conclusion

With around 20mA per pixel, at full brightness, the total of the 384 pixels is almost 8A. Everything is at 5V, so around 40 Watts is needed when all pixels fully on. Everything then is powered by a 10A 5V power supply. 

This is the reason I’m keeping the display open, that way an airflow exists between the pixels and everything is kept below 40°C.

It is not the first matrix made of  neon bulbs, here is a nice modular one made by Robin Sterling. (@RC_sterling) :

And an other one by @cronos_sv spotted by dangerous prototype at Tokyo Maker Faire 2013.

Recently Manawyrm Made 8×8 chainable matrices, featured in an atricle on hackaday:

 

Rear car Speedometer

Context

It’s subject to debate and delicate, but maybe you experienced this situation yourself while driving a car. The driver of another car, just behind you, would kindly like to travel at a higher speed. On your side however, you apparently yet travel at the maximum legal speed.

An hypothesis is the speedometers of both cars don’t agree. So why not showing in real time your actual traveling speed on the back of the car ?

Let’s make it looks like a Sonic the hedgehog power-up monitor !

Reading the car speed

I could use a GPS module to have the car speed, but I think there are two disadvantages. First, we loose it on tunnels, and second I’d like to show what I’m reading on my dashboard.

My first idea was to use a bluetooth OBD plug, and then connect to it with an ESP32. But I did not succeed because the OBD dongle I have uses classic bluetooth and not BLE. In addition I did not found a 12v power line on the trunk that is switching off once the ignition key removed. I don’t want to drain flat the car battery.

So I re-purposed the cheap OBDII reader. Luckily it uses an ELM327 clone and the bluetooth module can be de-soldered. That saves me the code of the raw CAN-bus handling, the ELM327 uses simple serial AT style commands. And it saves me the design of the CAN-bus circuitry.

Passive display

To display the car speed I’d rather choose the most passive, simple technology while having a large digit size. It is out of question to use something that emits light.

E-paper could do the job, but large displays are pretty expensive, and I’m not sure if they can handle the rough condition of a car parked in sunlight or a freezing winter.

Electro-mechanic Flip display would be a good choice if only the big 7 segments units were not so expensive. Besides, I’m not sure the continuous flipping would be good for the display and the driver ears.

Fortunately we can still find good old fashion 7 segments LCD in large size. I yet use some of these panel on the BIG_CLOCK project. The biggest apparently are made by Lumex, the LCDS101D40TR. The character size is 10×7 cm.

Only two digit is relevant in my opinion. At a speed faster than 100Km/h, digits should be unreadable due to the safety distance. So we have to drive only 14 segments. The PIC16F19156 can drive them directly, without multiplexing.

The code simply take the received byte on the serial port and display its decimal value from 0 to 99.

Processing

Originally I planed to use a wireless bluetooth link, it explains why I started and kept an ESP32. It’s a bit overkill for the task, but there is nice libraries for plenty of devices. I used Platform.io on Visual Studio Code, with Arduino, for the development.

One interesting point here is the use of the 3 serial ports. One for the programming / debug, one to the ELM327, and one to the LCD screen.

I also add a little Oled display for debug and showing what speed is acquired.

3D printed enclosures

To put the two electronic boards plus some wiring, I made a case that fits inside the rear cup holder. Conveniently there is a 12v plug just aside. I need 3 cables: the 12v, the connexion to the OBD plug in the front, and the connexion to the rear LCD. I re-purposed old Lemo 3 way plugs, a perfect fit.

On nighttime everything glows red, without being annoying.

To hold the LCD panels it appends I have a Sonic the hedgehog plush on the back of the car, why not try to mimic the power-up monitors of the video game ? I printed this enclosure in PETG because I had bad experience with PLA on direct sunlight. I tried to have an ajustable, stable and discreet design.

And here is how it looks like on the car :

The 3D files, the PIC code and the ESP32 code can be found here.

The quest of a beacon for cats (part 1)

Mio is a tiny female cat, with a rather independent and proud way of life. She spends quite a lot of time outside doing… well… important cat stuff, among proving her duchess status to the other neighbor cats. However, she never misses us, each evening after work, when we come back home. She can enter the warm house in order to get the well deserved food and attention.

Until one day. And the day after.

It affected me far more than I could expect, but fortunately the worst things I started to imagine were false. Mio came back home. We conclude she might be being locked by mistake in a barn from the neighborhood. That’s where started the idea of a small RF beacon for Mio. It should to be very small, at least a month of battery life, and can enable a kind of search with a receiver.

What exists

I usually enjoy to think about and make solutions by myself, but what exists yet on the market ?

thepawtracker.com

There are some expensive modules that combine GPS and GSM. Usually they come with a subscription (monthly fees) and you get the beacon location from a website. The few days of battery life is problematic, and they cannot be realistically attached to a small cat due to their size.

Some bluetooth tag seems to have some success. They are small and have a long battery life. These tags have however only a 10th of meter range, and some relies on the proximity of a smartphone, with the special app’ installed and running…

Finally, over internet I found a very interesting article of someone having the same concern. (https://www.f1nqp.fr/articles.php?lng=fr&pg=144 in french). I’m less confident with analog RF electronics. In addition, the size of the antenna wire is not very confortable. However this solution should be kept.

Exploring RF modules

I discarded the modules working at wifi frequencies (2.4GHz) for two reason. Maybe I should come back here later, but with a coin-cell battery budget, these frequencies are absorbed easily by walls.

I made some tests with three different RF modules. From left to right:

1 – A basic 315Mhz transmitter

These modules seems to meet the low power requirements. I can even use a TV usb dongle as SDR to receive and find the beacon. The difficulty comes from the antenna. A 1/4 wave antenna for 315MHz is 23cm long. If I spool the wire inside a small case, it makes a coil and degrades dramatically the antenna impedance/efficiency. So the range goes down to something like 10 meters.

2 – Lora module based on SX1278 at 433MHz

These LoRa modules are amazing. They have a really huge range, more than 500 meters. But the problem is still the antenna at 433Mhz. If I use a simple wire, wrapped in the case, I must increase the output power to the maximum (~+17dBm). Then the battery dies after a day. Mainly because the peak current is up to 100mA, thus not suitable with coin-cells.

3 – ST electronics module base on SPIRIT1 at 868Mhz

The ST SPSGRF module integrates the antenna, in a very small board. The power consumption is very interesting as well, so let’s go a bit further with them.

For each module, made a draft case. I choose a small PIC12F1822 in SOIC package to drive them.

ST SPIRIT1 tests

The PIC code basically setup the module and send a message every minute. Fortunately, in addition of the numerous application notes, ST provides a little application (STSW-CONNECT9) to generate dthe setup C code of the Spirit1. It is very convenient as the registers are quite numerous. The message sent is just composed of the battery voltage and the battery voltage drop during the RF broadcast.

The 3D drawing is done with Fusion360. To make the case waterproof, I used neoprene glue on the outside join between the cap and the body. With the screwdriver tool that fits the pattern on the cap, there is enough torque to tear the glue appart to unscrew it. I had to pay attention to not cover the antenna with the coin-cell battery. Event shifted like that, I’m sure it reduces the transmission efficiency.

 

 

Receiver and integration

On the receiver side, one interesting feature of the Spirit1 is the RSSI value – in received signal strength. It not gives an absolute distance between the two modules, as it is greatly dependent of the obstacles, but it rather gives an idea.

I used the ESP32 on this side for two reasons. First because there are nice libraries for the RF module and different screens, and because I would like the wifi connectivity. With wifi, I can connect it to my logging station and observe the evolution of the signals. I had a PCD8544 LCD, pretty much enough to display few values and a small history chart. The screen on the receiver let me take it outside and try to locate the signal. It displays RSSI, voltages, and a countdown in order to knows roughly when the beacon will emit.

The PIC code, the ESP32 codes and 3D models are on this github repository: https://github.com/pierre-muth/RF-cat-beacon

 

 

From the tests I made, the range is around 100 meters. I had the receiver outside in the village, while the cat is (sleeping) in the house (which has half a meter thick walls).

I have now additional logged data channels, I can observe the trends of RSSI and battery voltage on logging station.

 

 

Conclusion for now

I need to wait more to conclude on the battery lifetime. Over the last 10 days, the voltage seems constant at 3V. I could increase the transmission rate if possible.

I’m not sure about the reception range, is it enough to locate the beacon by walking around in the village? That’s why I should continue to study the other solutions. For example, I just saw it exists 433MHz ceramic antenna as well. Maybe it enables the use of the LoRa module at low power. They are still interesting as their modulation scheme makes the reception very sensitive.

Thanks for reading and take care of your cat.

Internet Of Mailbox

Abstract.

This post summaries the test I made to produce a mail presence sensor. It is aimed to be wireless, connected to the Pilogger logging station. It is interesting to use a load cell in order to know the weight of the object in the mailbox. But we will discuss the difficulties to implement a reliable solution.

The sensor.

Figure 1 – NTC inserted in the load cell

It could be found very cheap load cell on Ebay, with a small board featuring a 24-bits ADC. The ones I used for this test is a 10Kg cell with a HX711 board.

As the principle of sensing is based on the physical deformation of the metallic rod, the system is affected by temperature change. So I decide to use a thermistor (NTC), placed directly within the metallic rod, by placing it in a small drilled hole. (Figure 1, on the left)

The electronic

The HX711 is an interesting chip for its price range. It is design to measure very tiny resistance change using a Winston bridge. It have two channels, one with two gains (64 and 128) and another with a fixe 32 gain. While the first channel is connected to the load cell, the second one is perfectly usable for measuring the thermistor. To do so we have to do another Winston bridge including this thermistor. (Figure 2, on the right)

Figure 2 – Wireless mailbox probe schematics

I chose to use the same micro-controller and RF link as the previous wireless temperature probe. In other words, a PIC16F1825 and a nRF24l01+. The difference is the HX711 module and a voltage regulator. The HX711 needs a stable 3.3V, and then I use an analog input of the PIC to have a battery voltage information.

Code.

The micro-controller code is rather simple as well, it sleeps for around 8 seconds, then sequentially get 8 values of HX711 channel ‘A’ and average them, the same for channel ‘B’, then get the ADC value of the battery, and finally send the data with the nRF24l01.

The XC8 C compiler file for the PIC16F1825 is here in Github.

Installation.

I fixed one end of the load cell directly to the mailbox bottom, and the other end to an aluminium plate of approximately the surface of the box. For the tests, I just fixed the proto board on a side with tape, and the battery below.

Figure 3

Figure 4

Figure 5

Tests and data.

The system is surprisingly sensible, a letter is clearly visible on the weight data.

Figure 6

Figure 7

But sensitivity is not precision. And things start to be more complex when I try to figure out how to calibrate the system. There is a link between temperature and weight data, but not only. The entire mechanical system plays a role.

Figue 8 – One month of data

Figure 8 shows a complete month of temperature and weight data, with arbitrary units (ADC output). While points marked with ‘1’ are the time where a letter was on the plate, the others are interesting. Point ‘3’ shows that a heavy parcel was kindly placed in the box by the postman. But after that, the weight base line did not recover to the same value. Apparently a mechanical bias appeared, it could be a permanent distortion of the load cell.

I could not fully understood the events marked as ‘2’. These drops should reflect a resistance change, so I imagine it could be linked with humidity and water condensation. It seems it disappeared once I cover the HX711 pins and copper tracks with varnish.

Figure 9

Figure 10

I tried to establish a correlation between the temperature values and the weight values in order to compensate the changes. As the event ‘3’ put an offset I have two data groups. I agree the data looks funny, and it is hard to see a true correlation. (Figure 9&10) We could barely see a kind of exponential curve such as Weight = a + b. Temp², but not enough to compensate correctly.

Conclusion.

Figure 11 – Battery discharge in volts

To summarize, the concept is clearly working. I first though the battery would not last so long, but event not fully charged, the 4000mAh li-ion is still alive after a month. (Figure 11).

The HX711 used strait out of the box without shielding gives quite good results. On the 24bit resolution, around 19 to 20 are out of noise, which is remarkable for such a draft system.

As it is, I have at least an idea if there is something present (and roughly how big) in the mailbox, and this everywhere I could have an internet access. To be continued !

The BIG_CLOCK

We need clocks. Once you have passionate activities which absorbs all your attention, if you want to keep contact with the social society surrounding you, it’s crucial to know when we are.

From this observation, it started this project with the wish to use the big LCD panels which take the dust somewhere. They are Lumex LCD-S101D30TR, 7 segment digit 3″ tall. The micro controller is a PIC18F87K90, and it does everything. So the hardware comes down to only a battery, a micro (with surrounding capacitors and an oscillator) and 6 LCD panels.

 

The digits are soldered on prototyping boards, which are screwed to two long rods. A basic white surrounding plastic frame, and I think it does the job!

No relief now to say “Oh god, I didn’t see the time passing while I’m playing….”

For details, go to the hackaday.io project page : https://hackaday.io/project/9687-bigclock

 

New sensor: Electrical consumption.

One of the objective I had when I started the Raspberry pi based logging system is to record the power used in the house. My first thought was naturally use a transformer around the main power cable of the house. I tried with this kind of device :

1 – Non-invasive AC Current Sensor

As it give an AC signal proportional to the intensity, it should be use with diode and filtering capacitor to be acquired by an ADC.

As you can imagine, resolution is fixed by the ADC and for low current, you get low precision.

My power provider’s meter is one made in the 60’s, the famous electromagnetical induction watt-hour meter. The metal disc makes a complete revolution every  10Watt/hour or 36KJ. If we divide these 10Watt/hour by the time the disc takes to make a revolution, we get the instantaneous power consumption in Watts.

2 – Principle of rotation detection

We now have to detect the passage of short black mark on the side of the disc, and count the time between two. I choose to use a photo-resistor and a red laser diode for high brightness.

I’m using PIC 8bit micro-controllers, and instead of using the ADC, I choose to use the convenient comparator.

A divider made of a potentiometer give the fix voltage to compare with the signal from the photo-resistor. The rotating disc is like a large gear, implies the edge is made of tooth. The resulting signal from the brightness is then not pure square, but more a square with sine on top. Our comparator will see some “bounce” between the two states.

But the dark mark has certain length, brightness drops lasts a certain time. We could imagine then a kind of de-bouncing code (or hysteresis ?) . Consisting of allowing a change of state only if it lasts a certain time.

3 – State De-bouncing

4 – Laser and board installed, yes I should definitively improve this

The absolute precision of the system relies of the watt-meter and the PIC clock precision. Less you consume, more the counted time number increase then more ‘resolution’ we have.

It takes a bit of effort to tune the threshold of the comparator as well as the ‘de-bouncing’ counters. Also, aligning the diode and photo-resistor with the disc behind the small glass window is a bit delicate. To help, three leds indicate the status.

The code of the PIC micro-controller is compiled with Hi-Tech C compiler and is there : link

The logging station is my pilogger project. The RF link is made with a new address of the nRF24L01 network.

It runs now for about a month and have around 1 watt of resolution. I could identify that my fridge consume 90 watts during ~10 min every 90 min. Or that the water circulating pump of my heating system consume roughly constantly 80 watts.

5 – 24 hours of power consumption

On the log of this particular 24 hours window, we can see the 3Kw of the traditional oven (I made a cake :oP ), the 1.5Kw of the micro-wave oven, the regular runs of the fridge, some media such as TV plus computer plus audio amp, etc…