Beiträge von redPanther

    wir brauchen was reproduzierbares. Also am besten ein effekt der das problem produziert und virtuelle leds (https://github.com/redPanther/hypersim). Wenn wir das damit hinbekommen, dann sollte sich der fehler leicht finden lassen.


    Vom code her, wird smoothing und farbkorrektur vollkommen gleichwertig auf effekte und grabber angewandt (bzw. es ist an dem punkt wo die farbkorrektur gemacht wird, garnicht mehr zu sehen wo die led daten herkommen) - damit sollte es erstmal keinen unterschied geben, ob die daten vom effekt oder vom grabber kommen.


    Was ich auch spannend finden würde, ob der fehler auftritt wenn man die ganze farbkorrektur weglassen würde. Aktuell kann man die noch nicht via config umgehen, man müßte im code
    https://github.com/hyperion-pr…yperion/Hyperion.cpp#L877
    ledcolors durch priorityInfo.ledColors ersetzen und dann wird keine Korrektur vorgenommen.

    ich ändere die einstellungen direkt in der konfig - sollte aber kein unterschied machen.
    Vielleicht hat es was mit der ledhardware zu tuen?
    Meine led hardware ist sehr anders als deine, vielleicht bekomme ich den effekt deswegen nich hin.
    Ich sende via tcp an einen serverdienst, der dann eine hardware namens "fadecandy" bedient. Daran hängen 2 ws2812 a ca. 64 leds.


    Das nette ist, das ding kann smoothing/interpolation gleich in hardware. Für die tests hab ich das natülich ausgeschaltet gehabt ...


    @Brindosch, du hast das phänomen doch auch beobachtet, vielleicht kannst du noch infos beisteuern

    hmmmm, ich kanns beim besten willen nicht reproduzieren. Was ich sehe, ist wenn die parameter (time und updatefrq) ungünstig sind, dann gibts komische effekte ....



    getestet habe ich mit nem effekt der "grelle" farben produziert und dann auf schwarz schaltet.


    import hyperion, time
    while not hyperion.abort():
    hyperion.setColor(255, 15, 15)
    time.sleep(0.5)
    hyperion.setColor(0, 0, 0)
    time.sleep(0.5)
    hyperion.setColor(15, 255, 15)
    time.sleep(0.5)
    hyperion.setColor(0, 0, 0)
    time.sleep(0.5)
    hyperion.setColor(15, 15, 255)
    time.sleep(0.5)
    hyperion.setColor(0, 0, 0)
    time.sleep(1)


    Vom code her kann ich nur sagen, das das alles gut aussieht. Das einzige was mir da potenziell gefährlich aussieht ist die verwendung von dezimalzahlen. Das kann durchaus mal ungenau bei berechnungen werden (rundungsfehler, verlust der genauigkeit beim int casting, ...)


    Da aber der effekt schon von anderen gemeldet wurde, muss da natürlich was dran sein.

    Probier mal was mit der frequenz. Die muss ne ganzzahl sein also nich 30.0 sonder 30. Der wert muss bei der division 1000 / frq keinen rest liefern. Also 30 liefert nen rest. Nimm doch mal 25 ....

    Ich schau mir das heut abend mal an. Das prob is ja auch nich neu. Ich glaube die kombi backlight + smooth hat irgendwas. Kannst mal schauen ob das prob auch mit deaktiviertem backlight noch da is?

    hi, kannst mal deine config via pastbin (o.ä.) hier posten ... das machts etwas einfacher dein problem nachzuvollziehen.


    > Leider sieht es noch immer so aus als hätte sich bei dunklen Szenen die letzte Farbe eingebrannt.


    Ist der effekt ohne smoothing auch vorhanden?
    Nebenbei ich hatte bisher auch eher zweifel das "eingebrannte" farbe an smoothing mit deaktivierten continuous output liegt. Denn da wurde, falls keine neuen daten vorhanden waren immer die letzten LED farben gesendet.
    Es gab im smoothing wirklich ein bug, dieser trat aber nur auf bei continuousOutput=false und updateDeley>0. Dies ist jetzt behoben.


    Es könnt sein, das der Fehler ursächlich garnicht im smoothing liegt ... leider kann ich den effekt nicht reproduzieren, daher ists schwer mit der fehlersuche.

    > Is there any software for windows so i dont even need the RPI to run hyperion and i can run it on the pc altogether?


    hyperion is currently linux only. There are posibilities for porting, but this will take longer time. Perhaps you can try runing hyperion in virtual box. Install a linux in virtualbox (e.g. latest debian) and then install virtualbox tools and hyperion there. Activate usb passthrough in virtualbox and pray that it works (usb passthrough can work, but I'ts a bit "plug'n'pray")

    if "updateDelay" in smoothing is used, this would always freeze colors earlier as it should. if updateDelay is not used, it should work as expected - or better say I didn't notice any problems with that and the code looks good to me in that case.


    I will make a fix in hyperion repo for updateDelay issue