Sensors design

[elsalahy]

Summary:

Sensors options and device design discussions and decisions.

[elsalahy]

@azerimaker can you please add relevant design documents and relevant design decisions here. We should also target asking specific questions here.

[elsalahy]

Design decision: LEDs can act as a light sensor

Should we consider using an LED as a light sensor?

Pros:

• Very cheap
• Simple to Add

Cons:

• Adds complexity to the enclosure
• Adds complexity to the SW

@azerimaker @wienke @johanstokking

What are your thoughts on this?

[johanstokking]

We need some quantitative aspects and a bit more information here; these pros and cons as stated above can be applied to virtually anything.

1. What is the cost?
2. What is the power consumption?
3. Do we support interrupts? (I think we didn't in the old design)
4. What are the resulting requirements for the enclosure in terms of material choice, weather sealing, cost, aesthetics, etc?
5. What is the added complexity to software? Do we need custom drivers?

[elsalahy]

• On the cost front the LED component cost is negligible in the cents, @azerimaker do you confirm and can you please help us realize more quantitative data?

Here is my thought on the other topics The cost is paid by the added overhead is in the SW/HW:

• on the HW we require an extra GPIO to have LED as a light sensor
• on the power, we need to do pulling to get the data, there is no interrupts support
• on the enclosure, we would need a punched transparent hole or LED mounted enclosure
• on the SW, we need timers and small driver, with OTA calibration

[azerimaker]

@elsalahy, @johanstokking if we use LEDs, then they have to be visible from outside. Since we are going to use an opaque enclosure there has to be some kind of transparent medium to conduct light through the enclosure. There are several ways to achieve this:

1. by adding a light pipe to the enclosure with custom machining and fitting
2. by using a through-hole LED with waterproof fitting (light-guide cap)

Using LED is a cost-effective way of measuring the relative ambient light, but the measured values will very greatly across different LEDs from the same batch.

[johanstokking]

1. by adding a light pipe to the enclosure with custom machining and fitting
2. by using a through-hole LED with waterproof fitting (light-guide cap)

This sounds all very costly.

Using LED is a cost-effective way of measuring the relative ambient light, but the measured values will very greatly across different LEDs from the same batch.

Calibration of what the meaning is of a certain value is probably necessary anyway, as light varies vastly from mount point to mount point. So this is not really an issue to me.

Next to using the LED as sensor, having LED for feedback, or any feedback at all, adds lots of value to the user experience. How does the device communicate physically that it's still powered, for example?

Do we ditch feedback to a human being holding the device? What are alternatives to LED? Do we have another solution, like sound?

---

I also wanted to raise the issue of adding a button to the equation. This would also, most likely, make the selection process for existing enclosures more challenging. However, to me, enclosure has the function of protecting the end device and look nice, but we shouldn't limit ourselves too much in the functionality because of the enclosure. So if we want to do light sensing, light feedback and a button, but we can't because of the enclosure, we didn't decide things in the right order, in my opinion.

The business case for the button is to program arbitrary actions to human input. The best example is the Amazon Dash Button, of which hundreds of thousands if not millions are sold. They are fully customizable by a sticker, and you can program in the cloud what should happen if somebody presses the button, like order condoms:

The thing here is that you don't need WiFi to transmit that somebody pressed a button; constrained LPWAN is perfect for that. And it's super long range. You can put these buttons everywhere in warehouses to replenish stock, etc.

[azerimaker]

@johanstokking one of the main thing that lags us behind is our lack of clear vision. Maybe instead of designing a generic-like node, we can design a generic module and customize the sensor mother board based on use cases. New issue to discuss this TheThingsIndustries/genericnode#188

[wienke]

Really like this idea. Let's research how the feedback can come from a speaker and the touch can be done without modifying the casing.

[wienke]

@azerimaker can you make another ticket for the piezo speaker?

[wienke]

For the button let's investigate a very simple static capacitive field solution.

[azerimaker]

We can certainly get away with a touch and piezo buzzer based user input, instead of physical button. Will create respective User Interface issue for our discussion.

[elsalahy]

On the discussion about using an Accelerometer or Accelerometer+ Gyroscope Combo. With some research, here are some pointers:

• It is clear we only need an accelerometer, see a good explanation here
• Most available Accelerometers provide orientation detection
• TWTG generic node ST Accelerometer LIS2DE12 had multiple features and worked great, see demo
• We need to compare the various Accelerometers available such as LIS2DW12 and LIS3DHH with LIS2DE12 to decide on the resolution and feature set needed based on the requirements.

@azerimaker, @wienke and @johanstokking please let me know your thoughts

[johanstokking]

Let's consider the use cases as in TheThingsIndustries/genericnode#189;

Use case	Accelerometer requirements
Room temperature with ~1 error margin	n/a
Cold chain for fridges	see below
Condensator monitoring of fridges	n/a
Retrofit mouse/rat traps	yes: interrupt, configurable scales, any direction
Condition monitoring of moving goods like temperature, direction of the box and fall detection	yes: interrupt, configurable scales, in any direction
Orientation of valves	yes: orientation, interrupt movement detection
Soap dispenser usages	not sure
Door usage	yes: orientation, interrupt movement detection
Window/Door open or closed	yes: orientation, interrupt movement detection
Usage of high value tools and equipment	not sure
Fire extinguisher usage	yes: interrupt movement detection
First aid kit usage	yes: interrupt movement detection
Step counter for factory worker	yes: interrupt movement detection (can we count interrupts?)
Fall detection	yes: free fall detection
NEW: Fall/shock detection of fridges	yes: interrupt movement detection with configurable scales (i.e. high g) and/or free fall detection
NEW: Water leakage	yes: high frequency, accurate vibration detection *

* maybe this gets us in the area of expensive industrial accelerometers, which may no be worth it for a single use case

[azerimaker]

On the discussion about using an Accelerometer or Accelerometer+ Gyroscope Combo. With some research, here are some pointers:

• It is clear we only need an accelerometer, see a good explanation here
• Most available Accelerometers provide orientation detection
• TWTG generic node ST Accelerometer LIS2DE12 had multiple features and worked great, see demo
• We need to compare the various Accelerometers available such as LIS2DW12 and LIS3DHH with LIS2DE12 to decide on the resolution and feature set needed based on the requirements.

@azerimaker, @wienke and @johanstokking please let me know your thoughts

Looking at various Accelerometer options (price, performance, output resolution, power consumption) it looks like LIS2DW12 can do the job.

[elsalahy]

@johanstokking yes, this is exactly what we need to validate the component selection Mapping Use cases to device functionality, and as you mentioned having more relevant use cases is vital.

@azerimaker, LIS2DW12 looks like a solid option indeed, let's consider it as the contender to beat and keep comparing it with the reference LIS2DE12 and any other options that we may find

[elsalahy]

Some analysis on the Accelerometer options:

• ST is the dominant Accelerometer maker in the market with a very large component selection portfolio.
• All drivers are open source and can be integrated easily within our device.

• After evaluating the prices and feature set and cross matching them with use cases, I think we should consider LIS2DH12 or LIS2DE12 instead of the LIS2DW12.

  The reason for me not recommending the LIS2DW12, is the price as it is almost 2X the other two alternatives (priced at 0.87$/1K) (with less features).

@azerimaker What are your thoughts on this?

[elsalahy]

On the external serial flash selection, here are my points after some analysis:

• We need to use SFDP or Dataflash compatible external serial flash
• The min external flash size must be 3X the internal flash size of the chosen SOC variant
• We need to consider QSPI as we have many unused IOs
• External flash security and durability are crucial factors, so NOR flash is the best option
• Adesto seem to have highly specialised IoT friendly external flash devices, with SRAM buffers and documented SW libraries (also they are ST partners).
• Other vendors such as Cypress Semiconductors, ON semiconductors, AMIC and Macronix provide good serial flash options that we might want to consider.

I think Microchip SST26 option is a good alternative incase we don't find any other alternative, but I feel it should be a last resort as we don't want a Microchip device around an ST SOC

@azerimaker did you research any options and if so, what are your thoughts on this?

@wienke we might want to explore partnering with a flash vendor like Adesto as this is a core Component and they might benefit from all the Marketing around the new device, any thoughts?

[johanstokking]

The reason for me not recommending the LIS2DW12, is the price as it is almost 2X the other two alternatives (priced at 0.87$/1K) (with less features).

Would be interested to hearing @azerimaker's thoughts on this too.

What does "wakeup" mean in this context? Is it configuring some interrupt threshold and allowing the device to wakeup that way, like "wake on shake"? That, and the orientation and free-fall seem very useful to me. I would argue that the accelerometer is the key sensor on this Generic Node as it's used in virtually all use cases per TheThingsIndustries/genericnode#189

---

Thanks for the detailed evaluation on flash.

as we don't want a Microchip device around an ST SOC

We don't? I'm not against it. We're pretty much free to choose any hardware; that's one thing we learned from TTKG and former GN.

[azerimaker]

@azerimaker What are your thoughts on this?

I'm also undecided between LIS2DE12 and LIS2DW12. It all comes down to price, versus output resolution and functionality. Bit more detailed comparison table is here. Personally, I'm a bit more inclined towards LIS2DW12 , mainly because of its lower power consumption and higher output resolution for increased sensitivity.

BTW, changing the sensor IC is not that hard, in fact most of the ST sensors are pin compatible, so we can just swap them during prototyping.

Sensor	Price @1K	Output resolution
LIS2DW12	0.90€	16-bit
LIS2DE12	0.55€	8-bit
LIS2DH12	0.62€	12-bit

[azerimaker]

What does "wakeup" mean in this context? Is it configuring some interrupt threshold and allowing the device to wakeup that way, like "wake on shake"? That, and the orientation and free-fall seem very useful to me. I would argue that the accelerometer is the key sensor on this Generic Node as it's used in virtually all use cases per TheThingsIndustries/genericnode#189

@johanstokking to answer your question. To my understanding, wake-up is an event functionality where the sensor wakes up if it senses any movement above threshold in any direction (can be specified) or when the sleep time is up. It can set a status flag or toggle INT pin to alert the MCU.

Free-fall detection, single/double tap recognition are all basic functionalities which seem to be implemented in most ST sensors.

[elsalahy]

@azerimaker What are your thoughts on this?

I'm also undecided between LIS2DE12 and LIS2DW12. It all comes down to price, versus output resolution and functionality. Bit more detailed comparison table is here. Personally, I'm a bit more inclined towards LIS2DW12 , mainly because of its lower power consumption and higher output resolution for increased sensitivity.

BTW, changing the sensor IC is not that hard, in fact most of the ST sensors are pin compatible, so we can just swap them during prototyping.

Sensor Price @1k Output resolution LIS2DW12 0.90€ 16-bit LIS2DE12 0.55€ 8-bit LIS2DH12 0.62€ 12-bit

@azerimaker It is clear that LIS2DH12 is more power efficient, with a load switch?

[azerimaker]

@elsalahy, the thing is, Accelerometer is the main sensor of the system and most events will be triggered by it. Even if we add a load switch, we won't be using it frequently for the Accelerometer and rely on its low power sleep modes to detect movement related events. The lower the current consumption, the better.

Power consumption figure on your chart for LIS2DW12 is misleading because that's for its High-performance mode (>1KHz sampling). In normal mode (100 Hz) LIS2DH12 consumes 11μA, but LIS2DW12 consumes 5μA only.

I've already documented power consumption figures in this chart.

I still think extra features, sensitivity and lower consumption outweighs the added cost of 30 cents for this part.

[elsalahy]

@azerimaker Let's get LIS2DW12 and evaluate it's power consumption and see if it is worth the 30+ cent price increase for the minimal difference in the uA level.

[azerimaker]

Part selection update!

After some careful investigation and cost analysis, me and @elsalahy have decided to use LIS2DH12 Accelerometer from ST, mainly because of its wide availability, lower price and decent performance figures.

[azerimaker]

SST26

@elsalahy, I've added some more Flash options. Please check it out. There are cheaper and lower-power options than SST26.

*update: I did check Adesto's line of Flash memories, their operating voltage is a bit higher (2.3V-3.6V) than we need and price is almost 3x higher than the other memories. Their advantage is that they provide EEPROM like byte-access, better suited for config saving and data logging.

[elsalahy]

Analysis on the on serial Flash selection:

• I'm ok with MX25R1635FZUIL0 as an all around good serial flash option

• While browsing the flash I noticed that the current proposals 1 and 2 are limiting components selection such as flash and secure element.

• Adesto flashes fall under two categories

  • One with SRAM buffers which is more expensive than typical serial flashes (for a good reason), see AT45DB081E-MHN-T and the operating voltage is between 1.7V - 3.6V
  • One without SRAM buffers which are cheaper than most of the current proposals for the twice the size see AT25SL321-UUE-T with operating voltages incompatible with current power supply design

The current power supply design enforces the selection of wide Vcc products which is something that we might want reconsider, @azerimaker what do you think?

I consider the priority of the components as follows (high to low):

1. Flash, Secure element (highest priority, core components for any LoRaWAN device)
2. MCU + Transceiver (SOC or SIP or individual components)
3. Sensors (Accelerometer, temperature)
4. Others (load switches, capacitors, ....)

Developing a design around the core components such as Flash and secure element will allow for the adoption of these practices in LoRaWAN devices and will allow us to integrate these components with other sensors/MCUs.

[azerimaker]

@elsalahy , our power supply range is dictated by the fact that we want to use single BOM to cover EU and US bands, while being able to transmit at 22dBm, otherwise I'm ok using 2V as a main system voltage without dynamic scaling.

[azerimaker]

• One without SRAM buffers which are cheaper than most of the current proposals for the twice the size see AT25SL321-UUE-T with operating voltages incompatible with current power supply design

btw, this Adesto part has 2x > the standby and ~200x > the shutdown consumption of the Macronix part.

[elsalahy]

• One without SRAM buffers which are cheaper than most of the current proposals for the twice the size see AT25SL321-UUE-T with operating voltages incompatible with current power supply design

btw, this Adesto part has 2x > the standby and ~200x > the shutdown consumption of the Macronix part.

You are using a load switch with flash? how is this relevant?

[elsalahy]

@elsalahy , our power supply range is dictated by the fact that we want to use single BOM to cover EU and US bands, while being able to transmit at 22dBm, otherwise I'm ok using 2V as a main system voltage without dynamic scaling.

I understand this, is there any solution to this? Off the top of my mind (if having one device for the EU and US is the highest priority): Maybe we can set the system voltage to 2.7V with no dynamic scaling which will get us +20 DBM and allow us to use use less expensive components?

[azerimaker]

@elsalahy , our power supply range is dictated by the fact that we want to use single BOM to cover EU and US bands, while being able to transmit at 22dBm, otherwise I'm ok using 2V as a main system voltage without dynamic scaling.

I understand this, is there any solution to this? Off the top of my mind (if having one device for the EU and US is the highest priority): Maybe we can set the system voltage to 2.7V with no dynamic scaling which will get us +20 DBM and allow us to use use less expensive components?

That was one of the solution actually. Using a buck-boost converter with a HW jumper switch, we could use 2.5V for EU and 3.3V for the US regions. The problem is, by constantly running the system at higher voltage will significantly reduce the battery life (~20% for for EU and ~40% for US compared to 2V)

[elsalahy]

@elsalahy , our power supply range is dictated by the fact that we want to use single BOM to cover EU and US bands, while being able to transmit at 22dBm, otherwise I'm ok using 2V as a main system voltage without dynamic scaling.

I understand this, is there any solution to this? Off the top of my mind (if having one device for the EU and US is the highest priority): Maybe we can set the system voltage to 2.7V with no dynamic scaling which will get us +20 DBM and allow us to use use less expensive components?

That was one of the solution actually. Using a buck-boost converter with a HW jumper switch, we could use 2.5V for EU and 3.3V for the US regions. The problem is, by constantly running the system at higher voltage will significantly reduce the battery life (~20% for for EU and ~40% for US compared to 2V)

I checked again, and it seems 2.7 will allow for +20 dpm which can be used for the US (this is the LoRaWAN requirements), and we might not need to scale to 3.3, this will save power consumption in the US and increase power consumption in the EU which might be a compromise we are willing to make to have better sensors compatibility.

[azerimaker]

@elsalahy , since we're in the prototype phase, we don't know for sure what will be the final operating voltage for our system. Therefore, I'm going to choose MX25R1635FZUIL0 (16 Mbit NOR flash) to begin with. This way we can have room play around with the voltages and keep the firmware simple for FUOTA.

[azerimaker]

as for the Temperature & Humidity sensor I went with SHTC3 from Sensirion, which offers good performance for fair price.

[azerimaker]

Magnetic Sensor @wienke pointed out the Sense Connect Detect (SCD) device from Bosch as an inspiration and it looks like they use similar set of sensors to us, with addition of Light and Magnetic field sensors. Now is a good time to discuss whether we should add an extra sensor or not?

Magnetic field sensors applications:

• Compass for orientation detection
• Contactless current sensing
• Linear and angular position
• Rotation sensing
• Non-contact switch for intruder detection

Pros:

• new use cases for industrial applications
• added marketing benefits

Cons:

• Added component cost (~0.8 EUR @1K)
• Added work of demo FW development

[elsalahy]

The magnetic sensor is only relevant to the orientation of valves use case mentioned in #3

And even with this sensor, the detection of valve orientation will be tricky as the valve needs to be made of a specific material to trigger the sensor.

I think we should only add it, if @wienke and @johanstokking have more relevant use cases in mind.

[elsalahy]

ST provided the info that they are building FUOTA support for a duel bank memory architecture. Consequences of this is partially relevant to Flash and MCU selection:

• You don't need external flash for FUOTA if you use ST FUOTA SW.
• Must be able to turn flash completely off from reference design stand point as some might opt for using our device with this approach.
• We can reduce cost on Flash memory size choice (smaller size is cheaper), if we opt to use the duel bank approach.
• We must choose WL SOC variant with the highest flash memory size (at least 256K) and even then, it might not be enough for the application as it will be limited to ~ less than 60K (of course in case we opt to use only duel bank without external flash)

From practicality standpoint, I don't see value in using a duel bank and I think using external flash is the way to go.

Nevertheless this would mean we will undertake the effort/risks of building HW and SW to support external flash FUOTA device (not ideal).

I will explore if we can modify their duel bank FW to function with external flash and provide more details on the subject if any.

[johanstokking]

Yeah ST is pushing pretty hard on dual bank. Another advantage is that you can rollback to the previous version at any time.

• We must choose WL SOC variant with the highest flash memory size (at least 256K) and even then, it might not be enough for the application as it will be limited to ~ less than 60K (of course in case we opt to use only duel bank without external flash)

Where does the other half (68 K) go?

[elsalahy]

LMN stack (class A) after optimised compilation, is taking around 66K, without any SE SW or FUOTA support. And this is the bare-metal approach, if you consider adding an OS, duel-bank then would be considered an even bigger problem as embedded OS + LW STACK can become quite big.

[elsalahy]

In this thread we made the following decisions: Integrated Accelerometer, Temperature and humidity sensor, secure element and external flash.

Here is a list of the integrated sensors:

• LIS2DH12 is the Accelerometer
• SHTC3 is the Temperature and Humidity sensor
• ATECC608A-TNGLORA is the secure element
• MX25R1635 is the external 16MB external SPI flash
• Piezo Buzzer