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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.