search

openeew / openeew-sensor

Hardware for an OpenEEW sensor
https://openeew.com/docs/build-sensor
Apache License 2.0
43 stars 12 forks source link

Accelerometer data to Cloud - Continuous Send vs STA/LTA #60

Closed johnwalicki closed 3 years ago

johnwalicki commented 3 years ago

The v1.30 firmware runs silently in STA/LTA mode, just holding a 10 second FIFO queue. It also subscribes to a MQTT_TOPIC_SENDACCEL topic iot-2/cmd/sendacceldata/fmt/json which, if published from the Cloud/Dashboard, sends a json object to the sensor:

{"LiveDataDuration":<integer>}

The device parses this MQTT message: numSecsOfAccelReadings = cmdData["LiveDataDuration"].as<int32_t>(); The device then starts counting down and sending live accelometer data to the cloud. The payload is n seconds of data

Some regional networks / scientists might want a continuous stream of accelerometer data. This obvious requires more bandwidth and will generate lots of MQTT data. Someone will have to pay but we can implement the feature.

To keep the code modifications easy, I suggest changing this to an unsigned integer 32 uint32_t That is 4294967295 seconds (which is 136 years or close to 50000 days). That's sufficiently large! There would be no other changes to the firmware required.

johnwalicki commented 3 years ago

@andygrillo Would that be sufficient?

johnwalicki commented 3 years ago

@vkuna Would that be sufficient?

vkuna commented 3 years ago

I don't have a strong opinion. If this is an easy solution and it would be easy to change the value remotely, I think it should work just fine.

johnwalicki commented 3 years ago

Here's how I imagine this working:

We might have to worry about timing? What happens to published messages before the device subscribes to the topic?

johnwalicki commented 3 years ago

Or... We could create another MQTT topic that "declares" the algorithm that the device should use. Today, the device firmware implements STA/LTA (local 10 second algorithm) or blindly sending all the accel readings. Maybe in the future the firmware will implement other seismic algorithms? We could future proof the firmware so that this potential MQTT topic could tell the device to switch between algorithms.

johnwalicki commented 3 years ago

At the implementation level for "continuous send mode" it just sets numSecsOfAccelReadings = 4294967295 seconds. We would then be able to extend the firmware with whatever else algorithm a seismologist invents.

vkuna commented 3 years ago

Yes if we can keep that option open it would be great. STA/LTA is a standard and reliable option, however, we want to try some ML detectors deployed on sensors in future. Plus there might be more changes to station functionality, like allowing station to issue 'on-site' warning etc.. All of these would need significant changes to the firmware and we should be able to upgrade all sensors remotely.

andygrillo commented 3 years ago

I like this 2nd option better because it means the algorithm change can be done at any time, not only when boot up. \

If I understand correctly, this would allow the change to be done on the fly via the dashboard.

On Sun, 7 Feb 2021 at 16:01, John Walicki notifications@github.com wrote:

Or... We could create another MQTT topic that "declares" the algorithm that the device should use. Today, the device firmware implements STA/LTA (local 10 second algorithm) or blindly sending all the accel readings. Maybe in the future the firmware will implement other seismic algorithms? We could future proof the firmware so that this potential MQTT topic could tell the device to switch between algorithms.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openeew/openeew-sensor/issues/60#issuecomment-774775753, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP5GHMECLQ5UCXYS34XR5LS54EUTANCNFSM4XH4JIGA .

-- Andres Meira m +52 (55) 12246468 skype andresmeira

johnwalicki commented 3 years ago

Without any changes to the firmware, I implemented the following UI change in the OpenEEW Device Mgmt interface: http://openeew-devicemgmt.mybluemix.net/ui/#!/1

Essentially, its sending the maximum int32_t which is 2147483647 seconds ( ~ 68 years )

andygrillo commented 3 years ago

looks great! [image: image.png]

On Mon, 8 Feb 2021 at 10:44, John Walicki notifications@github.com wrote:

Without any changes to the firmware, I implemented the following UI change in the OpenEEW Device Mgmt interface: http://openeew-devicemgmt.mybluemix.net/ui/#!/1

Essentially, its sending the maximum int32_t which is 2147483647 seconds ( ~ 68 years )

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openeew/openeew-sensor/issues/60#issuecomment-775280421, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP5GHPB4AS74H3CVKWSD7LS6AIIDANCNFSM4XH4JIGA .

-- Andres Meira m +52 (55) 12246468 skype andresmeira

johnwalicki commented 3 years ago

The idea to dynamically change the algorithm is interesting but potentially out of scope for this release. We currently only have one algorithm.

andygrillo commented 3 years ago

Sorry my bad description, I just meant change from continuous to triggered, which it seems you have achieved.

On Mon, 8 Feb 2021 at 10:48, John Walicki notifications@github.com wrote:

The idea to dynamically change the algorithm is interesting but potentially out of scope for this release. We currently only have one algorithm.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openeew/openeew-sensor/issues/60#issuecomment-775282916, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP5GHOK2U4ARXV45KE67P3S6AIV7ANCNFSM4XH4JIGA .

-- Andres Meira m +52 (55) 12246468 skype andresmeira

johnwalicki commented 3 years ago

Firmware v1.3.0 is released. This issue is closed via https://github.com/openeew/openeew-sensor/pull/61