Rohm SensorShield-EVK-003 (Arduino Compatible) - Review

Table of contents

RoadTest: Rohm SensorShield-EVK-003 (Arduino Compatible)

Author: Jan Cumps

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: For the sensors, I reviewed competitor's offerings. The SensorShiels evaluation system is unique to ROHM. I have reviewed other manufacturer's evaluation shields but have not seen an ecosystem like ROHM's.

What were the biggest problems encountered?: Readable schematic and explanation of the jumper functions not available. Some sensors are easier evaluated without the SensorShield.

Detailed Review:

I'm Road Testing the Rohm SensorShield-EVK-003 (Arduino Compatible) and the sensors that come with it.

This is the review, focusing on the SensorShield ecosystem.

 

What's the ROHM SensorShield Ecosystem?

 

ROHM have made a set of tools to help you evaluate their sensors.

The system has these components:

  • SensorShield: Arduino compatible test bed to evaluate sensors
  • Firmware: for each of the sensors supported by this shield, ROHM developed an Arduino library and an example sketch
  • A set of standard sensors: 8 sensors from the ROHM range come with this evaluation kit.
    They come as little evaluation plug-on boards, all in the same form factor.
  • Optional sensors: the shield also supports other sensors from the ROHM gamma

 

 

The kit is specifically targeted to engineers that want to check if a sensor can be used for their application. It's not a demo system for sensors.

I reviewed and scored it that way: "Does the SensorShield make my evaluation job as designer easier?".

My experience with the sensors themselves I've documented in separate blog posts. You can find the links at the end of my review.

 

The SensorShield Hardware

 

The board is an Arduino shield. It has docking positions for three types of sensors:

  • analog: 2 positions, each with 2 analog pins, linked to Arduino A0 - A3.
  • GPIO: 1 position, linked to D0 (more on that below the schematic) and D1
  • i2c: 5 places. Each with a digital pin, connected respectively to D0 - D4.

 

The board has a logic level switcher that can be configured and a selectable supply voltage for the sensors (1.8, 3 and 5 V).

You can route the digital pins of both the i2c and GPIO blocks to an Arduino interrupt capable pin via jumpers.

I've gone in some more detail in this blog post: ROHM SensorShield V3: Map PINS to Arduino

 

source: ROHM website

 

In general, the design choices made by ROHM are decent. There's enough options and flex.

The only one that's a bit unfortunate is the use of D0 and D1. In particular D0 is better avoided when dealing with sensors.

These two pins are not only connected to the ATMega controller, but also, via 1K resistors, to the serial communication (USB controller).

 

 

source: arduino.cc

 

That can cause that you can't program an Arduino UNO with a sensor board plugged in (see the HAL sensor).

It also interferes with some tests. For that same HAL sensor, my measurements were out of spec because the output pin voltage is influenced by the Arduino USB part.

That's a case where the evaluation kit made the sensor appear non-compliant and testing it without the kit was easier.

For all other sensors, the kit proved to be of excellent value and I had a working test bed in minutes.

 

I would have preferred a different PCB colour . Black is very beautiful but makes it difficult to follow traces.

 

Firmware Libraries and Examples

 

For each sensor, there's an Arduino library available.

You can download that as a ZIP file. It's in the right format for the Arduino IDE and can be imported via the "Add .ZIP library..." menu.

The libraries are of decent quality. I've reviewed the source code and that's well written. Have a look at them if you want to expand your Arduino knowledge.

Each of these libraries also comes with an example sketch, automatically added to the IDE's Example menu when you import the ZIP.

These examples are good. They are useful for the firmware developer to learn how to get the sensors up and running.

For i2c sensors, that require configuration before they give their data, that is a big help.

One of the examples requires an additional library to be installed in the IDE: FlexiTimer2 (thank you for finding that out).

It's worth checking the internet for other people's examples. In particular for the Colour sensor, I found examples that tested advanced features of the sensors.

I've documented that in the separate sensor blog posts.

Overall, I'm very satisfied with these examples. That's where this offer stands out. The software is not an afterthought - it's a core part of the ecosystem and a joy to use and review.

 

They can be used without the SensorShield and you can also use them as starting point when writing firmware for a non-Arduino.

The license is liberal.

 

Documentation

 

The documents for each of the sensors and for the shields are instructions on how to get the test running.

They explain where to plug the evaluation board and how to set all jumpers.

The docs also explain how to load the firmware and what to expect when the test is executed - mostly output on the IDE's serial monitor.

They do not go beyond that. Don't expect to find theoretical or practical info on the design under test in the PDFs.

 

The documentation of the SensorShield itself follows the same principle. It explains the very basics of the board.

I would have liked that they elaborated more on the use of the different jumpers.

There's a system behind the interrupt jumpers that's poorly explained. It required an evening with multimeter, pen and paper to grasp how it's working.

A schematic inside that document would also be helpful. In particular because a readable schematic is hard to locate on the ROHM website.

 

source: ROHM datasheet

 

The datasheet of each sensor is sufficient to work with. ROHM is sparse with info in some of these documents.

Sometimes I had to peek over the wall into competitor's datasheets to better understand how the type of sensor operates.

 

The Sensors

 

I've written a separate article for each sensor. Please check the table below for a link to each of these reviews.

The kit ships with a good variety of sensors - a nice introduction in ROHMs offerings.

Each sensor is mounted on a little evaluation board, all of them the same size.

(again black - and with i2c sensors that makes it difficult to spot the location of the trace you have to cut if you want to change the address).

 

source: ROHM leaflet

 

All sensors behaved good (read my comments above on how the HAL sensor behaves good if not used with the SensorShield).

Just like with , (we had a secret background discussion on that , to make sure we were not misinterpreting the measurements),

the temperature sensor was on the upper side of the range. All others were well within the typical area of the specifications.

 

Here are the detailed experiments with the standard sensors that arrive with the kit:

 

Related blog
ROHM Temperature Sensor BD1020HFV
ROHM Magnetometer Sensor BM1422AGMV
ROHM Hall Sensor BD7411G
ROHM Colour Sensor BH1749NUC
ROHM Colour Sensor BH1749NUC - part 2: Other Firmware Libraries
ROHM Ambient Light and Proximity Sensor RPR-0521RS
new: BM1383AGLV  with the MAXIM  MAX32660: Low Power Sensor design - Barometer Hardware
new: BH1790GCL Medical Heart Rate Sensor

 

Overall

 

The SensorShield package is a good approach to give engineers hands-on experience with the sensors.

I hope that ROHM keeps on designing compatible evaluation boards for other sensors in their portfolio.

The road view was interesting and a learning moment (thank you , and with the GEO sensor calibration).

A big thanks to ROHM and element14.

Anonymous
Parents
  • Use of D0 and D1 are unfortunate for those using older Atmega328/168 based Uno/Duemilanove/etc boards. Better choices could have been made (possibly) or a switch integrated into the design.

     

    However, newer 32U4 boards (e.g. Leonardo) are not likely to have such issues as the USB COM Serial port runs on the chip as part of the bootloader, with D0 and D1 relegated to Serial1. On those boards, as long as you don't call Serial1.begin(), then D0 and D1 should work as well as any other GPIO.

     

    - Gough

  • True, though the leaflet talks about Arduino UNO. So my take is that this was not considered.

Comment Children
No Data