Skip navigation
> RoadTest Reviews

Omron Environmental Sensors - Review


Product Performed to Expectations: 10
Specifications were sufficient to design with: 10
Demo Software was of good quality: 7
Product was easy to use: 9
Support materials were available: 10
The price to performance ratio was good: 9
TotalScore: 55 / 60
  • RoadTest: Omron Environmental Sensors
  • Buy Now
  • Evaluation Type: Development Boards & Tools
  • Was everything in the box required?: Yes - Received both 2JCIE-BU01 (USB) version and 2JCIE-BL01-P1 (Bluetooth) version due to a shipping mix-up.
  • Comparable Products/Other parts you considered: Bosch CISS, DLP-TH1C, Oceasoft Emerald, Ruuvitag, Tempo Disc, XIaomi Mijia, Inkbird IBS-TH1
  • What were the biggest problems encountered?: Deficiencies in demonstration code.

  • Detailed Review:

    Omron Environmental Sensors RoadTest

    By Gough Lui – November-December 2019


    With the advent of relatively low-cost, compact, low-powered MEMS sensors, it has recently become possible to monitor a wide range of environmental parameters at a fairly reasonable price. While the sensor ICs and modules may be widely available, there are few turnkey solutions available on the market and rolling your own sensor solution may not always be easy or appropriate.


    Omron’s 2JCIE series of Environmental Sensors are low-cost, multi-sensor units which come with a fully documented interface (USB, Bluetooth Low-Energy) which can be directly integrated into various sensing projects without the need to design and build your own sensor solution. They come in various form factors including “bag”, USB-stick or bare PCB form factor for maximum versatility.


    Thanks to element14 and Omron for selecting me as a RoadTester for this product. Owing to a mistake in shipment, I have ended up with both the 2JCIE-BU01 (USB) and 2JCIE-BL01-P1 (Bluetooth) versions of the environmental sensors, so this review will cover both versions of the product. I will examine the product as shipped, setup process, documentation quality, compare it with other sensors and do a full teardown to examine its internals.


    As always, if you found this review interesting, useful, insightful or entertaining, feel free to like, bookmark, leave a comment, leave a rating or share with others who might find it interesting.


    Table of Contents


    Introduction & Market Survey

    With the explosion of Internet-of-Things style devices and low-cost MEMS sensors, there has been an interest in monitoring multiple environmental parameters for a number of different reasons. Increasingly, environmental conditions are well known to affect worker safety, performance and productivity. In schools for example, student attentiveness and performance can be impacted, while sick-building syndrome has received greater acknowledgement. Often, facilities managers are looking towards monitoring indoor air quality to ensure occupant comfort and to proactively understand maintenance requirements. But sometimes, the need to monitor the environment has to do with protecting the operation of the machinery and equipment that provide critical services (e.g. within utility cupboards and sheds) and to provide key data for predictive failure analysis.


    With this interest in mind, it seems like the market will demand “plug-and-play” style solutions to perform this monitoring without the need to design custom hardware and software. In line with industry requirements, this will often entail products which are well-documented, easy to integrate, have high reliability, ongoing support and availability guarantees from a reputable manufacturer.


    I looked around the market for environmental monitoring solutions that might fit this description at the time of this review. Some solutions from smaller companies appear to have environmental monitoring as a secondary aim or require the use of their platform and are not designed for tight integration. A wealth of options exist when it comes to development boards and modules, but these are not finished deployable products.


    This left us with a shortlist:

    • Omron 2JCIE-series
    • Bosch Connected Industrial Sensor Solution (CISS)
    • DLP Design DLP-TH1C USB-Based Multi-Sensor Module
    • Oceasoft Emerald Bluetooth Mobile Temperature Datalogger
    • Ruuvitag
    • Tempo Disc
    • Xiaomi Mijia Bluetooth Hygrometer/Thermometer
    • Inkbird IBS-TH1


    Of them, the first two probably best fit the description of industrial-grade reputable multi-sensor devices. The third device is perhaps suitable, although the company is not particularly well-known. The fourth device is specialised for logistic applications, while the remaining devices are from relatively young companies that feature more limited sensor features and are mainly targeting the consumer market. This makes them less suited for an industrial application.


    Concentrating on the Omron 2JCIE-series, there are three types of sensor available including Bag type, PCB type and USB type. The first two types (2JCIE-BL01) are identical in sensors and specifications, although the Bag type has its own enclosure and the PCB type is designed for integration into another device. These are designed for battery operation and all offer Bluetooth low-energy connectivity. Connectivity via USB and continuous power via USB is available on the 2JCIE-BU01. The types of measurements made by the BL-type vary slightly from the BU-type.


    Key specifications as excerpted from their datasheet include the following:



    It seems that the Omron series of sensors is best suited for indoor/office/factory comfort and safety monitoring purposes, which is evidenced in the inclusion of seismic detection, heatstroke and discomfort indices. However, the inclusion of UV index capabilities suggest that it may be suitable for outdoor usage given the appropriate precautions are taken. The sensors themselves are relatively intelligent – they feature onboard memory for periodic data logging, the ability to set flags for alarm purposes in case of thresholds (absolute value, rate of change, etc) being exceeded and can act as a Bluetooth advertising beacon (for one-to-many) applications or as a regular Bluetooth GATT device (for one-to-one connections).


    In contrast, the Bosch CISS is intended for condition monitoring of machinery with the capability of monitoring the operating environment as well. The specifications are summarised below:

    While there is some overlap in parameters, it bears mentioning that the CISS is much more expensive than the Omron sensor (list price approximately eight times more expensive), but it has an IP54 ingress protection rating and facilities to mount the sensor temporarily using magnets or permanently using bolts. As a result, the CISS is not the best match for the Omron in terms of market – but it’s probably the closest thing I could find and I’m lucky to have one thanks to the Harting MICA RoadTest earlier. It does have some similarities in providing both USB and BLE connectivity, but not in one-to-many advertising mode like the Omron.



    Let us take a look at what you get in each package.



    The PCB-type sensor comes in a white thin cardboard box with a label attached to one side that identifies the type of unit, the barcode, lot number and country of origin. A QR code is printed that contains more serial-numbering information.

    Inside the box are two static-dissipative bubble-wrap packages.

    One contains a set of coin-cell battery contacts.

    The other contains the complete PCB including insulating tape over the rear where the coin-cell contacts would be soldered down. I have placed the contacts in their rough position. No documentation is included within the package, so it is provided as a “part” rather than a product.


    I suspect the PCB that is provided is the exact PCB that goes inside the 2JCIE-BL01 “Bag type” unit as there are footprints for a CR2032 coin-cell and the battery contacts are included. That being said, that may actually be a trap …

    The battery contacts are easily shorted if the soldering is not done carefully as the metal plates have very little clearance.

    Even if it is soldered correctly, without the support of an enclosure, the CR2032 cell would just lever out of the contacts on its own, making a very poor connection. Unless you were to design and make your own enclosure that supported the battery, the battery contacts are perhaps not very useful.

    Instead, it would be better to solder in an alternative source of 3V (e.g. from a standalone battery holder of some description) as I have done in the image above.



    The USB-version comes in a similar sized-box, but it is printed in black and white including a line-art drawing of the sensor on the front. The sides show the regulatory approvals, hazardous substances contained within and country of origin. There is also a QR code that brings you to the product information page.

    Within the box, there is the USB-stick form factor sensor inside anti-dissipative bubble-wrap and a declaration of conformity leaflet.

    The sensor itself has a white-coloured plastic body with a metallic USB shell. The Omron brand is printed in grey on the top side, including a diffused plastic window for the light sensor within. The underside is labelled with the model information and conformance IDs. The sides have vent holes to allow for air movement to ensure accurate sensing.

    The USB connector itself appears to be made of the internal PCB, with some components visible from the end of the shell. The rear end of the unit is made of the diffused plastic, which is where the multi-coloured LED indication would appear.


    Documentation and Setup

    This section will look at the quality of the documentation, some of the more advanced features of the sensors, the supplied software and set-up process.



    The devices ship with very little to no documentation included, instead, the documentation can be downloaded from the website (BL, BU), consisting of brochures, datasheets, manuals and software.


    Both manuals have a number of similarities, so they will be discussed together. I found both manuals to be a fairly good read, free of any major errors, being relatively comprehensive about the advanced features and configurations that the devices are capable of. The manual makes use of numerous tables to highlight data formats and structures and flowgraphs or diagrams to clarify the mode of operation.


    After reading both manuals, it became clear that these environmental sensors are more than just sensors. The integrated memory within permits for data logging and retrieval over the BLE interface. The number of logging points is limited to 26,624 points (BLE version) or 60,000 points (USB version), but this is a great feature to have especially if there is no device constantly listening for broadcasts or connecting and querying the device. The devices support Bluetooth Advertising Beacon functionality which allows for the unit to do a one-to-many transmission, allowing the readings from the sensor to be shared amongst many Bluetooth hosts rather than requiring a one-to-one connection as a traditional GATT device would. Transmission power levels can also be adjusted to restrict range and increase battery life. Depending on the advertisement mode, different data could be made available on a programmable periodic basis. The device also features on-board processing of the data to set flags in case of exceeding fixed thresholds, changing by more than a given threshold or rate of change, computation of heatstroke and discomfort indices, and computing moving averages, with internal clock featuring 32-bit Unix time. The USB version also has acceleration measurement modes (similar to the Bosch CISS) and also seismic detection which is unique to Omron.


    On the downside, it seems that the units have limited security and configurability options. Some device name parameters are fixed, while the ones that can be changed cause problems for the mobile app and may not be the optimal outcome especially for integration use. It could be easy for an attacker to identify a 2JCIE-series sensor and reprogram it via using a BLE Scanner app and sending a few values to change its behaviour entirely. The broadcasting modes are pre-defined, and are only capable of conveying a sub-set of the measurement data requiring the choice of one mode or another with the compromise that entails. There also does not appear to be a way to disable the BLE radio on the USB version, which may be a problem if it is to be used in an application where radio use is prohibited. It also seems that despite both BLE and USB version being part of the 2JCIE-series, the sensors which are available are slightly different and the Bluetooth characteristic IDs are also different, thus it does not seem possible to use the one version of code with both devices without handling them separately.


    Omron GitHub

    Thanks to a tip-off from an element14 member, software suitable for demonstrating the 2JCIE-series of sensors is available from the omron-devhub GitHub account. This did not seem to be mentioned by the documentation. Specifically, the 2jciebl-bu-ble-raspberrypi project works with the BLE announcements and the 2jciebu-usb-raspberrypi works with the USB interface. Both projects are written in Python for easy integration and target the Raspberry Pi but could easily be ported to other platforms. The documentation for these programs is relatively limited and the capabilities of the sample programs do not exploit the full capabilities of the product.


    Set-Up for the 2JCIE-BL01-P1/2JCIE-BU01 BLE Interface

    As both sensors have a BLE interface, it seemed simpler to start with trying to get the BLE interface working. The provided sample code, however, proved difficult to install and get working.


    The code claims dependencies on python3 and pybluez, but installing these did not seem to be sufficient as errors were encountered referencing libboost, gattlib amongst other packages. After a number of hours of frustration, I was able to get the code working by doing the following:

    sudo apt-get install libbluetooth-dev python-dev libglib2.0-dev libboost-python-dev libboost-thread-dev

    pip3 download gattlib

    tar xvzf ./gattlib-0.20150805.tar.gz

    cd gattlib-0.20150805/

    sed -ie 's/boost_python-py34/boost_python3-py37/'

    sudo pip3 install .

    sudo python3 -m pip install pybluez pybluez\[ble\]


    Part of the issue is that gattlib seems to be coded to expect libboost to be installed under boost_python-py34, but the version and naming convention had changed as of the time of the review to boost_python3-py37. There are also unlisted dependencies on libbluetooth as well.

    After this process, it was possible to receive data from the sensors as long as they have been pre-configured with the advertising beacon mode that has measurements and the time has been set on the module. This is most easily achieved using the mobile apps listed towards the end of this chapter. There were, however, problems with the BLE sample code as was discovered later during testing.


    Set-Up for the 2JCIE-BU01 USB Interface

    On the Windows side, plugging the device in does not result in automatic installation as custom drivers are required.

    Drivers are provided on the website for the 2JCIE-BU01 which recognises the custom VID/PID of the Omron Environmental Sensor and provides a virtual COM port interface similar to regular FTDI drivers. This can be installed using the ‘Have Disk’ option.

    This is particularly useful, as there may be firmware updates available for the 2JCIE-BU01 to correct bugs and the DFU firmware update tool is provided for Windows. In my case, the supplied unit had firmware 0069 while the latest firmware available for 0070, thus I updated the firmware prior to using it any further.

    This is done by selecting the path to the .zip file containing the update and then clicking on the start button.

    After a minute, the update should complete successfully and the utility can be closed.

    To make the 2JCIE-BU01 operate under Linux does require some additional work as well, as the custom VID/PID pair is not detected by the ftdi_sio kernel module. Steps to add the PID/VID to the ftdi_sio module are provided inside the readme of the 2jciebu-usb-raspberrypi project on GitHub. Once working, it will be available in the /dev/ttyUSB0 path.

    To run the sample app requires installing pyserial using sudo pip3 install pyserial.


    Omron Mobile App

    Aside from the demonstration software on the GitHub account, there is also the ENV Monitor app which can be downloaded from the Google Play or Apple App store, which allows for you to test, configure, visualise and do limited recording from the sensors within the app but not the device.

    The application starts up into a screen which shows the identified Bluetooth sensors in the area including the mode of broadcast, MAC address, RSSI and device name. The device name shown seems to be memorised within the app and is not set on the actual device itself, meaning that using another device will cause the device name to show up as a blank.

    Clicking on the cog allows the advertising mode to be changed between the supported modes, along with a brief description of the data beaconed in each mode. Some of the finer details regarding special behaviours of the broadcast mode are not clearly indicated here and reference to the manual is necessary.

    Clicking on the device allows the real-time values to be visualised.

    Clicking on a particular value will bring up the trend graph which exists for each sensor type and can be changed between different plotting durations. This graph is built upon the data collected while the app is running on the phone and is not based on the data stored within the device. As a result, when the app is not running, there are gaps in the data.


    Many more advanced configuration settings are not available within the app, thus referring to the manual and using a third-party BLE testing app such as BLE Scanner from Bluepixel Technologies is recommended. This needs to be done with care, as improper values could result in improper operation which may be difficult to recover from – one of the key things to remember is the use of little-endian for all fields which often means that byte values need to be entered in reverse (least-significant byte to most-significant byte).


    Performance Comparison and Testing

    Both the 2JCIE-BU01 and 2JCIE-BL01-P1 were tested side-by-side in the same environment as the Bosch CISS to compare readings under a number of different test scenarios using the provided sample code modified slightly to allow for data logging. Testing of the power consumption of both Omron units was also undertaken.


    Indoor Comparison – Omron 2JCIE-BL01-P1 vs. Omron 2JCIE-BU01 vs. Bosch CISS (Round 1)

    Testing of the sensors was done using a Raspberry Pi 3B+ on which all the necessary software was installed. Modified versions of the sample code on the omron-devhub was used to perform data logging (attached to this review). Similarly, a modified version of the sample code from Bosch was used to log data from the comparison device, a Bosch CISS. For this test, both 2JCIE-BL01-P1 and 2JCIE-BU01 had the data values logged via their BLE advertisement broadcasts, while the Bosch CISS was logged via the USB connection. Recorded data was imported into MATLAB for analysis.

    Testing was performed inside my room, with all three sensors located in close proximity. The USB-version of the sensor was connected via a USB extension lead to avoid conducted heat from the Raspberry Pi 3B+ SBC.

    Initial viewing of the temperature data showed spikes all over, for both Omron sensors, the reasons for which would be elaborated towards the end of this section. Zooming in, we can see that with the exception of the spikes, the USB version appeared to trend well with the Bosch CISS reading virtually identically, whereas the BLE version measured about almost 1°C lower. This is within the specifications.

    Zooming further, we can see that both Omron devices have a resolution advantage over the Bosch CISS.

    Spikes persisted in the relative humidity channel, where the USB version again better concurred with the Bosch CISS values, differing by only a few percentage points. The BLE version, however, seemed to read about 10% higher. Considering the sensors each claim ±5% and the Bosch CISS claims ±7% at 20°C, these results seem slightly borderline as the expected difference between curves is around 8.6%.

    Aside from the spikes, measurements of barometric pressure seemed to concur very well across all sensors. In this case, both the Bosch CISS and USB-version had a resolution advantage over the Bluetooth version.

    Ambient light measurements were very much variable (±100 lux Omron/15% CISS) which is unsurprising given the small absolute values due to the dark room, while the trends are similar. The Bosch CISS doesn’t have much resolution at such low levels of light.

    The sensors also provide indicative results which the Bosch CISS does not. The noise levels reported by both sensors showed similar trends, but with an offset of about 5dB between the two versions. The CO2-eq and VOC sensor within the Bluetooth version show very big spikes in the data as metal-oxide sensors have cross-sensitivity with organics and other materials. Opening a bottle of isopropyl alcohol causes the sensor to read elevated levels of VOC and impossibly high levels of CO2eq, but this is common downside to all such sensors. Discomfort index, heatstroke risk and UV index are available from the Bluetooth version in the BLE broadcast, while the USB version only provides this data on the “full data” query or via USB. The first two indices are calculated based on the measurements, while the UV index is expected to be negligible due to being indoors. On the whole, ignoring the spikes, the readings looked reasonable.


    Why the Spikes?

    I verified that problems in the data were present within the log files for both sensors and this ruled-out the possibility the errors were introduced during data processing.

    As both sensors were logged based on their Bluetooth advertisement packet data, I wanted to find out what the data looks like once out-of-expected-range values were removed. It became clear that there is a pattern:

    From this, it was determined that the data spikes were likely not due to a fault in the sensor hardware itself, but due to a subtle and insidious error in the sample code for the Bluetooth advertising packet receiver. The offending code in question looks like this:

    temperature = str(int(hex(packet[24])+format(packet[23],'x'), 16)/100)


    The code itself uses a number of format conversions to concatenate two bytes of results into a single value, converting this into a number, dividing this by 100 then converting it into a string. The problem arises when a nibble in the middle contains all zero values – for example in our observations:

    • 0000 1001 0001 0000 = 2320 = 23.2°C is represented correctly
    • 0000 1001 0000 1111 = 2319 = 23.19°C fails – the zero-nibble is lost!
    • 0000 0000 1001 1111 = 159 = 1.59°C is what is reported instead.


    Interestingly, the code for the BU version of the unit seems to avoid this problem and passes a format string to the format() function that zero-pads the result to ensure correct conversion:

    temperature = str(int(hex(data[9]) + '{:02x}'.format(data[8], 'x'), 16) / 100)


    Due to this problem, I repeated the experiment again to obtain better data. I did attempt to contact Omron via their web form regarding this observation, but did not receive a response. I am not sure if this is because their web form submission process is problematic or due to the enquiry being lost somewhere in the system.


    Indoor Comparison – Omron 2JCIE-BL01-P1 vs. Omron 2JCIE-BU01 vs. Bosch CISS (Round 2)

    To improve the chances of success and to test the USB functionality of the 2JCIE-BU01, the experiment was repeated but instead using USB logging instead for the 2JCIE-BU01.

    The modified version of the code retains the green LED indication when connected.

    Unfortunately, it seems that the fix may not have completely fixed the spiking. I’m not sure if this is because of an uncaught bug within the code or whether there are corrupted BLE advertisement packets occasionally being received due to local interference. I suspect reimplementing the code with less byte-by-byte massaging might avoid bugs. On the upside, having the fix reduced the spiking frequency dramatically, making it possible to mostly filter out the spikes using simple thresholding for comparison.


    This time, it seems the USB device reported temperature 1°C higher than, and the BLE version reported a temperature 1°C lower than the Bosch CISS. The trends are very close, but the USB version is a bit noisier. The Omron sensors feature an installation-offset feature which allows such errors to be compensated.

    Post-filtering the BLE version data, the relative humidity data shows the USB and Bosch CISS concur, but the BLE version seems to report about 10% higher.

    As previously demonstrated, the barometric pressure data is practically perfectly identical.

    The ambient light data is slightly closer, but now the USB version seems to have a “floor” to the signal. This seems to be because the internal indicator LED is influencing the light sensor at such low values. I would recommend disabling the indicator LED if accurate light measurements are required. Again, the resolution of the Bosch CISS at the low end is poor by comparison.

    Calculated discomfort indices are slightly higher on the USB version compared to the BLE version, possibly due to differences in both humidity and temperature. Heatstroke risk levels were similar. This data could be compared this time as the USB interface allows for recording this data unlike the BLE advertisement mode on the USB device.

    As expected, the CO2-eq values were very much influenced by presence of VOC content, with some correlation between the two measurements. The noise trends were similar, although the BLE version measured lower values and appears to have a “floor” around 31dB. Somehow, I suspect the noise levels recorded were perhaps a bit higher than I’d expect – this is in my bedroom where loud noises are not common, so perhaps some filtering or averaging is necessary to obtain useful information.


    Outdoor Comparison - Omron 2JCIE-BL01-P1 vs. Omron 2JCIE-BU01 vs. Bosch CISS

    As the Bluetooth-version has the ability to report UV index and the lighting indoors is relatively poor, I decided to do some testing outside to provide those sensors an opportunity to prove themselves and a chance to test the sensors across a wider range of values. I used the same Raspberry Pi 3B+, but instead, powered it from a Xiaomi 16000mAh power bank both underneath the up-turned shipping box.

    Temperature values between the USB and Bosch CISS were similar, but the BLE-version appears to have been more affected, possibly due to a lack of enclosure. Due to the influence of direct radiative heating from the sunlight, temperatures exceeding 55°C were reported from the BLE unit.


    The relative humidity value varied significantly throughout the day, with the CISS reporting lower values most of the time and the BLE version reporting about 12% higher. The USB version fell between these values most of the time, with occasions where it dipped below the CISS. This may be due to a difference in response time between sensors – the CISS has a protection membrane which may reduce its ability to respond to rapid changes.

    Similar to previous tests, the barometric pressure values were almost perfectly coinciding, although towards the end of the day, the CISS was reporting slightly lower than the other two, perhaps due to the influence of the ambient temperature.


    Testing of the ambient light sensing showed that while the CISS had low resolution at low values of light, it had a much greater range making it more capable of reporting the value of direct sunlight. By contrast, the BLE-version saturated and remained mostly saturated throughout the day. The USB version saturated at a higher value, but then appeared to roll over back to zero once exceeding a fixed value, implying some problem with the data processing routine.

    Calculated values of discomfort index and heatstroke risk were similar in profile, but with the BLE version reading higher values mainly due to the differences in temperature readings.

    The measured carbon dioxide and volatile organic compound data seems to be slightly unreliable based on it being outside in open air, where I would expect readings mostly around 400-800ppm. However, this may be excusable as Sydney is currently suffering through a bushfire crisis and perhaps smoke particles have interfered with the correct operation of the sensor.


    Similarly to the other test, the noise values recorded from the USB version were higher, but both show suspiciously high levels of spiking, thus some averaging may be necessary to get useful data.

    While the BLE-version’s light sensor appeared to saturate, the UV index data appears to look reasonable and follows the intensity as reported by the Bosch CISS.


    Power Consumption

    Testing both units on my Rohde & Schwarz NGM202 power supply, I found that the power consumption under the condition of BLE advertising broadcasts at one second intervals on default output power was as follows:

    • 2JCIE-BL01-P1 at 3V – Average Current: 0.84mA, Peak Current: 11.33mA.
    • 2JCIE-BU01 at 5V – Average Current: 19.02mA, Peak Current: 64.17mA.

    The power consumption of the BLE version is kept relatively low on average as the unit seems to have about 4.85µA of drain when it is sleeping, although the peak current is quite sizeable and perhaps pushing what a CR2032 coin cell would be able to supply. Based on the current consumption, a CR2032 cell may last just 15 days under this load, which suggests that using much longer measurement intervals would be advisable.

    The power consumption of the USB version seems to be quite a bit higher, but this is probably not a great problem as it would be likely used with a nearly “limitless” supply of power. Part of the reason for this consumption may be the quiescent current taken by the FTDI USB interface, which would be different when a USB connection is established, or when the internal LED is used, as testing was performed with power supplied but no USB connection active and the LED is in the default off state. The current profile was very spiky, which suggests to me that there may be an on-board switching converter in use.


    Omron 2JCIE-BU01 Data Logging Mode

    One of the feature benefits of the Omron 2JCIE-series is the capability to perform on-device data logging, which frees up the need for a host to remain connected to the device to retrieve results continuously. Instead, at a configured interval, the device will take measurements from all the sensors and store it into the onboard Flash memory where it can be later retrieved to determine the trend over time. Given a reasonable logging interval, the number of data points (26,624 for BLE version or 60,000 for USB version) can be quite sufficient.


    However, it did not seem that any of the demonstrations provided actually made use of this mode. The GitHub examples were only reading from BLE advertisements or polling for the latest data, while the mobile app seems to only use the data that is recorded while connected and does not rely on the Flash storage on device.


    As a result, in order to prove this functionality, I had to implement code based on the datasheet specifications. I decided to use the USB device for this as I have more experience implementing code for serial-based devices and began with the GitHub example specific for the USB version. In order to implement the desired functionality, it would be necessary to be able to construct and send commands, as well as receive and decode responses.


    Thankfully, the CRC-16 algorithm required for data integrity had already been implemented and most of the data decoding had already been done (albeit, sub-optimally). I ended up implementing the necessary logic to construct a full data frame from an address + command + data payload, to send this to the device and receive the response (reading exactly the number of bytes required as per the length field), to check the returned payload’s CRC-16 matches the computed value and to strip the headers and CRC to decode the data. The original implementation featured fixed delays in serial reading which was sub-optimal, with no CRC checking of the returned data and a byte-by-byte handling of the little-endian data which was difficult to maintain. I instead opted for the easier methods – the full code is part of the attached .zip file.


    To make the logging work, it is necessary to set the time on the device which causes logging to begin based on the configured (or default) logging interval. Unfortunately, as the device does not feature an RTC back-up battery, once the device loses power, the time is lost and reconfiguring the time is necessary to continue logging. Logging data is also lost if the device if changed between normal (environmental) and acceleration logging mode, where data clearing takes about two minutes.

    The above is an example of executing the test code I had written on a Windows machine with reading of the RAW data from the device’s Flash memory store.

    This is the result of swapping the output mode to invoke the decoder – this produces a CSV-formatted output which has the decoded values in the full form (i.e. including flags). As a result, it is clear that the data logging functionality works as specified in the datasheet. I suspect implementation for BLE would be fairly similar, except that all the data transactions would be made over a BLE connection instead and using different addresses for the BLE-version device.



    I’m sure readers would be curious to know what sensors are employed within the 2JCIE-BU01 and 2JCIE-BL01-P1 units, so I took some time to examine their PCBs closely.


    2JCIE-BU01 (USB version)

    The USB version is built around a bespoke white metallised plastic shell with the metal USB connector shell being an integrated part of the assembly and the PCB forming the contact fingers for the plug. This is perhaps not ideal in all cases, as the profile of the pins are flat due to the PCB which may not make optimal contact with some sockets especially in case of high vibration. There is a milky-translucent plastic insert which forms the diffuser for the inbuilt LED indicator and for the light sensor on the unit.

    The PCB is quite small in size, being barely larger than the USB connector itself.

    The top side of the PCB houses (what appears to be) a MEMS PDM microphone marked KV1 809 (which looks similar to the ST MP34DT01-M), a Sensirion SHT30 Temperature and Relative Humidity Sensor, an AMS CCS811B VOC and CO2-eq sensor, an unidentified 6-pin light sensor (NOA1305?) and an Omron 2SMPB-02E Digital Barometric Pressure Sensor.

    The underside hosts the FTDI FT234XD USB Bridge that provides the USB interface, a Winbond Q64JVXGIQ 64Mbit Flash (8Mbyte) and (what I suspect to be) an Omron accelerometer similar to the one on their D7s vibration and seismic sensor module. There is also a right-angle multi-coloured LED firing out of the rear for status indication.


    The unit is controlled and the Bluetooth interface is provided by the Taiyo Yuden EYSHJNZWZ Bluetooth Module mounted in the top-right corner. This is based on the Nordic Semiconductor nRF52832 SoC with an ARM Cortex M4F CPU, 512kB of Flash and 64kB of RAM. A very compact solution indeed.


    2JCIE-BL01-P1 (Bluetooth Version)

    From what I can tell, this version in its bare PCB form is probably the same PCB as used within the “bag type” environmental sensor, just without its external enclosure. Because the PCB is bare, no disassembly is required to see the sensors involved.

    Looking closely at the PCB, the chip covered by the QR code label appears to be a Flash chip where the memory function records sensor values to. Below that, U2 is a Sensirion SHT20 Humidity and Temperature Sensor IC. To the right, U4 in the glass package appears to be a Silicon Labs Si1145/46/47 Proximity/UV/Ambient light sensor IC. Underneath is U8 which appears to be a MEMS microphone from STMicroelectronics, possibly the MP23AB02B.

    In the top corner of the board, there is an Omron 2SMPB-02A Digital Barometric Pressure Sensor marked as U3. Below that is an IC marked with a data matrix code and what appears to be Japanese characters – I suspect this is an Omron accelerometer, similar to that featured on their D7S vibration and seismic sensors. Aside from that, the unit is run by the Bluetooth module from Taiyo Yuden, specifically the EYSGCNZXX which is based around a Nordic Semiconductor nRF51822 SoC with ARM Cortex-M0 CPU with 256kB Flash and 16kB RAM. The design of this unit is perhaps not as small as it could be, compared to the USB-version, but part of the reason is that the Bluetooth version uses slightly different sensors and a larger Bluetooth module.



    The market of turnkey environmental sensors for integration into larger monitoring projects which do not require added engineering effort to design bespoke solutions is relatively limited at this time. The Omron 2JCIE-series of Bluetooth or USB-connected environmental sensors provides a compelling suite of sensors at a reasonable price. Utilising familiar low-power MEMS sensors from various suppliers, devices in the series can sense temperature, relative humidity, barometric pressure, ambient light, noise with some units capable of seismic, acceleration, CO2-eq, VOC and UV Index. The units are also capable of internal data logging into integrated Flash memory, calculated variables such as discomfort index/heatstroke risk and condition flags including basic thresholds, rates of change and moving averages. For additional flexibility, the unit supports BLE-advertisement based broadcasting of measurements, to allow a one-to-many connection in addition to GATT-profile one-to-one connections.


    For the most part, both USB and Bluetooth Low-Energy versions of the 2JCIE performed similarly on the common measurements, compared to the Bosch CISS solution (a much more expensive solution designed for industrial condition monitoring), with minor offsets in temperature and greater offsets in relative humidity being recorded. Some metrics (e.g. noise) for indication only did demonstrate differences between the units and spiky values which suggest some averaging may be necessary. Sensing of CO2eq and VOC showed some cross-sensitivity which limits its reliability in areas where chemicals or gases may be used, while light sensing seemed to saturate at outdoor sunlight levels suggesting indoor use is most appropriate. Documentation was sufficiently comprehensive to allow for relatively easy integration and use of more advanced features.


    On the downside, it appears that there is no way to disable the BLE interface on the USB-version which may limit appeal where radio usage may not be permitted. Furthermore, the BLE interface is limited in its integration flexibility as many of the identification values are hard-coded and no security exists against users connecting to the device and changing its configuration. The PCB-version is supplied with battery terminals which are also not particularly useful without an enclosure around the unit to hold the battery in place. Data issues with the light sensor saturation on the USB version cause roll-over of values. Finally, set-up of the sample programs for BLE were complicated by difficulties in dependency installation and sample code was relatively limited in its scope as it did not demonstrate many of the capabilities of the device and contained errors which caused incorrect data values to be returned.


    Despite this, the 2JCIE-series of sensors is still quite suitable for developers wishing to integrate environmental sensing into their projects owing to the strength of the documentation, onboard functionalities within the sensors and ease of integration which requires no hardware design or manufacturing expertise.


    Thanks again to element14 and Omron for selecting me as a RoadTester and providing both the 2JCIE-BU01 and 2JCIE-BL01-P1 for this RoadTest review.


Also Enrolling

Enrollment Closes: Oct 5 
Enrollment Closes: Oct 9 
Enrollment Closes: Oct 5