Problem mit der seriellen Kommunikation Arduino Due und Navilock NL-852ETTL

[alexander_ro]

Hier (https://www.roboternetz.de/community/threads/67321-GPS-Embedded-Modul-gesucht/page2) hatte ich ja gefragt nach welchem GPS-Modul da es jetzt mehr um die Programmierung geht habe ich jetzt diesen Thread eröffnet.

Da der DUE über mehrere serielle Schnittstellen verfügt habe ich jetzt mal zum Testen ob mein Programm funktioniert einfach die Daten von seriel 0 über seriel 1 zu seriel 2 und wieder zum PC geleitet das funktionert auch. Zum überprüfen habe ich den serellen Monitor der Arduino IDE benutzt.

So sieht das Programm aus:


void setup()
{
// Serielle Schnittstelle initialsieren
Serial.begin (9600);
Serial1.begin (9600);
Serial2.begin (9600);
}

void loop()
{
if (Serial.available () > 0)
{
Serial1.write (Serial.read ());
}

if (Serial1.available () > 0)
{
Serial2.write (Serial1.read ());
}

if (Serial2.available () > 0)
{
Serial.write (Serial2.read ());
}

}


Ich habe auch mal gemessen an der TX Leitung vom Navilock Modul das sendet laufend Daten die auch ankommen aber leider nicht in irgendwie verwertbarer Form. Ich habe auch mal versucht die Daten von seriel 1 (Navilock) zu seriel 0 (PC) durchzuleiten und dann die Windowssoftware von ublox zu benutzen um mit dem Modul zu arbeiten. Die ublox Software sagt aber nur das es einen Timout gibt beim lesen von dem Modul.



void setup()
{
Serial.begin (38400);
Serial1.begin (34800);
}

void loop()
{
if (Serial.available () > 0)
{
Serial1.write ((char) Serial.read ());
}

if (Serial1.available () > 0)
{
Serial.write ((char) Serial1.read ());
}
}


Hat vielleicht einer eine Idee an was das liegen könnte?

[HeXPloreR]

Hallo alexander_ro,

vielleicht ist es ja sinnvoll bei einer Baudrate (wie z B: 9600) mal zu bleiben. Dann ist es vielleicht sinnvoll einfach mal den Aduino auf einer Schnittstelle (Terminal) das empfangene auszugeben - ohne noch über andere Schnittstellen "versuchen" zu leiten.
Man kann mit einer einzigen Schnittstelle wie TTL-UART (5V -TX/RX) die Daten über RX reinholen und über TX (sofern man z.B. eine virtuelle Com-Schnittstellen hat) an den PC weitergeben, fürs Terminal. Ground nicht vergessen!!
Sonst mal wirklich nur die Schnittstellen benutzen die man benötigt - 1x USB zum PC und 1x UART zum GPS Modul.
Zum Testen der Verbindung einfach mal einen "definierten" String (z.B. hallo) aus dem Arduino-Code senden und ansehen obs ankommt. Dann mit dem GPS Modul verscuhen.
Laut Datenblatt werden die Daten im NMEA-Satz $GPGSA ausgegeben. Man müsste also nicht nur die Schnittstelle auf empfangen Zeichen prüfen, sondern auch anschliessend prüfen welches Zeichen gekommne ist. Den Anfang sollte das "$" Zeichen machen. Ist das angekommen, wird das Anschliessende als String eingelesen, solange bis wieder das $ kommt. Dann Hast du alle Daten zusammen. Jetzt erst kannst Du den String zerlegen und die Daten separieren, umwandeln und weiter damit arbeiten.

Viele Grüße
Jörg

[alexander_ro]

Ich habe verschiedenen Baud Raten ausprobiert und dann leider vergessen das im Source oben wieder auf den gewünschten Wert einzustellen.

Das mit dem Loopback nur am Programmierport (serial 0) hatte ich als erstes probiert. Das mit dem weiterleiten über mehrere Schnittstellen war auch nur ein Experiment um auszuschließen das es am Arduino (seriel 1 od. 2) oder dem Programm liegt. Beide Varianten funktionieren einwandfrei.

Das zweite Programm ist die Version die der gewünschten Funtion entspricht. Also die Daten vom Programmierport (serial 0) zum Navilock (serial 1) hin und zurück leiten. Da das Modul eine 3,3 Volt TTL Schnittstelle hat kann ich es ja nicht direkt am PC verwenden. Mit dem Arduino DUE als konverter sollte eigentlich dann die Software vom Hersteller auch funktionieren.

Wie die NEMA Daten aussehen weiß ich schon nur bekomme ich beim lesen (Arduino seriel Monitor) über die Schnittstelle kaum ASCII Zeichen zu sehen.

Viele Grüße
Alexander

[alexander_ro]

Jetzt funktionierts. Wenn die Hersteller mal brauchbare Doku liefern würden wäre fein. Aber so was kostet halt Geld und Hardware teuer ohne Doku verkaufen gibt mehr Gewinn ... na ja das alte Lied.

In der Doku steht das Modul stellt sich automatisch auf die Baudrate ein tut es aber nicht. :-(
4800 8n1 ist scheinbar die default Einstellung mit der es geht. Jetzt funktioniert auch der Arduino als Konverter zwischen USB und 3,3 Volt TTL seriel.

... :-) ...

[durchgebrannt]

Moment, der einzige Sinn vom Arduino ist gerade, als Konverter zu funktionieren? Wenn dem so ist: ](*,). Für sowas gibt es Pegelwandler. Weiterhin kann man zum Beispiel über einen Timer die Baudrate messen, sofern man kein Oszi zur Verfügung hat. Wenn es dann immernoch eine Plug&Play Lösung sein muss, FT232RL-Breakouts oder vergleichbares gibt es aus China zu Hauf ^^
Gruß Jannis

[alexander_ro]

Ich will Dir ja nun nicht zu nahe tretten aber wenn Du das OK findest das man bei einer Komponete die zumindest mal ca. 100 € kostet dann auch noch selbst die grundlegenden Technischen Parameter ausmessen musst ist das Deine Sache meine ist es nicht. Ganz klar nicht meine Baustelle ...

Ja find ich OK einen ARM 32 BIt 80Mhz Prozessor als Schnittstellen Umsetzer. Wozu soll ich mir einen Konverter bauen oder kaufen wenn der DUE schon da ist? Ausserdem ist er recht fexibel und kann wie in dem Fall auch gleich Schnittstellen Diagnose mit erleichtern hat er ja auch. Bei einem Dummen Konverter ist das nicht möglich.

1,2-1,4 Khz wie viele Baud ist das?

Ausserdem ist es nicht mein Schuld das der Chip Hersteller nur eine Windows Software zum konfigurieren anbietet und keine Module als Source Code die das können. Dann bräuchte ich auch den konverter nicht weil ich dann das Modul nicht an den PC anschließen müsste.

Nach den Start schwierigkeiten macht das Modul aber einen sehr guten Eindruck auch der Empfang ist gut.

Wenn Du jetzt noch wissen willst obwohl Du nicht erst gefragt hast was es werden soll. Der DUE soll noch ein 5" Display mit Touchscreen (wenn ich eins mit guter Qualität finde) bekommen und dann in meinen Fahrzeugen Daten Sammel. Ist mir bekannte das es fertige Lösungen gibt aber ich will wenigstens halbwegs sicher sein das die Daten meine bleiben (bei Handy oder Navi sehr unsicher) und ausserdem soll der noch eine Statistik erstellen zu welchen Zeiten ich auf welchen der Strecken am schnellsten ans Ziel komme. So zu sagen nicht nur ein Routen Ansager sondern ein Routen Berater der dann auch meine Persönlichen vorlieben berücksichtigt das ich im zweifelsfall lieber länger Fahre als Kürzer stehe. Es ist ein Fahrzeug kein Standzeug und stehen nervt gewaltig.

Grüße
Alexander

[durchgebrannt]

[...]Du das OK findest das man bei einer Komponete die zumindest mal ca. 100 € kostet dann auch noch selbst die grundlegenden Technischen Parameter ausmessen musst ist das Deine Sache meine ist es nicht. Ganz klar nicht meine Baustelle ...
Ganz deiner Meinung! Ändert aber an dieser Stelle nichts an der Tatsache, dass die Ermittlung der Baudrate nicht 100% trivial war.

Ja find ich OK einen ARM 32 BIt 80Mhz Prozessor als Schnittstellen Umsetzer. Wozu soll ich mir einen Konverter bauen oder kaufen wenn der DUE schon da ist? Ausserdem ist er recht fexibel und kann wie in dem Fall auch gleich Schnittstellen Diagnose mit erleichtern hat er ja auch. Bei einem Dummen Konverter ist das nicht möglich.
In Kombination mit:

Wenn Du jetzt noch wissen willst obwohl Du nicht erst gefragt hast was es werden soll. Der DUE soll noch ein 5" Display mit Touchscreen (wenn ich eins mit guter Qualität finde) bekommen und dann in meinen Fahrzeugen Daten Sammel.
Da muss ich meine Aussage dann etwas revidieren ;). Dann ist das DUE, oder der ARM an sich, passend und ein einfacher Konverter zweifelsohne nutzlos. Ich habe in deine Aussage hineininterpretiert, dass das DUE nun dauerhaft als Konverter dienen soll. Da war ich wohl etwas Arduino-überkritisch^^.


1,2-1,4 Khz wie viele Baud ist das?
BD=Symbole/Sekunde
Bei 10Bit je Zeichen, 8Datenbits, ein Startbit, ein Stoppbit
=120Symbole/Sekunde=120Bd


Ausserdem ist es nicht mein Schuld das der Chip Hersteller nur eine Windows Software zum konfigurieren anbietet und keine Module als Source Code die das können. Dann bräuchte ich auch den konverter nicht weil ich dann das Modul nicht an den PC anschließen müsste.
Aus dem selben Grund liegt hier auch noch ein Modul, wo ich das Konfigurationsprotokoll mal ausspähen muss ^^.

Einen schönen Abend noch,
Gruß Jannis ;)

[alexander_ro]

Die Frequenz Messung an seriellen Daten ist schwierig. Ich hatte mit meinem Oszi die ca. 1,4 Khz gemessen und kam auf ein ähnliches Ergebnis wie Du nur ist das halt sehr weit von den 4800 entfernt die es dann tatsächlich waren. Vielleicht hängt das auch irgendwie mit der angeblichen automatischen Baudraten Ermittlung zusammen. Ich kenne jetzt nicht wirklich die letzten Implemtierungsdetails der Abwicklung. Vermute aber mal das irgendwas nicht so kompatibel ist wie es sein sollte.

Wenn es ein ublox Chip oder Navilock Modul ist dann kannst Du die Protokoll Beschreibung von denen bekommen. Im ersten Posting oben auf das hier klicken. Da gibs einen Beitrag von mir mit einem Link zur ublox Protokollbeschreibung also für mein Modul zumindest. Mir war das aber jetzt im ersten Anlauf zu Aufwändig das alles nur für die Konfiguration zu Programmieren. Erst mal die NEMA Daten für meine Zwecke auswerten. Alles andere kann man später machen.

[Peter(TOO)]

Hallo,

Die Frequenz Messung an seriellen Daten ist schwierig. Ich hatte mit meinem Oszi die ca. 1,4 Khz gemessen und kam auf ein ähnliches Ergebnis wie Du nur ist das halt sehr weit von den 4800 entfernt die es dann tatsächlich waren.
Man misst da auch nicht die Frequenz!
Je nachdem welche Daten versendet werden, bekommt man da ganz unterschiedliche Werte!

Man misst die Zeit für eine Bitzelle!
Bei ASCII-Werten kann man meist das Startbit recht gut erkennen. Je nachdem welche Werte gesendet werden, findet man noch ganzzahlige Vielfache einer Bitzelle.

4'800Bit/s ergibt dann etwas um die 208µs für eine Bitzelle.

Übrigens, mit Bit/s und Baud muss man sehr vorsichtig umgehen, diese haben, per Definition, nicht immer die selben Werte.
Bei einer RS232 sind sie identisch.
Bei einer Centronis-Schnittstelle ist die Baudrate dann aber 8x Kleiner als Bit/s, da mit jedem Takt 8 Bit übertragen werden.

Die Baudrate ist aber der wichtige Parameter um die Bandbreite der Übertragungsstrecke zu bestimmen.
Die alten Telefonmodem hatten keine Baudrate über 2'400 Baud, da eine analoge Telefonleitung nur eine maximale Frequenz von 3'500Hz garantiert. Durch Modulationsverfahren mit z.B. 64 unterschiedlichen Zuständen, können aber dann 8 Bit gleichzeitig übertragen werden. Dadurch ergeben dann 2'400 Baut = 19'200Bit/s.

MfG Peter(TOO)

[alexander_ro]

Man misst die Zeit für eine Bitzelle!

Klingt für mich sehr nach Frequenzmessung ... :-)
Hast Du schon recht damit aber das habe ich nicht hin bekommen. Weil mir irgendwie die Triggerung auf das Signal nicht richtig gelungen ist und wenn die Darstellung immer in der gegend herumwandert ist das mit dem Kästchenzählen nicht einfach und schon gar nicht wenn man die an einer bestimmten stelle im Signal zählen sollte. Bräuchte man so ein Digital Oszi mit den ganzen Software Optionen die können dann Schnittstellen analysieren. Man könnte auch die TX Leitung des GPS Moduls an einen normalen GPIO hängen und dann die analyze mit einem kleinen Programm selber auf dem Arduino DUE machen der ist schnell genug dafür aber das war mir zu viel arbeit.



4'800Bit/s ergibt dann etwas um die 208µs für eine Bitzelle.

Wie hast Du das denn ausgerechnet?



Bei einer Centronis-Schnittstelle ist die Baudrate dann aber 8x Kleiner als Bit/s, da mit jedem Takt 8 Bit übertragen werden.

Mir kommt es so vor als ob Du hier Gemüse mit Obst vergleichst ... ;-)
... serielle und parallele Daten Übertragung ...

[PICture]

Hallo!

Fürs Beobachten einer Dataleitung von COM Schnittstelle auf einem analogem Oszi würde ich empfehlen bei horizontaler Ablenkung zum Triggern "single" bzw. "one shot" verwenden und die "time/div" so einstellen, dass auf dem Bildschirm nur ein Byte sichtbar ist. Dann sieht man sogar sich ändernde Bits. ;)

[Klebwax]

Klingt für mich sehr nach Frequenzmessung ... :-)

Und was kommt wohl für eine Frequenz heraus, wenn 2 aufeinanderfolgende Bits den gleichen Wert haben, oder auch drei? Und was wenn der Abstand zwischen den Bytes mal variiert?

MfG Klebwax

[PICture]

Ich würde über feste Frequenz nur am Clockleitung reden, weil es sonst sinnlos ist.

[alexander_ro]

An aufeinander folgenden gleichen Bits kannst Du auch keine Baudrate bestimmen. Aber nur weil ich einen Teil aus einem Signal herausgreife um dessen Timing zu ermitteln ist es trotzdem nichts anderes als die Bestimmung der Frequenz. Eine Frequenz auf einer Leitung muss nicht statisch sein. Ist aber halt dann auch nicht mit einem normalen Frequenzzähler zu messen. Es ging um die Bestimmung einer Bit-Zelle nicht um Bytes.

Selbst die Baud Angabe ist ja nichts anderes als eine Frequenzangabe. 4800 Bit pro Sekunde. Die Definition entspricht halt nicht dem Herz. Aber die Definitionen sind völlig willkürlich von Menschen gemacht um Vorgänge beschreiben zu können oder um damit rechnen zu können.

Clockleitung gibts hier keine nur TX RX und GND. Wäre der Takt auf der CLOCK Leitung eigentlich abhängig von der Baudrate?

[PICture]

Clockleitung gibts hier keine nur TX RX und GND.

Stimmt. Ich habe Taktgenerator beim Senden gemeint, der die Bits an TX schiebt. Der Taktgenerator beim Empfangen muss gleiche Frequenz haben und mindestens innerhalb eines Bytes synchron mit sendendem laufen, damit die am RX empfangene Bits richtig ausgewertet werden.


Wäre der Takt auf der CLOCK Leitung eigentlich abhängig von der Baudrate?

Natürlich, weil jeder Takt (CLOCK Impuls) einer Übertragung von einem Bit entspricht. ;)

[Peter(TOO)]

Klingt für mich sehr nach Frequenzmessung ... :-)
Hast Du schon recht damit aber das habe ich nicht hin bekommen. Weil mir irgendwie die Triggerung auf das Signal nicht richtig gelungen ist und wenn die Darstellung immer in der gegend herumwandert ist das mit dem Kästchenzählen nicht einfach und schon gar nicht wenn man die an einer bestimmten stelle im Signal zählen sollte. Bräuchte man so ein Digital Oszi mit den ganzen Software Optionen die können dann Schnittstellen analysieren. Man könnte auch die TX Leitung des GPS Moduls an einen normalen GPIO hängen und dann die analyze mit einem kleinen Programm selber auf dem Arduino DUE machen der ist schnell genug dafür aber das war mir zu viel arbeit.


Wie hast Du das denn ausgerechnet?

1s/4'800 ~ 208µs
Schauen wir mal was da bei RS232 über die Leitung geht:


StartBit StopBit
| |
V V
+-+
... | | ... Data = 0x00
--+ +-+-+-+-+-+-+-+-+-+---

->|-|<-- BitZelle (~208µs @ 4'800 Bit/s)


+-+-+-+-+-+-+-+-+-+
... | | ... Data = 0xFF
--+ +-+---

+-+ +-+ +-+ +-+ +-+
... | | | | | | | | | | ... Data = 0x55
--+ +-+ +-+ +-+ +-+ +-+---


Jetzt miss da mal die Frequenz mit einem normalen Frequenzmesser!
Dieser misst eigentlich die Anzahl Impulse über eine Sekunde.
Hinzu kommt noch, dass die Pause zwischen Stop- und Startbit Minimal 0 ist und maximal gegen unendlich gehen darf.


Mir kommt es so vor als ob Du hier Gemüse mit Obst vergleichst ... ;-)
... serielle und parallele Daten Übertragung ...
Das spielt bei Baud gar keine Rolle.
Zudem spielt es keine Rolle ob ich nun 8 Datenleitungen verwende oder eine Datenleitung und auf dieser mit 256 unterschiedlichen Pegeln arbeite.
Baud bezeichnet die Anzahl Zustandswechsel pro Sekunde der Schnittstelle. Jetzt kommt es aber auf die Schnittstellendefinition an, wie viele Bits pro Zustandswechsel übertragen werden. Man kann dabei auf einer Leitung mit mehr als zwei Zuständen arbeiten oder mit mehreren Leitungen oder auch beide kombinieren!
https://de.wikipedia.org/wiki/Baud

Schau dir mal an, wie das GigaBit Ethernet funktioniert:
Die Datenrate ist 1Gbit/s die Baudrate aber nur 125MBaud und es werden zwei Aderpaare in jede Richtung verwendet. Die nötige Bandbreite betraägt dann pro Adernpaar 62.5 MHz.
https://de.wikipedia.org/wiki/Ethernet#Gigabit-Ethernet

So einfach ist das mit Bit/s und Baud ;-)

Bei der seriellen Übertragung gibt es zwei Methoden: synchron und asynchron.

Bei der synchronen Übertragung wird der Takt mit übertragen. Dies kann über eine zusätzliche Clock-Leitung geschehen oder der Takt kann aus dem Datenstrom gewonnen werden. Hierbei kann der Takt variabel sein.

Bei der asynchronen Übertragung (RS232 gehört dazu) wird die Taktinformation nicht mit übertragen. Sender und Empfänger brauche jeweils einen eigenen Taktgenerator, welche empfängerseitig mit dem Sender synchronisiert wird.
Ein UART für RS232 arbeitet typisch mit der 16-fachen Bitrate. Mit der Flanke des StartBits wird dann der Zähler auf 8 gesetzt. Bei einem Zählerstand von 16 wird dann immer der Wert von der Daten-Leitung eingelesen, was dann immer in der Mitte einer Bitzelle geschieht und der Zähler wieder auf 1 gesetzt.

MfG Peter(TOO)

[alexander_ro]

Danke für die Erklärung alles wusste ich davon noch nicht. Aber bei allem will ich Dir nun auch nicht recht geben ... :-)

Ja 1/4800 ist mir dann auch aufgefallen. Da hatte ich aber die Frage schon geschrieben.



Jetzt miss da mal die Frequenz mit einem normalen Frequenzmesser!

In irgendeinem meiner vorherigen Beiträge steht das es schwierig ist. Es geht mit Frequenzmessung nur wenn man die an einem Teilabschnitt des Signals macht. Etwas bessere Digital Oszi die können dann erstens das Signal brauchbar Trigger und mit Cursormessung ist es ein leichtes den gesuchten Wert zu ermitteln. Ich hatte da aber nur so ein günstiges Teil zum Messen das mehr ein Multimeter als ein Oszi ist. Mein zwar Uraltes Fluke ist die Stromversorgung kaputt. Das hätte aber die nötigen Funktionen. Alternativ wenn man nicht weiss was man mit seiner Zeit anfangen soll könnte mit ein bisschen Programmieren das auch der Arduino DUE messen.

Da wir bei den Baudraten wenn ich den Text richtig verstanden habe die physikalischen Signale auf einer Datenleitung einer seriellen und einer paralellen betrachtet haben sind die unterschiedlich wenn beide Daten mit der gleichen Geschwindigkeit übertragen. Den Vergleich finde ich aber trotzdem nicht ganz passend. Im übrigen übertragen die beiden genannten Schnittstellen ihre Daten nicht mit 256 zuständen. Aber sowas ist möglich da hast Du schon recht.