Add: cell_nats service

[facastiblancor]

This PR adds the cell_nats service, a NATS exporter for received cell signal strength metrics as reported by ModemManager. Exposed metrics include: RSSI, RSRQ, RSRP, and SNR for LTE, and RSSI, ECIO and SNR for UMTS (a.k.a 3G).

Metrics are exported though the cell.* topic, where each metric is a subtopic.

Cell signal metrics are expected to be received as:

[#1] Received on "cell.rssi"
{'value': -74.0, 'time': '2021-11-09 19:19:03'}

[#2] Received on "cell.rsrp"
{'value': -97.0, 'time': '2021-11-09 19:19:03'}

[#3] Received on "cell.rsrq"
{'value': -10.0, 'time': '2021-11-09 19:19:03'}

[#4] Received on "cell.snr"
{'value': 10.2, 'time': '2021-11-09 19:19:03'}

[#5] Received on "cell.tech"
{'value': 'lte', 'time': '2021-11-09 19:19:03'}

TO DO:

• Test docker container in Toradex and Raspberry Pi test units
• Test container after several sleep/wake cycles.

[abalmos]

@facastiblancor I can do a proper code review next week.

In the meantime, a few quick questions.

Modem ID

Should we include some sort of modem identification in this message? We may have two or modems of various types over time.

Format

Are the metrics gathered at once / related to the same timestamp? If so, maybe something like

[#1] Received on "cell.status"

{"time": "2021-11-09 19:19:03", "rssi": -74.0, "rsrp": -97.0, "rsrq": -10.0, "snr": 10.2, "tech": "lte"}

could be easier to work with?

Some things worth discussion:

1. Subing to many topics and then re-indexing under the common time has been annoying in the past.
2. Data serialization / de-serialization overhead vs. costs of additional NATS messages. I'm not sure here, but I suspect 5 messages is more over head then de-serializing the joined JSON for just a few of the parameters. Also, using not JSON would also help.

Time / Avena standard structure

We should have standard structure across our messages. For another thread, but are we ready to pick a better format like protobuf, etc? Adding to a message schema is easy, but changing existing fields is breaking.

Time: String like "2021-11-09 19:19:03" or UNIX timestamp. A min, if a string we should include the timezone. I vote timestamp personally.

Only cell?

Using the paper's lingo. Is this a HAS or CAS? In other words, is this a generalize interface for radio strength or a MM/cell specific wrapper?

If we had a CBRS/TVWS/LoRaWAN/etc. radio would also want?

[#1] Received on "radio.status"
{'time': '2021-11-09 19:19:03', 'rssi': -74.0, 'rsrp': -97.0, 'rsrq': -10.0, 'snr': 10.2, tech: 'lte'}

[#2] Received on "radio.status"
{'time': '2021-11-09 19:19:03', 'rssi': -74.0, 'rsrp': -97.0, 'rsrq': -10.0, 'snr': 10.2, tech: 'lte'}

I ask, because maybe we do want a cell.* as you have hear then is combined with lorawan.*, cbrs.*, etc. to make a radio.* topic?

[facastiblancor]

@abalmos Sounds good. Just wanted to open up the discussion.

Should we include some sort of modem identification in this message?

Indeed we can include a modem ID. Though, ModemManager IDs are not consistent for each system, and are very likely to change after each sleep/wake cycle. I have seen cases where the modem ID keeps increasing daily during the season to numbers like 400.

Are the metrics gathered at once / related to the same timestamp?

Yes, they are gathered at once and can be related to the same timestamp, even though they are split into 5 different messages.

...could be easier to work with?

Indeed it is easier to work with a single status message, and I consider the deserialization overhead lower than that of creating 5x the amount of messages. However, the reason I chose to split into different topics was to be consistent with j1939d's and cand's, by splitting the main topic into subtopics for each metric.

Time / Avena standard structure

I vote for UNIX timestamp. It's better to leave all the time/date decoding to other services. However, the reason I chose the format presented on the initial commit was to ease testing. I plan to change this right before merging. Also, I don't think timezone info is necessary, as long as UTC is enforced for all services.

Is this a HAS or CAS?

CAS. Planned this as a MM wrapper to ease signal strength info collection. However, a model to standarize radio status logging would be great. Could be the opener for a future discussion.