empfohlene schnittstelle

[fanta2k]

hi,

nachdem es bei mir mit dem usb interface nicht so stabil läuft (debian 64bit / intel NUC, nur USB 3.0) und ich mir deshalb für knxd noch ne andere schnittstelle zulege, meinerseits die frage - mit welcher schnittstelle läuft knxd bei euch stabil ? (evtl jemand auch gleiche hardware wie ich)

lg,

[makki]

TP-UART war und ist eine gute Wahl - würde ich immer ggü. der USB und FT1.2 bevorzugen..
Das NUC kann bestimmt - so wie jeder Rechner mit Intel-Chipsatz - auch automatisch auf USB 1.1/2.0 runter an den Ports.

Makki

[fanta2k]

leider nein, bei dem model kann man xHCI nicht deaktivieren.

aber daran liegt es vermutlich auch nicht, weil mit dem raspi (und der hat ja nur usb 2) hatte ich komplett das gleiche problem mit der 0.14 - die 0.12 und eibd liefen mit der schnittstelle.

hat denn jemand ein tpuart sauber auf nem usb 3.0 port laufen ? nich das ich dann damit das gleiche problem hab, weil zu tpuart gibt es ja auch einige timeout issues.
so wie es aktuell aussieht, veträgt sich die 0.14 nicht mit meinem merten usb interface

[makki]

xHCI (USB3) sind immer auch abwärts-kompatibel zu 2.0/1.1 - by design (man bremst damit zwar den xHCI-Hub evtl. massiv aus, aber das ist hier ja mal egal)
Also ja, jemand hat das an USB3-only-Ports am laufen (zwar kein KNX sondern was anderes mit FTDI USB-RS232) - tausendfach: ich

Also das ist nicht Dein Problem glaube ich.. Wirf den USB-KNX-HID-Emulator (der auch mit der ETS nativ nur 1-12h am Stück mitm Gruppenmonitor funktioniert, da Designfehler, war schon immer so) weg, wirste mit nem TP-UART glücklich, ich hatte noch nie ein Problem unter Linux native USB 1/2 Geräte an einem nativen USB3-Port zu betreiben.

Ich hab das uralte, erste TP-UART1 (gibts garnicht mehr) mit ATMega32 davor gerade extra für dich an ein Notebook mit USB3-only angesteckt und meine aus älteren Tagen vorh. Testroutine mit 100k Telegrammen übern Bus blasen lassen: problemlos, funzt.

Makki

[fanta2k]

ok danke

ja das mit abwärtskompatibel is klar, aber treiberseitig brauchst da dann ja extra xhci unterstützung - das läuft nicht immer sauber.

dann besorg ich mir mal ein tpuart von busware.

[marcB72]

Hallo zusammen,

da bei mir der Tpuart eben nicht stabil läuft, bin ich auf der Suche nach alternativen und bin auf diesen Eintrag gestoßen...
Hier läuft ein Banana Pi M2U mit SmartVISU und smartphone.py im ansonsten sehr stabilen 24/7 Betrieb.
Jedoch hatte ich das Problem, dass Telegrame, die ausschließlich an den Pi gehen, kein Ack bekommen haben, und somit unnötigerweise viele Wiederholungen auf dem Bus waren und dadurch teilweise auch Telegrame verloren gingen!

Genauere Recherchen ergaben, dass der Tpuart ein Ack nur dann sendet, wenn man ihm es schon während dem Empfang des aktuellen Telegram mitteilt (nach dem 6. Byte). Da dies sehr timing-kritisch ist, habe ich das mal nachgemessen. Der Befehl für das Ack kommt viel zu spät...
Der Uart-treiber berücksichtigt leider das low-latency Flag nicht und somit wird wahrscheinlich ein Fifo mit Timeout verwendet.

Ich habe hier jetzt auf der Uart Strecke einen Pic-controler der nun einfach jedes Paket bestätigt. Dennoch kommt es vereinzelt vor, dass Pakete, die vom Pi gesendet werden nicht auf dem Bus ankommen... Alle 'nativen' KNX Teilnehmer funktionieren 100%.

ich bin wirklich ratlos und überlege, den Tpuart gegen ein Ip-Interface zu tauschen - würde jedoch eigentlich das Geld sparen wollen...

Kann jemand ein Ip-Interface empfehlen? Oder hat jemand eine andere Idee?

Viele Grüße

[fanta2k]

ich hab bei mir jetzt das knxd mit dem schon vorhandenen ip router verbunden, bisher schaut es gut aus.

nutze das merten 680329