Embedded-Linux: Terminal vom GSM-Modem hängt

Am 03.09.2015 10:29 schrieb Manuel Reimer:

probieren ist auch oft eine gute Idee.

Restliche Probleme mit Watchdogskript und Reboot erschlagen. - Die USB-Anbindung vom Raspi entspricht nicht ganz dem, was man vom PC so kennt. Es ist unklar, ob man die wirklich jemals stabil bekommt. Das ist

Hanno

bestelle ich das hier:

Hutschienen-Netzteil sollte hochwertig genug sein.

Da habe ich im Netz aber schon andere Meinungen gelesen. Mal sehen was die Erfahrungen hier zeigen...

Manuel

Systemtechnik des Netzbetreibers - generell sind all diese Dinger

abschmieren.

UMTS/LTE-Dinger eine Resetfunktion, die dem Ding kurz die 5V abklemmt, wenn es abschmiert. Die wissen, warum das eine gute Idee ist :)

-ras

--
Ralph A. Schmid 
http://www.schmid.xxx/ http://www.db0fue.de/ 
http://www.bclog.de/ http://www.kabuliyan.de/

Am 03.09.2015 12:07 schrieb Manuel Reimer:

nicht zuletzt vom Aufwand in den Treibern ab.

Hanno

Hast du da eine Quelle dazu? Konnte auf die Schnelle nichts finden.

Wenn sich das Modem morgen wieder totstellt, dann sende ich mal den Befehl, dass der Port in Standby gehen soll. Wenn die Firmware nicht

eigentlich jedes Mal machen wenn ich meinen Datentransfer durchhabe (spart ja auch Strom). Wenn er daraus wieder in funktionalem Zustand

Manuel

Das es USB-OTG ist, habe ich erwartet. Allerdings ist der SoC mittlerweile gut abgehangen. Einige fahren problemlos kleine

Stimmt. Mehr wie "usbserial" brauche ich aber nicht. Ich erwarte einfach mal, dass dieser Treiber nach etlichen Jahren doch ziemlich stabil sein

Extra aus dem Grund habe ich den Stick ja bis auf "Modem" runterkonfiguriert. Den ganzen anderen Treiber-Murks will ich garnicht erst mitladen.

Manuel

Aber wie Hanno schon schrieb, ist USB auf dem Raspi recht "eigenartig". Ich

gleichzeitig am Raspi nicht funktionieren.

sowie ein WLAN-Stick.

gestrickt.

endlich stabil lief.

Vielleicht hifts ja bei Dir auch.

Paul

das nicht.

Nachtrag: Eine sehr lange Laufzeit braucht es garnicht sondern schon nach kurzer Zeit scheint in irgendeinem "Buffer" so viel Status-Nachricht gespeichert zu sein, dass der serielle Port dauerhaft

Manuel

Stichwort M2M, machine to machine, da sollte man schon was googeln

nur, weil ich von denen ein Modul im ThinkPad hatte.

wenn der Port in standby geht.

-ras

--
Ralph A. Schmid 
http://www.schmid.xxx/ http://www.db0fue.de/ 
http://www.bclog.de/ http://www.kabuliyan.de/

Am 2015-09-03 um 10:29 schrieb Manuel Reimer:

Ich habe einen Huawei (genaues Modell muss ich zuhause nachschauen) an einem RP B+. Das ganze macht SMS forwarding an ein Iridium Satphone (deutsche Mobilfunkanbieten schicken keine SMS ans Iridium Netz), daher nutze ich die webseite von Iridium per curl um die empfangene SMS weiterzuleiten.

Am Anfang hatte ich auch Probleme (komisches Verhalten, kein kompleter Ausfall) bis ich den USB Surfstick per extern versorgtem USB Hub an den

liefern kann.

Vielleicht hilft das auch bei Dir.

Bernd

On 09/03/2015 04:15 PM, Bernd Nebendahl wrote:

Habe ich gerade probiert. Hochwertiger Hub mit 2,5A externem Netzteil. Verhalten bleibt exakt gleich.

Der "Ausfall" resettet sich wenn man rebootet. Wenn die Hardware (der

abgestellt wird.

Ich bin so langsam echt mit meinem Latein am Ende...

Konkret bekomme ich (bevor der Stick erst wieder nach Aus-/Einstecken oder Reboot reagiert) folgendes im Log:

Sep 03 16:30:45 alarmpi pppd[358]: pppd 2.4.7 started by root, uid 0 Sep 03 16:30:46 alarmpi chat[359]: timeout set to 5 seconds Sep 03 16:30:46 alarmpi chat[359]: abort on (\nBUSY\r) Sep 03 16:30:46 alarmpi chat[359]: abort on (\nERROR\r) Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO ANSWER\r) Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO CARRIER\r) Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO DIALTONE\r) Sep 03 16:30:46 alarmpi chat[359]: abort on (\nRINGING\r\n\r\nRINGING\r) Sep 03 16:30:46 alarmpi chat[359]: send (^MAT^M) Sep 03 16:30:46 alarmpi chat[359]: send (ATZ^M) Sep 03 16:30:46 alarmpi chat[359]: timeout set to 12 seconds Sep 03 16:30:46 alarmpi chat[359]: expect (OK) Sep 03 16:30:46 alarmpi chat[359]: ^MAT^M^M Sep 03 16:30:46 alarmpi chat[359]: OK Sep 03 16:30:46 alarmpi chat[359]: -- got it Sep 03 16:30:46 alarmpi chat[359]: send (ATE1^M) Sep 03 16:30:47 alarmpi chat[359]: expect (OK) Sep 03 16:30:47 alarmpi chat[359]: ^M Sep 03 16:30:47 alarmpi chat[359]: ATZ^M^M Sep 03 16:30:47 alarmpi chat[359]: OK Sep 03 16:30:47 alarmpi chat[359]: -- got it Sep 03 16:30:47 alarmpi chat[359]: send (AT+CGDCONT=1,"IP","data.access.de"^M) Sep 03 16:30:47 alarmpi chat[359]: expect (OK) Sep 03 16:30:47 alarmpi chat[359]: ^M Sep 03 16:30:47 alarmpi chat[359]: ATE1^M^M Sep 03 16:30:47 alarmpi chat[359]: OK Sep 03 16:30:47 alarmpi chat[359]: -- got it Sep 03 16:30:47 alarmpi chat[359]: send (ATD*99#^M) Sep 03 16:30:47 alarmpi chat[359]: expect (CONNECT) Sep 03 16:30:47 alarmpi chat[359]: ^M Sep 03 16:30:47 alarmpi chat[359]: AT+CGDCONT=1,"IP","data.access.de"^M^M Sep 03 16:30:47 alarmpi chat[359]: OK^M Sep 03 16:30:47 alarmpi chat[359]: ATD*99#^M^M Sep 03 16:30:47 alarmpi chat[359]: CONNECT Sep 03 16:30:47 alarmpi chat[359]: -- got it Sep 03 16:30:47 alarmpi chat[359]: send (^M) Sep 03 16:30:47 alarmpi pppd[358]: Serial connection established. Sep 03 16:30:47 alarmpi pppd[358]: Using interface ppp0 Sep 03 16:30:47 alarmpi pppd[358]: Connect: ppp0 /dev/ttyUSB0 Sep 03 16:31:18 alarmpi pppd[358]: LCP: timeout sending Config-Requests Sep 03 16:31:18 alarmpi pppd[358]: Connection terminated. Sep 03 16:31:19 alarmpi pppd[358]: Modem hangup

PPP kann dann die Verbindung nicht aktivieren.

Manuel

u-blox und Quectel fallen mir noch ein - ich habe mit beiden keine Erfahrungen.

Die Sierra UMTS/LTE-Module zeigen normalerweise keine der hier beschriebenen

cu Michael

Am 03.09.2015 um 10:29 schrieb Manuel Reimer:

Das sind "unsolicited result codes", Du kannst ja mal versuchen die mit

at^curc=0

abzustellen. Die AT-Kommandoreferenz zum E352s konnte ich nicht finden, aber hier...

Andreas

Manuel Reimer :

M.

Ist sie. So kommen auch keine 5V am USB raus, sondern IIRC nur so um die

4.4V. Das ist zwar noch im Bereich der USB Spec, aber wenn man Hardware erwischt, deren Entwickler die Specs nicht gelesen haben und froehlich 5V erwarten dann kann es da schonmal eng werden.

An sowas hat man sich doch in dem Bereich der kleinen (embedded) Bastel-

Man liest sich, Alex.

--
"Opportunity is missed by most people because it is dressed in overalls and 
 looks like work."                                      -- Thomas A. Edison

Ack, so sehe ich das auch. Die Probleme beginnen IMHO ab:

| Sep 03 16:31:18 alarmpi pppd[358]: LCP: timeout sending Config-Requests

Ich verstehe das so, dass der pppd vergeblich auf LCP-Antworten der Gegenstelle wartet. Woran das liegt, wird aus dem log leider nicht deutlich, weil danach keine detaillierten Meldungen mehr kommen. Du kannst entweder den syslogd empfindlicher einstellen, wie das genau

also wer wann was sendet, bzw. erwartet. Dann wird klarer, wo es hakt. Aber generell brauchst Du mehr Informationen, also das logging

Fehlermeldungen im web auf die Suche gehen.

wir hatten vor vielen Jahren mit Telit-Teilen ebesolche Probleme und

einer kurzen Bedenkzeit wieder zu geben. Das Ding hat nichtmal mehr auf den /Reset sauber reagiert....

Naja, seit dem funktioniert das

- Michael Wieser

Hallo,

ich habe gestern nochmal einige Zeit rumprobiert und jetzt steht die Verbindung.

dann meine Konfigurationen neu reingespielt.

Manuel

man neben der stehenden Internetverbindung auf /dev/ttyUSB0 noch den

/dev/ttyUSB2 liest (habe ich mit Perl versucht. Wollte die Daten eigentlich auswerten und nutzbar machen). Das ist zu 100% reproduzierbar. Passiert nur auf dem Raspberry. Das gleiche Perl-Script

mir auf dem Desktop die gleiche wie auf dem Raspberry.

pastebin.com/Eacp7TP4

Danach geht wieder eine Einwahl.

entlade ich alle Kernel-Module die mit dem Surfstick zu tun haben. Vor dem Transfer resette ich einmal den Port was dann effektiv die Module

Manuel