Skip to main content

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:

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... ;)


Popular posts from this blog

Simulink 2x1 MIMO Channel Estimation Test

I have been working on a MATLAB Simulink based Alamouti testbed for USRP software defined radio. I am using the Ettus B210.

I have implemented a very simplistic channel estimation scheme whereby I transmit each of the four QPSK constellation points on each antenna consecutively. I then receive using a single antenna, and after all of the frequency and phase synchronisation I divide what was received by the ideal constellation leading to a simple H-matrix.

Check out this video where you can see the pilot constellation change as I move the antenna! Awesome!

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:

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!

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 mount…