Hallo, ich entwickle gerade eine kleine Alarmanlage für einen Snackautomaten und nutze dafür ein marktübliches GSM-Modul, welches über ein Raspberry Pico angesteuert wird. Um einen Alarm zu versenden, muss ich das GSM-Modul mittels PDU-kodierten Befehl ansteuern. Grundsätzlich funktioniert das Versenden von SMS auch. Da ich aber vorhabe, über die DEX-Schnittstelle des Automaten später auch zusätzliche Informationen über den Automaten zu versenden, wollte ich den SMS-Versand direkt in Unicode umsetzen. Da das nicht funktionierte und das Internet zwar voll mit irgendwelchen Quellen ist, die aber kaum bis überhaupt nicht weiterhelfen, habe ich mir die Spezifikation für das PDU-Protokoll heruntergeladen (3GPP TS 23.040, siehe Anhang). Dabei hänge ich jetzt gerade an den Message Flags (erstes Oktett nach den kodierten Informationen über das SMSC). Die Spezifikation unterscheidet nach Nachrichtentyp (Kapitel 9) und gibt vor, welche Bits welches Flag repräsentieren. Theoretisch zumindest. Tatsächlich lässt sich das aus der Spezifikation nur schwer ableiten, da nur lose dabei steht, welche Flags für welchen Nachrichtentyp mit wievielen Bits überhaupt gesetzt werden. Da ich zukünftig nur selten wieder mit dem PDU-Format in Berührung kommen werde, insofern alles reibungslos funktioniert, trage ich meine Erkenntnisse in einer PowerPoint zusammen, die ich als PDF beigefügt habe. Auf Seite 8 ist mein Problem mit einer möglichen Lösung zusammengefasst. In der Spezifikation findet sich das ab Kapitel 9.2. Zu meiner Frage: Woher weiß ich bei der Option SMS-DELIVER, welches der Bits nicht zu setzen ist? Es handelt sich um ein Oktett, dass laut Spezifikation aber nur 7 Bits bei diesem Nachrichtentyp verwendet. Grundsätzlich hätte ich auf Bit 7 getippt, welches nicht zu setzen ist. Spaßeshalber habe ich ChatGPT gefragt, die KI benennt Bit 5 und 6 als reserviert (witzig, dann wären es nur noch 6 Bits) und auf Nachfrage dann nur Bit 5 "weil es etablierte Regeln gibt". Grundsätzlich habe ich festgestellt, dass die Auflistung in der Spezifikation bei Bit 0 beginnt. Steht also TP-MTI als erstes (was zwei Bit benötigt), so belegt diese Flag eben Bit 0+1 (anhand der Darstellung der Tabelle ist das nicht unbedingt intuitiv, ich bin zuerst verkehrt herum rangegangen). Zum Vergleich siehe http://www.nobbi.com/sms_pdu.html (die einzige sehr gute Quelle zu dem Thema). Bei den REPORT-Nachrichtentypen steht unter der Tabelle wenigstens noch, welche Bits reserviert sind, da kann ich mir das ableiten. Schaut man sich in meiner PDF aber mal die Tabelle an, dann könnte die Antwort von ChatGPT durchaus richtig sein, da die UDHI-Flag sonst einzig bei DELIVER auf Bit 5 und nicht wie bei allen anderen Nachrichtentypen auf Bit 6 übertragen werden würde. Einfach testen, welche SMS ankommt und welche nicht, will ich aus Kostengründen nicht. Ich hoffe, meine Frage ist verständlich. Viele Grüße und vielen Dank bereits jetzt, Sören
Die Spezifikation ist eine Sache. Wie es von den Konkreten Modems/Handies umgesetzt wurde, ist leider eine andere. Oft unterstützen die Geräte nur ein Subset der Spezifikation. Vielleicht magst du von meinen SMS Server Tools abgucken: http://stefanfrings.de/smstools/index.html Der Code ist schon sehr alt, deswegen stecke ich da im Detail nicht mehr drin. Aber ich denke, die Datei pdu.c macht das, was du brauchst. Da findest du auch die Flags wieder. Das Programm PDUSpy war mit in dem Zusammenhang hilfreich: http://www.nobbi.com/pduspy.html
:
Bearbeitet durch User
SMS PDUs gibt es doch schon sehr lange, es gibt mehr als genügend Source Code der damit umgeht. Zum PDU Type siehe z.B. hier: https://bluesecblog.wordpress.com/2016/11/15/sms-deliver-tpdu-structure/ Und wenn man eine SMS-DELIVER PDU dekodieren will kann man sich z.B. das hier ansehen: https://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-deliver-pdu-decoder/
Vielen Dank euch beiden. Dann gehe ich mal so rum ran. Also bestehende Implementierungen unter Berücksichtigung der Spezifikation anschauen und mit Hilfe von Decodern bzw. der PDUSpy-Anwendung offene Punkte (wie den aus meiner Frage) durch probieren herausfinden. Auf jeden Fall besser als ständig kostenpflichtig abzuschicken, die dann abgelehnt werden, um der Sache auf den Grund zu gehen.
Ich möchte die Bemühungen und Erfolge ja nicht schlechtmachen, aber man könnte sich viel Zeit und Aufwand ersparen, indem man a) die SMS über die Webschnittstelle eines entsprechenden Anbieters versendet oder b) einen Telegram-Bot (oder beliebig anderen Messenger) benutzt. c) Lora wäre auch eine Überlegung wert
Nochmal zum Erzeugen von SMS PDUs, man findet auch fertige
Implementierungen die Unicode können, u.a. die hier ("A simplified C
library for generating PDU encoded multi-part multilingual SMS"):
https://github.com/hu55a1n1/Multi-part-SMS-PDU-generator
Diese basiert auf einer scheinbar erweiterten/angepassten Version der
bereits weiter oben erwähnten SMS Server Tools.
Wie schon geschrieben, das ist alles nichts Neues, wenn man sehen will
wie das Ganze auf der Mobilfunkseite implementiert ist kann man sich
z.B. OpenBSC (Netz) oder OsmocomBB (Telefon) ansehen.
Frank E. schrieb: > Ich möchte die Bemühungen und Erfolge ja nicht schlechtmachen, aber man > könnte sich viel Zeit und Aufwand ersparen, indem man Ja, damit hast du Recht. Es ist ein erheblicher Aufwand für ein bereits oft gelöstes Problem. Als Freizeitprojekt reizt es mich aber durchaus, auch wirklich die Hintergründe zu verstehen. > a) die SMS über die Webschnittstelle eines entsprechenden Anbieters > versendet > oder > > b) einen Telegram-Bot (oder beliebig anderen Messenger) benutzt. Der Automat steht leider nicht in einem Areal, in dem Internet verfügbar wäre. Ich bin schon froh, dass überhaupt für SMS genug Empfang da ist. > c) Lora wäre auch eine Überlegung wert Sehr interessantes Projekt, kannte ich noch nicht! Nicht für dieses Vorhaben, aber generell ein wirklich interessanter Ansatz, inbesondere weil man damit monatliche Kosten für den Mobilfunk sparen könnte. Dieter S. schrieb: > Nochmal zum Erzeugen von SMS PDUs, man findet auch fertige > Implementierungen die Unicode können, u.a. die hier ("A simplified C > library for generating PDU encoded multi-part multilingual SMS"): > > https://github.com/hu55a1n1/Multi-part-SMS-PDU-generator Das ist mir bei meinen Suchen gar nicht untergekommen, danke für den Hinweis! Zu meiner ursprünglichen Frage und der Vollständigkeit wegen: Ich konnte die genaue Bitzuordnung in der Spezifikation finden (vorab: ChatGPT lag wie so oft bei nicht fundierten Annahmen falsch mit Bit 5). Sie steht bei den Erklärungen der jeweiligen Flags. Da da aber teilweise 30 Seiten mit völlig anderen Inhalten dazwischen liegen, ist mir das vorher durch die Lappen gegangen. Wenn ich das alles für meine Anforderungen fertig erarbeitet habe, stelle ich die PowerPoint als PDF nochmal hier rein. Danach schaue ich mir dann die hier genannten Implementierungen für mein Projekt an, das geht am Ende schneller, als es selbst zu implementieren.
Rhino R. schrieb: > Der Automat steht leider nicht in einem Areal, in dem Internet verfügbar > wäre. Ich bin schon froh, dass überhaupt für SMS genug Empfang da ist. GSM wird aber so langsam abgeschaltet. In der Schweiz schon vor anderthalb Jahren. Es gab Gerüchte, dass Vodafone das Ende 2025 abschaltet, aber momentan sagen sie, dass es wahrscheinlich bis Ende 2030 nach und nach abgeschaltet wird. https://www.pcwelt.de/article/2251322/wann-2g-abschaltung-folgen.html SMS scheint zwar auch über 4G/5G zu gehen, aber wenn Du da keinen Empfang hast solltest Du langfristig an Alternativen denken.
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.