Gast
#5234421
Hallo Alle,
es verwundert mich extrem, dass bei sog. IoT Modulen (z.B. Queltec BG96)
immer noch das Hayes AT Interface State of the art zu sein scheint.
Da werden auf der Netzwerkseite hochoptimierte Protokolle und auf der HW
Seite Sleep Modes propagiert, die die Batterielaufzeit theoretisch auf
11 Jahre strecken sollen, aber das Hostprotokoll basiert auf 80er Jahre
Technologie, bei der komplett unnütze Zeichen zu Hauf von A nach B
geschickt werden:
- In jedem Kommandozyklus mindestens 'A','T',CR sowie der
Kommandoschwanz ('+', das Klartextkommand wie "cgdconf=" sowie jeder
Parameter durch Klartextkomma getrennt) zum Modem, zurück im Best case
Fall mindestens CR LF (bei numerischen Resultaten gibt es dann
wenigstens eine '0' als OK zurück)
- Dazu muss jedes Datenbyte lesbar aufbereitet werden (also auf 0x4 wird
dann z.B. 0x3034). Eine IPv4 IP Adresse zu kommunizieren benötigt im
Durchschnitt 11 bytes ("xx.yy.zz.ww") statt 4 bytes, die sie in binärer
Repräsentation benötigt.
Das bläht nicht nur das Datenvolumen um ein Vielfaches auf, sondern
erfordert auch völlig unnötig auf Modem- UND Hostseite CPU Zyklen zum
Aufblasen der Daten auf der einen und Abpumpen auf der Anderen Seite.
Von dem Parsen der Antwort mal ganz abgesehen.
Ein kleines Rechenbeispiel: Nehmen wir mal sehr konservativ an, dass bei
jedem Befehlsyklus zum Modem 10 unnötige Bytes gesendet werden. Während
eines Wachzyklus werden sagen wir mal 10 Pakete hin- und hergetauscht.
Das sind bei 115200 BPs auf der Hostschnittstelle fast 10ms allein an
komplett sinnfreien Kommunikationsoverhead, von dem o.g. beidseitigen
Auf- und Abpumpen mal ganz abgesehen.
Und wenn dann noch als Host (wie kürzlich gesehen) ein Arduino Nano
genutzt wird, reden wir nicht TTL UART, sondern RS232, also geht für die
Charge Pump der Pegelkonvertierungen nochmal Energie völlig unnütz in
die Luft.
Vermutlich könnte ich mir als Modemhersteller eine goldene Nase damit
verdienen, Modems mit einem Binärinterface über SPI herzustellen. Leider
aber wird das höchstens eine Pappnase werden, und zwar aus folgenden
Gründen:
1. Batterielaufzeiten im IoT empirisch zu messen und zu vergleichen
würde (wenn seriös) Testzeiten verlangen, die länger sind als es
Buzzwords wie IoT jemals gibt, also kein Marketingvorteil
in absehbarer Zeit
2. Die Zertifizierungskosten für so ein Modem würden zur Amortisierung
ein Mindestabsatzstückzahl erwarten, die für einen Startup
nicht realistisch sind
3. Man müsste an die Entwicklung gegen so ein Modem einen
Profi heranlassen. Die von der Strasse geheuerten Micky Maus
Klickibuntikids, die nur etwas mit symbolischer "Programmierung"
wie HTML oder XML anfangen können, wären allein mit
dem Lesen des Data Sheets hoffnungslos überfordert.
Schöne neue Welt. Naja, eher neu als schön...