Hallo, kennt jemand von euch einen Sensor, der das "extended serial message format" oder das "short serial message format" der SENT-Spezifikation benutzt? gruß
Im Automotive Umfeld wird SENT immer öfter eingesetzt. Von Bosch habe ich schon Drucksensoren mit Slow Channel gesehen. Gibt auch schon Controller mit SENT Sender, zb S12Z. Grüße
me schrieb: > Im Automotive Umfeld wird SENT immer öfter eingesetzt. Von Bosch > habe > ich schon Drucksensoren mit Slow Channel gesehen. Gibt auch schon > Controller mit SENT Sender, zb S12Z. > > Grüße Danke erstmal. Das es im Automotive Bereich verwendet wird, wusste ich. Ich bin/war allerdings auf der Suche nach Sensoren die den Slow Modus nutzen, hab halt bis jetzt noch nix gefunden. Danke schonmal. P.S. das AppNote vom S12Z zu SENT gelesen -> kein Slow Channel
Genügt dir irgendein Sensor, oder wo führt das hin? Das Interface von Kopf kann auf jeden Fall alle 3 slow-channel typen. Von Vector gibt es ein VT-Modul. Grüße
Ich musste das noch nicht machen, könnte aber in die Verlegenheit kommen und habe da bisher nur wage über die Specs drüber geschaut. Wie implementiert man SENT auf einem MikroController? Einen Transceiver gibt es dafür nicht, oder? Also müsste man wohl per Input-Capture die Zeiten ausmessen? Das klingt aber danach als wäre das anfällig gegen Stör-Impulse.
Rudolph R. schrieb: > Wie implementiert man SENT auf einem MikroController? Senden: kann man mit etwas wackeln an den Pins realisieren. Empfangen: man nimmt einen Prozessor der das in Hardware implementiert hat: http://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-tm-microcontroller/aurix-tm-family/aurix-tm-family-%E2%80%93-tc29xtx/channel.html?channel=db3a30434422e00e014426454e2b3d81 Alternativ hat man halt eine hohe Rechenlast. Gruß Anja
Kann ich bestätigen, eine Implementierung mit Input-Compare kostet viel Laufzeit. Ext. Trcv ist nicht notwendig. Der MPC Panther hat auch einen SENT Receiver. Grüße
Gabi schrieb: > Hallo Senex, > was ist denn der Hintergrund deiner Frage? me schrieb: > Genügt dir irgendein Sensor, oder wo führt das hin? Das Interface > von > Kopf kann auf jeden Fall alle 3 slow-channel typen. Von Vector gibt es > ein VT-Modul. > > Grüße Mir geht es ganz allgemein um die Frage: Gibt es denn schon Sensoren die die beiden Slow-Channel Nachrichtentypen(also short und enhanced message format der Spec). Einfach ganz allgemein, wenn irgendjemand ein Sensor bekannt ist, der so Daten überträgt, dann her damit.(mich würde hauptsächlich interessieren welche Datentypen über den Slow-Channel übertragen werden). P.S. In SW lösen ist wohl sehr unperformant, das stimmt. Aber das ist bei jedem Protokoll so(CAN,LIN, etc.)
Okay, ich hatte eigentlich den Eindruck, dass SENT sehr billig sein soll, quasi noch unterhalb von LIN. Wenn man dafür einen speziellen Controller benötigt widerspricht das der Idee ja schon etwas. Gibt es denn sowas wie einen SENT Transceiver? Mit dem Begriff "SENT" Google zu füttern bringt ja offensichtlich nicht wirklich viel. Edit: hab garnicht reingesehen, aber ROFL für den AURIX, 300 MHz und drei 32 Bit Kerne passt so richtig gut zu einfach und billig :-)
:
Bearbeitet durch User
Ein Datenblatt hab ich nicht zur hand, aber typischerweise sind die slow-channel Nachrichten Logistik Daten wie Seriennummer, Hersteller, ... und Status Informationen wie Fehlercodes. Je nach Format dauert es ja auch 16 Frames, bis man eine slow-channel Nachricht empfängt und dementsprechend lange.
Rudolph R. schrieb: > Okay, ich hatte eigentlich den Eindruck, dass SENT sehr billig > sein > soll, quasi noch unterhalb von LIN. > Wenn man dafür einen speziellen Controller benötigt widerspricht das der > Idee ja schon etwas. > > Gibt es denn sowas wie einen SENT Transceiver? > Mit dem Begriff "SENT" Google zu füttern bringt ja offensichtlich nicht > wirklich viel. > > Edit: hab garnicht reingesehen, aber ROFL für den AURIX, 300 MHz und > drei 32 Bit Kerne passt so richtig gut zu einfach und billig :-) Die Idee ist, das dein Sensor einen eingebauten Transeiver hat und dann die Daten, gleich digitalisiert, an die ECU weitergibt. Ist auch kein Bus wie LIN, braucht es aber auch gar nicht zu sein. Soll da eingesetzt werden, wo ich zwar Sensordaten an eine ECU schicken will, aber ein Bus keinen Sinn macht, oder zu aufwendig wäre. Mehr sowas wie "UART" aber halt nicht auf einer ECU, sondern zwischen ECU und Sensor me schrieb: > Ein Datenblatt hab ich nicht zur hand, aber typischerweise sind > die > slow-channel Nachrichten Logistik Daten wie Seriennummer, Hersteller, > ... und Status Informationen wie Fehlercodes. Je nach Format dauert es > ja auch 16 Frames, bis man eine slow-channel Nachricht empfängt und > dementsprechend lange. Ich hab ein Datenblatt da, aber das muss man ja leider lizensieren. Ja mir gings eher um die Anwendung, die Spec kenn ich ;) (16 oder 18 Bit SENT-Frames umd "serielle" Daten zu verschicken)
me schrieb: > Ein Datenblatt hab ich nicht zur hand, aber typischerweise sind die > slow-channel Nachrichten Logistik Daten wie Seriennummer, Hersteller, > ... und Status Informationen wie Fehlercodes. ...und typischerweise will man auch nicht dass da zu viele Informationen übertragen werden, sonst wird gegenüber "Der Behörde" (CARB) aus dem "einfachen Sensor" schnell mal ein "Steuergerät" mit all seinen zusätzlichen Aufwänden aus OBD-Sicht. senex schrieb: > Die Idee ist, das dein Sensor einen eingebauten Transeiver hat und dann > die Daten, gleich digitalisiert, an die ECU weitergibt. Da ist man mittlerweile deutlich weiter, auch bei den analogen Sensoren (mal abgesehen von einfachen NTC's o.ä.). Die Signalverarbeitung erfolgt komplett digital im Sensor, bei den analogen Sensoren wird zum Schluss DA-gewandelt. Und hier ist der entscheidende Vorteil der SENT-Schnittstelle: die DA-Wandlung entfällt und man umgeht die ungenaue/fehleranfällige analoge Übertragung.
Rudolph R. schrieb: > Okay, ich hatte eigentlich den Eindruck, dass SENT sehr billig sein > soll, quasi noch unterhalb von LIN. > Wenn man dafür einen speziellen Controller benötigt widerspricht das der > Idee ja schon etwas. Ist kein Widerspruch da es immer eine unidirektionale Übertragung vom Sensor zum Prozessor ist. Der Sensor wird sehr billig (RC-Oszillator ohne Temperaturkompensation reicht aus). Der Aufwand steckt im Steuergerät (Decodierung mit Kalibrierung). Außerdem spart man grundsätzlich Leitungen und Steuergerätepins ohne daß Sicherheitskriterien verletzt werden. (Verfügbarkeit ist ein anderes Thema). Fahrpedal 3 anstelle 5-6 Leitungen für 2 kanaligen redundanden Sensor. Drosselklappe Positionssensor dto. Luftmassenmesser 3 anstelle 4 Leitungen für Temperatur und Luftmasse. usw. Gruß Anja
senex schrieb: > Die Idee ist, das dein Sensor einen eingebauten Transeiver hat der Sensor hat nur einen Sender = kurzschlußgeschützter open collector oder open drain. Der Empfänger ist ein (gefilterter) normaler Digitaleingang. Gruß Anja
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.