Considerations for LTE-M or NB-IoT devices?

[boaks]

A web-search about "earthquak" detection systems guided me to this project.

Using WLAN comes in some cases also with pain, e.g. installation.

Did you already consider to build also devices on NB-IoT or LTE-M modems? In the recent time, they get better and better. Maybe a first approach even doesn't require own hardware, there "Multi-sensor cellular IoT prototyping platform" available, which are already equipped with accelerator sensors and a modem. It's not that cheap as the sensor of this project, but it opens also some new possibilities.

One of those platforms is the Nordic Semiconductor - Thingy:91.

Together with a SIM-Card it starts about 150 Euro of invest.

If there is some interest, I would be happy to help. If started a general small demo project, see CoAP/DTSL 1.2 CID for Zephyr. Together with a Eclipse/Californium server, it demonstrates, how reliable and efficient UDP can be.

[andygrillo]

This is a great idea, and something we have discussed but never done. I agree that LTE-M would be an important addition to OpenEEW as it would allow placement of sensors in areas without the use of residential wifi or ethernet (which is often a challenge).

@boaks are you offering to help with the firmware ? do you have a Nordic Thingy and an ADXL355 (I suppose we could tet this with a cheaper ADXL345 also?)

A proof of concept with a CoAP server would be great. We would need to demonstrate that it could continously receive 31 samples for each of the 3 channels every second.

[boaks]

The Thingy:91 is equipped with two accelerometer, a ADXL372 and a ADXL362.

A proof of concept with a CoAP server would be great. We would need to demonstrate that it could continously receive 31 samples for each of the 3 channels every second.

CoAP will not be the limit there, but if you send about 31 msgs/s, your SIM card will get expensive and the battery will be a very large one. Such use-cases don't fit LTE-M (not NB-IoT).

Usually LTE-M is for devices, which reports "regularly every couple of hours" an "alive" and on an event an "alert". That requires, that the device accumulates the sensor values and pre-process them, reporting only the values either as "less frequent alive" or if the values are indicating an possible earthquake event.

are you offering to help with the firmware ?

Yes, but it depends on the primary approach. As written above, sending 32 msgs/s is in my opinion no mobile IoT use-case.

[febalci]

What about using LoRa network?

[boaks]

continously receive 31 samples for each of the 3 channels every second.

With LoRa?