IoT Monitoring System for Commercial Fridges

Using LoRa Technology

IoT implementations can take many shapes and forms. Learn how these four Camosun College students developed a system to monitor all the refrigeration units in a commercial kitchen simultaneously. The system uses Microchip PIC MCU-based monitoring units and wireless communication leveraging the LoRa wireless protocol.

In 2017, the commercial food service industry created an estimated 14.6 million wet tons of food in the United States [1]. The second leading cause of food waste in commercial food service, next to overproduction, is product loss due to defects in product quality and/or equipment failure [2].

While one of our team members was working as the chef of a hotel in Vancouver, more than once he’d arrive at work to find that the hotel’s refrigeration equipment had failed overnight or over the weekend, and that thousands of dollars of food had become unusable due to being stored at unsafe temperatures. He always saw this as an unnecessary loss—especially because the establishment had multiple refrigeration units and ample space to move product around. In this IoT age, this is clearly a preventable problem.

For our Electronics & Computer Engineering Technologist Capstone project, we set forth to design a commercial refrigeration monitoring system that would concurrently monitor all the units in an establishment, and alert the chefs or managers when their product was not being stored safely. This system would also allow the chef to check in on his/her product at any time for peace of mind (Figure 1).

FIGURE 1 – This was the first picture we took of our finished project assembled. This SLA printed enclosure houses our 10.1” LCD screen, a Raspberry Pi Model 3B and custom designed PCB.

We began with some simple range testing using RFM95W LoRa modules from RF Solutions, to see if we could reliably transmit data from inside a steel box (a refrigerator), up several flights of stairs, through concrete walls, with electrical noise and the most disruptive interference: hollering chefs. It is common for commercial kitchens to feel like a cellular blackout zone, so reliable communication would be essential to our system’s success.

SYSTEM OVERVIEW
We designed our main unit to be powered and controlled by a Raspberry Pi 3B (RPi) board. The RPi communicates with an RFM95W LoRa transceiver using Serial Peripheral Interface (SPI). This unit receives temperature data from our satellite units, and displays the temperatures on a 10.1″ LCD screen from Waveshare. A block diagram of the system is shown in Figure 2. We decided to go with Node-RED flow-based programming tool to design our GUI. This main unit is also responsible for logging the data online to a Google Form. We also used Node-RED’s “email” nodes to alert the users when their product is stored at unsafe temperatures. In the future, we plan to design an app that can notify the user via push notifications. This is not the ideal system for the type of user that at any time has 1,000+ emails in their inbox, but for our target user who won’t allow more than 3 or 4 to pile up it has worked fine.

FIGURE 2 – The main unit can receive temperature data from as many satellite units as required. Data are stored locally on the Raspberry Pi 3B, displayed using a GUI designed by Node-RED and logged online via Google Sheets.

We designed an individual prototype (Figure 3) for each satellite monitoring unit, to measure the equipment’s temperature and periodically transmit the data to a centralized main unit through LoRa communication. The units were intended to operate at least a year on a single battery charge. These satellites, controlled by a Microchip Technology PIC24FJ64GA704 microcontroller (MCU), were designed with an internal Maxim Integrated DS18B20 digital sensor (TO-92 package) and an optional external Maxim Integrated DS18B20 (waterproof stainless steel tube package) to measure the temperature using the serial 1-Wire interface.

— ADVERTISMENT—

—Advertise Here—

FIGURE 3 – This enclosure houses the electronics responsible for monitoring the temperatures and transmitting to the main unit. These were 3D printed on Ultimaker 3 printers.

HARDWARE
All our boards were designed using Altium Designer 2017 and manufactured by JLCPCB. We highly recommend JLCPCB for PCB manufacturing. On a Tuesday we submitted our order to the website, and the finished PCB’s were manufactured, shipped, and delivered within a week. We were amazed by the turnaround time and the quality of the boards we received for the price ($2 USD / 10 PCB).

Main Unit Hardware: As shown in Figure 4, our main board’s purpose is communicating with the RPi and the LCD. We first had to select an LCD display for the main unit. This was an important decision, as it was the primary human interface device (HID) between the system and its user. We wanted a display that was around 10″—a good compromise between physical size and readability. Shortly after beginning our search, we learned that displays between 7″ and 19″ are not only significantly more difficult to come by, but also significantly more expensive. Thankfully, we managed to source a 10.1″ display that met our budget from robotshop.com. On the back of the display was a set of female header pins designed to interface with the first 26 pins of the RPi’s GPIO pins. The only problem with the display was that we needed access to those same GPIO pins to interface with the rest of our peripherals.

FIGURE 4 – The main unit PCB’s role is simply to allow the devices to communicate with each other. This includes the RFM95W LoRa transceivers, RPi, LCD screen and a small fan.

We initially planned on fixing this problem by placing our circuit board between the RPi and the display, creating a three-board-stack. Upon delivery and initial inspection of the display, however, we noticed an undocumented footprint that was connected to all the same nets directly beneath the female headers. We quickly decided to abandon the idea of the three-board-stack and decided instead to connect our main board to that unused footprint in the same way the RPi connects to display (Figure 5). This enabled us to interface all three boards, while maintaining a relatively thin profile. The main board connects four separate components to the rest of the circuit. It connects the RFM95W transceiver to the RPi, front panel buttons, power supply and a small fan.

FIGURE 5 – Our main board, labeled Mr. Therm, was designed to attach directly to the LCD screen headers. RPi pins 1-26 share the same connectivity as the main board and the LCD.

Power Supply Design: We designed our own power supply (Figure 6), to add more to the hardware side of our project. However, for safety’s sake, we also designed a PCB to mount a CSA-approved power supply module, so we could test the system in commercial kitchens without worrying about burning them down. When we began the design process, we planned on connecting a transformer directly to the line voltage to step it down, followed by a buck converter for regulation. We did some searching and immediately realized that any transformer that fit our specification would be way too big and heavy to fit inside our enclosure, sending us back to the drawing board.

FIGURE 6 – Our schematic stepping down the 120 V mains to 5 V. This was built using the flyback topology, to minimize the overall physical size inside of the enclosure.

After doing some research, we came across a switching power supply topology that we had not covered in school–the flyback topology. Most power supplies used in modern electronics employ this topology, because it allows for a significantly smaller transformer while maintaining a relatively low part count. It accomplishes this by placing the switching element in series with the transformer. We began by finding a suitable PMIC (power management integrated circuit), the NCP1027 from ON Semiconductor. The next step was finding a transformer. Luckily, we found one specifically made for the NCP1027, the DA2077 from Coilcraft. From there, we were able to design the rest of the circuit shown in Figure 4, using the NCP1027’s datasheet and the many reference designs Coilcraft provides.

Satellite Unit Hardware: We designed the satellite units (Figure 7 and Figure 8) to be placed either inside a refrigerator or magnetically mounted on the refrigerator’s side, with a temperature probe running in. Our primary concerns when designing the satellite units were power consumption and temperature accuracy. The goal was to keep the unit small, so that we could reliably solder by hand, and it would not take up too much room in smaller refrigerators. We decided to use four AA batteries to maximize both capacity and user serviceability. To reach the 1+ year battery life that we were aiming for, we had to design with efficiency in mind, starting with power regulation. After some research, we selected the Analog Devices LT3971 3.3 V buck converter for its ultra-low quiescent current (< 2.5 µA).

Figure 7
Figure 8

FIGURE 7 – This device is controlled by the PIC. It monitors the refrigerator’s temperature with a DS18B20 on the 1-Wire bus, and transmits to the main unit via the RFM95W transceiver.

FIGURE 8 – The finished satellite PCB with a long-legged post-production decoupling capacitor added for good measure.

Powering our PIC24FJ64GA704 MCU and RFM95W LoRa transceivers off of the same 3.3 V net, our aim was to transmit temperature data four times per hour. After deciding that the smallest acceptable accuracy for our temperature sensor would be ±0.5°C (± 0.9°F), we chose the DS18B20 1-Wire sensors.

SOFTWARE
Satellite PIC Software Flow: The satellite units were programmed in the MPLABX/XC16 IDE provided by Microchip and MPLab Code Configurator v.3 (MCC) plugin to facilitate coding. To our knowledge, this is the standard development environment for PIC programming.

The satellite units are controlled by the centralized PIC MCU and designed to measure multiple DS18B20 temperature sensors on a 1-Wire multidrop bus. A multidrop bus was required to allow several slave devices on each unit. This provided an ability to concurrently monitor refrigerators located in close physical proximity to each other on a single satellite.

— ADVERTISMENT—

—Advertise Here—

The 1-Wire Driver Flow: Each step starts with an initialization command (Link Layer) followed by ROM command (Network Layer) and a function command (Transport Layer) as needed.

Step 1
The PIC searches the 1-Wire bus to identify how many devices (slaves) are connected to the bus, and what their individual ROM codes are.

Step 2
The PIC configures the scratchpad memory (SPM) (Figure 9) to change the thermometer resolution to 10 bits from 12 bits (the default). From the DS18B20 datasheet, this gives us accuracy to ± 0.25 °C with a 187.5 ms maximum conversion time.

FIGURE 9 – From the DS18B20 datasheet: The Memory Map (Scratchpad Table) of the temperature sensor [3].

Step 3
The PIC initiates a single temperature conversion. This is stored as 2 bytes in the scratchpad memory on the temperature sensor.

Step 4
Now, it’s time for the PIC to read the scratchpad which contains our 10-bit temperature data in binary.

After acquiring the temperature, the PIC prepares a packet for LoRa transmission. The PIC identifies each individual satellite unit to the main unit, by using a DIP switch representing its common Network ID and unique Node ID. The Network ID consists of 2 bits and Node ID is 4 bits.

We chose this specific version of the PIC MCU, because it boasts the feature of Microchip’s eXtreme Low-Power (XLP) consumption. The load switch is present in the circuit to feed power to the peripherals when required, and to power them down when not. It is controlled on/off by the PIC. Its purpose is to maximize power saving and get as much battery life as possible. The PIC feeds a 3.3 V logic directly to the controller pin of the load switch to activate it, then delays 10 ms for the peripherals to power up.

LoRa Wireless Transmission: Now, it’s time to prepare the PIC’s data packet for transmission to the RPi. The PIC communicates with the RFM95W module through SPI.

LoRa Initialization: For each transmission, the PIC initializes the RFM95W with an active low-logic reset on Pin 6 to reset the register values. Since this was developed in British Columbia, Canada, RF is set to 915 MHz, the ISM (Industrial, Scientific and Medical) radio band up here in the north. Low-noise Amplifier (LNA) boost and Auto-gain control (AGC) are also set. Adding CRC (cyclic redundancy check) information is enabled to allow the receiver to discard packets with invalid data [3]. Transmission power is then set to +17 dBm (the datasheet maximum power is limited to +20 dBm). The PIC will then write the data packet (payload) onto the RFM95W FIFO register.

LoRa Transmission: The transceiver is put into TX mode, and transmission is initiated (Figure 10). The PIC is polling the RegIrqFlags register, waiting for the TxDone bit to go high. This indicates a transmission is complete. At this point, the PIC puts the RFM95W into RX mode to await a “packet received” message (ACK) from the main unit. There is a 100-ms timeout to await the response from the main unit. Then, if no ACK is received, there is a random interval delay (100 ms to 1 second) before the RFM95W will reattempt to transmit the payload. This randomized interval decreases the chance of interference with transmission from the other satellite units. The satellite unit makes three transmission attempts before going into sleep mode.

FIGURE 10 – This is the format of the data packet being sent from the satellite unit to the main unit.

Watch Dog Timer (WDT): As soon as the PIC program starts, the WDT starts ticking. WDT times out at 16.384 seconds. The timeout causes a system reset, and the program restarts. The timeout is expected to happen when the program is stuck in a while loop during serial communication. WDT also works to wake-up the system from Sleep Mode. The program has to continue the process of sleep and wake-up several times to reach the desired time-out (about 15 minutes).

MAIN UNIT
LoRa Task: The LoRa Task puts the transceiver into Continuous Reception Operating Mode. In this mode, the transceiver continuously listens for an incoming packet. When the fidelity of the incoming packet is checked, it is stored in the transceiver’s FIFO register. The transceiver then sends an interrupt signal via DIO0 to the RPi. This is the trigger for the ISR running on the RPi to initiate SPI protocol and access the RFM95W’s FIFO register to read and save the data into a file.

Node-RED Task: The Node-RED task program was designed to read from a data file being written by the LoRa task. This file is updated with the received data connecting the temperature value to its ROM ID. Accordingly, this file overwritten each time data are received—no data logging here.

The Node-RED task’s next job is to combine the data in both the XML file created during setup and the data being updated by the LoRa task. Basically, a new data packet is created that now associates the name of the unit being monitored with its temperature data. The Node-RED task also monitors the state of the data—have the data been updated recently, or are we sending old data and there may be a problem with the satellite unit? As we aim to update the LCD every 15 minutes, if the timestamp of the data is more than 30 minutes old, we include this in the payload to Node-RED to alert the user of the possible issue. The Node-RED task now posts this data packet to Node-RED for the GUI display, local data logging and email alerts.

Node-RED is responsible for bringing the whole system together. It monitors the data packet containing temperature data, utilizes “email“ nodes to alert the users when their temperatures are not in a safe food-storage range, displays the relevant data on the LCD screen and logs 24 hours of data. It also actively monitors the GPIO pins of the RPi, which are responsible for GUI navigation and reset.

— ADVERTISMENT—

—Advertise Here—

Anyone who has used Node RED before will agree that it is an enjoyable way to program a GUI. We did find that the Node-RED community support was a bit lacking. That made it tougher for us to customize the layout and appearance of our GUI.

Note: To access some of the nodes we used, you must first install the Node-RED dashboard via the “Manage Palette “ setting. This gives you access to the “template” node, where you can build a GUI using static HTML and JavaScript. This gives you the freedom to completely customize your GUI.

ENCLOSURES & GOOGLE DOCS
Satellite Units: We designed the enclosure for our satellite monitoring units using Autodesk Fusion 360. We had access to several Ultimaker 3 and Ultimaker 3 Extended 3D printers. Printing our enclosure prototypes with polylactic acid (PLA) would not give us the long-term water resistance that our sensors needed, but served as acceptable prototype models. PLA is biodegradable and derived from renewable resources, and was available to us in a variety of bright and vibrant colors. PLA also holds up well in cold environments, considering we were popping these into refrigerators and freezers.

Main Unit: We recruited a mechanical engineering technologist to design and print the enclosure for the main unit and LCD. He provided us access to a Viper SLA printer, and designed some sleek enclosures for our LCD housing (Figure 11).

FIGURE 11 – This is the enclosure after being raised out of the resin.

Google Docs: Because our target demographic is a chef or food service manager (not usually technically oriented), we chose to go with a basic and user-friendly format. Storing the data on Google Forms gives accessible data on any mobile platform, and with multiple PC operating systems via Google Sheets. Compared to using ThingSpeak or Firebase, we didn’t think that for our purpose, accessing the data in .JSON or .CSV format was necessary. We required something that could be opened up and checked by the least technologically savvy person.

CONCLUSION
This project was a great learning experience for our team of rookie technologists. We had huge success with the RFM95W transceivers. When testing our signal strength, we were able to transmit reliable data until about -120 RSSI. We had no problem transmitting from inside a refrigerator, up several flights of stairs, and to the main unit. The line-of-sight transmission data were reliable up to about 1 km.

In hindsight, we likely would have used an alternative to Node-RED. Although it was fast and easy to get a basic GUI up and running, we found it quite difficult to customize. However, that may be because of our own inexperience. In addition, we should have spent more time designing for effective EMC (electromagnetic compatibility) and making use of proper decoupling capacitors in the PCB design stage. This as a topic was introduced after we had designed our PCBs, and would have influenced the way we designed our circuit boards.

For detailed article references and additional resources go to:
www.circuitcellar.com/article-materials
References [1] through [3] as marked in the article can be found there.

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MARCH 2019 #344 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!	Don't miss out on upcoming issues of Circuit Cellar. Subscribe to Circuit Cellar Magazine Note: We’ve made the May 2020 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.
Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article

Tyler Canton, Akio Yasu, Trevor Ford and Luke Vinden

+ posts

Tyler Canton (tylercanton1@gmail.com) worked as a Chef for 17 years before becoming an electronic and computer
engineering technologist. He hopes to pursue a career in naval electronics on Vancouver Island, Canada.

Akio Yasu (akioyasu@hotmail.com) worked as a programmer (C/C++) for 15 years. He chose to obtain a diploma in electronics and computer engineering technology to learn more about the hardware side of electronics.

Trevor Ford (trevorford@hotmail.ca) is an electronics and computer engineering technologist who, after completing the bridge program at Camosun College, plans to obtain his bachelor’s in engineering from the University of Victoria. Trevor is interested in analog circuit design and printed circuit board design.

Luke Vinden (lukevinden@gmail.com) is an electronics and computer engineering technologist from Camosun College. He has a background in construction and hospital renovations. He has an interest in object oriented programming.

Using LoRa Technology

Tyler Canton, Akio Yasu, Trevor Ford and Luke Vinden

You may also like

IoT Monitoring System for Commercial Fridges