Project: SkyPi
The First Step to a Connected Lab
In the last quarter and a half of my first year as Product Engineer in Lattice Semiconductor, I proposed a project to improve the current lab monitoring process. The resulting embedded solution introduces several connected features that supplements the current monitoring process, and lays the foundation for future connected-lab related improvement projects. This serves as an overview of Project: SkyPi and its development process.
The Problem
A Quick Background
Lattice Semiconductor’s Manila office has several lab facilities, and strict environment control is imposed to provide a consistent setting for lab operations.
Among others, the labs use Omega Engineering’s CTXL-TRH sensors to measure and record ambient temperature and humidity.
What’s the problem?
The process of monitoring the temperature and humidity could be improved. The CTXL sensor performs its intended task, but not much else. Some limitations include…
- A physical inspection is required to get the current measurements of a particular CTXL sensor, and there are multiple sensors deployed across the lab facilities.
- The CTXL records the environment data onto circular paper charts for storage and analysis. This makes backtracking and correlation of out-of-spec events tedious.
- The CTXL emits an alarm to notify lab staff in the local area that the environment is out-of-spec. However, there is no way to inform other lab staff about the environment unless someone in the lab sends out the alert.
While none of these issues are critical, combined they can take valuable time. I saw an opportunity to apply my hardware development skills and improve the monitoring process, and proposed a solution to my managers.
The Solution
What should the solution do?
The solution is aimed to supplement the current lab monitoring process with digital, connected features. It should…
- Record environment data digitally using the CTXL’s readings. The CTXLs are ISO-9001 certified, so their use is mandatory.
- Alert all lab staff of significant environment events in the lab.
- Live-monitor an area of the lab. Security cameras only monitor the labs’ entrances and exits. An additional camera adds another layer of safety.
- Make the environment data and live-feed available to lab staff.
To top it all off, the solution must not prevent the CTXL from operating as expected, as the CTXL will still be the primary method for alerting the local area of significant environment events.
What is the solution?
After some research, the solution (codename: SkyPi) was proposed to be an embedded device that pairs with a CTXL, and interfaces with Lattice’s existing IT infrastructure. The embedded device will…
- Interface with the CTXL and sample data at regular intervals.
- Store that data internally.
- Monitor a specific area of the lab it is stationed in.
- Host a website where staff can view the lab’s status, the live-feed, and the environment history.
- Email lab staff if it encounters significant environment events.
Hardware
After the solution definition, it was time to purchase the hardware necessary to realize SkyPi. The key components of a SkyPi setup are…
Raspberry Pi 3
The Raspberry Pi 3 was chosen as the primary embedded device for many reasons.
- The Raspberry Pi 3 accomplishes several requirements in one package. It can interface with the CTXL, gather and store the data locally, act as a web server, send emails, and more.
- The Raspberry Pi 3 has built-in WiFi. This allows the Pi to be setup closer to the CTXL sensors.
- Other reasons, such as…
- Established community, plenty of example code, tutorials, etc.
- I have prior experience in developing on the Pi.
RS Electronics sold the Pi as a kit with additional accessories, such as a case and power supply.
Raspberry Pi Camera Module V2
The Raspberry Pi Camera Module V2 is the Pi’s officially supported camera module. It was chosen for its synergy with the Raspberry Pi 3.
The Camera Module can be placed inside the case (from the aforementioned kit) along with the Pi, simplifying the setup.
Digilent PmodRS232 UART-RS232 Converter Module
The Raspberry Pi has no serial port; the next closest thing is the UART protocol using the Pi’s GPIO pins.
The Digilent PmodRS232 is required to convert the Pi’s GPIO voltage levels to the CTXL’s RS232 voltage levels and vice-versa, enabling data transfer between the two devices.
RS Pro 9 Way D-sub Female to RJ11 Adapter
The CTXL has an RJ11 port instead of a DB9 port, so a simple converter from RJ11 to DB9 was needed in order to connect to a device such as a laptop.
The DB9-RJ11 adapter is required to connect the PmodRS232 to the CTXL and complete the hardware bridge. This particular DB9-RJ11 adapter has breakouts for the user to custom assign the RJ11 wires to the DB9 pins.
RS Pro MNGC Series Gender Changer
The PmodRS232 converter and the DB9-RJ11 adapter both have female ports, so a gender changer (an M-M connector) is required to join the two.
The gender changer does not have any internal wiring of its own.
Final Bill of Materials
A budget of PHP49,815 ($1000 at the time of making the BOM) was allocated for the project. The total came to PHP28,929.10 (~$575).
The lab has four CTXLs, so materials for four SkyPi setups were purchased. In addition, a 7" touch screen LCD and case was purchased in case a mobile screen was necessary. All components were purchased from RS Electronics (PH), which is a licensed supplier.
SkyPi Architecture
The SkyPi architecture consists primarily of the Raspberry Pi 3.
As the embedded component, the Raspberry Pi 3 will run headless and interface with the CTXL. The Pi will store the sampled data in a local database. Finally, the Pi will run as a web server and serve a simple website.
I made the system architecture diagram using draw.io.
Interfacing the Hardware
The CTXL has a serial port for a device like a PC to connect to. The PC uses a program like PuTTY or HyperTerminal and establishes a serial connection to the CTXL using settings specified in the manual.
A Raspberry Pi should also be able to establish the same connection to the CTXL, with the help of additional hardware.
Raspberry Pi 3
The hardware interface begins with the Raspberry Pi 3. The Raspberry Pi 3 has 40 GPIO pins (including power and ground). Specific GPIO pins have additional functions and support protocols like I2C or SPI.
Since we’re using UART, I connected GPIO pins 8 and 10 (which correspond to the TXD and RXD lines) to the PmodRS232.
PmodRS232 UART-RS232
The PmodRS232 is the next item in the hardware interface, and is required to convert the Pi’s UART voltage levels to RS232 voltage levels, and vice-versa.
Based on the CTXL’s serial connection settings, Pins 1 and 2 of the PmodRS232’s UART side are unused. Pins 3 and 4 connect to the Pi’s UART pins. Pins 5 and 6 connect to the Pi’s VCC and GND pins. The PmodRS232 suggests a VCC of 3.3V.
The only pins necessary in the DB9 side (besides GND) are pins 2 and 3, the RXD and TXD pins.
DB9-RJ11 Converter
The DB9-RJ11 Converter is the next item in the hardware interface, and simply connects the pins from a DB9 connector to an RJ11 connector.
The advantage of the DB9-RJ11 converter purchased from RS Electronics is that the RJ11 wires are color coded and broken out, allowing the user to custom assign the wires to the DB9 pins.
CTXL-TRH
The last item in the hardware interface is the CTXL. The CTXL has a RS232 port that a PC can interface with to gather data or calibrate the sensor, among other commands.
According to the CTXL’s datasheet, the CTXL came with a DB9-RJ12 adapter for interfacing with a PC.
However, the only serial-related supported accessory on the CTXL’s website is a DB9-RJ11 connector (see below), similar to the aforementioned DB9-RJ11 converter.
RJ11 uses four wires, while RJ12 uses six. Since the supported accessory lists an RJ11 connector (and only three wires are used for the serial connection anyway), I came to the conclusion that the RJ11 cable / connector will work for the hardware interface.
That was confusing. I’m not sure why there was a discrepancy between the datasheet and the supported accessories page.
Putting it all together
Unfortunately, interfacing the Raspberry Pi to the CTXL wasn’t as easy as connecting all the aforementioned parts together. It turns out, not all DB9 connections are made equal.
The CTXL, which is configured as a DCE device (Data Communications Equipment), is intended to interface with a PC, which is normally configured as a DTE device (Data Terminal Equipment). The DB9 connection between a DTE and a DCE is straightforward.
However, both the PmodRS232 and the CTXL are configured as DCE devices, which means that both devices’ TXD pins are connected to each other. The same thing applies for both devices’ RXD pins.
Data cannot be transferred this way. Instead, the Pi’s TXD pin must be connected to the CTXL’s RXD pin, and the Pi’s RXD pin must be connected to the CTXL’s TXD pin.
One solution is to swap the TXD and RXD wires once, somewhere in the connection (notice the crossover between the red and green wires in the diagram above).
Fly wires between the DB9 ports could work, but since the DB9-RJ11 adapter has internal wire breakouts anyway, the wire swap can happen inside the adapter and keep the setup clean.
Wiring Schematic
The whole thing can get confusing pretty quickly, so I made a basic wiring schematic (again using draw.io) between the Raspberry Pi, the CTXL, and the hardware in between.
The wire swap to point the devices’ TXD pins to RXD pins happens inside the DB9-RJ11 converter (the red and orange wires).
Final Setup
With the wiring confirmed, it was time to connect the components. After switching pins 2 and 3 on the DB9-RJ11 converter, all components can be connected without using fly wires, which makes for a clean setup!
Through this hardware interface, the SkyPi will send commands serially to the CTXL, which then responds with the data the SkyPi has requested. Onto the software.
Developing the Software
After interfacing the Raspberry Pi to the CTXL, the next step was installing the necessary software and developing the scripts.
Software Requirements
We weren’t doing any fancy or performance-intensive tasks with the Raspberry Pi, so open-source software was sufficient for our needs.
Operating System: Linux (Ubuntu Mate 16.04)
Web Server: Apache2
Database: MySQL
Scripting Languages: Python / PHP
Back-End Scripts
I wrote several scripts in Python, executed at set time intervals by cron.
- One script samples the data (temperature and humidity) from the CTXL, and saves that data as an entry in a MySQL database.
- One script emails lab staff if significant environment events have been detected (more detail later).
- One script queries a week’s worth of gathered data from the MySQL database, saves that data as a CSV file for permanent storage. This script runs once a week.
Some Python libraries used in these scripts include:
- pyserial: A library for establishing serial connections and transmitting / receiving data serially.
- MySQLdb: A library that serves as a Python interface for interacting with MySQL databases.
- smtplib: A library for emailing text and attachments.
Front-End Code
I wrote a simple website to display all of the necessary info. PHP queries a range of data from the MySQL database, and JavaScript modifies some elements of the website depending on that data.
Some JavaScript libraries / APIs used include:
- date.js: An easy-to-use, powerful date library.
- ZingCharts: An easy-to-use, feature rich API for generating charts.
Motion and MotionEye
Motion is a daemon that monitors the signal from video cameras (in this case, the Raspberry Pi V2 Camera Module). It can be installed on the Raspberry Pi.
MotionEye is a web front-end of the motion daemon, with an admin dashboard that allows the user to customize settings or select cameras to use. The resulting live-feed is port-forwarded to the website.
Deployment
The SkyPi’s small footprint and built-in WiFi allows it to be set up close to the CTXL. As long as the SkyPi is connected to the internal network, the power supply, and the CTXL, it will operate as expected.
Without WiFi, the SkyPi is still able to gather and store data. However, the SkyPi will not be able to send out emails or respond to HTTP requests until it is connected to WiFi.
Website
From the website, lab users are able to view a quick summary of the lab’s current state, the MotionEye live-feed, and previous data as charts generated by ZingCharts.
Parameter State
Each parameter’s state (temperature / humidity) is based on its most recently measured value and its acceptable limits.
WITHIN SPEC: The parameter is within acceptable limits by a safe margin.
ALERT: The parameter is approaching spec limits.
OUT-OF-SPEC: The parameter has exceeded its acceptable limits.
Email Alerts and Lab State
The SkyPi sends out basic email alerts, indicating that the lab is within spec, or that the lab is (close to) out-of-spec. The email also include(s) the out-of-spec parameter(s).
The SkyPi sends out an email depending on the lab’s state, which is based on the combination of the measured parameters’ states (see above).
WITHIN SPEC: All parameters in the lab are within spec (and no parameters are on alert or out-of-spec). This is the ideal state of the lab.
ALERT: At least one parameter is on alert (but no parameters are out-of-spec). Lab operations can still continue in this state, as the lab is technically still considered within spec.
OUT-OF-SPEC: At least one parameter is out-of-spec. Lab operations must cease until all out-of-spec parameters are brought back within spec.
From any initial state, the lab can either maintain its current state or transition to one of the remaining two states.
Emails are sent out during specific lab state transitions. The email recipients and contents depends on the state transition.
Using transitions (instead of just the current state) prevents the script from flooding the lab staff’s inbox with potentially redundant emails.
CSV
The gathered data is initially stored as an entry in a MySQL database on the SkyPi. Every week, a script gathers last week’s data and saves it in a CSV file. The CSV file is sent to Lattice servers for permanent storage.
From there, lab users can access and analyze the environment history, and perform tasks like backtracking or correlating out-of-spec events without having to refer to the circular charts.
Special Thanks
This project would not have been possible without the support from several people, including…
My managers Dave Dy and Ronnie Asuncion, for greenlighting the project. Dave handled several key aspects of Project: SkyPi, particularly in networking, setting up motionEye, and email info from IT.
Lab staff Rey Abella and Richard Virtucio for supporting the project. Rey put in the purchase order for the parts, and provided me with additional hardware (including a spare CTXL sensor) to aid in Project: SkyPi’s development.
Closing Thoughts
Four SkyPi setups have been deployed across the lab facilities, and have been working as expected, without impacting the CTXL’s functions in any way.
Project: SkyPi is just the first step! From here, there are plenty of exciting routes to go — maybe in the next project, SkyPi can be given control over the lab’s HVAC system and maintain the environment autonomously… Too far?
Regardless, I think SkyPi is a great foundation for future connected-lab related continuous improvement projects.
Thank you for reading! For questions or comments, please feel free to contact me on LinkedIn.
