Beiträge von Rheinhesse

Hallo Carnica,

die meiseten Hersteller geben bei ja SD-Karten einen Wert von ca. 300.000 Read/Write Operations an (endurance), wobei das Schreiben wohl der "belastendere" Teil ist.

Beim Defragmentierten eines Dateisystems kommen leicht einige tausend Änderungen in der Verwaltungsstruktur (File Allocation Table) zusammen.

OT:
ZUM SCHIEFLACHEN ... wie man richtig defragmentiert

Wer wissen will, wie man "manuell" defragmentiert, bitte hier klicken

Hallo,

>HIER< im Forum PPC-Welt finden sich noch Infos zum Defragmentieren der Speicherkarten.

Hallo,

laut heise online ist der erste Virus für PDAs mit Windows Mobile/Pocket-PC-Betriebssystem aufgetaucht.

Artikel siehe HIER

Ist zwar erst ein "proof of concept" aber die Schädlinge folgen meist umgehend.

Hallo Extrapurifier,

den "Flohmarkt" des Forums findest Du HIER

Hallo hamba,

Zitat

Original von hamba

Ich habe mal theoretisch die Übertragungsmenge (ASCII-Zeichen) ausgerechnet, wenn alle NMEA-Protokolle angeschaltet und auf 1s Intervall eingestellt sind und wenn 12 Satelliten in view sind. Es müssten dann so ca. 484 Zeichen (GGA= 70, GLL = 47, GSA = 53, GSV1 = 71, GSV2 = 71, GSV3 = 71, RMC = 67 und VTG = 34) anfallen. Diese 484 Zeichen ergeben wiederum bei 8 Bit pro Zeichen 3872bit.

hast Du bei der Berechnung der Protokolllänge pro Protokoll auch jeweils die 2 Zeilenende-Zeichen (CR/LF) berücksichtigt ?
Im LOG ist ja zu erkennen das jedes Protokoll in einer neuen Zeile anfängt. Wären die 2 Zeichen nicht im Datenfluß hätte man im Protokoll nicht diese "optische" Trennung der Einzel-Protokolle. Zu kontrollieren ggf. mit einem HEX-Editor auf die Protokolldatei.

Zitat

Diese 484 Zeichen ergeben wiederum bei 8 Bit pro Zeichen 3872bit. Das ist also weniger als die theoretisch mögliche Übertragungsmenge die pro Sekunde bei 4.800b/s übertragen werden kann.

bitte nicht mit 8 Bit/Zeichen bei serieller Übertragung rechnen, das ist definitiv falsch. 10Bit sind ein guter Wert.

Hallo karomue,

schön das ich auch mal mit Tips helfen konnte

Läßt sich aber nur bei ASCII-Daten verwenden. Binärdaten lassen sich ggf. mit einem Hex-Editor analysieren.

Hallo karomue,

Zitat

Original von karomue
Ach, Rheinhesse: der Neuigierde halber: wie macht man das mit dem Terminalprogramm? Irgendwie habe ich das bislang nicht geschnallt, würde mir das gerne mal am NB ansehen. Habe eine BT-Maus und einen BT-Adapter.Damit kann ich auch am NB "GPS"-len, z.B.mit VisualGPSXP.

Bitte Detailanweisung "für Anfänger". Telegrammstil sollte aber reichen.

Aber gerne. Ich kann hier momentan nur für Windows (Notebook) sprechen, entsprechende Terminal-Programme sollte es aber auch für PDA's geben.

• Start des mitgeliefertren Terminal-Programms unter Windows (HyperTerminal)
• Neue Verbindung definieren auf entsprechenden COM-Port mit GPS-Maus (kein Modem wählen, sondern COMx analog zu Einstellung in VisualGPS)
• Anschlußeinstellungen festlegen (4800 Bit/sec, 8N1)

und schon läuft der ASCII-Output der Maus im Terminal-Fenster (Klarschrift der Übertragung). Ein Log-File läßt sich auch einschalten. Da ich eine englische Windows-Version am laufen habe kann ich Dir die genauen Menübefehle nicht sagen (Transfer / Capture Text ...)

Hallo,
leider kann ich mich an der Detailanalyse der LOG-Dateien nicht beteiligen aber

Zitat

Original von pug304

das würde ich so jetzt nicht stehen lassen...

Was spricht hier dagegen ? Kennst Du den Aufbau des RS232-Protokolls ?
Normalerweise ist als Parameter auf den beiden Gegenstellen 8N1 eingestellt
- 1 Startbit (immer fix definiert)
- 8 Datenbit
- No Parity (ggf. 1 zusätzliches Bit bei Even oder Odd)
- 1 Stopbit (ggf. auch 2 möglich)

Wenn man von einer Dreidrahtverbindung (Masse, TxD, RxD) ausgeht muß man auch noch die Bits des Overhead für das Software-Handshake (Xon / Xoff) von Brutto-Übertragungsvolumen abziehen.
Also ca. 460 ASCII-Zeichen / Sec. bei 4800 Baud !!!

Zitat

ich habe nmich mit dem Thema tatsächlich nicht tiefer beschäftigt, aber das würde ich auch bezweifeln! ASCII ist ein Highlevelzeichensatz, der vom Prinzip ausschliesslich zur Visualisierung vom maschinenverständlichen Binärcode dient. Der nmea-Datenstrom ist nun wirklich sehr maschinennah (bzw. mausnah :gap ), es würde technisch gar keinen Sinn machen, so etwas in ASCII-Form umzurechnen und dann zu übertragen!

Wenn jemand nähere Links zum Aufbau vom SIRF-Chipsatz hat bzw. zur Definition des NMEA-Protokolls bzw. deren Übertragung würde mich das sehr interessieren, mal nachlesen, von was wir hier so sprechen....

vg

Bodo

Alles anzeigen

Das NMEA-Protokoll mit seinen Unterprotokollen ist eindeutig ein ASCII-Protokoll. Man kan z.B. mit einem Terminal-Programm auf dem COM-Port die Daten in Klarschrift mitlesen.
Aufbau der Daten siehe z.B. Doku von karomue: HIER
oder auch bei NMEA: HIER
ASCII ein Highlevelzeichensatz ?? Dies ist einer der ältesten Zeichensätze in der EDV überhaupt (ursprünglich 7 Bit aus Amerika).

Im Gegensatz hierzu ist das SIRF-Protokoll ein Binärprotokoll.

Hallo,
zur der ursprünglichen Frage möchte ich mal folgendes einwerfen:
in der PC-Welt kann 4800 Baud mit 4800 Bit/sec. gleichgesetzt werden, da wir bei der Übertragung nur 2 Zustände haben.
Ein Zeichen wird mit 8 Bit übertragen, dazu kommen ein Start- und ein Stopbit. Wenn man jetzt noch den Handshake (Hardware oder Software je nach Geräten) unterschlägt muß man mit 10 Bit pro übertragenem Zeichen rechnen.
Das heißt, das in einer Sekunde max. 480 Zeichen übertragen werden können.
Da das NMEA-Protokoll kein Binär- sondern ein ASCII-Protokoll ist wird eben eine Zahl (z.B. 12,123456) mit 9 ASCII-Zeichen zu je 8 (10) Bit übertragen.
Weiterhin ist zu beachten, das bei jedem empfangenen Zeichen von der COM-Schnittstelle ein Interrupt ausgelöst wird, damit das Programm die Zeichen abholt (haben PDA's FIFO Speicher ?)
Das belastet die NAVI-Applikation, die permanent zum Zeichenabholen unterbrochen wird. Es ist für die Application besser wenn sie sich nicht permanent mit der Abholung der Zeichen am COM-Port beschäftigen muß sondern.

Hallo all,

erst mal vielen Dank für Infos. Habe nun wieder etwas zu lesen

Werde den Versuch demnächst noch mal unter freiem Himmel wiederholen.

Hallo,

es hat den Anschein das es sich um das Gerät MS 4150 RS von VDO Dayton handelt.

Jedenfalls von Aussehen her und vom C-IQ Konzept. Auch die wenigen technischen Daten stimmen überein.

Siehe auch HIER

PS: Bei der Anzeige von Aldi (Nord) fehlt mittlerweile der Hinweis auf die Stiftung Warentest.

Hallo grossmeister,

versuchs mal mit VisualGPS: Hier

Dieses Tool gibt es für Windows als auch für CE. Hat mir bereits gute Dienste geleistet.
LOG-Files (NMEA-Daten) erstellen ist kein Problem. Liefert auch weitere recht nützliche GPS Status-Infos.

Auch dies sieht proffesionell aus:

Hier

Hallo sgroschup,

du hast recht. In den Zeiten wo die Position extrem schwankt ist der H-DOP Wert sehr groß. Bei kleinem H-DOP Wert ist die Position relativ stabil.

Wie läßt sich das erklären ? Was gibt der Wert denn genau an (es sind ja genug Satelitten für die Positionsbestimmung in view) ?

Hallo sgroschup,

im Laufe der Aufzeichnung (ca. 12 Stunden) schwankte die Anzahl der Sat's in use zwischen 3 und 6 (kurzzeitig auch mal 0) und der Sat's in view immer zwischen 7 und 11.
Der HDOP-Wert schwankt zwischen 1,5 und 45 (alle Werte aus GPSTrack).

Was gibt der HDOP-Wert eigentlich an ?