freebus.org

Hallo Idefix,

hab die neue AVR Firmware für den 8in aufgespielt.
Programmieren der PA und der Parameter funktioniert im Mischbetrieb mit LPC Controller
bestens. Keine Probleme beim Programmieren.

Habe bei mir den 8inLPc gegen den 8inAVR getauscht.
Ich betreibe den 8in zum ansteuern meiner Rollladen.
Hier ist mir aufgefallen, dass beim AVR die Funktion AUf/AB vertauscht ist.
In der ETS ist "AUf" eingestellt, der Rollladen fährt "AB". Bei Einstellung "AB" ist es genau umgekehrt.

Auch ist mir aufgefallen, dass bei Eingang 1,3,5 und 7 immer ein Stopp Telegramm nach loslassen des Tasters gesendet wird.

Bei Eingang 2,4,6 und 8 wird kein Stopp Telegramm gesendet, so dass mein Rolladen wie gewünscht hochfahren kann.

Gruß Jens

Hallo Jens,

danke für die Meldung, wir schauen rein und suchen woran es liegen kann.

_________________
Gruß
Matthias

Hallo Jens,

sei doch bitte so nett und leg dafür ein Ticket an, nicht das es vergessen wird:
http://bugs.freebus.org/projects/ftt/issues/new

Danke Dir.

_________________
Gruß
Matthias

Die Sache mit dem UP/DOWN scheint klar. Sieht man schon im Code das hier was anderes gesendet wird als in der LPC version.
Ich werde das mal ändern.

Die Sache mit dem Stop auf den Eingängen 1,3,5,7 ist nicht so offensichtlich. Muss getestet werden ....

hallo

musste heute zum 2 mal feststellen, dass nach betätigen der Taster kein
Rollladen fährt. Nach Aufzeichnen der Telegramme hab ich festgestellt, dass keine
Telegramme vom 8in an den Bus gesendet werden.
Beim drücken des Prog Tasters, blinkt die Programmier LED.

Gruß Jens

Wenn das prog-led blinkt bedeutet es, er ist im Panicmodus, das sollte nie passieren und ist ein Hinweis, das etwas richtig schief gelaufen ist.
Du hast die aktuelle Version aus dem Downloadbereich drauf?

Kannst es reproduzieren, wann es genau auftritt?

_________________
Gruß
Matthias

@jens78: kannst du nachvollziehen wie es zu dem zustand kommt ?
nach strom-ein sollte es ja mal gehen, danach gibts aktionen bzw. telegramme die zu diesen zustand führen.

btw, die sache mit dem stop auf 1,3,5,7 dürfte daran liegen, dass die timeout werte für diese eingänge falsch aus dem eprom gelesen werden.

Hallo,

also nach Strom ein funktionierts wieder.
Werde heute mal versuchen die Telegramme aufzuzeichen.
Bis jetzt kann ich bnicht sagen woran es liegt.
Hab nach dem Reset die Taster einigemale betätigt und die Jalousie ist gefahren.
Am nächsten Abend wieder versucht die Jalousie zu fahren, ab er es ging nicht mehr.

Gruß jens

Hallo zusammen,

ich hab so ein Ding mal ausprobiert und hab das Problem möglicherweise eingrenzen können. Es sieht so aus, als ob das Problem dann auftritt, wenn die Länge eines empfanegnen Telegramms nicht korrekt ist bzw. ganze Teile eines davon fehlen. Das dürfte intern einen Fehler auslösen, der anders behandelt wird als ein NACK. Nach dem exakt 8ten mal geht dann das Gerät in den Panik Modus. Anscheinend läuft dann ein Speicher über. Wenn nur Bits im Telegramm umfallen wird korrekterweise ein NACK gesendet ohne dass der Speicher überläuft. Anscheinend wird bei einem solchen Fehler das Telegramm nicht mehr aus dem Speicher gelöscht. Da ich den Sourcecode nicht kenne kann ich das Problem nicht weiter eingrenzen. Wenns neue Versionen zum Testen gibt stell ich mich gern zur Verfügung...

Nur ne Frage: Sollts sowas wie den Panik Modus überhaupt geben (auch wenn er nie auftreten dürfte)? Der Modus wird ja offenbar gestartet, wenn der Telegrammspeicher voll ist, was ja auch nie passieren sollte. Wärs da nicht gut statt dem Panikmodus einen Notanker ein zu bauen und z.B. den Speicher einfach wieder frei zu machen, od Watchdog -> Restart? Datenverlust - klar, aber immerhin funktioniert das Gerät noch... Zu Entwicklungszwecken könnte man ja die LED vorher ein paar mal blinken lassen, wenns denn wirklich nötig ist den Status an zu zeigen.

lg knx_fan

Hallo knx_fan,


super vielen Dank, für diese Einschränkungen, schau mir bei schlechten Wetter mal an, wieso es zu diesem Fehler kommt und stelle dann eine neue Version zur Verfügung.


ja und nein. Der Panik Modus wird aufgerufen, wenn ein kritischer Fehler auftritt. Klar könnte man einen watchdog aktivieren, der dann das Gerät neu startet, aber dann würden diese Fehler nie auffallen und in Folge dessen auch nicht behoben werden. Wer sitzt schon an dem Gerät und beobachtet ob das Prog LED blinkt?
Primäres Ziel ist es das Gerät so robust zu machen, das kein watchdog benötigt wird.

_________________
Gruß
Matthias

wie hast du es geschafft so ein kaputtes Telegramm zu schicken?
Muss mir genauer anschauen, was da passiert, dafür muss ich es schaffen so ein Telegram am Bus zu schicken.

_________________
Gruß
Matthias

Ich hab mehrere solche Geräte am Bus betrieben und hatte bei einem hardwaremäßig ein Problem sodass nur der erste Teil eines Telegramms von den anderen Geräten empfangen werden konnte. Das hat den Fehler dann ausgelöst. Du kannst das reproduzieren indem du die Versorgungsspannung von einem der µCs reduzierst (2V...2V5). Das führte bei mir dazu, dass beim FET der Sendestufe nur mehr zu Beginn des Telegramms die nötige Spannung am Gate zum vollen Durchschalten erreicht wurde. Der hintere Teil des Telegramms kommt nur mehr verstümmelt und wird von der Freebus eingangsstufe nicht mehr korrekt empfangen.
Es dürften aber auch eine oder sehr wenige Flanken am Bus (ohne dass ein eigentliches Telegramm kommt) reichen. Zumindest konnte ich das später bei Störungen, die durch einen größeren Verbraucher in der Nähe verursacht wurden, beobachten. Allerdings konnte ich das schlecht reproduzieren. Wollte mir dazu noch einen Taster + Widerstand basteln um einzelne Flanken zu generieren, bin aber dann nicht mehr dazu gekommen.
Ich hoffe du kannst mit dieser dürftigen Beschreibung was anfangen...

Hallo Idefix,

habe dazu mal eine Grundsätzliche Frage, kann es sein, das dies Problem auch beim LPC auftreten kann?
Wenn ja sollte man es auch dort gleich angehen und lösen, das klingt ja eher nach einem Grundsätzlichen "Fehlverhalten".

Gruß

Andy

Hallo,

mir ist dazu noch was eingefallen: eigentlich dürfte es mit einer einzelnen Flanke ja kein Problem geben weil die Spec vorsieht, dass wenn innerhalb einer gewissen Bitezeit (50 od. 53 wenn ich mich recht erinnere) kein 0 kommt, der Bus ja wieder "frei" ist und das bis dahin empfangene Telegramm zu verwerfen ist (also auch kein NACK). Ich denke mal, ihr habt das sicher in eurem physikal Layer berücksichtigt... Wäre es möglich, dass der Mechanismus vielleicht nicht richtig funktioniert?

lg knx_fan

@Andy_BN
wenn das beim LPC auch so ist, schreib dafür bitte einen neuen Beitrag, hier geht es um den AVR nicht den LPC.

@knx_fan
Ein zittern auf dem Bus ist kein Problem, das wird von der AVR SW ignoriert.

Mein Problem ist, ich muss rausfinden wo in der Statemachine er sich befindet, damit ich das Problem eingrenzen kann, das ist nur möglich wenn ich fehlerhafte Telegramme verschicken kann.

Muss die Firmware wohl mal dahingehen umschreiben, das diese fehlerhafte Telegramme schickt und das mit einem zweiten Board debuggen, wird wohl etwas mehr Arbeit werden.

_________________
Gruß
Matthias