Hallo Forum, die beiliegenden Programme sind Konvertierungsprogramme für externe Peripheriegeräte, die das Display eines Siemens Mobiltelefons nutzen. Jedes Programm konvertiert je in eine Richtung. Programm 1: Damit ist möglich, die belauschte Kommunikation z.B. zwischen Mp3-Spieler Adapter fürs Mobiltelefon und dem Mobiltelfon selbst zu übersetzen. Programm 2: Damit ist möglich beliebige Texte auf dem Display des Mobiltelefons darzustellen. Vgl. hierzu die Abbildung. Viel Spaß damit. Anwendungen gibts ja genug ;-) Mehr zum Thema Siemens Telefon und PDU gibt es hier: Beitrag "SMS in PDU Format konvertieren" Beitrag "SMS im PDU.Format in Text umwandeln" Beitrag "GSM GPS - Tracker" Grüße Niels
HALLO; weis jemand ob das S45i Handy den befehl AT^SSTK= unterstüzt? Bei mir kommt nur Error raus siehe Anhang ( ohne Echo ). Hat es schon jemand auf ein anderes Siemens Handy als dem A60 ausprobiert? Eigentlich sollte das auch auf dem S45i laufen. @Niels ich habe dein Programm genommen und entsprechend den M16 und Baud=19200 und 4800 ausprobiert. Gibt es zum Befehl weitere Infos wie und warum das so und so gemacht wurde. Gruss AVRNix
Avr Nix schrieb: > Gibt es zum Befehl weitere Infos wie > und warum das so und so gemacht wurde. Der AT^SSTK-Befehl bedeutet bei den Siemensgeräten "Sim Toolkit Test Command". Infos zum Befehl gibt es z.B. hier: http://alumni.ipt.pt/~pmad/s35i_c35i_m35i_atc_commandset_v01.pdf oder alternativ nach "Siemens at command reference" suchen. In diesen Datenblättern ist recht gut erklärt, wie die Befehle strukturiert sind. Getestet mit: A31, MC60, CV65, C60 Ist im Grunde bei allen Geräten dabei, die externe Geräte, wie z.B. mp3-Spieler anschließen können und lediglich(!) das Display nutzen. Probiere mal den Funktionsaufruf aus dem IQP500-Bildüberträger (http://www.mikrocontroller.net/attachment/62627/Software.zip) aus - dieser funktioniert bei mir recht gut.
@Niels danke hat soweit geklappt :) kann man Wo der Titel T-Mobile oder Vodafon steht ausblenden oder löschen sonst kommt es zu einen Blink Effekt. Wie bekommt du eine freie Anzeigefläche? Danke AVRNix
Kannst du bitte einmal erklären, wie der Header [c] Ergebnis = "D0" Hexanzahl = Hexanzahl - 2 T3 = Hex(hexanzahl) Ergebnis = Ergebnis + T3 Ergebnis = Ergebnis + "8103012180820281028D [\c] zustande kommt?? Ich bin im GSM 11.14 (v5-2-0) nicht so richtig fündig geworden. Evtl. kannst mir auch mal die Seite im GSM 11.14 sagen, wo das aufgeschlüsselt ist. B in irgendwie zu blöd das zu finden. Danke schon mal im voraus.
Ich hab mir jetzt alles rausgesucht. Was mich nur noch wundert ist die Angabe von: Command Detail Tag --> laut GSM 01 --> bei dir 81 Device Detail Tag --> laut GSM 02 --> bei dir 82 Text String Tag --> laut GSM 0D --> bei dir 8D
> Ich bin im GSM 11.14 (v5-2-0) nicht so richtig fündig geworden. Evtl. > kannst mir auch mal die Seite im GSM 11.14 sagen, wo das aufgeschlüsselt > ist. B in irgendwie zu blöd das zu finden. Danke schon mal im voraus. Das wird dort auch nicht aufgeführt - es handelt sich bei allen Befehlen, die mit AT^Sxxx anfangen, um siemensspezifische Befehle. Diese sind demnach nicht in der Normung aufgeführt. Man findet die Informationen in diversen Siemensdatasheets, wie bereits oben genannt, oder aber durch Ausprobieren, d. h. Abhören der Kommunikation zwischen mp3-Spieler und Telefon C´est déjà tout. > Wie bekommt du eine freie Anzeigefläche? Bei mir ist sie frei. Sobald aber wieder auch nur ein Zeichen gesendet wird, verschwindet der Text wieder. Das ist ja auch der Sinn bei Sekundenangaben, daher gibt es die Möglichkeit zwischen Single und Continous zu wechseln. Dies geschieht in folgenden Zeilen. Hier die 0 ändern und der Modus wird gewechselt.
1 | Print "AT^SSTK=" ; Hexanzahl; |
2 | '0 da single command |
3 | Print ",0" |
Niels Keller schrieb: > Das wird dort auch nicht aufgeführt - es handelt sich bei allen > Befehlen, die mit AT^Sxxx anfangen, um siemensspezifische Befehle. Diese > sind demnach nicht in der Normung aufgeführt. Man findet die > Informationen in diversen Siemensdatasheets, wie bereits oben genannt, > oder aber durch Ausprobieren, d. h. Abhören der Kommunikation zwischen > mp3-Spieler und Telefon C´est déjà tout. Das ist so nicht richtig. In dem besagten GSM paper, auf welches in der Erläuterung des Befehls im AT command set verwiesen wird, ist alles detailliert aufgeführt. Nur eben alles etwas durcheinander. Man muss von einem Kapitel zum nächsten springen - immer wieder hin und her - um alle Details zu finden. Dabei ist mir dann eben aufgefallen, dass bei: SL55 schrieb: > Command Detail Tag --> laut GSM 01 --> bei dir 81 > Device Detail Tag --> laut GSM 02 --> bei dir 82 > Text String Tag --> laut GSM 0D --> bei dir 8D Ungereimtheiten vorhanden sind. Deswegen die Nachfrage. Ich habs jetzt aber noch nicht getestet. Hier noch einmal der Link zur Spezifikation: http://www.ttfn.net/techno/smartcards/GSM11-14V5-2-0.pdf
SL55 schrieb: > Das ist so nicht richtig. In dem besagten GSM paper, auf welches in der > Erläuterung des Befehls im AT command set verwiesen wird, ist alles > detailliert aufgeführt. Teilweise OK. Der eigentliche Befehl, der gesendet wird, und um welchen es hier geht, ist dort nicht explizit aufgeführt - es wird lediglich auf das prinzipielle ME Toolkit Accesoire eingegangen. Leider stehe ich bei diesem Befehl auch nicht tiefer in der Materie und müßte mich auch erst wieder mit dem Sachverhalt auseinandersetzen - bin aber gerade mit meiner Kamera und den Macken einer SD-Karte bei Kabellängen >1m beschäftigt. Wie es zu den Unterschieden beim Zusammensetzen kommt müßte man wohl beim Hersteller erfragen. Das Ding wurde ohnehin in einer dreiviertel Stunde von hinten nach vorne durchgezogen. Es wurde überprüft, was gesendet wurde und mit dem Text verglichen. Das Ganze einige Male und dann den Overhead analysiert. Dieser Teil ist komplett übernommen worden, da er immer gleich war: "8103012180820281028D" Der Rest ist variabel und, das ist der Unterschied zum Siemensdatasheet, noch nicht einmal im PDU-Format, sondern direkt als 8Bit-Byte HEXDUMP übertragen. Mein Vorschlag ist es daher ein Telefon zu nehmen und den Praxistest zu machen, welche Auswirkungen die Änderungen haben - oder alternativ zu einem Mobilfunkaparatehersteller Kontakt aufzunehmen und zu erfragen, wie man an die Geräte externe Hardware anschließen kann.
Niels Keller schrieb: > Dieser Teil ist komplett übernommen > worden, da er immer gleich war: "8103012180820281028D" Der Rest ist > variabel und, das ist der Unterschied zum Siemensdatasheet, noch nicht > einmal im PDU-Format, sondern direkt als 8Bit-Byte HEXDUMP übertragen. Das nächste Byte sollte eigentlich auch immer gleich sein. Das müsste das Data Coding Scheme sein. Das sollte sich eigentlich auch nicht ändern. Ich arbeite bei mir im PDU Format.
SL55 schrieb: > Das nächste Byte sollte eigentlich auch immer gleich sein. Das müsste > das Data Coding Scheme sein. Das sollte sich eigentlich auch nicht > ändern. Ich gehe davon aus, dass es sich um die Länge des Textes handelt. > Ich arbeite bei mir im PDU Format. Das ist interessant - ob man bei einer SMS auch einfach direkt einen HEX-Dump abschicken kann, also ohne PDU-Format?
Niels Keller schrieb: > Ich gehe davon aus, dass es sich um die Länge des Textes handelt. Die Länge des Textes kommt vorher. Also nach Text String Tag (bei mir 0D, bei dir 8D) kommt die Länge des Textes (variabel), danach das Data Coding Scheme (konstant, bei mir 00) und schließlich der Text. Eine SMS verschicke ich mit dem Befehl AT+CMGS im PDU Format. Es müsste aber auch mit AT^SSTK gehen. Niels Keller schrieb: > Das ist interessant - ob man bei einer SMS auch einfach direkt einen > HEX-Dump abschicken kann, also ohne PDU-Format? Das unterstützte Format für AT+CMGS kann man zumindest einstellen. Da besteht aber eigentlich nur die Wahl zwischen PDU und Klartext (mein SL55 kann nur PDU).
Bitte 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.