[Sigg]

Ist zufällig, betrifft immer wieder mal eine andere Lok.
Scheint deshalb schon an meiner Implementierung zu liegen.

Gruss
Dani

[Rainer Müller]

Hallo,

und endlich mal wieder gibt es eine neue Version 2002 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Die einzige nennenswerte Änderung ist diesmal das Abschalten bei Kommunikationsverlust.

Bei den Tests mit nach außen geführtem CAN-Bus fiel auf, dass es möglich war, das System so zu blockieren, dass es nicht mehr kontrollierbar war. Deshalb gibt es jetzt eine Überwachung, die einen Nothalt auslöst, wenn der Kontakt zum letzten Steuergerät verloren geht. Dazu wird bei CAN-Clients der Ping und bei SRCP-Clients die Anzahl der aktiven Kommandokanäle überwacht.

Wenn durch ausbleibende Pings und verlorene Kommandokanäle die letzte Einflussmöglichkeit verloren zu gehen scheint, wird das wie ein Nothalt behandelt, also der Fahrstrom abgeschaltet, sofern der neue DDL-Parameter "enable_client_checking" auf yes gesetzt ist.

Außen vor bleiben derzeit die Browsersitzungn am maecan-Server, da habe ich noch keine passende Schnittsstelle gefunden, die deren Anzahl ermittelbar macht.


Gruß
Rainer

[Rainer Müller]

Hallo,

für alle, die den basrcpd in Gerds OpenWRT Image verwenden, gibt es seit Juni eine Vereinfachung:



Man muss den basrcpd-Server(1) nicht mehr per Kommandozeile starten und auch das Aktivieren des "presume-ack"-Modus(2) wurde wesentlich vereinfacht (bisher war editieren einer Konfigurationsdatei erforderlich) - das geht jetzt alles über die Luci-Bedienoberfläche im Browser.

Mit dem Start-Knopf sofort einschalten bzw. per (De)aktiviert-Knopf einstellen, dass automatisch bei jedem Start eingeschaltet wird.

Kurzerklärung "presume-ack":
Wenn man ein oder mehrere externe CAN-Geräte mitverwendet, aber die Möglichkeit besteht, dass auch einmal kein aktives CAN-Gerät angeschlossen ist, hilft die Option "presume-ack on", um eine Blockade der internen CAN-Kommunikation zu vermeiden, da der ACK dann nicht mehr erforderlich ist.


Gruß
Rainer

[Rainer Müller]

Hallo BPi-Anwender,

nach fast einem Jahr gibt es wieder eine neue Version 2102 des basrcpd auf meiner Gleissignalerzeugungs-Seite mit folgenden Änderungen:

- Bei einer schnellen Abfolge von Notstopp und Richtungswechsel konnte der Notstopp-Befehl verloren gehen wenn er zum Zeitpunkt des Richtungswechsels noch nicht über das Gleis gesendet war. Dieses Verhalten ist nun korrigiert, sodass auf jeden Fall der Notstopp zuerst rausgeht.

- Desweiteren werden MS1-CAN-Meldungen jetzt ignoriert, da sie teilweise sinnlose Antworten des basrcpd auf dem Bus bewirkten. Und ein paar Compiler-Warnungen habe ich wieder mal beseitigt, denn die Compiler mäkeln mit jedem Update mehr an bestehendem Code rum.


Gruß
Rainer

[Rainer Müller]

Hallo BaPi-Anwender,

ein Lagebericht.

Nachdem mein altes SD-Kärtchen zunehmend Probleme machte, wollte ich nicht mehr die jahrelang upgegradete Version aufspielen, sondern auf das neue Kärtchen auch neue SW: Armbian bot ein Buster-Image vom Mai 21 mit Kernel 5.10.34. Das lief auch ganz gut los, hatte eine für mich gute Paketauswahl an Bord, aber oh Schreck - der im BananaPi eingebaute CAN-Controller wollte nicht.

Nach einigem Suchen fand ich das Problem im Device Tree: da sind im Boardteil die Pingruppennamen geändert worden, aber nicht im CAN-Overlay. Als Anwender eines "offiziellen Armbian-Images auf unterstützter HW" durfte ich eine Fehlermeldung erstellen. Aber erst danach merkte ich, dass die Ursache viel tiefer steckte, schon Ende 2018 hatte das Linux-Kernel-Team die unvollständige Umbenamung angestoßen. Der CAN-Controller des BananaPi dürfte also bei weiteren Distributionen und schon seit einiger Zeit nicht mehr funktionieren. Ausgenommen davon sind natürlich Images mit eigenem Device Tree wie z.B. Gerds OpenWRT-Image.
Zum Glück kann man das CAN-Overlay korrigieren und das falsche damit überschreiben, damit das Image nutzbar wird. Der Fehler lässt die Interpretation des Device Tree scheitern, so dass auch andere Overlays wie z.B. das fürs SPI nicht ausgeführt werden.

Klar ist, dass der originale CAN-Treiber noch kein "presume-ack" kann, aber NOCH lässt sich der von Gerd angepasste compilieren. "NOCH" weil von Kernelseite Ungemach droht, siehe die Änderung von "dlc" nach "len" .

Der SPI-Treiber ist noch der alte mit Loch bei 64 Bytes; keine Ahnung wie man die bekannte Korrektur in den Kernel kriegt. Da muss man halt sehen, dass die SPI-Pakete kürzer oder länger als 64 sind.

Neu dagegen ist, dass die BaPi-UARTs als Type 4 (16550A) mit Fifo 16 statt als Typ 19 (U6_16550A) mit Fifo 64 erkannt werden, Grund ist dass zur Zeitersparnis beim Booten keine Variantenprüfung mehr stattfindet . Hat aber vermutlich bei meinem Projekt keinen Einfluss, trotzdem seltsam was da im Kernel rumgehampelt wird.

Insgesamt läst sich aber erfreulicher Weise feststellen, dass die modellbahnspezifischen SW-Anteile, also das can2udp-paket, der basrcpd, der maecan-server und das ms1relay, unter dem neuen Kernel weiterhin problemlos laufen.


Gruß
Rainer


NB: jetzt gabs einen neuen Kernel 5.10.43, der hat dann bei der Installation mein korrigiertes CAN-Overlay wieder mit dem fehlerhaften überschrieben!

[Rainer Müller]

Hallo,

es gibt mal wieder eine neue Version 2110 des basrcpd auf meiner Gleissignalerzeugungs-Seite mit folgenden Änderungen, die hauptsächlich die "inneren Werte" der Software betreffen:

- Korrekturen bei TERM- und LOCK-Funktionalitäten via SRCP

- geringfügige Überarbeitung der mfx-Paketerzeugung

- Bearbeitung des "mfx Seek"-Systemkommandos zur Kommunikation mit externen Boostern

- Vorbereitung für die Anschaltung eines RDS-Empfängers über UART-Schnittstelle

- Korrekturen an "common"-Variablen, da deren Verwendung von gcc-10 pingeliger geprüft wird

- Beseitigung von cppcheck-Warnungen


Für den dritten und vierten Punkt habe ich auch die SRCPD-Parameterübersicht angepasst, da diese Funktionen explizit über die Konfigurationsdatei aktiviert werden müssen.


Gruß
Rainer

[vikr]

Hallo Rainer,

Zitat von Rainer Müller im Beitrag #56

---

- Vorbereitung für die Anschaltung eines RDS-Empfängers über UART-Schnittstelle.

---

ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?

Erinnere mich an einen Thread hier im Forum, der ziemlich plötzlich verschwunden ist.

MfG

vik

[Rainer Müller]

Hallo Vik,

Zitat von vikr im Beitrag #57

---

Hallo Rainer, ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?

---

seit Längerem beschäftigt mich das Thema "mfx-Rückmeldeempfänger ohne exotische Bauelemente", nachdem sich ja die RDS-Chips nur noch schwer beschaffen lassen und deshalb nicht so recht für einen Bastelvorschlag taugen. Dieser Detektor kann dann einen "dummen Booster" um die mfx-Erkennung erweitern oder auch sonst die mfx-Rückmeldungen mit Hilfe eines weiteren Prozessors auswerten. Leider macht das Projekt bislang nur wenige Fortschritte.

Nach derzeitigem Stand soll im Zentrum ein PIC16F1705 stehen, dessen beiden OpAmps mit ein paar Widerständen und Kondensatoren einen zweistufigen aktiven Bandpass für den mfx-Träger bilden. Die interne Programmierung des PICs soll das Signal decodieren und das Ergebnis per UART ausgeben, so dass es mit wenig Aufwand (1 Draht) an den Zielprozessor geführt werden kann.
Im BPi-Fall würde also dieses Signal von einem der internen UARTs empfangen und ggf mit den Meldungen über "mfx Seek" kombiniert ausgewertet. Die UART-Ansteuerung habe ich jetzt im basrcpd eingebaut, die Auswertung fehlt noch.


Gruß
Rainer

[vikr]

Hallo Rainer, Danke für die Info!

Zitat von Rainer Müller im Beitrag #58

---

"mfx-Rückmeldeempfänger ohne exotische Bauelemente"

---

Wie händeln denn ESU, Märklin, Uhlenbrock (Piko) und Zimo das? Wie bekommen die mfx codiert bzw. decodiert, wenn RDS-Bausteine so rar sind? Oder modellieren die das auch selbst in der Firmware nach? Für "mfx" wurde ja nie ein Patent erteilt.
Erinnert mich irgendwie an das Ende der Fertigung der Motorola-Fernbedienungs-Chips...

MfG

vik

[Rainer Müller]

Hallo Vik,

Zitat von vikr im Beitrag #59

---

Hallo Rainer, Danke für die Info!

Zitat von Rainer Müller im Beitrag #58

---

"mfx-Rückmeldeempfänger ohne exotische Bauelemente"

---

Wie händeln denn ESU, Märklin, Uhlenbrock (Piko) und Zimo das?

---

Außer bei Märklin, die laut Karstens Analyse für den Booster 60175 den schon vor Jahren abgekündigten PT2579 verwenden, den sie oder ihr Auftragsfertiger wohl eingelagert haben, keine Ahnung.

Vor ziemlich genau vier Jahren habe ich mich schon mal im Beitrag 18 diesen Threads über die Verfügbarkeit ausgelassen, heute hat vom letzten Typ LC72725KV zwar Mouser noch ein paar in der Kiste, vermerkt aber "Gilt als veraltet und wurde vom Hersteller abgekündigt".

Alle anderen mfx-Aufgaben außer der RDS-Decodierung sind relativ einfach in Firmware zu lösen.


Gruß
Rainer

[vikr]

Hallo Rainer,

Zitat von Rainer Müller im Beitrag #60

---

Außer bei Märklin, die laut Karstens Analyse für den Booster 60175 den schon vor Jahren abgekündigten PT2579 verwenden, den sie oder ihr Auftragsfertiger wohl eingelagert haben, keine Ahnung.

Vor ziemlich genau vier Jahren habe ich mich schon mal im Beitrag 18 diesen Threads über die Verfügbarkeit ausgelassen, heute hat vom letzten Typ LC72725KV zwar Mouser noch ein paar in der Kiste, vermerkt aber "Gilt als veraltet und wurde vom Hersteller abgekündigt".

Alle anderen mfx-Aufgaben außer der RDS-Decodierung sind relativ einfach in Firmware zu lösen.

---

es gibt ja ein paar interessante Programme zum Download auf https://www.ukwtv.de/cms/
genauer auf:
https://www.ukwtv.de/cms/downloads-aside...s-software.html

Vermutlich bekommt "man" das ja auch in aktuellen Prozessoren zum laufen...

MfG

vik

[Rainer Müller]

Hallo Vik,

willst du wirklich einen Windows-PC neben jeder Zentrale und jedem Booster?

Zitat von vikr im Beitrag #61

---

es gibt ja ein paar interessante Programme zum Download auf https://www.ukwtv.de/cms/
genauer auf:
https://www.ukwtv.de/cms/downloads-aside...s-software.html

---

Leider decken die Programme eine andere Ebene ab, sie befreien nicht die Daten aus dem Signalgemisch, sondern stellen die Daten für "echtes" RDS schön auf dem Bildschirm dar. In den Anleitungen findet man, wie man für den PC die Signale am RDS-Chip abgreifen kann, aber genau den will ich ja ersetzen. Lediglich das erste (RDS Spy) bietet auch einen Modus für die Soundkarte statt RDS-Chip, stellt dafür aber an diese spezielle Ansprüche (z.B. Samplingrate von 192 kHz).


Gruß
Rainer

[vikr]

Hallo Rainer,

Zitat von Rainer Müller im Beitrag #62

---

willst du wirklich einen Windows-PC neben jeder Zentrale und jedem Booster?
...

---

natürlich nicht, aber dieser Hype ist ja auch schon 10 bis fast 20 Jahre alt. Ein ATmel wird vielleicht nicht reichen...

Zitat von Rainer Müller im Beitrag #62

---

In den Anleitungen findet man, wie man für den PC die Signale am RDS-Chip abgreifen kann, aber genau den will ich ja ersetzen. Lediglich das erste (RDS Spy) bietet auch einen Modus für die Soundkarte statt RDS-Chip, stellt dafür aber an diese spezielle Ansprüche (z.B. Samplingrate von 192 kHz).

---

Ja, aber wie RDS, d.h. auch der Chip arbeitet ist ja gut dokuentiert. Ich dachte bisher immer die Geschwindigkeit ist das Limitierende.

Jedenfalls bin ich gespannt!

MfG

vik

[Rainer Müller]

Hallo,

es gibt mal wieder eine neue Version 2112 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Dieses Mal ohne neue Leistungsmerkmale, es ist eine reine Korrekturausgabe gegen die Auswirkungen der Korrektur des Jahr-2038-Problems, bei dem der Sekundenzähler bei 32-Bit-Zeitstempeln ins Vorzeichenbit überläuft.

Bei neueren Kerneln werden deshalb auch bei 32-Bit-Linuxen die Zeitstempel auf 64 Bit aufgebläht, so z.B. bei dem von Gerd auf dem BananaPi eingesetzten OpenWrt. Dass das ab Kernel 5.6 so sein soll findet man zwar im Internet, aber für BaPi- und RaPi-Distributionen (mit Kernel 5.10.xx) gilt das wohl nicht unbedingt, deshalb gab es unter Armbian beim Test keine Probleme, dagegen unter OpenWrt: da waren srcp-Meldungen mit Zeitstempeln so verfälscht, dass ein srcp-Client nicht mehr synchronisiert wurde, wenn ein anderer Client Zustände im basrcpd änderte.
Dies ist mit der Version 2112 nun behoben, korrekte Funktion sollte jetzt mit 32- und 64-Bit-Zeitstempeln gegeben sein.


Gruß
Rainer

[Rainer Müller]

Hallo Mitleser,

Zitat von Rainer Müller im Beitrag #64

---

Dies ist mit der Version 2112 nun behoben, korrekte Funktion sollte jetzt mit 32- und 64-Bit-Zeitstempeln gegeben sein.

---

nachdem Gerd blitzschnell aus meinen geänderten Quellcodes ein neues Installationspaket für den basrcpd gezüchtet hat, habe ich ein Update mit diesem durchgeführt und getestet.

Ergebnis: die Funktion sollte nicht nur korrekt sein, sie ist es jetzt!


Gruß
Rainer

[Rainer Müller]

Hallo Mitleser,

Zitat von Rainer Müller im Beitrag #58

---

Hallo Vik,

Zitat von vikr im Beitrag #57

---

Hallo Rainer, ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?

---

seit Längerem beschäftigt mich das Thema "mfx-Rückmeldeempfänger ohne exotische Bauelemente", nachdem sich ja die RDS-Chips nur noch schwer beschaffen lassen und deshalb nicht so recht für einen Bastelvorschlag taugen. Dieser Detektor kann dann einen "dummen Booster" um die mfx-Erkennung erweitern oder auch sonst die mfx-Rückmeldungen mit Hilfe eines weiteren Prozessors auswerten. Leider macht das Projekt bislang nur wenige Fortschritte.

Nach derzeitigem Stand soll im Zentrum ein PIC16F1705 stehen, dessen beiden OpAmps mit ein paar Widerständen und Kondensatoren einen zweistufigen aktiven Bandpass für den mfx-Träger bilden. Die interne Programmierung des PICs soll das Signal decodieren und das Ergebnis per UART ausgeben, so dass es mit wenig Aufwand (1 Draht) an den Zielprozessor geführt werden kann.
Im BPi-Fall würde also dieses Signal von einem der internen UARTs empfangen und ggf mit den Meldungen über "mfx Seek" kombiniert ausgewertet. Die UART-Ansteuerung habe ich jetzt im basrcpd eingebaut, die Auswertung fehlt noch.

---

nachdem der mfx-Rückmeldeempfänger jetzt erste sinnvolle Zuckungen macht (die Trägererkennung für mfx-Verify und Ermitteln der Decoder-UID), sollte sich am Schaltplan nichts Wesentliches mehr ändern:



Links unten kommt das ausgekoppelte mfx-Rückmeldesignal (z.B. von dem Strommesswandler) und wird mit den beiden Operationsverstärkern im PIC mit Bandfilterfunktion verstärkt, insbesondere im Bereich der Rückmeldeträgerfrequenz. Das Signal an Pin 8 des PIC wird intern mit einem Schwellwertschalter auf Polarität bewertet, und diese Info abgetastet im SPI-Schieberegister bereitgestellt. Außerdem wird das verstärkte Signal mit D1 gleichgerichtet und einem A/D-Wandlerkanal zugeführt, um die Amplitude des Signals zu bestimmen.

Aus der Information aus dem Schieberegister kann die Frequenz und die Phase des Trägersignals gewonnen werden, und daraus kombiniert mit dem Messwert für die Amplitude die mfx-relevanten Ereignisse. Diese werden dann über den UART nach außen gemeldet, wobei je nach Anwendungsfall die mit einem Transistor bestückte Invertersufe rechts oben erforderlich sein kann.

Die Firmware initialisiert den PIC und verarbeitet dann periodisch (z.B alle 38µs) die Info aus dem SPI-Schieberegister und dem A/D-Wandler. Sobald ein relevantes mfx-Ereignis erkannt wird, wird ein entsprechender Code über den UART abgesetzt. Solch ein Ereignis ist das Erkennen eines stabilen Trägersignals und für das Auslesen von Daten die Interpretation von Phasensprüngen.

Bisher ist das nur die Ein-Bit-Rückmeldung mit ASK-Wert implementiert, die Auswertung der Phasensprünge fehlt momentan noch.

Details werde ich auf der Projektseite mfx-Rückmeldeempfänger veröffentlichen, im Moment steht dort aber fast das was hier auch steht.

Gruß
Rainer

[Rainer Müller]

Hallo,

es gibt mal wieder eine neue Version 2208 des basrcpd auf meiner Gleissignalerzeugungs-Seite, im Wesentlichen eine wip-Version.

Naja, "work in progress" bedeutet ja genau genommen, dass man etwas angefangen hat, was noch nicht komplett fertig ist. So geht zwar das Ermitteln einer mfx-UID mit meinem mfx-Rückmeldeempfänger problemlos, aber das Auslesen von Konfigurationsvariablen damit ist leider noch eine Katastrophe. Die Auswertung der Phasensprünge ist sehr fehlerbehaftet.

Beim "Lokzyklus beenden"-Kommando zeigte sich beim Testen, dass die entsprechende Lok aus der Verwaltung genommen wurde, aber nicht aus dem Refresh-Puffer. Da dieses Problem beim originalen srcpd schon seit 20 Jahren existiert und noch niemand sich daran gestört hat, habe ich das nicht mit höchster Priorität angegangen.

Eingebrachte Änderungen in Version 2208 im Detail:

- Auslesen der mfx-UID mit Hilfe eines RDS-Empfängers über UART-Schnittstelle

- Überarbeitung der Wiederholungen bei 32 Funktionen

- Schnelleres Rückschalten von schnellem auf normalen Refresh

- Bearbeitung des "Lokzyklus beenden"-Kommandos über CAN hinzugefügt

- Beseitigung von Rechteproblemen durch Abfrage auf effektiven User geändert


Für den ersten Punkt habe ich auch die SRCPD-Parameterübersicht angepasst, da diese Funktion explizit über die Konfigurationsdatei aktiviert werden muss.


Gruß
Rainer

[vikr]

Hallo Rainer,

Zitat von Rainer Müller im Beitrag #67

---

So geht zwar das Ermitteln einer mfx-UID mit meinem mfx-Rückmeldeempfänger problemlos, aber das Auslesen von Konfigurationsvariablen damit ist leider noch eine Katastrophe. Die Auswertung der Phasensprünge ist sehr fehlerbehaftet.

---

grundsätzliche Frage: wäre nach Beenden des wip-status mit Deinem mfx-Rückmeldeempfänger ein lokaler Rückmelder in einem Gleisabschnitt möglich, mit dem man in relativ kurzer Zeit auslesen kann, welche mfx-Lok-Adresse(n) sich gerade dort befindet/befinden?

MfG

vik

[Rainer Müller]

Hallo Vik,

Zitat von vikr im Beitrag #68

---

grundsätzliche Frage: wäre nach Beenden des wip-status mit Deinem mfx-Rückmeldeempfänger ein lokaler Rückmelder in einem Gleisabschnitt möglich, mit dem man in relativ kurzer Zeit auslesen kann, welche mfx-Lok-Adresse(n) sich gerade dort befindet/befinden?

---

um das zu erreichen, müsste halt der Decoder mitspielen. Ein Broadcast-Kommando an alle mfx-Decoder, sich zu identifizieren, haben die Entwickler vor 20 Jahren vermutlich nicht vorgesehen oder es ist ihnen gelungen, das bis heute geheim zu halten. Damit könnte man dann die Decoder z.B. jede Sekunde veranlassen, sich zu melden. Öfters sollte es nicht sein, weil sonst die Rückmeldestufe zu viel Wärme erzeugt, was weder ihr noch dem Fahrzeug drum rum gut tut.

Die Decodererkennung ist für das was du vorhast nicht geeignet, viel zu langsam und außerdem reagieren nur nicht angemeldete Decoder.

Vermutlich einzige Möglichkeit ist, alle bekannten Decoder zyklisch anzupingen und den ACK auszuwerten: ein ACK in einem Abschnitt bedeutet dann, dass die letzte angepingte Adresse die des Decoders im Abschnitt war. Bei einem Ping alle 250ms wären da dann bei 20 mfx-Loks 5s maximale Erkennungszeit. Zur dynamischen Verfolgung eher nicht geeignet, aber um bei Betriebsstart die Positionen zu verifizieren würde das evtl. genügen.

Gruß
Rainer

[vikr]

Hallo Rainer, Danke für die Info.

Zitat von Rainer Müller im Beitrag #69

---

Ein Broadcast-Kommando an alle mfx-Decoder, sichfür die zu identifizieren, haben die Entwickler vor 20 Jahren vermutlich nicht vorgesehen oder es ist ihnen gelungen, das bis heute geheim zu halten. Damit könnte man dann die Decoder z.B. jede Sekunde veranlassen, sich zu melden. Öfters sollte es nicht sein, weil sonst die Rückmeldestufe zu viel Wärme erzeugt, was weder ihr noch dem Fahrzeug drum rum gut tut.

---

Die Hoffnung, dass Herr Lindner doch ein Broadcast-Kommando versteckt hatte, stirbt zuletzt...

Zitat von Rainer Müller im Beitrag #69

---

Vermutlich einzige Möglichkeit ist, alle bekannten Decoder zyklisch anzupingen und den ACK auszuwerten: ein ACK in einem Abschnitt bedeutet dann, dass die letzte angepingte Adresse die des Decoders im Abschnitt war. Bei einem Ping alle 250ms wären da dann bei 20 mfx-Loks 5s maximale Erkennungszeit. Zur dynamischen Verfolgung eher nicht geeignet, aber um bei Betriebsstart die Positionen zu verifizieren würde das evtl. genügen.

---

Ja, dies entspricht - in etwa - der bei Railcom geübten Kanal-2-Rückmeldung. Da passiert es auch, dass - bei genügend Fahrzeugen im Refresh - der Zug den Abschnitt schon Sekunden verlassen hat, bis die Zentrale den ACK vom betreffenden Decoder endlich bekommt. Zur Notbremsung - z.B. wenn der Fahrdraht endet - zumindest bei einem ICE läßt es sich jedenfalls nicht sinnvoll verwenden. Für eine Lokalisierung der Startbedingungen ist es aber sicher hilfreich.

MfG

vik

[Sigg]

Hallo zusammen
Habe nun einen PIKO GIRUNO. Bei diesem hat zwar noch die MFX Anmeldung knapp (mit Mühe) funktioniert, aber kein Auslesen von Daten.
Schlussendlich musste ich feststellen, dass der PIKO Decoder mit ca. 8kHz anstelle 52kHz antwortet
Das selbe Verhalten habe ich dann auch noch bei einem neu gekauften ESU Lokpilot 5 Dekoder beobachtet.
Gibt es da eine MFX Änderung die das elraubt oder verstösst PIKO / ESU gegen das Proktokoll und es funktioniert z.T. einfach mehr oder weniger
Zufällig? Weiss jemand mehr?
Gruss
Dani

[est2fe]

Hallo Dani,

die 8kHz könnten aber auch von der Motor-Endstufe kommen!
Wie hast du denn das mit den 8kHz gemessen?

Gruß est2fe

[Sigg]

Kein Motor war in diesem Moment an. 8kHz genau da sichtbar, wo ich das 52kHz Signal erwarte, vorher und nachher nicht mehr.
Gruss Dani

[Sigg]

Habe noch ein paar Messungen:
Maerklin_OK.png: Antwort eines Märklin Dekoders, 52kHz gut sichtbar
Maerklin_OK_Zoom.png: Antwort eines Märklin Dekoders, mit Messung 52kHz
PIKO_NOK_Zoom.png: Gleiche Situation bei PIKO Dekoder, nichts von 52kHz zu sehen sondern nur etwas im Bereich 7.5-8KHz, es war KEIN Motor an.

[Stefan Krauss]

Hallo, Dani!

Zitat von Sigg im Beitrag #71

---

Gibt es da eine MFX Änderung die das elraubt oder verstösst PIKO / ESU gegen das Proktokoll und es funktioniert z.T. einfach mehr oder weniger
Zufällig? Weiss jemand mehr?

---

Eine mfx-Protokoll-Änderung gibt es nicht. Es würde auch Hardware-seitig nicht funktionieren, denn die heutigen Geräte nutzen einen RDS-Chip, dessen Filter fest auf die 52 kHz eingestellt sind. Die Frequenz muss sogar ziemlich gut passen, sonst lassen sich keine Daten auslesen. Die reinen Ja/Nein-Rückmeldungen werden jedoch auch dann noch recht gut erkannt, wenn die Frequenz etwas daneben ist. Aber natürlich nicht bei 8 kHz.

Woher deine verbogenen Signale kommen, kann ich dir leider auch nicht sagen. Meine Erfahrungen mit den Piko-Dekodern bzgl. mfx sind jedoch auch sehr, nennen wir es, gemischt. Aber auch nicht so, dass sie grundsätzlich nicht funktionieren. Sie sind halt noch nicht so ganz ausgereift, ist mein Eindruck. Von den ESU-Dekodern kann man das allerdings nicht behaupten. Ich würde daher eher vermuten, dass die Dekoder die Aufforderung zum Datensenden nicht korrekt empfangen oder interpretiert haben.

Grüße
Stefan