Jump to content

salvo

Members
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Hallo Borg, hast Du neue Erkenntnisse in Sachen niedriger Durchsatz bei RS485 mit der neuen Master FW?. -- Salvo
  2. Hallo Borg, ich habe auf eine meiner drei Masterbricks(die RS485 Master) testweise die neue FW draufgemacht. Positiv ist dass die Erkennung der angeschlossenen beiden anderen Master jetzt wieder funktioniert (gegen die x.3) Auffällig ist aber dass die Abfrage der Sensoren jetzt sehr viel länger dauert. Jedenfalls schaffe ich es nicht mehr die Sensoren innerhalb von 200 ms alle abzufragen. Das war bei der 1.22 noch problemlos möglich( ausser natürlich bei den Hängern) Also m.E. is da immer noch was faul. Ich lasse meine Konfiguration derzeit mit 1Mbps/s laufen. -- Salvo
  3. Hallo Borg, das klingt ja hoffnungsvoll. Hast Du denn Auffälligkeiten gefunden die die beschriebenen Phänomene erklären ? -- Salvo
  4. Hallo Borg, prima, dass sich das Problem halbwegs reproduzierbaren läßt. Viel Erfolg bei der weiteren Suche ! --Salvo
  5. Ok,danke, dann ist die größere Programmlänge erklärt. Mit Led Blinken meine ich nicht den Anfang sondern während des normalen Betriebes. Mit der V1.22 ist das Blinken schneller, eher so ein Flackern. bei der 1.23 ist es langsamer und es flackert weniger. Liegt villeicht an den größeren Timeouts... Aber das wäre mir ja wurscht. Die 1.23 kriege ich in der absolut gleichen HW konfiguration de facto nicht ans Laufen. Die Bricklets werden teilweise erkannt (mal mehr, mal weniger) , aber auch nicht immer. Dann gibt es schnell immer häufiger Fehler bei der Abfrage, dann geht garnichts mehr. Dann muss alles resetted werden, dann beginnt das Spiel von vorne. bei der 1.22 läuft das Ganze meistens zwischen 10 und 30 Stunden durch ohne probleme, dann gibt es auch ab und an Hänger. Vielleicht liegt es ja daran dass bei mir wegen der größeren leitungslänge mehr Fehler auftreten die sich dann anders auswirken. Aber wie gesagt, es macht praktisch (in Sachen Hänger) keinen unterschied ob ich 500 oder 2000 Kbps Datenrate einstelle.
  6. Also selbst wenn es ginge wird 3 dB mehr TX-Leistung kaum viel helfen. Da sind andere Einflussgrößen (Reflexionen, Wände, Antenne) drastisch wirksamer. Eine bessere (Richt) antenne würde schon viel mehr bringen, zumal diese nicht nur beim Senden sondern auch beim Empfangen eine Verbesserung bringt. Meiner Erfahrung sind die Chibis aber ( zumindestens war es bei mir so ) sowas von taub, dass sie für sinnvolle Anwendungen eh nicht brauchbar sind.
  7. Ich habe wieder die 1.22 Firmware draufgemacht. Meiner Meinung nach hat die 1.23 ziemliche Macken und sie verhält sich auch ganz anders. Alleine an der Led ist das schon deutlich zu sehen. Alles funktioniert jetzt wieder wie vorher (wenn auch nicht wirklich zufriedenstellend, aber deutlich besser als die 1.23) Schließlich hat die 1.23 auch 6KB (bei 74 K Programmlänge ist das schon recht viel) mehr als die V1.22, das ist m.E. mit ein paar Timeouteinstellungen nicht zu erklären. -- Salvo
  8. Ich habe insgesamt 10 Bricklets angeschlossen (3x Ambient Light, 4x Temperatur, 2 x IO4, 1 IR Distanzsensor), die alle 200 ms abgefragt werden. Mir scheint mit der neuen FW auch die Enumeration viel länger zu dauern als mit der 1.22. Auch im Brickviewer erscheinen die Masterbricks viel langsamer.
  9. Hm, ich habe auf allem meinen drei Master bricks die neue Firmware geflashed. Der erste Eindruck ist dass es eher noch instabiler geworden ist. Mit der vorherigen FW Version lief das Ganze meistens so ca. 20Stunden, bis die Kommunikation zusammenbrach und nur noch ein Reset geholfen hat. Mit der neuen FW bringe ich nur nach mehrfachen Versuchen mit Powerdown/up einen Betrieb hin, der aber nicht lange anhält. Ich habe 500Kbs und 2000kbs probiert, das macht aber jetzt und auch mit der alten FW keinen reproduzierbaren Unterschied. Was mir auffallen ist dass das Led Geflacker an der Master Extension deutlich weniger geworden ist. Heisst das dass der RS485 Paketverkehr jetzt anders gestaltet ist ?. Ich habe den Eindruck dass es in der Firmware Zustände gibt aus denen man nur mit einem Reset bzw. Powerdown wieder rauskommt. Kann man die Firmware nicht so gestalten dass z.B. durch Timeouts sichergestellt wird dass diese Hänger nicht passieren? --Salvo
  10. Hm, gudev habe ich installiert. Ich sehe auch keine Meldung. Wenn gudev fehlt, müßte der Daemon das doch auch im Log anzeigen... -Salvo
  11. Jetzt wird es dubios. Nachdem ich die letzten Bindungs (1.18 glaube ich, vorher war es 1.17) gestern abend noch eingespielt habe geht es jetzt plötzlich. Nichts an der Hardware bzw. Verkablelung habe ich verändert. Ich werde die Sache jetzt mal längere Zeit laufen lassen und schauen ob es stabil bleibt. Grübelnd, Salvo
  12. Hallo Borg, ich habe einmal beide Slaves gesehen. Aber wie gesagt ich habe verschiedene Geschwindigkeiten probiert und das macht keinen reproduzierbaren Unterschied. Das mit den kürzeren Kabeln werde ich demnächst mal ausprobieren, aber momentan bin ich etwas zu frustiert :-( Der Brickd hört auf zu arbeiten wenn ich den USB Stecker abziehe. Wenn ich ihn neu starte funktioniert es wieder. Das Log habe ich angehängt. ich habe OpenSuse 12.1 im Einsatz und dne aktuellen brickd. Vielleicht hilft es Euch ja.. brickd.log
  13. Hallo Borg, erst mal Danke dass Ihr Euch so schnell kümmert. Ja die Konfiguration ist fast identisch wie von Dir beschrieben ausser dass ich die beiden Slaves per DC/DC versorge, dass ich zwischen Master und 1 Slave ca. 50m Kabel (CAT5) verwende und der 2. Slave (Terminierung On) nochmal per 10 m langem (CAT5) Kabel (von 1. Slave aus gesehen) angeschlossen ist. Ich habe mit verschiedenen Bitraten experimentiert aber das scheint keinen grossen Unterschied zu machen. Erst schien es als ob es mit 250KBs besser funktionierte, aber jetzt läuft die Kommunikation zwischen Master und 1. Slave wieder mit 1Mbbs und das geht auch. Problem ist der 2. Slave der nicht ansprechbar ist, wenn ich beide Slaves in der Adressliste des Masters angebe. Die Slaves schalte ich immer zuerst ein, dann den Master. (Das wäre noch ein gutes Feature wenn man im Master die Konfiguration noch mal anstossen koennte und nicht jedesmal ausschalten muss. Das mit dem Reset hätte auch den Effekt, aber dann crasht regelmäßig der Brick Daemon bei mir unter OpenSuse 12.1 und das ist dann auch keine gute Lösung). Hauptproblem für mich dass das Verhalten (geht, geht nicht) für mich a) nicht absolut reproduzierbar ist und allee Erklärungsansätze die ich bisher hatte mir nicht wirklich schlüssig erscheinen. Peter
  14. Die Endgeräte sind jeweils terminiert, das "mittlere" nicht. SO wie es sein soll und ich habe die 60 Ohm über der RS485 Leitung gemessen. Und wie gesagt: Das Gerät dass ich in der Adressliste des Masters angebe funktioniert auch. Gebe ich beide Slave Adressen ein, funktioniert das erste in der Liste, das zweite nicht. ALle Master habe ich mit der neuesten Firmware vor ein paar Tagen geflashed. Mit der älteren Firmware geht die RS485 Extension ja eh nicht.
  15. Ich habe drei Master Bricks mit je einem RS485 Extension Modul verschaltet. Die RS485 am USB Master ist als master geschaltet, die anderen beiden haben die Slave Adressen 2 und 3. Mit dem Brickviewer kann ich nach dem Einschalten 2 Masterbricks sehen, der Dritte(Slave) bleibt verschwunden. Wenn ich in der Adressliste des RS485 Masters immer nur einen Slave angeben findet sich auch immer genau dieser im brickViewer. Wenn ich beide SlaveAdressen angebe, ist immer der Masterbrick zu sehen dessen Slave Adresse an erster Stelle in der Adressliste steht. Daher würde ich ein HW oder Kommunikationsproblem ausschliessen. Eher tippe ich auf einen Bug in der Firmrware oder im Protokoll. Irgendwie scheint die Erkennung der angeschlossenen Slaves nur vernünftig zu funktionieren wenn nicht mehr als ein Slave angeschlossen ist. Ich wäre für eine Idee oder noch besser ein Abhilfe dankbar, denn so ist das Ganze noch nicht brauchbar.
×
×
  • Create New...