reference model - Modem Subsystem managing the Modem Hybrid

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 5) Shutdown all services (possibly optional) 6) 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. https://github.com/neilh10/ModularSensors/issues/3 (offered in https://github.com/EnviroDIY/ModularSensors/pull/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 https://github.com/neilh10/ModularSensors/issues/1 for reasonably flexible communications https://github.com/neilh10/ModularSensors/issues/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 https://github.com/neilh10/ModularSensors/issues/4

HAL Discussion https://github.com/EnviroDIY/ModularSensors/issues/244 Ref starting discussion https://github.com/EnviroDIY/ModularSensors/issues/298

neilh10 / ModularSensors

reference model - Modem Subsystem managing the Modem Hybrid #8