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?
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.
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.
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.
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!
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.
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 ...
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 :)
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:
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:
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.
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 :)
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 ...
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 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.
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.
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.
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 ...
Vielen Dank für die tolle Arbeit! Ich habe es auf einen wemos d1 mini (esp8266) portiert. Ich nutze es um den Trigger an einer "electric cannon" auszulösen.
https://github.com/Danielxyz123/GravitraxTrigger
ich habe auch einen „lever“, dieser feuert die Kugel jedoch auch automatisch ab wenn der Kanal z.B. auf rot steht. Er reagiert nicht auf meinen Trigger. Als ob er zunächst ein gültiges Signal empfangen oder gekoppelt werden müsste. Im Gegensatz zur „electrical canon“ besitzt dieser zusätzlich einen automatischen Modus für stand-alone Betrieb.
Vielen Dank für die tolle Arbeit! Ich habe es auf einen wemos d1 mini
(esp8266) portiert. Ich nutze es um den Trigger an einer "electric
cannon" auszulösen.
https://github.com/Danielxyz123/GravitraxTrigger
Freut mich, dass dir mein Projekt geholfen hat. :)
Danke für die Rückmeldung. Nachdem ich mich nochmal damit beschäftigt habe, saß der Fehler scheinbar vor dem Lever. Durch den Trigger wird die Rückbewegung in die Ausgangsstellung getriggert. Wenn die Kugel einläuft wird immer sofort automatisch transportiert.
