[{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/tags/hugo/","section":"tags","summary":"","title":"hugo","type":"tags"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/tags/kicad/","section":"tags","summary":"","title":"kicad","type":"tags"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/tags/meta/","section":"tags","summary":"","title":"meta","type":"tags"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/posts/","section":"posts","summary":"","title":"posts","type":"posts"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/","section":"soldernerd","summary":"","title":"soldernerd","type":"page"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/tags/","section":"tags","summary":"","title":"tags","type":"tags"},{"content":"It\u0026rsquo;s been a while. The blog has been sitting there, largely unchanged, collecting dust and serving ads to anyone who happened to stumble across it. So I decided it was time for an overhaul.\nNew look, no ads # The site has been rebuilt from scratch. Gone is WordPress, gone are the ads. What you\u0026rsquo;re looking at now is a static site generated by Hugo using the Blowfish theme. The entire site is a collection of Markdown files and a handful of config files — no database, no PHP, no plugin updates to worry about.\nComments are handled by Giscus, which uses GitHub Discussions as a backend. No ads, no third-party tracking. You need a GitHub account to comment — which if you\u0026rsquo;re reading this blog, you probably already have. As a side benefit, the need to have a github account hopefully acts as a quite effective spam filter. Spam comments have been a real issue previously.\nThe source lives on GitHub and every push to the main branch automatically builds and deploys the site. Writing a new post is just creating a Markdown file and running git push.\nRethinking the toolchain # The blog rewrite is part of a broader effort to rethink the tools I use and how I work. The common thread: move away from GUIs and proprietary binary formats, toward codebases and open text formats that play well with version control — and increasingly, with AI tools. The blog rewrite was 95% Claude Code, currently my favourite of the AI tools I\u0026rsquo;ve tried.\nEagle to KiCad # A significant toolchain change on the hardware side is moving from Eagle to KiCad. I used Eagle for years and it served me well. And since I\u0026rsquo;m using Fusion 360 for my mechanical designs and pay for a Fusion subscription anyways, the new Autodesk licensing changes are not impacting me directly. But Fusion is not where the hobbyist crowd hangs out nowadays. And the move from Eagle to Fusion is not entirely self-explanatory either. I have never made that transition but rather stuck with long-outdated Eagle 7 until now. Since I have to make an effort to learn a new tool anyways, I evaluated the 2026 landscape more carefully and ended up with KiCad.\nFirst of all, it\u0026rsquo;s usually a good idea to use what other hobbyists use and today that\u0026rsquo;s KiCad. It\u0026rsquo;s open source, actively developed, and stores everything in human-readable text formats. A schematic or PCB layout is a text file. That means it can live in git, diffs are meaningful, and an AI assistant can actually read and reason about the design.\nWhat\u0026rsquo;s next # The workshop projects haven\u0026rsquo;t stopped — they\u0026rsquo;ve just been undocumented here. The day to day stuff is on Zerspanungsbude — a German forum, roughly the equivalent of practicalmachinist.com. As that indicates, most of my more recent projects have been precision mechanics rather than electronics, so expect to see more of that here in the future. That said, my more recent experiments with those increasingly capable AI tools have really motivated me to do more electronics again. I love designing electronics. And I also like writing code. But developing and maintaining a large base of embedded C code is extremely time consuming and sometimes tedious and repetitive. Or at least it has been. If I can outsource some of that work to, say, Claude Code that would change things a lot for me. Expect a mix of electronics and mechanics going forward.\n","date":"17 April 2026","externalUrl":null,"permalink":"/posts/the-blog-is-back/","section":"posts","summary":"It’s been a while. The blog has been sitting there, largely unchanged, collecting dust and serving ads to anyone who happened to stumble across it. So I decided it was time for an overhaul.\n","title":"The Blog is Back","type":"posts"},{"content":"","date":"17 April 2026","externalUrl":null,"permalink":"/tags/workflow/","section":"tags","summary":"","title":"workflow","type":"tags"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/categories/","section":"categories","summary":"","title":"categories","type":"categories"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/categories/diy-projects/","section":"categories","summary":"","title":"diy-projects","type":"categories"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/categories/mechanics/","section":"categories","summary":"","title":"mechanics","type":"categories"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/tags/pic18/","section":"tags","summary":"","title":"pic18","type":"tags"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/tags/pic18f47j53/","section":"tags","summary":"","title":"pic18f47j53","type":"tags"},{"content":" Looks almost like the first version\nThis board may look familiar to some of you. Because at first glance, it looks just like its older brother described here: Dividing Head Controller. But many things have been improved in Revision B.\nChanges are only visible from the back side\nIt has also found new use cases. Depending on how it is programmed, it can be applied wherever a stepper motor needs to be driven from a user interface or PC. So while it was first designed specifically to drive a dividing head, it is actually quite universal.\nRe-designed power supply on the left\nNow what\u0026rsquo;s new? First of all, the power supply has been improved to accept input voltages in the range of 6 - 60 volts instead of 6 - 30 volts previously. For me, this was one of the main reasons for the upgrade. The stepper motor I\u0026rsquo;ve used for the dividing head lacked a bit more torque at higher RPMs when operated from 24V. This new version has allowed me to use a 48V supply which has solved all the torque problems.\nA more powerful microcontroller on the left and the new flash chip on the right\nThe other main upgrade is a more capable microcontroller, a PIC18F47J53. Together with a 32Mbit flash chip, this allows for a USB bootloader. It enables firmware updates without any specialized hardware or software. Any PC with a USB port will do, no matter the operating system. Watch this video for a demonstration of how it woks.\nhttps://www.youtube.com/watch?v=vja0ijuAdeU\nSince the stepper controller behaves just like a USB drive when connected to a computer, it also allows users to customize their device by simply editing a config file that resides on that drive.\nBesides the fan output, there is now also an output for a mechanical brake. But despite the labelling, these are simply open collector outputs, with flyback diodes included, capable of driving around 1 amp. So depending on the software, they can be used for any other purposes.\nThree devices during programming and testing\nThe remaining features are unchanged: There is still a 4 x 20 characters LCD display and two nicely hardware-debounced rotary encoders. There is still a buzzer, EPROM memory, reverse-polarity protection, an on-board temperature sensor and an input for an external temperature sensor (or any other analog input signal in the 0-3.3V range).\nDesktop application for the dividing head\nAnd there still is that USB port. But with the USB bootloader and the config file, this USB port has become much more useful. And I\u0026rsquo;v also spent some time writing software so that the device can be controlled from a (Windows) PC.\nA different desktop app for a different use case. But absolutely identical hardware.\nAnd as I\u0026rsquo;ve mentioned, the board has found new use cases that use application-specific software but absolutely identical hardware. And the modular design of the software allows for the most of the software to be re-used so you don\u0026rsquo;t have to re-invent the wheel whenever you have a new application for this device. You don\u0026rsquo;t have to re-do all the heavy lifting required for USB or smooth motion control. A few changes to the user interface and the corresponding API will typically cut it.\nAll the hardware and software is open source, ready for you to use, improve and adapt. It\u0026rsquo;s all on GitHub so let me just share the various repos:\nHardware:\nhttps://github.com/soldernerd/StepperMotorController\nBootloader:\nhttps://github.com/soldernerd/StepperMotorController_Bootloader\nFirmware:\nhttps://github.com/soldernerd/StepperMotorController_Software_RevB\nDesktop applications:\nhttps://github.com/soldernerd/RotaryTableApp\n","date":"1 January 2020","externalUrl":null,"permalink":"/posts/stepper-motor-controller-rev-b/","section":"posts","summary":" Looks almost like the first version\nThis board may look familiar to some of you. Because at first glance, it looks just like its older brother described here: Dividing Head Controller. But many things have been improved in Revision B.\n","title":"Stepper Motor Controller Rev B","type":"posts"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/tags/stepper-motor/","section":"tags","summary":"","title":"stepper-motor","type":"tags"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/tags/usb-bootloader/","section":"tags","summary":"","title":"usb-bootloader","type":"tags"},{"content":"","date":"1 January 2020","externalUrl":null,"permalink":"/tags/usb-msd-bootloader/","section":"tags","summary":"","title":"usb-msd-bootloader","type":"tags"},{"content":"","date":"16 December 2019","externalUrl":null,"permalink":"/tags/cnc/","section":"tags","summary":"","title":"cnc","type":"tags"},{"content":"","date":"16 December 2019","externalUrl":null,"permalink":"/categories/cnc-mill/","section":"categories","summary":"","title":"cnc-mill","type":"categories"},{"content":" The Universal Interface\nIt\u0026rsquo;s time to present a relatively simple yet useful device: the Universal Interface. The need for this little helper arised when building the control for my CNC milling machine. But that\u0026rsquo;s a major project that I will introduce another time. Today it\u0026rsquo;s only about this little board.\nUniversal Interface at work inside the CNC control cabinet\nMy challenge was that I had to connect to and from a variety of external devices. Such as coolant pumps, pneumatic valves, probes and the like. Input and output signals could be anything from 5V logic, open collector logic, 24V logic to a relay. And they could be active low or active high.\nThe backside\nSome situations also required a bit of logic. Not much but still some. Something like an AND and an OR gate or so. None of those circuits were challenging to design. But there were several of those and I didn\u0026rsquo;t really want to custom design and build a board for each one. Besides the fact that some in- and outputs were not entirely final yet or could change in the future. In other words, I wanted a single design that is flexible enough to handle all the present and future little challanges.\nA total of 4 such interfaces are at work in the CNC control\nNow to the design. There are 3 inputs (A, B and C) plus an enable input (EN). Each of these inputs is 24V tolerant and can be equipped with pull-up or pull-down resistors. And each of them can be configured to be either active high or active low. And of course, each of these inputs is nicely debounced by running it trough an RC filter followed by a Schmitt triggered logic gate. The logic state of each input is indicated with an orange LED located next to the input.\nThe inputs\nNext comes the logic part. It uses a 74HC151 8-input logic multiplexer. The three inputs A, B and C select, which of 8 possible inputs is selected. The logic value of these inputs is then determined by 8 resistors as shown below. This allows an arbitrary logic function to be implemented in hardware. Nothing on this board requires software, it\u0026rsquo;s all hardware.\nA hardware-configured logic table\nThen comes the output stage. There is only one single logic output but it is provided in multiple varieties:\nFirst, there is a single-pole, double-throw (SPDT) relay that is good up to 250 volts and 10 amps.\nThen there is a powerful open collector output that can drain up to 2 amps. Flyback diodes are already included so this output can directly be used to drive another relay, a motor or whatever.\nThen there is a standard CMOS 5V logic output. It can source or drain up to something like 25mA, pretty standard really.\nAnd then there is also a 24V logic output which can optionally be equipped with a pulldown resistor or as a push-pull output as you know it from a typical CMOS gate. It can easily sink or source something like 500mA, maybe more. Protection diodes are also provided.\nThe outputs\nAnd then there is also the enable input. If the enable input is not active, the 5V, 24V and OC output will all enter a high-impedance state. Of course, the relay does not have a high-impedance state and will just remain in its unenergized (i.e. off) position.\nThe power supply\nAs this circuit was intended to for use in an industrial environment, its supply voltage is 24V. This could easily be changed to 12V by simply using the 12V version of the relay - nothing else needs to be changed. The 5V voltage for the logic and 5V output is generated by a switching power supply that is good for up to 1 amp output current (far more than ever needed here) and an input voltage up to 30 volts. There is plenty of capacity both at the input (220uF) as well as the output (680uF). And yes, it is also reverse-polarity protected.\nSide by side\nThat\u0026rsquo;s all I can say about this device. I\u0026rsquo;m currently using 4 of them in my mill, with different configurations, and they all work reliably.\nThere is room for more.\nAs you never know what the future brings, there is room for 3 more of these little helpers in the control cabinet. And if something is to change, I can likely accomodate for that change by simply changing a few resistors.\nWhere the input signals get treated\nAs all my stuff (or most of it, anyway), this project is on github:\nhttps://github.com/soldernerd/UniversalInterface.\n","date":"16 December 2019","externalUrl":null,"permalink":"/posts/universal-interface/","section":"posts","summary":" The Universal Interface\nIt’s time to present a relatively simple yet useful device: the Universal Interface. The need for this little helper arised when building the control for my CNC milling machine. But that’s a major project that I will introduce another time. Today it’s only about this little board.\n","title":"Universal Interface","type":"posts"},{"content":"","date":"3 February 2019","externalUrl":null,"permalink":"/tags/encoder/","section":"tags","summary":"","title":"encoder","type":"tags"},{"content":"","date":"3 February 2019","externalUrl":null,"permalink":"/tags/fu/","section":"tags","summary":"","title":"fu","type":"tags"},{"content":"","date":"3 February 2019","externalUrl":null,"permalink":"/tags/pic16f18855/","section":"tags","summary":"","title":"pic16f18855","type":"tags"},{"content":"","date":"3 February 2019","externalUrl":null,"permalink":"/tags/tachometer/","section":"tags","summary":"","title":"tachometer","type":"tags"},{"content":"I\u0026rsquo;ve just finished the variable-frequency drive (VFD) for my 1970s Schaublin 102 lathe. Before I dig into details, there\u0026rsquo;s a youtube video here:\nhttps://www.youtube.com/watch?v=TJsa5KmIs7Y\u0026t\nMy new VFD drive in action\nI bougth this lathe around a year ago and it came with a bulky, two-speed 3-phase motor. My workshop at the time didn\u0026rsquo;t have a wall outlet for 3-phase power so I decided to run the lathe on regular 1-phase 230 volts using a frequency inverter. I knew that this kind of motors run poorly on inverters but I tried anyway. The result was even worse than expected, it barely ran and lacked any torque.\nThe old drive\nSo as expected I had to get a more suitable motor. After a bit of online research I ordered a physically smaller, 080 size Lenze MF series motor. This series of motors is specifically designed for inverter operation and offers constant torque over a wide range of frequencies. I sized it to offer slightly more torque than the original motor but that still resulted in a considerably smaller size and weight.\nNew motor temporarily mounted\nI temporarily mounted the new motor with an adaptor made of 3 sheets of wood and added a cheap RPM meter I ordered on Alibaba. With a pot and two switches quickly mounted on top of the motor I got a working lathe. The new drive offered enough torque in all situations I encountered as well as a wide range of speeds. The main downside was that I lost the 3-speeds the lathe originally offered because the original V-belt pulley with its 24mm bore would not fit the new motor\u0026rsquo;s 19mm shaft. So I started to design a more permanent arrangement.\nCarelessly mounted Alibaba RPM meter worked reliably (but super slow)\nJust turning an adapter for the original pulley was not really an option because that would have resulted in a top speed of 8000+ RPM while only going down to about 200 RPM in low gear. So I decided to use the original pulley but with a fixed 2:1 reduction before that, giving me a more useful 100-4200 RPM range. For that purpose, I decided to use a 25mm, HTD-5M toothed belt.\nBasic arrangement with shaft, bearings etc.\nAfter playing around with several different designs in Fusion360 I started turning the various parts above. The motor, gearing as well as the inverter and controls were to be held together by an aluminium structure.\nThe 2:1 gearing at the core of the new drive\nWith the mechanics in place I started designing the electronics around it. For me, that\u0026rsquo;s the easy part ;-) Obviously, I need a pot and a 2-way switch to control the speed and direction plus a main switch. But since my lathe doesn\u0026rsquo;t have a lead-screw and hence can\u0026rsquo;t cut threads I thought I might one day want to add a CNC control just for that purpose. So I wanted to be able to remote-control the entire drive as well as to provide the necessary signals for a CNC control to monitor the speed.\nBasic construction using 4 aluminum plates\nWhile the chinese RPM meter worked reliably, it reacted super-slow to changes in speed and the bulky sensor proved difficult to mount in an elegant way. On top of that, it offered only a resolution of a single impulse per rotation and no information regarding the direction of rotation. I googled a bit and ordered a GTS45 gear tooth sensor from Renishaw. Its output is a standard, 90 degrees out-of-phase quadrature signal. Despite being a quality, industrial grade sensor, it only costs around 20 EUR and they are happy to sell them in single quantities. I also ordered a maching 90mm, 64-tooth tooth weel.\nThe remaining 64-thooth thooth-wheel with sensor in the background\nI turned away most of this tooth wheel until only a rim with an 80mm bore remained. That then fitted nicely besides the pulley on the headstock. I decided to design my own RPM meter and to fully integrate it into the rest of the control. This reduces everything to a single PCB which simplifies wiring quite a bit.\nFront panel\nI wanted to have nice, large switches on the front panel even though the forward/reverse switch only provides a control signal and doesn\u0026rsquo;t switch any power. I also turned a know for the pot out of 1.4305 stainless steel. Together with the 4-digit 7-segment display, the physical layout was pretty much given. So I had to design the PCB to somehow fit in.\nBack side of the front panel\nTo simplify things, the control runs right off mains voltage which is converted to 12V and 5V DC right on the board. The 12V rail is used to power the sensor as well as to operate 3 DR12 relais. Everything else runs on 5 volts. The inverter is controlled by two of the relais (one for forward, the other for reverse) while the third relay is used to choose beween two speed sources, one from the front-panel pot, the other one from an external input.\nPIC microcontroller and input filtering\nAt the core of the design is a PIC16F18855 microcontroller. There are numerous inputs and outputs:\nForward, Reverse and Speed output to the inverter Inputs for the forward/reverse switch and the pot on the front panel Inputs for the quadrature signals from the sensor (as well as power supply for the sensor) Inputs \u0026amp; outputs for remote operation: Enable, On and Reverse digital inputs, speed analog input (0-10V) and quadrature digital outputs All digital inputs are RC-filtered and Schmitt-triggered before they are used. The PIC consumes all these inputs and then controls the display and the 3 relays accordingly. The cleaned inputs from the sensor are then also made available for the remote control via ULN2003 darlington pairs.\nState of digital inputs is displayed via LEDs\nThe state of all digital inputs as well as the relays is clearly displayed using LEDs. While these are invisible inside the case, they are valuable while programming and setting things up.\nFinal assembly\nWith the motor coated with 2-component paint in RAL7031 blue grey, everything was assembled and wired using shielded wires. All that remained was to install it on the lathe and to try it out.\nFinally. The new drive is mounted on the lathe and ready for use\nFor testing the remote operation functionality, I had to build some sorts of a remote control first. Besides the switches and a pot it also needed an RPM meter capable of dealing with quadrature signals. For the fun of it, I designed my own. I\u0026rsquo;ll describe that in a future post.\nRemote control using a DIY RPM meter\nAs always, eagle files and code are available on github:\nhttps://github.com/soldernerd/InverterController https://github.com/soldernerd/InverterControllerSoftware ","date":"3 February 2019","externalUrl":null,"permalink":"/posts/variable-frequency-drive/","section":"posts","summary":"I’ve just finished the variable-frequency drive (VFD) for my 1970s Schaublin 102 lathe. Before I dig into details, there’s a youtube video here:\n","title":"Variable-Frequency Drive","type":"posts"},{"content":"","date":"3 February 2019","externalUrl":null,"permalink":"/tags/variable-frequency-drive/","section":"tags","summary":"","title":"variable-frequency-drive","type":"tags"},{"content":" This post ist about the CNC conversion of a manual dividing head aka indexing head. If you\u0026rsquo;re not familiar with that kind of equipment, there\u0026rsquo;s a wiki page here. One makes use of interchangeable indexing plates and and the internal worm gear to accurately divide the circle. Parts like cogwheels and the like can be machined this way. A video of the finished project can be found here on my youtube cannel.\nThe downside is that a high level of concentration is required to not mess things up. Often a single distraction is all it takes to ruin a part. Besides the fact that constantly changing indexing plates can get tedious. So I decided to mount a stepper motor to that indexing head and to design a controller to take care of that motor.\nThere are many affordable and well-designed stepper motor drivers out there so I decided to use one of those rather than building my own. So an external driver takes care of translating the 5 volts logic step / direction signals into the (typically 12, 24 or 48V) power signals required to drive the stepper motor. What this circuit does is to provide a user interface and to generate that step / direction signal.\nI decided to use this motor driver from Planet CNC that comes with a 2x5 pins 100-mil header for the logic signals. So I also put such a connector with a corresponding pin-out on my board. Then a single ribbon cable (provided with the motor driver) is all it takes to hook up the driver.\nThe user interface consists of a 4x20 character LCD display and two rotary encoders with push buttons. The display is a Midas MCCOG42005A6W that I have used in several of my other projects before. It is very compact and comes with an I2C interface which saves quite a few pins on the microcontroller. There is also a buzzer to provide some acoustic feedback on button presses and the like. If it enoys you, you can always turn it off in software.\nAs in all my designs, the rotary encoder signals are nicely debounced in hardware as described here.\nThe board runs on a 24V supply that is also used to drive the motor. The microcontroller, a Microchip PIC1826J50, runs on 3.3 volts. Furthermore, the motor controller requires a separate 5V supply to power its logic. So I first designed a switching converter that generates a 5V output from any input voltage in the range of 6 to 30 volts. A linear regulator then produces 3.3 volts out of that 5V rail to power the PIC and other on-board logic. Unfortunately, a bug as creeped into my PCB layout - hence that fix with a piece of wire just below the coil.\nWith the PIC running on 3.3 volts and the motor driver at 5 volts, I also had to provide some logic-level conversion. A 74AHCT125 line driver / buffer and a few resistors take care of that.\nThe PIC also comes with a USB interface so that the board could be controlled remotely from a PC. All the hardware for that is present on the board but I haven\u0026rsquo;t written any software for that yet. Most of that can be copy-pasted from other projects such as the solar charger but I simply haven\u0026rsquo;t done any of that yet.\nFinally, there is a temperature sensor and a fan output on the board. I\u0026rsquo;m not currently using it but if there is need for a fan for the motor driver and/or the power supply, you can connect a fan directly to this board and have it temperature controlled. For the fan output, the buzzer and the display backlight are driven by a TPL7407L that already includes the free-wheeling diodes necessary to drive inductive loads such as a fan.\nI\u0026rsquo;ve mounted all the power supply, the motor driver as well as this board in a nice, compact case that I bought at a flea market earlier this year.\nNice, solid ground connections are provided to all relevant components. The USB connector is accessible from the back through an extension cable.\nThe other USB connector belongs to the motor driver and is used for configuration.\nFinally, the two knobs for the rotary encoders were turned out of aluminum at the lathe.\nThe rest of it is mainly mechanics. This may seem somewhat off-topic on this blog but expect to see more of it in the future ;-)\nHere are the parts required for the mechanical part of the CNC conversion. With the exception of the two cog wheels for the timing belt, they are all machined out of aluminum on a manual mill.\nFirst, a spacer is mounted using three existing, M5 threaded holes.\nThe main body is then screwed onto this spacer and the cogwheel is mounted.\nThe hub of the cogwheel was turned out of steel and then press fitted to the aluminum cogwheel. This provides for a firm, true-running.\nThen the motor with the 22 tooth sprocket can then be mounted together with the 15mm HTD-5M timing belt. Together with the 44 teeth cogwheel on the other end, this provides a 2:1 geering. The dividing head\u0026rsquo;s internal worm drive adds another factor of 90:1.\nSince the motor, a Sanyo Denki 103 H7823 1740, has a resolution of 200 steps per revolution, this translates to a very convenient 0.01 degrees per full step.\nNow all that is left to do is to fix the cover plate. As usual, all the relevant files are on github:\nHardware: https://github.com/soldernerd/StepperMotorController Software: https://github.com/soldernerd/StepperMotorController_Software ","date":"2 December 2018","externalUrl":null,"permalink":"/posts/dividing-head-controller/","section":"posts","summary":" This post ist about the CNC conversion of a manual dividing head aka indexing head. If you’re not familiar with that kind of equipment, there’s a wiki page here. One makes use of interchangeable indexing plates and and the internal worm gear to accurately divide the circle. Parts like cogwheels and the like can be machined this way. A video of the finished project can be found here on my youtube cannel.\n","title":"Dividing Head Controller","type":"posts"},{"content":"","date":"2 December 2018","externalUrl":null,"permalink":"/tags/pic18f26j50/","section":"tags","summary":"","title":"pic18f26j50","type":"tags"},{"content":"","date":"20 November 2018","externalUrl":null,"permalink":"/categories/mppt-solar-charger/","section":"categories","summary":"","title":"mppt-solar-charger","type":"categories"},{"content":"","date":"20 November 2018","externalUrl":null,"permalink":"/tags/mppt-solar-charger/","section":"tags","summary":"","title":"mppt-solar-charger","type":"tags"},{"content":"","date":"20 November 2018","externalUrl":null,"permalink":"/categories/software/","section":"categories","summary":"","title":"software","type":"categories"},{"content":"","date":"20 November 2018","externalUrl":null,"permalink":"/tags/solar-charger/","section":"tags","summary":"","title":"solar-charger","type":"tags"},{"content":"Let\u0026rsquo;s start with a video. It will tell you most of what I\u0026rsquo;m going to write about today.\nhttps://www.youtube.com/watch?v=dOdkUrF5qdM\u0026t\nThat Hackaday Prize final has passed and unfortunately for me, the solar charger didn\u0026rsquo;t make it into the top 5. The good news is that there are plenty of projects and stuff that I would like to share. Things that I did over the last one or two years but never had time to write about. I\u0026rsquo;m trying to catch up with all that now.\nFirst of all, I have completed the USB bootloader for the solar charger. This part of the project will enable the non-technical end user to easily and reliably update the firmware in the field.\nUnlike a USB HID (Human Interface Device) bootloader that requires some application to run on the host computer, this USB MSD (Mass Storage Device) bootloader requires absolutely nothing in terms of host software. It\u0026rsquo;s entirely independent of the OS used. Windows, Linux, Mac, it all doesn\u0026rsquo;t matter. As long as they can deal with a USB drive, they\u0026rsquo;re good to go. Just copy the new software (in the form of an .hex file) to the Solar Charger drive and follow the instructions on the display.\nIt might even be that this bootloader is the world\u0026rsquo;s first of its kind for the PIC18 platform. To be sure, this kind of bootloader has been around for years for more powerful 32-bit microcontrollers like ARM Cortex and the like. But in my online research I have been unable to find any other such project for the PIC18 family (or any other 8-bit microcontroller). So I had no choice than to write my own. If you know of any other implementation, please let me know.\nOnce the file has been found and the user has pressed the button, the file is checked. If all those checks pass, we can be confident that we have a valid hex file. Of course, it doesn\u0026rsquo;t tell us anything about the quality of that code, that\u0026rsquo;s an other issue. But technically we should be fine.\nOnce the checks have passed, the user is once again requested to press the push button to confirm that this file should be programmed onto the chip. While it\u0026rsquo;s programming, it keeps displaying the current hex file entry it is processing to give the user an idea of the progress. It also keeps track of the number of flash pages it has written. One page corresponds to 1024 bytes on this architecture.\nOnce all the new code is flashed onto the chip, a message is displayed and the user is asked to once again press a key to re-boot the device into normal operating mode.\nThere are two different ways to enter bootloader mode. One is to press the push button at power-up. The other one consists in writing the value 0x94 (an arbitrarily chosen value) to the EEPROM address 0x100. In this case, the device will start up in bootloader mode no matter the state of the push button. The bootloader then overwrites this value (to 0x00) in order to start up normally next time.\nAfter the reboot, you should be greeted by the startup screen of the solar charger firmware as shown above.\nWhile I wrote this bootloader specifically for the solar charger, the code is rather universal. It can be ported to other PIC18 projects with relatively little effort. As always, the code\u0026rsquo;s on github: https://github.com/soldernerd/PIC18_USB_Bootloader.\n","date":"20 November 2018","externalUrl":null,"permalink":"/posts/usb-mass-storage-device-bootloader/","section":"posts","summary":"Let’s start with a video. It will tell you most of what I’m going to write about today.\n","title":"USB Mass Storage Device Bootloader","type":"posts"},{"content":"","date":"26 July 2018","externalUrl":null,"permalink":"/tags/mppt/","section":"tags","summary":"","title":"mppt","type":"tags"},{"content":"I\u0026rsquo;m delighted to tell you that my MPPT Solar Charger has been nominated for this year\u0026rsquo;s Hackaday Prize Finals taking place on October 22nd. I\u0026rsquo;ve submitted it in the Power Harvesting Challenge (link no longer available) category a while ago and was just informed that it was picked as one out of twenty projects submitted to the finals. Check out the original article here. Of course, any support is highly appreciated.\nIf you check out the project description on hackaday.io you will notice that my blog is somewhat lagging the latest developments. But don\u0026rsquo;t worry, I hope to post more updates as well as a few videos soon.\n","date":"26 July 2018","externalUrl":null,"permalink":"/posts/solar-charger-in-hackaday-prize-finals/","section":"posts","summary":"I’m delighted to tell you that my MPPT Solar Charger has been nominated for this year’s Hackaday Prize Finals taking place on October 22nd. I’ve submitted it in the Power Harvesting Challenge (link no longer available) category a while ago and was just informed that it was picked as one out of twenty projects submitted to the finals. Check out the original article here. Of course, any support is highly appreciated.\n","title":"Solar Charger in Hackaday Prize Finals","type":"posts"},{"content":"","date":"4 July 2018","externalUrl":null,"permalink":"/tags/i2c/","section":"tags","summary":"","title":"i2c","type":"tags"},{"content":"While the solar charger was originally intended to be used as a standalone device, it can just as well be integrated into other projects. In such applications, the user interface can be left away without sacrificing functionality other than the display and rotary encoder.\nOne project doing just that is MeshPoint, a rugged wifi hotspot for disaster and outdoor areas. But in most cases, the main application needs to be able to communicate with the solar charger. It wants to know if power is harvested, how full the battery is and so on. It needs to be able to enable and disable the various power outputs and maybe to control the fan. Or maybe it wants to make use of the charger\u0026rsquo;s real time clock and calendar. Or store some configuration data on the charger\u0026rsquo;s EEPROM. Possibilities are endless.\nAnd when it comes to external communication interfaces, all the chargers up to revision D had little to offer other than the USB interface. Depending on your project, adding USB host functionality may be inconvenient or even totally out of the question. There was always the possibility to somehow tap the display\u0026rsquo;s I2C port but there was no extra header on the board for that.\nRevision E has finally changed that. The charger now comes with two extra headers, one for I2C and one for SPI. As of now, the PIC acts as a master on both of those buses but slave functionality can be (and is planned to be) added in software. Hardware-wise it is even possible to update the charger\u0026rsquo;s firmware through those interfaces. I must admit that this is not the number one priority to be implemented but its nice to know that the possibility is there.\nWith the implementation of the USB bootloader next on the agenda I also upgraded the microcontroller to the newly introduced PIC18F47J53. It is extremely similar to the previously used PIC1846J50 and entirely pin compatible so it didn\u0026rsquo;t require any changes to the board. But it has twice as much flash memory (now 128kB) which allows for a feature-rich USB bootloader without runing into any issues memory-wise.\nAnother nice thing about it is that it has many more PWM modules which means that all four power outputs can now be PWM controlled. Think of LED lighting which is probably one of the main uses of those outputs. As a bonus, it also comes with an 12bit ADC which means four times the resolution on the temperature sensors.\nWhen modifying the software to fit the new board and microcontroller, I noticed that my pin choice for the external SPI slave select signal was somewhat unlucky. I happend to pick one of the few pins without PPS (peripheral pin select) functionality which can be a problem if you try to use that interface with the charger configured as slave. The fix was easy, just swapped two pins but required a slightly modified board. That\u0026rsquo;s why the current version is now revision F.\nClick here for the previous post in this series.\n","date":"4 July 2018","externalUrl":null,"permalink":"/posts/mppt-solar-charger-revision-f/","section":"posts","summary":"While the solar charger was originally intended to be used as a standalone device, it can just as well be integrated into other projects. In such applications, the user interface can be left away without sacrificing functionality other than the display and rotary encoder.\n","title":"MPPT Solar Charger - Revision F","type":"posts"},{"content":"","date":"4 July 2018","externalUrl":null,"permalink":"/tags/spi/","section":"tags","summary":"","title":"spi","type":"tags"},{"content":"","date":"27 September 2017","externalUrl":null,"permalink":"/tags/arduino/","section":"tags","summary":"","title":"arduino","type":"tags"},{"content":"","date":"27 September 2017","externalUrl":null,"permalink":"/tags/arduino-shield/","section":"tags","summary":"","title":"arduino-shield","type":"tags"},{"content":" A reader of this blog was so kind to send me a number of surplus boards of two of my solar charger designs. Thank you, Joachim.\nSolar Charger Hall of Fame\n\\[November 10, 2017\\]After just a few days, all of the boards were sent out to all over the world. Today, the first photo of an assembled board has arrived. I\u0026rsquo;ll post this and all following photos here:\nBy Orkhan from Germany Arduino Solar Charger\nThe first variety is my Arduino solar charger shield. Being my first attempt it is maybe not the most advanced design but it\u0026rsquo;s by far the simplest. So it\u0026rsquo;s well suited if you want to get your hands dirty while keeping the level of complexity reasonably low and do all your programming via the Arduino IDE. And despite its simplicity it operates very efficiently - apart from the power-hungry Arduino.\nSolar Charger Rev C\nThis is a relatively recent and far more advanced design. It is very low power, highly efficient, comes with USB and lots of bells and whistles. So if your ambitions are somewhat higher this board is for you.\nThe Rules\nNow here are the rules. As the title of this post suggests, I give these away for free. I ship them world wide absolutely free of charge. All I ask for in return is a photo of the assembled board within 6 weeks after you get the board. A maximum of 2 boards per person (one of each design). First come first served. Just send an email to \\[admin at soldernerd dot com\\].\n","date":"27 September 2017","externalUrl":null,"permalink":"/posts/free-solar-charger-pcbs/","section":"posts","summary":" A reader of this blog was so kind to send me a number of surplus boards of two of my solar charger designs. Thank you, Joachim.\n","title":"Free Solar Charger PCBs","type":"posts"},{"content":"","date":"27 September 2017","externalUrl":null,"permalink":"/tags/free-pcb/","section":"tags","summary":"","title":"free-pcb","type":"tags"},{"content":"","date":"18 September 2017","externalUrl":null,"permalink":"/tags/diy/","section":"tags","summary":"","title":"diy","type":"tags"},{"content":"","date":"18 September 2017","externalUrl":null,"permalink":"/tags/laser-cut/","section":"tags","summary":"","title":"laser-cut","type":"tags"},{"content":"","date":"18 September 2017","externalUrl":null,"permalink":"/tags/pic16/","section":"tags","summary":"","title":"pic16","type":"tags"},{"content":" It\u0026rsquo;s been almost two years since I did (or at least started) this project but I never sat down to document it. That\u0026rsquo;s what I want to do today. As the title says it\u0026rsquo;s about a little robot based on a RaspberryPi. Like many of its kind it is driven by a pair of stepper motors each driving a wheel directly attached to the respective motor axis. At the back there is another smaller, pivotable wheel to keep the robot in balance.\nhttps://www.youtube.com/watch?v=3j1LsXb6C0Q\nHere\u0026rsquo;s a video of the finished robot in action, running a simple demo program demonstrating the various functions. By the way, I\u0026rsquo;ve started a youtube cannel to share these kind of videos. I\u0026rsquo;m not really a video guy so this text and photos blog will stay my main medium but some projects like this robot, videos are a welcome addition.\nYes, I\u0026rsquo;m well aware that many similar designs already exist out there I could just go out and buy a kit like this. But making my own sounded more interesting so when I was looking for a Christmas present for my godson of sorts I did just that.\nAbove is a close-up of the main PCB that I\u0026rsquo;ve designed and built for this project. The idea is simple: There is a PIC16F1936 microcontroller that communicates with a RaspberryPi over I2C. The PIC then handles all the low-level details of controlling a pair of Allegro A4982 stepper drivers. These work at up to 35 volts, handle up to 2 amps of current and can hence drive much more powerful motors than the relatively small NEMA 17 size motors I\u0026rsquo;ve used here. They are easy to use and feature microstepping up to 16th steps.\nBesides the two stepper drivers there is a ULN2803 providing 4 power outputs capable of driving up to 1 amp each. The ULN2803 includes free-wheeling diodes so these outputs could be used to directly drive somethingn like a relay or a DC motor. But at least for now these outputs drive some RGB LEDs at the front as well as a buzzer.\nThe original idea was to power the RaspberryPi from the 5V linear regulator on the board and then draw the power for the PIC from the RaspberryPi\u0026rsquo;s 3.3 volt rail. Since the PIC uses only a few milliamps that\u0026rsquo;s entirely possible.\nUnfortunately I haven\u0026rsquo;t given that setup a lot of thought before building the board. Of course, when powered from something like 12V, the LM2931 regulator gets way too hot when powering a RaspberryPi that pulls a few hundred milliamps. So I\u0026rsquo;ve sacrificed one of my solar charger RevC boards that includes two very powerful USB charging outputs.\nDuring testing and debuggin I\u0026rsquo;ve used a small 12V AC/DC converter screwed to the bottom side of the robot. Once more or less completed I\u0026rsquo;ve changed the power supply to an old 3-call (11.1V) LiPo battery from a RC helicopter. It\u0026rsquo;s no longer fit for flying but still adequate to power this thing for a few hours.\nThe entire structure is laser-cut from 5mm medium-density fiberboard and held together with M2.5 torx screws with square nuts. M2.5 square nuts measure precisely 5x5mm so that goes together rally nicely. I\u0026rsquo;ve added and changed a few things as I went along, drilling extra holes to mount the blue PCB for the power supply, the LEDs, to hold the battery in place and some other things. But the structure as such works very nicely. It\u0026rsquo;s relatively simple if you have some place to do laser cutting (try your local fab lab\u0026hellip;) and is inexpensive and sturdy.\nThe weels are laser-cut from the same material and are sized to measure precisely 200mm in circumference. That\u0026rsquo;s handy since the steppers feature 200 steps per rotation.\nThat\u0026rsquo;s about it, most of the relevant files are on github. The OpenSCAD files for the laser cutting are not so just let me know if you\u0026rsquo;re interested in them. I\u0026rsquo;m happy to share them, too. Here are the links for the software and hardware, respectively.\nhttps://github.com/soldernerd/Robot_Software https://github.com/soldernerd/Robot_Hardware As always, I welcome any thoughts or comments.\n","date":"18 September 2017","externalUrl":null,"permalink":"/posts/raspberrypi-robot/","section":"posts","summary":" It’s been almost two years since I did (or at least started) this project but I never sat down to document it. That’s what I want to do today. As the title says it’s about a little robot based on a RaspberryPi. Like many of its kind it is driven by a pair of stepper motors each driving a wheel directly attached to the respective motor axis. At the back there is another smaller, pivotable wheel to keep the robot in balance.\n","title":"RaspberryPi Robot","type":"posts"},{"content":" It\u0026rsquo;s been a while since I posted anything related to my MPPT Solar Charger project. That doesn\u0026rsquo;t mean that no progress has been made\u0026hellip;\nI\u0026rsquo;ve performed many hours of testing, pushing the charger to and even beyond its 75 watts rating. I was able to confirm the very high efficiency n the range of 96 to 98% over a wide range of loads from 1 to 75 watts. And I\u0026rsquo;m happy to report that during all those tests I haven\u0026rsquo;t damaged anything. I\u0026rsquo;m more than pleased how this little charger is performing.\nThe most obvious progress that I\u0026rsquo;ve made is the mechanical design that you can see on the various photos here. The case is a pretty standard 115x90x55mm cast aluminum box for which the boards were designed right from the start. So if you\u0026rsquo;ve ever wondered about the peculiar shape of the display unit\u0026rsquo;s PCB you now know why. If I had made it rectangular it won\u0026rsquo;t fit.\nI\u0026rsquo;ve milled the various holes and slots out of that cast case on a manual mill which was somewhat time consuming but a lot of fun. The slots at the back for the in and outputs have turned out particularly well I find. Hence the close-up ;-)\nI\u0026rsquo;ve also given away some boards over the months. A few of them went to an open-source project named MeshPoint where they are integrated into a WiFi hotspot designed for outdoor use in disaster areas, refugee camps and the like. The project is also on hackaday .io where it runs for this year\u0026rsquo;s hackaday prize.\nTogether with the bords that I\u0026rsquo;ve used myself for testing I\u0026rsquo;m slowly but surely running out of the protopac that I\u0026rsquo;d ordered from dirtypcbs.com. So I decided to make a few minor changes to the board resulting in Revision D. The changes are really slight and require no or only slight changes in the firmware.\nBy far the biggest change concerns the flash chip. As I\u0026rsquo;ve mentioned before, the last one was simply a bad design choice because it can\u0026rsquo;t do sector ereases. The Atmel AT45DB161E can do that and provides 16Mbit (i.e. 2 MB) of storage which is plenty for our application. This change of course does require firmware changes but since hardly any code for the flash chip has been written so far that\u0026rsquo;s not really an issue.\nI\u0026rsquo;ve also included the surge suppression diodes that I removed when going from Rev B to Rev C. They are not really required but make the charger far more rugged against any spikes in the (particularly input) voltage. That also makes testing quite a bit safer so I thought at least having the option of including them is well worth while.\nThe signals from the three temperature sensors now get RC filtered to hopefully solve some issues I\u0026rsquo;ve experienced with overly noisy measurements. Placing the capacitors close to the microcontroller was a major challenge but I think I did the best I could.\nThe other changes are really tiny. I\u0026rsquo;ve fixed a mistake on the silk screen, changed a number of footprints to make the parts easier to solder and added a diode from the USB bus to the output. That allows to power the charger via USB. That\u0026rsquo;s obviously only useful for testing and debugging but there it\u0026rsquo;s a nice feature.\nIf you want to check out the details, they are on github: https://github.com/soldernerd/SolarChargerHardware. Or click here for the next post in this series.\n","date":"11 September 2017","externalUrl":null,"permalink":"/posts/mppt-solar-charger-update/","section":"posts","summary":" It’s been a while since I posted anything related to my MPPT Solar Charger project. That doesn’t mean that no progress has been made…\n","title":"MPPT Solar Charger - Update","type":"posts"},{"content":"","date":"11 May 2017","externalUrl":null,"permalink":"/tags/analog/","section":"tags","summary":"","title":"analog","type":"tags"},{"content":"","date":"11 May 2017","externalUrl":null,"permalink":"/categories/ham-radio/","section":"categories","summary":"","title":"ham-radio","type":"categories"},{"content":"","date":"11 May 2017","externalUrl":null,"permalink":"/tags/ham-radio/","section":"tags","summary":"","title":"ham-radio","type":"tags"},{"content":"","date":"11 May 2017","externalUrl":null,"permalink":"/tags/pic16f18325/","section":"tags","summary":"","title":"pic16f18325","type":"tags"},{"content":"","date":"11 May 2017","externalUrl":null,"permalink":"/tags/relay-sequencer/","section":"tags","summary":"","title":"relay-sequencer","type":"tags"},{"content":" Much like the beacon keyer presented here earlier, this RX/TX sequencer is a simple but useful little device. Its typical use is in ham radio applications when a separate power amplifier (PA) and/or a sensitive low-noise pre-amplifier (LNA) is used. Care has then to be take to safely transition between RX and TX states - and that\u0026rsquo;s where this sequencer comes in.\nWhy a sequencer?\nThere are many sequencer designs on the web, both analog (http://www.ifwtech.co.uk/g3sek/dx-book/sequencer/) and digital (http://www.mancuso.net.au/sequencer.html) There\u0026rsquo;s also a beautifully made but somewhat more involved design here: http://www.w6pql.com/relay_sequencer.htm. The links above (and many more) explain the purpose of (and need for) such a sequencer in quite some detail so I won\u0026rsquo;t repeat it all here.\nsoldernerd.com on YouTube\nMaybe the best way to understand what this sequencer does is to see it in action. I\u0026rsquo;ve just yesterday started a YouTube channel to share that kind of videos. Here\u0026rsquo;s the link: https://www.youtube.com/watch?v=Ctxm0VxeM4g.\nThis is already Rev D\nI have designed and built a number of sequencers over the years so this is already revision D. Unfortunately, I don\u0026rsquo;t seem to have photos of the first two versions.\nAbove is a photo of the previous (Rev C) version. Its design was very similar but quite a bit larger as the side-by-side comparison shows.\nInput and Output\nThe sequencer presented here is of the digital variety, uses a 12V power supply and is fully reverse-polarity protected. It is controlled via a PPT input which is pulled high (to +5V) with a 10k resistor and active when pulled to ground.\nThat PPT input is both debounced as well as reasonably well protected. You can short it to the 12V supply without any adverse effects. Actually, anything in the plus/minus 50 volts range is fine.\nIts outputs consist of 3 relay outputs. I\u0026rsquo;ve used DR-12V types. Those are single-pole, double throw (SPDT) reed relays. They are not inexpensive but both reliable and fast as well as nearly bounce-free. Each relay has an LED next to it indicating its state and all three relevant relay contacts are accessible via the orange 200mil header.\nPIC Microcontroller\nThe actual behaviour of the relays is controlled by a PIC16F18325 whose programming pins are accessible via the 5-pin, 100mil ICSP header. Its pinout matches that of the popular PICKit3 programmer distributed by Microchip.\nSpeed control\nHow much delay should there be between switching the individual relays? The answer obviously depends on your lineup and that\u0026rsquo;s why you can control the speed via the on-board pot. The way I have it programmed the delay can be varied from 70 to 325 milliseconds.\nUndervoltage lockoutThere were still some pins left on the microcontroller and the PIC comes with a 10bit ADC and voltage reference module. So I decided enable the PIC to measure the input voltage of nominally 12 volts. As it is now programmed, the sequencer will only start operation after the input voltage has consistently been above 11.1 volts for 1.6 seconds.\nGithub\nAs usual, all the files are on github:\nHardware: https://github.com/soldernerd/SequencerHardware Software: https://github.com/soldernerd/Sequencer_Software ","date":"11 May 2017","externalUrl":null,"permalink":"/posts/rxtx-sequencer/","section":"posts","summary":" Much like the beacon keyer presented here earlier, this RX/TX sequencer is a simple but useful little device. Its typical use is in ham radio applications when a separate power amplifier (PA) and/or a sensitive low-noise pre-amplifier (LNA) is used. Care has then to be take to safely transition between RX and TX states - and that’s where this sequencer comes in.\n","title":"RX/TX Sequencer","type":"posts"},{"content":"","date":"30 April 2017","externalUrl":null,"permalink":"/tags/debouncing/","section":"tags","summary":"","title":"debouncing","type":"tags"},{"content":"","date":"30 April 2017","externalUrl":null,"permalink":"/tags/dimmer/","section":"tags","summary":"","title":"dimmer","type":"tags"},{"content":"","date":"30 April 2017","externalUrl":null,"permalink":"/tags/led/","section":"tags","summary":"","title":"led","type":"tags"},{"content":"","date":"30 April 2017","externalUrl":null,"permalink":"/tags/pic/","section":"tags","summary":"","title":"pic","type":"tags"},{"content":" Around one and a half years ago I\u0026rsquo;ve designed and built various LED dimmers for both white and RGB LEDs. Then late last year someone approached me asking if I could make an RGB dimmer for him, too. But my designs were really tailored to their specific applications and built with home-made, i.e. milled PCBs which are time-consuming to make. So I decided to make a more universal version based on a proper, etched board which could be built in a small series and used for all kind of applications, both white and RGB. The result is this versatile, programmable 4-channel dimmer.\nThe design is based on my previous RGB dimmer but with a number of improvements.\nsoldernerd.com is now on YouTube\nI\u0026rsquo;ve just uploaded a short video showing this device in action. Here\u0026rsquo;s the link: https://www.youtube.com/watch?v=ehZybd3Y2kc. This is only my second video so don\u0026rsquo;t expect miracles but I\u0026rsquo;d be interested to hear if you would like to see more videos in the future or if you prefer the traditional text and photos format.\nWide voltage range\nIt now operates from any voltage in the range of 6 to 26 volts as opposed to 12V only. In order to accomodate such a wide range of inupt voltages the regulated logic level voltage of 5V rather than the inupt voltage is now used to drive the mosfets.\nExtremely low standby current\nThis 5V rail is generated by an LM2936 linear regulator with a very low quiscent current and shutdown input. That allows for a nice power saving feature for when all the outputs are off. After a few seconds of sitting idle the entire device powers itself off, i.e. it turns off the LM2936 thus only consuming 30 microamps (typ.) plus some leakage in the capacitors. So the device can stay connected to a battery for months without draining it. To wake it up one has to press any of the two push buttons.\nRotary encoder design options\nTalking of push buttons. Like my previous RGB dimmer it features two rotary encoders with push buttons.\nBut now there are two different types of encoders that can be used. The ones previously used with their axis perpendicular to the board and a different type where the rotary axis is parallel to the board. And either type can be mounted on either side which gives you even more freedom for your physical design.\nPerfectly debounced switch signals\nAs always with my designs, the signals from the encoders (six in total) are nicely debounced in hardware by running the RC-filtered signal through a 74HC14 schmitt-triggered hex inverter. So the singals are perfectly clean when they reach the microcontroller.\nNoise immunity\nWith my last design I had experienced some difficulties with ground bounce or insufficient ground connections in general leading to less-than-reliable encoder readings. It\u0026rsquo;s always more difficult go ensure good, low impedance ground connections on those prototype boards since there are no plated-through holes and vias. On that prototype board the issue was solved by soldering in a few short pieces of wire where the ground connection needed improvement.\nSo with this new design I paid very close attention to ground. I spent a lot of time working on the board layout to ensure that everything is as noise immune as possible. I always use ground vias generously but here I really tried everything to get the best, shortest and lowest impedence ground connections could get. I\u0026rsquo;ve also used decoupling capacitors even more lavishly than I usually do.\nNew microcontroller\nI\u0026rsquo;ve changed the microcontroller to a PIC16F18325 which is smaller and cheaper than the previously used PIC16F1936. The 18325 has become my standard choicer whenever I need a low pin-count microcontroller. I particularly like its remappable pins which give a lot of freedom to simplify your signal routing on the PCB.\nSmaller size and more outputs\nThe mosfet drivers are basically the same as before but now with non-inverting outputs: LM5111-1M. There are two of them for a total of 4 outputs compared to only 3 with the previous version. They now drive much (physically) smaller but no less capable mosfets which allowed me to significantly downsize the whole board to 75x65mm. The NXP BUK9Y12-40E are rated at 40 volts and offer an on-resistance of 12 milliohms (max @ 25 degrees ) with a 5V drive as we have here. Their large thermal pads a the bottom (NXP calls that package LFPAK) pass heat efficiently to the PCB which then serves as a heat sink. There is also a 30V version that offers even better performance but with a maximum input voltage of 26 volts I thought the 40V version is the safer choice.\nAs you can see, there\u0026rsquo;s plenty of capacity on the board. A total of 5 330uF 35V low ESR capacitors are placed in parallel in order to smooth out the PWMs inherent current ripple.\nSoftware\nSo now we have a device with 2 rotary encoders and 4 outputs but it won\u0026rsquo;t do anything without software. There\u0026rsquo;s absolutely nothing hard-wired between the encoders and the outputs so we can program this device to behave in any way we like. That\u0026rsquo;s what makes it so flexible.\nI have so far implemented two functions. The first is aimed at RGB LEDs and behaves exactly like my RGB dimmer. One encoder controls the brightness, pressing its button turns the outputs on and off. The other encoder controls the color, pressing its button toggles between white and color. The three outputs are 120 degrees out-of-phase which presents a more steady load to the power supply.\nThe second function is aimed at plain white LEDs. There are two pairs of outputs with output 1 \u0026amp; 2 forming a group and 3 \u0026amp; 4 the other. Each pair is controlled by one encoder. Turn it to control the brightness and press its button to turn the respective output pair on and off. The two outputs of any group are 180 degrees out-of-phase to smoothen the load. And since there is a 4th output it is easy to implement a case where there is an independent white channel.\nWith both functions, the entire device turns off after a pre-defined period of time (currently set at 3000ms) with all outputs off in order to save power. Before turning its own power supply off and hence losing all its data in RAM, the necessary parameters are saved to EEPROM. So the device remembers its last state and will power up the with the same (brightness, color and so on) settings it powered off with.\nThe switching frequency is 31.25kHz which is high enough to be entirely inaudible and the 10bit resolution gives you 1023 levels to finely control the brightness down to very low levels.\nAll the settings reside in a file named config.h. That is where you define the function you want the device to perform. The number of brightness levels and their respective values can simply be parameterized there. The same is true for the colors. You can also set the RGB values for neutral white. The seemingly obvious choice of 1023/1023/1023 often does not result in a pleasent white. For my LEDs I had to substantially reduce the green content but this, of course, depends on your particular choice of LEDs.\nI currently have 3 devices productively deployed and they perform very nicely. Also, adding new functions is easy since all the heavy lifting like has already been done. It takes somethign like 100 lines of relatively simple code to implement a new function. No need to get involved with any registers and the like. So if you have any experience in C you should be totally fine programming this thing.\nVisit github for code and Eagle files\nBoth the eagle files (including Gerbers) and code are on github:\nhttps://github.com/soldernerd/DimmerHardware https://github.com/soldernerd/ProgrammableDimmer_Software Also want one?\nI have some boards left and can make one for you, too. Fully built, tested and programmed to your needs. Cost is USD 65 payable via PayPal, including worldwide shipping. Simply contact me using this form.\n","date":"30 April 2017","externalUrl":null,"permalink":"/posts/programmable-led-dimmer/","section":"posts","summary":" Around one and a half years ago I’ve designed and built various LED dimmers for both white and RGB LEDs. Then late last year someone approached me asking if I could make an RGB dimmer for him, too. But my designs were really tailored to their specific applications and built with home-made, i.e. milled PCBs which are time-consuming to make. So I decided to make a more universal version based on a proper, etched board which could be built in a small series and used for all kind of applications, both white and RGB. The result is this versatile, programmable 4-channel dimmer.\n","title":"Programmable LED Dimmer","type":"posts"},{"content":"","date":"30 April 2017","externalUrl":null,"permalink":"/tags/pwm/","section":"tags","summary":"","title":"pwm","type":"tags"},{"content":"","date":"23 April 2017","externalUrl":null,"permalink":"/tags/beacon/","section":"tags","summary":"","title":"beacon","type":"tags"},{"content":" This is likely the first ham radio related project that I document here on this blog. But my very first PIC project was a beacon keyer that I made for my father, HB9BBD. That was was in 2013. A beacon keyer is a great project to get started with microcontrollers since it\u0026rsquo;s not much more than a fancy way of blinking an LED.\nAt that time I didn\u0026rsquo;t even use Eagle yet and so the layouts were based on a software called Sprint Layout. These were all very simple circuits, all based on a PIC16F688, and therefore perfectly suited for making some of my first homemade PCBs as well. The very early versions like the one in the picture above even used the DIP version of the PIC in a socket. All the resistors and capacitors are 1206 size not 0805 like of my later designs.\nIn fall last year, HB9MPU asked me if I could make some keyers for his new 10GHz beacon. That was a great oportunity to design a new one from scratch and this is what this post is about.\nRequirements\nThese were the requirements: - 12V operation - Open drain outputs, i.e. a transistor to ground - 2 outputs, one of them inverted\nMicrocontroller\nI decided to use a PIC16F18325 this time. Like the 688 it is a 14-pin PIC but a much more recent addition to the PIC16 family. It\u0026rsquo;s fully featured with I2C, remappable pins, an onboard voltage reference, plenty of timers and a whole bunch of other features. And it\u0026rsquo;s widely available a very low price. So I tend to use this PIC whenever I need a low pin count micro somewhere. Like for my fan controller.\nOutputs\nInstead of using discrete transistors and protection diodes I\u0026rsquo;ve used a Texas TPL7407. That\u0026rsquo;s a 7-channel low-side driver, basically 7 mosfets to ground together with an on-board voltage regulator for the gate voltage and protection diodes all in a SOIC16 package. It sinks up to 600mA (with a maximum of 2A total) per channel and operates from 8.5 to 40 volts. Perfect to drive relays, small motors, powerful diodes or just about anything else that doesn\u0026rsquo;t require that much current. Some of you may be familiar with the ULN2003 which does the same thing but using bipolar transistors (as darlington pairs) instead of mosfets.\nPower supply\nThe power supply is based on a Texas LM2931, basically a rugged LM7805 that operates all the way up to 26 volts and survives up to plus/minus 50V. While the LM2931 is reverse polarity protected, the diodes in the TPL7407 will short any negative input voltage to ground which is obviously a bad idea. I\u0026rsquo;ve added a 60V, 2A schottky diode at the input so the device is truely reverse protected. Minimum operating voltage of the TPL7407 (after a diode drop) and maximum operating voltage of the LM2931 result in an input voltage range of the final device of 9 to 26 volts.\nSpeed control\nThere\u0026rsquo;s a small pot on the board that lets you control the speed of the keyer. The PIC measures the wiper voltage with its built-in 10-bit ADC and sets its speed accordingly.\nFan output\nAs mentioned, the TPL7407 has 7 channels but I only really needed two for the beacon keyer outputs, one normal and the other one inverted. The PIC also has an on-board voltage reference module and a temperature sensor so I decided to use all that functionality to add a fan controller. Beacons often have fans that run constantly even when there\u0026rsquo;s absolutely no need for cooling such as in winter which only wears out the fan\u0026rsquo;s bearings.\nSo the pic also measures the temperature and turns the fan output on and off according to software-defined threshold temperatures. Since the PIC\u0026rsquo;s temperature module is rather inacurate I\u0026rsquo;ve added an inexpensive but much more accurate LMT86 analog temperature sensor.\nI\u0026rsquo;ve used 4 TPL7407 channels for the fan output so the current is limited by the total allowable current of 2 amps. Of course, you can also use this output to control a relay and use, for example, a 230V fan.\nThere are also 3 LEDs on the board so you can immediately see what\u0026rsquo;s going on. And just in case you care, the board measures 45x45mm.\nAs always, programming is done with a PicKit3 or similar via a 100mil in-circuit programming header.\nThat\u0026rsquo;s pretty much all that is to say about this little device. As always, I appreciate any feedback and let me know if you need one of these.\nAnd as always, everything from Eagle files to firmware is on Github:\nhttps://github.com/soldernerd/BeaconKeyerHardware https://github.com/soldernerd/BeaconKeyerSoftware ","date":"23 April 2017","externalUrl":null,"permalink":"/posts/beacon-keyer/","section":"posts","summary":" This is likely the first ham radio related project that I document here on this blog. But my very first PIC project was a beacon keyer that I made for my father, HB9BBD. That was was in 2013. A beacon keyer is a great project to get started with microcontrollers since it’s not much more than a fancy way of blinking an LED.\n","title":"Beacon Keyer","type":"posts"},{"content":"","date":"23 April 2017","externalUrl":null,"permalink":"/tags/beacon-keyer/","section":"tags","summary":"","title":"beacon-keyer","type":"tags"},{"content":"","date":"23 April 2017","externalUrl":null,"permalink":"/tags/fan-controller/","section":"tags","summary":"","title":"fan-controller","type":"tags"},{"content":"","date":"23 April 2017","externalUrl":null,"permalink":"/tags/hb9tko/","section":"tags","summary":"","title":"hb9tko","type":"tags"},{"content":"","date":"2 April 2017","externalUrl":null,"permalink":"/tags/buck/","section":"tags","summary":"","title":"buck","type":"tags"},{"content":"","date":"2 April 2017","externalUrl":null,"permalink":"/tags/hid/","section":"tags","summary":"","title":"hid","type":"tags"},{"content":" Over the last few weeks I have been quite busy with my MPPT Solar Charger project. I\u0026rsquo;ve built up a first board and started writing firmware for it. Since the last version was not too different in terms of hardware I was able to re-use most of that code. But I hadn\u0026rsquo;t even touched on the whole USB stuff back then so there was still a lot of work to do. While the project is still far from being complete I am happy to say that I\u0026rsquo;ve made quite some progress. Most importantly, the new design seems to work well and so far I haven\u0026rsquo;t found any mistakes in the board layout. But let\u0026rsquo;s go through this step by step.\nUSB\nI regularly find USB communication to be the most complex and obscure part of the firmware. That\u0026rsquo;s why I like to get that working first and then add all the other functionality later. I\u0026rsquo;ve started with some sample code that Microchip provides for their PIC1846J50 family of chips. That way I was able to get the my board act as a composite HID (Human Interface Device) / MSD (Mass Storage Device) quite quickly. Of course, that demo application doesn\u0026rsquo;t do anything particularly useful but it provides a solid basis for adding the functionality you need.\nAt least for the HID I\u0026rsquo;ve implemented most of that functionality. I can read all the relevant data such as settings, currents, temperatures, voltages and so on over USB. I can also control all the outputs as well as the actual solar charger remotely. More on that later.\nOn the MSD side there is still lots to be done. The solar charger successfully enumerates as a USB flash drive and you can read and write data from and to it. But that\u0026rsquo;s really it. The charger doesn\u0026rsquo;t care about the files you save there and also doesn\u0026rsquo;t put any data there.\nFlash and EEPROM\nThis brings us to the next topic: Non-volatile memory. There is both a I2C EEPROM as well as a SPI flash on the board. Communication with the EEPROM is fully implemented but currently its only used to save the time and date. The idea is to save all the settings and calibrations on the EEPROM. That shouldn\u0026rsquo;t be difficult but I haven\u0026rsquo;t had time for that yet.\nThe flash also works just as it is supposed to but the chip I chose turned out to be a bad design choice. It can\u0026rsquo;t do page erase, only entire 16k sectors can be ereased. That makes it difficult to use since you have to temporarily save the sector\u0026rsquo;s data somewhere when you want to change only part of a sector. We don\u0026rsquo;t have that much RAM so we have to save that data to flash itself. That can all be done but it\u0026rsquo;s just a hassle. Apart from that a sector erease takes time. A loooot of time. So I\u0026rsquo;ll just juse a different chip when I do the next iteration of the board. For now I\u0026rsquo;ll just use the first 512bytes of each sector. That\u0026rsquo;s extremely wasteful but will do for now I guess.\nSolar Charger\nThe actual charger circuit hasn\u0026rsquo;t changed much since the last version so I expected little trouble in getting it to work. However, I managed to confuse the low and high gate pins in firmware and only found that bug days later when I had already done plenty of damage to the board. By the time I found and fixed the problem I had already killed the input current sensor, the ADC, as well as some of the PIC\u0026rsquo;s output drivers.\nSo I built up a second board but only with the components required to test the buck. And much to my relief it works. And it works well. I haven\u0026rsquo;t done any precise measurements yet but it seems at least as efficient as the last version. I had it running at its rated power of 75 without it getting overly hot. As expected, most power dissipation takes place in the coil so the coil did get quite warm but not hot. The FETs heat up a bit due to their proximity to the coil but otherwise don\u0026rsquo;t care much. My main problem with these tests was to somehow sink the power at the output without overcharging the battery. My home-made dummy load can sink up to 4.5 amps but not for very long before it regulates down to avoid overheating. I had the charger running at around 40 watts for several hours and it only got modestly warm.\nAlso, the wave forms on the scope look nice and clean. There\u0026rsquo;s considerably less ringing and overshoot than with the last version. So the improved layout seems to work well. During the tests so far I have turned the charger on and off at least a hundred times, switched from asynchronous to synchronous mode and vice versa and had it running for about 10 hours. I also pushed it all the way up to about 85 watts where the coil starts saturating and the caps have to handle more ripple than they are rated for. I\u0026rsquo;m happy to report that during all these tests I haven\u0026rsquo;t killed a single fet nor any other component (once the firmware was ok). I am confident that it will stay this way.\nSynchronous bucks are somewhat dangerous in the sense that it is easy to short the input or output to ground when you\u0026rsquo;re not careful. My solution to this is having rigorously tested functions for turn-on, turn-off, switching mode and changing duty cycle and then rely only on these functions when implementing different MPPT strategies. If these few functions do what they should you can get away with quite a bit of abuse without damaging anything.\nWhat I also noticed during my tests is that the break-even between synchronous and asynchronous mode is somewhere in the region of 1 amp. That\u0026rsquo;s about twice what it was with the last version and is thanks to the extremely efficient diode that makes asynchronous mode much more efficient.\nUSB Charger and power outputs\nThis is something that has changed quite a bit since so I was eager to see how it performs. I haven\u0026rsquo;t done any detailed tests but I\u0026rsquo;m very pleased with it so far. It definitely performs better than the last version. In theory, you should be able to simultaneously pull 2 amps from each of the two USB charging ports. I haven\u0026rsquo;t done that yet but when fast-charging two cell phones (approximately 2 amps judging from the power it pulls from the battery) it stayed surprisingly cool – unlike the last version.\nAlso no surprise with the 4 power outputs. I had changed the mosfet drivers and mosfets in order to save board area. Apart from that everything works like before. I can still turn off the drivers when none of the outputs is in use in order to preserve power. All works as it should.\nSolar Charger App\nOf course, all the USB HID functionality is of little use without some software on the other side, i.e. running on a PC. I\u0026rsquo;ve spent a lot of time writing my Solar Charger App over the past few weeks and I can say it\u0026rsquo;s getting pretty good. I has already proved very useful in testing the buck. Since I can monitor and control everything via USB there is no need to have a user interface sitting on top of the board during testing. That means unrestricted access for scope and multimeter probes. And since there\u0026rsquo;s so much more space on a PC screen than on the little LCD I can display all parameters simultaneously.\nThe program is written in C#, using my recently published HID utility and WPF . I\u0026rsquo;ve tested it on Win7 and Win10 and runs absolutely stable. It also copes well with ultra high resolution displays where everything gets scaled-up in order to still be visible/readable. The screen shot above gives you some idea of its current functionality. Take the efficiency measurement with a grain of salt, though. The measurements are yet to be calibrated.\nThe code is available on github: github.com/soldernerd/SolarchargerApp. To compile it you need VisualStudio 2015 Community which is available free of charge.\nMeasurements\nMeasurements is another important topic. The newly chosen 16-bit ADC works well. Actually, I don\u0026rsquo;t feel much of a difference to the 18-bit version used previously. Anyway, the measurements are done with 14-bit precision only in order to speed them up.\nThe readings I get from the two current sensors are surprisingly accurate even without having done any calibration so far. So for now, all measurements have been done with their theoretical (i.e. calculated) multipliers and offsets.\nThe temperature measurements are done by the PIC directly, using a 2.5V external voltage reference. Both the temperature sensors (one on-board, up to two externally) as well as the voltage reference perform just like they should but I get a lot of noise in my otherwise reasonable measurements. This is quite certainly a software issue. I might not give the PIC\u0026rsquo;s internal ADC enough time to settle after switching channels or something like that. I\u0026rsquo;m sure it can and will be solved but I haven\u0026rsquo;t given this very high priority so far.\nNext steps\nA lot of work remains to be done. One of the next things I will do is to implement proper calibration for the voltage and current measurements. At the moment, all the relevant constants are hard-coded so I first need to change them being variables, store them in EEPROM and retrieve them from there at startup. In a second step I need to make them accessible over USB. Once that\u0026rsquo;s done it should be possible to calibrate them in a fully automated fashion. I\u0026rsquo;ve never done that so far but my multimeter as well as my power supplies can be controlled via USB (or GPIB, respectively). So I want to write a calibration routine that sweeps the device under test, calculates the proper calibration values and sends them to the solar charger.\nGetting the Mass Storage Device working from FLASH is another big thing to do. As reported, the currently 7kb of memory on the flash drive are mapped into the PIC\u0026rsquo;s internal flash memory. I\u0026rsquo;ll have to dive quite deep into the Microchip USB code in order to figure out how to change that. I expect to spend a significant amount of time until that works but there\u0026rsquo;s no way around it in the long run.\nOnce mass storage works properly I can also start implementing settings as a configuration file on the flash drive. So as an alternative to doing things via HID which requires dedicated software to run on the PC you can also check and change settings by editing a text file residing on the flash drive. The next step will then be to also write measured data to that storage.\nThen most of the low-power features are still to be implemented. The most basic stuff is there: The 5V buck for USB charging is turned off when not in use and so are the mosfet drivers for the power outputs and the solar charger. The user interface is also turned off after a certain time of inactivity. But the PIC constantly runs at 48MHz, the USB module is never turned off even when not in use, it never goes into any of the several low-power modes and so on. So at the moment it consumes around 10mA with the display off and 16mA with the display on.\nAnd yes, there\u0026rsquo;s also more testing to be done on a lot of aspects. The code could definitely use a clean-up once I\u0026rsquo;m done with it, I also have plans of adding a boot-loader so users can update the firmware via USB\u0026hellip; I won\u0026rsquo;t run out of work any time soon.\nThe firmware is on github, too: github.com/soldernerd/SolarChargerRevC_Software. It is updated much more frequently than I do posts here so if you\u0026rsquo;re interested I suggest you track the most recent development there.\nThe next post on this topic is here.\n","date":"2 April 2017","externalUrl":null,"permalink":"/posts/mppt-solar-charger-rev-c-first-test-results/","section":"posts","summary":" Over the last few weeks I have been quite busy with my MPPT Solar Charger project. I’ve built up a first board and started writing firmware for it. Since the last version was not too different in terms of hardware I was able to re-use most of that code. But I hadn’t even touched on the whole USB stuff back then so there was still a lot of work to do. While the project is still far from being complete I am happy to say that I’ve made quite some progress. Most importantly, the new design seems to work well and so far I haven’t found any mistakes in the board layout. But let’s go through this step by step.\n","title":"MPPT Solar Charger Rev C - First Test Results","type":"posts"},{"content":"","date":"2 April 2017","externalUrl":null,"permalink":"/tags/pic18f46j50/","section":"tags","summary":"","title":"pic18f46j50","type":"tags"},{"content":"","date":"2 April 2017","externalUrl":null,"permalink":"/tags/solar/","section":"tags","summary":"","title":"solar","type":"tags"},{"content":"","date":"2 April 2017","externalUrl":null,"permalink":"/tags/usb/","section":"tags","summary":"","title":"usb","type":"tags"},{"content":"","date":"22 February 2017","externalUrl":null,"permalink":"/tags/dirtypcbs/","section":"tags","summary":"","title":"dirtypcbs","type":"tags"},{"content":" Over the last year or so I\u0026rsquo;ve designed, built and tested a standalone solar charger. It performed quite well but as with any complex design there were a number of things that needed to be improved. So I eventually reached the point where I decided to design a revised version. And this is what this post is all about.\nThings to improve\nHere\u0026rsquo;s a list of things that I wanted to improve besides fixing the design errors of the old design:\nDownsize the board and give some thought to how to put the whole thing into a case. Consider carefully where to put screw holes, connectors and the like. Reduce complexity wherever possible. Reduce the number of distinct components. Reduce total component cost without sacrificing performance. Reduce height of the assembled board so that it can ship in a padded envelope. Turn user interface on by means of a logic signal as opposed to turning its power supply on and off. Ability to control the display entirely via I2C, including backlight brightness and reset. Let\u0026rsquo;s look at these points one by one.\nDownsize the board\nI looked around for a suitable case for my solar charger and finally decided on a 90x115mm cast aluminium case. The specific model chosen is available from Farnell at around 10 bucks which I found very reasonable. With the case chosen the size of the board was pretty much given. The inside shape of the case is rather special since there are also mounting holes for the case itself that take away space for the board. However, I decided to keep the board rectangular so it stays universal and is not just made to fit that particular case. That left me with a board of 85x78mm as opposed to 90x140mm of the last version. That\u0026rsquo;s about half the size in terms of board area so fitting everything on the new board was really a challenge.\nThe main space saving came from using much smaller mosfets. The model previously used was rather huge in physical size. I\u0026rsquo;m now using NXP PSMN6R0-30YL in a LFPAK package that is much smaller while delivering similar if not better performance.\nThe main inductor is also somewhat smaller. I found that the Coilcraft MSS1210 series delivers pretty much the same performance as the MSS1583 while saving some space.\nApart from that I didn\u0026rsquo;t downsize any of the components in order to keep everything hand-solderable and hobbyist-friendly. Particularly, all the resistors and ceramic capacitors are at least 0805 in size.\nGetting the board made from dirtypcbs.com also allowed me to do a denser layout, mainly by using smaller vias. But I didn\u0026rsquo;t push it to the limit, all traces are still at least 12 mils (0.3mm) wide with 0.4mm vias and 6 mils clearance.\nNow all the power connectors are located at the top of the board with a single 12-pin 200-mil connector. USB is still located at the front and the programming header is at the right edge of the board. External temperature sensors and fan output are now on the left side. The header for the user interface is now located so that the user interface can just be stacked on top of the charger and sits precisely in the middle. There are also mounting holes for the user interface on the charger board.\nReduce complexity\nThe obvious place to start was the combination of PIC18F26J50 microcontroller with a I2C multiplexer and a port extender. The same PIC family also includes a 44-pin version that allows replacing all 3 chips with a single chip. I\u0026rsquo;m now using the top-of-the-line PIC18F46J50. That not only simplifies the board but also the software since we no longer need to care about the mux and which pins are on the PIC and which are on the port extender.\nThe 4 mosfet drivers for the power outputs have been replaced by 2 MCP14A0153 dual mosfet drivers that also don\u0026rsquo;t require a reference voltage signal which further reduces complexity somewhat.\nThe 5V switching converter for USB charging on the last version needed quite a few external components to function. Besides that it got rather hot at 2 amps. I\u0026rsquo;ve replaced it with a Texas TPS54428 synchronous switcher that is more efficient, uses less external components, delivers up to 4 amps and has a thermal pad at the bottom which helps keeping it cool. The new Coilcraft MSS1048 coil is slightly higher but otherwise the same size and helps keeping power dissipation low.\nI\u0026rsquo;ve tried quite hard to keep the number of distinct capacitor and resistor values to a minimum. You can easily see that the same values such as 10k, 300k and 680k appear over and over again. The only point where there are still a lot of distinct resistor values are the USB charging ports where I\u0026rsquo;ve tried to emulate an Apple and Samsung charger, respectively. I\u0026rsquo;m not sure to what extent one can cut corners here without risking that certain devices don\u0026rsquo;t charge properly.\nOverall, the number of distinct components has been reduced from 60 to 47 despite some added features.\nReduce cost\nGetting rid of the I2C mux and the port extender already saves some cost. The same goes for the dual mosfet drivers and the downsized inductor. There were some unnecessarily expensive components on the last version. There was an 18-bit ADC that we didn\u0026rsquo;t really need. The Microchip MCP3428 is a very similar model that only has a maximum resolution of 16 bits and is quite a bit cheaper without making any difference to our application. Another component that was somewhat of an overkill was the voltage reference. Note that the voltage reference is only needed for the temperature measurements. The voltage and current measurements are done by the external ADC that comes with a precise on-board voltage reference. I found the Silicon Labs TS6001 which provides a sufficiently precise 2.5V reference. I\u0026rsquo;ve also replaced the large and relatively expensive EEPROM with a much smaller 16kbit Microchip 24AA16 EEPROM in combination with a cost-effective serial Flash (Spansion S25FL208K) with 8Mbit of capacity. This way we get much more storage at a similar total cost while still keeping some easy-to-use EEPROM for configurations and the like.\nReducing height\nSince the only overly high components on the last version were the input and output capacitors this was an easy task. I decided that I want to use the same model for both input and output which meant that I needed a 25 volt rating. Maintaining the 10mm diameter and limiting the height to 12.5mm left me with a maximum available capacity of 470uF. The ripple current rating of the new caps is also lower so I now have to use 2 caps in parallel at the input to not exceed this rating at 75 watts. The caps are still the highest components on the board but only slightly higher than the USB connector, the main inductor and the 200-mil connector. The resulting total height of about 15mm is low enough to comfortably ship the assembled board in a padded envelope which is much cheaper than a small parcel.\nUser interface\nI\u0026rsquo;ve already presented a user interface that fulfills most requirements listed. However, I still needed to again revise the user interface for two reasons. First, the previous version would not physically fit inside the cast aluminium case. So I had to somewhat taper off the board towards the side so it would fit. I also had to re-locate the mounting holes inward so that they lay on the charger board. Secondly, I need to be able to shut down the user interface without blocking the I2C interface. This was not an issue with the last version where I had a I2C mux in between. So the new interface now includes a 2-channel bi-directional switch that is controlled via the same signal that turns the interface on and off.\nNext steps\nI\u0026rsquo;m looking forward to my ReflowR hopefullly arriving soon so I can build up the board in an efficient way. As you can see below I have already prepared a setup to apply the solder paste to the board. I have glued three faulty user interface boards to a piece of coated plywood to repeatedly align the board. I have limited experience with reflow soldering but I will hopefully learn quickly and report my progress and lessons learned here.\nAs you can see from all the photos here the boards have already arrived and I\u0026rsquo;m excited to try them out. All the eagle files as well as the Gerbers and everything are on github: github.com/soldernerd/SolarChargerHardware.\n","date":"22 February 2017","externalUrl":null,"permalink":"/posts/mppt-solar-charger-rev-c-design/","section":"posts","summary":" Over the last year or so I’ve designed, built and tested a standalone solar charger. It performed quite well but as with any complex design there were a number of things that needed to be improved. So I eventually reached the point where I decided to design a revised version. And this is what this post is all about.\n","title":"MPPT Solar Charger Rev C Design","type":"posts"},{"content":"","date":"22 February 2017","externalUrl":null,"permalink":"/tags/reflow-soldering/","section":"tags","summary":"","title":"reflow-soldering","type":"tags"},{"content":"","date":"13 February 2017","externalUrl":null,"permalink":"/tags/c/","section":"tags","summary":"","title":"c","type":"tags"},{"content":"Have you ever tried to write a program that connects to some device via USB? I have done so a few years ago and was shocked how much of a pain that is (at least on a Windows plattform). I always thought there should be a nice little library that wraps all those uggly DLL imports, marshalling and COM API calls and offers a nice and clean C# interface to the outside world.\nMuch to my surprise I found nothing that really did what I was looking for. Now I finally sat down and wrote my own. It\u0026rsquo;s on github.com under GNU GPLv3 license for anyone to modify and use.\nMy starting point was the Microchip PIC18F46J50 FS USB Demo Board. This nice little board comes pre-programmed as a HID (Human Interface Device) / MSD (Mass Storage Device) USB composite device and is a great starting point for anyone interested in building a USB device based on a PIC.\nOnce uppon a time, Microchip also wrote a WindowsForms application to showcase the USB functionality of their microcontrollers and that application (in various versions) can still be found here. It lets you read an analog voltage from the board, tells you if a pushbutton is pressed or not and lets you toggle an LED. Very simple but all you need to get started with your own device and application.\nUnfortunately, that code no longer gets maintained and is quite outdated by now. It was created with VisualStudio2010 and .NET 2.0. And all USB and WindowsForms code is mixed up in a single file which makes it difficult to re-use. It also lacks some functionality such as the ability to list available devices. Apart from that it works very well and stable so I used it as a starting point.\nMy solution is now based on VisualStudio Community 2015 (which is available for free) and .NET framework 4.6. So you can just download VisualStudio and open the HidUtilityDemo.sln file.\nThere are 3 projects inside the solution:\nA WindowsForms application named HidDemoWindowsForms A WPF application named HidDemoWpf A console application named HidDemoConsole All projects use a common file named hid.cs. This file is what this is all about. The applications mainly just show how to use it and give you a starting point for your own application.\nhid.cs is not pretty. 900 something lines of DLL imports, COM object calls and marshalling. It\u0026rsquo;s C# but it doesn\u0026rsquo;t look and feel like C#. But it does all the heavy lifting for you and offers a nice, clean, truely C# interface for you to work with HID devices.\nYou add it to your namespace, create an instance of HidUtility, tell it what device to connect to and subscribe to the events you are interested in: // Get an instance of HidUtility HidUtility HidUtil = new HidUtility(); // Connect to device with Vid=0x1234 and Pid=0x5678 HidUtil.SelectDevice(new hid.Device(0x1234, 0x5678)); // Subscribe to the events you care about HidUtil.RaiseDeviceRemovedEvent += DeviceRemovedHandler; HidUtil.RaiseDeviceAddedEvent += DeviceAddedHandler; HidUtil.RaiseConnectionStatusChangedEvent += ConnectionStatusChangedHandler; HidUtil.RaiseSendPacketEvent += SendPacketHandler; HidUtil.RaisePacketSentEvent += PacketSentHandler; HidUtil.RaiseReceivePacketEvent += ReceivePacketHandler; HidUtil.RaisePacketReceivedEvent += PacketReceivedHandler;\nYou can also obtain a list of all available HID devices at any time: foreach (Device dev in HidUtil.DeviceList) { Console.WriteLine(dev.ToString()); }\nAs the three projects demonstrate, the very same hid.cs file can be included in just about any C# project. There is not a single API call or anything in the remaining files.\nJust register some event handlers and your application will be informed whenever a device has been added or removed, when a package of data has been received from the device, when the connection status has changed or whatever else.\nSo you don\u0026rsquo;t have to re-invent the wheel every time and can fully concentrate on the application you have in mind, not the details of USB communication.\nA word of caution: I am by no means an expert C# programmer. I have tried the applications on 3 different PCs running Win7 and Win10, respectively. They seem to work reliably on any of these. Apart from that the code has not yet been productively deployed and there may well be some bugs and issues. If you find anything that doesn\u0026rsquo;t work, please let me know and I will do my best to get things fixed and updated on github. Also, please comment on this post if anything needs clarification.\nSo once again, the code is available for download from github.com/soldernerd/HID_Utility.\n","date":"13 February 2017","externalUrl":null,"permalink":"/posts/c-usb-hid-utility/","section":"posts","summary":"Have you ever tried to write a program that connects to some device via USB? I have done so a few years ago and was shocked how much of a pain that is (at least on a Windows plattform). I always thought there should be a nice little library that wraps all those uggly DLL imports, marshalling and COM API calls and offers a nice and clean C# interface to the outside world.\n","title":"C# USB HID Utility","type":"posts"},{"content":"","date":"13 February 2017","externalUrl":null,"permalink":"/tags/software/","section":"tags","summary":"","title":"software","type":"tags"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/tags/anemometer/","section":"tags","summary":"","title":"anemometer","type":"tags"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/categories/arduino-ultrasonic-anemometer/","section":"categories","summary":"","title":"arduino-ultrasonic-anemometer","type":"categories"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/tags/cad/","section":"tags","summary":"","title":"cad","type":"tags"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/tags/fablab/","section":"tags","summary":"","title":"fablab","type":"tags"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/tags/ultrasonic/","section":"tags","summary":"","title":"ultrasonic","type":"tags"},{"content":" In my last post of this series I\u0026rsquo;ve looked at different transducers and finally decided on a entirely waterproof 14mm model. The much lower signal level from those kind of transducers makes it necessary to reduce the distance between the transducers in order to still receive a reasonable signal amplitude. So I took my previous lasercut design and reduced it in size so that the distance between the transducers is only 120mm. I went to the local FabLab and and lasered two copies of the downsized design.\nSince the new transducers are only 14mm in diameter but those plastic pipes are only available in 16mm I had to pad the transducers with short sections of aluminium tube with an outer and inner diameter of 16 and 14mm, respectively. I previsously connected the wind meter to an Arduino with a LCD display to test the I2C functionality as well as to read the wind speed and direction without having to connect the anemometer to a PC. Now I have used my I2C user interface for that purpose. It is powered from the wind meter\u0026rsquo;s 3.3 volt rail and is controlled via I2C including the backlight brightness and display reset. The user interface usually also includes a rotary encoder with push-button not present in this application.\nIn an attempt to boost signal amplitude I\u0026rsquo;ve also changed the first stage op amp\u0026rsquo;s gain from 11 to 31 by replacing the 10k resistor with a 30k one. I\u0026rsquo;ve argued in my last post that this is probably about as far as you can safely push it. Even with the lowered transducer distance and increased gain the signal amplitude after the first stage is less than impressive. But we knew that already. And we have a second variable-gain stage at our disposal. Setting the second stage\u0026rsquo;s gain sufficiently high we hopefully get the 3 volts peak-to-peak amplitude we are aiming for.\nBy the way, I\u0026rsquo;ll started from scratch with the firmware. The reason for that is mainly USB. Currently, the anemometer acts as a HID device. While working on my solar charger I started to play around with HID / MSD (human interface device / mass storage device) composite devices. They still act as HIDs with all the functionality just like before. But when you plug it into a PC it also enumerates as a mass storage device, i.e. it behaves just like a memory stick. You can read and write the files on it from any computer, irrespective of the operating system and without needing any particular softwar or driver installed. So you can put all the configuration parameters in a text file that resides on what looks like a memory stick. I guess that\u0026rsquo;s the most user friendly way of dealing with those user-specific configuration parameters. Just plug it in, open a text file, change what you need, save the file and you\u0026rsquo;re done. This is how the solar charger will operate and I\u0026rsquo;ve decided to implement the same here. Microchip\u0026rsquo;s Harmony library includes all that functionality so I have no doubt it\u0026rsquo;s doable. But I\u0026rsquo;ve figured that it\u0026rsquo;s likely easier to do this as a new project and then add the previously implemented functionality step-by-step.\nAnd then there\u0026rsquo;s another USB-related feature that I had in mind right from the start but which I haven\u0026rsquo;t event started to implement so far: A USB boot loader. That would enable people to do a firmware update without needing a in-circuit programmer such as the PICKit 3. Users could just download a new HEX file and upgrade the firmware without needing any special hardware or even skills. USB boot loaders come in various flavours. The Harmony library includes support for an HID boot loader. But that\u0026rsquo;s not really ideal if you ask me. It means that you need to run some software on your PC that communicates with the anemometer and sends the new firmware via USB. The need for software means that it matters what kind of operating system you run. And needing additional software is undesirable in the first place.\nThere are also MSD bootloaders which do not have all those downsides. The device acts as a memory stick to the PC. The user then just copies the HEX file to that memory stick and that\u0026rsquo;s it. Just drag-and-drop, no extra software, no matter what OS.\nThe problem is that the Harmony library does not support that out of the box. Indeed, Microchip doesn\u0026rsquo;t seem to have implemented that for any of their chips. That\u0026rsquo;s kind of strange because other chip manufacturers have done so long time since. There is at least one implementation for PICs out there in the web but I haven\u0026rsquo;t looked at it yet because the website it was hosted on no longer exists it seems. Probably I\u0026rsquo;ll have to implement this myself but the Harmony support for MSD will hopefully do much of the heavy lifting.\nSo that\u0026rsquo;s the plan. Implement a bootloader, preferably of the MSD variety. And then run the anemometer appliction as a HID/MSD composite device. You may say that I set the wrong priorities given the fact that the actual measuring is not yet as good as it needs to be. But this kind of fundamental architecture is easier to get right from the very beginning. So that\u0026rsquo;s why. If you\u0026rsquo;re interested in this lasercut design you can find iton github.com or more precisely on https://github.com/soldernerd/AnemometerLasercut. This version is called Anemometer_03.scad and the PDF that was used for the actual laser cutting is Anemometer_03.pdf.\n","date":"5 February 2017","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-30-downsized-hardware/","section":"posts","summary":" In my last post of this series I’ve looked at different transducers and finally decided on a entirely waterproof 14mm model. The much lower signal level from those kind of transducers makes it necessary to reduce the distance between the transducers in order to still receive a reasonable signal amplitude. So I took my previous lasercut design and reduced it in size so that the distance between the transducers is only 120mm. I went to the local FabLab and and lasered two copies of the downsized design.\n","title":"Ultrasonic Anemometer Part 30: Downsized Hardware","type":"posts"},{"content":"","date":"5 February 2017","externalUrl":null,"permalink":"/tags/ultrasonic-anemometer/","section":"tags","summary":"","title":"ultrasonic-anemometer","type":"tags"},{"content":"","date":"29 January 2017","externalUrl":null,"permalink":"/tags/inductance-meter/","section":"tags","summary":"","title":"inductance-meter","type":"tags"},{"content":"","date":"29 January 2017","externalUrl":null,"permalink":"/tags/pcb/","section":"tags","summary":"","title":"pcb","type":"tags"},{"content":" In late 2014 and early 2015 I had posted a short series on an inductance meter project. The first post in that series described an Arduino shield that allowed an Arduino UNO to do inductance measurements and got this blog mentioned on dangerousprototypes.com for the very first time.\nI got a lot of encouraging feedback and some time last year Andy Beasley asked me if I could help him extracting Gerber files from Eagle so that he could get some boards made and build his own. I was happy to do so and was rewarded with half a dozen boards. Thank you very much, Andy.\nAt the time I was busy working on other projects so the boards collected some dust until Sean Connolly sent me a message asking if I could make an inductance meter for him. That was a great opportunity to finally build up one of these boards.\nThe result was the most beautiful of my inductance meters so far. There\u0026rsquo;s nothing new technically - It\u0026rsquo;s still the circuit described in this post.\nBy the way, I\u0026rsquo;ve started to share more and more of the projects on github. All the photos, descriptions and so on will continue to be published here on soldernerd.com but I will put the download material such as source code, eagle files and the like on github.com/soldernerd where it is easier to keep files in sync and to potentially collaborate with other developers.\nSo here\u0026rsquo;s a list of the relevant repositories on github:\nHardware: InductanceMeter_Hardware Software: InductanceMeter_Software ","date":"29 January 2017","externalUrl":null,"permalink":"/posts/standalone-inductance-meter-on-a-etched-board/","section":"posts","summary":" In late 2014 and early 2015 I had posted a short series on an inductance meter project. The first post in that series described an Arduino shield that allowed an Arduino UNO to do inductance measurements and got this blog mentioned on dangerousprototypes.com for the very first time.\n","title":"Standalone Inductance Meter on a Etched Board","type":"posts"},{"content":"It\u0026rsquo;s been way too long since the last post in my Ultrasonic Anemometer series. But better late then never.\nSo far I have always used the same type of transducers. When I started this project I looked around and found the Multicomp MCUSD16A40S12RO. They were comparatively cheap and readily available so I ordered some and used nothing else for the next two or so years.\nHowever, they are not hermetically sealed and therefore not the most suitable type to use outdoors all year around. Some of you have already experimented with other, truely watertight types and have reported that the signal level with those is dramatically lower. So I decided to see what\u0026rsquo;s available and do a more systematic comparison. That\u0026rsquo;s what this post is about.\nThe Contestants\nMulticomp MCUSD16A40S12R0 (Farnell 2362677), 16mm, not waterproof, no wires attached. Multicomp MCUSD14A40S09RS (Farnell 2362679), 14mm, waterproof, no wires attached. Multicomp MCUSD14A40S09RS-30C (Farnell 2362678), 14mm, waterproof, with attached wires. Multicomp MCUSD18A40S09RS-30C (Farnell 2362680), 18mm, waterproof, with attached wires. You might wonder why I\u0026rsquo;m only considering Multicomp models but those 3 models are pretty much all the 40kHz watertight transducers I can get from Farnell.\nSo what I did is I attached all 4 models to the same anemometer so that I can switch back and forth between them. That turned out to be rather tedious and time consuming and resulted in a big mess of wires so I was happy that I only had 4 types to worry about.\nI\u0026rsquo;ve measured the signal after the first (fixed gain) stage of the op-amp. So the signal reported here is already boosted up by a factor of 11.\nThe Benchmark\nLet\u0026rsquo;s first look at the model used so far. As we already know it delivers a solid signal amplitude.\nZooming in at the burst at the center of the screen (the one with the smalles amplitude) gives us a reading of 1.9 volts peak-to-peak.\n14mm waterproof transducer without wires\nLet\u0026rsquo;s look at the first waterproof model. The signal amplitude us barely noticable at first.\nZooming in (both horizontally and vertically) then reveals the amplitude: 47 millivolts, a factor of 40 less than the benchmark model.\n14mm waterproof with wires\nNext in line is a transducer that looks virtually identical but has a pair of drilled wires at the back as opposed to just two pins. The overview looks just like before.\nZooming in shows an even smaller signal amplitude of only 37millivolts. That\u0026rsquo;s surprising because it has somewhat better specs compared to the previous model.\n18mm waterproof with wires\nOnce again, the overview shows hardly anything for the 18mm model.\nZooming in we find an amplitude of 38 millivolts, basically the same as the last model.\nConclusion\nThe first fact is obvious: with hermetically sealed transducers you can only expect a small fraction of the signal at the input. I knew that but was still surprised to find how much smaller that singal is. In this comparison it\u0026rsquo;s a factor of 40in the very best case.\nBut an anemometer is useless if it cannot withstand the elements so I guess we have to live with that. I will use the 14mm without wires type going forward. Not only did it perfom best in my comparison but it is also the most affordable (waterproof) model. Apart from that I like its small 14mm form factor allowing for slim designs posing less resistance to the airflow.\nThe road ahead\nWe obviously need to make some hardware changes to deal with the low signal amplitude. The most obvious solution is more gain. We can get more gain of the first (fixed gain) stage by just changing a resistor. However, we need to be careful not to push the op amp beyond its limits. I\u0026rsquo;ve looked at the LMC6482 datasheet again and found a gain/bandwidth product of 1.5MHz. That means we can get a maximum gain of 37.5 at 40kHz. You probably don\u0026rsquo;t want to push the op amp right to its limit so something like 31 (changing the 10k resistor to 30k) is probably about the best we can do here. That gives us an extra factor of 2.82.\nMaking the physical design smaller and therefore reducing the distance between the transducers is another thing we can do. The current desing is 245mm which is rather large. Someone has reported to me that he reduced that all the way down to 100mm. I don\u0026rsquo;t think I will go that far but will try 120mm which is about half of what I have now. That should double the signal amplitude. And the smaller transducers should make the task easier.\nThe two measures combined give an extra gain of factor 5.6. That leaves us with another factor 7 to be compensated elsewhere. Fortunately, we still have a second op amp stage (the one controlled by software) which hasn\u0026rsquo;t been doing much so far. With the previous transducer model it only had to deliver something like a factor 1.5. If we boos this up to 10 we pretty much have all we need.\nA software bug\nDuring my tests I also discovered some weird software behaviour when the signal (after both stages of amplification) is not in the expected range. USB may hang, among other things. The pulse-sending sequence can also get upset. Someone had reported this to me earlier but I wasn\u0026rsquo;t able to reproduce the problem until now. I don\u0026rsquo;t expect this to be a major thing to fix but you never know. But I\u0026rsquo;ll definitely look into this.\n","date":"23 December 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-29-transducer-comparison/","section":"posts","summary":"It’s been way too long since the last post in my Ultrasonic Anemometer series. But better late then never.\nSo far I have always used the same type of transducers. When I started this project I looked around and found the Multicomp MCUSD16A40S12RO. They were comparatively cheap and readily available so I ordered some and used nothing else for the next two or so years.\n","title":"Ultrasonic Anemometer Part 29: Transducer Comparison","type":"posts"},{"content":"","date":"23 December 2016","externalUrl":null,"permalink":"/tags/ultrasonic-transducer/","section":"tags","summary":"","title":"ultrasonic-transducer","type":"tags"},{"content":"","date":"25 November 2016","externalUrl":null,"permalink":"/categories/general/","section":"categories","summary":"","title":"general","type":"categories"},{"content":"This will be my shortest post ever. But I just spotted a project on indiegogo.com that I think is worth mentioning: A small and affordable tool to do reflow soldering. It\u0026rsquo;s basically a heating plate specifically designed for reflow soldering. So it can reproduce JEDEC temperature profiles, it does data logging and and you can even control it via a web interface if you spend an extra 9$ on the wifi upgrade.\nHere\u0026rsquo;s the link: https://igg.me/at/reflowr/x/15560432 or reflowr.com (links no longer available)\nI\u0026rsquo;ve been looking around for some kind of reflow oven for a while but nothing affordable quite convinced me. This morning I just stumbled accross this project by chance. I\u0026rsquo;ve ordered a \u0026ldquo;Large ReflowR\u0026rdquo; with the wifi upgrade and an external thermoucuple and will report on how it performs once I get it which should be some time in February next year.\n","date":"25 November 2016","externalUrl":null,"permalink":"/posts/reflowr-on-indiegogo-com/","section":"posts","summary":"This will be my shortest post ever. But I just spotted a project on indiegogo.com that I think is worth mentioning: A small and affordable tool to do reflow soldering. It’s basically a heating plate specifically designed for reflow soldering. So it can reproduce JEDEC temperature profiles, it does data logging and and you can even control it via a web interface if you spend an extra 9$ on the wifi upgrade.\n","title":"ReflowR on indiegogo.com","type":"posts"},{"content":"","date":"15 November 2016","externalUrl":null,"permalink":"/tags/dc-dc-converter/","section":"tags","summary":"","title":"dc-dc-converter","type":"tags"},{"content":"","date":"15 November 2016","externalUrl":null,"permalink":"/tags/electronics/","section":"tags","summary":"","title":"electronics","type":"tags"},{"content":"It\u0026rsquo;s time to follow up on the MPPT Solar Charger project. Progress has been slow since I\u0026rsquo;m currently working full time and doing a master\u0026rsquo;s degree at the same time. Given that this blog has previously been something close to a 50% job at times things will necessarily slow down a bit. But all the projects, including this one and the ultrasonic anemometer are alive and well and I\u0026rsquo;m working on them whenever I find some time.\nUser Interface\nSo what\u0026rsquo;s new with the MPPT solar charger? First of all, it got this nice user interface. Unfortunately there were still some issues with the first version so there is an identically looking but much-improved and bug-free Rev B. I\u0026rsquo;ll do a separate post on that documenting all the things I\u0026rsquo;ve changed.\nI re-used the white-on-blue display from the initial version for the Rev B. as opposed to the black-on-white used with the Rev A. They are pin compatible so you can use whichever you prefer. I more and more start liking that black-on-white look. It\u0026rsquo;s about 10 bucks cheaper as well. What\u0026rsquo;s your opinion on this?\nSolar Panel drains Battery\nMy intention with this design was to just leave the solar panel connected to the input of the buck converter. There\u0026rsquo;s a problem with that, however. The input of a buck is always at least at the output voltage minus a diode drop. With a 12V lead-acid battery at the output the input (i.e. where the solar panel is connected) the voltage never drops much below 12 volts.\nThat\u0026rsquo;s a serious problem since even a small solar panel like the monocrystalline 30W panel I have here sinks around 10mA at that voltage. So whenever the panel is not providing any power it considerably drains the battery.\nTry a Diode\nObviously we need a way to avoid that. The first solution that comes to mind is a diode. But there\u0026rsquo;s a problem with that, too. To keep the power loss in the diode acceptable, the diode needs to have a low forward voltage. However, any diode with a low forward voltage also comes with a high reverse leakage. Physics seems to dictate that.\nLeakage can easily be in the range of milliamps for a diode that can handle, say, 4A like needed here. And that reverse leakage is also highly temperature dependent. It may be ok-ish at room temperature and then detoriate by an order of magnitude at 50 degrees centigrade.\nTo get an acceptable reverse leakage one needs to tolerate at least half a volt of forward drop which is something like 3% in efficiency. Since our converter operates at around 97% efficiency that would mean doubling the energy dissipated.\nP-Channel or N-Channel Mosfet\nSo the next obvious thing to try is a mosfet acting as a switch. Yes, a mosfet also has a body diode that also has a reverse leakage. But the body diode is a bad diode in terms of forward drop and has a correspondingly low reverse leakage.\nA nice way of solving our problem would be to use a p-channel high-side switch disconnecting the battery from the converter whenever the panel is not producing. That not only disconnects the panel but powers off the entire buck including the input and output caps and everything. Where there is no voltage no power can get wasted. Perfect.\nUnfortunately, powerful (i.e. low Rds-on) p-fets are relatively large, rare and expensive. As a rule of thumb a p-fet needs twice as much silicon area for the same performance compared to a n-fet. Besides that, that would be another type of component and I\u0026rsquo;m trying to not use too many distinct components.\nSo the other solution is to use an n-fet as low-side switch just disconnecting the panel. We already have 6 powerful n-fets in our design and they are cheap, too. So this is what I\u0026rsquo;ll do in the next version.\nFor now I\u0026rsquo;ve used one of the power outputs to connect the panel. I\u0026rsquo;ve cut some traces and soldered in some wires so that the fet is on whenever the buck is powered on.\nBuck Software\nDuring early testing of the buck converter I managed to kill the bottom fet several times. Since I was able to run the buck at relatively high power levels for prolonged periods of time without any issues (and without getting hot) I suspected that this was caused by carelessly written software. This seems to have been the case indeed. Whenever I killed a fet it happened at startup or shutdown, usually the latter. In the mean time I\u0026rsquo;ve written well-defined startup and shutdown routines and never had any issue since.\nSynchronous converters are dangerous in this respect. It is very easy to short the battery to ground via the bottom fet. All it takes is a duty cycle that\u0026rsquo;s too low or a timer is running too slow or not at all. Or you stop the PWM module at a time when the bottom fet is on and it will stay on forever. Or at least a few milliseconds until it\u0026rsquo;s dead.\nAsynchronous topologies are much more forgiving in this respect since you can\u0026rsquo;t short anything. So an easy solution would be to start up and shut down in asynchronous mode. We can easily make this an asynchronous converter in software by just not utilizing the bottom fet. The diode in parallel with it will then automatically take over.\nUnfortunately we cannot start up in asynchronous mode. Why? To enable the upper fet we need a bootstrap voltage above the input voltage. And we don\u0026rsquo;t have that unless the converter is running. It\u0026rsquo;s a chicken and egg problem, really. So we need to start up in synchronous mode at least for a few switching cycles for the bootstrap diode to charge up.\nThat\u0026rsquo;s exactly what the startup routine does. It completes 16 cycles in synchronous mode at a neutral duty cycle. What do I mean by neutral? Simple: Duty Cycle = Output Voltage / Input Voltage. That means no current actually flows on average. So this is a nice, soft way to start up. After those 16 duty cycles the buck enters asynchronous mode. As the screenshot above shows, the bootstrap capacitor is fully charged after just one full duty cycle so that number is more than sufficient.\nThis routine is critical. If it doesn\u0026rsquo;t do precisely what it should chances are high that the buck is destroyed. So I\u0026rsquo;ve checked it carefully by both looking at the code and the scope. I\u0026rsquo;ve run it many times and observed closely what it does just to be sure it starts up nicely very time.\nWhy run in asynchronous mode? Because it\u0026rsquo;s more efficient at low power levels. Once the current rises above a software-defined threshold the converter will change to synchronous mode. If the current later falls below a second (lower) threshold, the buck changes back into async mode.\nThe optimal values for the two threshold will have to be determined experimentally but will likely be in the range of a few hundred milliamps.\nThe shutdown sequence is simple. The buck is shut down if the current falls below a very low threshold (say, 10mA) below which it cannot run profitably. If the current falls even lower we are better off shutting down the buck and entering a low-power mode. Since the current is low when we shut it off, the converter is already in async mode. So shutting it down is now easy and uncritical. We just turn off the top fet and can then also turn off the timer and supply voltage to the buck. The screenshot above shows an example of that.\nConserving power\nA main feature of this solar charger is it\u0026rsquo;s ability to (hopefully\u0026hellip;) run at a very low (\u0026lt;100microamps) current when not in use. So we obviously need to turn off everything we don\u0026rsquo;t need and run the PIC at a much lower frequency as well.\nThe PIC\u0026rsquo;s maximum operating frequency is 48MHz. This is the frequency it runs at when the buck and/or USB (not yet implemented) is on. These two features need that clock frequency to perform their task.\nIf both the buck and USB are off we can clock the PIC down to 8MHz which already saves a great deal of power. At 8MHz we can still do everything else, including running the user interface. Updating the display and particularly calculating the display content consumes quite some computation time and so we need a few MHz to do this.\nIf the user interface is not used for a certain time (say, 10 seconds), it is turned off. We can then lower the board voltage to 2.3 volts and lower the CPU frequency even further to 32.768kHz. This is the frequency of the real-time clock that is running anyway. At such a low frequency the PIC\u0026rsquo;s computational power is low but still sufficient to do some housekeeping tasks.\nOne can wake up the user interface at any time by pressing the push button. Turning the encoder won\u0026rsquo;t help because that, too, has been powered off.\nWhile in this low power mode every 6 seconds the board voltage is raised to 3.3 volts and all temperatures as well as the input and output voltages are measured. That all happens at 32.768kHz. After the measurement is complete the PIC decides if the panel voltage is high enough to start harvesting energy or not. If this is not the case the board voltage is lowered again and a new set of measurements is captured 6 seconds later.\nDespite all those efforts the board consumes something like 530 microamps which is much more than it should. About 100 microamps comes from the voltage divider used to measure the panel voltge. That\u0026rsquo;s an easy to solve design problem that I\u0026rsquo;ve described earlier already. But that still means that something is drawing 400 microamps. Not much at all but still way too much.\nI\u0026rsquo;ve spent an evening trying to find the problem but I still don\u0026rsquo;t know. I\u0026rsquo;ve suspected the capacitors but when I measured some spare caps of the same type they hardly drew any current at 12 volts. I also un-soldered the buck\u0026rsquo;s mosfet driver but that made hardly any difference so that\u0026rsquo;s also not the problem. It may even just be some near-short on my board homemade board. So I leave that for now and check again once I have a revised design with a proper PCB.\nBuck testing\nI\u0026rsquo;ve saved the most interesting part for last ;-) I\u0026rsquo;ve established before that this converter has a similarly high efficiency than the Arduino version published some time ago. But at that time I was only able to test up to 35 or so watts.\nThis solar charger is capable of handling much more power than that. Testing how much was a bit more difficult than expected. Unless the battery is very empty it won\u0026rsquo;t draw as much as this charger is able to provide. And you don\u0026rsquo;t want to discharge a lead acid battery too much, they don\u0026rsquo;t appreciate it at all. So once again my constant current dummy load came to the rescue.\nWith the dummy load at one of the power outputs I was able to draw some serious current. I set the dummy load to 4 amps and the battery absorbed (or provided) whatever was left. Obviously, I can only do that for a limited amount of time until the dummy load gets too hot. It automatically shuts down once the heat sink reaches 70 degrees centigrade which is soon the case at 4 amps.\nI let the charger draw 4.5 amps at a bit more than 17 volts for as long as I could. The coil got quite warm, slightly hot even, maybe something like 60 degrees. The mosfet only got lukewarm and I\u0026rsquo;m not sure if this was because of their own power dissipation or due to their proximity to the coil.\nSo from this test I\u0026rsquo;d conclude that this was about the power which the charger can handle for a prolonged period of time. So I think something like 75 watts is a realistic power rating.\nI\u0026rsquo;ve also had another look at the datasheet of the coil and it pretty much confirmed my findings. 75 watts at (say) 13 volts output corresponds to 5.8 amps through the coil. The datasheet states that the coil starts saturating at 8.2 amps which means we\u0026rsquo;re still safe with 5.8 amps plus the ripple current. The datasheet also states a 40 degree temperature rise at 5.3 amps. So thermally the coil is pretty much at its limit at 75 watts. That, too, seems realistic to me having touched it after some time at that power.\nThe road ahead\nSo how to continue? As we have seen, there is a number of design issues but the general concept works. During testing and debugging I\u0026rsquo;ve cut and re-soldered many traces and also made some modifications like the one with the n-fet described above. I\u0026rsquo;ve unsoldered and changed many components as well. All of that doesn\u0026rsquo;t improve the reliability of the board. At some point it makes sense to design a new version, build it and take it from there. A clean slate kind of.\nI think this point has been reached here. So I will work on a new revision from now on. The concept won\u0026rsquo;t change at all but I\u0026rsquo;ll try to apply what I\u0026rsquo;ve learned so far. I also hope to reduce the number of different components, reduce the size and total cost while not sacrificing performance. In other words move a step towards a design that may one day be built as a small series. Let\u0026rsquo;s see.\n","date":"15 November 2016","externalUrl":null,"permalink":"/posts/mppt-solar-charger-testing-ii/","section":"posts","summary":"It’s time to follow up on the MPPT Solar Charger project. Progress has been slow since I’m currently working full time and doing a master’s degree at the same time. Given that this blog has previously been something close to a 50% job at times things will necessarily slow down a bit. But all the projects, including this one and the ultrasonic anemometer are alive and well and I’m working on them whenever I find some time.\n","title":"MPPT Solar Charger Testing II","type":"posts"},{"content":"","date":"15 November 2016","externalUrl":null,"permalink":"/tags/testing/","section":"tags","summary":"","title":"testing","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/20x4-lcd/","section":"tags","summary":"","title":"20x4-lcd","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/4x20-lcd/","section":"tags","summary":"","title":"4x20-lcd","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/74hc126/","section":"tags","summary":"","title":"74hc126","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/display/","section":"tags","summary":"","title":"display","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/lcd/","section":"tags","summary":"","title":"lcd","type":"tags"},{"content":" As you may have noticed I\u0026rsquo;m quite busy working on the MPPT Solar Charger project. The latest version uses a 4 lines x 20 characters LCD that connects via I2C as well as a rotary encoder with a push button.\nWhile the display got its own little board, the encoder connected directly with the solar charger where its signals aredebounced in hardware and then routed to the PIC.\nAfter a few little fixes (see my last post) that worked but I had to use the signal intended for controlling the backlight brightness for the display\u0026rsquo;s reset signal. I don\u0026rsquo;t want to run any more wires to the display and there are no spare pins on the PIC anyway so I had to come up with another solution.\nAnd it was not very elegant that the display was powered off by just cutting the entire power supply. Having a digital enable/disable signal would be preferable\nDesign a universal User Interface\nI then decided to design an new board that also includes the rotary encoder with all the necessary debouncing. That way I get a quite universal, easy to use user interface that I can use for other projects as well. That eliminates the need to design the same functionality (think debouncing) again and again. The size of the board is mainly given by the size of the display so there is plenty of board space.\nSo far so good but that doesn\u0026rsquo;t solve the actual problems yet. I still need a way to control both the backight as well as the reset signal without needing any more singnals. Since the display connects via I2C it was quite straight forward to use I2C communication for those purposes as well. My first thought was to add a I2C port expander just like I\u0026rsquo;ve done on the solar charger board. Those chips aren\u0026rsquo;t expensive but they typically provide 8 or 16 extra GPIO pins which seemed a bit wasteful. And PWM control of the backlight would require a great deal of I2C communication which puts a burdon on the microcontroller.\nI also considered adding a sub-dollar PIC16 which could be programmed as an I2C slave and control both the backlight and the reset signal (as well as giving the option of getting the encoder input via I2C). But I wasn\u0026rsquo;t eager to write any software for this thing.\nRequirement: Ultra Low Power State\nAnother design requirement was to keep this a very low-power design. To be sure: when the display and especially the backlight are on it will consume several milliamps to several dozen milliamps. Illumination doesn\u0026rsquo;t work without power, such is life. But when the user interface is not in use, we need a way to put it in a very low power state where the display as well as the rotary encoder is off but the push button still works in order to wake up the microcontroller. In that state the user interface must not use more than a few microamps. Furthermore the encoder signals must assume a high impedance state when the user interface is disabled.\nMy final solution was as follows:\nUse the previous (backlight) PWM signal as an enable signal. Power can now always stay on. When the enable signal is high, the display is on, when enable is low, the user interface goes into its low-power state. Add a dual I2C digipot to control both the reset signal as well as the backlight. The reset signal is connected directly to the wiper of one of the two digipots. Of course any intermediate digipot values don\u0026rsquo;t make sense. The digipot should always be either at its minimum or its maximum.\nThe backlight brightness is controlled by the other digipot via an op-amp and a n-channel mosfet.\nThe debouncing is basically unchanged. Like in the solar charger design, a 74HC126 quad tri-state buffer is used together with some resistors and capacitors.\nSince there are 4 gates on the 74HC126 and I only need to debounce 3 signals, there is still one gate left. I used that gate to power the display as well as the encoder and the encoder\u0026rsquo;s gates(without the push button which is always powered on). So the enable signal only controls the input of that gate. I thought that\u0026rsquo;s a nice and elegant solution. Well, if you think so too, think again. More on that later.\nTesting\nFirst of all nothing worked at all. I asserted the enable signal and nothing happened. Nothing was powered on. The error was soon found. I made a design error with the result that the respective gate was permanently in a high-impedance state. Somehow I had tied the gate\u0026rsquo;s enable input to ground instead of VCC. The mistake was corrected by cutting the ground connection and conecting the respective pin to the enable singal itself which was available from the pin right next to it. Not pretty (see below) but problem solved.\nThen ok, power was there but when I tried to turn off the reset singal (i.e. pulling the reset signal high) nothing happened - again. Again, the reason was simple. The digipot\u0026rsquo;s upper terminal was floating instead of being connected to VCC. On the schematic the wire touched the respective pin but there was no connection. While that was really hard to notice on the schematic I should have noticed the problem when I laid out the board. There was obviously no connection to that pin.\nThis was a bit harder to fix than the previous error. There were no signals to cut but the digipot\u0026rsquo;s pins are much more closely spaced and the right signal was not to be found nearby. I ended up soldering a thin wire accross the digipot to a resistor that is connected to VCC on the upper end.\nEven less pretty but problem solved anyway. Turning on the backlight basically worked as intended but the load was a bit much for the 74HC126. While it can supply up to 35mA according to the data sheet, its output voltage is nowhere near its positive supply rail when it supplies that much current. Even with a more modest 5mA load the gate\u0026rsquo;s output voltage was about half a volt below the input voltage. As a result, the display as well as all the other components only get to see about 2.8 volts instead of 3.3. This didn\u0026rsquo;t pose any problems so far but it\u0026rsquo;s not nice.\nAnother issue I noticed was that the LM321 op amp I had chosen is not a rail-to-rail op amp. The LM321 is inexpensive and I had quite a few left from another project so I used it without giving it much thought. I measured that the output voltage doesn\u0026rsquo;t get closer than about 1.4 volts of the positive supply rail. Since the n-mosfet used to control the backlight has a very low threshold voltage that didn\u0026rsquo;t pose a problem but the LM321 is not really a good choice here. While it does work from as little as 3 volts it\u0026rsquo;s made for split supply and higher voltages, say plus/minus 12 volts. I\u0026rsquo;ll use a low-voltage rail-to-rail type next time.\nSoftware\nGetting any MIDAS I2C display to work is a nightmare. They make nice, pretty and affordable displays. That\u0026rsquo;s why I buy them. And once you\u0026rsquo;ve managed to properly initialize them they are easy to work with. But getting them initialized with the right settings is always a lengthy trial-and-error process. I\u0026rsquo;ve ranted about that before but I feel the need to do it once again.\nThe entire initialization sequence needs to be written in one single I2C transmission. At least for me it didn\u0026rsquo;t work otherwise. The data sheet says absolutely nothing about that.\nThe data sheet doesn\u0026rsquo;t even mention the initialization sequence. Nor the timing of the reset singnal. The reset signal needs to be pulled low for 10ms. One then needs to wait for 5ms before the initialization sequence is sent. There is not one word about that it in the current datasheet. There is an older version in the net somewhere that mentions those timing issues and at least gives a sample initialization sequence.\nThere are various contrast settings that must be set properly via I2C commands but there is very little information on those commands in the data sheet. I wrote an email to their customer support asking if there is a list of commands the display supports. That was more than a month ago and I still didn\u0026rsquo;t get any answer. As so often, google was my friend and others have faced similar problems before so I managed to find some commands that make the display work properly. I\u0026rsquo;m sending 10 or so bytes to the display but for most of them I have not a clue what they actually mean or what they are supposed to do. And the commands for this black-on-white display are different to the (otherwise identical) white-on-blue display. Have fun\u0026hellip;\nDebouncing\nI\u0026rsquo;ve devoted one of my very first posts to the much-neglected issue of debouncing. The logic is pretty much the same here except that I use different (non-inverting) gates here. The reason for that is the need for 3-state outputs as mentioned before.\nUnfortunately the 74HC126 doesn\u0026rsquo;t have schmitt-triggered inputs so I need to implement the necessary feedback myself via the 680k resistors.\nDebouncing something like a pushbutton is quite easy. Just use a relatively long time constant (i.e. large resistors and capacitors) and all will be fine. That will introduce some delay in the output signal but as a rule of thumb anything below 50ms is not noticable. And a time constant of a few milliseconds is totally sufficient so you might end up with something like 10ms of delay. No human user will ever notice it and it\u0026rsquo;s more than enough to perfectly debounce any switch that I\u0026rsquo;ve seen.\nWith rotary encoders things get much trickier. The basic circuit is exactly the same but choosing the right component values is more difficult. You can\u0026rsquo;t press a button more than a few times a second but a rotary encoder might produce pulses just milliseconds or even less apart.\nSo you face the challenge of debouncing the signal while still letting relatively fast transitions pass. If you use a time constant of a few milliseconds like with the push button you will not be able to detect when the encoder is turned quickly.\nThe data sheet of the Burns encoder I\u0026rsquo;m using here recommends using two 10k resistors together with a 10nF cap. I\u0026rsquo;ve increased the value of one resistor to 22k but have otherwise followed that recommendation. So the time constant is now a few hunderd microseconds.\nToghether with the positive feedback via the 680k resistors that works very well. I expected to tweak those values a bit but found that they work so well that I just leave them as they are.\nI\u0026rsquo;ve inserted plenty of scope screenshots here to give you an idea of what the undebounced and debounced signals look like. Even with the same encoder there\u0026rsquo;s plenty of variation as you can see. But with the hardware debouncing applied here we get a clean, digital output singal nevertheless.\nPower consumption\nVery low standby power consumption was one of the key design goals. When in low-power mode only the push button pull-up and the 74HC126 is supplied with power. Everything else, the display, the op-amp, the digipot and the pull-up for the rotary encoder are all completely powered off.\nAs long as the push button is not pressed, no power flows there so the only power consuming device is the 74HC126. Its datasheet specifies a maximum static current consumption of 8 microamps (worst) at room temperature. There\u0026rsquo;s no typical figure so that\u0026rsquo;s all the information I had. When I measured it, this is what I got.\nThat\u0026rsquo;s 4 nanoamps at 3.3 volts which is nothing really. Actually the measurement fluctuated between about 0 and 15 nanoamps. I thought something is not hooked up correctly but when I pushed the button the current jumped to 326 microamps which is just what I expected since there is a 10k pull-up resistor conected to that button.\nSo the measurement works and it seems that the 8 microamps given in the data sheet are just a very conservative worst case. I mean CMOS is close to zero-power when static and only a single tri-state gate is active so essentially no current flows. Cool.\nNext steps\nAfter the two hardware fixes this user interface works quite as intended. Using the spare gate to supply the rest of the circuit with power was not as good an idea than I thought. On the positive side the debouncing works just perfect with the chosen component values. And as mentioned, the op-amp was not a great choice for the job at hand.\nBut I like the look and feel of this universal user interface and think the overall concept is good. So there will be a Rev B of this board with those issues solved.\nHere you find the eagle files as well as PDFs of the schematic and board. The two errors are already corrected but I haven\u0026rsquo;t actually built them so check carefully yourself. I\u0026rsquo;ve also re-exported the gerbers so they, too, already include the fix.\nUserInterfaceRevA_EagleAndPDFs (file no longer available) UserInterfaceRevA_Gerbers (file no longer available) ","date":"14 October 2016","externalUrl":null,"permalink":"/posts/low-power-user-interface/","section":"posts","summary":" As you may have noticed I’m quite busy working on the MPPT Solar Charger project. The latest version uses a 4 lines x 20 characters LCD that connects via I2C as well as a rotary encoder with a push button.\n","title":"Low Power User Interface","type":"posts"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/midas/","section":"tags","summary":"","title":"midas","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/push-button/","section":"tags","summary":"","title":"push-button","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/switch/","section":"tags","summary":"","title":"switch","type":"tags"},{"content":"","date":"14 October 2016","externalUrl":null,"permalink":"/tags/user-interface/","section":"tags","summary":"","title":"user-interface","type":"tags"},{"content":" In a previous post I have presented a design for an MPPT Solar Charger. In the mean time I have built a prototype and also wrote some software for it. So today I\u0026rsquo;ll go through my findings of what works well and what needs to be improved. And yes, there are some flaws in the design\u0026hellip;\nThe software is far from final but with the notable exception of USB all the basic functionality has been implemented.\nPower Supply\nOne of my main goals with this design is to archieve very low standby current, somewhere in the tens of microamps. The basis for this is a low-power buck on the basis of a Texas TPS62120 where the microcontroller can switch the output voltage between 2.2 and 3.3 volts nominally. This works as intended. With no load and the output voltage low, the supply consumes 12.9 microamps at 12V input voltage. With the high output voltage the idle current goes up to 14.3uA. Quite a bit of that current is due to the voltage divider that sets the output voltage. The regulator itself consumes about 9uA in both cases.\nMicrocontroller\nThe PIC18F26J50 starts up using the primary oscillator\u0026rsquo;s 8MHz crystal with the internal PLL disabled. It can then switch to 48MHz operation by enabling the PLL or to the secondary oscillator running at 32.768kHz. The latter is always running since it also serves as the clock source to the real-time clock and calender (RTCC). Switching between clock sources as well as the RTCC have been implemented in software and work fine.\nI2C Multiplexer and Port Expander\nThe microcontroller doesn\u0026rsquo;t have enough GPIO pins so a I2C port expander (Microchip MCP23008) is used to give us another 8 pins. The display is connected via I2C as well but since the display is entirely powered off when not in use, the display cannot be on the same bus. Otherwise it will pull the SCL and SDA lines low and block the bus. The NXP PCA9546 multiplexer takes care of that. Both devices, the mux as well as the port expander work as they should.\nVoltage Reference, Temperature Sensors and Fan\nThere is a total of 3 temperature sensors, one on the board and 2 external ones. The temperature is measured by the PIC directly so it has a 2.5V voltage reference in order to get meaningful results. At room temperature all three temperature sensors deliver very similar results, typically within a few tenth of a degree. Better than expected. The fan output can also be enabled if the on-board temperature gets too high.\nVoltage and Current Measurements\nThe more important measuements, namely the input and output voltages and currents are performed by a MCP3424 4-channel 18-bit ADC. I was already familiar with that type so I quickly got it to work. In this application I don\u0026rsquo;t use its internal PGA (programmable gain amplifier) or rather I leave the gain at 1. All the measurements are done with 14bit accuracy which is reasonably fast (23ms worst case) and sufficient here.\nUser Interface\nThe debouncing of the rotary encoder works ok but I\u0026rsquo;ll tweak the resistor and capacitor values a bit when I get time. The push button is uncritical but there is a bit too much debouncing for the rotary encoder itself making it miss some very fast turns. But it already performs reasonably well as it is.\nThe display module is the first real flaw in my design. It has 5 wire connections: GND, VCC, SDA, SCL and Backlight. The idea was to turn the display off by simply cutting off VCC when the display is not needed. When in use, the brightness of the backlight is then controlled by the Backlight PWM signal.\nSince the display needs quite a few supporting components (mainly 1uF capacitors) and has no mounting holes I made a little one-sided PCB for it. When I first tried it nothing worked. A ground connection was missing and I didn\u0026rsquo;t notice that in Eagle because in Eagle it was a double-sided board. That was easily fixed by a short piece of blank wire soldered in place. So far so good.\nUnfortunately the display (a Midas MCCOG42005A6W-BNMLWI) still didn\u0026rsquo;t work. Besides the data sheet being a nightmare it needs to be reset after having powered up. So you need to power it up, wait for a while and then do a reset by pulling its reset pin low. So just pulling the reset pin high with a resistor like I have done won\u0026rsquo;t work. My solution for now was to connect the backlight signal to the reset pin. So I can now use the display but the backlight brightness is permanently at it\u0026rsquo;s maximum.\nI already have a new and hopefully better version of this display unit in the making and there will be a separate post on that. My idea is to have a rather universal module that I can use in other projects as well.\nUSB Charging\nThe USB charging module works reasonably well. When pulling the full rated current of 2A it gets rather warm but doesn\u0026rsquo;t overheat. I was able to pull 2.5 amps for a prolonged period of time without any issues. I only had a Samsung A5 to try but at least that phone charged perfectly fast pulling around 1A of current. With that load the module only gets slightly warm.\nTurning the USB charger on and off in software also works as planned. This can now even be done via the user interface - see above.\nPower Outputs\nThe 4 power outputs can be controlled in software. In order to save power, the mosfet drivers can be powered off if none of the outputs is on . All that is already implemented in software and the outputs can be turned on and off individually via the user interface.\nI plan to implement a low-frequency (say, 100Hz) PWM functionality for these outputs in order to e.g. control some LED lighting but that has not been done yet.\nEEPROM\nI haven\u0026rsquo;t implemented any data logging functionality yet but I have written a few library functions for the EEPROM. When the date and time is set via the user interface those values are saved to EEPROM and restored after a reset. Reading from and writing to the EEPROM therefore works.\nSolar Charger\nYes, I\u0026rsquo;ve left the main thing for last. Don\u0026rsquo;t know why.\nWhen I first assembled the board I noticed that I had ordered the wrong mosfet driver - a MIC4605-2 instead of a MIC4605-1. They are near-identical except the fact that the -1 has two independant inputs while the -2only has one PWM input plus an enable signal. That also works but doesn\u0026rsquo;t give us the option to run the converter in asynchronous mode. So I\u0026rsquo;ve unsoldered the chip again and replaced it with the MIC4605-1 that I had in mind when I designed this thing.\nAs you can see on the photos above, I\u0026rsquo;m now using a 22uH coil, not a 68uH coil as shown in the schematic. The reason for that is that I\u0026rsquo;m using a relatively high switching frequency of 48MHz / 256 or 187.5kHz. That high switching frequency enables me to use a lower value inductor which massively increases its current rating while pyhsically being the same size. Since the inductor was the limiting element in this design before this significantly increases the power rating of this solar charger. The previous version was (very conservatively) rated at 30 watts only. With the new 22uH inductor this very similar design can handle something like 75 watts. I need a more powerful power supply to do some serious testing but at 35 watts it\u0026rsquo;s getting slightly warm at the most. I\u0026rsquo;ve only done some quick and dirty testing but efficiency at 35 watts is around 97%. That means we are only losing about 1 watt which is the reason the charger barely gets warm.\nThere will likely be another post focussing only on the charger itself so I won\u0026rsquo;t go into more details here. The code regarding the buck is extremely basic and potentially dangerous at this point. I\u0026rsquo;ve killed the bottom mosfet twice due to the not very graceful way the buck turns off. If it turns off while the bottom fet is on, that fet will stay on, effectively shorting the battery to ground. At least that\u0026rsquo;s my explanation at the moment.\nOh yes, there\u0026rsquo;s another issue with the buck as well. With the battery at its output there will always be the battery voltage minus a diode drop at its input where the panel is connected. So when there is no sun, the battery is powering the panel. I\u0026rsquo;ve tried that with a small 30W panel and the panel draws 8mA at 12 volts which several magnitudes more than we are willing to use when the charger is sitting idle. So the next version will have to disconnect the panel when the charger is off. And we will also need to disconnect the voltage divider at the charger\u0026rsquo;s input when we\u0026rsquo;re not measuring the voltage, just like we\u0026rsquo;re doing at the battery.\nSummary\nThere are a lot of features on this board and getting them all to work properly requires quite a bit of work. But most of the heavy lifting has been done so I can now focus on improving the software.\nFirst and foremost I need to work on the way the buck is controlled. First there needs to be a strict and safe procedure how this thing is turned on and off. I\u0026rsquo;m confident that there won\u0026rsquo;t be any blown-up mosfets once that\u0026rsquo;s done. Then I also need to improve the algorithm of how the maximum point of power is tracked. And I also want to implement asynchronous operation at low loads in order to improve efficiency. I\u0026rsquo;ll spend some time on all these issues next, looking at the signals on a scope and trying to improve things.\nBut all-in-all I\u0026rsquo;m quite happy with how how this design has performed so far. Yes, there are some issues but nothing that can\u0026rsquo;t be fixed with relative ease.\nFor those of you interested, the code can be found under downloads on the overview page. In my next post we will take a closer look at the display unit / user interface.\n","date":"28 September 2016","externalUrl":null,"permalink":"/posts/mppt-solar-charger-testing/","section":"posts","summary":" In a previous post I have presented a design for an MPPT Solar Charger. In the mean time I have built a prototype and also wrote some software for it. So today I’ll go through my findings of what works well and what needs to be improved. And yes, there are some flaws in the design…\n","title":"MPPT Solar Charger Testing","type":"posts"},{"content":"","date":"28 September 2016","externalUrl":null,"permalink":"/tags/switch-mode-power-supply/","section":"tags","summary":"","title":"switch-mode-power-supply","type":"tags"},{"content":"","date":"7 September 2016","externalUrl":null,"permalink":"/tags/pic32/","section":"tags","summary":"","title":"pic32","type":"tags"},{"content":"","date":"7 September 2016","externalUrl":null,"permalink":"/tags/pic32mx250/","section":"tags","summary":"","title":"pic32mx250","type":"tags"},{"content":" I last time proudly presented the new RevB board and got a lot of feedback from people who want one, too. As mentioned I have all the components here to ship up to 10 kits but I was reluctant to send anything until I had the chance to do some hardware testing. Not much had changed since the last revision but I don\u0026rsquo;t like taking chances on things like this.\nIn the mean time I managed to do some rudimentary testing and now feel confident to take orders. These tests concern the hardware only. What I said last time about the state of the software still applies. But let me tell you what I\u0026rsquo;ve been able to test so far.\nTests performed so far\nThe PIC32 can be programmed from a PICKit3 via the ICSP header without any issues. Power consumption is as expected. Like the previous version it draws 45mA@12V (programmed) and the other two rails come up with +3.310 and -3.279V, respectively. Also as expected. Regulator stays cool. With the PIC controlling the AXIS, DIRECTION and SIGNAL pins, the transducers receive the 12V signal from the mosfet drivers. HOWEVER: the signals AXIS and DIRECTION are incorrectly labeled both in Eagle as well as on the silk screen. Electrically everything is fine but the names have been confused. The signal from the transducers is properly received (Rec pin on the board) and amplified by a factor of 11 by the first stage of the amplifier (S1 pin on the board). The PIC is able to control the digipot over the internal I2C bus and the second amplifier stage also performs as expected. The zero-crossing detector (ZCD) works. The input to the PIC\u0026rsquo;s ADC (ADC+ and ADC-) look fine, too. HOWEVER: the labeling on the silk screen is wrong. Eagle is correct, it\u0026rsquo;s just the silk screen. Plus should be minus and vice-versa. Again, electrically everything is fine. The PIC can communicate (as a slave) with an Arduino UNO connected to the external I2C bus. Communication over USB to a YAT-terminal under Win 7 works. The following has not been tested so far\nFor my tests I still used the transducers already used previously. I believe the ones I ordered last week are of the same type but I haven\u0026rsquo;t tested them. EEPROM. I haven\u0026rsquo;t tried the newly added memory yet. I have confirmed that it has power and is connected to the same bus as the digipot so I have no reasons to assume there are issues with it. But testing it would require some software first. The external SPI bus has never been tested, neither on the Rev A board nor with the new one. I don\u0026rsquo;t expect any problems but I haven\u0026rsquo;t done any testing so far. Is there anything important that I forgot to mention? In that case just ask. A lot still needs to be done but at this point I\u0026rsquo;m confident that the board has no major flaws and performs much like the prototype. Want to give it a try? I have some kits left for you.\nContinue here to the next post of this series.\n","date":"7 September 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-28-new-hardware-tested/","section":"posts","summary":" I last time proudly presented the new RevB board and got a lot of feedback from people who want one, too. As mentioned I have all the components here to ship up to 10 kits but I was reluctant to send anything until I had the chance to do some hardware testing. Not much had changed since the last revision but I don’t like taking chances on things like this.\n","title":"Ultrasonic Anemometer Part 28: New hardware tested","type":"posts"},{"content":"","date":"7 September 2016","externalUrl":null,"permalink":"/tags/wind-meter/","section":"tags","summary":"","title":"wind-meter","type":"tags"},{"content":" Good news: the boards from dirtypcbs.com have arrived and look great. I also got all the components for the 11 boards. Why 11? I ordered about 10 (they call it a protopack) and was lucky enough to get 11. Thats dirtypcbs.\nLast week I also upgraded my hobbyist Eagle license to a proper Premium LS license which means I can now legally start selling stuff. So I\u0026rsquo;m basically ready to ship the first kits.\nToday I assembled one of the boards and it at least looks great. All the footprints are correct and it was a pleasure to solder. Now what I want to do is to run some tests with it just to make sure it works as intended. I didn\u0026rsquo;t change much since the last version but I want to be sure first.\nAbout the kit\nThere\u0026rsquo;s one thing I want to be absolutely clear about. At this stage of development the wind meter is not yet ready to be deployed. While I think the hardware is final now, a lot more work is needed to get the software ready. So for the time being this kit is intended for people who want to join the development and testing. I\u0026rsquo;ve done most of the low-level, register-fiddling stuff but much remains to be done at a higher level. I know there are a lot of people out there with much more experience in signal processing than me and I\u0026rsquo;m looking forward to work on this challenge together. And a challenge it is. But the PIC32 still has plenty of RAM, Flash and CPU time left to try out new ideas and approaches until we find one that works well.\nThe kit contains the board and all the necessary components. Details can be found in the BOM linked on the overview page. Once assembled it should look precisely like on the photos on this page. But as the name suggests, it comes as a kit, i.e. as components that you have to solder yourself. Most components come in relatively large SOIC packages but there are a few smaller MSOP and SOT-23 packages as well. They can all be soldered with a conventional soldering iron and strain solder just like I\u0026rsquo;ve done today.\nThe microcontroller is not yet programmed so you will need a suitable programmer. Microchip\u0026rsquo;s PICKit3 (USD47.95) is the obvious choice here. This is also what I\u0026rsquo;m using and matches the board\u0026rsquo;s pinout. All the software (MPLAB X IDE and XC32 compiler) are available for download from Microchip free of charge.\nTaking pre-orders now\nI\u0026rsquo;ll start taking pre-orders now but as mentioned I won\u0026rsquo;t ship the kits until I\u0026rsquo;ve done some tests with my own board. Once that\u0026rsquo;s done I\u0026rsquo;ll let you know and if you\u0026rsquo;re still interested by then I\u0026rsquo;ll give you my PayPal details and ship the kits.\nSome have mentioned that they already have some ultrasonic tranducers and/or want to try some specific model so you are free to order your kit with or without the transducers.\nThere\u0026rsquo;s no online shop or anything like that so just use the contact form on the about me page.\nPricing\nNow it starts getting interesting. I\u0026rsquo;ll quote all prices in USD, EUR and CHF. Choose what\u0026rsquo;s cheapest or most convenient for you.\nKit without transducers: USD 70 / EUR 63 / CHF 69 Kit with transducers: USD 95 / EUR 85 / CHF 93 The prices above include worldwide shipping. The kits ship by Swiss Post Priority Mail in a padded envelope. I\u0026rsquo;ve used this service before to locations like Brazil or India and never had problems. However, there are no tracking numbers.\nAny other questions? Just ask.\n","date":"3 September 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-27-ready-to-take-pre-orders/","section":"posts","summary":" Good news: the boards from dirtypcbs.com have arrived and look great. I also got all the components for the 11 boards. Why 11? I ordered about 10 (they call it a protopack) and was lucky enough to get 11. Thats dirtypcbs.\n","title":"Ultrasonic Anemometer Part 27: Ready to take pre-orders","type":"posts"},{"content":"I\u0026rsquo;m currently waiting for the boards for my Ultrasonic Anemometer Rev B to arrive from Hong Kong and this gives me some time to write about the MPPT Solar Charger design that I did quite some time ago. I published a series of posts on a Arduino MPPT Solar Charger Shield and got a lot of encouraging feedback. But that shield was more of a proof-of-concept than a finished product. While it generally performed well it drew way too much current when idle to actually be deployed unless you can count on plenty of sunshine every day.\nAiming for very low power consumption\nWhile I like the Arduino platform I had to admit that it\u0026rsquo;s probably not ideal for a low-power design. Yes there are some things you can do to reduce the 50mA or the Arduino draws but it will never be truely low power. So I designed a stand alone version with plenty of extra features that I hope to draw only a small fraction of the current. I particularly care about the idle current, i.e. the current it pulls when the solar panel is not producing any energy. In winter, the panel might be covered by snow for weeks and you don\u0026rsquo;t want your charger to drain the battery during that time. With this new design I\u0026rsquo;m aiming for an idle current in the tens of microamps. Even if it ends up being 100 microamps that is still 500 times less than an Arduino uses just by itself. And that means it draws less than 1Ah (ampere-hour) per year so you will never drain the battery no matter how little sunshine there is.\nPIC18 series microcontroller\nAt the core of the design is a PIC18F26J50 in a 28 pin SOIC package. It\u0026rsquo;s capable of running at down to 2.15 volts and consumes extremely little power when running at lower clock speeds. And apart from that it features USB so we can have all the benefits of USB without any external components except, of course, a USB socket.\nThe PIC has two crystals at its disposal. A 8MHz crystal which will be boosted up to 32MHz by its internal PLL. That\u0026rsquo;s what the PIC will run on when there is work to do. And then there is a 32.768kHz crystal that will be used to run its real-time clock (RTC). When there is little to no work to do this low-frequency clock will also be used to run the CPU which will greatly reduce power consumption. Power consumption is approximately linear in frequency so this should cut power consumption by a factor of about 1000 compared to full-speed operation.\nSwitch mode power supply\nNow we can run the microcontroller at only a few volts but our power supply is a 12 volt battery. So one of the most straight forward things to do in order to save power was to use a switch mode step-down regulator aka buck.\nI looked around and found the Texas TPS62120. It\u0026rsquo;s only capable of providing 75mA but that\u0026rsquo;s more than enough for us in this case. It works at a switching frequency of 800kHz and only consumes a bit more than 10 microamps with no load at its output.\nIt needs a 18uH inductor as well as some ceramic capacitors to work. The output voltage is set via a pair of resistors acting as a voltage divider. I\u0026rsquo;ve added a n-channel mosfet that allows the PIC to increase the output voltage from 2.2 volts to 3.3 volts when needed. Because while the PIC can run on down to 2.15 volts the display can\u0026rsquo;t. And even the PIC needs 3.0 to 3.6 volts for USB operation.\nSynchronous / asynchronous operation\nThe actual MPPT converter has changed only little. I\u0026rsquo;ve changed the mosfet driver to a MIC4605. Unlike the IR2104 used last time, this model has adaptive dead-time (as opposed to the longish 540ns fixed) and separate inputs for each mosfet. This will allow us to either operate in synchronous (using both mosfets) or asynchronous (only using the upper fet and relying on the diode) mode. Asynchronous operation has a certain efficiency advantage at low power levels so this might come in handy.\nThe MIC4605 consumes quite little quiescent current for a mosfet driver, only 100uA typical. But that\u0026rsquo;s still too much for our purpose. So the PIC can power the whole thing off via a NPN transistor and a p-channel mosfet. That BUCK_ON signal also serves as the supply voltage for the INA213 current sensors already used in the last version. So the entire converter can be powered off and should consume precisely zero current when not in use.\nWhat about the voltage divider necessary to measure the battery voltage? That\u0026rsquo;s been taken care of, too. That divider is interrupted by a (low threshold voltage) n-channel mosfet unless a signal from the PIC turns on the mosfet and closes the circuit.\nPort expansion\nI soon ran out of GPIO pins with that PIC so I had to add an I2C port expander (MCP23008) to gain another 8 I/O pins. I\u0026rsquo;ve also added a PCA9546 I2C switch in order to translate between different voltage levels.\nIt\u0026rsquo;s probably not the most elegant solution and a future version might trade these 3 chips for a higher pin-count PIC. But I had all components here already so that\u0026rsquo;s what I\u0026rsquo;ll use for now.\nPrecise measurements\nIn order to precisely measure input and output voltages and currents there is now a MCP3424 4-channel 18-bit ADC. To be sure, we don\u0026rsquo;t need 18 bits of precision here but we\u0026rsquo;ll trade some of that precision for speed and work with 14 or 16 bits.\nThe ADC has its on-board voltage reference and PGA with gains up to 8. Since it only consumes a maximum of 1uA in standby mode it is always powered on.\nThere are also a total of 3 LMT86 temperature sensors, one on the board and 2 external ones. The external ones are intended to measure the temperature of the panel and battery, respectively. The maximum voltage for a battery is quite dependent on temperature so that\u0026rsquo;s a useful information to have. The inputs from the temperature sensors are measured directly by the PIC. For that purpose there\u0026rsquo;s also a ADR361 2.5V voltage reference.\nMeasuring temperatures requires the board voltage to be high, 3.3 volts nominally. So both the voltage reference and the temperature sensors are only powered on when then VCC_HIGH signal is set.\nUser interface\nTo communicate with a human user there is a 4x20 LCD display that is controlled via I2C in order to save some I/O pins. There are quite a few external components needed to run it at 3.3 volts so it has its own PCB and connects via a 5-pole wire. There is 3.3 volts and ground for power, SCL and SCD for I2C communication and a PWM singal in order to control the display brightness. Because that\u0026rsquo;s a rather universal board I will document that as a separate post.\nAs an input device there\u0026rsquo;s a rotary encoder with push button. Together with the display (and some decent software) that should allow for a pleasant user experience.\nThe inputs from the encoder are debounced in hardware via a 74HC126 that serves a double purpose. With its 3-state outputs it allows us to use the pins that are otherwise used for in-circuit programming of the PIC.\nBoth the rotary encoder (except the push button) and the entire display unit can be powered off when not in use. The push button is always powered on so the user can wake up the user interface at any time by pressing the button. When the user interface is not actively powered on the 74HC126\u0026rsquo;s outputs are in high-impedance mode and the PIC can be programmed without being affected by the rotary encoder.\nData logging\nOne might be interested how much energy has been harvested by the solar charger over the last hours, days, weeks or months. So there\u0026rsquo;s some non-volatile storage as well. The 24FC256 connects via I2C and offers 256kBit of memory. It consumes only 100nA in standby so it can stay powered on at all times.\nFan control\nAs mentioned, there\u0026rsquo;s a temperature sensor on the board. If it gets too hot, a fan can be powered on via the FAN_ON signal controlling an n-channel mosfet.\nOutputs\nThere are 4 power outputs, each controlled by a separate signal from the PIC. There should be some PWM modules left on the PIC so some (two I think) can be PWM controlled. A typical application would be LED lighting which can be controlled and dimmed directly from the solar charger via the rotary encoder. Each output channel has a beefy mosfet of the same type as the MPPT switcher (IPB136N08N3).\nEach has its own FAN3111E mosfet driver. They have a separate input for the reference voltage so the PIC can easily control them when running at only 2.2 volts. The FAN3111 should only draw 5uA (10uA max) when idle but there are 4 of them so they can be powered off (all togeher, not individually) when not in use.\nUSB charging ports\nOne of the first thing one wants to do when there is power is to charge one\u0026rsquo;s cell phone or similar device. So there are two USB charging ports capable of delivering some 2 amps of current at 5 volts in total.\nThey are powered from the 12V batter via a TPS54231 buck converter. So there are a total of 3 buck converters on this board\u0026hellip; It is always connected to the 12V rail but the PIC can turn it off when not in use. The regulator\u0026rsquo;s shutdown current consumption is only 1uA typical (4uA max) so that should be adequate.\nManufacturers of mobile devices have all come up with nasty ways of making their devices incompatible with other manufacturer\u0026rsquo;s chargers. They basically abuse the otherwise unused (for charging purposes) data lines to recognize their own chargers and discriminate against any others. That might mean they won\u0026rsquo;t charge at all or only at a slow rate. So there are two charging ports on this board, one emulating an iPad charger and the other one a popular Samsung scheme. So pretty much any device should be able to charge on at least one of these ports at a reasonable speed.\nSummary\nAs you can see, there\u0026rsquo;s a lot of functionality in this new design just waiting to be unlocked by some clever software. I\u0026rsquo;ve already milled a board and I\u0026rsquo;m looking forward to populating it and bringing it to life. I guess that will be quite a bit of work but I think its well worth it. Thanks to all of you who have kept asking about this project - I very much appreciate all your feedback.\nThere are only Eagle files (including PDFs of the layout and schematics) at this point. They can be downloaded on the overview page. There\u0026rsquo;s now also a prototype. First test results are presented here.\n","date":"28 August 2016","externalUrl":null,"permalink":"/posts/mppt-solar-charger-design/","section":"posts","summary":"I’m currently waiting for the boards for my Ultrasonic Anemometer Rev B to arrive from Hong Kong and this gives me some time to write about the MPPT Solar Charger design that I did quite some time ago. I published a series of posts on a Arduino MPPT Solar Charger Shield and got a lot of encouraging feedback. But that shield was more of a proof-of-concept than a finished product. While it generally performed well it drew way too much current when idle to actually be deployed unless you can count on plenty of sunshine every day.\n","title":"MPPT Solar Charger Design","type":"posts"},{"content":"","date":"20 August 2016","externalUrl":null,"permalink":"/tags/eagle/","section":"tags","summary":"","title":"eagle","type":"tags"},{"content":"","date":"20 August 2016","externalUrl":null,"permalink":"/tags/microcontroller/","section":"tags","summary":"","title":"microcontroller","type":"tags"},{"content":"I recently ordered my first PCB at dirtypcbs.com and the result was promising. So there was nothing stopping me from finalizing the Rev B of my standalone Ultrasonic Anemometer and ordering a protopack. I\u0026rsquo;ve placed the order a few days ago and expect the boards to arrive here in 2 to 3 weeks. This should be good news for all those of you who have been asking for kits and want to contribute to the further developement of this project. I\u0026rsquo;ll build up one or two boards as soon as they get here and do some testing. If everything works as planned I can order some more components and ship some kits soon after that.\nSo today I\u0026rsquo;ll go through the changes I\u0026rsquo;ve made compared to the previous version. All in all the changes are quite minor and only require minimal changes in software. But let\u0026rsquo;s go through them one by one.\nNon-volatile memory\nThis is the biggest change from a functional point of view. The PIC32MX250 doesn\u0026rsquo;t have any EEPROM memory of its own. So in order to be able to save some settings an the like I\u0026rsquo;ve added a Microchip 24AA16 I2C EEPROM providing 16kbit (2kB) of non-volatile memory. That should be more than enough to store any settings and calibrations one might want to make. For example, this gives the user the possibility to calibrate the filter kernels to the transducers used. Of course, the software first needs to make use of that memory but I think it\u0026rsquo;s great to have the possibility to durably store a reasonably large amount of data.\nSupport for 5V I2C communication\nI\u0026rsquo;ve hinted at this in a previous post. On the Rev A board the I2C signals were pulled up to the 3.3 volt rail. This was great as long as one didn\u0026rsquo;t want to interface to a 5V device such as an Arduino. The microcontroller pins are 5V compatible so you want to be able to pull those lines up to 5V whenever you interface to a 5V device. So I\u0026rsquo;ve added a diode to allow the SDA and SCL lines to be pulled higher than 3.3 volts. The I2C reference voltage of 3.3 volts minus a schottky diode drop or about 3.1 volts is accessible from the I2C header at the bottom. So just connect that to the external device\u0026rsquo;s 5V operating voltage and you have a fully compliant 5V I2C bus.\nPhysical layout and connectors\nThere was a rather large 8-pin connector on the last version to connect to the transducers. Now all the connectors along the edges of the board are standard 100-mil headers. This also allowed me to slightly shrink the physical size of the board to 60x70mm.\nThe pinout has also slightly changed. The board is now powered from a header on the right-upper side and all three voltage rails are now externally accessible from a newly added header on the right side. The pin order on the I2C and SPI headers on the bottom side of the board has changed, mainly to accomodate an exteral I2C reference voltage.\nPower supply\nThe tiny (SOT23-5) 3.3 volt linear regulator on the last version worked well but got rather hot when providing close to 50mA from a 12V input voltage. I never had any issues with it at room temperature but decided to be cautious and upgrade to a LD1117 regulator in a much larger SOT223 package. This should be more than sufficient any reasonable ambient temperature..\nMiscellaneous changes\nI changed the digipot used to set the amplifier gain to a Microchip MCP4531. This model only has 128 steps but this is still more than sufficient for its task and it\u0026rsquo;s quite a bit cheaper than the 256-step version.\nI also had to change the crystal because the model previously used became unavailable.\nThat\u0026rsquo;s it for now. I\u0026rsquo;ll let you know as soon as the boards get here.\n","date":"20 August 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-26-rev-b-board-ordered/","section":"posts","summary":"I recently ordered my first PCB at dirtypcbs.com and the result was promising. So there was nothing stopping me from finalizing the Rev B of my standalone Ultrasonic Anemometer and ordering a protopack. I’ve placed the order a few days ago and expect the boards to arrive here in 2 to 3 weeks. This should be good news for all those of you who have been asking for kits and want to contribute to the further developement of this project. I’ll build up one or two boards as soon as they get here and do some testing. If everything works as planned I can order some more components and ship some kits soon after that.\n","title":"Ultrasonic Anemometer Part 26: Rev B Board ordered","type":"posts"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/3-3v/","section":"tags","summary":"","title":"3-3v","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/5v/","section":"tags","summary":"","title":"5v","type":"tags"},{"content":" While most of my microcontroller designs run on 3.3 volts there is still the ocasional 5 volt design. Or I do something with an Arduino. So the need may arise to interface between logic working at different voltage levels. There are several ways of doing this, depending on your needs. Things are relatively simple as long as you know in advance which side is transmitting and which side is receiving. It gets more difficult if the communication is bi-directional or with busses such as I2C that are bi-directional by nature. I did a search on farnell.com and identified two chips that can translate between almost any two voltage levels bi-directionally. The Texas Instruments TXB0106 works with up to 6 CMOS (i.e. actively driven high or low) signals for protocols such as SPI. The PCA9306 (also from TI) is intended for protocols such as I2C that rely on pull-up resistors and where a line must never be actively driven high.\nI ordered a few of these chips and laid out a simple board that contains the two chips together with the pull-up resistors and some decoupling caps. I also added two larger 10uF ceramic capacitors for a generous amount of bulk capacitance. The result is a tiny little board (45x30mm) that can universally be used to translate between almost any two logic voltages for almost any protocol.\nGiving dirtypcbs.com a try\nI can think of a lot of situations where it could be useful. But the main reason for this project was to gain some experience with getting a PCB professionally manufactured by a board house. For several years I have done my own designs but I always milled and drilled them myself. This had pros and cons. I never had to worry about silk screens or solder masks because my boards never had any. On the other hand I suffered from the lack of plated-through holes. Vias were always a pain in the arse because I had to manually solder in pieces of wire to connect the two sides. And it was very difficult if not impossible to put a via below a component which made the layout challenging when working with ICs with many and/or tightly spaced pins.\nSo this simple project seemed perfect to gain some experience in getting a design made by a board house. I chose dirtypcbs.com for their unbeatable prices and read their requirements and restrictions.\nHere are some things to watch out for:\nIf you\u0026rsquo;re working with Eagle you can download a design rule file to automatically check if your design fulfills their requirements. This is great for checking things like minimum via size or trace width/spacing. Make your own gerber files. Yes, you can just send dirtypcbs.com your Eagle files and they will take care of it. But I highly recommend you do it yourself so you know what you\u0026rsquo;re getting. It\u0026rsquo;s not difficult. Just download their .cam file and run it. I modified it somewhat so the file names reflect what the file contains. The file types themselves are rather cryptic. View the gerbers online: There are several online gerber viewers available for free. I particularly like the online viewer at mayhewlabs.com (link no longer available). Just drag and drop the gerber files produced in Eagle and get a beautiful 3D view of your design. Check it carefully to be sure the gerbers represent what you are after. My workflow was rather iterative: I produced the gerbers, looked at them online, changed something in Eagle, produced some new gerbers\u0026hellip; Again and again until I was happy. Control what\u0026rsquo;s on your silk screen. A lot of the silk screen comes directly from the component libraries. Typically, the libraries print the outline, orientation, part name and part value on the silk screen. Unless your layout has a loooot of space between components the silk screen will soon be cluttered with all that information. I recommend you make your own libraries. You can then change the components to only contain the information you want and how you want it. I ended up only putting the outline and orientation of the components on the silk screen. Be aware that the design rule check will not look at your silk screen. You need to make sure your silk screen meets the minimum width of 0.15mm. If you\u0026rsquo;re using vector fonts (as you should) the math is simple. Just multiply the font size by the font ratio to calculate the line width. Example: A 70mils font size with a 10% ratio gives a line width of 7mils or 0.178mm. Make sure your silk screen doesn\u0026rsquo;t overlap any of the pads. Again, he design rule check will not check for this. The board house might avoid printing the silk screen over an exposed pad but I wouldn\u0026rsquo;t bet on it. Eagle seems to do quite a good job with the solder mask without any manual intervention but check the result carefully using the gerber viewer. Pay particular attention to the vias. You generally want your vias to be covered with solder stop - there\u0026rsquo;s no reason to have them exposed. But you might have some vias that you use as pads to access some signal for testing and debugging. Make sure they are not covered by the solder mask. An easy way to distinguish by the two types of vias is by drill size. You can set this parameter under DRC -\u0026gt; Mask -\u0026gt; Limit. It took me quite some time until I had my files ready for manufacturing. Especially given the simple nature of this project. I then ordered a proto-pack from dirtypcbs.com. I went for a industry-standard 1.6mm (they default to 1.2mm) FR4 with a cool-looking (and non-standard) blue solder mask at no extra cost. Some 3 weeks later I found 10 of those nice little boards in my mailbox. They are quite precisely how I expected from the gerber viewer. When you look at them close enough you\u0026rsquo;ll notice that the solder mask and silk screen are not perfectly aligned. The silk screen could also be somewhat cleaner. But don\u0026rsquo;t get me wrong - I\u0026rsquo;m not complaining. The quality is absolutely ok, these are nice little boards. And at this price - I paid 14$ including everything - they are simply amazing. Thank you, dirtypcb.\nSo the board house test was a success but how about the rest? So far I\u0026rsquo;ve only populated a single board. And while I haven\u0026rsquo;t actually used it yet I have performed some tests with a signal generator and a scope.\nPCA9306 for I2C\nSo let\u0026rsquo;s look at the PCA9306\u0026rsquo; performance in some more detail.\nI2C: 5V to 1.8V at 1MHz The chip performs excellently when translating from a high voltage to a lower voltage. In the example above it is translating from 5 volts to 1.8 volts at a very high 1MHz frequency and the wave forms still look nice.\nI2C: 1.8V to 5.0V at 100kHz Translating in the opposite direction (1.8 to 5 volts) everything is fine at 100kHz.\nI2C: 1.8V to 5.0V at 400kHz At 400kHz the output waveform starts to look very jagged, however.\nI2C: 3.3V to 5V at 400kHz But of course, translating from 1.8 to 5 volts is a rather extreme example. In the much more likely scenario of translating from 3.3 to 5 volts the chip performs reasonably well, even at 400kHz. And I2C doesn\u0026rsquo;t usually happen at frequencies higher than that. An Arduino, for example, will usually work at 100kHz. So I\u0026rsquo;m very happy with the performance so far.\nTXB0106 for SPI and the like\nNow let\u0026rsquo;s look at the TXB0106.\n5V to 1.8V at 100kHz Translating from 5V to 1.8V at a modest 100kHz is rather undemanding and the waveforms look nothing but perfect.\n5V to 1.8V at 1MHz Even up at 1MHz this translation works totally fine.\n1.8V to 5V at 100kHz Translating the opposite way, from 1.8V to 5V is more demanding but works very well at 100kHz.\n1.8V to 5V at 1MHz However, at 1Mhz the wave forms start to look pretty uggly. And with a protocol like SPI it is much more likely to actually operate at 1MHz. Note that the glitches might be an artefact of my primitive test setup.\n3.3V to 5V at 1MHz As with the other chip, the output signal starts to better when only translating from 3.3 volts to 5 volts. As mentioned above this is a much more likely application and the chip does a decent job even at 1Mhz.\nSupport this blog - Buy one\nBy the way: If you need one of these universal voltage level translators you can support this blog by ordering one (fully assembled) for USD 20, including worldwide shipping. Just use the contact form on the about me page.\nWith the following link you can download the Eagle files as well as the gerbers. Just click here (file no longer available).\n","date":"15 August 2016","externalUrl":null,"permalink":"/posts/bi-directional-voltage-level-translator-board-house-test/","section":"posts","summary":" While most of my microcontroller designs run on 3.3 volts there is still the ocasional 5 volt design. Or I do something with an Arduino. So the need may arise to interface between logic working at different voltage levels. There are several ways of doing this, depending on your needs. Things are relatively simple as long as you know in advance which side is transmitting and which side is receiving. It gets more difficult if the communication is bi-directional or with busses such as I2C that are bi-directional by nature. I did a search on farnell.com and identified two chips that can translate between almost any two voltage levels bi-directionally. The Texas Instruments TXB0106 works with up to 6 CMOS (i.e. actively driven high or low) signals for protocols such as SPI. The PCA9306 (also from TI) is intended for protocols such as I2C that rely on pull-up resistors and where a line must never be actively driven high.\n","title":"Bi-Directional Voltage Level Translator - Board House Test","type":"posts"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/bidirectional/","section":"tags","summary":"","title":"bidirectional","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/logic-level/","section":"tags","summary":"","title":"logic-level","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/logic-level-converter/","section":"tags","summary":"","title":"logic-level-converter","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/pca9306/","section":"tags","summary":"","title":"pca9306","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/txb0106/","section":"tags","summary":"","title":"txb0106","type":"tags"},{"content":"","date":"15 August 2016","externalUrl":null,"permalink":"/tags/voltage-level-converter/","section":"tags","summary":"","title":"voltage-level-converter","type":"tags"},{"content":"","date":"11 August 2016","externalUrl":null,"permalink":"/tags/arduino-uno/","section":"tags","summary":"","title":"arduino-uno","type":"tags"},{"content":"","date":"11 August 2016","externalUrl":null,"permalink":"/tags/microchip/","section":"tags","summary":"","title":"microchip","type":"tags"},{"content":" It\u0026rsquo;s been a long six weeks since my last post but that doesn\u0026rsquo;t mean that I haven\u0026rsquo;t done anything since. Among other things, I wrote some code to get the I2C interface working and hooked the anemometer up to an Arduino Uno with an LCD display attached. Apart from demonstrating the I2C interface this also nice for testing. For the first time I can see what this thing is measuring in real time without hooking it up to a PC over USB.\nI2C Interfacing\nBut let\u0026rsquo;s look at the setup in some more detail. The PIC has a total of two I2C interfaces and I\u0026rsquo;ve made both of them accessible via the 100mil headers along the edges of the board. One of them is primarily intended for internal purposes like controlling the gain via the I2C digipot. The other one can then be used to interface to some external logic without having to worry about any internal communication. This external I2C interface also comes with 5V compatible pins which means we can interface to 5V devices like an Arduino without any further logic level translation. All we need is a pair of pull-up resistors pulling the SDA and SCL lines up to 5 volts. The Arduino\u0026rsquo;s Atmega328 already has built-in (weak) pull-up resistors so that\u0026rsquo;s not a problem. I didn\u0026rsquo;t think of interfacing to a 5V device when I designed the board and pulled the I2C signals to the anemometer\u0026rsquo;s 3.3V supply. So for proper 5V operation I\u0026rsquo;d have to unsolder the two 10k resistors. Luckily, 3.3 volts is enough to almost certainly be recognized as a logic high by the Arduino so the setup works anyway. But I will think about how to improve this in the next version. I might add a diode to allow the lines to be pulled higher than 3.3 volts.\nThe I2C interface can be configured to act as a master or as a slave device. For now I\u0026rsquo;ve only implemented slave mode so the wind meter behaves just like a I2C temperature sensor or external ADC. The Arduino acts as a master and asks the slave for its latest measurement every 250ms. The anemometer then returns 8 bytes of data consisting of 2 status bytes, north-south wind speed, east-west wind speed (both in mm/s as signed 16-bit integers) and temperature (0.01 degrees centigrade as signed 16-bit integer). It\u0026rsquo;s also possible to send data to the anemometer. That data is then saved to a buffer is otherwise ignored. In a future version of the software one might use this functionality to set the data format to wind speed and wind direction or to change the temperature unit to kelvin or fahrenheit.\nIt would not be difficult to implement master mode as well but so far I haven\u0026rsquo;t done it yet. A lot of code could be copied from the module communicating with the digipot where the PIC acts as a master. The anemometer could then push data to an external device whenever a new measurement becomes available. Definitely something I\u0026rsquo;d like to implement at some point but no priority right now.\nBug fixes\nI\u0026rsquo;ve found (and fixed) a number of bugs while testing. Among other things, the axis and direction signals were not always properly set and so the measurements did not always correspond to the direction they should. So take with a grain of salt some of the test results reported earlier. Some of them were almost a bit too good to be true and this bug might have been the cause. I suspect I might have compared two successive measurements in the same direction when I actually wanted to compare measurements taken in opposite directions. But I\u0026rsquo;ve fixed the code and I\u0026rsquo;m confident that now all the directions are set and reported correctly.\nIndividual filter kernels\nAs can easily be seen from the scope screenshots above, the shape of the received signal varies quite a bit from transducer to transducer. Note that the amplifier gain is dynamically adjusted to make sure the peak amplitude is the same for all of them but the shape still differs quite substantially. So the kernel for the matched filter has to be some compromise to suit them all. I have now modified the software to use four individual kernels, one for each direction. This gives us the flexibility to calibrate the kernel to each transducer and so get more reliable results for the absolute phase.\nRevised board\nMy main priority at the moment is to complete the revised version of the board and to order a small series of boards. Until recently I never ordered a board from a professional board house so there are quite a few things for me to learn. For the first time I have to worry about silk screen, for example. Or solder mask. On the other hand, a board house can do a lot of things I can\u0026rsquo;t. Plated-through holes for example. Or smaller vias. Or place vias under an IC. This means a lot more flexibility in my layout that I first have to get used to. But I\u0026rsquo;m making progress. I got a simple design of mine produced by dirtypcbs.com and got a batch of very usable boards. More on that in a future post.\nWind tunnel\nIf you\u0026rsquo;ve been following this project for a long time already you might remember my simplistic wind tunnel made of a 120mm brushless fan and a cardboard tube. I got a number of suggestions from you guys on how to build something better than that and I also found some useful material online. So I\u0026rsquo;ve started to build a much improved wind tunnel that will hopefully allow me to perform more meaningful tests. That\u0026rsquo;s also for one or more future posts.\nSoftware ideas\nI\u0026rsquo;ve also played around with some software ideas that I believe to have potential. One is dynamically adjusting the frequency. I\u0026rsquo;m now only working at the transducer\u0026rsquo;s nominal frequency of 40kHz. But the individual transducer\u0026rsquo;s resonance frequency might be somewhat different and might change with temperature or age. So I might try to adjust the frequency dynamically using some perturbation and observation algorithm.\nI\u0026rsquo;m also thinking about measuring at two slightly different frequencies (say, 39.5kHz and 40.5kHz) and using the two phase shifts to figure out the absolute time-of-flight. I\u0026rsquo;ve given it a try and was not very successful but I haven\u0026rsquo;t given up on that idea yet.\nSo that\u0026rsquo;s it for now. The code for the Ultrasonic Anemometer as well as the Arduino are available for download. See the overview page for the respective links.\n","date":"11 August 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-25-i2c-interfacing-and-more/","section":"posts","summary":" It’s been a long six weeks since my last post but that doesn’t mean that I haven’t done anything since. Among other things, I wrote some code to get the I2C interface working and hooked the anemometer up to an Arduino Uno with an LCD display attached. Apart from demonstrating the I2C interface this also nice for testing. For the first time I can see what this thing is measuring in real time without hooking it up to a PC over USB.\n","title":"Ultrasonic Anemometer Part 25: I2C Interfacing and more","type":"posts"},{"content":"","date":"26 June 2016","externalUrl":null,"permalink":"/tags/digipot/","section":"tags","summary":"","title":"digipot","type":"tags"},{"content":"","date":"26 June 2016","externalUrl":null,"permalink":"/tags/gain/","section":"tags","summary":"","title":"gain","type":"tags"},{"content":"","date":"26 June 2016","externalUrl":null,"permalink":"/tags/isr/","section":"tags","summary":"","title":"isr","type":"tags"},{"content":"It\u0026rsquo;s been almost three weeks since my last post and some further progress has been made. I\u0026rsquo;ve upgraded the microcontroller and can now control the gain of the second amplifier stage in software. But let\u0026rsquo;s look at the changes in some more detail.\nNew microcontroller: PIC32MX250\nI mentioned last time that I was running out of code space, i.e. flash memory on the PIC32MC220. That particular model has only 32k of flash and I\u0026rsquo;m using the free version of the XC32 compiler. That free version only performs limited amounts of optimization and therefore produces rather large and slow code compared to the standard and professional version. But the other two are rather costly (around USD 500 and 1000, respectively) and are not really an option here. And at least so far I\u0026rsquo;ve always had all the speed I needed so the only issue was flash memory.\nSo the straight forward solution was to upgrade the microcontroller to an otherwise identical model with more memory. The 250 I\u0026rsquo;m using now has four times more of both flash (now 128k) and ram (now 32k). I unsoldered the old chip using a hot air gun and soldered in a PIC32MX250 in its place. Now we have all the flash we need to continue our journey.\nGetting I2C to work\nMy design uses a dual op amp for the necessary amplification of the received signal. The first stage is ground-referenced and uses a simple resistive divider to set the gain (currently set at 11).\nThe second stage is biased to 1.65V (i.e. half way between ground and 3.3 volts) and has its gain controlled by a I2C digipot. The idea is to have the PIC control the digipot so it can adjust the gain as needed to compensate for any effect that might change the amplitude of the received signal.\nSo in order to control our digipot we first need to get the I2C interface working on the PIC. There are two (identical) I2C peripherals on the PIC32MX2xx and this design uses one of them (#2) exclusively to communicate to the digipot. The other one (#1) is then available to interface to the outside world.\nI\u0026rsquo;ve written a set of simple functions to use the I2C interface. So far I\u0026rsquo;ve only implemented master transmit mode since that\u0026rsquo;s the only thing we need here.\nvoid app_i2c_internal_init(void); bool app_i2c_internal_write(uint8_t address, uint8_t *data, uint8_t length); void app_i2c_internal_writeDigipot(uint8_t value); The functions are entirely non-blocking so they can be called from within the interrupt service routines that do the measurement.\nFixing a design bug\nUnfortunately, I made a mistake in the schematic when I referenced the feedback loop of the second op amp stage to ground instead of the mentioned 1.65 volts. Now let\u0026rsquo;s look at what that did to the signal. First, below is the signal with the digipot at 0 (of 256). The gain is set to one and all is well.\nBut at a setting of 64, some clipping starts to occur as shown below.\nWith the gain turned up to 4 with a digipot setting of 192 things get really uggly with a completely unrecognizable output signal.\nI was extremely lucky that the correct signal was available right next to the pin where I needed it so all I had to do was to cut the ground connection with a carving knife and to connect the correct signal using a tiny bit of wire. The change is hardly visible on the photo below. Can you spot it? It\u0026rsquo;s almost at the center of the photo at pin 5 (bottom right) of the small 8-pin IC. It now connects to the 10k resistor at the bottom instead of the ground plane on its right.\nControlling the gain in software\nWith that error fixed we can now set the gain as we please. Here some examples. Yellow is the (unamplified) input signal whereas green is the output of the (fixed) first amplifier stage. The purple signal is calculated as the difference between the DAC+ and DAC- signals. Those two signals is what we feed into the PIC to be measured.\nWith the gain at 1 (digipot at 0) we get a about 2.6 volts peak-peak. A bit little but sufficient.\nThis is probably about what we want. Digipot at 50 resulting in a peak-peak amplitude of a bit above 3 volts.\nNeedless to say that we can jerk the gain up far more than that if we want. Below is an example where a gain of 4 results in a seriously clipped signal.\nNow let\u0026rsquo;s look a a situation where such a high gain might actually be useful. In the example below I\u0026rsquo;ve lowered the input voltage to only 5 volts. As a result the received signal is only 90mV in amplitude instead of the 220mV seen above. That\u0026rsquo;s easily compensated with a bit of help from our digipot. With a setting of 170 we get a nice, clean 3 volt output signal.\nCalculating the necessary gain\nFor the examples above I\u0026rsquo;ve explicitly set the gain in the code. But what we really want is to have the software calculate and set the necessary gain automatically.\nSo I\u0026rsquo;ve implemented a simple algorithm to do so. I set some target value for the peak-to-peak amplitude of the signal measured by the DAC. Knowing the amplitude and digipot setting of the last measurement I calculate the optimal gain and digipot setting for the next measurement.\nAbove is the signal without this automatic gain setting in place (gain=1). As you can see, the peak-to-peak amplitudes vary quite a bit between transducer pairs. So the gain calculations, too, work on a transducer pair basis. Each direction gets its own setting to compensate for different transducer sensitivities.\nBelow is a screenshot of the result. Notice how now all transducer pairs have identical (and somewhat larger) amplitudes.\nThat\u0026rsquo;s it for today. Click here for my next post.\n","date":"26 June 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-24-new-microcontroller-and-software-controlled-gain/","section":"posts","summary":"It’s been almost three weeks since my last post and some further progress has been made. I’ve upgraded the microcontroller and can now control the gain of the second amplifier stage in software. But let’s look at the changes in some more detail.\n","title":"Ultrasonic Anemometer Part 24: New Microcontroller and Software Controlled Gain","type":"posts"},{"content":"","date":"6 June 2016","externalUrl":null,"permalink":"/tags/pic32mx220/","section":"tags","summary":"","title":"pic32mx220","type":"tags"},{"content":"In my last post I was happy to report that I managed to get the USB interface to work. This interface has since proved to be extremely valuable in software development and testing. While the device is taking measurements you can look at the results (or intermediate results) at your PC in real time. You can even log large amounts of data to a .csv file and inspect the results in Excel.\nBut let\u0026rsquo;s look at the developements in a bit more detail. Last time the device was sending pulses and capturing some of the resulting zero-crossings but not much more than that. And in a not very structured way.\nMeasuring amplitude\nNow it\u0026rsquo;s not only capturing the times when the zero-crossings occur but also measures the amplitude of the half-waves in between. In order to do that an interrupt is generated at every zero-crossing capture. Inside that interrupt service routine time of the zero-crossing is saved (as previously) and the ADC is started. In order to measure the amplitude at its maximum (or minimum in case of a negative half-wave), the ADC first samples the input for a 6.25 microseconds (which corresponds to a quarter-wave at 40kHz). I\u0026rsquo;ve chosen the sampling period slightly shorter to compensate for the time from when the zero-crossing occured unil the ADC is started. After the sampling period the internal sample-and-hold amplifier switches from sample to hold and the actual analog-to-digital conversion takes place.\nThe PIC\u0026rsquo;s datasheet advertises a maximum sampling rate of 1 million samples per second. Beware, though, that this requires separate Vref+ and Vref- connections and doesn\u0026rsquo;t work in differential mode anyway. In my configuration without separate analog references and differential measurements the maximum sampling rate drops to 400k samples per second. And the reported conversion time doesn\u0026rsquo;t include the sampling time yet. I wasn\u0026rsquo;t aware of that but luckily the PIC\u0026rsquo;s ADC is still more than fast enough for what I\u0026rsquo;m doing here.\nFinding the absolute phase\nCapturing the zero-crossings is relatively easy and the results are very precise. But there\u0026rsquo;s a challenge: there are hundreds of zero crossings for each burst of pulses sent. How do you know which zero-crossings to use?\nThe Arduino-based anemometer used an analog envelope detector to solve this problem. After averaging plenty of samples this works most of the time. But even after many attempts to tweek the analog circuit the envelope detector approach was never as reliable as I wanted it to be.\nMy standalone anemometer has an entirely different approach. Being able to digitally measure the amplitude of each half-wave we can tackle the challenge in software. We have a series of measurements and we have an idea of that the signal we are looking for looks like. Looking the scope screenshot below you could easily and reliably determine where the maximum amplitude occurs. That\u0026rsquo;s what we need to teach the software to do.\nOne could, of course, just loop through the all the amplitudes and find the maximum. But there are a lot of similar amplitudes and so any noise would make the result unreliable.\nI did a bit of reading on digital signal processing (DSP) and realized that this is a classic DSP problem. The solution is a matched filter. You take the signal you are looking for (also known as kernel or template) and multiply it sample by sample with the captured signal and sum up the results. Do that for every possible (or reasonable) overlap of signal and kernel and find the position where the result reaches its maximum.\nIf you\u0026rsquo;re new to the subject (like I am), Steven W. Smith\u0026rsquo;s Digital Signal Processing is a great place to start. It\u0026rsquo;s even available online for free at dspguide.com. The method is also referred as convolution or correlation depending on who you ask. This wikipedia article gives a nice introduction to the subject.\nImplementing the matched filter\nI\u0026rsquo;ve parameterized the software to capture 34 zero crossings as well as the n=33 amplitudes in between them. The kernel consists of k=17 data points with a peak in the middle.\nThere are n-k+1=17 possibilities to entirely overlap the kernel with the signal. We can skip all the odd numbers where a negative kernel value would be multiplied with a positive sample value and vice versa. This leaves us with 9 possible positions to chose from.\nFor each position we need to do 17 multiplications and 16 additions. And we need to do that for every single measurement, i.e. 512 times per second. That sounds like a lot of work and it probably is. Luckily, since this is a very common DSP task, microcontrollers like the PIC32 have a special instruction for this. It\u0026rsquo;s called MAC - Multiply Accumulate and executes in a single clock cycle. The result is just amazing. The corresponding ISR takes less than 30 microseconds, including some housekeeping tasks as can be seen in the screenshot below.\nOnce the maximum amplitude is found, the 16 zero-crossings around it (i.e. the 8 before and the 8 after) are summed up and the sum is saved as the result of that measurement.\nAveraging measurements\nThe goal is to report wind speed and temperature four times per second. Since there are 512 measurements per second we can use up to 128 individual measurements (32 in each direction) to do our calculations.\nSo we have plenty of data to identify and exclude outliers and do some averaging of the remaining samples. Robust statistics is the key word here, click here for the corresponding wikipedia article.\nFor now I\u0026rsquo;m doing something reasonably simple: First the 32 results per direction are sorted. The 12 lowest and 12 highest results are ignored and only the 8 results in the middle are summed up.\nThis might seem wasteful but it makes the average very robust against outliers and still results in 16 x 8 = 128 zero-crossings being averaged. The resolution of each zero-crossing is equal to 1 / 48MHz or about 20.83 nanoseconds. Summing up 128 of them gives us a resolution of far below a nanosecond. Beware however that resolution doesn not imply accuracy.\nAs a last step, the resulting sum is multiplied with 125 and then divided by 768 to make the unit 1 nanosecond. So every 250 milliseconds we finally have 4 time-of-flight measurements with a resolution of 1 nanosecond. That\u0026rsquo;s what we will use to calculate the winds speed as well as wind direction and temperature.\nThis sorting and averaging step is a bit more costly in terms of computation time. It takes around 600 microseconds to complete (see below). But unlike the convolution, it only has to be performed 4 times per second so this is more than fine.\nCalculating wind speed\nWe are finally in a position to calculate the actual wind speed. There are various ways of doing this. For now I\u0026rsquo;ve just done the simple approach of taking the difference in time-of-flight, assuming room temperature and solving for wind speed. This means solving a quadratic equation for which I have resorted to floating point math and using \u0026lt;math.h\u0026gt; for the square root function.\nI don\u0026rsquo;t have my wind tunnel any more so doing any testing was difficult. But one thing was soon obvious: at zero wind speed, the time-of-flight measurements match extremely well and are extrordinary stable from measurement to measurement. Also, looking at the intermediate results (i.e. the 128 single measurements before averaging) shows that there are basically no outliers present. I could randomly pick a measurement and still get a very reasonable value.\nSomething seems to be systematically wrong with the first of the 128 measurements but I haven\u0026rsquo;t had time to look into this. Otherwise, the results are impressively stable. And I\u0026rsquo;m only using a relatively primitive kernel for the matched filter.\nUSB data logging\nAs I\u0026rsquo;ve mentioned at the beginning, the USB interface lets me do some serious data logging even at this early stage of development. Here\u0026rsquo;s a list of what I can do by sending a character to the device from a USB terminal.\n\u0026lsquo;Z\u0026rsquo;: Get all the 34 zero-crossings of a single measurement \u0026lsquo;A\u0026rsquo;: Get all 33 amplitudes of a single measurement \u0026lsquo;F\u0026rsquo;: Get a full single measurement, i.e. 34 zero-crossings plus 33 amplitudes \u0026lsquo;T\u0026rsquo;: Get all the 4 x 32 = 128 time-of-flights for a measurement series \u0026lsquo;R\u0026rsquo;: Get the 4 averaged time-of-flights as well as wind speed and temperature Some versions of these commands also let you specify the direction you\u0026rsquo;re interested in as well as how many sets of data you want to receive. This makes it easy to log large amounts of data that you can use to test possible algorithms on your PC before you implement them on the PIC.\nNext steps\nThe next step is to get the I2C digipot working so I can control the amplification in software. My idea is to aim for a maximum amplitude of around 3 volts independent of wind speed and so on.\nThere\u0026rsquo;s also plenty of work to do to improve the algorithm that calculates wind speed and temperature. And then I also have to implement the I2C and SPI interfaces that let the anemometer communicate to other embedded devices like an Arduino or Raspberry Pi.\nHaving used floating point math and \u0026lt;math.h\u0026gt; I\u0026rsquo;m also running out of flash memory. I\u0026rsquo;m currently using 93% of flash (32kB total) and 52% of ram (8kB total). There will be a slightly revised board (Rev B) that uses a PIC32MX250 which is identical to the MX220 used here but has four times as much flash and ram.\nThat\u0026rsquo;s it for today. On the overview page you find the software at the stage of developement just described as well as some examples of logged data (all at zero wind speed) as .csv files.\nThe next post on this project is here: Part 24.\n","date":"6 June 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-23-first-successful-measurements/","section":"posts","summary":"In my last post I was happy to report that I managed to get the USB interface to work. This interface has since proved to be extremely valuable in software development and testing. While the device is taking measurements you can look at the results (or intermediate results) at your PC in real time. You can even log large amounts of data to a .csv file and inspect the results in Excel.\n","title":"Ultrasonic Anemometer Part 23: First successful measurements","type":"posts"},{"content":"","date":"6 June 2016","externalUrl":null,"permalink":"/tags/zero-crossing-detector/","section":"tags","summary":"","title":"zero-crossing-detector","type":"tags"},{"content":"","date":"28 May 2016","externalUrl":null,"permalink":"/tags/mplab/","section":"tags","summary":"","title":"mplab","type":"tags"},{"content":"","date":"28 May 2016","externalUrl":null,"permalink":"/tags/mplab-harmony/","section":"tags","summary":"","title":"mplab-harmony","type":"tags"},{"content":" Last time I showed you the nice new hardware of the new standalone ultrasonic anemometer. But at that time I had hardly any software written for it so I couldn\u0026rsquo;t do much with its 32 bit microcontroller. So the last two or three weeks I spend lots of time writing code that I\u0026rsquo;d like to share with you today.\nAs I mentioned last time I worried most about getting the USB working properly. All the bit-fiddling with timers, PWM modules, input capture modules and the like can be time consuming and at time even frustrating. But I have all the confidence that I finally get what I aimed for. It might take a few nights digging through data sheets but in the end it will almost definitely work.\nNow with USB I don\u0026rsquo;t quite have that level of confidence. The USB specification is quite overwhelming and there are almost countless registers to properly set and USB descriptors to specify. Without some sample code I\u0026rsquo;m pretty much lost I must admit.\nOutdated Application Notes\nSo I was happy to see that Microchip has published a number of application notes and accompanying software. A handful of .h and .c files that you can include in your project, change some settings to suit your particular application and you\u0026rsquo;re ready to go. At least that\u0026rsquo;s what I thought.\nAll those application notes were published around 2008 and the code they are referring to is nowhere to be found nowadays. Aparently, Microchip has been quite pushy trying to get their PIC32 customers migrate to their new library or rather framework called Harmony. MPLAB no longer even includes the the PLIB peripheral library everyone has been using for decades. Microchip has depreciated it and while you can still download it they make very clear that Harmony is the library of the future.\nOn the road with MPLAB Harmony\nSo faced with few other alternatives I turned to the aforementioned Harmony library. It\u0026rsquo;s many hundred megabytes to download and takes up almost two gigabytes of disk space. It integrates nicely into MPLAB X and so I created a first project. You can graphically configure the clock and pin settings so I did that. Clicked on \u0026lsquo;create code\u0026rsquo; and was nothing less than shocked by the code I got. Around a dozend source files scattered around in a dozend deeply nested folders and subfolders. And that was not yet it. Those files referenced dozends more files that came as part of harmony. It took me quite a while to just more or less figure out what the project was doing. And it didn\u0026rsquo;t do anything yet except setting some clock and port settings. Just a nightmare.\nBut I felt I had few other options so I continued with harmony anyway. And after a few hours I had an almost working USB device. It enumerated just fine but I couldn\u0026rsquo;t send any data from or to it. It took me more than a week to finally get it working. In the end it was just a single character: a 1 instead of a 2 in one of the configuration files. But until then I had spent a lot of time with that harmony code and was forced to read through a lot of its documentation which is worth thousands uppon thousands of pages of PDFs.\nSo USB was finally working and I had acquired some rudimentary understanding of MPLAB Harmony. I still hated the whole framework but I thought that I now understand it well enough to change the code to suit my taste. So I spent another few nights trying to do that until it dawned on me that this is leading nowhere. Fortunately, by that time I had read and learned some more about Harmony and was willing to give it another try working with it as opposed to against it. So for the last week or so I was doing that.\nAnd while I still don\u0026rsquo;t love everyting about it I now feel comfortable working with that library. I\u0026rsquo;ve tried to follow its conventions and recommendations even where they didn\u0026rsquo;t make too much sense to me. I think this will make it much easier for others to work with my code and chances are that the conventions and recommendations will start to make more sense as I get more familiar with the framework. And its nice to know that I can integrate another module or migrate to another microcontroller without having to re-invent everything.\nThat was a long introduction but after all that pain the last few weeks I just had to write that down. Now to business.\nUSB\nThe anemometer inplements the USB HID (human interface device) class. While mainly aimed at devices such as mice and keyboards, this USB device sees a lot of use in applications that have nothing to do with human interaction. You can transfer up to 64 kbytes of data (64 bytes every millisecond) in each direction with guaranteed latency and that\u0026rsquo;s plenty for many applications. That data can be anything and in any format you like. And the good thing is that you don\u0026rsquo;t need to write your own drivers. You can free-ride on the device drivers that came with the operating system just like you don\u0026rsquo;t need to install a driver when you attach a new keyboard to your computer.\nI\u0026rsquo;ve written a bit of code on top of the Harmony library to provide the main application with a simple to use interface. It nicely encapsulates the the USB logic and data and adds a bit of buffering functionality on top of that. It\u0026rsquo;s just two files: app_usb.h and app_usb.c in the app_usb subfolder. You can basically include them in your project and they handle all the USB stuff for you.\nOnce initialized, the necessary code runns inside an interrupt service routine (ISR) so the main application has nothing to worry about. All the USB data including the data buffers are private to the app_usb.c file. The app_usb.h defines just 8 simple, non-blocking functions:\nvoid app_usb_init(void); bool app_usb_isReady(void); uint8_t* app_usb_getReceiveBuffer(void); uint8_t app_usb_getReceiveBufferCount(void); uint8_t* app_usb_getTransmitBuffer(void); uint8_t app_usb_getTransmitBufferCount(void); void app_usb_freeReceiveBuffer(void); void app_usb_sendTransmitBuffer(void); At system initialization you call app_usb_init(). But you can\u0026rsquo;t expect to have an USB connection. You need to check app_usb_isReady() every time. You never know if there is a USB cable plugged in and even if you had a connection that cable might be unplugged at any time. The module handles all that hot plugging/unplugging gracefully.\nThe module implements a circular buffer for both received packages (aka frames) and packages to be sent. Each package is 64 bytes in size and the ring buffers can be set at compile time but must be a power of 2. Currently the receive buffer consists of 4 frames and the transmit buffer of 8 frames.\nThe app_usb_getReceiveBufferCount() informs the caller how many new USB frames have been received if any. app_usb_getReceiveBuffer() then returns a handle to the first received frame. FIFO - First In First Out. Once the frame is no longer needed the application calls app_usb_freeReceiveBuffer() and the buffer can be re-used.\nSending data works similarly simple. app_usb_getTransmitBufferCount() returns the number of transmit buffers currently in use. If this number is smaller than then number of buffers then more data transmissions can be scheduled. Get a handle to then next buffer by calling app_usb_getTransmitBuffer(), write the data to be sent to the buffer and then call app_usb_sendTransmitBuffer().\nTaking measurements\nThis way the main application can focus on more interesting tasks such as measuring wind speed and direction. The first task for doing so is sending some pulses.\nIf you\u0026rsquo;ve alredy followed this project for a while you are probably familiar with the kind of screenshot above. Bursts of a PWM signal at 40kHz (SIGNAL, red) are sent trough ultrasonic transducers. Note that the signal is now active-low (i.e. inverted) since the mosfet drivers used to drive the transducers are themselfs inverting.\nAs before, the DIRECTION and AXIS signal determine which transducer is transmitting and receving. The SCLK and MOSI signals are just used for debugging purposes for now. They indicate when an ISR is running which helps a lot since in this example ALL the code is running inside an ISR.\nAs you can see above, the AXIS and DIRECTION signals are set a few microseconds before we start sending pulses. The first edge of the burst occurs when the 32 bit-timer (consisting of the 16-bit timers TMR2 and TMR3) is cleared. This is the point in time all our measurements are referenced to. The timer runs at the full CPU clock of 48Mhz so the resolution is about 20.8 nanoseconds.\nOutput Compare module 2 (OC2) handles the PWM pulses. Currently each burst consists of 12 pulses. At 48MHz a full wave equals 1200 clock cycles as opposed to 400 on the Arduino previously used. Note that the frequency of the pulses is precisely 40kHz as expected and that very little time is spend in ISRs despite the unoptimized C code.\nThe timer overflows precisely 512 times per second so each measurement takes a little less than 2 milliseconds. Output compare module 1 (OC1) can be used to generate an interrupt at any time during that interval. Currently it does three things: It takes care of the AXIS and DIRECTION signals which are set just shortly before the timer overflows. It also triggers the measurements of the zero-crossings and cancels them if they don\u0026rsquo;t complete withing reasonable time.\nThe input capture module 4 (IC4) captures the zero-crossings of the received and amplified signal. The board contains a high speed comparator to detect these events so the microcontroller only needs to measure the precise time whn they occur. The IC4 module has an internal buffer so we don\u0026rsquo;t need to generate an interrupt after every capture. I\u0026rsquo;ve currently set things up so that an interrupt occurs after 4 values have been captured up to a total of 32 measurements.\nCommicating the results over USB\nIn order to find the wind speed and direction we need to somehow identify the peak in the received signal which is where the ADC comes in. But I think this is enough for now and I instead show you how the measurements taken so far can be sent to a PC via USB.\nThe board doesn\u0026rsquo;t have any display or anything to communicate with a human. There\u0026rsquo;s not even a status LED we could blink. That would have been nice but there are just not enough I/O pins unfortunately. So connecting the board to a PC via USB is a straight-forward way of communicating with this device. Actually, USB will be the main testing and debugging tool during development. The in-circuit debugger isn\u0026rsquo;t very useful in this application since the measurements have to happen in real time. Setting breakpoints will just mess things up.That\u0026rsquo;s why I insisted to get USB working first.\nI\u0026rsquo;ve downloaded a simple terminal called YAT (yet another termial) that allows me to easily talk to the anemometer board. The anemometer looks at the first character in any message sent from the host and then decides what to do. So far I\u0026rsquo;ve implemented:\n\u0026lsquo;T\u0026rsquo;: Return the current value of the 32-bit timer \u0026lsquo;Z\u0026rsquo;: Return axis (0/1), direction(0/1), measurement count (0-31) values as well as the results of the first 9 zero-crossing measurements Anything else: Echo back the received string Here\u0026rsquo;s what my chat with the Standalone Ultrasonic Anemomete looked like.\nOf course, the measurement is far from complete at this stage but I think this is a nice foundation to build uppon. The code is quite clean for this early stage of development and being able to communicate with the device in real-time over USB is really a great advantage.\nThe software can be downloaded on the project over view page and as always I appreciate any feedback.\nThe next post on this project can be found here.\n","date":"28 May 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-22-usb-up-and-running/","section":"posts","summary":" Last time I showed you the nice new hardware of the new standalone ultrasonic anemometer. But at that time I had hardly any software written for it so I couldn’t do much with its 32 bit microcontroller. So the last two or three weeks I spend lots of time writing code that I’d like to share with you today.\n","title":"Ultrasonic Anemometer Part 22: USB up and running","type":"posts"},{"content":"Last time I went through the design of my new standalone anemometer. Now it\u0026rsquo;s time to build this thing and see if it works as planned.\nAfter I fried a couple of chips on my driver circuit testing board due to a wrong chip in the power supply I was a bit more careful this time and built up the board step by step.\nOnly after I confirmed that the power supply was ok I dared to solder some more.\nThe next step was to add the PIC32 with the crystal, the programming header and all the caps they need. This is a chip family that I\u0026rsquo;ve never used before so I wanted to first see if I can program it. All went well and I managed to get it to run on the crystal\u0026rsquo;s 8MHz boosted up to 40MHz by an internal PLL. So I was ready for the rest.\nI wrote some very basic software and confirmed that at least the basics were working ok. I was able to send and receive pulses, the pulses got amplified, the zero-crossing detector worked and so forth.\nAs mentioned, I\u0026rsquo;m entirely new to the PIC32 microcontroller series. There are a lot of similarities to the PIC16 and PIC18 series that I\u0026rsquo;m quite familiar with but still it\u0026rsquo;s always a challenge to work with a new family of chips and the tools that come with it. I took me the better part of an afternoon to master the vectored interrupts with the different priority levels and so on.\nDriver circuit (front) and standalone anemometer (back) side by side. By the way, with this project I\u0026rsquo;m using the free MPLAB X IDE with the also free XC32 C compiler from Microchip. So anyone is able to write, modify or compile code for this thing with free software. At least at the moment you need a programmer to actually burn the chip. But the PICkit3 only costs around 50 dollars and my idea is to write a USB bootloader so that any user can modify the software of a pre-programmed board.\nSo now comes what I think might be the hardest part: Getting the USB to work. I\u0026rsquo;ve spent quite a few hours so far but haven\u0026rsquo;t managed to get it working properly yet. If anyone has experience with this kind of software development - Let me know, any help is highly appreciated.\nIt now works: Click here to view it.\n","date":"14 May 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-21-standalone-anemometer-hardware/","section":"posts","summary":"Last time I went through the design of my new standalone anemometer. Now it’s time to build this thing and see if it works as planned.\nAfter I fried a couple of chips on my driver circuit testing board due to a wrong chip in the power supply I was a bit more careful this time and built up the board step by step.\n","title":"Ultrasonic Anemometer Part 21: Standalone Anemometer Hardware","type":"posts"},{"content":"Last time I outlined my reasons to \u0026lsquo;go digital\u0026rsquo; by adding a powerful on-board microcontroller and designing a standalone wind meter.\nIn the weeks that followed that decision I tried to find a suitable microcontroller and to design a prototype. Today I\u0026rsquo;ll show you the result of that work.\nI looked at various series of microcontrollers from different manufacturers and finally decided to go for the Microchip PIC32 series. It offers everything I could possibly ask for: 32 bit architecture, inexpensive, vectored interrupts, integer division, any interface you want (depending on the model of course) , available in large, low pin count, hobbyist friendly packages and so on.\nAs you can see above, the model chosen for my prototype is a PIC32MX220. This is low to mid-end representative of this series but even so the specs are quite impressive. CPU clock up to 50MHz, one instruction per clock cycle, full-speed USB 2.0, 32kB flash, 8kB RAM and all of that in a SOIC28 package at a price of CHF 3.58 in single quantities.\nAfter having chosen a chip the next task was to come up with an actual design. I took my anemometer driver design and tried to integrated the new PIC32. That driver circuit had performed extraordinary well so I changed very little. I left away the RELEASE signal since my tests had shown it to be unnecessary. I also replaced the LM5111-1M mosfet drivers by LM5111-2M. The difference is that the 2M is inverting while the 1M is not. The reason for changing this is because the 2M is available at a significantly lower price of CHF 1.35 vs CHF 2.25. Not a big deal if you just build a single prototype but I thought it might be smart to change this anyway. This also required some resistors to be changed from pull-downs to pull-ups. Except these details everything stayed the same with the drive circuit.\nI also had to re-design the power supply since the PIC needs a 3.3 volt rail as opposed to 5 volts in the driver test circuit. Since I had to re-design it anyway I also downsized the power supply somewhat. I\u0026rsquo;ve otherwise resisted all temptations to use smaller components but the power supply was just a bit too big with the two SOIC8 chips and four size C tantalum caps.\nThe prototype now uses an MCP1755 linear 3.3V regulator in a SOT23-5 package with a 33uF size B tantalum cap at its input and a 10uF 0805 size ceramic cap at the output. A TCM829 (also in a SOT23-5 package) and two more 10uF caps produce the -3.3 volts output. So there is a total of three supply rails: +12V, +3.3V and -3.3V.\nA major challenge was to make do with the very limited number of I/O pins on the PIC. 28 pins seem like a lot for the task at hand but plenty of them are already used for things like supply voltages and the like.\nIn the end I managed to still get three independent interfaces to the outside world: USB 2.0, I2C and SPI. All these interfaces as well as just about any other signal of interest is easily accessible from one of the numerous 100mil headers along the edges of the board.\nThe amplifier still uses a LMC6482 dual op amp , now running on a+/- 3.3 volt supply. The first stage amplifies the ground-referenced input signal by a fixed factor (currently 11 but this might change). The output signal is then biased to 1.65 volts and amplified once again. This time the gain can be adjusted digitally via a MCP4561 I2C digipot.\nBefore I forget: The PIC gets its system clock from a 8MHz crystal. That might seem low but there are two (variable) PLLs inside the PIC that (together with a number of pre- and post-scalers) let us produce the 48Mhz signal needed for USB as well as a reasonable clock speed to run the CPU and peripheral bus on (probably also 48MHz but we\u0026rsquo;ll see).\nThe board layout proved to be a bit tricky because there isn\u0026rsquo;t that much space on the board and I had quite clear ideas where I wanted certain headers to be. So I was more than happy when all the traces were finally laid out.\nAs you can see, the PCB is already milled and the vias soldered. I can\u0026rsquo;t wait to build this thing up and start to do some programming. That will be the topic of my next post.\nAs always, a zip file with the eagle files and PDFs of the schematic and board layout can be found on the overivew page.\nAnd here\u0026rsquo;s the finished board.\n","date":"11 May 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-20-standalone-anemometer-design/","section":"posts","summary":"Last time I outlined my reasons to ‘go digital’ by adding a powerful on-board microcontroller and designing a standalone wind meter.\nIn the weeks that followed that decision I tried to find a suitable microcontroller and to design a prototype. Today I’ll show you the result of that work.\n","title":"Ultrasonic Anemometer Part 20: Standalone Anemometer Design","type":"posts"},{"content":"","date":"26 April 2016","externalUrl":null,"permalink":"/tags/digital/","section":"tags","summary":"","title":"digital","type":"tags"},{"content":" In my last post I went through the design of the analog part of the ultrasonic anemometer. Today we will see how the circuit designed last time performs in practice.\nActive Full Wave Rectifier\nLet\u0026rsquo;s first look at the active full-wave rectifier. As a first test I fed the input with a 40kHz sine wave from the scope\u0026rsquo;s signal generator. Here\u0026rsquo;s what I got to see on the scope.\nThe input signal is shown in yellow. The pink signal is calculated as the absolute value of the input and is what we are trying to archieve. Finally, the blue signal shows what we actually get on the rectifier\u0026rsquo;s output. What do you think? The basic wave form is obviously right but the precision leaves quite something to be desired. So I tried the same setup with an input signal 10 times slower, i.e. 4kHz.\nAs you can easily see, things look much better at 4kHz. That doesn\u0026rsquo;t make it much better for us since we need it to operate at 40kHz but there doesn\u0026rsquo;t seem to be anything fundamentally wrong with the design per-se. I think a faster op amp might be that is needed to make this thing work properly at 40kHz, too.\nZero-Crossing Detector\nThe zero-crossing detector is by far the simplest element of this circuit and has hardly changed since the Arduino anemometer shield. It\u0026rsquo;s output is shown in blue above. It works just as expected, no surprise here. Well, in the end it\u0026rsquo;s just a comparator so the sources for error are limited.\nPeak Detector Sample And Hold\nThe input to the peak detector is the rectifier\u0026rsquo;s output so we should expect to see at least some inaccuracy carried over from the rectifier.\nBelow is what I got. Again, yellow is the 40kHz sine wave input. Blue and red are the peak detector of the positive and negative half-wave, respectively. Green is the output, i.e. either the blue or red singnal as chosen by the 2:1 multiplexer.\nThe good news is that the circuit basically works as designed. Each peak detector gets zeroed at just the right time. From the screen shot above one might even conclude that the peak detector is fairly accurate. Both half-waves show very similar amplitudes and the output is nicely held stable during the hold period. No droop is visible at least at this level of magnification.\nOnce you zoom in, things start to look less pretty. There is in deed no droop but the opposite. The output signal rises during the hold period. If you look closely in the screen shot above you can even see it - the segments of the green signal are slightly rising. We\u0026rsquo;re talking maybe 10mV here, far from dramatic but still.\nConclusion\nMy conclusion is as follows:\nZero crossing detector: perfect Active rectifier: poor performance as is but can probably be fixed with a faster op-amp. Peak detector: ok but not good enough. might need lots of trial-and-error to improve it. I have mentioned in a previous post that I\u0026rsquo;m still unsure if I should stick to the predominantly analog signal processing or if I should make the switch to a more contemporary, digital, DSP like approach. After having spent an evening or two testing and tweeking this circuit the answer became clear - go digital.\nIf you\u0026rsquo;ve followed my blog for even just a short while you have likely noticed that I enjoy designing and building hardware. Probably more than I enjoy writing software. But there are several good reasons to to more in software and less in hardware when it comes to this project.\nThe circuit as described above works kind of. But it might take a loooong time to improve it until it really performs well. Chances are that it will never perform as well as I\u0026rsquo;d like it to. Board space. All this circuitry takes up considerable board space. A later version might use smaller components but this thing will always take up quite a bit of space - maybe a third of the total board area. Even with most of the heavy lifting done in hardware the Arduino is likely not fast enough. We\u0026rsquo;d need to sample the amplitude at 80kHz which is out of reach for the Arduino\u0026rsquo;s Atmega328 even when sacrificing some resolution. Further development. Chosing a digital approach enables users to actively contribute to the further development and improvement of this project. Versatility: Eqiping the anemometer with a dedicated microcontroller makes this project much more versatile. It no longer has to be Arduino specific. If you\u0026rsquo;re an Arduino lover I promise you it will always be Arduino compatible. No need to worry. But equiping it with a easy-to-use SPI or I2C interface makes it useful beyond the Arduino community. Cost. My analog design uses two op amps among other things. Precision op amps are relatively costly components. It\u0026rsquo;s not an expensive circuit but it will always cost several dollars for the components alone. And improving the circuit is unlikely to make it cheaper. Processing power is cheap. You might rightly say that a few bucks is not a lot of money to spend on some nice analog circuitry. I fully agree. But one can buy a lot of processing power for far less money nowadays. Let me elaborate on some of these points:\nVersatility: Arduino Only vs. Anyting, including Arduino\nThe arduino is a great platform with a great user community. But the Arduino Uno might not be the best choice for this project. A on board microcontroller gives user the option to use this anemometer from whatever platform they chose. Besides: An arduino is a very expensive device even when compared to a quite high-end microcontroller. 32-bit microcontrollers running at frequencies of 40MHz and higher are available for less than 2 or 3 dollars even in small (say, 10 pieces) quantities. More advanced models might cost, say, 5 dollars. In comparison, an Atmel Atmega328 as used on the Arduino currently costs CHF 3.10 (USD 3.18 at the time of writing) at Farnell. Not really value for money if you ask me.\nCommunity Driven Developement\nThere are lots of creat coders out there. I can write decent code but there are plenty of people way better at that than I ever will be. I see this as an opportuinity to greatly improve this project. Once I get this thing up-and-running I\u0026rsquo;d like to build a small series and let users share their experience and contribute to the code. Have an idea on how it could be improved? Try it yourself if you have the skills. Share your code if it works. Or share your thoughts and ideas if writing emedded softwar is not for you. So the anemometer could get better and better without having to get new hardware. Just update the firmware.\nNext steps\nIn the weeks to come I will work hard to find a suitable microcontroller and to design and build a board with all that is needed for a stand-alone ultrasonic anemometer.\nIt\u0026rsquo;s now ready, click here.\n","date":"26 April 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-19-testing-the-analog-circuit/","section":"posts","summary":" In my last post I went through the design of the analog part of the ultrasonic anemometer. Today we will see how the circuit designed last time performs in practice.\n","title":"Ultrasonic Anemometer Part 19: Testing the Analog Circuit","type":"posts"},{"content":"","date":"19 April 2016","externalUrl":null,"permalink":"/tags/active-rectifier/","section":"tags","summary":"","title":"active-rectifier","type":"tags"},{"content":"","date":"19 April 2016","externalUrl":null,"permalink":"/tags/envelope-detector/","section":"tags","summary":"","title":"envelope-detector","type":"tags"},{"content":" Recently, I\u0026rsquo;ve sucessfully tested the new driver ciruit for my ultrasonic anemometer. It performed even better than I expected and I will be happy to use it pretty much as it is.\nBy the way: If you want to get an overview over how this project has developed over time check out the overview page. If you\u0026rsquo;re more interested in my latest design, this link will take to my new attempt.\nSo we have a circuit that can send powerful ultrasonic pulses from the right transducer, receive the signal from the opposite transducer and route it through an amplifier. The next task is to tell the time-of-flight from the received signal. A contemporary approach would probably involve some sort of DSP and software. My last approach used some analog circuitery to detect the zero crossings as well as the envelope of the received signal. Since most of the heavy lifting was done in hardware, a simple 8-bit microcontroller like the one on the Arduino UNO could be used to do the measurements.\nFor my new approach I haven\u0026rsquo;t quite decided which route to take. To me they both have a certain appeal. And over the last year or so I\u0026rsquo;ve had quite some ideas on how to process the signal in hardware so I\u0026rsquo;ll give it a try and see how it works out. In this post I\u0026rsquo;ll go through this new circuit and explain how it works (or is supposed to work) step-by-step.\nThe zero crossing detector (ZCD) is almost identical to to my last design. The amplifier output is biased to half the positive supply voltage and fed into a fast comparator (Microchip MCP6561R). On the comparator\u0026rsquo;s output we get a precise digital signal indicating if we are currently looking at the positive or negative half-wave. Right at the logic edge we observe a zero crossing which can then be used to very precisely determine the phase shift relative to the transmitted singal.\nThe more challenging part is to tell the absolute phase - this is where my last project was only partly successful. It used an active low-pass filter to get the envelope of the received singal. This envelope was then compared to some threshold and the time from the transmition of the singal to when the envelope exceeded the threshold was measured. With plenty of averaging this gave a usable but far from perfect indication of absolute phase. So this time I\u0026rsquo;ll try something entirely new.\nThe amplified singal is first run trough an active full-wave rectifier as found on page 257 of Horowitz and Hill\u0026rsquo;s 3rd edition of Art of Electronics. It uses two op amps as well as some resistors and diodes to produce a singal that corresponds to the absolute value of its input. The two op amps come in a single package. It\u0026rsquo;s the same type as for the amplification stage of the driver circuit - a Texas LMC6482.\nNow the rest of the circuit is a bit more adventurous. It attempts to produce a signal that corresponds to the peak of the previous half-wave. So it is steady during each halv-wave period and should give a (hopefully precise) indication of the amplitude of the received signal. This singal can then sampled by an ADC at 80kHz triggered by the zero crossing detector. 80kHz is not that fast for a (say) 10-bit ADC and definitely much slower than what we\u0026rsquo;d need if we sampled the amplified signal directly.\nThe advantage of measuring the amplitude is the following: We can find the peak of the amplitude in simple software and use the time when the peak occured to find the absolute phase. So we are no longer dependant on the absolute amplitude (as we were with the envelope detector approach) but only care about when the peak in amplitude occured. I think (hope) this is a much more reliable approach.\nIn order to find the peak of each half-wave I use a pair of simple diode-plus-capacitor peak detectors. One is held stable (\u0026ldquo;hold\u0026rdquo;) and fed through an op-amp buffer to minimize droop while the other is looking for the next peak (\u0026ldquo;sample\u0026rdquo;). At the beginning of the sample period the capacitor is discharged through a n-channel mosfet that is turned on for just an instance.\nThe whole mechanism is controlled by the output of the zero-crossing detector so absolutely no software intervention is needed to produce it. The microcontroller can just wait for the ZCD to trigger an interrupt (as before) and take a sample of the output.\nThe circuit is not that complex and used an inexpensive and readily available 74HC4053 multiplexer at its center. I don\u0026rsquo;t have any idea yet how this thing will perform but I must say this little circuit was a lot of fun to design.\nUntil my next post I will have built and tested this cuircuit and will let you know how it performs. Until then I leave you with the eagle files as well as PDFs of the schematic and layout as a zip file (file no longer available).\nHere\u0026rsquo;s how the final circuit looks and how it performs: Part 19.\n","date":"19 April 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-18-analog-signal-processing/","section":"posts","summary":" Recently, I’ve sucessfully tested the new driver ciruit for my ultrasonic anemometer. It performed even better than I expected and I will be happy to use it pretty much as it is.\n","title":"Ultrasonic Anemometer Part 18: Analog Signal Processing","type":"posts"},{"content":"","date":"9 April 2016","externalUrl":null,"permalink":"/tags/agilent/","section":"tags","summary":"","title":"agilent","type":"tags"},{"content":"","date":"9 April 2016","externalUrl":null,"permalink":"/tags/fan/","section":"tags","summary":"","title":"fan","type":"tags"},{"content":"","date":"9 April 2016","externalUrl":null,"permalink":"/tags/keysight/","section":"tags","summary":"","title":"keysight","type":"tags"},{"content":"","date":"9 April 2016","externalUrl":null,"permalink":"/tags/lab-power-supply/","section":"tags","summary":"","title":"lab-power-supply","type":"tags"},{"content":"","date":"9 April 2016","externalUrl":null,"permalink":"/tags/power-supply/","section":"tags","summary":"","title":"power-supply","type":"tags"},{"content":" I\u0026rsquo;m currently mainly working on my new anemometer design but once in a while I get distracted. For example when my Keysight E3645A lab power supply was making so much noise that I could hardly concentrate. That\u0026rsquo;s when the idea of this fan controller was born.\nOf course, the best temperature controlled fan in the world doesn\u0026rsquo;t help if you really need the cooling the fan is providing. But very often a small fraction of the cooling would do just fine most of the time. In my case the supply does control the speed of the fan. But it doesn\u0026rsquo;t seem to measure the temperature at all but seems to calculate the necessary cooling in a worst-case condition. An for a supply that may be rack-mounted together with lots of other heat dissipating gear the worst-case might be quite demanding. But my supply just sits on a shelf at, say, 22 degrees ambiant. And most of the time I\u0026rsquo;m hardly pulling any current. When working with microcontroller designs it\u0026rsquo;s rare for me to pull more than a few tens of milliamps. So little cooling is needed most of the time. But the E3645A (this one here does a better job) ran its fan at crazy speeds while the case still had this cold metallic feel to it. So we can definitely do better.\nSo the first step was to open the supply and to see what kind of fan it uses and how it is controlled. After beaking some seals and opening the case I found a 60x60x25mm 12V fan of Chinese origin. I also found out that the supply uses linear control. So there\u0026rsquo;s no PWM or anything but the supply voltage just varies in (I think) four steps from 7.4 to 12 volts. Most surprisingly, this voltage is not ground-referenced but symmetric around ground, i.e. plus/minus 6 volts.\nI was pleased to see that the fan connects to the main board by means of a standard two-pin 100mil header. So I could just plug anything in between the board and the fan.\nThat\u0026rsquo;s exactly what my first idea was. Stick with the original fan and just put a PWM controller in between. I\u0026rsquo;ve just recently made some LED dimmers and the technology needed here seemed to be very similar. So Rev A of my fan controller was born.\nIt\u0026rsquo;s simple: A linear 5V regulator, a PIC16F18325 microcontroller, an LMT86 temperature sensor and a N-channel mosfet. The PIC chosen here runs at up to 32MHz on an internal oscillator, has an internal voltage reference (of 1.024, 2.048 or 4.096V), six PWM modules and plenty of other nice features while comming in a small 14-pin package. So all I need to do is to measure the temperature, calculate the desired fan speed and set the PWM duty cycle accordingly.\nMy first surprise came when I first wanted to program the PIC. My trusted Mikroelectronika MikroC for PIC compiler doesn\u0026rsquo;t know that chip. And neither does my MikroProg programmer. So after a little bit of research I ordered a PICkit3 and downloaded the MPLAB IDE. As a nice side effect I can now also compile code for and program the fancier PICs like the DSPics and PIC32s. I might do that before long.\nSo I did the necessary programming (and debugging) and attached a small fan. It all worked but I had to chose a quite low PWM frequency in order to make the fan spin at lower duty cycles. And probably as a result of the low PWM frequency the motion of the fan didn\u0026rsquo;t look or sound very smooth.\nWith the larger fan from the supply things only got worse. I had to lower the PWM frequency even more into the tens of Hz range so it would spin at all. And even like this I couldn\u0026rsquo;t get it to run at low duty cycles. Of course, the low frequency caused nasty vibrations so I gave up on this approach. I read online that other people successfully use PWM on their fans but at least this model wasn\u0026rsquo;t happy to be PWM-dimmed. Does anybody know more about this? Was this an option in the old days before brushless motors were the norm? Is it that brushless motors aren\u0026rsquo;t unsuitable for this kind of control alltogether or does it depend on the specific model? Please use the comments section below if you can shead some light on this.\nBut I don\u0026rsquo;t give up easily so after a bit of research I ordered a four-wire fan conforming to the so-called Intel spec. Besides ground and +12V they have two control lines. A PWM line that lets you control the fan speed by means of a (25kHz nominally) PWM singal. And a so-called TACH singal that allows you to read the current fan speed. The PWM line has internal pull-ups to (depending on the fan) 3.3 or 5 volts so you just need to pull it low. The TACH signal needs an external pull-up resistor and gets pulled low by the fan twice per revolution. So you\u0026rsquo;re getting a digital signal with a frequency of twice the fan speed.\nI ordered a EBM Papst 622/2 HHP which is the right size and somewhat more powerful than the original fan. The new board has a somewhat odd shape so I can use one of the fan\u0026rsquo;s mounting screws to mount the board as well. Note that all the copper has been removed around the mounting hole. The fan is attached to a heat sink which is grounded while our board runs on a split suply. So ground as our board sees it is not actually ground but a negative voltage so we have to be careful.\nThe new Rev B design runs on 3.3 volts in order to be compatible with any fan independent of the fan\u0026rsquo;s internal logic voltage. I\u0026rsquo;ve also used a different temperature sensor - a classic LM35.\nLike the Rev A there is an LED to visually indicate what\u0026rsquo;s going on. There are also three pins on the microcontroller that are intended to be used as debug pins so I put some vias there to make it easy to connect a scope probe.\nAbove you get an idea of what the TACH signal looks like. It\u0026rsquo;s a quite low frequency singal since there are only two pulses per rotation. So the measured 104Hz shown on the screenshot correspond to 3120 RPM.\nHaving a TACH signal to measure and three debug outputs to worry about made the software development somewhat more involved but it was well worth it. I\u0026rsquo;ve used the debug pins as follows:\nActual (i.e. mesured) fan speed. 100% corresponds to 10000RPM Target fan speed. 100% corresponds to 10000RPM Measured temperature. 100% corresponds to 100 degrees centigrade So from the duty cycle measured by a scope you can easily read the speeds and temperature.\nOf course this is only possible since there are some unused PWM modules left. But as I said, this PIC has 6 of them and only two are needed to measure the fan speed and another to control the fan.\nThe transfer function from temperature to fan speed can be freely defined in software. In the screenshots above the fan was running at 1500RPM up to a temperature of 30 degrees. Above that the speed would rise linearly until reaching its maximum of 9000RPM at a temperature of 55 degrees.\nOne could easily implement a PID control if one was so inclined but the slowly chaning nature of the temperature in such a setting makes this largely unnecessary so at least for now only the proportional part is taken into consideration when calculating the PWM frequency.\nAs you can see, the little board is nicely held in place by one of the fan mouning screws. By the way, the LED blinks roughtly once per second and its duty cycle corresponds to the target fan speed relative to the maximum fan speed of 9000RPM. So if the LED is on one-third of the time the target fan speed is one-third of the maximum speed or 3000RPM.\nUnfortunately for my application, the supply senses the current consumed by the fan and shuts down if not enough current flows. This is probably a good idea and prevents the supply from possible damage if the fan is unplugged for example.\nI found that it is possible to run the fan at a lower speed without the supply complaining but with fan speeds below about 4000RPM the there were conditions causing an error condition. So I ended up connecting a 1W 150ohms resistor in parallel to keep the supply happy even with the fan running at only 1500RPM.\nI believe that my settings are very much on the safe side. At a a temperature of around 50 degrees measured inside the case the airflow matches the one of the original fan at max speed. But needless to say this kind of fiddling voids the warranty and is always done a one\u0026rsquo;s own risk. The reward is a supply that is now hardly audible and much more pleasant to use.\nThe zip file (file no longer available) contains the eagle files, PDFs and software of both revisions.\n","date":"9 April 2016","externalUrl":null,"permalink":"/posts/temperature-controlled-fan/","section":"posts","summary":" I’m currently mainly working on my new anemometer design but once in a while I get distracted. For example when my Keysight E3645A lab power supply was making so much noise that I could hardly concentrate. That’s when the idea of this fan controller was born.\n","title":"Temperature Controlled Fan","type":"posts"},{"content":" In my last two posts I have gone through my new anemometer circuit both in theory and practice. Click here for an overview over my ultrasonic anemometer project.\nThis will be a short post. Unlike most of my other posts, this one will not cover electronics but the physical design of this wind meter. As you can see, the new design all laser cut. At the Zurich Fab Lab I have access to a 75 watts Epilog laser cutter and I recently started playing around with OpenSCAD, an open-source CAD software.\nI immediately liked the OpenSCAD approach of designing a 3D part in code as opposed to a graphical interface with menus and buttons and the like. Using OpenSCAD is much like writing software. If you\u0026rsquo;re more familiar with coding than you are with classic CAD tools you will instantly feel at home with OpenSCAD. But it\u0026rsquo;s pretty much love it or hate it. At least with all the people I\u0026rsquo;ve talked to.\nI\u0026rsquo;ve seen some quite cool boxes that were just laser cut and then screwed together. I found it quite compelling how you can laser cut your parts, stick them together and maybe use a few screws to hold everything in place. So I decided to give it a try myself.\nThe design is not too complicated with just 6 wooden parts. The material is 5mm in thickness so I looked around for screws and bolt that would be appropriate in size. I also thought that it would be nice to use square bolts both from an optical as well as a mechanical point of view. I learned that square bolts are specified by DIN562 and that M2.5 square bolts measures 5x5x1.6mm - exactly what I needed.\nSo the next thing to find was M2.5 screws. I found nice ones in stainless steel and especially with a Torx (T8 size) head as specified by ISO14580 as well as some matching washers (DIN125).\nAll the tubes are recycled from my last model. Just standard 16mm plastic pipes intended to hold electrical wiring.\nAs you can see in the photo above, I\u0026rsquo;ve tried two different versions for the side parts. The one at the bottom takes the path usually followed: There are cuts that can later fit the screws. The one at the top doesn\u0026rsquo;t have those cuts and relies on holes being drilled by hand.\nDrilling those holes turned out to be really easy. After the parts are ready, just stick them together and drill the holes using a drill press. At the fab lab we have such a drill press and the holes were drilled within minutes. I never liked those cuts so for me this was the way to go.\nThe new design gives me a lot of space to mount any PCBs and hides all the wiring between the bottom and top plate. The bottom includes a large square hole so everything inside stays accessible. There are also two small drill holes to mount a 12 volts power supply. This way I can just plug it into the wall which I think might be handy.\nThe OpenSCAD model as well as the Adobe Illustrator (Ai) and PDF files are available as a download from the overview page. Keep in mind that this is one of my first attempts at OpenSCAD, laser cutting and solid CAD modelling alltogether. I\u0026rsquo;ve tried to keep the CAD model clean and modular but I\u0026rsquo;m not sure if I succeeded.\nIf you have any questions, suggestions or just your experience with this kind of thing please just post them as comments below. I\u0026rsquo;m quite new to most of this so I value your feedback and I\u0026rsquo;m always glad to help if I can.\nClick here to continue to my next post where I talk about the second, analog part of the circuit.\n","date":"6 April 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-17-lasercut-mechanical-design/","section":"posts","summary":" In my last two posts I have gone through my new anemometer circuit both in theory and practice. Click here for an overview over my ultrasonic anemometer project.\n","title":"Ultrasonic Anemometer Part 17: Lasercut Mechanical Design","type":"posts"},{"content":"","date":"31 March 2016","externalUrl":null,"permalink":"/tags/pic16f1936/","section":"tags","summary":"","title":"pic16f1936","type":"tags"},{"content":" Last time I\u0026rsquo;ve presented my new design for the ultrasonic anemometer driver circuit. So now it\u0026rsquo;s time to see how it performs. If you\u0026rsquo;re new to this project you might want to check out the overview page or at least my last post.\nBy 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.\nAfter 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-\u0026hellip;). 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.\nBelow 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.\nFrom 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.\nSo sending pulses is easy and works well. But that\u0026rsquo;s the easy part. Now let\u0026rsquo;s see how the circuit performs in receiving and amplifying singals.\nBelow 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.\nThe 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.\nNote that I\u0026rsquo;m sending much more pulses this time and that there is a larger-than-usual gap after the 18th pulse. As mentioned, I\u0026rsquo;m still experimenting with how many pulses should be sent and how. Here I\u0026rsquo;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.\nBelow 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. Now let\u0026rsquo;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\u0026rsquo;s about as simple as it gets. There are no filters or anything up to this point. But the output looks nice and clean. Here\u0026rsquo;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.\nIf you\u0026rsquo;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.\nNevertheless 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. Being much slower and wider than the noise we\u0026rsquo;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\u0026rsquo;s a time when we won\u0026rsquo;t want to look at the received singal anyway. We haven\u0026rsquo;t even sent any pulses yet. The spike abates long before the received singal starts being of interest. So I\u0026rsquo;m confident that this spike causes no real harm and can savely be ignored.\nAll in all I\u0026rsquo;m positively surprised how well this design has performed. I\u0026rsquo;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\u0026rsquo;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.\nBut I\u0026rsquo;m most surprised of how well the simple op amp performs. Using this super-simple setup I\u0026rsquo;m getting an output signal that\u0026rsquo;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.\nSo 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\u0026rsquo;ll take a closer look at the new lasercut mechanical design.\n","date":"31 March 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-16-testing-the-new-driver-circuit/","section":"posts","summary":" 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.\n","title":"Ultrasonic Anemometer Part 16: Testing the new driver circuit","type":"posts"},{"content":"","date":"22 March 2016","externalUrl":null,"permalink":"/tags/shield/","section":"tags","summary":"","title":"shield","type":"tags"},{"content":" It\u0026rsquo;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.\nI 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\u0026rsquo;s the circuit explained step by step.\nPowerful 12V drive\nMy 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.\nUnfortunately, 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.\nDiscrete Mosfet Switches\nThe 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\u0026rsquo;t have the low Rds-on that we need here. And they are definitely not happy if you\u0026rsquo;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.\nOp-Amp Amplifier and Filter\nThe 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\u0026rsquo;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.\nSo this design uses a dual op amp at its center. I\u0026rsquo;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\u0026rsquo;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\u0026rsquo;ve learned from Horowitz \u0026amp; Hill\u0026rsquo;s classic Art of Electronics. It\u0026rsquo;s my first time to use it so I\u0026rsquo;m exited to see how it works.\nFor now, the gain of the amplifier is controlled via a pot. Future designs will probably have a fixed gain once I\u0026rsquo;ve figured out how much gain we need.\nActive Bandpass Filter\nJust in case the slew rate limitation of the op amp isn\u0026rsquo;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.\nI\u0026rsquo;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\u0026rsquo;ll do some more experimenting once I can test the results on the real circuit. So don\u0026rsquo;t pay too much attention to the compoent values of this filter for now.\nSignal Routing via 74HC4052 Dual 4-Channel Multiplexer\nThis is something that hasn\u0026rsquo;t changed much. The 74HC4052 has already been part of my last design. I\u0026rsquo;m now using two of them, one for transmitting and one for receiving.\nThe 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.\nThe 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\u0026rsquo;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.\nPower Supply\nThis 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.\nOn-board Microcontroller\nI\u0026rsquo;ve included a PIC16F1936 on the board. No, I don\u0026rsquo;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\u0026rsquo;m currently looking at different architectures but no decision has been made yet.\nThis is it for now. In my next post I\u0026rsquo;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.\n","date":"22 March 2016","externalUrl":null,"permalink":"/posts/ultrasonic-anemometer-part-15-a-new-attempt/","section":"posts","summary":" 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.\n","title":"Ultrasonic Anemometer Part 15: A new attempt","type":"posts"},{"content":"","date":"11 March 2016","externalUrl":null,"permalink":"/tags/hp/","section":"tags","summary":"","title":"hp","type":"tags"},{"content":" I don\u0026rsquo;t usually do reviews but I just got a Keysight E36103A Lab Power Supply today and since it\u0026rsquo;s a newly released model there\u0026rsquo;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\u0026rsquo;ll share my first impressions.\nTalking 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\u0026rsquo;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\u0026rsquo;ll focus on other stuff here.\nDisplay\nThis 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\u0026rsquo;ve taken some photos trying to show this. Just click on the thumbnails to enlarge them.\nThe 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:\nWhat 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.\nFan Noise\nThis is a big issue for me but it\u0026rsquo;s difficult if not impossible to get any useful information from the datasheet. I can\u0026rsquo;t do sound pressure measurements or anything like that but here\u0026rsquo;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\u0026rsquo;s still audible but not loud at all. That\u0026rsquo;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\u0026rsquo;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](/posts/temperature-controlled-fan/)\\] 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.\nAs 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\u0026rsquo;s fan noise at the highest speed to that of the E 3645A\u0026rsquo;s at its lowest speed setting. I think its not only quieter but I also find it less annoying despite the higher pitch.\nBut 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.\nProgramming and Readback Accuracy\nTo me, readback accuracy is even more important than programming accuracy. I don\u0026rsquo;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\u0026rsquo;m calculating the efficiency of some switching regulator like my MPPT solar charger. I don\u0026rsquo;t want to set up 4 DMMs for that (and I don\u0026rsquo;t have 4). So I want reliable readings from the supply.\nThe 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).\nSimilarly the E36103A features better programming accuracy: 0.05%+7mV (vs. 0.05%+10mV) and especially 0.05%+1mA (vs. 0.2%+10mA).\nI 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.\nI 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.\nSmall Current Readback Accuracy\nThis supply has the nice feature of being able to measure very small currents quite precisely. That\u0026rsquo;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.\nI\u0026rsquo;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\u0026rsquo;t affect the measurement.\nSince the resistance is 1MOhm we can expect 1uA of current per Volt. So at the maximum output voltage we\u0026rsquo;ll only draw 20uA. That\u0026rsquo;s really not much given the specified 0.25%+40uA readback accuracy (up to a maximum of 8mA).\nWith 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.\nHere are some photos that illustrate that point:\n@10V\n@20V\n@3V\nAll 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.\nPackage Content\nI didn\u0026rsquo;t check what exactly is suppoed to be in the box but found everything I expected but also nothing more.\nBesides the supply itself and a power cord there is a certificate of calibration, a CD with some software as well as some warranty papers.\nSize\nThis 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.\nIt doesn\u0026rsquo;t really show on the photos but it looks even smaller than half the size. I guess that\u0026rsquo;s because of the rubber padding around the E3645A which the E36103A doesn\u0026rsquo;t have.\nConnectivity\nEthernet 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\u0026rsquo;m looking forward to do the same with this supply. I\u0026rsquo;m also planning to send commands from C# programs in order to do some calibration and things like that.\nSo far I haven\u0026rsquo;t tried any of that yet but I\u0026rsquo;ll definitely share my experience once I got a chance.\nAnother thing I really like is the sense terminals on the front rather than on the back. I found I don\u0026rsquo;t use them on the E3645A since it\u0026rsquo;s just too much of a hassle to attach sense leads to some screw terminal located at the back of the supply.\nUser Interface\nI haven\u0026rsquo;t even glanced at the user manual but have found everything to be quite intuitive.\nThe 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.\nAll the (few) menues are straight forward and easy to find/use.\nConcluding Remarks\nAgain, I\u0026rsquo;ve only had my hands on this thing for a few hours but so far I\u0026rsquo;m very happy with what I saw and I\u0026rsquo;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 ;-)\nIf you have specific questions please just leave a comment below and I will try to answer it.\n","date":"11 March 2016","externalUrl":null,"permalink":"/posts/keysight-e36103a-lab-power-supply-review/","section":"posts","summary":" I 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.\n","title":"Keysight E36103A Lab Power Supply Review","type":"posts"},{"content":"","date":"11 March 2016","externalUrl":null,"permalink":"/tags/psu/","section":"tags","summary":"","title":"psu","type":"tags"},{"content":"","date":"11 March 2016","externalUrl":null,"permalink":"/tags/review/","section":"tags","summary":"","title":"review","type":"tags"},{"content":"","date":"11 March 2016","externalUrl":null,"permalink":"/categories/reviews/","section":"categories","summary":"","title":"reviews","type":"categories"},{"content":" Finished RGB dimmer In my last post I\u0026rsquo;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.\nEncoder\u0026rsquo;s side There\u0026rsquo;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\u0026rsquo;s now installed as a stand-alone solution.\nSince we\u0026rsquo;re now controlling RGB LEDs we obviously need three independant PWM outputs, one for each for red, green and blue. But let\u0026rsquo;s go through the circuit step by step.\nPower Supply\nThe 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\u0026rsquo;s 3.3 volts operating voltage. Apart from hobbyist projects there aren\u0026rsquo;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\u0026rsquo;s voltage.\nWhat I\u0026rsquo;ve done here is the following: The board has it\u0026rsquo;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\u0026rsquo;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.\nRotary Encoders\nI\u0026rsquo;m using a pair of Bourns PEC11R-4215F-S0024. These are 24 steps-per-rotation encoders with a push button that I\u0026rsquo;ve used for other projects before. I\u0026rsquo;ve made it a habit to debounce switches and encoders in hardware rather than having to worry about it in software. There\u0026rsquo;s even an entire post just on that subject: /posts/switch-debouncing-using-74hc14/.\nSo 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.\nMicrocontroller\nI\u0026rsquo;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.\nThe 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.\nOutput\nI 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.\nSoftware\nAs so often, most of the interesting stuff happens inside interrupt service routines (ISRs). This one serves two tasks:\nRead 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\u0026rsquo;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\u0026rsquo;ve mentioned I\u0026rsquo;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\u0026rsquo;s current state of operation such as brightness of each color channel and some more data.\nThere is also nothing preventing the content of the buffer from being changed while a transmission is in progress. So if you\u0026rsquo;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.\nControlling 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\u0026rsquo;ve used are of the inverting type so the duty cycle has to be inverted in software.\nI\u0026rsquo;ve used a lookup table for brightness (only 32 brightness levels this time) and color. I\u0026rsquo;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.\nTesting and Troubleshooting\nAcoustic 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\u0026rsquo;t know, haven\u0026rsquo;t tried.\nMass 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\u0026rsquo;s thanks to John and it has served me very well.\nBut back to the problem: It seems that this time I\u0026rsquo;ve been a bit sloppy with my ground connections around the two MOSFET drivers and the encoder on the right. They\u0026rsquo;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\u0026rsquo;ve already fixed that problem in Eagle so the files available for download should be fine.\nThere 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\u0026rsquo;t suffer from this problem.\nAs 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.\nI first tried a pull-up resistor on that PWM signal but that didn\u0026rsquo;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.\nSince the board is installed hidden in some kind of bookshelf I didn\u0026rsquo;t make a new pretty board with all these fixes already in place. But I\u0026rsquo;ve now been using it for two months or so and it works perfectly every day.\nI\u0026rsquo;ll finish this post with a few impressions of the final product and the download link below.\nAs always, here (file no longer available) you find the Eagle Files, PDFs of schematic and Board as well as the code.\n","date":"5 March 2016","externalUrl":null,"permalink":"/posts/pwm-dimmer-for-rgb-led/","section":"posts","summary":" 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.\n","title":"PWM Dimmer for RGB LED","type":"posts"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/tags/fet/","section":"tags","summary":"","title":"fet","type":"tags"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/tags/lm2931/","section":"tags","summary":"","title":"lm2931","type":"tags"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/tags/lm5111/","section":"tags","summary":"","title":"lm5111","type":"tags"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/tags/mosfet/","section":"tags","summary":"","title":"mosfet","type":"tags"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/tags/mosfet-driver/","section":"tags","summary":"","title":"mosfet-driver","type":"tags"},{"content":" Like my ultrasonic anemometer project, this is something a bit more involved. So there will be a series of posts. This page serves as a directory for all my posts about my MPPT solar charger. More will definitely be comming up\u0026hellip;\nPosts # Concept and hardware: /posts/arduino-mppt-solar-charger-shield/ Hardware testing: /posts/arduino-mppt-solar-charger-shield-testing/ A closer look at the software: /posts/arduino-mppt-solar-charger-shield-software/ A new, very low power, standalone design: /posts/mppt-solar-charger-design/ First tests with the standalone design: /posts/mppt-solar-charger-testing/ User interface: /posts/low-power-user-interface/ More testing: /posts/mppt-solar-charger-testing-ii/ Introducing the Rev C design: /posts/mppt-solar-charger-rev-c-design/ Test results for Rev C: /posts/mppt-solar-charger-rev-c-first-test-results/ Mechanical design and a few words on Revsion D: /posts/mppt-solar-charger-update/ Revision F board: /posts/mppt-solar-charger-revision-f/ Hackaday prize: /posts/solar-charger-in-hackaday-prize-finals/ Bootloader ready: /posts/usb-mass-storage-device-bootloader/ Github # Github has become the way I share both hardware designs as well as code. So whenever you\u0026rsquo;re looking for something, chances are high that it\u0026rsquo;s on github.\nThese are the repos relevant to this project:\nhttps://github.com/soldernerd/SolarChargerHardware https://github.com/soldernerd/SolarChargerRevC_Software https://github.com/soldernerd/SolarChargerRevE_Software https://github.com/soldernerd/PIC18_USB_Bootloader https://github.com/soldernerd/UserInterface https://github.com/soldernerd/SolarChargerApp Downloads # Since I\u0026rsquo;ve moved (almost) all my stuff to github, these are largely outdated:\nSchematic, board layout and eagle files: SolarCharger_Rev1.zip (file no longer available) Arduino Sketch: solarpanel.zip (file no longer available) Eagle files including PDFs of the standalone solar charger: SolarCharger_Rev2 (file no longer available) Very basic software for the standalone solar charger: SolarChargerRevB_Code (file no longer available). ","date":"19 February 2016","externalUrl":null,"permalink":"/projects/mppt-solar-charger/","section":"posts","summary":" Like my ultrasonic anemometer project, this is something a bit more involved. So there will be a series of posts. This page serves as a directory for all my posts about my MPPT solar charger. More will definitely be comming up…\n","title":"MPPT Solar Charger","type":"posts"},{"content":"","date":"19 February 2016","externalUrl":null,"permalink":"/projects/","section":"posts","summary":"","title":"Projects","type":"posts"},{"content":" Finished LED dimmer I have recently moved to a new apartment and was looking for a PWM dimmer to control some 12V LED strips. I thought that should be easy enough nowadays but it proved more difficult than I thought. All I found either didn\u0026rsquo;t meet my requirements, were uggly or expensive. So I decided to build my own, tailor-made to my needs.\nFinished PCB mounted below a shelf The requirements # Handle 100W @ 12Volts comfortably Controlled by a simple on-board pot (no remote control or the like) Affordable No acoustic noise Fine-grained control down to very low brightness levels I\u0026rsquo;ll go through these requirements one-by-one.\nTwo LED strips below the shelf give a nice lighting on the desk Handle 100W @ 12Volts comfortably # My LED strips suck up a bit more than 20 Watts per meter and there is a maximum of 4-5 meters of LED strips per dimmer so I need a power rating of around 100W. If you do the math you\u0026rsquo;ll find that there will be a maximum current of about 8.3 amps.\nI don\u0026rsquo;t want this thing to get hot nor do I want to put a heat sink on it. So the total power dissipation in the dimmer should stay below, say, 1 watt. So if we use a single FET, we need a Rds-on of 14.5 milliohms. Thats not a lot but there are inexpensive MOSFETs that meet this requirement. And we can always parallel two or more of them if necessary.\nAnd yes, there will also be some switching losses but they should be low given the modest switching frequency of an application like this.\nPIC microcontroller with its power supply Controlled by a simple on-board pot # This is most likely the simplest way of controlling a dimmer but it\u0026rsquo;s surprisingly hard to find. A lot of commercially available dimmers come with IR remote controls nowadays. And some of the higher quality models expect a 0-10V control signal which means that you have to use an external pot which you have to mechanically attach somewhere. I would like everything on a single PCB to keep things simple.\nAffordable # I needed 3 of these things so cost was a factor, too. All the nicely-made dimmers I could find were priced at $50 and uppwards. Not that bad but I figured that I could make my own for a small fraction of this, perhaps $10.\nNo acoustic noise # We all know those dimmers that produce audible humming. Especially when dimmed somewhere half-way down. I hate it. Drives me crazy.\nThis proved to be more difficult to archieve than I thought. More on this later.\nSince the power supply has 4 output leads, my dimmer has a 8x connector at its input Fine-grained control down to very low brightness levels # This is where most products fail miserably. Most of those remote-controlled things only have 8 brightness levels. And just about everything I found works linearly which makes very little sense if you ask me. We humans perceive brightness logarithmically, rather than linearly. So going from 1% to 2% seems the same as going from 50% to 100%.\nBeefy mosfet and capacitor Linear control will not give you fine control at the lower end. Ideally, you want to have an exponential transfer function from pot position to PWM duty cycle to compensate for the logarithmic nature of the human vision. I found the easiest way to do this was using a microcontroller. Furthermore, the ability to do all of this in software enables you to play around with it and find a transfer function that you\u0026rsquo;re happy with.\nHigh granularity at the lower end also means that we need quite a bit of PWM resolution. The common 8-bit resolution translates to about 0.25% per step. Going from 0.5% (wich is about what I mean by very low brightness) to 0.75% is already quite a step. Many microcontrollers are capable of 10 bits which is 4 times better and probably good enough.\nYet another view The design # At the center of my design is a 8-bit PIC microcontroller, a PIC16F1936. There\u0026rsquo;s not much special about this particular model, it\u0026rsquo;s just a type I\u0026rsquo;ve used several times before and still had some on stock.\nA LM2931 provides the PIC with 5 volts from the 12 volts input voltage. I use the LM2931 as my standard 5V regulator. It\u0026rsquo;s pin compatible with the legendary 7805 but survives input voltages in the range of -50 to +60 volts making it very robust against transients.\nA LM2931 generates 5V from 12V The PIC controls a LM5111 dual FET driver that provides a powerful 12V gate drive to a pair of Infineon IPB136N08N3 N-channel MOSFETs. This is the same transistor that I\u0026rsquo;ve recently used for my Arduino Solar Charger Shield. Its an inexpensive (\u0026lt; $1), large SMD type with an exellent Rds-on of 11.5 mOhms.\nThere are several variants of the LM5111. It comes in inverting and non-inverting configurations as well as combinations of inverting and non-inverting. At Farnell, the the inverting ones were by far the cheapest so that\u0026rsquo;s what I\u0026rsquo;m using here. It doesn\u0026rsquo;t really matter since you can change the polarity in software as needed.\nPot and one of the output drivers Why am I using two FETs despite the fact that one could easily handle the entire current? First, I\u0026rsquo;m driving two LED strips with this dimmer and using two transistors simplifies the layout so I have two outputs exactly where I need them. Secondly, the LM5111 is a dual FET driver anyway so I get the second gate drive for free.\nNice 2kOhm pot I\u0026rsquo;ve provided each output with a generous 1.5mF capacitor in order to shield the supply from the ripple that is inevitably produced by the PWM. I\u0026rsquo;ve also taken care to use a cap with low serial resistance (ESR) and a high current rating. The Panasonic FR series fulfills both of these requirements while being good value for money. I thought this should be enough to avoid excessive ripple and therefore also acoustic noise.\nTop side of the long version The input to the PIC comes from a quite nice 2 kOhms pot that I\u0026rsquo;ve recovered from some scrap. There is also a voltage divider to measure the 12V input voltage. The idea was to only enable the output once the input voltage has stabilized but I found this to be a quite unnecessary feature when programming the PIC.\nBottom side of the long version The Layout # Top side of the short version I\u0026rsquo;ve built the two different versions of this dimmer. The schematic is exactly identical for both of them, they only differ in their physical layout and board dimensions. I\u0026rsquo;ve just tailor-made them to their specific application so the pots are located in a handy position and the outputs are exactly where I need them.\nBottom side of the short verison Software and Testing # My first version of the software measured the voltage from the pot using the on-chip ADC and outputed an identical 2kHz PWM signal on both outputs. 2kHz should be enough to avoid visible flicker and seemed a reasonable choice. Everything worked but the power supply made quite a bit of noise over most of the brightness range. Worse than any commercial design. Even worse, there was an awful lot of flicker. Ouch.\nToo much ripple producing lots of audible noise Looking at the power supply output / dimmer input voltage on a scope if became clear that the two 1.5mF caps still allow too much ripple at this frequency.\nThe first thing I tried was running the two outputs out-of-phase. Since I\u0026rsquo;m using two FETs I have two independent outputs. So I can run them 180 degrees out-of-phase. Now, at duty cycles below 50% it looks like I\u0026rsquo;m only driving a load half the size with a frequency and duty cycle twice as high. At precisely 50% duty the supply even sees a constant load at its output since exacly one LED strip is on at any point in time. At duty cycles above 50% the on-times overlap so the load only varies from 50% to 100% and with twice the frequency. As you can see from the scope screenshot below, this already helped a great deal but the problem was not yet resolved. So the natural thing to do was to increase the PWM frequency.\nRunning the outputs out-of-phase helps At 8kHz, things already looked (and sounded) much better. Ripple and acoustic noise were much reduced but the supply was still audible at least in a quiet environment.\nIncreasing the PWM frequency to 8kHz almost solves the problem So I moved the PWM frequency up as far as i could. Given the PIC\u0026rsquo;s 32MHz clock and a 10 bit resolution this was 31.25kHz. Now every last bit of audible noise was gone. Finally.\nAt 31.25kHz all the noise is finally gone I then noticed that the phase shift was 176 degrees as opposed to the intended 180 degrees.\nPhase shift is 4 degrees off Not that this makes much of a difference in practice but I solved it anyway. I\u0026rsquo;ve implemented this phase shift by starting one PWM module at 128 and the other at 0 (we\u0026rsquo;re only talking about the 4 most-significant bits here, so the maximum is 255). The two instructions are on successive lines in my C code but 3 clock cycles are needed to process each of them so they are not enabled at the precisely same time. Starting the first PWM module at 131 has solved the problem as you can see below.\nNow the phase shift is fixed With these changes in place the flicker mentioned previously was also much reduced but had not yet disappeared. Looking at the voltages on a scope for a while the problem became clear. I was measuring the voltage from the pot at fixed intervals that had no connection with the switching frequency. So I was effectively measuring at random points in time.\nI said that the input voltage now showed much less ripple but some ripple is inivitable. Some of that ripple is likely to somehow feed through to the voltage from the pot. That introduced noise in the value measured by the ADC which lead to variations in the duty cycle which was noticable as flicker.\nI did two things to resolve this. First, I\u0026rsquo;m generating an interrupt signal (from the same timer as I use for the PWM) every 64 PWM cycles. In the corresponding interrup service routine (ISR) I read (and save) the ADC value and start a new conversion. This way I\u0026rsquo;m always measuring at the same point during the PWM cycle. So the effect of the ripple should be similar every time. I\u0026rsquo;m also averaging 32 measurements which further helps to smooth the value I\u0026rsquo;m using to calculate the duty cycle. So flicker is gone as well as you can see below.\nAfter averaging the ADC readings, the duty cycle stays rock solid Now for the transfer function. My first try was exponential. The problem with that was that it gave away too much of the pot range for very low brightness levels. I played around with this for quite some time and finally settled for a combination of linear (at the very low end of the range) and exponential (for everything above that). Also, two of my dimmers can be fully turned off by turning the dimmer all the way to the left. Their power supply is always on and the light is only controlled by the pot so I need to be able to really turn them off (not only down). The third one has a slightly different transfer function that only allows to turn it down to 2% or so. That one has its power supply controlled by a conventional light switch so I don\u0026rsquo;t want the pot to completely turn it off.\nSame at lower duty cycles The result # After all, I\u0026rsquo;m very happy with the result. There is no noticable power dissipation on the board. There certainly is a bit of dissipation but the board doesn\u0026rsquo;t heat up noticably so I\u0026rsquo;d say its clearly below a watt.\nThe components have cost me around $10 per board. Some stuff like the connectors I have bought a flea markets, they can be surprisingly expensive through regular retail channels. The PCBs are home-made so they have cost me a considerable amount of time but not much in terms of cash.\nLM5111-2M is the inverting variant They are, furthermore, controlled by a simple pot, produce no audible noise and can be finely dimmed just as planned. So I can proudly state that all the requirements have been met.\nIf you\u0026rsquo;re in need of a dimmer and have a soldering iron and a bit of spare time I can only encourage you to build your own. It\u0026rsquo;s not too hard, needs only few components and is very doable on a prototyping board if you don\u0026rsquo;t want to etch or mill your own board.\nAs always, attached is a zip file (file no longer available) with all the eagle files, board layouts, schematic as well as the software.\n","date":"19 February 2016","externalUrl":null,"permalink":"/posts/pwm-dimmer-for-led-lighting/","section":"posts","summary":" Finished LED dimmer I have recently moved to a new apartment and was looking for a PWM dimmer to control some 12V LED strips. I thought that should be easy enough nowadays but it proved more difficult than I thought. All I found either didn’t meet my requirements, were uggly or expensive. So I decided to build my own, tailor-made to my needs.\n","title":"PWM Dimmer for LED Lighting","type":"posts"},{"content":"There have been two previous posts on this project: one on the concept and the hardware and one on hardware testing. You probably want to check them out first if you\u0026rsquo;re not yet familiar with this project. Or even better: Click here for an overview over this project.\nMaintaining an input voltage of 17 volts even if that means a lower-than-desirable voltage at the output Now that we know that we have a functioning MPPT solar charger we are ready to talk about the software (or the sketch as the Arduino folks call it). It\u0026rsquo;s quite simple, really. So this will be a short post. And yes, you can download the sketch. There is a link at the end of this post. As always, I appreciate any feedback, comments and the like.\nThere is a number of basic tasks the arduino needs to perform in order for this shield to be useful. I\u0026rsquo;ll go through them one by one.\nControlling the DC-DC converter # At the heart of this project there is a synchronous step-down (or buck) DC-DC converter that is controlled by a PWM signal from the arduino. So one of the tasks is to set the frequency and duty cycle of that PWM signal.\nWe let the PWM signal run at the maximum frequency the arduino allows with an 8 bit resulution. Thats simply 16MHz (the Arduino\u0026rsquo;s frequency) divided by 256 (the 8 bit resolution), or 62.5 kHz. So the prescaler will be 1.\nAs you can see from the shields\u0026rsquo;s schematic, we need to output the PWM signal from Pin 6 (by the Arduino\u0026rsquo;s pin numbering, not Atmel\u0026rsquo;s). In order to do this kind of low-level stuff you\u0026rsquo;ll have to read the Atmega328\u0026rsquo;s data sheet. There is usually no Arduino-ish shortcut if you really need to controll what\u0026rsquo;s going on.\nLuckily it\u0026rsquo;s just a few lines of code to set things up. All in the function buck_setup(). There are three more little functions to control the DC-DC controller once it\u0026rsquo;s set up:\nbuck_enable() and buck_disable() are very simple and just turn it on and off, respectively. buck_duty(uint8_t duty) is only slightly more involved. It changes the duty cycle to the value you pass to it. Besides that it ensures that the duty cycle stays within certain limits.\nTest setup with resistor-based dummy load You don\u0026rsquo;t want it to go to 100% since in order to keep the bootstrap capacitor C6 charged you need a little bit of off-time. In order to drive the upper FET you need a voltage higher than the panel\u0026rsquo;s voltage and that\u0026rsquo;s exactly what C6 is for. So we enforce an upper limit on the duty cycle.\nLikewise, you don\u0026rsquo;t want your duty cycle to go below 50% because in that case you would be pumping energy from the battery to the pannel. A synchronous step-down converter is basically the same thing as a synchronous step-up (aka boost) converter with input and output confused. So we also want to enforce a lower limit on the duty cycle.\nThe upper and lower limits are set through the #defines DUTY_CYCLE_MINIMUM and DUTY_CYCLE_MAXIMUM.\nMeasuring voltage and current # The shield has all the hardware necessary to measure both voltage and current both at the input as well as on the output. We\u0026rsquo;ll just need to write some simple software to make good use of that hardware.\nUnlike with the PWM singal where we had to do some low-level bit fiddling ourselfs we can just rely on convenient Arduino library functions to do the job. Basically, analogRead() is all we need here.\nNicely regulating so that the input stays at 17 volts I\u0026rsquo;ve written a function called read_values() that uses analogRead() to read all 4 values (input voltage, output voltage, input current and output current) 16 times each, averages the results and converts the ADC reading to proper voltages and currents.\nThe necessary multipliers are defined as floats in VIN_MULTIPLIER, VOUT_MULTIPLIER, IIN_MULTIPLIER and IOUT_MULTIPLIER. I\u0026rsquo;m doing all the voltage and current measurements in floating math. Yes, this is not at all efficient but we don\u0026rsquo;t need the Arduino\u0026rsquo;s computational power for anything else most of the time so this is fine here. Just keep in mind that you can save a lot of resources here if you ever need to do so.\nDisplaying voltage and current on the LCD # Our hardware also involves a 2 lines x 16 characters LCD so we can show the world what we are measuring. Again, we can rely on standard Arduino functionality to do the job. There is an LCD library that does everything we need.\nSo my function write_display() can focus entirely on formatting. The upper line shows the voltages in Volts, the lower line shows the currents in Milliamps. The input is on the left hand side of the display, the output on the right.\nDeciding what to do # In the first section we\u0026rsquo;ve discussed the functions necessary to controll the DC-DC converter. But in order to use those functions, the Arduino needs to first decide what to do.\n66% duty cycle at 21V input voltage gives the desired 13.8V at the output This is where the function buck_update() comes into play. You could consider this the heart of this sketch. This is where all the relevant decisions are made. When to turn the converter on, when to turn it off, when to increase the duty cycle, when to decrease it\u0026hellip; You get the idea.\nThe behaviour of buck_update() is controlled by 8 #defines. I list them here together with the values I have used:\n#define ENABLE_VOLTAGE 18.0 #define DISABLE_VOLTAGE 15.0 #define INPUT_TARGET_VOLTAGE 17.0 #define OUTPUT_TARGET_VOLTAGE_LOW 13.8 #define OUTPUT_TARGET_VOLTAGE_HIGH 13.9 #define INPUT_CURRENT_LIMIT 2000.0 #define OUTPUT_CURRENT_LIMIT 3000.0 #define INPUT_CURRENT_MINIMUM 0.0\nI think they are quite self-explanatory, especially if you look at how they are used inside buck_update. It\u0026rsquo;s quite simple: If the panel\u0026rsquo;s voltage rises above 18V, turn the converter on. Once the converter is on, try to archieve a panel voltage of 17V without exceeding 13.9V at the output. If the panel\u0026rsquo;s voltage drops below 15V turn the converter off again.\nAt 55% duty cycle with a 16.9V input voltage we\u0026rsquo;re getting only around 9.2V at the output Besides that the function is also looking at the input and output current and makes sure certain limits are not exceeded. But with a 30W panel it should never be possible to reach those limits anyway.\nPutting it all together # Now all we need to do in the loop() function is calling read_values(), buck_update() and write_display(). Since writing to the LCD is quite slow we are only doing it every 32nd time we read the values and update the PWM signal.\nWith this sketch I\u0026rsquo;ve hooked the MPPT Solar Charger up to my lab power supply. (a Keysight E3645A, my newest toy *g*) and my extremely simple but occasionally useful resistor-based dummy load.\nThe enable and disable voltages are simple and work as expected. Maximum output volage is also not tricky. If the voltage at the output goes too high, the duty cycle is decreased and everything is fine again.\nThere\u0026rsquo;s not much to photograph when you\u0026rsquo;re writing and testing software More interesting was to see how the shield would regulate when faced with a limited current budget at the input. For that the supply was set to a voltage of 21V (about a 12V solar panel\u0026rsquo;s open-circuit voltage) with a current limit of 100mA to 500mA. That\u0026rsquo;s quite a nasty supply, quite a bit trickier to handle than a real solar panel. Try to pull just a bit too much current and the voltage will drop to zero\u0026hellip;\nAlso, the resistors at the output are not a realistic load for the converter. A car battery will pull no current at 12 volts or so (unless overly discharged) but will quickly start to sink large currents when the voltage goes just a bit higher and the battery is charging.\nBut I think the setup is good enough to test the sketch. And it handles the challenge quite well. With all resistors on (i.e a 100/6 ohms load) and a 300mA current limit, the input voltage sits at 17V (our target input voltage) while 9.25V appear at the output. At 400mA, the output voltage rises to 10.7V with the input still at 17V. At 600mA the input is still at 17V but with the output now at 13.15V. If I take the current limit even higher, the output voltage rises to 13.82V but not any higher, just as we want. The input voltage rises to 21V (since this is a lab supply and not a panel) with a corresponding drop in current to 530mA.\nQuite realistic: The charger is pulling as much current as it can with the current limit at 530mA and reaches an output voltage just above 12 volts I\u0026rsquo;m honestly quite happy with the project as it is now. The idea definitely works and I\u0026rsquo;m motivated to design a new, deployable version with some fancy features that will use much less power at the same time. I\u0026rsquo;ve already done quite some work on that new version but it will take another few weeks until I get to describe that project here.\nUntil then I will show you some other, smaller projects that I\u0026rsquo;ve already finished but didn\u0026rsquo;t have time to document yet. So you will first see a number of smaller, simpler projects over the next few weeks.\nBefore I forget: There\u0026rsquo;s the Arduino sketch for download (file no longer available). And click here for an overview over this project.\nUpdate: Now there\u0026rsquo;s an entirely new design.\n","date":"12 February 2016","externalUrl":null,"permalink":"/posts/arduino-mppt-solar-charger-shield-software/","section":"posts","summary":"There have been two previous posts on this project: one on the concept and the hardware and one on hardware testing. You probably want to check them out first if you’re not yet familiar with this project. Or even better: Click here for an overview over this project.\n","title":"Arduino MPPT Solar Charger Shield – Software","type":"posts"},{"content":" First tests are being performed on the Solar Charger Shield In my last post I\u0026rsquo;ve introduced a proof-of-concept Arduino solar charger shield. I went through the hardware as well as the way it works - or at least is intended to work. It was prominently linked on dangerousprototypes.com as well as some other sites and got quite a bit of publicity as a result. Thank you all for sharing this post.\nBy the way: here\u0026rsquo;s an overview over all posts on this project.\nDUT hooked up to my Constant Current Dummy Load This time I\u0026rsquo;ll show you some results of the testing that I\u0026rsquo;ve done. The basic test setup is shown above: The solar charger is hooked up to my home-brew constant current dummy load, together with a pair of DMMs at the output in order to precisely monitor output voltage and current. For the input I\u0026rsquo;m relying on the lab supply to provide these measurements. And yes, the shield does its own measurements of both input and output currents and voltages. Once calibrated they are even quite accurate but I won\u0026rsquo;t rely on them for things as calculating the converter\u0026rsquo;s efficiency.\nVin=17V, no load But first we need to see if our converter works at all. As the scope screenshot above demonstrates - it does. For all the tests shown in this post, the input voltage was provided by a lab supply set to 17 volts. So we\u0026rsquo;re not yet testing the software and its capability to draw just the right amount of current.\nVin=17V, no load As you can see, since the converter can draw any (reasonable) current at the input, it provides the maximum voltage (set in software) of 13.8V at its output. In order to do that, the upper FET is on approximately 80% of the time. The signals all seem nice an clean and there is no noticable ripple at the output at 1V/div and no load. And the switching frequency is 62.5kHz (16MHz / 256) as expected.\nVin=17V, Iout=1A At 1 Amp output current, the software has to increase the duty cycle somewhat to 82% (above) and even further to 84% at 2A (below). Besides that, everything still looks very similar under load conditions.\nVin=17V, Iout=2A In my last post I\u0026rsquo;ve raised the question if the FET driver\u0026rsquo;s dead time of 540ns according to the datasheet is not a bit excessive. Well, let\u0026rsquo;s look at the dead time on the scope. First of all we can observe that the dead time of the IR2104 is in line with the data sheet. I don\u0026rsquo;t have it in front of me right now to check the min/max specs but the measured 522ns seem reasonably close to the theoretical 540ns.\nThe IR2104 has a built-in dead time of 540ns according to the data sheet. We\u0026rsquo;re measuring 522ns here - close enough. From looking at the screen shot above, the dead time does seem a bit long. The reason dead time is introduced is to prevent shoot-through. If both FETs are on there is a short-circuit from the input to ground. Together with the input capacity and the FETs low Rds-on, very large currents could flow, possibly destroying the FETs and at least detoriating efficiency. So introducing a bit of time when both transistors are off seems reasonable. But too much of it also costs efficiency since current has to flow through the diode instead of the lower FET. The main reason for using a synchronous topology is to prevent this in order to gain efficiency. So obviously one has to find a balance. I think here we\u0026rsquo;re a bit far on the conservative side but never mind for now.\nLet some current flow So now that our converter is working, let\u0026rsquo;s take a look at efficiency. I\u0026rsquo;ve measured the efficiency at output currents ranging from 100mA to 2.6A in 100mA steps with the input voltage at 17V. I didn\u0026rsquo;t use the sense-wires connections on the lab supply so I had to compensate for the voltage drop on the input leads manually.\nThere was a drop of up to 220mV on the input leads so the voltage reading of the lab supply is not quite accurate The results are quite impressive:\n95.5% @ 100mA (worst) 96.9% @ 200mA 97.9% @ 400mA 98.1% @ 800mA (best) 97.1% @ 1600mA 95.7% at 2600mA So the efficiency is constantly at a very high 95.5% and better over the entire current range of interest.\nThis little dummy load is really useful The resulting loss is less than 1.6 Watts @ 2.6A out. As a result, the shield never gets hot, even when running at this power level for a while.\nNote that this is quite a bit more power than the converter was designed for. 37W as opposed to the 30W I designed it for. The FETs could even handle much more. The limiting factor would likely be the coil reaching saturation. Unfortunately my lab supply doesn\u0026rsquo;t supply any more than 2.2A so I can\u0026rsquo;t push it any further.\nShield performs well even beyond 30W spec One thing to note is that these efficiency figures don\u0026rsquo;t take into account the power consumed by the arduino, the display, the fet driver, current monitoring ICs and so on. This brings us to the last topic for now: The current consumed by the various components. I did these measurements mainly in order to understand how to limit power consumption in a later version. To me, this shield is only a proof of concept and so reducing power consumption was never an issue.\nHere are the results:\nArduino: 48.7mA LCD backlight: 8.9mA LCD excluding backlight: 1.148mA FET driver (standby): 106.56uA FET driver (62.5kHz, Iout=0): 2847uA FET driver (62.5kHz, Iout=2.5A): 2937uA Current sensors (each): 48.6uA So the arduino itself is using up the lion\u0026rsquo;s share of current. Next comes the LCD backlight. Nothing unexpected so far. The LCD without backlight still consumes a considerable 1.15mA, no matter if it\u0026rsquo;s on or off. The FET driver uses around 2.9mA when on and only about 0.1mA when off. Output current only has a minor impact. The current sensors don\u0026rsquo;t use up much - less than 0.1mA for both.\nCheck out my next post for a closer look at the software or here for an overview over this project.\n","date":"3 February 2016","externalUrl":null,"permalink":"/posts/arduino-mppt-solar-charger-shield-testing/","section":"posts","summary":" First tests are being performed on the Solar Charger Shield In my last post I’ve introduced a proof-of-concept Arduino solar charger shield. I went through the hardware as well as the way it works - or at least is intended to work. It was prominently linked on dangerousprototypes.com as well as some other sites and got quite a bit of publicity as a result. Thank you all for sharing this post.\n","title":"Arduino MPPT Solar Charger Shield - Testing","type":"posts"},{"content":" A friend has approached me regarding his solar project. He wants to install a solar panel together with a battery and an inverter in order to have power at his allotment garden. He had looked at a hobbyist project where an arduino was used to build a MPPT (maximum point of power tracking) charge controller. I took a look at the design, liked a lot of what I saw and decided to build something similar.\nThe basic idea behind an MPPT solar charger is simple. A solar panel has a certain voltage (in the region of 17 to 18 volts for a 12 volts pannel, somwhat dependent on temperature) at which it provides most power. So as long as the battery needs charging, you want to pull just as much current to reach this voltage. But once the battery is full you need to avoid overcharging the battery. So you want to maintain a maximum voltage for your battery (somewhere around 13.8 volts for a 12 volt lead acid battery) and no longer care about the pannel\u0026rsquo;s voltage.\nSo the charger needs to convert an input voltage of 17-18V to an output voltage of 12-14V as efficiently as possible. Obviously, a step-down (aka buck) switching converter is ideally suited for the job. However, a typical DC-DC converter is designed to maintain a stable voltage at it\u0026rsquo;s output, independent of it\u0026rsquo;s input voltage. As described above, our requirements here are different.\nSwitching converters are controlled by the duty cycle of a (typically) fixed-frequency PWM signal. So a microcontroller could be used to do the job. In most applications, this wouldn\u0026rsquo;t work that well because a microcontroller would be too slow to react to sudden changes in load or input voltage. But this is not much of a concern in our solar application: Sun intensity changes within seconds at best and the battery will absorb any sudden changes in load. So if we adjust our duty cycle a few times per second we\u0026rsquo;ll be more than fine. And that\u0026rsquo;s easy to do with a microcontroller.\nThe next step was to figure out at which frequency to run our converter. An arduino runns at 16MHz. At a 8-bit resolution, this gives us a maximum PWM frequency of 62.5kHz. That\u0026rsquo;s a pretty slow speed for a switching DC-DC converter nowadays. Most modern designs run in the hundreds of kHz to a few MHz. The main reason of using higher and higher switching frequencies is size. The higher the frequency, the smaller the inductor can be. For us, using a somewhat bigger inductor is totally acceptable. And in terms of efficiency, a lower frequency is even preferable since it reduces switching losses.\nThe project here is intended mainly as a proof on concept. I expect it to be fully functional but it will consume quite a bit of power while sitting idle. The display (including backlight) is always on, the same goes for all the other components. But the main drain on the battery will be the Arduino itself which consumes around 50mA when running at 16MHz. That might not sound like much but it will add up during the many hours the solar panel doesn\u0026rsquo;t produce any power. The system will be installed in Zürich, Switzerland so you can\u0026rsquo;t count on having 8 hours of sunshine every day. In winter, there might be snow on the panel, preventing it from producing anything for weeks in an extreme case. So a productive system should draw hardly any current (say \u0026lt;1mA) when not doing anything useful.\nAt least for now, the we\u0026rsquo;ll be using a 30W 12V monocrystaline panel and a 45Ah car battery. So I\u0026rsquo;ve scaled this converter to comfortably handle 30W input power which translates to about 1.8 amps at the input and 2.5 amps at the output.\nAs deba168\u0026rsquo;s design, I\u0026rsquo;m using a synchronous buck topology. If you\u0026rsquo;re new to switchers, you might want to check out this wiki page. If you\u0026rsquo;re serious about designing your own you might want to read Sanjaya Maniktala\u0026rsquo;s \u0026lsquo;Switching Power Supplies A - Z\u0026rsquo;, it\u0026rsquo;s a great book. I\u0026rsquo;ve also read his other two books on the topic but this is the one I love the most, especially to start with. I\u0026rsquo;m also using the same half bridge driver (IR2104) even though I find the 540ns off time somewhat excessive. But I like the enable/pwm input signals as opposed to having to drive each fet individually and I found this feature to be somewhat rare.\nApart from that I\u0026rsquo;ve really done my own design, mainly using parts I\u0026rsquo;ve still had from previous projects. As most stuff I build, it\u0026rsquo;s entirely SMD, except for the input and output capacitors. Not only are SMS designs smaller in size. The parts are much easier to source (and often cheaper) than conventional through-hole components nowadays. And contrary to popular belief, with a bit of practice I find them easier and faster to solder.\nThe FETs are IPB136N08N3, a quite large surface-mount type that I use quite frequently. They have a 11mOhms Rds-on resistance which will be great for efficiency. They are also easy to drive in terms of gate capacitance. Probably a bit oversized for the 2.5 amps we\u0026rsquo;re trying to switch here but I still have some here and they\u0026rsquo;re not expensive, around 70 cents each. The inductor is a 100uH Coilcraft MSS1583 with a resistance of 0.103 ohms and a 2.8A current rating. 100uH is a bit much at full load, 68uH would easily do. But the system will spend most time at moderate loads (remember, this is not California). I\u0026rsquo;ve ordered a 68uH as well and intend to use it for a later design or maybe to see what difference it makes. Input and output caps are quite a bit oversized as well, 680uF 35V at the input and 820uH 25V at the output. They are from the Panasonic FR series which I like using for my switchers since they work well at frequencies up to a few hundred kHz while being afordable and having very high ripple current ratings.\nI\u0026rsquo;m doing voltage and current sensing at both input and output. I\u0026rsquo;ve decided to use conventional high-side, shunt resistor based current sensing. The Texas INA213 are fairly precise, work up to 26 volts and have a fixed gain of 50. Also here, I still had some left over from my dummy load project. Most components are much cheaper if you buy 10 in stead of just one or two so I tend to buy 10 ;-)\nI\u0026rsquo;ve also added a standard 2x16 characters LCD display so I can see what\u0026rsquo;s going on. And you may have noticed that I\u0026rsquo;ve put a zero ohms resistor at several places. This will enable me to easily measure current consumption of the respective sub-circuit. As mentioned before, current consumption will play a major role in the final design so I\u0026rsquo;m interested to see how much juice is used by certain components under real-life conditions.\nBesided the connectors for the panel and the battery, I have added a separate connector for the power supply. This is handy for early testing and programming. Just connecting this supply will power up the entire system. The arduino, the display, the converter and all. But there is not yet any load at the converter\u0026rsquo;s output and no supply at it\u0026rsquo;s input. So I can start programming the Arduino, start measuring and displaying voltages and currents and even turn on the converter to see if everything behaves as expected. And since there is nothing at the converter\u0026rsquo;s input and output, not much can go wrong. I don\u0026rsquo;t risk blowing up the FETs due to a bug in the program or a problem with the board. Only once I\u0026rsquo;m confident that everything works as expected I will connect a panel and a battery. At that point, the 12V input can just be connected to the battery as well.\nI\u0026rsquo;ve written a simple sketch for the Arduino that measures voltage and current at the input and output and displays the result on the LCD. Once the input voltage exceeds a certain threshold, it will enable the half bridge driver and start switching. It starts at a duty cycle that will produce an output voltage equal to the current battery voltage. That means that no current will flow to the battery yet so the converter can start up with no load. Once the switcher is turned on, the Arduino will adjust the duty cycle about 4 times a second. If the input voltage is above its optimum and the battery has not yet reached its maximum voltage, the duty cycle will be increased by 1/255. If either the battery voltage is too high or the input voltage is below its optimum, the duty cycle is decreased by 1/255. There are also some checks for overcurrent at the input and output.\nThe switcher is turned off when the input voltage or the output current falls below a pre-defined threshold. This is a synchronous converter so current can flow back from the battery to the panel. We can\u0026rsquo;t just wait for the input voltage to fall. As long as the switcher is on, the input will never fall because energy is pumped from the battery to the panel. A synchronous buck converter is just the same as a synchronous boost converter with its inputs and outputs inverted. So we need to make sure current is actually flowing to the battery. Luckily, a car battery will always draw a clearly non-zero current at 13.8 volts, even when fully charged. So when current stops flowing to the battery, we know the panel is no longer able to provide any power and we can or rather must turn the converter off.\nThis post ist getting rather long so I\u0026rsquo;ll stop here and will write another post later about how the circuit has been performing and what I have learned so far. I guess this project will turn into a little series, maybe with further (and hopefully improved) versions being developped. Looking forward to that.\nBefore I forget: Here\u0026rsquo;s the eagle files as well as schematic and layout PDFs as a zip file: SolarCharger_Rev1 (file no longer available).\nUpdate: Click here to see how the shield performs or here for an overview over this project.\nUpdate 2: Now there is an entirely new design.\n","date":"21 January 2016","externalUrl":null,"permalink":"/posts/arduino-mppt-solar-charger-shield/","section":"posts","summary":" A friend has approached me regarding his solar project. He wants to install a solar panel together with a battery and an inverter in order to have power at his allotment garden. He had looked at a hobbyist project where an arduino was used to build a MPPT (maximum point of power tracking) charge controller. I took a look at the design, liked a lot of what I saw and decided to build something similar.\n","title":"Arduino MPPT Solar Charger Shield","type":"posts"},{"content":"","date":"4 August 2015","externalUrl":null,"permalink":"/tags/boost-converter/","section":"tags","summary":"","title":"boost-converter","type":"tags"},{"content":" Finished 5V to 12V USB boost converter I frequently need a low-power supply to run a microcontroller system. Typically, one uses a lab power for such purposes. But at least on the desk where I do the programming I don\u0026rsquo;t have one. Since these systems typically consume little current it would be handy to be able to power them from USB. Most of my devices have on-board regulators so the voltage is rather uncritical. For 3.3 volt devices, the 5V from USB is just right. But others have a 5V regulator so they need a higher supply voltage. And even others might even need 12 volts.\nFully assembled PCB So I decided to build a small low-power boost converter with a USB plug on its input. The output voltage is set by a pair of resistors. So once built the output voltage is fix but my idea is to build several of them anyway. So some will produce 12V while others will produce 7.5V. The latter is intended to power all those systems with on-board 5V regulators. Of course, you could use a trimmer or pot if you wanted a variable voltage version. However, the feedback loop requires a capacitor for stability and its value also depends on output voltage. You might well find a value that results in stable operation over a say 6 - 12V range, but I haven\u0026rsquo;t tried that.\nBottom side I had a look for a suitable integrated switcher IC and found the Texas Instruments LMR62014. It comes in a small SOT23-5 package. It switches at a high frequency of 1.6MHz which will keep the other components small, too. It switches up to 1.4 amps. It\u0026rsquo;s easy to use. And even afordable, around 1.50 a piece. The datasheet is very helpful when it comes to PCB layout. It includes a two-layer sample layout that works even with hobbyist-sized components (0805, 1206 for the input and output capacitors).\nNot a bad heat sink Generally, layout is important with switch-mode DC-DC converters. Their operation requires switching square-wave power signals (as opposed to just logical-level signals where little current flows). And that requires careful layout in order to minimize stray inductance, mainly. Things are more forgiving when you work with relatively slow (say 100kHz) switchers but get much more demanding when switching at higher frequencies. There has been a steady trend to ever-higher frequencies and 1.6MHz is fairly high even by 2015 standards. So I was very happy to have a nice layout example to start with.\nTop side As you can see from the photo above, the thing is small, only 26 x 14mm. Also note how the layout makes the components magically fit together without any long traces and few vias.\nHome brew constant current dummy load in action So far, I\u0026rsquo;ve built two units, one running at 12V, the other at 7.5V. Theoretically, one should be able to pull 580mA and 930mA from them, respectively. Of course, these are theoretical figures assuming no losses. Also, the 1.4A rating on the IC is likely the current limit at the top of the switching cycle (the datasheet will tell you or course but I don\u0026rsquo;t have the PDF open right now), not an average. And thermal considerations might also put limits on continuous currents. More on that later. And don\u0026rsquo;t expect to be able to pull 1.4A from a random USB port (which would violate the USB specifications anyway). But given my use-case for these things I\u0026rsquo;m entirely happy if I can pull a 100mA or so. And that should work comfortably.\nSwitcher IC: 70 degrees @ 200mA Diode: 58 degrees @ 200mA Coil: 50 degrees @ 200mA I\u0026rsquo;ve pushed both versions to their respective limits on the bench, using a stiff 5V supply and my home-brew constant current dummy load (link). With case temperatures approaching 100 degrees centigrade I was able to pull around 250mA of continuous current from the 12V version. The ICs include thermal limiting so you don\u0026rsquo;t need to worry too much about damaging them when performing this kind of tests. As you can see on the photos, I did these tests with the naked PCBs sitting in a vise which probabely made a not-so-bad heatsink for the board as a whole.\nOutput voltage folds back when the switcher gets too hot I\u0026rsquo;ve encountered slight stability problems with the 12V version (but not with the 7.5V one). There is some oscillation at currents above 200mA or so. Changing the value of the compensation capacitor changed the frequency and amplitude but I haven\u0026rsquo;t managed to get rid of it entirely. But anyway, I won\u0026rsquo;t run them at 200mA so I haven\u0026rsquo;t put much more effort into this.\nClose up of the final product The finished units have a USB wire on the input and a arduino-compatible plug on the output. To protect against short-circuits I\u0026rsquo;ve put them in a piece of shrinking hose which is a bit of a themal nightmare of course. There is also a voltage drop over the USB cable which means the input voltage seen by the converter is below 5V even with a perfectly stiff USB port. Which in turn means more work for our converter, making things worse.\nShrinking hose doesn\u0026rsquo;t help in keeping it cool I have frequently used the 7.5V version to power my Ultrasonic Anemometer which pulls around 60mA. That\u0026rsquo;s the kind of application that I had in mind for this little device and it works well for that. It hardly gets warm at all and provides reliable power on my desk without the need for a lab power supply.\nAttached the Eagle files as well as a PDF of the schematic and layout: USB_BoostConverter (file no longer available)\n","date":"4 August 2015","externalUrl":null,"permalink":"/posts/usb-boost-converter/","section":"posts","summary":" Finished 5V to 12V USB boost converter I frequently need a low-power supply to run a microcontroller system. Typically, one uses a lab power for such purposes. But at least on the desk where I do the programming I don’t have one. Since these systems typically consume little current it would be handy to be able to power them from USB. Most of my devices have on-board regulators so the voltage is rather uncritical. For 3.3 volt devices, the 5V from USB is just right. But others have a 5V regulator so they need a higher supply voltage. And even others might even need 12 volts.\n","title":"USB Boost Converter","type":"posts"},{"content":" The world has been waiting since 1989, now it\u0026rsquo;s finally here. The 3rd edition of the classic book The Art of Electronics by Paul Horowitz and Winfield Hill is finally out. My (Amazon.de pre-ordered) copy just arrived today.\nIt\u0026rsquo;s slightly disappointing in size. It quite matches the 2nd edition and grew only about 50 pages in volume. Haven\u0026rsquo;t really had time to read any of it or compare the table of content.\nFeel free to leave any of your impressions on this or the last edition in the comments below.\nUpdate as of August 4th, 2015\nI\u0026rsquo;ve finally found the time to read the first 300 or so pages of the 3rd edition. Some of the material is very familiar to readers of the 2nd edition. But there is plenty of stuff that was not yet part of the 2nd edition. Such as a very comprehensive coverage of JFET amplifiers. Other chapters have disapeared entirely such as the one on high frequency / RF circuits. In my opinion it makes perfectly sense to own and read (!) both editions. And there is a second volume (called the AoE x-chapters) to be released at some time in the future (another 30 years?) . I\u0026rsquo;m looking forward to it.\n","date":"7 April 2015","externalUrl":null,"permalink":"/posts/the-art-of-electronics-third-edidition/","section":"posts","summary":" The world has been waiting since 1989, now it’s finally here. The 3rd edition of the classic book The Art of Electronics by Paul Horowitz and Winfield Hill is finally out. My (Amazon.de pre-ordered) copy just arrived today.\n","title":"The Art of Electronics - Third Edition","type":"posts"},{"content":" In a recent post I\u0026rsquo;ve offered a free PCB on a first-come first-served basis. I\u0026rsquo;ll be happy to mail the board together with some components to Mumbai, India tomorrow. It goes to Parth Sane, a student, homebrewer and soon-to-be ham radio operator.\n@Parth: Please share some photos of the finished inductance meter once you\u0026rsquo;re done.\n","date":"8 March 2015","externalUrl":null,"permalink":"/posts/inductance-meter-pcb-goes-to-india/","section":"posts","summary":" In a recent post I’ve offered a free PCB on a first-come first-served basis. I’ll be happy to mail the board together with some components to Mumbai, India tomorrow. It goes to Parth Sane, a student, homebrewer and soon-to-be ham radio operator.\n","title":"Inductance Meter PCB goes to India","type":"posts"},{"content":"It\u0026rsquo;s been a while since I posted the last update on the anemometer project. The reason for this is that I\u0026rsquo;m struggling with the aerodynamical design.\nBy the way: Click here for an overview over the ultrasonic anemometer project: /projects/arduino-ultrasonic-anemometer/\nFor my very first tests I had misappropriated my wife\u0026rsquo;s hair dryer to generate some wind. Of course the results wereneither reliable nor repeatable so I built myself this ghetto wind tunnel:\nIt\u0026rsquo;s basically a 120x120mm square tube, made of cardboard and about 1.4m in lenght.\nIt\u0026rsquo;s powered by a powerful 120mm size brushless fan drawing some 2.25 amps at 12 volts. I don\u0026rsquo;t know about the air throughput but it generates a loooot of wind for a fan this size.\nThe legs put it at the right height for the anemometer prototype. There are two holes at the bottom through which the anemometer\u0026rsquo;s arms can be inserted. The transducers are then nicely centered inside the cardboard tube.\nI can regulate the fan speed using a simple LM317-based regulator. It might look familiar to some of you, it has it\u0026rsquo;s own post here.\nUnfortunately, the LM317 is only good up to 1.5A so I have to connect the fan directly to my 12V supply in order to run the fan at maximum speed.\nAs you know, the main indicator of wind speed is the phase shift between the transmitted and received signal. The distance is 0.21m and speed of sound is approximately 340m/s so with no wind, the signal travels about 618us. Signal frequency is 40kHz so one full wave corresponds to 25us. So a full wave (or a phase shift of 360 degrees) translates to a wind speed of around 14m/s or 50km/h.\nNote that we usually calculate the difference in phase shift measured forth and back.In that case, the signal already repeats at half that wind speed or 7m/s.\nNow my impression was that I don\u0026rsquo;t get nearly as much phase shift as I should. What makes this difficult is that I don\u0026rsquo;t know the true wind speed so maybe the wind is just not as strong as I think it is.\nI went back and checked my code but didn\u0026rsquo;t find any bugs there. So I attached the scope to the transducers and looked at the signals directly. And the scope confirmed what I saw on the LCD display. So if there\u0026rsquo;s a good news it\u0026rsquo;s that both the electronics as well as the code seem to do what they should: They faithfully report what they get from the ultrasonic transducers. So maybe it\u0026rsquo;s just the physical design of my prototype that poses too much resistance to the wind and therefore causing too much of a dead wind effect.\nI have done some more testing and will follow up on this shortly. Maybe some of you have a piece of advise for me\u0026hellip;\n","date":"16 February 2015","externalUrl":null,"permalink":"/posts/arduino-ultrasionic-anemometer-part-14-wind-tunnel-testing/","section":"posts","summary":"It’s been a while since I posted the last update on the anemometer project. The reason for this is that I’m struggling with the aerodynamical design.\nBy the way: Click here for an overview over the ultrasonic anemometer project: /projects/arduino-ultrasonic-anemometer/\n","title":"Arduino Ultrasonic Anemometer Part 14: Wind Tunnel Testing","type":"posts"},{"content":"There have now been several posts on my inductance meter project so I thought this might be good to have an overview over the various posts including the download files.\nI\u0026rsquo;d like to thank dangerousprototoypes.com, electronics-lab.com and others who helped to make this project quite popular around the web. I appreciate it.\nHere\u0026rsquo;s a chronological overview over all related posts:\n/posts/arduino-based-inductance-meter/ /posts/stand-alone-inductance-meter/ /posts/stand-alone-incuctance-meter-finished/ /posts/free-inductance-meter-pcb-first-come-first-served/ /posts/standalone-inductance-meter-on-a-etched-board/ And here are the downloads:\nArduino based meter, all in one zip: LMeterShield (file no longer available) Stand alone version, everything except software: InductanceMeter (file no longer available) Stand alone version, software only: LMeter (file no longer available) Gerber files for the stand alone L-Meter: InductanceMeter_Rev1_Gerbers (file no longer available) Or check out my repos on github.com: github.com/soldernerd/InductanceMeter_Hardware github.com/soldernerd/InductanceMeter_Software ","date":"16 February 2015","externalUrl":null,"permalink":"/projects/inductance-meter/","section":"posts","summary":"There have now been several posts on my inductance meter project so I thought this might be good to have an overview over the various posts including the download files.\n","title":"Inductance Meter","type":"posts"},{"content":"","date":"16 February 2015","externalUrl":null,"permalink":"/tags/lm317/","section":"tags","summary":"","title":"lm317","type":"tags"},{"content":" When I made the PCB for the stand-alone inductance meter, I erroneously used a SSOP footprint for the microcontroller (instead of the desired SOIC). The PIC is available in a SSOP package (PIC16F1963-I/SS instead of PIC16F1936-I/SO) but I didn\u0026rsquo;t have any at hand so I simply made a new board with a SOIC footprint.\nApart from the footprint, the SSOP board is identical to what I\u0026rsquo;ve finally used and is fully functional. If anyone is interested I\u0026rsquo;m happy to give it away for free - first come, first served.\nBy the way, I\u0026rsquo;m building a second inductance meter for my father who has asked me if he could get one, too. It\u0026rsquo;s technically identical but this time the 3D-printer had orange PLA in it so I used just that.\nBy pure coincident, the color just about matches the newer Agilent / Keysight multimeters ;-)\n","date":"15 February 2015","externalUrl":null,"permalink":"/posts/free-inductance-meter-pcb-first-come-first-served/","section":"posts","summary":" When I made the PCB for the stand-alone inductance meter, I erroneously used a SSOP footprint for the microcontroller (instead of the desired SOIC). The PIC is available in a SSOP package (PIC16F1963-I/SS instead of PIC16F1936-I/SO) but I didn’t have any at hand so I simply made a new board with a SOIC footprint.\n","title":"Free Inductance Meter PCB - first come, first served","type":"posts"},{"content":"","date":"22 January 2015","externalUrl":null,"permalink":"/tags/measuring-inductance/","section":"tags","summary":"","title":"measuring-inductance","type":"tags"},{"content":"If you\u0026rsquo;ve read my last post you\u0026rsquo;re already familiar with my Inductance Meter project: /posts/stand-alone-inductance-meter/. At that time the hardware was ready but there was no software yet. That\u0026rsquo;s been corrected, the inductance meter is now fully functional.\nFrom a high-level point of view the new software is very similar to the Arduino sketch I wrote for the Inductance Meter Shield (/posts/arduino-based-inductance-meter/). If you look a bit closer, you\u0026rsquo;ll notice some differences for several reasons:\nThis project uses an entirely different microcontroller: A PIC 16F1936* instead of the Atmel Atmega328 This code is written in C (for the MikroC for PIC compiler by Mikroelektronika), not Arduino-style C++ The display I\u0026rsquo;m using here comes with a I2C interface rather than the familiar Hitachi interface *: In an earlier version I wrote 16F1932 instead of 1936. Thanks to Ralph Doncaster for pointing this out to me. By the way, Ralph has his own blog at http://nerdralph.blogspot.ca which I regularly enjoy reading.\nI\u0026rsquo;ve noticed that the MikroC compiler is not very popular among hobbyists but I like using it. It\u0026rsquo;s entirely free as long as your compiled code does not exceed a certain size. You can use any features, any library, just anything for free when you\u0026rsquo;re getting started. Yes, once your projects get bigger you\u0026rsquo;ll run into the limit and will have to buy a license but it was worth the price to me.\nAs expected, the I2C display took me some time to get used to. It\u0026rsquo;s a MIDAS MCCOG21605B6W-BNMLWI (Farnell: 2063209). It seems to use a Hitachi-compatible controller with a I2C interface built on top of it. I like the concept and will probabely use one of these again. If there is a downside, it\u0026rsquo;s the data sheet. I had to do quite a bit of guessing and trial-and-error to get it working. I had used Hitachi-compatible MIDAS displays before so I had some idea what might work otherwise I might have given up. Examples?\nNo page numbering. Yes, this is a minor thing but have you ever seen a data sheet without page numbers? There is a reset pin. As many reset pins, it\u0026rsquo;s active-low. But the data sheet never says so. Not explicitly, not with a bar accross the RST, not with a ~RST. Absolutely nothing. It explains some of the Hitachi-functionality in great detail but does not really tell you that this functionality is not accessible over the I2C interface. Like Hitachi-compatible types, this display needs some start-up time before you configure it. Otherwise it will just not work. But the data sheet doesn\u0026rsquo;t mention that with a single word. But it\u0026rsquo;s all working fine now. The PIC16F1936 has more than enough ROM, RAM and processing power for this meter so don\u0026rsquo;t expect the code to be optimized in any way. It was just not necessary. It does most of the math in floating-point which bloats the (compiled) code size and is dead-slow on this kind of architecture but it\u0026rsquo;s still more than fast enough and only uses around half of the available RAM and ROM.\nI think the code itself is quite readable but don\u0026rsquo;t hesitate to ask if you have any questions. Here\u0026rsquo;s the code as zip: LMeter (file no longer available) ","date":"22 January 2015","externalUrl":null,"permalink":"/posts/stand-alone-incuctance-meter-finished/","section":"posts","summary":"If you’ve read my last post you’re already familiar with my Inductance Meter project: /posts/stand-alone-inductance-meter/. At that time the hardware was ready but there was no software yet. That’s been corrected, the inductance meter is now fully functional.\n","title":"Stand-alone Incuctance Meter Finished","type":"posts"},{"content":"","date":"13 January 2015","externalUrl":null,"permalink":"/tags/3d-printing/","section":"tags","summary":"","title":"3d-printing","type":"tags"},{"content":"","date":"13 January 2015","externalUrl":null,"permalink":"/tags/coil/","section":"tags","summary":"","title":"coil","type":"tags"},{"content":"","date":"13 January 2015","externalUrl":null,"permalink":"/tags/colpitts-oscillator/","section":"tags","summary":"","title":"colpitts-oscillator","type":"tags"},{"content":" Some of you may have seen my arduino-based inductance meter in this post: /posts/arduino-based-inductance-meter/. The guys at dangerousprototypes.com picked it up (http://dangerousprototypes.com/2014/12/16/arduino-based-inductance-meter/) and this blog got more visitors than I could ever have imagined. Thanks, dangerousprototypes.\nThe arduino-based meter works well and made a great proof-of-concept. But for everyday use you\u0026rsquo;re probabely not looking for an arduino solution but rather something that looks and feels more like a multimeter. That\u0026rsquo;s why I\u0026rsquo;m following up with this stand-alone version.\nSo this version is battery powered and comes complete with a 3D-printed case. It uses a mid-range PIC microcontroller, a PIC16F1936. Not that there\u0026rsquo;s much special about this model, I just happened to have some left from previous projects. I also thought about using a Atmel Atmega328, the same chip that is on the Arduino UNO.\nUsing an entirely different chip means I\u0026rsquo;ll have to write the software from scratch. But I felt that the Atmega328 was just too much of an overkill just to measure a frequency and control an LCD. They are quite a bit more expensive than the PIC, CHF 3.70 compared to CHF 1.90 @10pieces at Farnell where I get just about all my chips.\nTalking of the LCD: The one I\u0026rsquo;m using here comes with a I2C interface. It\u0026rsquo;s blue with a white backlight and 2x16 characters and really tiny. I bought 2 of them years ago because they were small and relatively cheap (around 15CHF) and don\u0026rsquo;t require so many precious I/O pins of your microcontroller. Somehow I never used them but here their small size makes them a good choice. I/O pins aren\u0026rsquo;t a constraint here obviously as most of the 28 pins are unused.\nI\u0026rsquo;m not yet familiar with the details of how they are controlled. I had a look at the data sheet and it looks like you send them just about the same commands like with the standard Hitachi compatible ones, just over I2C. But I expect to spend an evening or two figuring out the details.\nThe case was designed using FreeCAD. As the name suggest, it\u0026rsquo;s a free (and open-source) CAD design tool. This was only the second time I was using it but I found it quite easy to learn.\nI printed the case at the Zürich fab lab (zurich.fablab.ch) on one of their Ultimakers. Was my first 3D-printing project, thank you very much for your support, everyone.\nAs always, I\u0026rsquo;ll put all the files online as a zip. So you can download all the Eagles plus PDFs as well as the FreeCAD models. Here it is: InductanceMeter (file no longer available). I haven\u0026rsquo;t written any software yet but I\u0026rsquo;ll but that online, too, as soon as it\u0026rsquo;s finished.\nThe software is ready now. Klick here for the next post: /posts/stand-alone-incuctance-meter-finished/.\n","date":"13 January 2015","externalUrl":null,"permalink":"/posts/stand-alone-inductance-meter/","section":"posts","summary":" Some of you may have seen my arduino-based inductance meter in this post: /posts/arduino-based-inductance-meter/. The guys at dangerousprototypes.com picked it up (http://dangerousprototypes.com/2014/12/16/arduino-based-inductance-meter/) and this blog got more visitors than I could ever have imagined. Thanks, dangerousprototypes.\n","title":"Stand-alone Inductance Meter","type":"posts"},{"content":"","date":"13 January 2015","externalUrl":null,"permalink":"/tags/ultimaker/","section":"tags","summary":"","title":"ultimaker","type":"tags"},{"content":"It\u0026rsquo;s been a while since the last post of this series. As so often, the task turned out to be more demanding than I first thought. And then I was also entirely new to assembly language, got distracted by my Inductance Meter Project (/posts/arduino-based-inductance-meter/) and went on a skiing holiday. But finally, the promised library is ready.\nIf you’re new to my Arduino-based ultrasonic wind meter project, you might want to click here for an overview: /projects/arduino-ultrasonic-anemometer/. This is also where you find all the various downloads, including the new library.\nUsing the new library is easy:\n#include \u0026lt;anemometer.h\u0026gt; extern volatile anemometerResults_t *anemometerCalculationSet; extern volatile uint8_t anemometerStatus;\nanemometerSetup();\nYou can then access the results as follows (replace NORTH_TO_SOUTH with SOUTH_TO_NORTH, EAST_TO_WEST or WEST_TO_EAST as needed):\nanemometerCalculationSet\\[NORTH\\_TO\\_SOUTH\\].timeOfFlight anemometerCalculationSet\\[NORTH\\_TO\\_SOUTH\\].sine anemometerCalculationSet\\[SOUTH\\_TO\\_NORTH\\].cosine\nI\u0026rsquo;ll go through the meaning and usage of these one by one:\nanemometerSetup()\nThis function has to be called once before the anemometer can be used:\nvoid setup() { anemometerSetup(); }\nanemometerStatus\nanemometerStatus notifies your when a new set of measurements has been completed and is ready to use. Every time a new set is ready, anemometerStatus will be set to 1. You have to set it back to 0 once you\u0026rsquo;re done with your calculations.\nif(anemometerStatus==1) { /* use the results */ anemometerStatus = 0; }\nA new set of results is made available exactly every 250ms or 4 times a second.\nanemometerCalculationSet\nanemometerCalculationSet is a pointer to the ready-to-use results.\nInternally, the library uses a ping-pong buffer. Every time a new set of results becomes available, anemometerCalculationSet is updated to point to the last completed set of results.\nThe result set pointed to by anemometerCalculationSet is a\nanemometerResults_t anemometerResults\\[4\\];\nwhere anemometerResults_t is a struct defined as\ntypedef struct { uint32_t timeOfFlight; int16_t sine; int16_t cosine; } anemometerResults_t;\nThe following #defines may be used as array subscripts:\n#define NORTH_TO_SOUTH 0 #define EAST_TO_WEST 1 #define SOUTH_TO_NORTH 2 #define WEST_TO_EAST 3\ntimeOfFlight\nThis is easy to understand. It is the time it takes for the envelope detector to trigger. It is averaged over 32 measurements. Reference point is the rising edge of the first pulse sent. The unit is nanoseconds (ns).\nTime of flight explained graphically sine, cosine\nsine and cosine indicate the phase shift between the transmitted and the received signal.\nThis was by far the most challenging part of library. For each of the 32 measurements, 4 rising and 4 falling edged of the zero-crossing detector are evaluated. So the phase shift indicated by sine and cosine is an average over 256 measurements. But phase shifts wrap around, casually speaking. A phase shift of 359 degrees is almost the same as phase shift of 1 degree. The average should be zero degrees, not 180. Now you could try to solve the problem by constraining your phase shift to the range of -180 to +180 degrees. But that only moves the problem to the other side of the circle: -179 and +179 degrees are almost the same and their average should be 180 degrees, not zero.\nI spent quite some time thinking about this and came up with increasingly complex alogrithms that still failed when some unlucky combination of angles was encountered. Remember, we are trying to average n (currently n=256) angles, not only 2.\nBut of course, many people smarter than me have encountered the problem before and have come up with a perfectly elegant solution: If phi is your phase shift, then calculate sine(phi) and cosine(phi). Sum up all the sines and all the cosines. Then use the arctangent function to convert the summed sines and cosines back to an (averaged) angle. \\[If wordpress had something like LATEX support, one could state this as a nice-looking formula\\]So there is an elegant solution. But there\u0026rsquo;s also a tight time budget: The zero-crossing detector triggeres every 12.5 microseconds (us). In order to not miss the next zero crossing, we need to calculate both sine and cosine and add them to their respective sum in less time than that. And then there is some overhead like context switching. Plus we also have to do some housekeeping during that time.\nsine and cosine are expensive functions, even more so on a 8bit microcontroller. So the only way was using a lookup table. With this approach I managed to stay within budget (around 10.8us). Besides, missing the next edge is not the end of the world - the edge after that is almost as good.\nZero-crossing interrupts are just fast enough not to miss the next edge So we now have summed sine and cosine values - how do we use them?\natan2(cosine, .sine) gives you the phase shift in radians. Multiply this by (180/PI) if you prefer degrees. My preferred approach is:\n(12500.0/PI) * atan2(cosine, sine)\nThis also gives you the phase shift but with nanoseconds (ns) as unit which makes it directly comparable to the timeOfFlight which is also in ns.\ntemperature()\nThere\u0026rsquo;s also another function returning the temperature. It returns a int16_t containing the temperature in 0.01 degrees centigrade. So if the temperature is 23.45 degrees, it will return 2345.\nIt\u0026rsquo;s currently implemented using floating-point math and does not account for the sensor\u0026rsquo;s (slightly) non-linear nature. It\u0026rsquo;s there mainly as a placeholder. I\u0026rsquo;m planning to implement it properly using a lookup-table with interpolation which will make it much faster and will allow it to include the non-linear effects.\nArduino Sketch\nThe .zip file with the library also includes a very basic arduino sketch using that library. I\u0026rsquo;m still evaluating what is the best way to calculate the actual wind speed and direction taking into account issues such as calibration and the like.\nBut my preliminary results look quite promising and I\u0026rsquo;m confident that most if not all the heavy lifting has been done.\nAs always, I highly appreciate any feedback and suggestions. Click here for the next post on this project: /posts/arduino-ultrasionic-anemometer-part-14-wind-tunnel-testing/\n","date":"1 January 2015","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-13-arduino-library-finally-ready/","section":"posts","summary":"It’s been a while since the last post of this series. As so often, the task turned out to be more demanding than I first thought. And then I was also entirely new to assembly language, got distracted by my Inductance Meter Project (/posts/arduino-based-inductance-meter/) and went on a skiing holiday. But finally, the promised library is ready.\n","title":"Arduino Ultrasonic Anemometer Part 13: Arduino library finally ready","type":"posts"},{"content":"","date":"1 January 2015","externalUrl":null,"permalink":"/tags/assembler/","section":"tags","summary":"","title":"assembler","type":"tags"},{"content":"","date":"1 January 2015","externalUrl":null,"permalink":"/tags/assembly/","section":"tags","summary":"","title":"assembly","type":"tags"},{"content":"","date":"1 January 2015","externalUrl":null,"permalink":"/tags/library/","section":"tags","summary":"","title":"library","type":"tags"},{"content":"","date":"14 December 2014","externalUrl":null,"permalink":"/tags/74hc590/","section":"tags","summary":"","title":"74hc590","type":"tags"},{"content":" Incuctance meter in action. It displays the resonance frequency together with the inductance I\u0026rsquo;ve just finished a little Arduino project. It\u0026rsquo;s a shield for the Arduino Uno that lets you measure inductance. This is a functionality that I found missing in just about any digital multi meter. Yes, there are specialized LCR meters that let you measure inductance but they typically won\u0026rsquo;t measure voltages or currents. So I had to build my inductance meter myself.\nClose-up of the circuit with the display removed The basic design is really simple. It a colpitts oscillator (http://en.wikipedia.org/wiki/Colpitts_oscillator) with the coil missing. You use the test leads to connect it to a coil which will make it resonate. The Arduino then measures the frequency at which the oscillator is resonating and calculates the inductance. The capacitors are part of the shield so the capacity is known.\nWith the test leads open, the oscillator can\u0026rsquo;t resonate. The current calibration/zero-offset is displayed in stead There is 1uH of inductance included on the schield which is placed in series with the coil to be measured. This serves two purposes: The oscillator can resonate when you short-circuit the test leads. When you then press the push button on the shield, the software will use the current measurement as new calibration. It also puts an upper limit on the resonance frequency. This ensures that the software the rest of the circuit can keep up with the oscillator.\nPressing this blue button zeroes the meter As can be seen from the schematic, the oscillator uses two 1nF capacitors in series. Together with the 1uH inductance, this limits the frequency to about 7.1MHz. In practice, it oscillates at around 5.4MHz when the test leads are short-circuited.\nThe Arduino shield from below The oscillator output is followed by a comparator turning the sine wave of the oscillator into a square wave. I\u0026rsquo;ve used an inexpensive but fast Microchip MCP6561R. It has a maximum propagation delay of 80ns which allows it to keep up at the maximum frequency.\nViewed from straight above But of course, 5.4MHz is way too fast for the Arduino to keep up. The Arduino runs at 16MHz and will need at least a few dozend instructions to process each pulse from the shield. My solution was to add a 74HC590 8-bit binary counter dividing the frequency by 256. That gives a theoretical maximum frequency of 7.2MHz / 256 = 27.7kHz. That\u0026rsquo;s something the Arduino can deal with.\nThe entire shield with the display removed For obvious reasons, there is also a display included on the shield. And then there\u0026rsquo;s that pushbutton which is debounced in hardware by running it through an RC low-pass filter and a Schmitt-triggered buffer. The button is used to zero the meter, i.e. the current measurement is used as the new zero-offset.\nEven very small inductance values can be measured All related files can be downloaded as a .zip file: LMeterShield (file no longer available). This includes the Arduino source code (aka sketch) as well as the Eagle files and PDFs of both the layout and the schematic.\nNow there\u0026rsquo;s also a stand-alone version: /posts/stand-alone-inductance-meter/\n","date":"14 December 2014","externalUrl":null,"permalink":"/posts/arduino-based-inductance-meter/","section":"posts","summary":" Incuctance meter in action. It displays the resonance frequency together with the inductance I’ve just finished a little Arduino project. It’s a shield for the Arduino Uno that lets you measure inductance. This is a functionality that I found missing in just about any digital multi meter. Yes, there are specialized LCR meters that let you measure inductance but they typically won’t measure voltages or currents. So I had to build my inductance meter myself.\n","title":"Arduino-based Inductance Meter","type":"posts"},{"content":"","date":"14 December 2014","externalUrl":null,"permalink":"/tags/colpitts/","section":"tags","summary":"","title":"colpitts","type":"tags"},{"content":"","date":"14 December 2014","externalUrl":null,"permalink":"/tags/oscillator/","section":"tags","summary":"","title":"oscillator","type":"tags"},{"content":"This is just a very brief update on what I\u0026rsquo;ve been working on the last few days. By now, this blog has caught up with where the project currently stands so the blog posts won\u0026rsquo;t be quite as frequent as they used to be. When I just started this series I had already worked on this my wind meter project for two months so I had plenty of material I only had to post.\nArduino Ultrasonic Anemometer Shield waiting for software By the way: If you’re new to my Arduino-based ultrasonic wind meter project, you might want to click here for an overview: /projects/arduino-ultrasonic-anemometer/\nAs you can see in my last post, all the hardware is working really beautifully now so I can focus entirely on the software. So far, the software was really basic, just enough to show the hardware is working. That\u0026rsquo;s changing now. I\u0026rsquo;m working on a library to handle all the low level stuff, like setting up Timer1 and handling the interrupts.\nOne advantage of putting all that stuff in a library is that I can write in native assembler (as opposed to inline assember which I find a pain in the arse). Not everything will be written in assember. But the two I interrupt service routines (ISRs) will be. Everything else will be regular C code I guess. told you in an earlier post that my ISRs were surprisingly slow: around 5us for the most trivial tasks. The TIMER1_COMPB ISR is now re-written in assember and performs about four times faster. For simple tasks, the interrupts take only around 1.2us now.\nIt took a while but it\u0026rsquo;s finally ready. Click here for the next post: /posts/arduino-ultrasonic-anemometer-part-13-arduino-library-finally-ready/\n","date":"3 December 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-12-working-on-an-arduino-library/","section":"posts","summary":"This is just a very brief update on what I’ve been working on the last few days. By now, this blog has caught up with where the project currently stands so the blog posts won’t be quite as frequent as they used to be. When I just started this series I had already worked on this my wind meter project for two months so I had plenty of material I only had to post.\n","title":"Arduino Ultrasonic Anemometer Part 12: Working on an Arduino library","type":"posts"},{"content":"","date":"3 December 2014","externalUrl":null,"permalink":"/tags/avr/","section":"tags","summary":"","title":"avr","type":"tags"},{"content":"","date":"3 December 2014","externalUrl":null,"permalink":"/tags/interrupt/","section":"tags","summary":"","title":"interrupt","type":"tags"},{"content":"Today I\u0026rsquo;ll go through each part of my new Arduino shield to see if it performs as expected.\nIf you\u0026rsquo;re new to my Arduino-based ultrasonic wind meter project, you might want to click here for an overview: /projects/arduino-ultrasonic-anemometer/\nWhen I first powered on the new shield, only two out of the four transducers worked. As it turned out, I had two different Direction signals on my schematic: one named DIR and one named DIRECTION. They should be one and the same signal but Eagle had no way of knowing about that so they ended up unconnected on the board as well. But luckily it was easy to fix with a piece of wire. After that, the circuit was quite ok. This was the first impression (with some comments of mine):\nOverview of the circuit when first powered on But let\u0026rsquo;s go through it step by step.\nAmplifier\nThis was the main design flaw of the first version. Yes, it eventually worked but drew much more current than necessary. This one got the gain right the first time as can be seen from the screenshot above. Output amplitude was about 5.6V pp and the signal looked nice an clean.\nSo all I had to do was to tune the LC tanks to get them to resonate at 40kHz. The inductor has a 20 or even 30 percent tolerance rating and I can\u0026rsquo;t measure it. So I had to start somewhere, see how it performs and adjust it from there. I started with a 15nF cap and used a signal generator to find the resonance frequency for each amplifier stage.\nAmplifier stage 1 in resonance at 40.98kHz Amplifier stage 2 in resonance at 38.78kHz At resonance, the phase shift is exactly 180 degrees. Maximizing gain should give the same result but I found it easier to look at the phase shift. Above you see two screenshots: one with the first amplifier stage in resonance at 40.98kHz and one with the second stage in resonance at 38.78kHz.\nFrom that you can calculate how much more or less capacitance you need. It took me 3 attempts to get it really right but the final result looks like this:\nAfter some LC-tank tweeking the resonant frequency is at 40kHz now Both stages are perfectly at resonance at 40kHz.\nAbout the biasing: I\u0026rsquo;ve removed the 10k speed-up resistors R6 and R11. I guess they were unnecessary to start with and they lowered imput impedance too much. I noticed by the fact that there was a noticable voltage drop across the 100k biasing resistors R3 and R4. So while the emitter of the biasing transistor pairs was precisely 1V above ground as intended (I measured 1.015V), the actual amplifier\u0026rsquo;s darlington pair had it\u0026rsquo;s emitter only about 0.85V above ground. Not at all what I was looking for.\nWith the two resistors removed everything is fine. 1V emitter voltage for each of the four darlington pairs. And no measurable voltage drop accross the 100k resistors.\nZero Crossing Detector\nZero crossing detector at work I had changed the comparator to a much faster type and this is the result. Now it triggers exactly at the zero crossing, without any noticable delay.\nClose up of the ZCD: Now it really triggers at the zero crossing Before it triggered nowhere near the actual zero crossing because it always lagged behind so much. Now this problem is gone and the edges of the ZCD output are very clean and steep. If you zoom in even more you\u0026rsquo;ll see that rise and fall times are only around 20ns and there is no overshoot and ringing.\nZCD: Nice, clean, fast edge No excuses for the Arduino to not trigger accurately on them.\nEnvelope detector\nThe envelope before and after smoothing I had changed the envelope circuit quite a bit. It has now two op-amp buffered low-pass filters. And this is what I get before the first stage (yellow), after the first stage (pink) and the final envelope (blue).\nEnvelope smoothing close-up The first buffer has a gain of 2.5 set by the 15k and 10k resistors (R9 and R10). This has caused the op-amp to rail before the maximum amplitude was reached. I thought about reducing the gain but then decided to leave it as it is.\nIt doesn\u0026rsquo;t matter if we cut off the top of the envelope. All we care about is the rising edge, this is what we trigger on. We don\u0026rsquo;t care what happens after that. So the high gain gives us some more resolution in the area that we care about.\nCapturing the rising edge of the envelope I\u0026rsquo;m using the same fast comparator for the envelope detector as for the ZCD. And it works just as perfectly here. Above you see how it generates a perfectly clean output signal (pink) when the envelpe (blue) crosses the threshold (yellow).\nAs you can see, there is still a small amount of ripple in the envelope. I have set the -3db points of the filters quite a bit higher than in the first version: 15k plus 1nF results in about 10.6kHz. So I\u0026rsquo;m smoothing the envelope quite a bit less than I used to.\nI might try increasing the 100k resistor at the input to maybe 150k. That would result in less saw-toothing at the filter input (ENV1 above). But for now I leave it as it is.\nSignal routing / multiplexer\nI\u0026rsquo;m now using the second, otherwise unused half of the 74HC4052 to route the PWM signal to the right buffer of the 74HC126. This works flawlessly.\nWhat doesn\u0026rsquo;t work is routing the pre-biased received signals to the amplifier. Well, the signal does get to the amplifier but look at the shape of the amplifier input (yellow signal) in the overview screenshot at the very top. It gets pulled down to zero every time I change the input channel.\nSo I had to change that back to how it was in the first version. The unbiased signal goes through the multiplexer and gets capacitively coupled into the amplifier where it is biased to the right level. But this time I don\u0026rsquo;t have the -5V supply at the multiplexer any more.\nAn unbiased 200mV signal passes the multiplexer without problem Here I\u0026rsquo;m again using a signal generator to generate an unbiased sine wave with 200mV amplitude pp which is applied at the multiplexer input. As you can see above, it reaches the amplifier input in perfect condition.\nBiased to -300mV it still works Even when I biased it to -300mV it passed almost unattenuated. Only when I increased the biasing to -700mV, the amplitude was cut in half:\nAt -700mV biasing we lose half the signal amplitude So I\u0026rsquo;ve replaced the four capacitors at the multiplexer inputs (C16, C24, C25, C26) with zero-ohms resistors and placed one of them at between the multiplexer and the amplifier input. For this second part I had to do a bit of surgery on the board but nothing major.\nNow the amplifier input looks ok:\nAmplifier input looks ok now Crosstalk / Mute signal\nI\u0026rsquo;ve eliminated two of the three multiplexers in this design and was prepared to get quite a bit of cross-talk because of that. This is why I planned ahead and included a mute signal that lets me mute both the amplifier input and output.\nNot much of a cross-talk problem As it turned out, there was not much of a crosstalk problem. Yes, the received signal does pick up some (around 100mV pp) of noise from the transmitted signal but it doesn\u0026rsquo;t do much harm.\nCross-talk zoomed in Most of the noise is high frequency spikes and they don\u0026rsquo;t make it trough the amplifier. Apart from that: We are never transmitting and receiving at the same time. Note that the screenshots above are with the mute signal disabled. So I probabely won\u0026rsquo;t use that mute functionality going forward. One singal less to worry about. And if I change my mind the circuit is still there.\nTemperature sensor / Voltage reference\nNot much of a surprise here. I\u0026rsquo;ve measured the voltage reference output at 2.4989 volts, very close to the rated 2.5V and well within specs.\nThe temperature sensor also works like advertised. But It seems to be significantly (several degrees) warmer than ambient. I\u0026rsquo;ve used a thermocouple to measure the temperature of the sensor and the board around it and really found it to be several degrees warmer.\nI have placed it a bit close to the LED which heats it up a bit. The orange LED I\u0026rsquo;ve used turned out to be very efficient so it was very bright with the 330 ohms resistor. I\u0026rsquo;ve changed that resistor to 1k now and the LED is still quite bright and only consumes a third of the power. But it didn\u0026rsquo;t help much as far as the temperature sensor is concerned.\nSeems the heat is not mainly coming from the LED. Which brings us to the next topic.\nPower consumption\nI\u0026rsquo;ve measured the current (at 12V) the arduino was pulling at its DC plug. Since the Arduino is using a linear regulator, current should be independant of input voltage. Anything above 5V is just disposed as heat.\nThese are my results:\nArduino + shield + display: 67.3mA Arduino + shield: 61.0mA Arduino only: 52.4mA So the display is pulling 6.3mA and the shield another 8.6mA. Most of the current is used by the Arduino itself.\nThe power consumption of the shield makes sense: Every darlington pair is pulling 1mA, the LED uses about 3mA. Makes 7mA so far which leaves 1.6mA for everything else.\nThe Arduino is using quite a bit more power than I thought. At 12V this makes about 0.6 watts. Which is probably what\u0026rsquo;s heating up our shield and the temperature sensor with it.\nSummary\nI\u0026rsquo;m quite happy with the new shield. After a bit of soldering everything is working fine. So from now on, this will mainly be a software project. Here\u0026rsquo;s an update on that: /posts/arduino-ultrasonic-anemometer-part-12-working-on-an-arduino-library/\n","date":"30 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-11-testing-the-new-hardware/","section":"posts","summary":"Today I’ll go through each part of my new Arduino shield to see if it performs as expected.\nIf you’re new to my Arduino-based ultrasonic wind meter project, you might want to click here for an overview: /projects/arduino-ultrasonic-anemometer/\n","title":"Arduino Ultrasonic Anemometer Part 11: Testing the new hardware","type":"posts"},{"content":" A world\u0026rsquo;s first: Ultrasonic Anemometer Shield for Arduino Uno I\u0026rsquo;m happy to announce that my new Arduino wind meter shield is ready. I had posted the design as well as a photo or two of the naked board in my last post but now I\u0026rsquo;ve placed and soldered all the numerous components and it\u0026rsquo;s ready to go.\nClick here for an overview over this series of posts on the Arduino Ultrasonic Anemometer: /projects/arduino-ultrasonic-anemometer/\nLooking pretty. Any good? Don\u0026rsquo;t know yet. So now all my custom hardware boils down to this easy-to-use Arduino UNO shield. Just stack it on top of your Arduino, attach four ultrasonic transducers and you\u0026rsquo;re ready to go.\nBottom side I have high expectations for this shield and hope I won\u0026rsquo;t be disappointed. I\u0026rsquo;ll check on the weekend when I\u0026rsquo;ll first power it up and see if it\u0026rsquo;s any good. I\u0026rsquo;ll let you know.\nStraight from above Click here to see how the new shield perfoms: /posts/arduino-ultrasonic-anemometer-part-11-testing-the-new-hardware/\n","date":"27 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-10-arduino-shield-ready/","section":"posts","summary":" A world’s first: Ultrasonic Anemometer Shield for Arduino Uno I’m happy to announce that my new Arduino wind meter shield is ready. I had posted the design as well as a photo or two of the naked board in my last post but now I’ve placed and soldered all the numerous components and it’s ready to go.\n","title":"Arduino Ultrasonic Anemometer Part 10: Arduino Shield Ready","type":"posts"},{"content":"My first wind meter prototype is kind of working. The software will need improvement to make this wind meter into something really useful. But both hardware and software are basically functional and can be built up upon.\nIf you\u0026rsquo;re new here, you might want to check out the overview over this series of posts on the arduino-based ultrasonic anemometer: /projects/arduino-ultrasonic-anemometer/.\nThe new ultrasonic wind meter Arduino shield The next thing I will do is re-design the entire hardware. Instead of two distinct boards with wires all over the place I will design a single, standard-sized Arduino Shield that can be stacked on an Arduino Uno. Just like any of those commercially available shields that add motor control, Ethernet or whatever. That will make the whole setup much smaller and simpler. And I hope this will also make it easier for others (like you?) who want to build their own.\nThis re-design is what I\u0026rsquo;m going to talk about today so I guess there won\u0026rsquo;t be much in the way of photos, just some schematics and board layouts. And I\u0026rsquo;ll put all the Eagle files on the overview page as a zip download. Here\u0026rsquo;s what I\u0026rsquo;ve changed and why:\nPower supply\nThe first version used the (unregulated) Vin of the Arduino so it had a linear 5V regulator of its own. On top of that there was also a flying capacitor type inverter to generate a -5V rail for the analog multiplexer. Both of these chips have been eliminated. I\u0026rsquo;m now using the the 5V rail straight from the Arduino, there is just a 100uF tantal input cap. The -5V is no longer needed by the multiplexer. I\u0026rsquo;ll later explain why.\nSignal routing / pulse generation / drive\nThe drivers are entirely new: I\u0026rsquo;ve replaced the two 74HC368 inverters with a single 74HC126 non-inverting line driver / buffer. It has four 3-state buffers, one for each transducer. The negative pin of each transducer is simply grounded in the new design. That costs us half the signal amplitude but simplifies things greatly. And our two-stage amplifier should have more than enough gain to make up for that.\nAs suggested earlier, there is only a single 74HC4052 left (instead of 3). We will get some crosstalk issues but we\u0026rsquo;re always transmitting or receiving, never both at the same time. Plus, the tuned amplifier filters out most of that high frequency stuff (such as square waves). And we have the option to mute the amplifier, this time both at the input as well as on the output. Not sure if we\u0026rsquo;ll need it, I\u0026rsquo;ll check once everything else is working.\nPermanently grounding the negative pin of the transducers means we only have four signals to worry about. So I\u0026rsquo;m only using half of the 4052 to chose exactly one of the four signals. Y0, Y1, Y2, Y3 as inputs from the four transducers and Y as output that goes to the amplifier.\nBut why don\u0026rsquo;t I need the -5V anymore? Here is why. In my first design I routed the signal from the transducers straight through the 4052. Because this signal swings around ground, it will be negative half of the time and positive the other half. So I needed both a negative and a positive supply. Later, that signal was capacitively coupled into the amplifier where it was biased so somewhere around 2.3 volts. Now I already do the biasing before the 4052. So the signal will be positive at all times and hence there\u0026rsquo;s no longer a need for a negative voltage. I find this a really elegant solution, I just hope it will work ;-)\nThere is still an Axis and Direction signal controlling a 74HC139 encoder generating the enable signals for the transducer drivers / output buffers. I had LEDs on these enable signals in the first version, these are no longer present. The software changes the axis/direction every 2ms so you won\u0026rsquo;t be able to see anything now.\nThe 74HC126 has active high enable signals (as opposed to the 125 which is otherwise identical). Since all but one enable signals are high, only one transducer can float freely. That\u0026rsquo;s our receiving transducer. That also means that the other 3 transducers are actively driven so only one of them must receive the PWM signal.\nThis is how I\u0026rsquo;ve solved this: As I said, I only used half of the 4052 for the tranducer signals. So the other half can be used to route the PWM signal from the Arduino to the correct output buffer. So the signal from the Arduino is connected to the input X and the outputs X0, X1, X2, X3 carry the signal to the different gates of the 74HC126. There is one potential problem: The outputs that are not selected are floating freely so there are 10k pull-down resistors on X0, X1, X2 and X3.\nSo from the 8 large ICs on the first version, only 3 are left. That saves plenty of board space so we can fit our circuit on a standard sized Arduino shield.\nSame board from the other side Amplifier\nThe basic design with two stages of tuned common emitter amplifiers with NPN darlington pairs has worked well so I\u0026rsquo;ll stick to that.\nThe main shortcoming of my first version was the 47uH plus 330nF LC tank (see part 4) so I\u0026rsquo;m changing that to 1mH plus 15.82nF. Same resonant frequency but much higher impedance. The inductor I\u0026rsquo;ve chosen has a dc resistance of a bit more than 16 ohms which will give a Q-factor of around 15 - comfortable for our application.\nThe main change is the biasing. A wind meter will be deployed outside so it is likely to see great variation in temperature. So the biasing of our amplifier and thus the quiscent current need to be stable over a wide temperature range. Two things make this a difficult task here: First, we\u0026rsquo;re using darlington pairs which means twice the variation in base-emitter drop. Second, our rather low operating voltage of 5 volts.\nA common solution for difficult biasing situations is the use of a matched transistor to generate the base biasing voltage. And that\u0026rsquo;s what I\u0026rsquo;ll do here. Each stage has an additional darlington pair with collector and base connected for this purpose. So the collector will always be 2 diode drops (around 1.3V at room temperature) above its emitter. I want the emitter to sit 1V above ground and 1mA of quiscent current. So I add a 1k emitter resistor and a 2.7k collector resistor and get just that.\nBase emitter drop will change by about -2mV per degree per transistor. So for a 50 degree increase in change in temperature, the drop accross our darlington pair will change from 1.3V to 1.1V - quite substantial. But quiscent current will only increase to 1.054mA and the emitter will then sit 1.054V above ground. A 5.4% variation for a 50 degree change in temperature. Not bad at all I think.\nThe last change to the amplifier is that I\u0026rsquo;ve put the gain limitting resistors (R7 and R12) in series with only the bypass caps (C5 and C10). This will let me change the gain without affecting biasing which is given by R8 and R13.\nZero Crossing Detector (ZCD)\nAlmost no change here. I\u0026rsquo;ve only changed my comparator to be a Microchip MCP6561R. It has a worst-case propagation delay of only 80ns which is 100 times faster than the one I used last time. And it\u0026rsquo;s still cheap: CHF 0.43 at Farnell if you buy 10.\nEnvelope Detector\nI told you earlier that I had some trouble with my last envelope detector which utilized a VCVS active low-pass filter. If I turned up the gain too much I got wild output swings. I found a screen shot of that:\nEnvelope going wild Green is the amplifier output. We\u0026rsquo;re trying to get the envelope of that. But look what happens to the pink line when I turn up the gain. Nothing to do with an envelope. And I would like even more gain to make the envelope use (almost) all of the 0\u0026hellip;5 volts range.\nI haven\u0026rsquo;t really understood why that is. Suggestions anyone? The only thing I can think of is the rather narrow gain-bandwidth product of the op amp, 600kHz if I remember correctly.\nSo I\u0026rsquo;m using two op-amp buffers, each followed by a normal RC low-pass filter. So I can set any gain I want for the two buffers without affecting the signal shape. As an added benefit, I can now look at the signal after each buffer / filter. I\u0026rsquo;ve also changed the op-amps to be Microchip MCP601R. Less precise (we don\u0026rsquo;t need precision here) but fast (2.8MHz) and cheaper.\nAt the very input of the envelope detector I\u0026rsquo;m now using a second (not really matched but same type) diode (D2) to produce a bias voltage just a diode drop above ground to precisely compensate for the rectifying diode (D1) of the envelope detector.\nThe comparator at the output is now a MCP6561R as for the ZCD. Not that we need the speed here, just to use the same type.\nTemperature measurement\nEverything new here. LMT86 as a temperature sensor. Cheap, works from -50 to +150 degrees centigrade and is accurate to 0.4 degrees. Its output is between 1.5 and 2.5volts over the temperature of interest. It comes in a SC-70 package. That\u0026rsquo;s a bit small but still hand-solderable without problem.\nThere is no more op-amp to scale it up but I\u0026rsquo;ve added a rather precise 2.5V voltage reference, the ADR361. Quite an overkill maybe but I thought if you are measuring wind speed you are likely to also measure things like humidity, pressure, light intensity or something like that. So with the anemometer shield you get a precise and stable reference for all your measurements.\nSummary\nAs you can see, I ended up changing quite a lot. When laying out the board I was surprised how easily everything fitted in. Not only did the fewer logic ICs save space themselves, it also greatly simplified signal routing. As you can see from the photos, I\u0026rsquo;ve already made a board. All the components have arrived as well so I\u0026rsquo;m ready to go ahead and build it up. I\u0026rsquo;m really looking forward to seeing how it will perform. I just hope everything works as planned.\nAll the board and schematic PDFs as well as the Eagle files can be found on the overview page as a .zip file: /projects/arduino-ultrasonic-anemometer/\nThat\u0026rsquo;s it for now, click here for the finished shield: /posts/arduino-ultrasonic-anemometer-part-10-arduino-shield-ready/\n","date":"24 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-9-a-new-hardware/","section":"posts","summary":"My first wind meter prototype is kind of working. The software will need improvement to make this wind meter into something really useful. But both hardware and software are basically functional and can be built up upon.\n","title":"Arduino Ultrasonic Anemometer Part 9: A new hardware","type":"posts"},{"content":"In my last post I talked about how to get the Arduino to output bursts of 40kHz pulses. Today I\u0026rsquo;ll go through the rest of the software so by the end of this post we\u0026rsquo;ll have a very rudimentary but working sketch for our ultrasonic wind meter.\nClick here for an overview over this series of posts on the Arduino Ultrasonic Anemometer: /projects/arduino-ultrasonic-anemometer/\nOverview over one round of measurements, i.e. each direction is measured once in turn. If you\u0026rsquo;ve read part 7 of this series you will have noticed that all the key tasks are handled not in the main code but in interrupt service routines (ISRs). That\u0026rsquo;s fairly typical for an application like this one.\nIn this project, there are 2 ISRs:\nTIMER1_COMPB Interrupt: It is triggered by Timer/Counter1. It sends 15 PWM pulses every 2ms and takes care of the Axis, Direction and Mute signals. Named TMR_INT on the screen shots in this post. This is what I\u0026rsquo;ve covered last time. TIMER1_CAPT Interrupt: This is where all the measurement takes place. It is triggered by the envelope detector and zero-crossing detectcor. It reads the current value of Timer/Counter1. Named CAPT_INT on the screen shots in this post. This is what I\u0026rsquo;ve covered last time. This is mainly what I\u0026rsquo;ll be covering today. The basic Idea of the software is as follows:\nEvery measurement takes 2ms. It takes 375us (15 times 25us) to send the pulses plus 500us - 1500us for the pulses to arrive (assuming very extreme wind situations). So 2ms gives us plenty of time to finish our measurement. Shortly after sending the pulses we start listening and wait for the envelope detector to trigger TIMER1_CAPT interrupt. We save the current value of timer1, this is our coarse measurement of time-of-flight. We then set up interrupts to capture a rising edge of our zero-crossing detector (ZCD). A rising edge of our ZCD triggers TIMER_CAPT interrupt. We save the current value of timer1 and set up interrupts to capture a falling edge of the ZCD. A falling edge of our ZCD triggers TIMER_CAPT interrupt. We save the current value of timer1 and set up interrupts to capture a rising edge of the ZCD. Repeat steps 3 and 4 until we\u0026rsquo;ve captured 8 rising and 8 falling edges. Averaging these will give us a very precise measurement of the phase shift. After every measurement we change the direction we measure: N-\u0026gt;S, E-\u0026gt;W, S-\u0026gt;N, W-\u0026gt;E, \u0026hellip; We measure each direction 32 times until we calculate the actual wind speed. So one full measurement will take 4 x 32 x 2ms = 256ms. So we take about 4 measurements per second. Overview over a single measuement The screen shot above shows how a measuement proceeds: AXIS and DIRECTION are set depending on the direction to be measured. MUTE is driven high and 15 PWM pulses are sent. TMR_INT triggers after every pulse in order to count them. After a short break, TMR_INT triggers again and turns MUTE off again. Eventually, the envelope detector (ENV_DETCT) triggers CAPT_INT. Shortly afterwards, CAPT_INT is triggered 16 more times by the zero-crossing detector (ZCD).\nClose-up of the actual measurement. There are 2 sets of variables to save all the measurements from the envelope and zero-crossing detector: At any point in time, one is in use by the ongoing measurements, i.e. they\u0026rsquo;re being updated. The other set represents the last set of measurements and is static. This second set can be used by software in our main loop to calculate the wind speed and direction. As I\u0026rsquo;ve said, capturing one set of measurements takes 256ms. So we also have 256ms to do all the calculations, send data (via USB or whatever), write the new measurement to the display, do some data logging or whatever else we have in mind. There is likely to be some floating-point math, square roots and tigonometric functions going to be needed to arrive at the wind speed and direction but 256ms should be pretty comfortable even for that.\nA long series of measuements. Look at the cursors: It takes about 25ms to do our calculations. This is what I\u0026rsquo;ve tried to show in the screenshot above: There is a signal named CALC which is driven high when a new set of measuements becomes available and driven low when the calculations are finished. So this signal shows you how much time the Arduino\u0026rsquo;s Atmega328 spends processing the data and writing to the display. As you can see, it\u0026rsquo;s less than 25ms so there is ample of room for more complex calculations or other tasks. We\u0026rsquo;ll definitely need some of that head room since the calculations performed so far are really just the bare minimum.\nThere definitely is still a lot to be improved, mainly how the raw measurements are evaluated to get the actual wind speed. But what\u0026rsquo;s more important to me at this time is that the basic idea/setup works. With no wind, my measuements fluctuate somewhere between plus/minus 0.3 meters per second without having done any calibration. It also reacts nicely when I blow a bit of air towards it.\nI\u0026rsquo;ve changed the pinout many times while developing this software but I\u0026rsquo;m confident that I won\u0026rsquo;t have to change the pinout any more. So my plan is to now build version 2 of the hardware first. The entire setup will be much less complex (and prone to errors) without all the lose wires going back and forth between the different boards. Then, with the updated and hopefully final (or nearly final) hardware I\u0026rsquo;ll go ahead and finish the software.\nSpeaking of software: You can download the Arduino sketch from the overview page where you also find the Eagle files for both boards: /projects/arduino-ultrasonic-anemometer/. I\u0026rsquo;ll make it a habit to post all the download material for this project on the overview page so people don\u0026rsquo;t need to go through all the posts trying to find a certain file.\nThat\u0026rsquo;s it for today, continue here to my next post of this series: /posts/arduino-ultrasonic-anemometer-part-9-a-new-hardware/\n","date":"22 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-8-more-software/","section":"posts","summary":"In my last post I talked about how to get the Arduino to output bursts of 40kHz pulses. Today I’ll go through the rest of the software so by the end of this post we’ll have a very rudimentary but working sketch for our ultrasonic wind meter.\n","title":"Arduino Ultrasonic Anemometer Part 8: More Software","type":"posts"},{"content":"","date":"22 November 2014","externalUrl":null,"permalink":"/tags/atmega/","section":"tags","summary":"","title":"atmega","type":"tags"},{"content":"","date":"22 November 2014","externalUrl":null,"permalink":"/tags/atmega328/","section":"tags","summary":"","title":"atmega328","type":"tags"},{"content":"","date":"22 November 2014","externalUrl":null,"permalink":"/tags/atmel/","section":"tags","summary":"","title":"atmel","type":"tags"},{"content":"Today I\u0026rsquo;ll tell you how I got started with my software. If you\u0026rsquo;re new to my blog you might want to click here for an overview over my arduino-based wind meter project: /projects/arduino-ultrasonic-anemometer/\nThe first thing we\u0026rsquo;ll need to archive is to send a series of pulses at 40kHz which is the frequency the ultrasonic transducers work. They must be as precise and repeatable as possible since all our measurements depend on them. Any jitter and the like will affect our measurements. And the duty cycle should be 50%. So you really want to do them in hardware. The Atmega328 comes with a single 16-bit counter/timer (Timer/Counter1) as well as two 8-bit counters (Timer/Counter 0 and 2). We\u0026rsquo;ll need the 16-bit resolution so the choice is clear: Timer1.\nSending pulses using timer/counter1 Well yes, you could easily use one of the 8-bit counters to generate your pulses but you\u0026rsquo;ll still need timer1 for measurement. I\u0026rsquo;ve decided to do everything with just one timer so it\u0026rsquo;s going to be timer1.\nHow many pulses we should send is not so clear. I\u0026rsquo;m working with 15 pulses which works quite well but I\u0026rsquo;m not claiming it\u0026rsquo;s an optimal choice. But it is short enough to make sure we\u0026rsquo;ve stopped transmitting before the first sound waves reach the opposite transducer, even with heavy tail wind.\nSince we have such strict requirements for our pulses, we can\u0026rsquo;t rely on any of those convenient high-level functions to set up our timer but have to study the Atmega328 datasheet and do it ourselfs.\nThis is what I have done:\npinMode(10, OUTPUT); TCCR1A = 0b00100011; TCCR1B = 0b11011001; OCR1AH = 0x01; OCR1AL = 0x8F; OCR1BH = 0x00; OCR1BL = 0xC7;\nThis is a short explanation of what it does: Set pin 10 as an output. Arduino pin10 is pin16 of the Atmega328. And that\u0026rsquo;s the pin connected to the output B of timer1. That\u0026rsquo;s line 1.\nI then set up counter1 in FastPWM mode running at the full system clock frequency of 16MHz. Output B (that\u0026rsquo;s our pin 10 on the arduino) is set high when the counter starts at zero. It will be cleared (i.e. set low) when the timer reaches the value in output compare register B (OCR1B). The counter will be reset when (i.e.it will start at zero again) when it reaches the value in couput compare register A (OCR1A). I also enable an interrupt for when the timer overflows. More on that later. That\u0026rsquo;s lines 2 and 3.\nThen comes the part where I actually set duty cycle and pulse with. I do that by setting the output compare registers. OCR1AH and OCR1AB are the high and low bytes of register OCR1A. So the final value in that register is 0x018F which equals to 399. That means counter 1 will count from 0 up to 399 before it starts again. That\u0026rsquo;s 400 steps. And here\u0026rsquo;s the math: The timer runs at 16MHz, our counter will overflow every 400 cycles. 16000000 / 400 = 40000. That\u0026rsquo;s exactly the 40kHz we\u0026rsquo;re looking for. The duty cycle is set to half that time by setting OCR1B to 199 or 0x00C7.\nThat\u0026rsquo;s it. We have a perfect PWM signal at exactly 40kHz and 50% duty cycle. Look at the screenshot above to convince you that this is exactly what we are getting.\nBut so far, the pulses go on forever. What we need is a way to turn the output signal off after 15 (say) pulses. One way of doing that is to count the pulses and turn the output off once the 15 pulses have been sent. That\u0026rsquo;s what the interrupt at overflow is used for.\nIn that ISR (interrupt service routine) I increment the variable pulse_count. Once pulse_count reaches 15 I know that all the pulses have been sent and turn the output off: TCCR1A = 0b00000011; The timer/counter will continue to run but the PWM output has been turned off.\nFor debugging/monitoring purposes, I set pin A5 high at the beginning of the ISR and low at the end. So I can tell when (and how long) the ISR is running by monitoring pin A5. Here\u0026rsquo;s what I get:\nPulses sent (yellow) and time spent in timer interrupts (blue) The yellow signal is the PWM output (pin10) as before. The blue line shows the time spent handling the interrupt. I could then continue counting without sending any pulses and turn the output back on when I reach 80 for example. And at the very beginning that\u0026rsquo;s exactly what I did. But then the microcontroller has to handle an interrupt every 25us (microseconds) even when not sending pulses. That\u0026rsquo;s quite wasteful so I set a longer time period by increasing the OCR1A and OCR1B registers seen above.\nActually, I\u0026rsquo;m using this interrupt to do some other things as well such as setting Axis and Direction as well as the Mute signal and some other housekeeping. That wide blue pulse you see at the left side of the screenshot above does most of that, that\u0026rsquo;s why it is so wide.\nTime consumed handling a regular timer overflow interrupt Speaking of time consumed handling interrupts. It\u0026rsquo;s quite significant as you can see here: About 5 microseconds for a normal (just counting) interrupt. That\u0026rsquo;s 20% of CPU time while sending pulses (5us every 25us). That\u0026rsquo;s muuuch more than I ever imagined it to be. That\u0026rsquo;s about 80 instructions. I\u0026rsquo;m writing in C so I\u0026rsquo;ll have to check the assember code produced by the compiler to see what\u0026rsquo;s going on.\nClick here for the next post of this series: /posts/arduino-ultrasonic-anemometer-part-8-more-software/\n","date":"20 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-7-basic-software/","section":"posts","summary":"Today I’ll tell you how I got started with my software. If you’re new to my blog you might want to click here for an overview over my arduino-based wind meter project: /projects/arduino-ultrasonic-anemometer/\n","title":"Arduino Ultrasonic Anemometer Part 7: Basic software","type":"posts"},{"content":"If you\u0026rsquo;ve read through my previous posts of this series you know that here is an Arduino and two home-made PCBs together with 4 transducers waiting to work together as an ultrasonic wind meter. If you haven\u0026rsquo;t you may click here for an overview of posts on my anemometer project: /projects/arduino-ultrasonic-anemometer//posts/arduino-ultrasonic-anemometer-part-6-mechanical-design/\nMilling the base plate. For this wind meter to work, the four transducers need to be held in place somehow. Even during testing and development I wanted some reliable mechanical setup so that I don\u0026rsquo;t need to worry about it all the time. For this prototype I don\u0026rsquo;t need anything waterproof that I can put outside for a prolonged period of time. Anyway it will be sitting on my bench most of the time so wood works just fine for me.\nHere two videos of the CNC milling machine at work:\nVideos no longer available.\nThe transducers are 16mm in diameter. 16mm plastic pipes are readily available from hardware stores. They are intended for electrical wiring so you also get matching angles and the like. So I got myself 8 90-degree angles and a 2m pipe from a local hardware store. I think I\u0026rsquo;ve mentioned before that I want the transducers to sit in a 20cm distance so make the wind meter rather compact.\nMore CNC milling. I\u0026rsquo;ve just recently attended a CNC machining course at the Zurich Fab Lab (http://zurich.fablab.ch/) so I decided to do my first CNC milling project and use my newly aquired knowledge to make a wooden base to hold the plastic tubes (and PCBs) in place.\nMounting the PCBs. Still using my Arduino Mega here. I\u0026rsquo;ve used some left over 18mm melamine-coated multiplex. It\u0026rsquo;s extremely sturdy and has a nice smooth surface. I ran my first tests with a Arduino Mega so that\u0026rsquo;s what you see above but I\u0026rsquo;ve replaced that with a Uno by now. So all the software development will take place on an Arduino Uno and its Atmega328.\nMy prototype sitting on the bench Besides the two boards you already know, there is a 2x16 characters LCD. I thought it would be nice to have a display connected to the Arduino when writing the software. Just to see what you\u0026rsquo;re doing. An easy way to drop some debugging output and of course display the measurements once we are ready to actually run this thing.\nView from above There is a little PCB attached to the LCD display. It mainly holds a trimmer to adjust the contrast as well as a resistor for the backlight LED. Since I had to make a board anyway I also included a 10uF plus 100nF ceramic capacitor as well as a protection diode.\nLots of wires to connect everything As you can see from the photos above, there are definitely more and longer wires than necessary. But for a prototype I\u0026rsquo;m always reluctant to soldering things and cutting wires to their minimal or optimal length. I like to be able to just unplug a board and do some changes to it.\nWhen I started writing my software I didn\u0026rsquo;t have a clue which signal will be on which pin. I just plugged them in as I went along. And I changed it several times until I was finally happy with it. So I do need some flexibility. But it also makes the setup a bit of a mess I must admit.\nOk, the hardware is working now. Time to write some software and see if we get it all up and running. See you next time.\nClick here: /posts/arduino-ultrasonic-anemometer-part-7-basic-software/\n","date":"18 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-6-mechanical-design/","section":"posts","summary":"If you’ve read through my previous posts of this series you know that here is an Arduino and two home-made PCBs together with 4 transducers waiting to work together as an ultrasonic wind meter. If you haven’t you may click here for an overview of posts on my anemometer project: /projects/arduino-ultrasonic-anemometer//posts/arduino-ultrasonic-anemometer-part-6-mechanical-design/\n","title":"Arduino Ultrasonic Anemometer Part 6: Mechanical design","type":"posts"},{"content":"","date":"18 November 2014","externalUrl":null,"permalink":"/tags/mechanical-design/","section":"tags","summary":"","title":"mechanical-design","type":"tags"},{"content":"","date":"17 November 2014","externalUrl":null,"permalink":"/tags/74hc139/","section":"tags","summary":"","title":"74hc139","type":"tags"},{"content":"","date":"17 November 2014","externalUrl":null,"permalink":"/tags/74hc368/","section":"tags","summary":"","title":"74hc368","type":"tags"},{"content":"","date":"17 November 2014","externalUrl":null,"permalink":"/tags/74hc4052/","section":"tags","summary":"","title":"74hc4052","type":"tags"},{"content":"In the last post I went through the analog board and showed what I had to do to get it working properly. Today I\u0026rsquo;ll do the same whith the digital board. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\nThe corrected digital board So I plugged in the board for the first time and everything looked fine. The power LED came on, both the +5V and -5V rails worked as expected. But not everything worked that well.\nI\u0026rsquo;ve explained in a previous post how the Arduino can control the direction by means of two lines: Axis and Direction. Here\u0026rsquo;s the meaning of these signals (L=low, H=high):\nAxis=L, Direction=L -\u0026gt; North to South\nAxis=L, Direction=H -\u0026gt; South to North\nAxis=H, Direction=L -\u0026gt; East to West\nAxis=H, Direction=H -\u0026gt; West to East\nThe first thing these two signals do is to control 74HC139 address decoder. The 139\u0026rsquo;s enable signal is grounded so its outputs are always on. Depending on Axis and Direction the 139 turns exactly one of the signals North_EN, South_EN, East_EN and West_EN on. EN stands for enable. As the bar over the signal name indicates, these are active-low signals. So zero volts means on and 5V means off. Each of these enable signals is connected to an LED. The other side of the LEDs is connected (via a resistor of course) to +5V so the LED is on when the signal is on despite the fact that it is active low. This part also worked.\nThen we have two 74HC368 hex inverters. If you look at the 368s data sheet you\u0026rsquo;ll notice that it consists of 6 inverting buffers. But there are only two enable signals. As with most enable signals, these too are active-low. One enable signal controls 4 of the inverting buffers while the other one controls only 2. For us, this doesn\u0026rsquo;t matter since we need a total of 4 groups (one for each transducer) of 2 buffers each (one for each transducer pin). So we\u0026rsquo;ll only use two buffers of each group no matter if there are four.\nEach group is controlled by one of the enable signals coming from the 139. The North_EN signal enables the buffers of the group connected to the North transducers and so forth. So exactly one group of buffers is on at any given time. That\u0026rsquo;s the transducer that is transmitting. All 4 buffer groups are connected to the same PWM signal (named Signal on the schematic) coming from the Arduino. But since only one buffer group is on, only that transducer is actually sending. The other buffer outputs are off and their transducer pins can float freely. Notice how the PWM signal is connected to the input of only one of the buffers in each group. The output of that buffer ist then connected a transducer pin as well as to the input of a second buffer. So one pins of the transmitting transducer are always in opposite states. When the first one is high, the second one is low and vice versa. There were no surprises here, everything worked as expected.\nHow Axis and Direction control the 74HC139 Here\u0026rsquo;s a little visualization of the 74HC139 in action. Note the glitches in the West_EN and East_EN signals. The Arduino can\u0026rsquo;t change both Axis and Direction perfectly simultaneously, there will always be at least one clock cycle in between the two commands. That\u0026rsquo;s why those glitches happen. But Axis and Direction are changed between measurements so nothing interesting is going on anyway. No need to worry about this here.\nBut then there is the task of selecting the right signal to listen to. And that\u0026rsquo;s where I\u0026rsquo;ve messed up just about everything. I guess I just wanted to build my first prototype as soon as possible and didn\u0026rsquo;t double-check everything as I should have. I probably also tried to be clever and use as few signals as possible and chose my inputs so that it simplifies the physical routing on the PCB. Anyway, I ended up with a design that doesn\u0026rsquo;t work. So if you want to build this circuit, look at the RevB board and schematics where I\u0026rsquo;ve corrected the mistakes.\nAs explained before, there are three 74HC4052 multiplexers to eliminate crosstalk. Like the 139, the 4052s are controlled by Axis and direction. But watch out: You need to select the transducer opposite from the one that is transmitting. So for example Axis=L and Direction=L means North to South. North_EN is low so the North buffer group is on and so North is transmitting. That means we have to chose the South transducer for receiving. Nothing complicated, really. But you have to concentrate and think carefully about which transducer has to connected to which of inputs. There are multiple solutions that work but many more that don\u0026rsquo;t.\nMy working solution is as follows: IC5 selects between North and East. So North is connected to input 1 while East is connected to input 3. When we want to listen to North, East is idle and vice versa. That\u0026rsquo;s why we get rid of crosstalk. The negative output of IC5 is grounded, the positive one is named NorthEast and routed to IC6. The second multiplexer, IC7 selects between South on input 0 and West on input 2. Again, the negative output is grounded and the positive output named SouthWest is connected to IC6. IC6 then only has the simple task of choosing between SouthWest and NorthEast. That\u0026rsquo;s why I only needed my Direction signal to control this multiplexer. The other address input can be left grounded.\nI didn\u0026rsquo;t bother building another board so I\u0026rsquo;ve just used some pieces of wire to correct my mistakes. The corrected circuit is equivalent to what you see on the RevB schematic and works flawlessly.\nThis was definitely not my most interesting post so far. Lots of text and much in the way of photos or screenshots. Analog circuits are usually more fun to work with I find. Next time I\u0026rsquo;ll connect the Arduino to my two boards and show you how they perform. There will be some photos and screen shots again, promise.\nClick here for the next post: /posts/arduino-ultrasonic-anemometer-part-6-mechanical-design/\n","date":"17 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-5-testing-the-digital-board/","section":"posts","summary":"In the last post I went through the analog board and showed what I had to do to get it working properly. Today I’ll do the same whith the digital board. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\n","title":"Arduino Ultrasonic Anemometer Part 5: Testing the digital board","type":"posts"},{"content":"","date":"17 November 2014","externalUrl":null,"permalink":"/tags/multiplexer/","section":"tags","summary":"","title":"multiplexer","type":"tags"},{"content":"In this post I will go through the testing of the analog circuit and what I had to do to make it work properly. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\nA first, basic test setup. Ok, so the the analog board is finally ready and all the components have been soldered into place. Time to see if it works as expected. My test setup looked as follows: I\u0026rsquo;ve programmed an Arduino (a Mega as you can see in the background, I didn\u0026rsquo;t have a Uno at that time but it doesn\u0026rsquo;t matter for what I\u0026rsquo;m doing here) to output 15 pulses at 40kHz from one of its pins (followed by a break of a few milliseconds). That pin was connected to one of the pins of a transducer while the other transducer pin was grounded. A second transducer was placed accross from the first one in a 20cm distance. That\u0026rsquo;s the distance/size I\u0026rsquo;m planning to use in the final design as it keeps the wind meter nice and compact. One pin of that second transducer was grounded while the other one was connected to the amplifier input of the analog board. So there are only 2 transducers at this time. One constantly transmitting, the other constantly receiving. Software is also minimal. Keep it simple for now, we\u0026rsquo;re just trying out the analog circuit.\nAmplifier\nTransmitted signal and amplifier in- and output. Here we have the transmitted signal in red at the bottom left, together with the amplifier input (yellow), output of the first stage (green) and output of the second stage (purple). On the positive side, the received signal (amplifier input) is quite strong, around 350mV peak-to-peak. But the amplifier is barely working. At the output of the second stage we want a signal in the range of 5V pp but we get just a bit more than 700mV. We\u0026rsquo;re using a two-stage tuned amplifier and only double the signal amplitude. That\u0026rsquo;s hopeless.\nAs I\u0026rsquo;ve said in part 3, the root cause for this is my poor choice for the inductor/capacitor combination. 47uH or 330nF at 40kHz only give an impedance of 12 Ohms. Even with a decent Q-factor the impedance across the LC tank will never be high enough. I\u0026rsquo;d rather use something like 1mH / 15nF or 470uH / 33nF as as Carl did. But I didn\u0026rsquo;t have a inductor like that at hand so I had to change some other components to fix it.\nFirst I changed the bypass capacitors (C5 and C10) from 100nF to 1uF. That makes the emitter \u0026lsquo;more grounded\u0026rsquo; at signal frequencies (4 ohms instead of 40 ohms if you do the math). That did help but was not enough to save the show.\nI then changed the emitter resistors (R8 and R13) from 330 ohms to only 47 ohms. The logic behind this is simple: The voltage across the LC tank is too small because the impedance is too low. Voltage is current times resistance (or impedance). I can\u0026rsquo;t change the impedance because I don\u0026rsquo;t have a suitable inductor so I have to increase the current. Changing the base resistors does just that.\nNow I have plenty of gain at the price of a much-higher-than-planned quiescent current. Actually, gain was even a bit too high so I put in 15 ohms for R7 and R12 to slightly reducing the gain. Power consumption is not really a concern in this prototype so we\u0026rsquo;re fine for now. But if you\u0026rsquo;re going to build your own, use a big enough inductor in the first place and you won\u0026rsquo;t have to jerk up the current just to squeeze out enough gain.\nAmplifier after fixing the gain Amplifier input (yellow), output of the second stage(green) and output of the second stage (purple). Note the different scales of 200mV, 1V and 2V per division. As you can see, the gain\u0026rsquo;s fine now. We\u0026rsquo;re getting a bit more than 4 Volts of amplitude peak-to-peak which is just what we need.\nClose-up of the amplifier signals You can also see how much cleaner the output is compared to the input. The yellow signal has picked up quite a bit of noise gut the purple signal looks perfectly clean. That\u0026rsquo;s the benefit we get from the narrow bandwidth of the tuned amplifier. And that\u0026rsquo;s why you don\u0026rsquo;t want to just use an op-amp.\nEnvelope detector\nLet\u0026rsquo;s turn to the envelope detector now. Fortunately this part worked right from the start but that doesn\u0026rsquo;t mean it can\u0026rsquo;t be improved. I\u0026rsquo;ve used a voltage divider of 1M and 47k (R14 and R15) to get a voltage of 2.2 Volts which just about compensates for the drop over the schottky diode D1. Maybe I\u0026rsquo;ll use an identical diode in my next design to get a voltage exactly one diode drop above ground.\nEnvelope before and after smoothing Here we see the transmitted signal (red) together with the amplifier output (purple), the output of the diode / input of the low-pass filter (green) and the filter output (yellow). Note how the filter makes the stairs in the green signal disapear. That\u0026rsquo;s exactly its purpose.\nI found the envelope to be a bit slow so I\u0026rsquo;ve changed the resistors R16 and R17 from 47k to 22k. Together with the 1nF caps (C15 and C16) that gives a -3db point of 7.2kHz. That makes the envelope quite a bit faster which means the rising edge will also be steeper. That makes it easier to precisely trigger on it, provided it is still smooth. Obviously you have to strike some balance here. Not sure if my values now are perfect but they definitely do work ok.\nOne problem I\u0026rsquo;ve encountered is that I get some nasty oscillations in the envelope if I turn up the gain too high (via the pot R1). Making the envelope faster has made it even worse. I\u0026rsquo;m not quite sure why that is. It\u0026rsquo;s my first time to work with a VCVS (voltage controlled voltage source) circuit such as this active filter. I might use two stages of simple op-amp buffers and RC filters in my next design. That means I\u0026rsquo;ll need an extra op amp but anyway. For now, I just have to be modest with the gain setting and everything is fine.\nEnvelope detector in action This screenshot shows the envelope detector in action: Transmitted signal (red), amplifier output (purple), envelope (yellow) and output of the envelope detector (green). Note that this screenshot was taken before the changed cutoff frequency of the filter. The yellow curve is very smooth but doesn\u0026rsquo;t track the purple amplifier output very well. That\u0026rsquo;s why I thought it was a bit slow.\nClose-up of the envelope detector triggering on the rising edge of the envelope The green signal is the output of the comparator which is also the output of our envelope detector. It will be connected to the Arduino where it will trigger an interrupt and serve as a coarse measurement of the time-of-flight.\nZero-crossing detector\nMy zero-crossing detector is extremely simple. I set the inverting input of the comparator to half the supply rail by means of R23 and R24. The 100nF cap across R24 (C21) makes sure it stays there and doesn\u0026rsquo;t swing around itself. I bias the amplifier output to the very same 2.5 volts so I really trigger exactly when the sine wave crosses zero. R22 makes sure the non-inverting input to the comparator can swing freely and the input impedance is reasonably high.\nZero-crossing detector Here we see the output of the amplifier / input to the zero-crossing detector (purple) together with the zero-crossing detector output. Everything seems to work fine. As expected, the detector also triggers on very small signals and potentially noise but that should not pose a problem.\nClose-up of the zero-crossing detector input and output These are the same two signals watched a bit more closely. You might notice that there is quite a bit of time delay from the actual zero-crossing to where the green signal changes. This won\u0026rsquo;t be a problem as long as the delay is constant but I\u0026rsquo;m planning to use a faster comparator in my next design. This one has a propagation delay of 8us according to its data sheet. You can get others that are two orders of magnitude faster for nearly the same price such as the MCP6561R with a propagation delay of only 80ns.\nTemperature measurement\nNo surprises here. The output of the LM35 is 10mV per degree centigrade as expected and is amplified by a factor of 4.3 by the op amp. Can\u0026rsquo;t quite remember why I chose only 4.3, I might change that to 11 by changing R25 to 10k.\nNext time I\u0026rsquo;ll go through the same kind of stuff for the digital circuit. Click here: /posts/arduino-ultrasonic-anemometer-part-5-testing-the-digital-board/\n","date":"16 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-4-testing-the-analog-board/","section":"posts","summary":"In this post I will go through the testing of the analog circuit and what I had to do to make it work properly. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\n","title":"Arduino Ultrasonic Anemometer Part 4: Testing the analog board","type":"posts"},{"content":"Today I\u0026rsquo;ll go through the details of the analog cirquit. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\nThe analog board ready to be connected This is what I would consider the heart of this wind meter. This is where the received signal is amplified and processed so the overall accuracy and reliability of the entire project really depends on it. The functionality of this board can be summarized as follows:\nAmplify the received signal Generate a digital signal when the amplitude exceeds a given threshold (envelope detector) Generate a digital signal every time the received signal crosses zero (zero crossing detector) Measure the temperature The finished analog circuit on the test bench This circuit runs on the +5V rail generated on the digital board. There\u0026rsquo;s no need for a negative voltage here, the +5V is all we need. The input to the amplifier (i.e. the received signal) also comes straight from the digital circuit. The 3 outputs temperature (analog), zero-crossing detector (digital) and envelope detector (digital) are all connected to the Arduino Uno. I\u0026rsquo;ll go through each of the four parts now.\nAnalog board with the Arduino on the left and the digital circuit below. Amplifier:\nJust as Carl, I have used two tuned amplifier stages. Each stage uses a NPN darlington pair built from two discrete transistors. The parallel LC tank at the collector determines the resonant frequency of 40kHz as well as the bandwidth. Check out this wiki page http://en.wikipedia.org/wiki/Common_emitter or google for \u0026lsquo;degenerated common emitter amplifier\u0026rsquo; if you\u0026rsquo;re not familiar with this topology.\nClose-up of the amplifier The main difference to Carl\u0026rsquo;s design is that it\u0026rsquo;s running from 5 volts instead of 8 which eliminates the need for an extra rail.\nI\u0026rsquo;ve added a 10k resistor from the emitter of the first transistor to the emitter of the second. This is often done to to enable Q1 to turn of Q2 faster. It\u0026rsquo;s probably not necessary at our low frequency but leaving it away later is much easier than adding it.\nI\u0026rsquo;ve also added an extra resistor to the emitter degeneration. There is a bypassed resistor as with Carl\u0026rsquo;s design but I\u0026rsquo;ve added another resistor in series that can be used to reduce the gain. I\u0026rsquo;ll use a zero-ohm resistor at the beginning and replace that with whatever is needed to get just the right amount of gain. Thinking of it, it would have been smarter to put the gain setting resistor in series with the bypass capacitor only. That way I could adjust the gain without affecting the biasing. But that\u0026rsquo;s something for the next version.\nFor simplicity, I\u0026rsquo;ve biased the input of both stages to half the supply rail or 2.5 volts. The emitter will be two diode drops lower at around 1.2 volts. That should be sufficient to get a stable quiescent current over a reasonably wide temperature range. Speaking of quiescent current: The 330 ohms emitter resistor will yield a quiescent current of around 3.5mA.\nI\u0026rsquo;ve made a rookie error on the LC tank. Carl had used a 470uH coil with a 33nF capacitor which gives just the right resonant frequency. He reports the DC resistance of his coil to be around 10 ohms which gives a Q-factor of around 10 - not great but sufficient. I didn\u0026rsquo;t have a 470uH inductor around but there were a few 47uH ones from a previous project. They had a DC resistance of slightly below 1 ohm so the Q-factor would also be just above 10. So I decided to use them, together with a 330nF cap to get the right frequency. Onetenth of the inductance, one tenth of the resistance, ten times the capacity. Same frequency, same Q, just perfect I thought. And yes, the resistance across the LC tank does have the same shape. But it only has one tenth of the value. So I got very little gain out of the amplifier when I first turned it on and had to correct this later. Lesson learned.\nEnvelope detector\nI\u0026rsquo;ve changed little for the envelope detector. It still uses a two-pole active low-pass filter. The values have changed somewhat but the time constants and cuttoff frequencies remain similar.\nClose-up of the envelope detector I\u0026rsquo;ve used a 1M plus 47k resistor at the input before the diode. At a 5V supply this yields a voltage of about 0.2 volts which just about compensates for the voltage drop over the schottky diode.\nI\u0026rsquo;ve added a 10k pot to adjust the gain of the active filter. So there are two parameters you can adjust without grabbing your soldering iron: filter gain and threshold voltage.\nI have included a (positive) feedback resistor across the comparator just in case I need some extra hysteris but don\u0026rsquo;t plan to use one unless tests show it\u0026rsquo;s really needed. I found that most of the time the comparator itself has enough hysteris of its own. But that remains to be seen, there is space on the board in case we need it.\nAbout the components: The op-amp is a Microchip MCP6061, a precision op-amp. We don\u0026rsquo;t need this here but I happened to have some of them from a previous project. The comparator is a Microchip MCP6541. A bit slow (up to 8us of propagation delay) but as with the op-amp I already had some at hand.\nZero-crossing detector\nI\u0026rsquo;ve simplified the zero-crossing detector somewhat. I want it to trigger every time the received signal crosses zero. When the signal is small it will most likely trigger on random noise but I\u0026rsquo;m not worried about that. I\u0026rsquo;m planning to average a number (say, 16) zero-crossings for each measurement. Exactly half of them shall be positive-to-negative and negative-to-positive. This will help to cancel some of the errors I hope. My plan is to set up my interrupts on the Arduino to trigger on the envelope detector first. Only after that I will enable the zero-crossing interrupts. Once I have captured all of my 16 (or whatever the number happens to be) zero-crossings, I\u0026rsquo;ll disable both time of interrupts until the next measurement. So this zero-crossing detector may random-trigger as much as it likes during all other times.\nClose-up of the zero-crossing detector So I bias the signal at half the supply rail at 2.5 volts. The threshold is at 2.5 volts as well so I can even use the same resistive voltage divider.\nAs with the other comparator, I\u0026rsquo;ve included a feedback resistor across it but don\u0026rsquo;t plan to actually use it.\nTemperature measurement\nAt the heart of the temperature measurement is a LM35 temperature sensor. It outputs a voltage of 10mV per degree centigrade. So there\u0026rsquo;s no way you can measure any temperatur below zero. That\u0026rsquo;s of course a problem depending on where you live but I see this version as a prototype and for testing it will do just fine.\nClose-up of the temperature measurement There is also an op-amp that lets you scale up the rather small voltage of the LM35 to the 0\u0026hellip;5V measurement range of the Arduino ADCs.\nHere are the links to the board layout and the schematic as PDFs. As I\u0026rsquo;ve mentioned before I\u0026rsquo;m happy to share the Eagle files if anyone\u0026rsquo;s interested but at the moment I can\u0026rsquo;t upload them here. Seems you have to go premium to upload zip files and the like.\nanalog_RevA_Board (file no longer available)\nanalog_RevA_Schematic (file no longer available)\nNext time I\u0026rsquo;ll talk about my first tests with the hardware described so far. Click here: /posts/arduino-ultrasonic-anemometer-part-4-testing-the-analog-board/\n","date":"15 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-3-analog-circuit/","section":"posts","summary":"Today I’ll go through the details of the analog cirquit. Click here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/\nThe analog board ready to be connected This is what I would consider the heart of this wind meter. This is where the received signal is amplified and processed so the overall accuracy and reliability of the entire project really depends on it. The functionality of this board can be summarized as follows:\n","title":"Arduino Ultrasonic Anemometer Part 3: Analog Circuit","type":"posts"},{"content":"I\u0026rsquo;m keeping my word and continue to document this project that I\u0026rsquo;ve been working on over the last two or so months. In this post I will talk about the digital part of the circuit.\nClick here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer/.\nDigital part of my ultrasonic anemometer. I\u0026rsquo;ve messed up some signals in Eagle and had to painfully correct this later. What is this cirquit supposed to do? It has 4 ultrasonic transducers attached to it. At any point in time, exactly one of them will be transmitting while the one accross from it will listen and receive the signal. For example, if the North transducers is sending then the South transducer needs to be listening. The other pair of transducers just sits there idle.\nThe signal to be sent is a series of PWM pulses with a frequency of 40kHz and a duty cycle of 50%. This signal will come from the Arduino, the circuit here just needs to route it to the correct transducers.\nFor the receiving transducer, one leg needs to be grounded while the other one must be allowed to float freely. The signal on this floating leg is what you are receiving. So this received signal needs to be routed to the analog part of the circuit where it will be amplified and processed. Here, we don\u0026rsquo;t need to worry about this yet, we just need to make sure, the signal is as strong and clean as possible. That means we will have to protect it from the much more powerful PWM signal.\nThe Arduino needs some way of telling this cirquit in which of the 4 possible directions to measure. I thought the easiest way of doing this is by means of two signals: Axis and Direction. Axis determines if we are dealing with the North/South or East/West axis. The Direction signal then determines which side is transmitting and which one is receiving.\nPower supply: LM2931 on the left, ICL7660 on the right. But let\u0026rsquo;s start at the beginning. Most of the board is powered from a +5V rail but the multiplexers (more on them later) also need a -5V supply to do their job. So I\u0026rsquo;m using a linear regulator to make +5V from the Arduino\u0026rsquo;s Vin voltage. Vin is the voltage applied to the Arduino\u0026rsquo; s DC jack.I\u0026rsquo;m using an LM2931 (pin compatible with the 7805) but you could use anything really. I then feed my +5V to a ICL7660 (the Microchip version of the 7660 but again, you could use anything) to get a -5V rail as well. Since the load on the -5V rail will be minimal I didn\u0026rsquo;t bother using tantalum caps but just used 10uF ceramics.\nClose up of the rat\u0026rsquo;s nest to correct for the messed-up signals on the PCB. The technical term for this is ECO: Engineering Change Order. The transducers are driven by a pair of 74HC368, a classic hex inverter with tri-state outputs. This last part is important because like I said, we need to let the receiving transducer float freely (at least one leg), otherwise it won\u0026rsquo;t be able to receive anything. The inverting nature of this chip allowes us to generate a 180 degrees out-of-phase PWM signal easily. So when transmitting, one leg is always high while the other one is low and vice versa.\nThe buffers are enabled by a active low enable signal. So when the respective enable signal is low, the output buffer is on and the transducer can send. When the enable signal is high, the output buffer is off and the pins can float freely.\nOn the receiving side I\u0026rsquo;ve used three 74HC4052 multiplexers. They allow you to choose 1 out of 4 signal pairs and connect them with a common pair on the other side. Two address pins are used to decide which of the 4 pairs to connect. For this we can just our Axis and Direction signals from above. The 4052s can be turned on and off just like the 368s but we never need to turn them off so we can just ground the enable signal.\nWe have four transducers and the 4052 can handle 4 pairs of input signals. So yes, we could just use one. But there would be cross-talk from the (powerful) PWM signal to the (weak) received signal. So the solution is to cascade 3 of them in such a way that the receiving and transmitting signals never meet. So you can\u0026rsquo;t put North and South on one multiplexer (mux) and East and West on another. That won\u0026rsquo;t help. You have to include one from each axis so one of them is always idle.\nI think once everything works as supposed, cross-talk won\u0026rsquo;t be a problem since we will stop sending before the signal arrives at the receiving transducer. But this is just a prototype anyway so I don\u0026rsquo;t mind some overkill that will probably save me some hassle during the testing/debugging phase. This way I can send and receive endless PWM signals (and not just bursts of them) while tuning the amplifier for example. But I\u0026rsquo;m planning to just use one in the next version.\nNote that I\u0026rsquo;ve grounded one pin of the output signal on the first two multiplexers. So when I choose a transducer to receive, one of its legs is automatically grounded while the signal on the other one is routed to the 3rd and final mux.\nThere is one final thing to watch out for with these multiplexers: They have two supply rails (plus ground) and the signal you want to pass through the mux has to lay between those supply voltages at all time. In our case, the received signal will oscillate around zero volts so it will be negative half of the time. That means we need to provide a negative voltage as well. That\u0026rsquo;s why we need the -5V rail. It\u0026rsquo;s not exactly elegant having to generate a negative voltage just for that but the way the circuit works it is needed. In the next version I will probably bias the input signal to oscillate around some positive voltage so I won\u0026rsquo;t need the -5V any more.\nLEDs are connected to the enable signals to show which way we are currently measuring. If you have studied Carl\u0026rsquo;s circuit (highly recommended), most things will look familiar to you up to here. I\u0026rsquo;ve drawn my own schematic and have done some things somewhat differently but the general idea is really similar. Supply rails of plus/minus 5 volts, a pair of 368s to drive the transducers and cascaded 4052s to route the received signal.\nNow there are two things where I\u0026rsquo;ve changed a bit more. The first is this Axis/Direction approach so I only need two control signals from the Arduino. It saves some pins on the Arduino and simplifies the software. If that\u0026rsquo;s necessary depends mainly on what else you want the Arduino to do. Carl has used a dedicated Atmega328 rather than an actual Arduino so there are plenty of I/O pins that serve no purpose otherwise. My goal is to (one day, hopefully) build a standard Arduino Uno shield that you can just stack of your Arduino Uno board. So who knows what other tasks that Arduino has to accomplish. That\u0026rsquo;s why I thought it wise to keep the task as simple and use as few pins as possible. The downside is that I had to use an 74HC139 to decode the Axis/Direction signal and generate the individual enable signals for the 368s. While I was at it, I decided to attach an LED on each of the enable signals. So you can see from where to where you are currently measuring. The final software will probably change that every few milliseconds so you won\u0026rsquo;t be able to tell anything but for testing and debugging I thought it might help.\nOne last thing that I\u0026rsquo;ve added was an NPN transistor that grounds the output signal to the amplifier when turned on. So with an optional mute signal I can turn the output off. Not sure if I will really use it. It\u0026rsquo;s completely optional but I\u0026rsquo;m already thinking about the next version and as I\u0026rsquo;ve mentioned I only want to use a single multiplexer. So I\u0026rsquo;m thinking about just grounding the output signal while transmitting pulses. A poor man\u0026rsquo;s RX/TX switching of sorts\u0026hellip;\nHere are the schematic and board layout as PDFs. I\u0026rsquo;d be happy to share the Eagle files as well but so far I haven\u0026rsquo;t managed to upload them here. Only a few file types are allowed here it seems. But let me know and I\u0026rsquo;ll send them to you.\nThis is what I\u0026rsquo;ve built so the errors are still there: digital_RevA_Schematic (file no longer available), digital_RevA_Board (file no longer available)\nThis is the updated version (but I\u0026rsquo;ve never built one): digital_RevB_Board (file no longer available), digital_RevB_Schematic (file no longer available)\nWow, this post got way longer than I ever thought. Here\u0026rsquo;s the link to the next post where I talk about the details of the analog circuit: /posts/arduino-ultrasonic-anemometer-part-3-analog-circuit/\n","date":"14 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-2-digital-circuit/","section":"posts","summary":"I’m keeping my word and continue to document this project that I’ve been working on over the last two or so months. In this post I will talk about the digital part of the circuit.\n","title":"Arduino Ultrasonic Anemometer Part 2: Digital Circuit","type":"posts"},{"content":"This is the first of a series of posts to follow. I will describe my attempts to build an ultrasonic wind meter (anemometer) based on an Arduino Uno. By the time of writing, I have a working prototype but it will take me a while to catch up in this blog. So this is just the first post - more will follow soon.\nClick here for an overview over this series of posts on the anemometer project: /projects/arduino-ultrasonic-anemometer//.\nThe finished analog part of the circuit. Let me quickly outline the project: My aim is to build an ultrasonic anemometer based on a Arduino Uno board. Now what\u0026rsquo;s an anemometer? That\u0026rsquo;s just a fancy name for a wind meter. I want to be able to measure both wind speed and wind direction with high accuracy. Most wind meters are of the cup or vane variety. They turn wind into mechanical motion and then measure that motion to calculate wind speed and possibly direction. An ultrasonic anemometer on the other hand sends and receives ultrasonic pulses and measures the time-of-flight. From the time-of-flight (or the time difference, depending on your approach) you can then calculate the wind speed in a given direction. Add a second pair of senders and receivers at a 90-degree angle and you get both wind speed and direction. As so often, wikipedia gives a nice overview/introduction to the subject: http://en.wikipedia.org/wiki/Anemometer\nA preliminary setup to test the basic functionality of my circuit Surprisingly, there seem to be very few people out there who have done this before. Basically, there is this one brave guy named Carl who has built such an anemometer from scratch and put all the relevant infomation online.His project was published on hackaday.com and this is where I found it: http://hackaday.com/2013/08/21/ultrasonic-anemometer-for-an-absurdly-accurate-weather-station/. All of his documentation used to be at mysudoku.googlecode.com/files/UltrasonicAnemometer.zip (link no longer available — Google Code was retired in 2016). This material makes for an excellent starting point if you want to build your own. I\u0026rsquo;ve looked carefully at Carl\u0026rsquo;s schematics and have copied many of his ideas. I did end up changing quite a few things and will explain my reasons for doing so but the general approach is very much the same. Many thanks for sharing this with us, Carl.\nThe basic idea is simple: You send a ultrasonic pulse and measure the time until it arrives at a receiver located in some distance. Ultrasonic transducers often operate at 40kHz and so do mine. A transducer is a device capable of both sending and receiving a signal. It\u0026rsquo;s the kind of thing cars uses for their parking aids, telling you if there is an obstacle and at what distance.\nThe board for the digital part waiting for the components to be placed and soldered. In a 2-dimensional anemometer such as here, you will have 2 pairs of transducers for a total of 4. Let\u0026rsquo;s call them North, South, East and West for simplicity. You need to be able to send and receive pulses in all 4 directions: N-\u0026gt;S, S-\u0026gt;N, E-\u0026gt;W and W-\u0026gt;E. Not all at the same time but one after the other.\nSo you will need some kind of circuit to route your signals from and to any of the transducers. For example you want to send from the West transducers and receive from your East transducer or vice versa. Let\u0026rsquo;s call it the digital part even though the received signal is analog in nature. The PCB without components just above is the basis for this digital part. If you wonder who or what Jingling Ding is: That\u0026rsquo;s the name of my step daughter who helped me drawing and laying out this PCB in Eagle.\nYou will then need some more circuitry to process the received signal. This circuit is shared among the 4 transducers so only one can be listening at any point in time. That\u0026rsquo;s why the digital part needs to route the signal from the correct transducer to this signal processing circuit. The received signal is analog in nature and will be very weak compared to the transmitted one. So you will need quite a bit of amplification first. But this analog signal cannot directly be used by your arduino to measure the time of flight. You need some digital signal(s) that you can measure using the timer(s) on the arduino\u0026rsquo;s Atmega328 chip (in case of the Arduino Uno). Let\u0026rsquo;s call this the analog part. That\u0026rsquo;s what\u0026rsquo;s shown on the photo at the top of this page.\nIn my next post I will go through the details of the two circuits. Click here for the second post: /posts/arduino-ultrasonic-anemometer-part-2-digital-circuit/\n","date":"13 November 2014","externalUrl":null,"permalink":"/posts/arduino-ultrasonic-anemometer-part-1-getting-started/","section":"posts","summary":"This is the first of a series of posts to follow. I will describe my attempts to build an ultrasonic wind meter (anemometer) based on an Arduino Uno. By the time of writing, I have a working prototype but it will take me a while to catch up in this blog. So this is just the first post - more will follow soon.\n","title":"Arduino Ultrasonic Anemometer Part 1: Getting started","type":"posts"},{"content":"This page serves as a directory of all my posts and downloads related to my Arduino based Ultrasonic Anemometer.\nFirst Attempt with an ArduinoUno and two separate boards\nPart 1: /posts/arduino-ultrasonic-anemometer-part-1-getting-started/ Part 2: /posts/arduino-ultrasonic-anemometer-part-2-digital-circuit/ Part 3: /posts/arduino-ultrasonic-anemometer-part-3-analog-circuit/ Part 4: /posts/arduino-ultrasonic-anemometer-part-4-testing-the-analog-board/ Part 5: /posts/arduino-ultrasonic-anemometer-part-5-testing-the-digital-board/ Part 6: /posts/arduino-ultrasonic-anemometer-part-6-mechanical-design/ Part 7: /posts/arduino-ultrasonic-anemometer-part-7-basic-software/ Part 8: /posts/arduino-ultrasonic-anemometer-part-8-more-software/ Ultrasonic Anemometer Shield for ArduinoUno\nPart 9: /posts/arduino-ultrasonic-anemometer-part-9-a-new-hardware/ Part 10: /posts/arduino-ultrasonic-anemometer-part-10-arduino-shield-ready/ Part 11: /posts/arduino-ultrasonic-anemometer-part-11-testing-the-new-hardware/ Part 12: /posts/arduino-ultrasonic-anemometer-part-12-working-on-an-arduino-library// Part 13: /posts/arduino-ultrasonic-anemometer-part-13-arduino-library-finally-ready/ Part 14: /posts/arduino-ultrasionic-anemometer-part-14-wind-tunnel-testing/ Trying out new ideas\nPart 15: /posts/ultrasonic-anemometer-part-15-a-new-attempt/ Part 16: /posts/ultrasonic-anemometer-part-16-testing-the-new-driver-circuit/ Part 17: /posts/ultrasonic-anemometer-part-17-lasercut-mechanical-design/ Part 18: /posts/ultrasonic-anemometer-part-18-analog-signal-processing/ Part 19: /posts/ultrasonic-anemometer-part-19-testing-the-analog-circuit/ Standalone Ultrasonic Anemometer with an on-board PIC32\nPart 20: /posts/ultrasonic-anemometer-part-20-standalone-anemometer-design/ Part 21: /posts/ultrasonic-anemometer-part-21-standalone-anemometer-hardware/ Part 22: /posts/ultrasonic-anemometer-part-22-usb-up-and-running/ Part 23: /posts/ultrasonic-anemometer-part-23-first-successful-measurements/ Part 24: /posts/ultrasonic-anemometer-part-24-new-microcontroller-and-software-controlled-gain/ Part 25: /posts/ultrasonic-anemometer-part-25-i2c-interfacing-and-more/ Revised Version on a professionally made PCB\nPart 26: Ultrasonic Anemometer Part 26: Rev B Board ordered Part 27: /posts/ultrasonic-anemometer-part-27-ready-to-take-pre-orders/ Part 28: /posts/ultrasonic-anemometer-part-28-new-hardware-tested/ Part 29: /posts/ultrasonic-anemometer-part-29-transducer-comparison/ Part 30: /posts/ultrasonic-anemometer-part-30-downsized-hardware/ Downloads:\nAll Eagle files for download as a .zip file: AnemometerEagle (file no longer available) Arduino Sketch: Anemometer_Uno_01 (file no longer available) Anemometer Arduino Shield PDFs and Eagle files as a .zip: AnemometerShield_REV1 Anemometer Library v1.0: AnemometerLibrary_10 (file no longer available) Anemometer Arduino Shield PDFs and Eagle files Rev2 as a .zip: AnemometerShield_REV2 (file no longer available) Eagle files and PDFs for the driver circuit of my new attempt: AnamometerDriver_RevA (file no longer available) OpenSCAD CAD model as well as PDFs and Adobe Illustrator files for the lasercut mechanical design: AnemometerOpenSCAD (file no longer available) Analog signal processing. Eagle files as well as PDFs: AnemometerAnalog (file no longer available) Standalone anemometer. Eagle files as well as PDFs: StandaloneAnemometer_RevA (file no longer available) Standalone anemometer: USB and basic send/receive working: StandaloneAnemometer_01_20160528 (file no longer available) Measuring time-of-flight, calculating wind speed. zip file includes sample data logs: StandaloneAnemometer_01_20160606 (file no longer available) Upgrade to PIC32MX250, controlling digipot over I2C: StandaloneAnemometer_01_20160625 (file no longer available) Standalone Anemometer interfacing to an Arduino Uno via I2C: StandaloneAnemometer_01_20160710_I2CExternal (file no longer available) Code for the Arduino Uno with the LCD: I2C_Master_LCD (file no longer available) Eagle files and PDFs of schematic and board for the standalone anemometer Rev B: standaloneanemometer_revb (file no longer available) The Gerber files for the standalone anemometer Rev B as ordered from dirtypcbs.com: dirtypcb_StandaloneAnemometer_RevB_ordered (file no longer available) Bill of materials (BOM) for the standalone anemometer Rev B: StandaloneAnemometer_RevB_BOM (file no longer available) GitHub\nNow the source code for the Ultrasonic Anemometer is available on GitHub: github.com/soldernerd/UltrasonicAnemometer\nAnd the board and schematics: github.com/soldernerd/UltrasonicAnemometerHardware\nAnd the OpenSCAD design for the lasercut structure: github.com/soldernerd/AnemometerLasercut\n","date":"13 November 2014","externalUrl":null,"permalink":"/projects/arduino-ultrasonic-anemometer/","section":"posts","summary":"This page serves as a directory of all my posts and downloads related to my Arduino based Ultrasonic Anemometer.\nFirst Attempt with an ArduinoUno and two separate boards\n","title":"Ultrasonic Anemometer","type":"posts"},{"content":"","date":"12 November 2014","externalUrl":null,"permalink":"/tags/74hc14/","section":"tags","summary":"","title":"74hc14","type":"tags"},{"content":"","date":"12 November 2014","externalUrl":null,"permalink":"/tags/schmitt-trigger/","section":"tags","summary":"","title":"schmitt-trigger","type":"tags"},{"content":" This was one of the first PCBs I ever made myself as well my very first attempt at soldering SMD components. So if you were wondering why some of the copper on the right has not been removed - that\u0026rsquo;s why. At that time, I was not even using Eagle yet but some software called Sprint Layout. But this post is not really about this unimpressing board but about proper debouncing. Something I feel strongly about ;-)\nAs opposed to many people out there, I still prefer to do all my debouncing in hardware. Yes, of course you can do debouncing in software and sometimes you may have to but if you have a choice, debouncing in hardware will generally yield better results and reduces software complexity. Most of the time, my switches will directly trigger an interrupt on a microcontroller so you really want to avoid false triggering. All that context switching associated with an interrupt adds quite some overhead compared with just reading an input pin so there are performance implications of this as well.\nJack Ganssle has written a really nice paper on this. It can be found here: http://www.eng.utah.edu/~cs5780/debouncing.pdf. He has run some experiments with a wide variety of switches and explains how to deal with them in practice. What I was doing here follows the recommended approach from Jack\u0026rsquo;s paper: You take a switch and a pull-up resistor, run the resulting signal through an RC filter and add a schmitt-triggered buffer. Cheap, simple and works perfectly every time.\nHere are the signals you get when the button is pressed (top) or released (bottom). Yellow is the output of the RC filter and red is the (digital) output of the schmitt-triggered buffer. Note that the 74HC14 is an inverting buffer so the output signal goes from low to high when the button is pressed.\nThe time constant of the RC filter and therefore the resistor and capacitor values are quite uncritical if you are working with simple switches as here. As you can see in the scope screens above, it takes around 20ms from when the button is pressed (or released) until the output signal changes. That\u0026rsquo;s more than enough time even for a pretty poor switch to have stopped bouncing. At the same time, that\u0026rsquo;s instantaneously as far as the user is concerned. Anything up to 50ms feels instantaneous even to impatient humans.That leaves 30ms for the microcontroller to take the desired action. If that\u0026rsquo;s enough depends of course on what you are trying to do but generally that\u0026rsquo;s plenty of time.\nHere\u0026rsquo;s yet another screenshot. This time it\u0026rsquo;s the digital output (red) as well as the same signal in analog. This is just to convince you that what your are getting is really a clean output signal. It goes high to low in less than 10ns. That\u0026rsquo;s less than one-sixth of a clock cycle on a typical (16MHz) microcontroller. Yes, there is some ringing but there always is if you look closely enough. In this case it\u0026rsquo;s well behaved with less than 700mV pp amplitude and dies out within 50ns or so.\nGetting the balance just right gets much trickier when you\u0026rsquo;re using rotary encoders. You won\u0026rsquo;t press a pushbutton 100 times a second but it\u0026rsquo;s not uncommon to get signals from an encoder with only a few milliseconds between them. So you have to think carefully about how much debouncing you need. Just a bit too little and you pick up bouncing noise. A bit too much and you start missing pulses.\nI\u0026rsquo;ll share my lessons learned on that, too. But that\u0026rsquo;s for another post in the future.\nHere you find the Eagle files as well as PDFs of the board and schematic as a zip file (file no longer available).\n","date":"12 November 2014","externalUrl":null,"permalink":"/posts/switch-debouncing-using-74hc14/","section":"posts","summary":" This was one of the first PCBs I ever made myself as well my very first attempt at soldering SMD components. So if you were wondering why some of the copper on the right has not been removed - that’s why. At that time, I was not even using Eagle yet but some software called Sprint Layout. But this post is not really about this unimpressing board but about proper debouncing. Something I feel strongly about ;-)\n","title":"Switch debouncing using 74HC14","type":"posts"},{"content":"","date":"11 November 2014","externalUrl":null,"permalink":"/tags/programmer/","section":"tags","summary":"","title":"programmer","type":"tags"},{"content":" I regularly use PIC microcontrollers. I\u0026rsquo;ve tried some Atmel chips lately but I\u0026rsquo;m still by far most familiar with the PIC16 \u0026amp; PIC18 chip families. As you can see in my other posts, I tend to use SMD components but once in a while I need to program a DIP package.\nI do all my PIC programming using the MikroC for PIC compiler from Mikroelektronika. They also make this MikroProg programmer/debugger that integrates nicely into their IDE.\nSo these DIP sockets have a 5x 100 mil header that lets me connect the MikroProg and route the signals to the respective pins of the PIC. Obviously, different chips have different pin counts and pinouts so I had to make a few of them to cover all the PICs I use.\nhttp://www.mikroe.com/\n","date":"11 November 2014","externalUrl":null,"permalink":"/posts/programming-sockets-for-pic-microcontrollers/","section":"posts","summary":" I regularly use PIC microcontrollers. I’ve tried some Atmel chips lately but I’m still by far most familiar with the PIC16 \u0026 PIC18 chip families. As you can see in my other posts, I tend to use SMD components but once in a while I need to program a DIP package.\n","title":"Programming sockets for PIC microcontrollers","type":"posts"},{"content":"My name\u0026rsquo;s Lukas. All my life I\u0026rsquo;ve been fascinated by anything technical and electronics in particular. With some help from my dad I soldered blinking lights and morse keys by the age of 12. Later, as a teenager, I got my ham radio license but have never done much with it. I guess I find tweeking circuits more fun than being on air.\nA morse key built at age 12 Some time in the late 1990s I started doing computer programming and then hardly touched a soldering iron for years to come.\nI was sucked back into the facinating world of electronics when I stumbled across a demo board with a NXP1769 microcontroller on it. At that time I had absolutely no experience with microcontrollers but I thought they\u0026rsquo;re fun so I immediately ordered one of those demo boards.\nSoon after that I felt an urge to design and build my own circuits so I turned, quite randomly, to the PIC16 and PIC18 family of microcontrollers that I\u0026rsquo;ve used quite extensively since.\nOver the years that followed I\u0026rsquo;ve read through piles of books on embedded systems and electronics and built countless circuits, some more successful than others. But to this day I have absolutely no formal education in any of the fields I write about here. So everything you see here is entirely hobbyist, in the true sense of the word.\nI\u0026rsquo;m planning to use this blog to document and share some of the the projects that I\u0026rsquo;m currently working on. Any feedback, comments, suggestions and the like are highly welcome. Just use the contact form below. However, if your message concerns a certain project or post please just post it there so other readers can also benefit from the discussion.\nOn copyrights: Unless mentioned otherwise everything on this blog is published under Creative Commons Attribution-ShareAlike 4.0 International (hardware) and GNU GPLv3 (software). So feel free to use and adapt anything you find here as long as you give credits to the original authors (attribution) and again share your design (share alike).\nIf you have a question or remark, please leave a comment on the relevant post directly.\n","date":"10 November 2014","externalUrl":null,"permalink":"/projects/about_me/","section":"posts","summary":"My name’s Lukas. All my life I’ve been fascinated by anything technical and electronics in particular. With some help from my dad I soldered blinking lights and morse keys by the age of 12. Later, as a teenager, I got my ham radio license but have never done much with it. I guess I find tweeking circuits more fun than being on air.\n","title":"About me","type":"posts"},{"content":" This is a constant current dummy load. It\u0026rsquo;s controlled by a PIC16F1936 microcontroller. As you can see, it\u0026rsquo;s equipped with a 4x16 character LCD display and, less obvious, a rotary encoder with push button. It accurately sets the desired current via a 16bit DAC and reads both current and input voltage with a single-channel 16bit ADC each. Temperature is measured by the microcontroller\u0026rsquo;s internal 10bit ADC.\nIt needs a 6\u0026hellip;16 volts supply for it\u0026rsquo;s own use. That\u0026rsquo;s what the upper pair of banana plugs is for. It can then burn up to 4.5 amps in the range of 0\u0026hellip;22 volts. You can set any current from up to 4.5 amps in 1mA steps via the rotary encoder. By pressing the encoder you can set the \u0026lsquo;sensitivity\u0026rsquo; of the encoder. There are 3 ranges: 1mA, 10mA and 100mA per (encoder) step. This way, you can quickly and precisely set any current you want.\nThere is a LM35 temperature sensor mounted directly to the heat sink. The temperature is shown on the display as well as used for protective purposes. The software automatically limits the current if the heat sink gets too hot. Using the temperature, current and voltage, it also calculates the die temperature of the two MOSFETs and makes sure their temperature rating is not exceeded. They have a temperature rating of 125 degrees centigrade and a die-to-heatsink thermal coefficient of around 4 degrees/Watt. So with higher voltages and currents it\u0026rsquo;s entirely possible to blow the MOSFETs even with moderate heat sink temperatures.\nYou might wonder what the Xilinx XC9572XL CPLD is doing on there. Well, this was my very first project involving an LCD display, my first project involving a rotary encoder, my first project involving external ADCs and DACs\u0026hellip; My first project at a lot of things. So I appreciated having the flexibility to change some of the signal routing in VHDL. All the signals traveling from the rotary encoder to the microcontroller and from the microcontroller to the display travel via the CPLD so I can re-route those signals any way I want. Now the CPLD mainly takes care of the encoder\nThe 100mil header at the front is a I2C interface that let the dummy load communicate with the outside world. It was added later so i had to run some wires to get access to the I2C bus.\nBy the way, this is how I got the idea of building a dummy load: http://www.eevblog.com/2010/08/01/eevblog-102-diy-constant-current-dummy-load-for-power-supply-and-battery-testing/\n","date":"10 November 2014","externalUrl":null,"permalink":"/posts/constant-current-dummy-load/","section":"posts","summary":" This is a constant current dummy load. It’s controlled by a PIC16F1936 microcontroller. As you can see, it’s equipped with a 4x16 character LCD display and, less obvious, a rotary encoder with push button. It accurately sets the desired current via a 16bit DAC and reads both current and input voltage with a single-channel 16bit ADC each. Temperature is measured by the microcontroller’s internal 10bit ADC.\n","title":"Constant Current Dummy Load","type":"posts"},{"content":"","date":"10 November 2014","externalUrl":null,"permalink":"/tags/dummy-load/","section":"tags","summary":"","title":"dummy-load","type":"tags"},{"content":"Another afternoon project. Some time ago I was working on a 80 watts 12-to-36 Volts DC-DC boost converter. Not one of my most successful projects but anyway.\nSo I needed some kind of load but my home made constant current dummy load can only handle 20-something volts. A few 100 ohms 15 watt resistors were just what I needed. So I took 6 of them and made a simple, single-sided PCB that holds the resistors as well as 6 switches.\nThe resistors are upright and have a bit of an air gap between them. That\u0026rsquo;s important, they get incredibly hot with 36 volts accross them. I know, I had to learn the hard way ;-)\nTogether with the aluminium front it has a nice weight for its size and with it\u0026rsquo;s silicone feet it sits firmly on the bench.\n","date":"10 November 2014","externalUrl":null,"permalink":"/posts/simple-resistor-based-dummy-load/","section":"posts","summary":"Another afternoon project. Some time ago I was working on a 80 watts 12-to-36 Volts DC-DC boost converter. Not one of my most successful projects but anyway.\nSo I needed some kind of load but my home made constant current dummy load can only handle 20-something volts. A few 100 ohms 15 watt resistors were just what I needed. So I took 6 of them and made a simple, single-sided PCB that holds the resistors as well as 6 switches.\n","title":"Simple, resistor based Dummy Load","type":"posts"},{"content":" A classic afternoon project. I was in need of a variable voltage and didn\u0026rsquo;t have a proper lab power supply available. But I did have a solid 12 volts from an old computer PSU. So I built myself this little thing.\nIt\u0026rsquo;s really nothing more than a LM317 in a TO220 package with a pot, two capacitors and banana jacks. It measures about 65x55mm and has rubber feet so it sits nicely on the bench. All the parts I found laying around here. The little heat sink can handle 5 to 10 watts without getting overly hot.\nOver a short period of time you can burn quite a bit more so you can draw up to 1.5 Amps (the LM317\u0026rsquo;s internal current limit) from anywhere between 1.25 and 10 volts when connecting it to a 12V supply.\n","date":"10 November 2014","externalUrl":null,"permalink":"/posts/variable-voltage-power-supply-using-a-lm317/","section":"posts","summary":" A classic afternoon project. I was in need of a variable voltage and didn’t have a proper lab power supply available. But I did have a solid 12 volts from an old computer PSU. So I built myself this little thing.\n","title":"Variable Voltage Power Supply using a LM317","type":"posts"},{"content":"","date":"10 November 2014","externalUrl":null,"permalink":"/tags/vhdl/","section":"tags","summary":"","title":"vhdl","type":"tags"},{"content":"Some time ago I wanted to try out programming CPLDs in VHDL. I was entirely new to both of those topics and I didn\u0026rsquo;t have a real need for a CPLD at the time. So I built myself a nice little prototyping board for the Xilinx XC9500XL complete with some push buttons, LEDs a 7-segment display and a PIC16F688 used mainly as a clock source.\nAs you can see, I\u0026rsquo;ve used a socketed PLCC44 package. The CPLD comes in two versions: XC9536XL with 36 macro cells and XC9572XL macro cells. 36 cells won\u0026rsquo;t allow you to do very much I had to soon find out and even 72 can be quite limiting depending on what you are planning to do. Prices don\u0026rsquo;t differ that much so I recommend you get the 9572 straight away.\nNotice that I\u0026rsquo;m using the 3.3V version in this project. There is a 5V version of these chips as well and many of the DIY projects you find on the web use them. But they are increasingly hard to find and might cost several times more. When I was doing this project, Farnell was selling them around $15 in small quantities compared to maybe $4 for the 3.3V version.\nThe board is powered from anywhere in the range of 4 - 16V so you can easily power it from USB. All the CPLD pins are accessible from the 100mil headers you on the top and the bottom of the board. On the right you can see the programming headers for the PIC and the CPLD, respectively. I\u0026rsquo;ve also included a few 3.3V \u0026lsquo;outlets\u0026rsquo; that I can use to power other boards connected to it.\nHere\u0026rsquo;s a list of related projects:\nbitcycle.org/electronics/1st_CPLD_project/ (link no longer available)\nhttp://hackaday.com/2008/12/11/how-to-programmable-logic-devices-cpld/\nstartingelectronics.com/projects/xilinx-CPLD-board/ (link no longer available)\nhttp://dangerousprototypes.com/docs/XC9500XL_CPLD_breakout_board\n","date":"10 November 2014","externalUrl":null,"permalink":"/posts/xilinx-prototyping-board/","section":"posts","summary":"Some time ago I wanted to try out programming CPLDs in VHDL. I was entirely new to both of those topics and I didn’t have a real need for a CPLD at the time. So I built myself a nice little prototyping board for the Xilinx XC9500XL complete with some push buttons, LEDs a 7-segment display and a PIC16F688 used mainly as a clock source.\n","title":"Xilinx Prototyping Board","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"authors","summary":"","title":"authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"series","summary":"","title":"series","type":"series"}]