Recap
Welcome again! This is my 6th blog in a series I am writing for the Summer of Sensors Design Challenge kindly sponsored by Element14 and in my case Vishay. The challenge is to make use of two selected sensor boards from Vishay’s SensorXplorer range. My project is an adaptive, smart bulb controller designed to save electricity, reduce eye tension and spark an interest in the Internet of Things (IoT) universe. In my last blog I successfully integrated the colour sensor (VEML3328) to the ESP32 micro-controller.
Introduction
I will try to keep today’s blog fairly short, but I just want to update you all on the progress of the sensor integration. I have now successfully integrated the second sensor board, the VCNL4035 Gesture Board, with contains the proximity sensor and ambient light sensor. These sensors will be integral to this project since they will be used to control the on/off state and brightness of the smartbulb.
Integrating the Gesture Board
After examining the datasheet of the VCNL4035 gesture board in more detail I discovered that the array of components in the top right corner of the board (which I originally incorrectly assumed to be a proximity sensor array in one of my earlier blogs) is actually an array of LEDs positioned and connected together in such a way as to depict 6 different symbols (among which are an up, down, left and right arrow). These can be controlled over I2C using the same PCA9554 GPIO controller as the RGB LED on the VEML3328 sensor board.
In my previous blog you will have seen that I successfully controlled the RGB LED over I2C which will be useful as a status LED, so I don’t particularly have need for this “gesture indicator”, but since it uses the same PCA9554 device I already have the code written to control it.
One annoying thing about this board is the I2C slave address of the PCA9554 used to control the arrow LEDs is the same as the I2C slave address of the PCA9554 used to control the RGB LED on the first sensor board. If you remember from my last blog the slave address of this GPIO controller is configured using three external pins (A0, A1 and A2). On the VEML3328 board they were all tied high (logic 1). The idea is that in other places where the same controller is used, those pins would be configured differently so the slave address would be different. However, Vishay obviously assumed that these two boards wouldn’t be used together in the same application so they have both been given the same slave address. As it happens, for my project, this is not the end of the world since I don’t need any more LED outputs – the RGB LED is fine for my design.
It is worth noting that since they both share the same slave address, they will both respond to the I2C commands being sent on that bus (assuming the slave/master acknowledgement doesn’t get in a pickle). This means that when I turn on the red LED (on the VEML3328 colour board) the UP arrow (on the VCNL4035 gesture board) will also illuminate because they are connected to the same GPIO number. To this end, I have updated my code to reflect which LEDs are connected to which pins on the GPIO controller in my header file for this controller:
Here you can see that the white LED (on the colour sensor board) does not share a GPIO number with the LEDs on the other board, and the left/right arrows (on the gesture board) do not conflict with anything on the colour sensor board. So potentially we could use some indication on one board and some on the other board to avoid conflicts, or we could just turn on the red LED on the colour sensor board and put up with the fact that this will also illuminate the down arrow on the gesture board. If it really bugs me, then I could take a soldering iron to one of the PCA9554 ICs and reconfigure one of the address pins to give a different slave address!
Anyway, with that bad news out of the way, the good news is that the I2C slave address of the ambient light and proximity sensor (which are incidentally integrated into the same IC in the centre of the board) is an entirely different value so there are no conflicts here which makes the integration of the final sensor a breeze. Looking at the datasheet for the integrated sensor I see that the I2C slave address can be 1 of 4 values depending on the option selected:
So I took a look at the schematics for Vishay’s Gesture sensor board and it shows that the “4035X01” model is fitted to the board meaning the slave address is 0x60:
This information allowed me to write some code to control the VCNL4035 sensor device. As before I created a separate file for this functionality - a source (.c) file for the implementation and a header (.h) file for function prototypes and defining constants (such as the slave address). I created two public functions – one to read the proximity value and one to read the ambient light level. These will then be used to control the smartbulb’s on/off state and brightness respectively.
With this code implemented, I then added some quick debug to the main application loop to print out the proximity value and ambient light value (alongside the RGB value which was being printed last week). The output of this code running on the ESP32 can be seen in the terminal window at the bottom where “P” is the proximity value and “A” is the ambient light level. Half way through the run, I placed my hand a few inches above the board. This can be clearly seen in the output where the proximity level increases (larger values indicate closer distance) and the ambient light level reduces substantially (because my hand was blocking a lot of the ambient light). This screenshot shows that the three sensors are now fully working and integrated with the ESP32 micro-controller.
Coming Next…
With the sensor integration satisfactorily completed, the next stage of the project is to integrate with the smartbulb. My next blog will document this process and will include setting up the WiFi connection on the ESP32, reverse engineering the smartbulb protocol, controlling the smartbulb from the ESP32, and ultimately controlling the smartbulb based on the three sensor readings taken above.
Thanks again for your interest in this project and stay tuned for the next exciting instalment in a few days’ time.
| Previous Blog (Part 5) | Next Blog (Part 7) |
