RoadTest: Wurth Sensor FeatherWing Kit
Author: dougw
Creation date:
Evaluation Type: Evaluation Boards
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?: STEVAL-MKSBOX1V1 (SensorTile box)
What were the biggest problems encountered?: I was unfamiliar wit VS Code and PlatformIO which required a learning exercise before I could start writing application software.
Detailed Review:
Introduction
This is a road test of the Würth Elektronik eiSos Sensor FeatherWing.
This road test challenged road testers to build a project using the Würth Elektronik Sensor FeatherWing kit, so that is the main objective of this road test.
I applied to road test this product because it includes a great suite of high performance sensors and in particular I am interested in the pressure sensor. The fact that the sensors are already integrated into a standard form factor circuit card allows me to focus on using the pressure sensor as an altimeter.
Although the circuit board includes eight sensors, I will be using it to measure an ninth parameter - altitude.
And I will also be using it to measure tenth-twelfth parameters - tilt angles - in 3 axes.
I hope that building the test product into a useful system will add an interesting twist to the road test.
This Würth Elektronik sensor card includes the following eight basic I2C sensors integrated onto a Featherwing circuit board:
3 axis accelerometer, 14 bit resolution, 4 ranges up to 16 g
humidity sensor, 16 bit resolution, 20% to 80% rH, averages 32 samples
temperature sensor1 (in the humidity sensor), 16 bit resolution, -40 to 120 deg C, 0.5 deg accuracy, averages 16 samples
temperature sensor2, 16 bit resolution, -40 to 125 deg C, 0.25 deg accuracy
temperature sensor3 (in the pressure sensor), 16 bit resolution, -40 to 85 C, 1.5 deg accuracy
pressure sensor, 24 bit resolution, 26 to 126 kPa, 2.5 Pa relative accuracy
These sensors all have excellent performance specifications. I have some instrumentation to measure these parameters, and I will compare my test instruments to these sensors, but my instruments are not as accurate as these sensors so it will be more of a confirmation than a proof of accuracy.
Test Preparation
Before starting the tests, I wanted to build the sensor card into a complete microcontroller system with a display so I can read the sensors without being tethered to a computer.
The Electronic System Build
Since the sensors are built into a FeatherWing card, this build also showcases how easy it is to turn the sensor kit into a complete measurement system.
To turn the electronic modules into a complete electronic system, I procured a FeaterWing TFT display module. This simply stacks on top of the Wurth Sensor FeatherWing, which in turn stacks on top of the Feather M0 MCU. I did a map of what each pin is used for in all modules to ensure there were no conflicts. There was a slight conflict between the display and the sensor card, but only if SPI was used to access the sensors. I am using I2C so the conflict can be avoided and Wurth provides a removable jumper to make this easy.
I played around with different color schemes because it seems a waste to use a full color display to just show black and white, but I opted for black and white to provide best possible contrast when taking outdoor readings.
Here is a video showing how all the parts went together to create a complete system:
The forum indicates I cannot upload a file larger than 96 MB so I had to delete this video....
I had no problems uploading the same video to another blog - here:
Pinout Map
Pin |
# |
I/O |
Function |
TFT |
Wurth Sensor |
Switch |
1 |
40 |
RST/ |
RST |
Not connected |
||
2 |
3V2 |
3V3 |
3V3 |
3.3V power supply |
||
3 |
4 |
PA02 |
AREF |
Not connected |
||
4 |
GND |
GND |
GND |
Ground |
||
5 |
3 |
PA02 |
A0 |
SD CS |
Not connected |
|
6 |
7 |
PB08 |
A1 |
RT CS |
Not connected |
|
7 |
8 |
PB09 |
A2 |
Not connected |
||
8 |
9 |
PB04 |
A3 |
Not connected |
||
9 |
10 |
PB05 |
A4 |
CS |
Not connected |
|
10 |
47 |
PB02 |
A5 |
D/C |
SPI_CE (JP1) |
|
11 |
20 |
PB11 |
SCK |
SCK |
SPI clock |
|
12 |
19 |
PB10 |
MOSI |
MOSI |
SPI MOSI |
|
13 |
21 |
PA12 |
MISO |
MISO |
SPI MISO |
|
14 |
16 |
PA11 |
U0RX |
Not connected |
||
15 |
15 |
PA10 |
U0TX |
Not connected |
||
16 |
GND |
GND |
Not connected |
|||
17 |
31 |
PA22 |
SDA |
I2C SDA |
||
18 |
32 |
PA23 |
SCL |
I2C SCL |
||
19 |
24 |
PA15 |
5 |
SD CS |
Not connected |
|
20 |
29 |
PA20 |
6 |
RT CS |
Not connected |
|
21 |
12 |
PA07 |
9 |
TFT CS |
Not connected |
|
22 |
27 |
PA18 |
U1TX |
TFT DC |
Not connected |
|
23 |
25 |
PA16 |
U1RX |
Not connected |
||
24 |
28 |
PA19 |
12 |
Not connected |
||
25 |
26 |
PA17 |
13 |
Not connected |
||
26 |
VBUS 5V |
VBUS 5V |
Not connected |
|||
27 |
3.3V EN |
'- |
Not connected |
|||
28 |
VBAT |
Not connected |
I had to make sure to solder the headers on the correct side of the MCU, but once that was done, stacking the modules was trivial. I could have trimmed the pins to reduce height a bit, but I don't have a guillotine cutter that could make a neat job of it, so I left them at stock length.
The Feather M0 can conveniently accommodate a Li-Po battery, but the battery I had needed a power switch and a JST 2mm connector. The white JST connectors I have needed the keyway shaved down ever so slightly to fit. I am surprised both that I have an appropriate JST connector and that it didn't quite fit to start with.
A slide switch was chosen for the power switch because it needs to be recessed. The exterior surfaces need to be flat so that angles can be measured.
The switch needs to be turned on to charge via the USB port, but when turned off the battery will last for years without self discharging.
The Mechanical System Build
The system requires a 3D printed case to be designed and printed.
The power switch was placed right under the USB port, to minimize the number of holes in the case.
The battery pocket holds the battery snugly and it cannot come out once the lid is on.
The display card slides into a snug slot holding the whole stack of modules in place. There is a brace under the stack to prevent the stack coming apart.
There is a cavity to hose the switch under the USB connector. A little tape ensures no possibility of a short, even though the switch body touching the USB connector would not constitute a short.
The case was kept very rectangular with no protrusions so the angles it is measuring can be directly referenced to the flat surfaces.
Software
The system requires some firmware development before it can really be used or tested.
Wurth provides example firmware intended to be developed using Microsoft Visual Studio Code with a PlatformIO extension. VS Code is a very flexible code editor that can handle many languages and extensions like PlatformIO turn it into a full IDE for microcontroller development. It provides a more comprehensive development environment than something like the arduino IDE, but necessarily is a a lot more complex. This was my first exposure to VS Code and it definitely proved my agility with new IDEs and code editors is far from stellar. Even adding the PlatformIO extension took me a long time because the instructions I was reading indicated I should use a package manager, which I couldn't find.
I don't use GitHUB much so getting the right code also took a lot longer than it should. At least I'm learning, although at a painfully slow pace.
Eventually I got everything set up, but no luck programming the device. It turned out to be a power-only USB cable. (those should be illegal)
When I finally got the example code running, I then had to figure out how to add in the display libraries. This promptly bricked the example code and I could not figure out how to undo what I did and get the code working again.
Eons later I started to understand how to add in libraries properly, but VS Code seemed to drag along a lot of baggage from mistakes I had made, and cleaning that out was just as painful as making the mistakes in the first place.
Once I got the 3 extra libraries working, I then had to figure out how to access the data that the Wurth demo was sending to the serial port. They had neatly packaged the sensors as objects, which I had to figure out. I'm sure it would have been obvious to a C++ programmer. One of these days I need to actually do some C++ programming.
Eventually I got everything working well enough to start writing the application software.
Application Software Functions :
Display Data
Altitude
A key initiative in this project was to see how well pressure could be resolved into altitude. I noticed it could resolve to less than a foot so I decided to try for inches. The program averages 100 pressure readings and astonishingly, it can measure the difference in pressure from the weight of 3 inches of air, sometimes even 1 inch is resolvable. Of course the pressure also registers changes in barometric pressure as altitude changes and temperature also affects the readings. Even motion of the sensor can cause dynamic pressure changes. To get the best reading, it takes a few seconds at a fixed height, to make sure all fluctuations have settled out. All these effects can be mitigated by simply zero-ing the altitude on power up, but I still need to program that feature. In the mean time I can manually correct for the barometric pressure by subtracting a baseline reading.
I am planning to test elevation and altitude on a nearby small hill using my laser rangefinder and the angle measurement of this sensor module to check if the elevation reading from pressure is reasonably accurate. To compute elevation from distance down the hill (which is the hypotenuse in this case) and the angle vertical distance is simply the hypotenuse times the sine of the angle. I started by determining if my rangefinder can measure the distance involved…. and it can't, at least not during the day. The sun obscures the reflected laser at distances beyond 21 feet. I tried it at night and it easily works beyond 80 feet, which should be good enough for this small hill. However it was raining so it will have to wait one more day. Update: We went for a walk to the small hill tonight. The altimeter indicated the hill was 277 inches high - just over 7 meters. This is about right, judging by the nearby houses. My laser didn't quite work bouncing off the grass, but I determined it can work over 90 feet - I just need to put something light colored at the bottom of the hill to bounce the laser off. It is kind of fun hauling out my altimeter to measure elevations as I walk around. Another update: I took a drive over to the river - there is a bigger hill going down to the river valley. The (Würth Elektronik) "altimeter" indicates the hill is 2,185 inches high (55.5 meters). I definitely notice that hill when riding my bicycle.
Sensor Tests
Accelerometers
The accuracy of the accelerometers was tested using 2 methods
One method was simply measuring 1 g in 3 axes. The accelerometers had a some offset in their data, for example they might read slightly higher than 1 g when vertical, but when flipped 180 degrees, they measured less than -1 g, even when trying to find the max reading. This type of offset is not just a residual tilt, but it can be calibrated out with a very simple procedure - find the max in each direction and shift the reading to make them symmetrical.
A second method used acceleration to measure tilt angles - the firmware actually converts acceleration to angle assuming the device is stationary. These measurements had the same offset as the 1 g experiment above. it is very sensitive to angle and can resolve a small fraction of a degree. It is so sensitive, that changing the angle in minimum increments is very difficult to do by hand.
The accelerometers are very good at measuring tilt angles, but they need to be calibrated to achieve maximum accuracy.
Temperature
There are 3 temperature sensors in this module. They all seem to read a bit high and they differ from each other by a degree or two. Again they have good resolution but for best accuracy they should be calibrated. They can easily be calibrated against a reference sensor, but care needs to be taken that the reference is at the same temperature as the sensor being calibrated. In my case the sensors are buried inside the case, so calibration would need to be performed before the case is assembled.
Humidity
I did not get a chance to test the accuracy of the humidity sensor, although it seems to be working very well. It reads about 24% in my house which is about right. If I breathe on it it shoots up which is what is expected, and takes a couple of minutes to purge back to ambient humidity.
Pressure
The barometric pressure is stably reading what is expected. I do not have a barometer, but the pressure changes about 10 Pa when I raise the sensor 1 meter. I dug the data to get maximum sensitivity when converting the pressure to altitude. The result was a very impressive sensitivity - I could easily detect changes in altitude of 3 inches. There was generally some noise of plus or minus 3 inches, but when left to settle properly, the reading would stay the same and only move one 3 inch quanta occasionally.
Altimeter Application
When doing a road test I like to not only test the product performance, I also like to use the product in a real application and this kit lends itself to complete one of my bucket list project ideas. That project is a self-contained altimeter that can tell me what floor I am on based on the change in barometric pressure. The pressure sensor in this kit has a relative accuracy of 2.5 pa, and since barometric pressure changes by about 12 pa per meter, I should be able to resolve which floor I am on. This turned out to be he case, actually it performed much better than expected.
Conclusions and Discussion
The Wurth FeatherWing Sensor module is a very easy device to hook up - it simply plugs into any Feather MCU. The supplied firmware reads all 8 sensors to demonstrate the entire module. If you know your way around Microsoft VS Code and PlatformIO you will have no trouble implementing a useful system. I like the form factor - the FeatherWing was a good choice to demonstrate these sensors and it makes the hardware extremely simple. The sensors themselves are small MEMS devices that can be used anywhere high performance sensors are needed. A couple of the sensors need calibration to achieve maximum accuracy, but that is common for all sensors.
The packaging I built for the module turns it into a useful little mobile system that can be used anywhere. I especially like the performance of the pressure sensor and its ability to provide altitude data. I am looking forward to finding more places to test it as an altimeter.
I have not done a real accuracy test yet since the sensors need a bit of calibration before doing a fair test of accuracy. However the sensors clearly have excellent resolution and the stability indicates calibration will improve their accuracy. Additionally, the firmware can filter any noise in the readings if even better accuracy is needed. I did this filtering/averaging with the barometric pressure and achieved awesome results.
There are a few things I would like to improve as time permits. One is a way to reset the baseline altitude, so I can set it to zero before any elevation test. Another one is adding a temperature compensation calculation to the altitude calculation - this is one reason the pressure sensor comes with a built-in temperature sensor. Another thing I want to do is calibrate the accelerometers and temperature sensors.
This road test has been an interesting learning experience and it is gratifying that the altimeter functionality is so sensitive. It was a good road test kit to challenge road testers to build a system.
I would like to thank Würth Elektronik and element14 for the opportunity to participate in testing this high performance sensor suite. I now have a nice little portable sensor system that can measure barometric pressure, tilt angles, elevation, temperature and humidity.
Relevant Links:
https://www.we-online.com/katalog/en/SENSOR_FEATHERWING
https://www.we-online.com/web/en/electronic_components/produkte_pb/service_pbs/wco/featherwings.php