Ultrasonic Anemometer Part 16: Testing the new driver circuit


Last time I’ve presented my new design for the ultrasonic anemometer driver circuit. So now it’s time to see how it performs. If you’re new to this project you might want to check out the overview page or at least my last post.


By now I had the time to build up the board and to do some testing. My main struggle was with the power supply. The linear regulator LM2931 comes in both fixed and variable voltage configurations. Unfortunately there is absolutely no way to tell them apart from their markings. So I accidentially used the variable voltage variant resulting in an almost 12 volts output voltage blowing up half of my circuit. I later noticed that I was out of 5V parts alltogether and had to use a LM7805 in a TO-92 package as you can see from the photo below.


After having fixed the blown-up components, the circuit worked quite well. The first thing I did was to write some basic software for the PIC16F1936 to output a burst of40kHz PWM pulses every 2 milliseconds. After every burst the Axis and Direction signals are changed so the transducers take their turns in a clockwise order (North-East-South-West-…). The screenshot below shows part of such a burst sent from the South transducer. Note that the signal is a precise 40kHz with a duty cycle of 50% as it should be.


Below you see a full burst of 10 pulses. The number of pulses to send will be something to optimize in software once the hardware is finalized.


From the following screenshot you can nicely see how the transducers are selected by means of the Axis and Direction signals.  The microcontroller always outputs its PWM burst from the same pin. All the signal routing is controlled by means of these two signals so there is not much of a software burdon.


So sending pulses is easy and works well. But that’s the easy part. Now let’s see how the circuit performs in receiving and amplifying singals.

Below you see a complete send-receive cycle. A number of pulses is sent (red) and somewhat later received (yellow) and amplified (green). Notice the different scales. Despite being only slightly larger in amplitude on the screen, the ampified signal is about 15 times larger in amplitude. Remember from the last post that the gain is controlled by a pot so this is just a temporary setting.

The distance between the transducers is 230mm so the time delay should be roughly 700us. Looking at the screenshot below this seems to be the case.


Note that I’m sending much more pulses this time and that there is a larger-than-usual gap after the 18th pulse. As mentioned, I’m still experimenting with how many pulses should be sent and how. Here I’ve sent 18 pulsed plus 7 more pulses 180 degrees out-of-phase. My hope was that the received signal will decrease more rapidly in amplitude after reaching its peak which would make the peak easier to identify. This is still work in progress but I think this might be a simple way to improve the reliability of this wind meter.

Below you see an overview over a round of measurements. Note how different transducers produce different patterns. There seems to be quite a bit of manufacturing spread between them even though they are presumably from the same production lot.SendReceiveOverview

Now let’s look at these signals in a bit more detail. There is a significant amount of noise present in the received signal but it seems to be largely gone after the amplifier stage. The amplifier is a single op amp with a DC-coupled input and a pot acting as resistive divider setting the gain. That’s about as simple as it gets. There are no filters or anything up to this point. But the output looks nice and clean.ReceiveAmpoutCloseup2

Here’s a close up making this even easier to see. There are narrow spikes present in at the input but the limited slew rate of the op amp seems to filter them all out. So the output is clean as a whistle without any filtering. Much better than expected. Wow.


If you’ve read my last post you know that there is a second op amp which I intended to use for a active band pass filter. But there seems to be no need for that at all. Simplifies the circuit, saves an op amp as well as quite a bit of board space. Great.

Nevertheless you might have noticed that there is a wider and much larger spike in the received signal every time the axis and direction signals change. The cause of this is most likely charge injection through the p-cannel Mosfets that are used as switches between the Mosfet drivers and the transducer. ReceiveSpikeCloseup

Being much slower and wider than the noise we’ve looked at so far, this spike makes through the amplifier with only slight attenuation. The good thing is that this spike occurs when we switch from one transducer to the next. That’s a time when we won’t want to look at the received singal anyway. We haven’t even sent any pulses yet. The spike abates long before the received singal starts being of interest. So I’m confident that this spike causes no real harm and can savely be ignored.


All in all I’m positively surprised how well this design has performed. I’m obviously getting a much stronger gate drive of 12 volts as opposed to 5 volts with my old design. And not only that. The Mosfet drivers used can source and sink several amps so there is reason to hope that the signal is not only larger in amplitude but also cleaner and more square. I’ll have to look at the shape of the wave form at the transducers in more detail to verify if this is really the case.


But I’m most surprised of how well the simple op amp performs. Using this super-simple setup I’m getting an output signal that’s just as clean as what I got from the rather complex two-stage tuned common emitter amplifier. No need to tune this thing making it much more production friendly. And it saves plenty of board space as well.


So this is the way to go I think. The next step will be to come up with some circuitry to process the received and amplified signal. I have some ideas in my mind and will elaborate on them shortly. But first I’ll take a closer look at the new lasercut mechanical design.

Ultrasonic Anemometer Part 15: A new attempt

It’s been about one and a half years since I started out with my ultrasonic anemometer project. Like others before me I had to notice that this a much more demanding project than it appears to be at first. After countless hours of development and testing I have built this Arduino shield. It worked but the reliability of the measurements was never what I had aimed for. The problem was mainly how to figure out the absolute phase of the received signal. So the measurements were always precise – but sometimes off by a full wavelength.  Then I was more or less inactive for most of 2015, mainly due to personal reasons. So the project was kind of stuck but i kept (and keep) getting a lot of encouraging feedback from you folks. I came up with new circuit ideas and decided to pretty much start with an entirely new design and to re-think each and every design choice I had made back then.


I will now outline and explain my new design for the send/receive circuit. So the board we are looking at today will handle the signal routing from the microcontroller to the individual transducers and from the transducers back to the amplifier where it is cleaned-up and amplified. There’s the circuit explained step by step.


Powerful 12V drive

My last design drove the transducers from a 74HC126 line driver / buffer. This chip has tri-state outputs which made it easy to switch to receive mode by releasing the respective transducer. It also has a strong (for a logic IC) output drive of up to 125mA to switch the capacitive load that the ultrasonic transducers present.

Unfortunately, the drivers only provided a 5V amplitude. Even worse, a more contemporary design would probably operate from a voltage of only 3.3 volts potentially making things worse in the future. So I decided to use a pair of Texas Instrument LM5111 Mosfet drivers. They can handle up to 18 volts so I can run them at a 12 volt input voltage directly. Mostet drivers are designed to drive large capacitative loads so they typically have powerful outputs. Specifically, the LM5111 can sink and source 5 and 3 amps, respectively. Thats more than any logic chip could ever provide. They also share a industry standard pin-out so they are easy to replace should the LM5111 not be readily available from your preferred supplier.


Discrete Mosfet Switches

The downside of using a Mosfet driver is that they lack the handy tri-state output. So I had to find another way to release the transducers for receive mode. Readily available  integrated switches and multiplexers don’t have the low Rds-on that we need here. And they are definitely not happy if you’re trying to pass 5 amps through them. So I decided to use a discrete p-channel Mosfet for each transducer. With the gate at -5V the Mosfets conduct in the 0 to 12V range of the driving signal with a on-resistance of far below 1 ohm. So the  strong drive of the LM5111 is not forfeited. With the gate at +5V the Mosfet is not conductive for signals a few volts around ground. So the receiving transducer can swing freely, unaffected by the LM5111.

Op-Amp Amplifier and Filter

The last design used a tuned two-stage common emitter amplifier. I found the design quite beautiful with nice biasing and everything but there were severe drawbacks. Mainly, the LC tank had to be tuned carefully to have it’s center frequency at 40kHz. Coils especially have large tolerances, plus/minus 20% is quite typical. This makes it at least difficult to produce any quantity of these things efficiently. It also takes some test equipment to see if your resonant frequency is correct so the design is not really suitable if you want to distribute it as a kit.

So this design uses a dual op amp at its center. I’ve decided to use a Texas Instrument LMC6482. This is an affordable precision OpAmp with rail-to-rail inputs and outputs that can run from a wide range of supply voltages. One of its main advantages for this application is its slew rate of 1.3 volts per microsecond. This is not especially much or especially little. But it’s just right for us. And this is why: A 40kHz signal with a peak-to-peak amplitude of 10 volts needs a maximum slew rate of 1.25 V/us. So 1.3 volts is enough when operating from a +/- 5V supply. And because it is just enough it will quite effectively block any high frequency noise/spikes that might be present at the input. This is a trick I’ve learned from Horowitz & Hill’s classic Art of Electronics. It’s my first time to use it so I’m exited to see how it works.

For now, the gain of the amplifier is controlled via a pot. Future designs will probably have a fixed gain once I’ve figured out how much gain we need.


Active Bandpass Filter

Just in case the slew rate limitation of the op amp isn’t enough to get a nice, clean output signal I have planned ahead and used the second op amp from the dual LMC6482 for an active band pass filter.

I’ve played around with an Excel spreadsheet and LT Spice for a few hours trying to find suitable values for the various resistors and capacitors. I’ll do some more experimenting once I can test the results on the real circuit. So don’t pay too much attention to the compoent values of this filter for now.


Signal Routing via 74HC4052 Dual 4-Channel Multiplexer

This is something that hasn’t changed much. The 74HC4052 has already been part of my last design. I’m now using two of them, one for transmitting and one for receiving.

The first half of the transmitting multiplexer  (IC2 in the schematic) takes the PWM signal from the microcontroller and sends it to the correct Mosfet driver according to the axis and direction signals that control which transducer is sending and receiving. The second half of that IC releases the receiving transducer located opposite of the transmitting one. It does so by providing +5V to the corresponding p-channel mosfet. Pull-down resistors to the -5V rail ensure that the mosfets are conducting when not actively turned off. The +5V release signal can be controlled from a microcontroller pin. Not sure if we need this functionality so a future version might just connect this signal directly to the positive rail.

The first half of the receiving multiplexer (IC1 in the schematic) routes the signal from the receiving transducer to the amplifier input. Note that there are 10k pull-down resistors on the floating leg of the transducers so the received signal is centered around ground. In order to avoid cross-talk, the second half of IC1 actively grounds the transmitting transducer’s signal. In order to make this possible, there are 10k resistors in the signal path before the multiplexer. Given the very hight input impedance of the op amp this should not have a negative effect.


Power Supply

This circuit runs from a 12V input voltage that is directly used for the mosfet drivers. For everything else, a linear regulator generates a +5V rail. An ICL7660 inverts this voltage to generate a -5V rail. The multiplexers and the op amp then run from this +/- 5 volt supply. This is somewhat of a complication compared to the sleek plus-five-volt-only approach that I took with the Arduino shield. But this gives us a much stronger 12V drive on the transducers even if a future design will run on +/- 3.3 volts. And the split supply allow for easy control of the discrete p-channel mosfet switches and ground referenced signals in the receiving circuit.


On-board Microcontroller

I’ve included a PIC16F1936 on the board. No, I don’t have any plans to use a PIC16 in my final design. I just thought it is convenient to generate the singals necessary for testing right on the board. I do consider using a dedicated on board microcontroller in my final design. I see several advantages of doing so. The design would no longer be Arduino specific. You could still interface it to an Arduino using a  standard I2C or SPI interface. But you could also interface it to a Raspberry Pi or just about anything else. That would make it much more flexible and versatile. And even if you interface it to an Arduino the Arduino is free to focus on other things than handling the technical details of running the wind meter. With the shield one had to pay close attention not to upset the timing by running other code. So a design with an on-board chip would be easier to use as well.  Cost would not really be an issue since powerful microcontrollers are available for around 2$ even in modest quantities.  Feel free to share your thoughts on this. I’m currently looking at different architectures but no decision has been made yet.

This is it for now. In my next post I’ll share my test results with this circuit. The Eagle files and PDFs are available as a download on the project overview page.  As always I very much appreciate your comments and suggestions.

Keysight E36103A Lab Power Supply Review

20160310_KeysightE36103__011I don’t usually do reviews but I just got a Keysight E36103A Lab Power Supply today and since it’s a newly released model there’s not much independent information out there so far. At least when I ordered mine 7 weeks ago I was unable to find a single proper review. So I thought I’ll share my first impressions.


Talking of independence: I bought mine through regular retail channels and I am not in any way affiliated with Agilent/Keysight. As mentioned, I just had it for a few hours now so it’s not a thorough review but rather a my first impressions for now. I guess most of you can read a data sheet yourself so I’ll focus on other stuff here.



This is what impresses me most about this supply is its display. It is not large but has a very nice contrast and is very readable from just about any angle. I’ve taken some photos trying to show this. Just click on the thumbnails to enlarge them.

20160310_KeysightE36103__009 20160310_KeysightE36103__008 20160310_KeysightE36103__007 20160310_KeysightE36103__006 20160310_KeysightE36103__012  20160310_KeysightE36103__010

The display is even easy to read from far above or below. I have mine sitting on a shelf above so I really appreciate that. Again some examples:

20160310_KeysightE36103__017 20160310_KeysightE36103__016 20160310_KeysightE36103__015 20160310_KeysightE36103__014 20160310_KeysightE36103__013

What I also like is that now I can see both the set AND actual values for voltage and current at the SAME time. This is something I miss in the E3645A.

Fan Noise

This is a big issue for me but it’s difficult if not impossible to get any useful information from the datasheet. I can’t do sound pressure measurements or anything like that but here’s my impressions. Of course this thing has a fan. A fairly small fan so the fan noise is rather high-pitched compared to other equipment. The fan comes on as soon as the supply is powered on but runs very slow as long as the output is off. It’s still audible but not loud at all. That’s important to me since I  have the supply on with its output off for quite a large proportion of the time. I turn the output on when I need it but don’t want to wait for the startup of the supply, recall the last settings and everything. My Keysight E3645A is a nightmare in that respect. It sounds like a airplane about to take off even with the output off. [2016-04-09: I’ve finally done something about it, see here] Yes, the fan of the E3645A can also vary its speed but its really loud even at the lowest speed and gets worse from there.


As the E3645A, the fan speed seems to depend on output current rather than temperature. When you turn the output on, the fan immediately speeds up quite a bit. When you then pull a fair amout of current the fan speeds up even more. But overall, fan noise is fairly well controlled. I prefer the E36103A’s fan noise at the highest speed to that of the E 3645A’s at its lowest speed setting. I think its not only quieter but I also find it less annoying despite the higher pitch.


But nevertheless, there is a fan and it is clearly audible, especially with the output on. Unfortunately, large heat sinks have gone out of style it seems.

Programming and Readback Accuracy


To me, readback accuracy is even more important than programming accuracy. I don’t care so much if my DUT is running at 3.3 or 3.32 volts but I like to know reliably and precisely what the voltage and current are. Especially when I’m calculating the efficiency of some switching regulator like my MPPT solar charger. I don’t want to set up 4 DMMs for that (and I don’t have 4). So I want reliable readings from the supply.


The datasheet states a readback accuracy of 0.05%+5mV and 0.05%+1mA, respectively. So the voltage readback accuracy is similar to the E3645A (0.05%+2counts) but current readback is much improved (vs. 0.15%+5mA).

Similarly the E36103A features better programming accuracy: 0.05%+7mV (vs. 0.05%+10mV) and especially 0.05%+1mA (vs. 0.2%+10mA).

I should note that the comparison for voltage is not quite fair since the E3645A has a much higher maximum output voltage of 35V and 60V compared to the 20V of the E36103A.


I have quickly hooked up a pair of DMMs to the supply and have found the readings of the DMMs to correspond very well to those of the supply as you can see on the photos.

Small Current Readback Accuracy

This supply has the nice feature of being able to measure very small currents quite precisely. That’s really nice when working with microcontrollers and the like that hardly consume any power when in sleep mode or running at a low clock speed.

I’ve done some tests with the supply connected to a 1% 1 megaohm resistor and an Agilent U1253A DMM that features a similar low current range. I have disconnected the voltage DMM just to be sure it doesn’t affect the measurement.

Since the resistance is 1MOhm we can expect 1uA of current per Volt. So at the maximum output voltage we’ll only draw 20uA. That’s really not much given the specified 0.25%+40uA readback accuracy (up to a maximum of 8mA).

With nothing connected to the output I have observed measurements in the range of 0 to 25uA which is well within spec. When looking at the difference in measured current before and after connecting the 1MOhms resistor, the results are reasonably close to the actual values.

Here are some photos that illustrate that point:


20160310_KeysightE36103__028 20160310_KeysightE36103__029


20160310_KeysightE36103__030 20160310_KeysightE36103__031



All in all I found the small current feature to be very usable (and well within spec). But unlike with currents in the mA to A range, a DMM like the Agilent U1253A performs much better as you can see from the photos.


Package Content


I didn’t check what exactly is suppoed to be in the box but found everything I expected but also nothing more.


Besides the supply itself and a power cord there is a certificate of calibration, a CD with some software as well as some warranty papers.



This is, of course a physically small supply and the datasheet will tell you precisely how large it is. I basically expected it to be half the size of the E3645A (which it technically is) but was surprised how small it was when I took it out of the box.


It doesn’t really show on the photos but it looks even smaller than half the size. I guess that’s because of the rubber padding around the E3645A which the E36103A doesn’t have.



Ethernet and USB connectivity is one of the big selling points for this series of power supplies. I find it surprising how long Agilent got away with RS232 and GPIB. I often control my scope over BenchVue and I’m looking forward to do the same with this supply. I’m also planning to send commands from C# programs in order to do some calibration and things like that.


So far I haven’t tried any of that yet but I’ll definitely share my experience once I got a chance.


Another thing I really like is the sense terminals on the front rather than on the back. I found I don’t use them on the E3645A since it’s just too much of a hassle to attach sense leads to some screw terminal located at the back of the supply.

User Interface


I haven’t even glanced at the user manual but have found everything to be quite intuitive.

The Lock/Unlock feature is nice to prevent you from changing your output voltage/current by accident. A short press of the Lock/Unlock button and the thing is locked. It then takes an a bit longer (maybe half a second or so) press to unlock it again. I like it.


All the (few) menues are straight forward and easy to find/use.

Concluding Remarks

Again, I’ve only had my hands on this thing for a few hours but so far I’m very happy with what I saw and I’m looking forward to using the E36103A as my main lab supply going forward.  It was an impulse buy really. I saw it on sale online for 823 Swiss Francs (USD 835 at the time of writing)  including shipping and taxes and everything and just ordered it from my cell phone on my way to work one day 😉

If you have specific questions please just leave a comment below and I will try to answer it.

PWM Dimmer for RGB LED

Finished RGB dimmer
Finished RGB dimmer

In my last post I’ve described the design and construction of my LED dimmer project. This project here is similar but a bit more involved. It controls RGB LEDs so it can not only change the brightness but also the color of the light. Instead of a simple pot it used a pair of rotary encoders with push buttons. One controls the brightness, pushing its button turns the light on or off. The other changes the color, pushing its button toggles between color and white.


Encoder's side
Encoder’s side

There’s also a I2C interface included this time. I originally had the idea to hook this thing up to a Raspberry Pi and so be able to control the light from my computer or cell phone. I did establish an I2C connection to the RPi and it all works but it’s now installed as a stand-alone solution.

Since we’re now controlling RGB LEDs we obviously need three independant PWM outputs, one for each for red, green and blue. But let’s go through the circuit step by step.

Power Supply

The board is powered from a fairly powerful 12V supply that is always on. A LM2931 turns this into a microcontroller-friendly 5V. But if we want to connect this board to a Raspberry Pi we need to match the RPi’s 3.3 volts operating voltage. Apart from hobbyist projects there aren’t many microcontroller circuits running at 5V nowadays. Most of the PIC16Fxxx family of chips still handle 5 volts but this is becomming more and more of an exception. So in order to be compatible with the rest of the world this board will need a way to adapt it’s voltage.


What I’ve done here is the following: The board has it’s own 5V regulator and you can power from that using a jumper on the I2C header. On the other hand, if the board is connected to a Raspberry Pi over I2C, it will just freeride on the RPi’s 3.3V operating voltage. Since the board is only drawing a few milliamps at 3.3V this is perfectly fine. The RPi specs allow for 30mA or so to be drawn in this fashion.

Rotary Encoders

I’m using a pair of Bourns PEC11R-4215F-S0024. These are  24 steps-per-rotation encoders with a push button that I’ve used for other projects before. I’ve made it a habit to debounce switches and encoders in hardware rather than having to worry about it in software. There’s even an entire post just on that subject: https://soldernerd.com/2014/11/12/switch-debouncing-using-74hc14/.

So all 6 signals comming from the encoders are first RC filtered and then run through a 74HC14 schmitt-triggered inverter and reach the PIC nice and clean.



I’ve once again used a PIC16F1936 but this is entirely uncritical since most microcontrollers come with the features needed here.  We mainly need 3 10-bit PWM modules and an I2C interface if we want to connect to the Raspberry Pi.

The PIC is running at 32MHz using its internal oscillator which gives us a maximum (10-bit) PWM frequency of 31.25kHz which has proved adequate in my last dimmer project.


I once again used the inexpensive yet powerful  Infineon IPB136N08N3 N-channel MOSFETs. Since I have to drive 3 of them this time I need two LM7111 dual MOSFET drivers. As opposed to last time when each output had its own capacitor, they now all share a 1.5mF electrolytic cap.



As so often, most of the interesting stuff happens inside interrupt service routines (ISRs).  This one serves two tasks:

  • Read the input from the rotary encoders. Every time one of these input signals changes, an interrupt (interrupt-on-change, IOC) is triggered and the ISR calculates the updated values for brightness and color and sets an update flag so the main code knows that something has changed.
  • Send and/or receive data over I2C. The PIC is configured as Slave so it won’t do anything unless some other device attached to it will request or transmit data. The ISR just technically handles the sending and receiving o data. It just fills a receive buffer or sends data from a send buffer. It is entirely up to the regular code what should be sent and how received data is interpreted.


As I’ve mentioned I’m not using the I2C interface at the moment so the implementation is somewhat basic. Data can be sent to the board and it is stored in a recieve buffer but nothing is not processed. When asked for data it transmits up to 11 bytes indicating it’s current state of operation such as brightness of each color channel and some more data.

There is also nothing preventing the content of the buffer from being changed while a transmission is in progress. So if you’re planning to really use this I2C feature you probably want to improve it somewhat but the code (download link at the end of this post) gives a good, working starting point. If you need help, just ask.

Controlling the outputs is not that challenging. Its jus 3 10bit PWM modules  running 120 degrees out-of-phase to smoothen the current seen at the input. Again, the LM7111 I’ve used are of the inverting type so the duty cycle has to be inverted in software.

I’ve used a lookup table for brightness (only 32 brightness levels this time) and color.  I’ve defined 24 colors that make a nice color circle. You can turn the color encoder infinitely and just loop through the colors defined in the lookup table. When you press the button on the encoder, the color changes to plain white but the color is remembered so when you press the button again the same color comes back.  Brightness works in a similar way: press the button and the light goes off, press it again and the light is back with the same brightness as before. Overall, this makes a quite intuitive user interface.

Testing and Troubleshooting

Acoustic noise was not an issue this time. I started with 31.25kHz switching frequency and 120 degrees phase shift right away. Apart from that the power level is lower, more like 70 watts maximum. And I was using a different supply that might be less susceptible to acoustic noise. don’t know, haven’t tried.


Mass connections have proved to be a problem, though. Usually I take great care during board layout to make sure all components have excellent ground connections. Together with the generous use of 100nF ceramics decoupling capacitors this prevents lots of problems before they even appear. Thank you John Catsoulis (http://shop.oreilly.com/product/9780596007553.do) for stressing this point when I started designing my own circuits. You might have noticed that just about every IC on any of my designs has its own ceramic cap on each of its power supply pins. That’s thanks to John and it has served me very well.


But back to the problem: It seems that this time I’ve been a bit sloppy with my ground connections around the two MOSFET drivers and the encoder on the right. They’re not that bad but aparently not good enough. The LM7111 are quite powerful. Up to 5Amps peak current according to the datasheet. And  together with my not-so-great ground connections that was enough to get false triggering from that encoder.  A few wire bridges improving the ground connections solved that problem. I’ve already fixed that problem in Eagle so the files available for download should be fine.


There was also another problem: It was impossible to turn the green (middle) channel off entirely. No matter what I did in software, the green LEDs always stayed on if only a little bit. I looked at the PWM signal from the PIC on a scope and there was a slight glitch every full PWM period, aparently when the PWM register overflows  from 1023 to 0.  The other two channels (red and blue) didn’t suffer from this problem.


As I said, I have to correct for the inverting nature of the LM7111 in software. The enhanced (ECCP) PWM modules can do this automatically. But there are only two if them in a PIC16F1936 so I had to use a regular (CCP) module for the green channel. So in order to turn the green LEDs off the duty cycle has to be 100%. And that seems to be impossible without that little glitch.

I first tried a pull-up resistor on that PWM signal but that didn’t help. The pic seems to actively pull that pin low. So I resorted to a 10pF cap to ground which finally solved the problem.


Since the board is installed hidden in some kind of bookshelf I didn’t make a new pretty board with all these fixes already in place. But I’ve now  been using it for two months or so and it works perfectly every day.

I’ll finish this post with a few impressions of the final product and the download link below.




As always, here you find the Eagle Files, PDFs of schematic and Board as well as the code.