Hallo Mirko,
als Bus Interface nutze ich die TPUART von Christian mit einem Raspi und knxd, den eibd nutze ich auf einem ALIX Board mit einem Buskoppler UP2 von Merten im ft1.2 mode. Werde mir mal bei Gelegenheit den Bus-Traffic genauer ansehen.
LG
Horst
Bekannte Probleme mit der Buskommunikation
Re: Bekannte Probleme mit der Buskommunikation
Hallo Chrisstian,
... das kann dann ja nur an dem EIB-In liegen, werde das mal mit dem Oszi prüfen.
LG
Horst
... das kann dann ja nur an dem EIB-In liegen, werde das mal mit dem Oszi prüfen.
LG
Horst
Re: Bekannte Probleme mit der Buskommunikation
Hi Christian,
habe mal die SW neu gebaut, ohne Handsteuerung, mit DUMP_TELEGRAMS, RX/TX auf PIO2_7/8. Was ich auf Putty sehe sind durchlaufende Messages von allen Objekten, wenn ich den EIB-In (100pF C) auf GND lege, sehe ich nur alle 7ms ein 0xBC (erstes Kontrol-Byte eines Telegrams) als Message die der Controller sendet. Ich kenne die SW noch nicht, benötigt diese die App-Relaisplatine, die hab ich noch nicht angeschlossen. Werde mal eine Debug SW bauen (z.B. example-busmon) um das mal zu analysieren.
Die Oszi Bilder von EIB Signal sehen an der IN/Out Stufe OK aus. Konnte den Controller ja auch über die ETS programmieren.
LG
Horst
habe mal die SW neu gebaut, ohne Handsteuerung, mit DUMP_TELEGRAMS, RX/TX auf PIO2_7/8. Was ich auf Putty sehe sind durchlaufende Messages von allen Objekten, wenn ich den EIB-In (100pF C) auf GND lege, sehe ich nur alle 7ms ein 0xBC (erstes Kontrol-Byte eines Telegrams) als Message die der Controller sendet. Ich kenne die SW noch nicht, benötigt diese die App-Relaisplatine, die hab ich noch nicht angeschlossen. Werde mal eine Debug SW bauen (z.B. example-busmon) um das mal zu analysieren.
Die Oszi Bilder von EIB Signal sehen an der IN/Out Stufe OK aus. Konnte den Controller ja auch über die ETS programmieren.
LG
Horst
Re: Bekannte Probleme mit der Buskommunikation
Hallo Christian, Mirko,
ich hab mir mal die LIB wegen den geschilderten Problemen angesehen und glaube 2 Themen gefunden zu haben:
1. Übersetzen eines OBject-write-request der App im Com-Objects Modul auf Bus Telegramme mit GroupAdr. Hierbei sind, wie in der Spec beschrieben, auch lokale Objekte upzudaten, wenn sie der gleichen Gruppenadresse zugeordnet sind. Die SW ist sehr effizient gebaut, mach aber auch ein update auf das triggernde Objekt, was zu einer Endlosschleife führen kann. Des weiteren ist mir aufgefallen, das diese Funktion der Information der lokalen Objekte bei Object.-Read-request fehlt.
2. Das Problem der Programmierbarkeit mit der ETS über den knxd mit TPUART und Raspi könnte in einer Verletzung der Timings beim Senden der ACK Message auf die PhyAdrRead Anforderung mit Adr. 0.0.0 liegen. Beim Ack ist es ggf notwendig und erwünscht, dass mehrere Devices antworten, dabei kann es zu einer Verschleifung der Pulse durch Laufzeiteffekte kommen (der 35us Puls kann dabei bis 70us lang werden, wobei ggf ein kurzer Spike bis auf DC Pegel möglich ist). Das kann ein Triggern des Flankleninterrups auslösen, was die SW als Verletzung eines 1-Bits ansieht und Kollisson meldet.
Ist den Stefan Taferner noch aktiv? Er hat wohl die sehr kompakte ( aber nicht ganz einfach nachzuvollziehend) SW geschrieben. Er könnte das wohl besser beantworten ob ich da richtig oder falsch liege.
Ich hab die Lib mal mit einer Debug Info die ein empfangenes und gesendetes Telegramm inkl timing und Flags über ein serielles Interface ausgibt kompiliert, und jede empfangene PhyReadReq wird mit ACK und Kollission beantwortet.
LG
Horst
ich hab mir mal die LIB wegen den geschilderten Problemen angesehen und glaube 2 Themen gefunden zu haben:
1. Übersetzen eines OBject-write-request der App im Com-Objects Modul auf Bus Telegramme mit GroupAdr. Hierbei sind, wie in der Spec beschrieben, auch lokale Objekte upzudaten, wenn sie der gleichen Gruppenadresse zugeordnet sind. Die SW ist sehr effizient gebaut, mach aber auch ein update auf das triggernde Objekt, was zu einer Endlosschleife führen kann. Des weiteren ist mir aufgefallen, das diese Funktion der Information der lokalen Objekte bei Object.-Read-request fehlt.
2. Das Problem der Programmierbarkeit mit der ETS über den knxd mit TPUART und Raspi könnte in einer Verletzung der Timings beim Senden der ACK Message auf die PhyAdrRead Anforderung mit Adr. 0.0.0 liegen. Beim Ack ist es ggf notwendig und erwünscht, dass mehrere Devices antworten, dabei kann es zu einer Verschleifung der Pulse durch Laufzeiteffekte kommen (der 35us Puls kann dabei bis 70us lang werden, wobei ggf ein kurzer Spike bis auf DC Pegel möglich ist). Das kann ein Triggern des Flankleninterrups auslösen, was die SW als Verletzung eines 1-Bits ansieht und Kollisson meldet.
Ist den Stefan Taferner noch aktiv? Er hat wohl die sehr kompakte ( aber nicht ganz einfach nachzuvollziehend) SW geschrieben. Er könnte das wohl besser beantworten ob ich da richtig oder falsch liege.
Ich hab die Lib mal mit einer Debug Info die ein empfangenes und gesendetes Telegramm inkl timing und Flags über ein serielles Interface ausgibt kompiliert, und jede empfangene PhyReadReq wird mit ACK und Kollission beantwortet.
LG
Horst
Re: Bekannte Probleme mit der Buskommunikation
Hi Horst,
cool, dass du dich so intensiv in die Software reingräbst! Da ich leider von der KNX-Spec und der sblib viel zu wenig Ahnung habe, kann ich inhaltlich leider wenig beitragen. Aber vermitteln kann ich gerne. Mit am tiefsten im Code dürfte aktuell Denis sein.
Stefan T. ist meines Wissens nach vollständig ausgestiegen. Aber man soll ja niemals nie sagen. Ich kann ihn ja mal wieder kontaktieren, habe ich eh schon lange nicht mehr.
Ein Gedanke, der mir durch den Kopf schoss, als ich gelesen habe
Ich hatte ja mal Probleme dokumentiert, als ich die FT1.2 Schnittstelle zum laufen bringen wollte. Da hat's auch schon Probleme bei der Kommunikation der Schnittstelle mit ARM-Controllern gegeben (LPC922 Variante der FT1.2-Schnittstelle). Der ARM-Teil der Schnittstelle wollte dann so gar nicht mit dem knxd funktionieren.
Vielleicht kommen die Probleme alle von den von dir beschriebenen Timing-Problemen?
Grüße
Christian
cool, dass du dich so intensiv in die Software reingräbst! Da ich leider von der KNX-Spec und der sblib viel zu wenig Ahnung habe, kann ich inhaltlich leider wenig beitragen. Aber vermitteln kann ich gerne. Mit am tiefsten im Code dürfte aktuell Denis sein.
Stefan T. ist meines Wissens nach vollständig ausgestiegen. Aber man soll ja niemals nie sagen. Ich kann ihn ja mal wieder kontaktieren, habe ich eh schon lange nicht mehr.
Ein Gedanke, der mir durch den Kopf schoss, als ich gelesen habe
das ist kein 100% flächendeckendes Problem, soweit ich mich erinnere. Ich müsste das mal wieder genauer betrachten, aber letzte Woche hatte ich erst mit DOnatas über Slack gechattet und der hatte RPi3+KNXD+TPUART+out8(ARM) wohl so am laufen, dass er programmieren konnte.Problem der Programmierbarkeit mit der ETS über den knxd mit TPUART und Raspi
Ich hatte ja mal Probleme dokumentiert, als ich die FT1.2 Schnittstelle zum laufen bringen wollte. Da hat's auch schon Probleme bei der Kommunikation der Schnittstelle mit ARM-Controllern gegeben (LPC922 Variante der FT1.2-Schnittstelle). Der ARM-Teil der Schnittstelle wollte dann so gar nicht mit dem knxd funktionieren.
Vielleicht kommen die Probleme alle von den von dir beschriebenen Timing-Problemen?
Grüße
Christian
Re: Bekannte Probleme mit der Buskommunikation
Hi Christian,
das Problem mit der Kollision tritt nur auf, wenn mehrere Devices, die über eine längere Kabelstrecke verbunden sind auf ein request mit einem ACK/NACK/BUSY antworten (Laufzeit des Pulses: Anfrage kommt später am entfernten Device an, und die ACK Antwort braucht nochmal die Laufzeit). Ein Low Pulse ist mit mind 25us und max 70us definiert, das muss die SW gerade für größere Installationen berherrschen.
Stefan hat wirklich eine gute SW erstellt, leider recht schwieig nachzuvollziehen, und ohne die Toleranzen. Das hat schon etwas gedauert bis mir klar wurde, dass er den PWM Pulse immer von der positiven Flanke aus neu berechnet. Ich versuch mal ein Fenster für die Kollisionserkennung einzubauen und vielleicht etwas an Kommentaren einzufügen. Mir ist auch aufgefallen, dass keinerlei Fehlerinformation oder Bus BUSY an die oberen Layer weitergereicht wird.
Wenn ich Zeit finde werde ich mal was einbauen (oder ggf mal meine State Machine, die ich vor ca 12 Jahren mal für den ATMega programmiert habe portieren). Die läuft auch mit einem Timer und 2 Machtregistern.
Die alte LPC Empfangsstufe wurde 1:1 übernommen. der Ruhepegel (high level für den Eingang) liegt damit im undefinierten Bereich des ARM, denke deshalb wurde auch der C ergänzt. Der high Pegel sollte mind. 0,7VDD betragen, also größer 2,3V. Mit der akt Schaltung sind das nur ca 1,8V. Der low level sollte bei max 0,3VDD liegen, also kleiner von ungefähr 1V. Mit 91k für R8 (anstatt 47k) kommt man auf ca 2,3V. Muss man aber genauer anschauen, da sich dadurch das Pulsverhalten ändert(Innenwiderstand der Basisspannungsquelle steigt von ca 29k auf ca 43k).
Der Störspannungsabstand ist im akt Design nur 0,8V. Ferner wird durch den Überschwinger des Bus-Pulses die Basis des Transistors weit über die 3,3V getrieben, Wenn die Sperrspannung der Basis-Emitterdiode überschritten wird , raucht der ARM-Eingang (ist ohnehin sehr empfindlich) ab.
Wenn da irgendwer mal ein Redesign macht, würde ich vorschlagen, das letzte Design der freebus-Jungs für den Eingang zu nutzen, das hat damit keine Probleme und kann den Puls besser detektieren (bei der fallenden Flanke des Überschwingers kann es zu Fehlinterpretationen (Bus low) kommen.
Ich hatte auch mal den Energieverbrauch angeschaut. Der ist durch die Peripherie (Oszillator und Spannungswandler unnötig hoch. Der Oszi ( 10-12mA) verbraucht mehr als der ARM (6-10mA), der Wirkungsgrad des Wandler ist bei 50%.
Das geht mit einem Quarz und dem alten MC3063 besser- ich glaub neuere Versionen kann man auch über 100kHz betreiben und hat damit kleine C und L Werte (habe alle meine alten LPC922 und ATMegas mit 80khz laufen) und liegt damit den Schaltverlusten deutlich besser.
Ich würde da lieber den langsamen Wandler einsetzen (braucht auch nicht viel mehr Platz) und ggf die Drossel rausschmeißen und die Spannungsversorgung erst mal mit Linearregler auf 18V drücken., da kommt man ggf auf vergleichbaren Energieverbrauch.
LG
Horst
das Problem mit der Kollision tritt nur auf, wenn mehrere Devices, die über eine längere Kabelstrecke verbunden sind auf ein request mit einem ACK/NACK/BUSY antworten (Laufzeit des Pulses: Anfrage kommt später am entfernten Device an, und die ACK Antwort braucht nochmal die Laufzeit). Ein Low Pulse ist mit mind 25us und max 70us definiert, das muss die SW gerade für größere Installationen berherrschen.
Stefan hat wirklich eine gute SW erstellt, leider recht schwieig nachzuvollziehen, und ohne die Toleranzen. Das hat schon etwas gedauert bis mir klar wurde, dass er den PWM Pulse immer von der positiven Flanke aus neu berechnet. Ich versuch mal ein Fenster für die Kollisionserkennung einzubauen und vielleicht etwas an Kommentaren einzufügen. Mir ist auch aufgefallen, dass keinerlei Fehlerinformation oder Bus BUSY an die oberen Layer weitergereicht wird.
Wenn ich Zeit finde werde ich mal was einbauen (oder ggf mal meine State Machine, die ich vor ca 12 Jahren mal für den ATMega programmiert habe portieren). Die läuft auch mit einem Timer und 2 Machtregistern.
Die alte LPC Empfangsstufe wurde 1:1 übernommen. der Ruhepegel (high level für den Eingang) liegt damit im undefinierten Bereich des ARM, denke deshalb wurde auch der C ergänzt. Der high Pegel sollte mind. 0,7VDD betragen, also größer 2,3V. Mit der akt Schaltung sind das nur ca 1,8V. Der low level sollte bei max 0,3VDD liegen, also kleiner von ungefähr 1V. Mit 91k für R8 (anstatt 47k) kommt man auf ca 2,3V. Muss man aber genauer anschauen, da sich dadurch das Pulsverhalten ändert(Innenwiderstand der Basisspannungsquelle steigt von ca 29k auf ca 43k).
Der Störspannungsabstand ist im akt Design nur 0,8V. Ferner wird durch den Überschwinger des Bus-Pulses die Basis des Transistors weit über die 3,3V getrieben, Wenn die Sperrspannung der Basis-Emitterdiode überschritten wird , raucht der ARM-Eingang (ist ohnehin sehr empfindlich) ab.
Wenn da irgendwer mal ein Redesign macht, würde ich vorschlagen, das letzte Design der freebus-Jungs für den Eingang zu nutzen, das hat damit keine Probleme und kann den Puls besser detektieren (bei der fallenden Flanke des Überschwingers kann es zu Fehlinterpretationen (Bus low) kommen.
Ich hatte auch mal den Energieverbrauch angeschaut. Der ist durch die Peripherie (Oszillator und Spannungswandler unnötig hoch. Der Oszi ( 10-12mA) verbraucht mehr als der ARM (6-10mA), der Wirkungsgrad des Wandler ist bei 50%.
Das geht mit einem Quarz und dem alten MC3063 besser- ich glaub neuere Versionen kann man auch über 100kHz betreiben und hat damit kleine C und L Werte (habe alle meine alten LPC922 und ATMegas mit 80khz laufen) und liegt damit den Schaltverlusten deutlich besser.
Ich würde da lieber den langsamen Wandler einsetzen (braucht auch nicht viel mehr Platz) und ggf die Drossel rausschmeißen und die Spannungsversorgung erst mal mit Linearregler auf 18V drücken., da kommt man ggf auf vergleichbaren Energieverbrauch.
LG
Horst
Re: Bekannte Probleme mit der Buskommunikation
Hallo Horst,
interessant! Hast Du auf die Schnelle mal einen Screenshot von der Freebus Eingangsschaltung?
In der Sendestufe würde auch ein FET einiges an Platz sparen und warum bisher ein Gyrator statt der Drossel verworfen wurde, erschließt sich mir noch nicht so recht. Mehr als 50mA sind doch lt. Spec sowieso nicht erlaubt.
Der stromhungrige Oszillator (ist mit bis zu 25mA angegeben) hat mich auch gestört. Ich habe zwar eine viel sparsamere MEMS Variante herausgesucht, die ist aber unnötig teuer und verträgt kein Helium - siehe iPhone Tod in der Radiologie
Echt jetzt, der Rohm Buck läuft bei nur 50% Wirkungsgrad? Wie kommt das denn? Der sollte doch wenigsten 70% schaffen.
Mirko
interessant! Hast Du auf die Schnelle mal einen Screenshot von der Freebus Eingangsschaltung?
In der Sendestufe würde auch ein FET einiges an Platz sparen und warum bisher ein Gyrator statt der Drossel verworfen wurde, erschließt sich mir noch nicht so recht. Mehr als 50mA sind doch lt. Spec sowieso nicht erlaubt.
Der stromhungrige Oszillator (ist mit bis zu 25mA angegeben) hat mich auch gestört. Ich habe zwar eine viel sparsamere MEMS Variante herausgesucht, die ist aber unnötig teuer und verträgt kein Helium - siehe iPhone Tod in der Radiologie
Echt jetzt, der Rohm Buck läuft bei nur 50% Wirkungsgrad? Wie kommt das denn? Der sollte doch wenigsten 70% schaffen.
Mirko
Re: Bekannte Probleme mit der Buskommunikation
Also die Freebus-Baugruppen findet man noch: https://freebus.org/content/freebus-grundschaltung
@Horst: die 25mA bei 3,3V, richtig?
Oder ich hatte mal absoluten Mist gemessen. In Ruhe laufen m.E. die Module weit unter 25mA bei 29V...
@Horst: die 25mA bei 3,3V, richtig?
Oder ich hatte mal absoluten Mist gemessen. In Ruhe laufen m.E. die Module weit unter 25mA bei 29V...
Re: Bekannte Probleme mit der Buskommunikation
Hallo Mirko, Christian,
Die letzte Freebus Eingangsstufe, die ich meinte wurde auf dem RF Board genutzt und die Eingangsstufe arbeitet in Basisschaltung.
Die letzte Freebus Eingangsstufe, die ich meinte wurde auf dem RF Board genutzt und die Eingangsstufe arbeitet in Basisschaltung.
- Dateianhänge
-
-
- atmega168p_4te_rf.zip
- (95.3 KiB) 328-mal heruntergeladen
Re: Bekannte Probleme mit der Buskommunikation
..Gyrator statt Drossel geht nicht. Ziel bzw gefordert ist, dass die Stromaufnahme des Device nahezu konstant ist (Slope <0.5mA/1ms bzw <2.5mA/1ms). Wenn der DC Pegel (Bus-Ruhepegel) durch einen Pulse auf Dc-8V, durch ein sendendes Device runter gezogen wird, würde mit einem Gyrator der Strom in das Device auf Null fallen (Der Eingangs-Kondensator ist auf DCPegel geladen und übernimmt die Versorgung. Das wirkt dem dI/dt in der Drossel in der Bus-Stromversorgung entgegen und der Spannungsabfall durch den quasi Kurzschluß des Sendestufe (max 300mA) wird durch den nun fehlenden Stromfluß der angeschlossenen Devices kompensiert. Der Gyrator verhindert nur eine Stromänderung am Bus, wenn das Device mehr benötigt, dazu reduziert er die Ausgangsspannung und versucht den Stromfluß konstant zu halten.
Einige ICs (FZE1066 von Siemens, alte TPUART ) haben das dadurch gelöst, dass sie durch einen Linearregler die Spannung erst mal auf 18V reduziert haben ( 18V ist min. Busspannung vor Abschaltung der Devices, 21V mind Betriebsspannung des Bus, 0,7V min Reduktion des DC-Pegel für ein Low Signal ), damit ist die Spannung am Bus immer größer als die Ladespannung des Stützkondensators und es kommt nicht zu einer Stromabnahme während eines Low Pulses.
Den Preis den man dafür bezahlt ist die Leistung ( bei 12mA als max Device Strom: 36mW - 140mW) die ungenutzt verloren geht. Bei einer Gesamtleistung von 250mW bis 360mW sind das ca 15% -38%.
Ich hatte vor langer Zeit die Drossel eingeführt, und mal mit eine alternativen Schaltung überlegt, aber nie erprobt. Glaube Oldi hat das mal ausprobiert. Anhang ist die alte Schaltung mit Stromspiegel,... das waren erste Überlegungen, denke das muss optimiert werden, kann ggf zum Schwingen führen .
LG
Horst
Einige ICs (FZE1066 von Siemens, alte TPUART ) haben das dadurch gelöst, dass sie durch einen Linearregler die Spannung erst mal auf 18V reduziert haben ( 18V ist min. Busspannung vor Abschaltung der Devices, 21V mind Betriebsspannung des Bus, 0,7V min Reduktion des DC-Pegel für ein Low Signal ), damit ist die Spannung am Bus immer größer als die Ladespannung des Stützkondensators und es kommt nicht zu einer Stromabnahme während eines Low Pulses.
Den Preis den man dafür bezahlt ist die Leistung ( bei 12mA als max Device Strom: 36mW - 140mW) die ungenutzt verloren geht. Bei einer Gesamtleistung von 250mW bis 360mW sind das ca 15% -38%.
Ich hatte vor langer Zeit die Drossel eingeführt, und mal mit eine alternativen Schaltung überlegt, aber nie erprobt. Glaube Oldi hat das mal ausprobiert. Anhang ist die alte Schaltung mit Stromspiegel,... das waren erste Überlegungen, denke das muss optimiert werden, kann ggf zum Schwingen führen .
LG
Horst
- Dateianhänge
-