Tuesday, 27 December 2016

Thoughts on the ESP-Live

I received the raw PCB's and some of the components for the ESP-Live I wrote about a few weeks back. I have built the first prototype and I have some thoughts and ideas that I wanted to share, as well as a few photos!

Here's the GitHub link: https://github.com/ManCaveMade/ESP-Live

The ESP-Live without mains PSU module showing the Quark One in the background. The Quark One is used for power and USB to serial.

The underside of the ESP-Live. Note that I have not soldered the CH340 yet.

I have not yet ordered the CH340G USB-UART converter chips. It seem that one can only get these direct from China, which is a bit of a hassle with shipping. :( For the moment, I have simply connected the RX, TX, RST and GPIO0 pins to one of my Quark One's and I am using the bootloader on the Quark One to program the ESP-12F module.

While playing around with this setup, I think that I will not bother with the CH340's and do a fresh design... The CH340's are really cheap compared to FT232's, but I think that for a little bit more money it's worth using a proper microcontroller with USB instead - much like my original Quark One.

Why use a microcontroller, you ask?

By using a cheap microcontroller that has USB, I can achieve the same functionality as a USB to UART converter, plus much, much more to make up for the down-sides of the ESP chip:

  • Superior (and several) Analog to Digital converters
  • DAC's
  • Many PWM pins
  • Lots of timers (real-time, so it's suitable for light dimming, etc.)
  • ...
Of course, I want the ESP to be the main processor in the system as opposed to the Quark One (where the ESP was meant to be a simple WiFi peripheral). I think that it's better to use a microcontroller with a serial or SPI interface to the ESP, and then define a simple protocol to access the various peripherals from the ESP code. 

I think that this makes more sense. The ESP will be running a web server, RESTful server / client, user interface, logic, etc. and as such, the ESP could simply delegate IO to it's own peripherals and the slave micro. The slave micro needs good firmware to be written once, after which it should Just Work™.


The ESP-12F can be programmed directly from the Arduino IDE as a generic ESP8266 module!
Finally, I have some ideas to improve the electronics of v1.0 of the ESP-Live. There is a lot of unused PCB real-estatue under the PSU module. Of course, some of that space is important as there should be clearance between the mains and the rest of the low voltage circuitry. There is 2 or 3 cm of usable space, though!

I want to design a solar battery charger circuit and place it here. That way, I can use the ESP-Live with mains, and just leave the parts unsoldered. However, if I want a WiFi board out in the wild (like my garden), I can leave the PSU module off, and solder the solar circuitry!

I also want to use a smaller screw terminal without the gap (I still need to check if clearance will be ok), and then put a place for a MOV after the fuse for rudimentary protection from power surges. In case you didn't know, it's a Bad Idea™ to put a MOV before a fuse because if it fails short-circuit you want to cut the power before it bursts into flame! The house circuit breaker might do the trick here, but 15A through the MOV is not going to be pretty, regardless.

More money spending... ;)

Saturday, 10 December 2016

Custom VCSEL Bias Driver

I have been working on a laser diode bias driver for a while now, in line with my latest research project. ThorLabs recently released some great looking bias driver "chip" things, the MLD203 series. I felt that I could use these on a custom board to modulate laser diodes and VCSELs using my USRPs.


In the image above (and below) you can see the two red PCBs which I have designed and constructed. The bias driver (left) connects with an SMA connector to a Bias-T from Mini-Circuits to to TO-Can laser diode adaptor PCB which is visible on the right. I have designed everything to be low noise and high frequency compatible.


Unfortunately, I made a mistake with the laser diode footprint and so I had to mount it upside down! I soldered a SMD capacitor at the point where the little red wire connects to the diode to minimise adverse high frequency effects.



Check out the Git repo for this and more: https://github.com/ManCaveMade/LDBiasDriver

Tuesday, 6 December 2016

Aligning an LG Mode Sorter

The so-called "mode sorter" is a great optical device that allows for easy separation of Laguerre-Gaussian (LG) modes [Berkhout2010]. Combined LG modes, which contain Orbital Angular Momentum (OAM) are input to the one end of the mode sorter and on the other end they are output as "spots" which can be detected with a camera, fibre array, etc. This naturally has many uses in optical communications and physics in general.

I have been working with one of these devices and since the alignment is very tricky, I felt that it would be useful to document it here for my own reference and hopefully that of others!

  1. The first thing to make absolutely sure of is the incoming beams' level. This beam must be perfectly parallel to the axis of the mode sorter, otherwise getting the alignment right after the installation of the mode sorter is close to impossible. I find it useful to mount the mode sorter in a pair of lens mounts. Before installing the sorter, use one of the mounts at the desired height to ensure the beam is level.
  2. It's a good idea to place 2 separate mirrors before the mode sorter for dedicated alignment.
  3. Place the mode sorter in the path of the beam. Try to line it up with the center of the beam and make sure it isn't tilted.
  4. Using a card, check the shape of the beam at the output of the sorter. The beam needs to be "walked" into alignment. The beam should be a horizontal line that has no bumps, twists, etc. It will continue to be a line as you move the card away from the sorter to any distance. The beam will not be perfect when you first install the sorter...
  5. We label first mirror the beam hits on it's way from the source to the sorter is M1, and the second mirror is M2. (Do this in your mind...)
  6. Adjust M1 to make a flat line with the card ~2 cm from the end of the sorter. Now check the beam ~30 cm or more from the sorter. Adjust M2 to make it flat. Repeat this process until the beam is always flat (horizontal).
An aligned mode sorter showing the beam close to the end of the sorter (left), far from the sorter (middle) and an unaligned sorter (right).
There is a pattern to errors in mode sorter alignment. If the beam looks like the right hand image, above, then the vertical alignment is off. Let's call this a "W" shape. In this case, since the card is far from the sorter, M2 must be adjusted. Any "peaks" in the line are due to vertical errors in my experience. If the line looks like an "S" on it's side then there is horizontal error that will probably result in a W when it's fixed. If there are 2 separate blobs of light, you are way off and should probably start from scratch.

When you are finally happy with the beam, you can install a long focal length lens and a camera at the focal point so that you can decompose your beams! At least 500 mm is typically required. The paper referenced above has more detailed calculations as to the focal length of this lens. It is not necessary to place the lens directly after the mode sorter. Anywhere along the horizontal beam is ok - but normally space is at a premium and so mounting is a few cm away is the norm.

This entire process will probably take you an hour or more the first time :) Good luck!

Friday, 2 December 2016

ThorLabs Automatic Mirror Aligner Setup

For a project we are working on we invested in a ThorLabs KPA101 Position Aligner and a very sexy looking piezo actuated mirror mount as well as some other bits and pieces to make it work. Check out the photos below! In any case, we were hoping for an easy setup but it turned out to not be so easy...

This post documents the configuration and my experience with the (very expensive) equipment.

The Equipment:

The piezo actuated (2-axis) mirror mount with beam-splitter and quadrant photodetector in the background.


As you may have noticed from the photos, but we are using the following equipment:
  • KPA101 Position Aligner (basically just 2 PID controllers with photodiode inputs and -10 to +10V outputs)
  • Two KPZ101 Piezo Controllers (one for each axis of the mirror)
  • Polaris K1PZ2 mirror mount
  • PDQ80A Quadrant Photodiode (the controller tries to keep the beam centred on this)
  • Two SMB to BNC cables (ThorLabs provides these with the mount)
  • Two BNC to SMC adaptors (to connect the BNC to the Piezo Controller... more on this below)
  • Two SMA to SMA cables (to connect the aligner to the controllers)
  • Power supplies
Irritatingly, after we bought all the bits, at no insignificant expense, we found that although ThorLabs supplies cables, for some random reason the HV out on the Piezo Controllers is actually a fairly exotic SMC connector! There was no mention of the fact that one would need an adaptor by default to make this work (yes, we should have realised... before we were in the lab hooking it up). The adaptor is around $50 which is pretty steep, although we found one at Farnell/RS/Mouser for less and so we bought two there instead.

The Configuration:

We were hoping that everything would be relatively "plug and play" but unfortunately this wasn't the case.

The outputs of the position aligner PID controller are bipolar, -10 to +10V, proportional to how far the mirror should move on each axis to get the beam centred on the detector. Of course, centred means that the optical intensity in each quadrant is equal so one should ensure the beam is symmetrical. A fairly simple mechanism which one could achieve with an Arduino and some trans-impedance amplifiers if time was of no importance ;)

The outputs simply hook up to the piezo controllers. This is where the problem comes in. IMO the product managers at ThorLabs need to seriously rethink at this: the inputs of the piezo controllers are 0 to 10V. See the issue? There is no easy way to get a 5V offset, or to force the position aligner to output 0 to 10V centred on 5V, or some other compromise to make it work well. Basically, the beam can be controlled to move down and left. Right and up would also be handy, right? Well... the controller outputs a negative voltage for that, and the controllers don't know what to do with a negative voltage.

Our solution (for now) is to make sure the beam starts of slightly misaligned in tho top right quadrant on the detector so that there is an approximately 5V artificial bias on things. This way when there is some wobble, there is some range to correct in any direction.

For reference, these are the settings we used:

The top image is the open loop "default" config where we have set the inputs of the controllers to be from the external SMA which is fed by the aligner. Notice how the beam is initially positioned in the top right quadrant. Below, the beam is well centred by the controller at about 5V.
The position aligners PID settings are controllable from the PC application via USB. The defaults worked, but the control was very slow but stable. We are hoping to use the system for tip-tilt correction in a free space comms link and so we need it to be quite fast. We settled on the following values: P=1.0, I = 0.5, D = 0.5. This seems to be stable with no overshoot or oscillation that is significant to our application. I'm sure it can be improved upon. I will update this post if I do so.

We also set the y direction to be reversed since the input from the quadrant photodiode is reversed. This is documented by ThorLabs.

Conclusion

All in all, the controller seems to work well. There are some irritations when using it and the initial alignment in a system will be quite difficult because of the fact that negative control outputs don't work. With my custom PID settings the beam converges to the centre from the position shown in the photo above in half a second or so. Hopefully this works for our application!

Monday, 28 November 2016

Ultimate GNU Radio Install

I find myself installing GNU Radio quite often lately, so I felt the need to document all (most) of the steps.

I use Xubuntu because I like the simple, minimalistic feel of it and the speed! Xubuntu 16.04 doesn't seem to work well just yet and so I use 14.04 with all the updates. I also use the PyBOMBS version because it is up to date and it's easy to install new packages.

The guide here is a good starting point after installing updates, etc. I'll repeat the steps here for copy-paste reasons...

sudo apt-get update
sudo apt-get upgrade

Now for the PyBOMBS and GNU Radio...

sudo apt-get install python-pip
sudo pip install -U pip
sudo pip install pybombs

We need to set the PyBOMBS prefix. I have no interest in messing about with prefixes, so things PyBOMBS installs should appear to the system as normal programs.

sudo pybombs prefix init /usr/local -a usrlocal
sudo pybombs config default_prefix /usr/local

sudo pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git
sudo pybombs recipes add gr-etcetera git+https://github.com/gnuradio/gr-etcetera.git


We can now do the installation, but first you may notice an HTTPS error when we run PyBOMBS installs. This can be fixed as follows:

sudo pip install 'requests[security]'

Install!

sudo pybombs install uhd gnuradio

Now is a good time to sit back or go grab a coffee. It will take a few minutes to fetch and compile everything. On my old 2GHz i7 it takes over an hour and on my i7-6770 @ 4GHz it takes at least 15 minutes.

At this stage I like to do a little customization. I set the background to a nice GNU Radio logo and put a CPU and network monitor widget next to the clock. I also like to change the system highlight colour to a matching orange.

sudo ldconfig

You must run ldconfig every time PyBOMBS finishes something or odd things just won't seem to work!

Once the install is done, GNU Radio should be working. There are a few more settings to deal with to avoid warnings, etc.

sudo groupadd usrp
sudo adduser <my-login> usrp

sudo nano /etc/security/limits.conf

Add the following line to the bottom of the file:

@usrp            -       rtprio          99

I use USRP so I need the firmware packages:

sudo "/usr/local/lib/uhd/utils/uhd_images_downloader.py"

Finally, test by typing gnuradio-companion in a terminal. Close it again. Let's install some more packages!

Note: For some reason it's not working anymore... :(

Sunday, 27 November 2016

The ESP-Live

I was doing some shopping (read: surfing Amazon) for Black Friday and I was checking out all of the home automation gear. Things have come a long way! Home automation has been a passion of mine for many years - although to date I still haven't automated my lights! I will eventually prevail... I think that with the ESP-Live (my latest attempt) I will prevail.

Many years ago, when I was still in school, I remember interfacing some LEDs to my old Pentium I box via the parallel port. I had set up a Visual Basic 5 program to write bytes to the port. I messed around with logic chips to expand the number of input and outputs I had and I even had some transistors to switch relays. Sounds pretty primitive - right? The cool thing about this prototype system was I had a pretty good voice recognition system written using the Microsoft Speech API and it could respond to quite a few commands:

"Computer, turn LED one on.", "Computer, turn LED one off.", "Computer, start Linkin Park, Parpercut.", "Computer, set volume ten.", "Computer, pause music.", "Computer, pause music!!!". And it didn't work because it couldn't hear me over the music...

Nowadays the Google and Amazon speech recognition are getting really good. I think I will work on a project to interface the speech recognition into my home automation, one day.

Back to the point. Why do I still not have a working home automation system, you ask? I have spent many years trying to develop my own custom system. I personally think that buying a system off the shelf is too easy... and no fun! There are also features that I want, that probably don't exist except in extremely high end systems (and I haven't necessarily decided on these features just yet!). I have gone through many iterations of design with different technologies, but one fact remains: the switches must be wireless so that they are easy to install and they must fit into the wall to replace my current switches.

Perhaps some day I will write a post detailing all the light switched I have half designed... and why I stopped.

What is the ESP-Live?

Arduino has pretty much taken over the hobbyist world in my opinion. It's really easy to get something up and running in no time compared to the DIY approach with the raw microcontrollers, in circuit programmers, etc. Kind of like C++ versus C#, I guess.

I usually prefer to not use something like Arduino, because it's too easy. In recent years, however, I have changed my mind. I think that since Ardunio is literally just a comprehensive C/C++ wrapper on top of existing Atmel gcc, it's not really cheating... I still want to design my own hardware - but at least now I can do that and not waste too much time on bringing it to life.

I like the ESP modules because they have a lot of documentation and are powerful and really cheap! I like what NodeMCU has done in making the ESP8266 more like an Arduino, but I still want to do C programming and not script in Lua.

The ESP-Live is an ESP-12F module, on a fairly general purpose board with all of the IO's broken out, with a USB-Mini port for programming and debugging, power supply, etc.

What's different then? 

The ESP-Live has an on board AC/DC converter so that you can connect it directly to the mains! The shields can then be things like TRAIC or MOSFET dimmers, power measurement boards, etc. I have also designed it to be as compact as possible. The final design measures a mere 30x65cm! Small enough to fit inside a 2x4 inch light switch box inside the wall.

I'll post the design files on GitHub soon.

PCB and Schematic:


A 3D rendering of the top of the PCB. The areas for the ESP module is visible on the right. To the left is the area for the power supply module and AC input.



Quark One Bootloader

In 2015 I decided to try out the ESP8266 line of WiFi modules. I did a lot of reading and I determined that I didn't like they normal way people used them. I decided that the ESP modules needed an additional microcontroller to be truly useful in terms on analog to digital conversion and other IO features.

The Quark One was born. I will write about the hardware details in another post. Suffice to say, I wanted to try out the Atmel Xmega microcontroller due to it's relatively low cost and great feature set. I also wanted everything to work with the Arduino IDE!

Typically, when people connect an ESP module to a microcontroller, they flash it separately and then integrate everything. I didn't like this way of doing things and so I hacked together and then polished a new bootloader for the Xmega which presents two separate USB devices to the computer it is connected to: the first device is the CDC Xmega bootloader, as one would expect. The second device is a CDC that passes through the chip to the ESP module! You probably guessed it by now, but I used the USB device built into the micro and then one of the hardware serial ports to interface to an ESP-01 module.

The Quark One bootloader deals with the reset signals to enable the ESP to be programmed from the Arduino IDE as if it was simply connected to a USB to Serial converter! To write code and flash the ESP, you do so in the usual way. To write code for the Xmega, I had to extend the xmega-arduino library to include the Quark One pin mapping. Otherwise, this is also standard!

To activate the bootloader I took some inspiration from the Arduino Lilypad type devices. A quick "double click" of the reset button on the edge of the Quark One puts it into bootloader mode.

Check out the source code on GitHub: https://github.com/ManCaveMade/QuarkOne-Bootloader

The bootloader should work on any Xmega chip that has quite a bit of bootloader flash... I used the Xmega128A4U.

Let me know what you think!

Home Assistant Hue Emulation

My Home Assistant setup uses nginx to proxy the web interface to HTTPS. I bought a Google Assistant for black friday and I want it to be abl...