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...
Hmmm, keine Meinungen (weder zustimmend noch widersprechend)? Scheinbar
noch nicht mal Rechtschreibfehler drin? Oder ist das Thema in
Fachkreisen schon so ausgelutscht, dass nur noch ein "Nicht schon wieder
das Ding..." Augenrollen kommt?
Das erwähnte Quectel (Rechtschreibfehler im Originalposting!) hat als
Funkmodul das Qualcomm MDM9206 drin, von dem leider keine technischen
Unterlagen frei verfügbar zu sein scheinen, also ist es schwer zu
beurteilen, ob man mit "Kurzschluss" effizienter vom Host an die Luft
kommt als über das Playmobilinterface. Wundert mich doch aber sehr, dass
dieser für den Stromverbrauch recht elementare Aspekt scheinbar ein Nop
ist.
Oder sehe ich da etwas falsch?
Alter_Sack schrieb:> Hmmm, keine Meinungen (weder zustimmend noch widersprechend)? Scheinbar> noch nicht mal Rechtschreibfehler drin? Oder ist das Thema in> Fachkreisen schon so ausgelutscht, dass nur noch ein "Nicht schon wieder> das Ding..." Augenrollen kommt?
Was soll es da für Meinungen geben?
Du warst sehr überzeugend mit deiner Argumentation ;-)
Und eine Frage hatte ich auch nirgends gelesen :)
Alter_Sack schrieb:> 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.
Es gibt auch noch die Sorte von Modulen wo man den µC zur Kommunikation
(BT LE, WLAN) direkt programmieren kann (u.a. ESP32, NRF5x). Damit fällt
bei vielen Aufgaben ein µC komplett weg.
Bei den Modulen mit Hayes AT Interface will man eher nur ein vorhandenes
Design mit Funk Kommunikation ausstatten. Spart Entwicklungskosten.
Alter_Sack schrieb:> 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.
Es gibt µCs die sehr sparsam bei langsamer UART Übertragung sind. Viele
Silabs EFM32 z.B. müssen für 9600Baud nur den Uhrenquarz anschalten.
Bei sehr vielen Anwendungen ist das zu übertragende Datenvolumen gering
(wenige Bytes pro Sekunde) und Verzögerungen im zweistelligen ms Bereich
akzeptabel. Im Ethernet muss man ohnehin mit sporadischen
Verzögerungszeiten bis zu einigen zig ms rechnen und im WLAN sind
gelegentliche Delays von einigen hundert ms normal.
Für diese Fälle ist die AT Schnittstelle sehr gut geeignet. Das
Interface zum µC benötigt nur 2 Signal-Leitungen, man kann die
Kommunikation buchstäblich mitlesen und man kann sie manuell simulieren.
Viele WLAN Module kann man wie gesagt auch direkt programmieren und es
gibt durchaus auch einige, die eine schnellere Schnittstelle (z.B. SPI)
mit einem binären Protokoll haben.
Das Senden von AT Kommandos lässt sich mit der printf() Funktion leicht
realisieren und das Parsen der Antworten ist kein Hexenwerk. Falls du
ein simples Beispiel sehen willst:
http://stefanfrings.de/wlan_io/index.html darin die Datei
src/driver/wlan-module.c. Das ist übrigens genau so ein Projekt was Jim
Meba meint, wo eine bereits bestehende Applikation um WLAN erweitert
wurde.
Bei einem Punkt muss ich widersprechen:
> 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.
Die UART Schnittstelle des Arduino Nano hat 5V Pegel. Da braucht man
keine Charge Pump sondern einen Spannungsteiler um auf 3,3V runter zu
kommen.
> Vermutlich könnte ich mir als Modemhersteller eine goldene Nase damit> verdienen, Modems mit einem Binärinterface über SPI herzustellen.
Nein, denn die gibt es längst. Schau mal bei der Firma Wiznet.
Abgesehen davon kann man wie Jim Meba schon schrieb, einige Chips direkt
selbst programmieren, und dann jedes beliebige Kommunikationsprotokoll
verwenden. Oder man nutzt die Chips für eine Single-CPU Lösung, dann
braucht man gar keine Kommunuikationsschnittstelle mehr. Die Firma
Espressif hat das so bereits am Markt, für Preise niemand unterbieten
können wird, nämlich 1,50€ bei Einzel-Abnahme!
Noch eine kleine Anmerkung zur Datei wlan-module.c:
Um uralte Firmware Versionen mit anderem Zeilenumbruch zu unterstützten,
habe ich dort die Variable "linefeed" verwendet. Heute würde ich den
Zeilenumbruch hardcodieren, die alten Firmware Versionen sind längst
obsolet geworden.
