reference model - Modem Subsystem managing the Modem Hybrid

[neilh10]

This is a model of Modem Management Subsystem - reference discussion,
The Modem Management Subsystem (MMS) refers to all aspects of managing the Modem Hybrid (interfaces ports) and power switches.
The Modem Functions (eg Class GsmControl) control is a "friend" or part of of a MMS
The MMS may be used by numerous entities publishing data or retrieving data (OTA)

The various Modem Hybrid(s) are a "communications Subsystem" and effectively implement the "Data Link" Layer 2 and "Physical Layer as defined in the OSI 7 Layer.
One description is here
https://www.networkworld.com/article/3239677/the-osi-model-explained-how-to-understand-and-remember-the-7-layer-network-model.html

The Modem Hybrid functions need to be sequenced to work reliably, and I would think its a core function for future connectivity in whatever way that happens.

The different Modem Hybrids are typically complex systems, and may be difficult to test for all stimuli.
The Modem Functions may experience "equipment" faults and "line" faults - two different types of problems. Equipment faults require the physical device to be replaced, or sometimes if not seated properly to be reseated.
Line "faults" may be intermittent or may, as invalid access parameters never work.

For a Modem Hybrid function, From power-up to power-down the states are
1a) Powering
1b) A subset may be "release reset"
1c) - verify/set registers and verify basic Modem Hybrid operation (eg via AT response)

2. Brought out of sleep (1st cold power up transitions this state) and verify operational. If not valid repower(step 7 then 1)
3. Verify creates/instantiates local wireless link - may have the widest range of problems as wireless as its limit or range is very lossey.
   4a) Use active data link in some form. i.e. create TCP links & post,
   4b) Management meta data in some form - such as RSSI or local services
4. Shutdown all services (possibly optional)
5. Put to sleep to reduce power. For LTE-M there may be specific requirements to speed wakeup.

< and repeat to 2) as needed>
7) Powered down - possibly autonomously, or reset, possibly next step 1a or 1b.

For any commissioning action (the hugely important installation) the success of steps 1c and 3 should be visible in some form. #3
(offered in EnviroDIY#290)

A good design practices for a "Logger" is to not turn on the power guzzling electrically noisy RF modem until the potentially sensitive sensing has been digitized.

As of 0.23.11 the Modem is based on the sensor, and the modem shouldn't turn on when the reading is done
class DigiXBeeWifi : public DigiXBee : public loggerModem : public Sensor

The TinyGsmXbee manages the complexity of the Modem interface, (as of f 0.23.11) the modem phy management functions are distributed in other modules.

class TinyGsmXBee {
public: class GsmClient : public Client
{ friend class TinyGsmXBee; ..} }
class Client : public Stream {}
class Stream : public Print {}

For a logger system what really matters is successful transfer of the data
#1
for reasonably flexible communications
#6

for a reasonable power budget
and perceived reliable system behaviour even with complete battery power loss and power recharge with a high impedance solar panel
#4

HAL Discussion EnviroDIY#244
Ref starting discussion EnviroDIY#298

[neilh10]

Part of the potential is to manage the modem separately from MS and enable it to be used for other functions such as OTA, or if combined BTLE. An API interface could be
https://github.com/paulo-raca/ArduinoBufferedStreams