momentan beschäftige ich mich intensiv mit dem Bau eines Senders für Siku. Der soll all das können, was der originale nicht kann: - Servoreverse - Wegbegrenzung - freie Kanalzuordnung der Steuerknüppel - LCD-Display für Variablen-Eingabe
Gleichzeitig soll dies mein Erstlingswerk mit Bascom werden, muß mir also alles erst selbst beibringen. Falls interesse besteht, werde ich den Schaltplan und das Programm gerne posten.
Momentaner Stand ist, daß der Code bis auf die Ausgaberoutine fertig ist. Was mir am meisten fehlt, ist daß ich das Siku-Protokoll nicht kenne. User mizu42 hat mal dazu ein paar Angaben gemacht, auf meine Anfrage hin genauere Auskunft zu geben hat er leider (noch) nicht geantwortet. Ich hoffe jetzt, daß mir Martin Jost da aus der Patsche helfen kann, denn ohne Oszi wirds schwierig !!!
Zitat von Martin JostIch habe gerade mal nach dem Siku-Protokoll gesucht und das gefunden:
Zitat Erst kommen 4 bit adresse (immer nur ein Bit gesetzt.) Dann 4 bit Schalter (die oberen 4) Dann kommen die Proportionalkanäle 7 bit bei zweien ist des 8. Bit für Blinker links bzw. Blinker rechts mißbraucht. Reihenfolge ist (soweit ich's noch im Kopf hab) Lenkung, Gas, Heckhydraulik, Kreuzknüppel auf/ab, Kreuzknüppel links/rechts. Und dann noch ne Prüfsumme (ist wenn ich mich recht entsinne einfach die 8 bit Summe der übertragenen Daten. Und das Paket wird nach einer vom Kanal abhängigen Pause wiederholt (damit sich zwei verschiedene nicht dauernd stören).
Ich versuche mal demnächst mir das Protokoll auf dem Oszi anzuschauen ob das mit der gefundenen Beschreibung übereinstimmt. Das Sendeprotokoll ist denk ich nicht allzu schwer zu implementieren, da du einfach die zu sendenden Werte abarbeiten musst. Leider kann ich dir auch nicht die Routine schreiben, da ich mich nur mit PIC beschäftigt habe und bei denen auch nur in ASM. Helfe aber gerne soweit ich kann, da mich das Projekt auch sehr interessiert.
Zweiter Knackpunkt ist, das der Speicher meines Atmega8 auf meinem Evaluationsboard zu klein ist und ich jetzt auf was grösseres Ausweichen muß. Ich werde diese Woche gleich noch einen anderen Mikroprozessor bestellen und in dem Zuge auch den Rest der Elektronik-Teile besorgen. Eine Unbekannte hab ich dabei aber noch: welche IR-Led ist für die 455khz geeignet?
ich hoffe doch das du jetzt nicht darauf warten musst das ich dir das Protokoll schicken kann. Habe im Moment recht viel zu tun und weis nicht wann ich dazu kommen werde mir das anzuschauen. (Vielleicht am WE) Ich werd auf jeden Fall dran denken, da ich da auch interesse dran habe.
Ganz ohne Deine/Eure Hilfe wird´s wohl nicht gehen. Oszi hab ich leider nicht. Für das Soundkarten-Oszi ist das ganze viel zu schnell. Ich werd mal versuchen, das Protokoll mit einem Eigenbau-Empfänger aufzufangen. Ich weis aber leider weder die Pulslängen, noch ob das Signal noch auf einem Träger sitzt. Nen Versuch ists allemal wert :-)
Vielleicht findet sich ein anderer "Freiwilliger", der sich mal einen Abend mit dem Sikuprotokoll und einem Oszi beschäftigen will ???
ich hatte gestern Abend doch mal Zeit und habe mich mit dem Siku-Protokoll beschäftigt. Dabei kam heraus, dass das schon beschriebene Protokoll fast komplett stimmt. Ich habe mal eine Tabelle angehängt, in der ich aufgelistet habe, welche Funktion die einzelnen Bits haben und die Zeite für Bits. Was ich allerdings vergessen habe, sind die Pausezeiten der Pakete in abhängigkeit der ID. Aber das kann ich recht schnell noch nachholen. Was ich allerdings noch nicht 100%ig verfolgt habe, wie sich die Prüfsumme zusammensetzt. Denn bei meiner Analyse stellte sich heraus, das die Prüfsumme 9bit lang ist. Werde mal versuche starten um diese zu berechnen.
Ich hoffe das hilft dir weiter!
Grüße Martin
Der widerstandsfähigste Parasit = Eine Idee
Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden! siku-protokoll.JPG
Hab gestern abend einen Empfänger programmiert und versucht, die Signale aufzufangen. Hab auch schon diverse 1en und 0en empfangen, aber irgendwie hat mein Timing nicht gestimmt. Liegt das Signal eigentlich auf einem Träger? Verstehe ich es richtig, daß sich die Länge(zeitlich) des Protokolls durch den Inhalt verändert (je nach Inhalt an High- und Low-Bits) ???
Momentan Empfange ich Protokolle mit 120 Bit länge :-((, muß da wohl noch weitertesten
Also so wie ich das gestern gesehen habe setzt sich das so zusammen: Das ganze beginnt mit einem Startbit, das 43µs lang ist. Dann kommt immer zwischen den einzelnen Bits eine Pause von 87µs wo nichts gesendet wird. Bei den einzelnen Bits wird für eine 0 32µs gesendet und für eine 1 54µs gesendet. Das Senden besteht immer aus dem 455kHz-Signal. Die zeitliche Länge aller Bits ist je nach Anzahl der 1en und 0en variabel. Aber das Ende kannst du an einer langen Sendepause erkennen. Diese ändert sich wohl auch je nach gesendeter ID. Leider habe ich gestern vergessen diese Pausenzeit zu messen, werde das aber heute Abend nachholen.
Bis auf die ungeklärte Prüfsumme, müsstest du damit aber schon das Protokoll zum laufen bringen können.
habs endlich geschafft, das Protokoll zu empfangen. FREU !!! Hier ein paar Beispiele: 110001101000000010000000101000101000000111010001000010010 100011101000000010000000101000101000000111010001011010010 100010001000000010000000101000101000000111010001010100100 100010000000000010000000101000101000000111010001011010100 100010000111011100000000101000101000000111010001001000100 100010000000000011100111101000101000000111010001001000100 100010000000000010000000101010001000000111010001011001000 100010000000000010000000110111101111000111111111010010000 100010000000000010000000110111101000100011001001001001000 101000000000000010000000110111101101111011111110011010000 101000011000000010000000110111101101111011111110010010010
Dabei ist die Checksumme gleich, bei der oberen Zeile ist nur Gaskanal (11101110), bei der unteren ist das Lenkservo anders (11001111). Aber 11101110 und 11001111 sind nicht gleich, also müsste auch die Checksumme anders sein, da der Rest des Protokolls gleich ist. Kopfkratzen !!!
Zitat von diezel Hier ein paar Beispiele: 110001101000000010000000101000101000000111010001000010010 100011101000000010000000101000101000000111010001011010010 100010001000000010000000101000101000000111010001010100100 100010000000000010000000101000101000000111010001011010100 100010000111011100000000101000101000000111010001001000100 100010000000000011100111101000101000000111010001001000100 100010000000000010000000101010001000000111010001011001000 100010000000000010000000110111101111000111111111010010000 100010000000000010000000110111101000100011001001001001000 101000000000000010000000110111101101111011111110011010000 101000011000000010000000110111101101111011111110010010010 Gerhard
Ah ja. Jetzt weis ich was da steht.
Da steht: Ich verstehe nur Bahnhof und Abfahrt.
Könnt ihr aus den Einsen und Nullen irgentwas lesen?
habe mich jetzt schon etliche Stunden mit dem Protokoll beschäftigt.
Prop-Kanäle: jeweils das letzte Bit gibt die Richtung an, der Rest den Wert, Bsp. wäre 11111111 für das Lenkservo Vollausschlag rechts, 11111110 Vollausschlag links.
Checksumme: Da geb ich bald auf. Sagen kann ich, daß die Schaltkanäle nicht in die Checksumme einfliessen. Wie und aus was sich die Checksumme bildet, wirft nur große Fragezeichen auf. Ist wohl doch nicht "nur" eine Summe :-(
Irgendwie vertraue ich meinen empfangenen Werten auch nicht, obwohl diese stabil sind.
Hallo Gerhard, interessantes Projekt. Was für einen Testaufbau und was für eine Software benutzt Du um das Protokoll aufzuzeichnen? Ist das 9´te Bit der Prüfsumme immer 0?
mein Testaufbau ist lediglich ein Atmega8 und ein TSOP7000. Habe dann dazu ein Programm in Bascom geschrieben, daß mir die Signallängen auswertet und das Protokoll via Hyperterminal am PC anzeigt. Das letzte Bit der Prüfsumme kann sehr wohl eine "1" sein, war nur zufällig in den Beispielen nicht so.
das "Geheimnis" um das Siku-Protokoll ist erforscht. Der Hauptknackpunkt war, daß die Bytes umgekehrt gesendet wird. Beispiel: Knüppelmittelstellung bei 8-Bit-Auflösung: 10000000 Gesendet wird aber: 00000001 Die Checksumme ist dann nur die Summe der 6 anderen Bytes. Davon werden jedoch nur die letzten 8 Bits gesendet.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
6
Offline
