Sehr geehrtes allwissenden Mikrocontroller Forum, ich habe ein Problem, vielleicht hat jemand hier eine Lösungsidee. Ich möchte insgesamt acht Honeywell HMC5983 http://www51.honeywell.com/aero/common/documents/myaerospacecatalog-documents/Defense_Brochures-documents/HMC5983_3_Axis_Compass_IC.pdf mit einem NI MYRIO auslesen. Die Sensoren habe ich auf einem Breakout-Board gekauft und werden per SPI ausgelesen: http://www.drotek.fr/ftp/schema/hmc5983.PDF Das Breakout Board habe ich mit einer RJ45 Buchse verlötet um die Sensoren schlussendlich mit Ethernet Kabeln an das MYRIO anzuschließen. Ein Sensor an Kabel an MYRIO funktioniert auch ohne Probleme. Um zwei Sensoren an den MYRIO anzuschließen habe ich eine zweite RJ45 Buchse mit dem MYRIO verbunden. Die MOSI/MISO/SCLK und Stromversorgung sind mit beiden RJ45 Buchsen verbunden, ein Chip Select wird jeweils seperat verwendet. Verbinde ich jetzt ein zweites Ethernet Kabel mit dem MYRIO (auch ohne Sensor!) funktioniert die Kommunikation nicht mehr zuverlässig. Angehägt sind zwei Scope traces, einmal ohne zweites Kabel, einmal mit. (D0: SCLK, D1: MOSI, D2: MISO, D3: CS) Sachen die ich probiert habe: - Trenne ich die SCLK Leitung von dem zweiten Kabel funktioniert es wieder ohne Probleme. - Parallel geschaltete Kondensatoren (zum Beispiel zwischen Clock und GND Supply und GND) haben das Problem nicht behoben. Vielen Dank schonmal, Andreas
Angehängte Dateien:
-
w_2nd_cable.png
5,8 KB -
wo_2nd_cable.png
5,9 KB
Nimm doch mal die analogen Kanäle Deines Oszis und mach damit Bildchen. Andreas schrieb: > - Parallel geschaltete Kondensatoren (zum Beispiel zwischen Clock und > GND Supply und GND) haben das Problem nicht behoben. Vielleich ist es genau anders herum. Die Kapazität ist zu groß für die Ausgangstreiber. Probiers doch mal mit einem langsameren Takt.
Von welchen Leitungslängen und welchem SPI-Takt reden wir hier?
Ein SPI Bus ist nicht wirklich fuer Kabel vorgesehen, sondern nur fuer auf einer Leiterplatte. Ohne Kabel dazwischen. Bei einem Kabel geht das Signal ja per Signal Leiter weg, und kommt per GND Leiter wieder zurueck. Dabei kann es Reflexionen geben, GND Bounce und so. Allenfalls mit 100 Ohm Seriewiderstand auf der anderen Seite betreiben. Schau dir die Signale doch mal mit einem Analogkanal auf der anderen Seite an.
Andreas schrieb: > Angehägt sind zwei Scope traces Die sind aber arg binär. Wie sehen die Signale in analoger Darstellung aus? Insgesamt ist es aber nicht schlimm, die "Störungen" kommen immer an der fallenden Taktflanke. Offenbar ist da der Treiber ein wenig stärker und du bekommst Ground-Bouncing. Das wäre alles kein Problem, wenn du mit der steigenden Flanke die Daten übernehmen würdest. Probier einfach mal die anderen drei SPI-Modes aus...
Angehängte Dateien:
-
w_2nd_MOSI.png
11 KB -
wo_2nd_MOSI.png
11 KB
Danke für die vielen und schnellen Antworten. Anbei mal zwei Bilder mit dem MOSI analog Trace, mit und ohne Kabel. Abgegegriffen vom Sensor, also hinter dem Kabel. - Langsamere SPI Taktraten habe ich probiert, ändert überhaupt nichts. Macht ja auch sinn, da die Flanken, wo offensichtlich die Störungen passieren dadruch nicht weniger steil werden. - Momentan läuft SPI auf 10 KHz. - Die Kabel sind 3 m lang. @lkmiller: Was meinst du mit anderen SPI modi? Clock Polaritiy und ob der das auf der steigenden oder fallenden Flanke liest? Das ist leider duch den Sensor vorgegeben. @jetztnicht: Was meinst du mit 100 Ohm "auf der anderen Seite"?
Jetzt N. schrieb: > Ein SPI Bus ist nicht wirklich fuer Kabel vorgesehen, sondern nur > fuer > auf einer Leiterplatte. Ohne Kabel dazwischen. > > Bei einem Kabel geht das Signal ja per Signal Leiter weg, und kommt per > GND Leiter wieder zurueck. Dabei kann es Reflexionen geben, GND Bounce > und so. Allenfalls mit 100 Ohm Seriewiderstand auf der anderen Seite > betreiben. > > Schau dir die Signale doch mal mit einem Analogkanal auf der anderen > Seite an. Geht das denn überhaupt? Wenn ja, mit etwa welche Kabellängen? Es wäre schon sehr gut wenn es so gehen würde, da ich am Ort wo die Sensoren hinsollen nicht so wirklich viel platz habe. Ansonsgten muss ich an jeden Sensor noch einen Mikrocontroller dödeln.
Schau dir mal bitte die Flanke vom SPI-Takt an. In viel größerer Auflösung. Die Teilnehmer arbeiten mit den Flanken des SPI-Takt. Wenn die Flanke des Taktes aufgrund von z.B. Reflexionen eine "Delle" hat, kann sein, dass zweimal die Schaltschwelle des Eingangs des Slave durchschritten wird und er somit zwei Taktflanken sieht. Das bringt natürlich die Statemachine des Slave komplett außer Tritt.
Andreas schrieb: > Geht das denn überhaupt? Nennt sich Serienterminierung. Sieh dir einfach mal den Beitrag "Re: Signalproblem bei langem Kabel" an... > Wenn ja, mit etwa welche Kabellängen? Mit allen. Aber warum schreibst nicht einfach mal du, wie lange deine Kabel sind?
Angehängte Dateien:
-
wo_2nd_SCLK_falling_2.png
7,9 KB -
w_2nd_SCLK_falling.png
9,7 KB
Schlumpf schrieb: > Schau dir mal bitte die Flanke vom SPI-Takt an. > In viel größerer Auflösung. > Die Teilnehmer arbeiten mit den Flanken des SPI-Takt. > Wenn die Flanke des Taktes aufgrund von z.B. Reflexionen eine "Delle" > hat, kann sein, dass zweimal die Schaltschwelle des Eingangs des Slave > durchschritten wird und er somit zwei Taktflanken sieht. > Das bringt natürlich die Statemachine des Slave komplett außer Tritt. Das sieht doch sehr danach aus. Auf der fallenden Flanke habe ich überschwinger bis zu 1.9 Volt. Leider habe ich im Datenblatt den Sensors garnicht gefunden was für eine Logik der verwendet, aber 1.9 Volt sollte schon kritisch sein.
Lothar M. schrieb: > Andreas schrieb: >> Geht das denn überhaupt? > Nennt sich Serienterminierung. Sieh dir einfach mal den > Beitrag "Re: Signalproblem bei langem Kabel" an... > >> Wenn ja, mit etwa welche Kabellängen? > Mit allen. > Aber warum schreibst nicht einfach mal du, wie lange deine Kabel sind? Habe ich oben gemacht, 3 meter.
Schlumpf schrieb: > Die Teilnehmer arbeiten mit den Flanken des SPI-Takt. > Wenn die Flanke des Taktes aufgrund von z.B. Reflexionen eine "Delle" > hat, kann sein, dass zweimal die Schaltschwelle des Eingangs des Slave > durchschritten wird und er somit zwei Taktflanken sieht. Meist ist das Problem viel einfacher: es wird mit der falschen Taktflanke eingelesen. Durch diese und jene Gatterlaufzeiten und Kapazitäten funktioniert das so gerade und wird deswegen niemals hinterfragt. Dann ändert sich irgenwas, eine geshrinkter, schnellerer Chip oder halt ein zusätzlicher Slave, und schon fängt der übersehene Fehler an, seine Wirkung zu zeigen. Oft genug erlebt MfG Klaus
Angehängte Dateien:
-
HMC5983_SPI.png
32 KB
Andreas schrieb: > Das sieht doch sehr danach aus. Könnte natürlich auch der "Wer Mist misst, misst Mist!" Effekt sein. Wie sieht dein Messaufbau aus? Wo sind die Massekabel wie angeklemmt? Klaus schrieb: > es wird mit der falschen Taktflanke eingelesen. Scheint zu passen. Allerdings ist zum Abtastzeitpunkt (steigende Flanke) das Signal doch eigentlich stabil. Aber der Slave-Select kommt arg knapp vor dem ersten Takt... Andreas schrieb: > Verbinde ich jetzt ein zweites Ethernet Kabel mit dem MYRIO (auch ohne > Sensor!) funktioniert die Kommunikation nicht mehr zuverlässig. Was passiert dann? Und was erwartest du stattdessen? Ist die Kommunikation nur immer flasch oder ab&zu gestört? Oder passt eigentlich alles, ist aber um 1 Bit "verschoben"?
Lothar M. schrieb: > Andreas schrieb: >> Das sieht doch sehr danach aus. > Könnte natürlich auch der "Wer Mist misst, misst Mist!" Effekt sein. > Wie sieht dein Messaufbau aus? > Wo sind die Massekabel wie angeklemmt? Ich habe die Signale direkt beim Sensor mit zwei Hirschmann Klemmen zwischen SCLK und GND abgegriffen. > Klaus schrieb: >> es wird mit der falschen Taktflanke eingelesen. > Scheint zu passen. Allerdings ist zum Abtastzeitpunkt (steigende Flanke) > das Signal doch eigentlich stabil. > Aber der Slave-Select kommt arg knapp vor dem ersten Takt... Hatte ich auch mal einen Delay eingebaut, das hatte nichts geändert. Ist allerdings schon etwas her. Könnte ich nochmal probieren. > Andreas schrieb: >> Verbinde ich jetzt ein zweites Ethernet Kabel mit dem MYRIO (auch ohne >> Sensor!) funktioniert die Kommunikation nicht mehr zuverlässig. > Was passiert dann? Und was erwartest du stattdessen? > Ist die Kommunikation nur immer flasch oder ab&zu gestört? > Oder passt eigentlich alles, ist aber um 1 Bit "verschoben"? Durch diese Spikes die du in dem MISO Signal, soweit ich das sehe, immer wenn eine fallende Flanke der Clock kommt. Gucke mir das gleich nochmal genauer an. Eigentlich würde ich erwarten das erstmal nichts passiert wenn ich den zweiten Sensor anschließe. Da der CS die ganze Zeit high sein sollte. Wenn ich nur das Kabel anschließe würde ich auch denken das nichts passierten sollte.
Andreas schrieb: > Das sieht doch sehr danach aus. Auf der fallenden Flanke habe ich > überschwinger bis zu 1.9 Volt. Leider habe ich im Datenblatt den Sensors > garnicht gefunden was für eine Logik der verwendet, aber 1.9 Volt sollte > schon kritisch sein. Das ist definitiv kritisch. Mit diesen Überschwingern bringst du das SPI garantiert aus dem Tritt. Also die müssen erstmal weg. Kurze Abhilfe kann sein: Längswiderstand in die Taktleitung, der zusammen mit der Eingangskapazität des Empfängers einen Filter bildet. Oder gleich nen kleinen RC-Filter auf die Taktleitung setzen. Damit bekommst du die Störungen weg. Besser wäre es aber, du beseitigst gleich die Ursache der Störungen (z.B. nicht angepasste Leitungen, falls das die Ursache ist) Aber wenn du die Ursache nicht in den Griff bekommst, dann kannst du nur filtern. Und wenn das Filter lahm genug eingestellt werden muss, dann musst du eben entsprechend mit der Datenrate runter.
Andreas schrieb: > Das Breakout Board habe ich mit einer RJ45 Buchse verlötet um die > Sensoren schlussendlich mit Ethernet Kabeln an das MYRIO anzuschließen. RJ45-Kabel sind paarig verseilt, da kannst Du keine einphasigen Signale übertragen, sondern nur differentiell. Nimm RS-485 Treiber/Empfänger, dann geht auch SPI.
Du hast Reflektionen auf den Leitungen, SPI eignet sich nicht für längere Kabel. Ein paar cm über Flachbandkabel in einem Gerät geht meist noch ganz gut, dann wird es doof. Ich würde dir als ordentliche Lösung dringend raten pro Sensor (bzw. Messort) einen µC zu nehmen und den auf ein geeignetes Bussystem umsetzen zu lassen, CAN z.B. Da gibt es auch kleine µC die schon einen CAN-Controller drin haben, da braucht's dann nur noch einen Treiber (SO8). Mfg Bimbo385 PS: Selbst die Tastköpfe können deine Messungen hier schon verfälschen. Reflektionen aufzuzeichnen ist eher schwierig. Edit: Die Idee von Peter mit den RS485 Treibern ist auch nicht verkehrt. Funktioniert höchstwahrscheinlich ziemlich gut.
:
Bearbeitet durch User
Peter D. schrieb: > RJ45-Kabel sind paarig verseilt Richtig, da hatte ich auch schon ein ungutes Gefühl... > da kannst Du keine einphasigen Signale > übertragen, sondern nur differentiell. Es geht schon, wenn der Partner immer Masse ist. Wenn aber z.B. der MISO mit dem CLK verseilt ist, dann kann der da prima übersprechen...
Lothar M. schrieb: > Peter D. schrieb: >> RJ45-Kabel sind paarig verseilt > Richtig, da hatte ich auch schon ein ungutes Gefühl... >> da kannst Du keine einphasigen Signale >> übertragen, sondern nur differentiell. > Es geht schon, wenn der Partner immer Masse ist. Wenn aber z.B. der MISO > mit dem CLK verseilt ist, dann kann der da prima übersprechen... Das war auch schon eine Befürchtung von mir. Ich hatte dann die Verkabelung um einen Pin verschoben, und damit demnach auch die Paarungen geändert. Das hatte aber auch nicht geholfen. RS485 Treiber gucke ich mir nächste Woche mal an wenn ich wieder bei der Arbeit bin. Vielen Dank für den Tipp!
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.