Hallo, Der Titel sagt eigentlich schon alles. :) Beim Spielen mit Kindern über die Weihnachtsfeiertage steht die Gravitrax Bahn hoch im Kurs. Seit kurzem haben wir auch dieses Gravitrax Power Set mit Fernbedienung, Kugel-Starter und Kugel-Trigger: https://www.ravensburger.de/de-AT/entdecken/gravitrax/gravitrax-power Jetzt würden mir da Selbstgebastelte Erweiterungen einfallen. Bspw. eine Stoppuhr mit Mikrocontroller und Display, welche die Laufzeit anzeigt. Dafür sollte es theoretisch ausreichen, für's erste die Funksignale mit zu hören. Wäre auch ein nettes Bastelprojekt gemeinsam mit den Kids. Dafür wäre natürlich fein das Gravitrax Funkprotokoll zu kennen - oder erstmal natürlich die Funkfrequenz (um überaupt abschätzen zu können, welche Funkmodule da in Frage kommen). Auf den Geräten/Verpackung bin ich nicht fündig geworden. Google Suche brachte auch noch keine Erkenntnisse. Aufschrauben und verbaute Hardware prüfen ist gerade keine Option, da ich für die verwendeten Schrauben keinen passenden Bit/Schraubendreher habe. Alternativ: wie kann man die Funkfrequenz herausfinden? Spektrumanalyzer hab ich leider keinen. Nur Standard equipment für eher digitale Elektronikbasteleien und ein Oszi. Mit Funk hab ich noch nicht nicht viel gemacht - Funkstrecke mit RFM68 war das einzige bisher. Hab das Gefühl, das wird eher schwierig. Daher mal die Frage in diese Runde: hat irgendwer Erfahrung mit Gravitrax Funk und hat irgendwelche sachdienlichen Hinweise? Danke schon mal! vG Alram
Wenn ein SDR-Stick vorhanden ist damit erstmal die Frequenzen 433 und 868MHz absuchen. Damit hab ich auch schon einige Frequenzen herausbekommen, ohne das jeweilige Gerät aufzuschrauben.
Alram L. schrieb: > Alternativ: wie kann man die Funkfrequenz herausfinden? Ins Handbuch gucken. Maximale Hochfrequenzleistung (HF-Leistung): < 10 dBm Frequenzbereich: 2400-2483,5 MHz Quelle: https://manuals.plus/de/ravensburger/gravitrax-power-element-connect-interactive-track-system-manual Könnte z.B. Bluetooth (LE) sein.
Klaus schrieb: > https://fcc.report/FCC-ID/2A2XI589 Da sie dort zwischen "Bluetooth Transmitter" und "2.4GHz GFSK-Transmitter" unterscheiden, wird wohl für die Smartphone-Kommunikation Bluetooth (LE) benutzt, intern ein (ebenfalls GFSK-basiertes) eigenes Protokoll.
Hmmm schrieb: > Da sie dort zwischen "Bluetooth Transmitter" und "2.4GHz > GFSK-Transmitter" unterscheiden, wird wohl für die > Smartphone-Kommunikation Bluetooth (LE) benutzt, intern ein (ebenfalls > GFSK-basiertes) eigenes Protokoll. Könnte gut sein dass die da einen von den Nordic nRF52 (oder verwandten Serien) verwenden. Die unterstützen neben BLE auch ANT und eigene 2.4GHz Protokolle. Dann brauchen sie nur einen Chip und Entwicklungsumgebung und nicht mehrere.
Danke für eure raschen & hilfreichen Rückmeldungen! Rüdiger B. schrieb: > Über die FCC ID suchen. Wusste gar nicht, was man über diese ID so alles an Infos bekommt. Sehr interessant ... Hmmm schrieb: > Ins Handbuch gucken. Nach dem keines mehr mitgeliefert wird, bin ich gar nicht auf die Idee gekommen eines online zu suchen :o) Dann werd ich mich als nächtes schlau machen, was ich benötige um ein 2,4GHz Funkprotokoll resp. BT zu analysieren. Ich hoffe da gibt's günstige USB Sticks und Software wie Wireshark o. ä.... Danke jedenfalls und wünsche euch ein gutes neues Jahr 2025! vG Alram
auf der FCC ID site ist folgendes PDF verlinkt: https://fcc.report/FCC-ID/2A2XI589/6697018.pdf ab Seite 4 sieht man die Platine in Grossaufnahme => XN297EBW Dürfte wohl dieser Chip sein: https://opendevices.ru/wp-content/uploads/2017/03/XN297-Low-Power-2.4GHz-GFSK-Transceiver.pdf Muss mich wohl in den protokoll stack da etwas einlesen ... vG
Alram L. schrieb: > > Dürfte wohl dieser Chip sein: Fast, die Beschriftung der 8-Pin ICs (es gibt zwei davon) wird XN297LBW sein und das ist dann der hier: https://www.panchip.com/static/upload/file/20190916/1568621331607821.pdf Wenn man das Funkprotokoll analysieren will kann man die SPI Kommunikation mitschneiden und zusätzlich schauen ob man eventuell an die Firmware im Mikrocontroller kommt.
:
Bearbeitet durch User
Dieter S. schrieb: > kann man die SPI > Kommunikation mitschneiden Leider Fehlanzeige. Hier liegen hab ich nur diese beiden (sendenden) Geräte: https://fcc.report/FCC-ID/2A2XI313 https://fcc.report/FCC-ID/2A2XI312 Nach den Fotos zu urteilen haben die einen Chip verbaut, wo ein Microcontroller + XN297L im selben Gehäuse verbaut wurde. Da wird eher nix mit SPI mitlesen :( Ich habe gerade meinen Elektronikvorrat etwas durchsucht - und da sind nRF24L01+ Module zum Vorschein gekommen. Da ich nicht wirklich Erfahrung mit Funkmodulen habe frage ich mal euch: Besteht eine Chance, dass die beiden kompatibel sind? Die Eckdaten aus den Datenblättern schauen ja ned so schlecht aus: XN297L: - Frequency band: 2.400 ~ 2.483GHz - Data rate: 2Mbps, 1Mbps and 250kbps - GFSK modulation nRF24L01+: - ISM frequency band at 2.400 - 2.4835GHz - 1 and 2Mbps air data rate - GFSK modulation Wenn der XN297L mit "nur" 250kbps betrieben wird (was wohl sehr wahrscheinlich ist) wird es wohl nicht funktionieren. Der jeweils im Datenblatt vermerkte Paketaufbau sieht auch nicht sehr identisch aus ... XN297L: Preamble (3 bytes) Address (3~5 bytes) Payload (1~32/64 bytes) CRC (0/2 bytes) nRFL24L01+: Preamble 1 byte Address 3-5 byte Packet Control Field 9 bit Payload 0 - 32 byte CRC 1-2 byte Ich also wird wohl eher nichts, ausser jemand mit mehr Erfahrung ist anderer Meinung ... was meint ihr? vG Alram
Hallo, wollte mich nur kurz zurückmelden und für eure Ideen/Vorschläge bedanken. Mit eurer Hilfe konnte ich mein Vorhaben fertigstellen. Wenn jemand selber etwas für GraviTrax umsetzen will > ich helfe gerne. Jetzt kenne ich das Funk Protokoll etwas besser :) VG Alram
Was spricht dagegen das Ergebnis hier im Thread zu beschreiben?
Ja geht natürlich auch - also hier eine Zusammenfassung. Wenn tatsächlich jemand mehr Interesse haben sollte, werd ich den Code etwas zusammenräumen und veröffentlichen. Was man wissen muss, damit man erfolgreich kommunizieren kann: a) Funkchip ist XN297L (wie oben schon beschrieben). ich hab mir dieses board bestellt: https://www.lcsc.com/product-detail/RF-Modules_DreamLNK-DL-297LDA-S_C2837201.html b) Das Protokoll ist erwartungsgemäss recht einfach: ein Sensor sendet je nach eingestelltem Kanal mehrmals (15-20x) das gleiche Paket auf 2 Kanälen aus. Der Paketaufbau ist denkbar einfach: 6 bytes lang; die ersten 3 sind je Sensor fix; die letzten 3 Bytes random (um Paketwiederholungen zu erkennen) c) Einstellungen am XN297L: Fixe Paketgrösse: 6 bytes, fixe Adresslänge: 5 bytes, 2 bytes CRC, kein auto ACK, kein auto resend; speed: 1mbps Was man noch wissen muss sind die verwendeten Kanäle und Adressen - hier Auszug aus meinem Header:
1 | #define GT_CHANNEL1_RED 0x02
|
2 | #define GT_CHANNEL2_RED 0x45
|
3 | |
4 | #define GT_CHANNEL1_GREEN 0x03
|
5 | #define GT_CHANNEL2_GREEN 0x46
|
6 | |
7 | #define GT_CHANNEL1_BLUE 0x04
|
8 | #define GT_CHANNEL2_BLUE 0x47
|
9 | |
10 | // die ersten 3 Bytes je nach Gerät:
|
11 | const PROGMEM char GT_PREFIX_TRIGGER[] = {0x13, 0x02, 0x00}; |
12 | const PROGMEM char GT_PREFIX_STARTER[] = {0x13, 0x04, 0xCA}; |
13 | const PROGMEM char GT_PREFIX_REMOTE[] = {0x13, 0x05, 0x00}; |
14 | |
15 | // Adressen je Kanal
|
16 | const PROGMEM char GT_ADDRESS_RED[] = {0x67, 0x3a, 0xC2, 0x94, 0x7d}; |
17 | const PROGMEM char GT_ADDRESS_GREEN[] = {0x68, 0x3b, 0xC3, 0x95, 0x7e}; |
18 | const PROGMEM char GT_ADDRESS_BLUE[] = {0x69, 0x3c, 0xC4, 0x96, 0x7f}; |
Wie gesagt - wenn Interesse besteht, räume ich den code auf und veröffentliche ihn gerne. vG Alram
Alram L. schrieb: > Wie gesagt - wenn Interesse besteht, räume ich den code auf und > veröffentliche ihn gerne. Auch wenn mein Nachwuchs (und damit auch ich...) aus dem Gravitrax-Alter schon raus ist - damals gab es leider noch keine Power-Bausteine - ich fände es super, wenn du deine Erkenntnisse teilen würdest. Hier oder vielleicht sogar noch besser gleich auf GitHub. Klingt für mich nach viel Potential zum selberbasteln.
Hätte auf jeden fall auch intresse dran, habe bereits ein Raspberry Pi mit eigenem Code damit ich einfach Python scripte für die Connect Elemente ausführen kann. Einen Farbsensor Stein hab ich auch gebastelt kann jedoch noch nicht mit den anderen Steinen Komunizieren.
Bitte sehr - wenn jemand Lust zum nachbauen hat: https://github.com/alramlechner/GTStoppuhr Das Repo beinhaltet das Microchip Studio Projekt, Schematic und Board (EasyEDA) und auch einen (bei weitem nicht fertigen) Saleae High-Level-Analyzer für den XN297L. Der Code ist noch recht prototypisch - die (für meine Kids) wichtigsten Dinge funktionieren. Und es macht Kindern spass, die Laufzeit ihrer Murmelbahn zu messen und verbessern. Die Idee für diese Stoppuhr ist in der Weihnachtszeit entstanden und das wichtigste war: Von Idee, Schema, PCB, löten und Software schreiben waren sie von Anfang an dabei und haben viel gelernt (wie ich auch :) ). Ideen für Funktionen gibt's noch viele ... wenn jemand aktiv beitragen will, dann gerne - 1-2 Platinen kann ich ohne Probleme noch abtreten :) vG Alram
Vielen dank, werde mir das mal anschauen, Signale zu senden sollte bestimmt auch möglich sein
Fynn N. schrieb: > Vielen dank, werde mir das mal anschauen, Signale zu senden sollte > bestimmt auch möglich sein Hatte gestern etwas Zeit und ein paar wesentliche Erweiterungen :) Beim Protokoll muss ich leider etwas "zurückrudern" - zwar funktioniert das Empfangen und interpretieren soweit, dass meine Stoppuhr einwandfrei ihren Dienst tut. Aber wenn ich Pakete versende konnte ich derweil noch keinerlei Reaktion bei den Original GT Komponenten auslösen. Also so ganz analysiert hab ich das Protokoll doch noch nicht. Da muss ich mich nochmal hinsetzen ... vG
Ggf könnte da auch die Python Library, welche zur kommunikation mit dem Connect element gedacht ist, nutzlich sein, einfach damit spizellere signale senden und diese dann auslesen
Sehr interessant - schau mir grad die Lib von Ravensburger an: https://github.com/Ravensburger-Verlag-GmbH/GraviTrax-Connect/blob/main/GraviTrax-Connect-Python-Library/gravitraxconnect/gravitrax_bridge.py Sehr aufschlussreich - auch wenn das die Kommunikation zwischen PC und Connect Element ist => dadurch weiss man schon, welche Informationen in einem Paket enthalten sind. Sind ein paar mehr, als ich herausgelesen habe :) Das wird wohl ein kleines Abendprojekt werden ... Pyhton lerne ich ja auch erst gerade kennen. vG
Also soweit ich weiß senden die Sender Elemente immer den Status "All" aber die Bridge kann auch nur eine Stein art benachrichtigen. Der einzige Stein der dies auch tut ist der Dome Starter der beim senden den Status Bridge hat.
Danke für den tipp zum Pyhton SDK von Ravensburger. Damit bin ich heute einen Schritt weiter gekommen und kann nun problemlos Signale zu den originalen Bausteinen senden. Paketaufbau der 6 bytes: - 1: 0x13/0x14/0x15 für rot/grün bzw. blauer kanal - 2: Baustein, welcher das Signal gesendet hat (https://github.com/Ravensburger-Verlag-GmbH/GraviTrax-Connect/blob/main/GraviTrax-Connect-Python-Library/gravitraxconnect/gravitrax_constants.py#L67) - 3: Status/gültige Empfänger (https://github.com/Ravensburger-Verlag-GmbH/GraviTrax-Connect/blob/main/GraviTrax-Connect-Python-Library/gravitraxconnect/gravitrax_constants.py#L32) - 4+5: random message id - 6: CRC damit konnte ich ein paar Variatonen durchprobiern und funkioniert wie erwartet. Code im repo ist akualisiert. Einen Bug muss ich jetzt noch finden: den XN297L von transmit auf receive zurückwechseln funktioniert noch nicht ... ist dann für morgen Abend :) vG
Das freut mich, werde mir deinen Code im laufe der Woche mal anschauen, sobald bei mir die Boards ankommen werde ich versuchen eine Python und Circuit Python Library für meine Projekte zu schreiben. Falls jemand Intresse hat kann ich diese mal hier Posten sobald ich die fertig habe. Muss mich jedoch erst mit C auseinander setzten, sollte aber kein problem werden.
:
Bearbeitet durch User
Ich nähere mich der v1 an. Der Code ist nun auch etwas aufgeräumter. Inzwischen funktioniert auch das Sperren des Starter Bausteins. Wenn die Kugel über meine Stoppuhr gestartet wird, kann ich die ein "Zwischenfunken" durch die Fernbedienung erfolgreich verhindern. Alles in allem würde ich sagen: das Funkprotokoll hab ich im Griff - jetzt kann ich mich mehr der Logik widmen. Allerdings scheint mir, als ob der Connect Baustein einen ziemlichen Fehler eingebaut hat. Der hat mich Anfangs bei der Protokollanalyse ziemlich beschäftigt: Wenn der Connect Baustein ein Signal sendet (bspw. Rot), dann sendet er es auf allen Kanälen (auch auf Grün und Blau). Auf diesen Kanälen wird dann auch das Kennzeichen (1. Byte) für die Signalfarbe ausgetauscht - allerdings wird das CRC Byte nicht angepasst. Vermutlich verwerfen die Bausteine dieses Paket dann. Da ich Anfangs versucht habe, diese Pakete zu simulieren und einfach zu keinem Erfolg gekommen bin, hat mich das ziemlich viel Zeit gekostet. Aktuell kann ich mir das nicht als Feature erklären ... grossen impact sollte es nicht haben. Ausser, dass der Baustein halt ziemlich viele sinnlose Pakete sendet und damit potentiell Bandbreite verbraucht ... vG
Dass das Connect so viele signale sendet wusste ich auch nicht, aber super dass jetzt alles klappt. Hilft mir auch bei meinen Projekten weiter
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.