freebus.org

Hallo,
ich betreibe einen kommerziellen EIB Raumtemperaturregler (RTR) mit 4-fach Schaltern zusammen mit Freebus Komponenten (8out, 4out, 2in2out, 2-fach Dimmer). Dabei ist mir aufgefallen, dass alle Telegramme, die vom RTR an den 2in2out und an den Dimmer gesendet werden, vom RTR 3 Mal wiederholt werden (sichtbar auf dem Gruppenmonitor und auf dem Busmonitor). Ich habe mehrere 2in2out im Einsatz. Der Effekt tritt bei allen 2in2out auf. Beim 8out und beim 4out (und einer anderen kommerziellen Komponente) tritt der Effekt nicht auf.
Wenn ich den 2TE Kontroller der 2in2out mit einem 8out oder einem 4out programmiere, tritt der Effekt nicht auf. Ein Hardware Defekt (alleine) kann daher ausgeschlossen werden.
Kann es sein, dass die 2in2out Software die Telegramme nicht korrekt annimmt oder nicht korrekt bestätigt?
Die Kommunikation der Freebus Komponenten untereinander funktioniert einwandfrei und ohne Wiederholungen.

Danke für die Hilfe im Voraus.
Grüße
dgra

Unsere Software teilt sich in den systembereich und dem apllikationsbereich auf.

die 2in2out , in8, jalousie haben gleiche systemsoftware.
die out8,Tastersoftware haben gleiche systemsoftware.

das ACK wird von der systemsoftware generiert, es ist aber ein
Vorhandensein der gesendete gruppenadresse im Empfänger nötig,
sonst erfolgt kein ACK und wenn auch kein anderes gerät diese GA
programmiert hat, wird das Telegramm wiederholt.

_________________
LG
Andreas

Hallo oldcoolman!

Wenn ich den 2TE Kontroller mit der 2in2out Software programmiere und natürlich die Gruppenadresse zuordne und der RTR ein entsprechendes Telegramm sendet, schaltet der Kontroller korrekt. Trotzdem wiederholt der RTR das Telegramm drei Mal.
Wenn ich den gleichen Kontroller mit der 8out Software programmiere und natürlich die Gruppenadresse zuordne, schaltet der Kontroller ebenfalls korrekt, die RTR sendet das Telegramm aber nur einmal.

Eine mögliche Erklärung wäre, dass das ACK im Falle der 2in2out Software (aus Sicht des RTR) nicht oder nicht korrekt gesendet wird. Im Falle der 8out Software dagegen aber erfolgt das ACK (aus Sicht des RTR) korrekt.

Was ist der Unterschied für das Senden des ACK in den beiden Systemsoftware Versionen? Welche Systemsoftware Version hat der 2-fach Dimmer?

Ist es möglich, dass ich die den Software Code für die beiden Systemsoftware Versionen bekomme?

Vielen Dank für die Hilfe im Voraus.

dgra

Hallo dgra!
Die fehlende GA scheidet also aus. (konnte ich nicht wissen )
Ich vermute ein timing Problem haarscharf an der Grenze.
Die alte backend soft tut hier nicht mehr, die neue schon.
Dimmer ist auch alte backend.
hast du Frequenzmessmöglickeit? Ein Multimeter mit 'Hz' würde völlig reichen.
Hier bitte mal die PWM wenn out8 geflasht messen und mitteilen.

_________________
LG
Andreas

Hallo oldcoolman,

habe wie im Chat besprochen eine Strommessung an einem 12Ohm Widerstand in der Busleitung am Kontroller (10Ohm hatte ich nicht) gemacht. Anbei das gemessene Signal. Zumindest antwortet der Kontroller. Ich verstehe allerdings nicht, wieso die Peaks so unterschiedlich hoch sind. Ich habe während der Messung den BusMonitor mitlaufen lassen. Die RTR hat das Telegramm vier Mal gesendet.
Kannst Du das Antwortsignal interpretieren?
Danke für die Hilfe im Voraus.
Grüße
dgra

Hier noch zwei Messungen.
Die eine zeigt, dass vier Mal geantwortet wird (RTR sendet das Telegramm ja auch vier Mal). Die zweite zeigt das komplette Antworttelegramm (ein Peak hatte auf der ersten Messung gefehlt).

Habe die gleichen Messungen auf dem gleichen Kontroller mit der out8 Applikation wiederholt. Man erkennt deutlich die Unterschiede in der Signalform.
Zur Erinnerung: Beim in2out2 sendet der RTR die Telegramme drei Mal, beim out8 nur einmal.
Warum sind die Signalformen für den in2out2 anders als beim out8?
In allen Fällen war der Quarz aktiv.

Ich habe eine Zwei-Kanal-Messung gemacht mit einem 2in2out und einem out8, die beide die gleiche Gruppenadresse haben. Auf dem Kanal A (gelb) habe ich das Bus-Signal aufgezeichnet, auf Kanal B (violett) habe ich die Strommessung (Spannungsabfall an einem 12Ohm Widerstand in der Busleitung) am Bus des 2in2out aufgezeichnet. Den Trigger habe ich auf Kanal B gesetzt, so dass in Kanal A das ACK Signal auf dem Bus vom 2in2out und vom out8 (beide schicken auf das gleiche Telegramm gleichzeitig ein ACK) aufgezeichnet wird.
Es ist deutlich sichtbar, dass der out8 sein ACK-Signal ca. 50µs vor dem 2in2out schickt. Bei der Überlagerung der beiden ACK-Signale entstehen entsprechend lange Pulse, die durch die beiden etwas unterschiedlichen Pegel der Signale etwa in der Mitte des Pulses eine Stufe haben.
Die Messung zeigt deutlich, dass das Timingverhalten des 2in2out und des 8out unterschiedlich sind. Das könnte auch meine Beobachtung mit der RTR erklären.
Da das unterschiedliche Verhalten auf der gleichen Hardware, allein durch Laden des anderen Programms, erzeugt werden kann, bleibt nur der Schluss, dass das Timingverhalten von der geflaschten Software abhängt.

Auf Grund der Probleme habe ich mir die Software näher angeschaut und bin auf folgende Zeile im File 2te_prot.c des 2in2out Projektes gestoßen:

"set_timer1(4830); // 4720 und neu starten fuer korrekte Positionierung des ACK Bytes"

Vergleicht man das mit dem entsprechenden Eintrag im File fb_prot.c der com-Files

"set_timer1(4720); // 4720 und neu starten fuer korrekte Positionierung des ACK Bytes"

liegt der Verdacht nahe, dass die 4830 im File 2te_prot.c durch eine 4720 zu ersetzen ist.

Ich habe die Änderung durchgeführt und (nach einem längeren Kampf mit dem Software Entwicklungsenvironment) ein neues hex-File für den 2in2out generiert und in die gleiche Hardware wie vorher geladen.

Mit der neuen Software läuft der 2in2out (so weit ich testen konnte) einwandfrei. Die RTR sendet die Telegramme an den 2in2out nur ein Mal (und nicht vier Mal). Weiterhin habe ich die 2-Kanal-Oszilloskop-Messung wiederholt. Die Messung zeigt eindeutig, dass das ACK Signal jetzt eine "saubere" Form hat. Ich gehe daher davon aus, dass der Timer1 in der Software auf 4720 zu setzten ist (wie im Kommentar angegeben).
Ich habe das neue, von mir erstellte Hex-File beigefügt.
Viele Grüße
dgra

Hallo grga,
wir müssen klären wo jetzt der Haken liegt.
Die ACK waren bei beiden auf die µs genau ausgerichtet(hörensagen):
wenn da jetzt wie man sieht ca 35µs Versatz drin sind, muss sich da ein
gravierender Denkfehler eingeschlichen haben.

Hast du die Spec zu hand? bezüglich timing?

_________________
LG
Andreas

Hallo oldcoolman,

ich habe außer den bei Freebus abgelegten Dokumenten keine Spezifikation.

Ich hatte auch schon überlegt, wie ich das absolute Timing (Zeit zwischen Telegramm-Ende und Beginn ACK) mit dem Oszi messen kann. Leider ist der Speicher von meinem Oszi dazu nicht ausreichend.

Grüße

David

Hallo oldcoolman,
nachdem ich eine Nacht über das Ergebnis geschlafen habe, hier noch einmal eine Zusammenfassung meiner Erkenntnisse:
1) Der kommerzielle Merten RTR funktioniert einwandfrei mit anderen kommerziellen BCUs (Universaltaster von Gira) und mit dem Freebus out4 und dem Freebus out8. Es sind keine Telegrammwiederholungen auf dem Bus sichtbar.
2) Sobald ein 2in2out dazugeschaltet wird (ich habe es mit mehreren ausprobiert) kommt es wiederholbar zu Telegrammwiederholungen.
3) Da die FT1.2 die Telegramme ebenfalls bestätigt, zeigt die letzte Messungen auch, dass das ACK des FT1.2 und des out8 zeitlich zueinander passen.
4) Die vorherigen Messungen zeigen (bei gleichem Aufbau und gleicher Hardware), dass durch den 2in2out eine Änderung des ACK Signals auftritt.

Wie wurde das ACK Signal der 2in2out auf die µs gleich ausgerichtet? Gleich mit welcher Applikation? Kann man das Experiment wiederholen? Kann es sein, dass man die steigende Flanke auf die fallende ausgerichtet hat?

Warum sollte in der Software der timer1 einen anderen Wert beim 2in2out haben, als in der Library (die für andere Programme verwendet wird)?

Bin gespannt, wie sich das Rätsel auflöst. Auf jeden Fall vielen Dank für die Unterstützung, auch an Erik (Hilfe beim SW Environment).

Viele Grüße
David

Für mich stellt sich da nur die Frage warum da was an der ack Position gedreht wurde.
hab das jetzt recht schnell durchgelesen gehabt und dein Posting mit settimer
übersehen.
Ich habe in der alten soft, die ja so dachte ich auch in 2in2out verwendung findet,
set_timer(4720) gesehen. Das ist auch der normal Wert.
Normalerweise benutzen wir die Prot.c als gemeinsame Datei, warum der 2in2out eine extra bekam
müssen wir den Entwickler fragen.

Wegen lib, hier sieht die software völlig anderst aus, es ist also nicht so ,dass die lib nur die
von dir gesehene software in lib gebunden ist.

ich müßte in den spec nachsehen, ack ist auf jeden fall in ganzen bit Abständen 1/9600 zum stopbit
spezifiziert. Dumm hier, dass das stopbit stehts 1 ist. man muss also auf parity oder letzten
Datenbit messen und rumrechnen.

Ich danke Dir vielmals für deine Mühen, du hast einigen sicherlich reichlich Frust erspart.

_________________
LG
Andreas

Hallo oldcoolman,

danke für die Bestätigung.
Leider ist das Thema nicht ganz zu Ende. Der 2-fach Dimmer zeigt den gleichen Effekt.
Ich bin noch nicht dazu gekommen, nachzusehen, ob da der gleiche Timer (mit dem falschen Wert) verwendet wird.
Ist meine nächste Aktion.

Vielleicht kannst Du mir einen Tipp geben.

Viele Grüße

David

Hallo David,
ich sehe erst mal keinen Grund dafür, warum der 2in2out eine spezielle backendsoftware nutzt.
In meiner gemeinsamen Datei steht :
set_timer1(4720); // 4720 und neu starten fuer korrekte Positionierung des ACK Bytes
Damit habe ich mir auch den Dimmer compiliert.
Eventuell wurde ja der 2 fach dimmer mit anderem Wert compiliert.
Check das bitte nochmal durch. Wichtig für uns zu wissen,ob die Datei im DL fehlerhaft ist.

_________________
LG
Andreas