WordClock mit WS2812

[0xef (Gast)]

Hallo Frank,

Da hab ich den Code nicht richtig vestanden.
So wie du es beschreibst, wäre es richtig.
Aber ich komm einfach nicht drauf, was den DMA-IRQ lange genug 
blockieren könnte und durch den ldr-ausgelöst wird.

Die andere Idee war, dass evtl. eine Race-kondition nach dem berechnen 
der ersten 2 LED's den Zeiger neu initialisiert und damit die ersten 2 
leds nochmal berechnet. (ausgelöst duch 
ldr-änderungen->ws2812_refresh()).
Aber du hast das gut gegeneinander gelockt, soweit ich den code richtig 
lese.

Und: warum nur bei diesem user? warum hat sonst keiner das Problem?
(Oder meldet sich sonst keiner?)

0xef

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> - evtl. doppelt sovile LED-Daten berechnen (Puffergröße verdoppeln ->
> mehr Zeit, bis es kritisch wird).

Ja, das wäre eine Möglichkeit. Bei der Vorausberechnung der Werte für 4 
LEDs statt 2 bleibt mehr Zeit für anderes.

> - Priorität des DMA-Interrupt erhöhen? bisher laufen ja alle auf
> gleicher Prio.

Das kann ich nicht nachvollziehen. Auszug aus ws2812.c:

    dma.DMA_Priority            = DMA_Priority_VeryHigh;                    // DMA_Priority_High;
...
    nvic.NVIC_IRQChannelPreemptionPriority  = 0;
    nvic.NVIC_IRQChannelSubPriority         = 0;

vs. Timer-Interrupt in main.c:

    nvic.NVIC_IRQChannelPreemptionPriority  = 0x0F;
    nvic.NVIC_IRQChannelSubPriority         = 0x0F;

]

Somit hat der Timer-Interrupt in main.c die niedrigste Priorität und 
diejenige in ws2812.c die höchste Priorität. So habe ich es jedenfalls 
verstanden.

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> Und: warum nur bei diesem user? warum hat sonst keiner das Problem?

Ich habe bisher 3 gezählt.

> (Oder meldet sich sonst keiner?)

Tja, das ist die Frage.

[Mirco D. (bpoh_voodoo)]

0xef schrieb:
> Warum das pixelmuster in diesem Szenario genau 2 leds springt, verstehe
> ich aber nicht.

Ähh, ich will euch ja nicht ärgern oder so, aber das sind nicht immer 2 
LEDs. Manchmal auch nur eine. Am häufigsten jedoch 2. Oder das ist nur 
zu schnell und ich erkenne nur das Verschieben von einer. Kann auch 
sein.

[Frank M. (ukw) (Moderator)]

Nach längeren Recherchen habe ich einen Hinweis erhalten, der vielleicht 
was bringt. Und zwar soll man beim STM32 den Systick-Handler vor allen 
anderen Interrupts mit ihren Prioritäten initialisieren, sonst könnte 
das mit den Prioritäten-Steuerungen schiefgehen:

Bisher stand in main.c:

    timer2_init ();                                                         // initialize timer2 for IRMP, DCF77, EEPROM etc.
    delay_init (DELAY_RESOLUTION_5_US);                                     // initialize delay functions with granularity of 5 us

Ich habe das mal umgedreht:

    delay_init (DELAY_RESOLUTION_5_US);                                     // initialize delay functions with granularity of 5 us
    timer2_init ();                                                         // initialize timer2 for IRMP, DCF77, EEPROM etc.

da delay_init() den Systick-Handler verwendet.

@Mirco: Ich lade das gleich mal hoch, dann kannst Du das mal testen über 
OTA.

[Frank M. (ukw) (Moderator)]

So, die 2.6.3pre1 ist online im Update-Path test.
Einzige Änderung: Das Vertauschen der beiden obigen Befehle (s. 
vorhergehenden Beitrag).

[Mirco D. (bpoh_voodoo)]

Geflascht und getestet.

Hab mal ein Video gemacht.
Das wars leider noch nicht.

[X. O. (overflow)]

https://youtu.be/pB5v6Q6dTuE

Bei mir schauts mit 2.5.0 so aus. Vielleicht könnt ihr die Verschiebung 
ja irgendetwas zuordnen.
"Es ist halb neun" war die Uhrzeit.

Es ist ein STM32F103c8t6 mit Esp12f, in der Verschaltung ohne OTA. An 
den WS2812b ist ein Pull-up von 1.5kohm installiert. Sowie der Rest ist 
mehr oder weniger 1:1 das MiniDevBoard.

Woran es liegt würde mich natürlich schon interessieren. Mit der 2.4.0 
läuft die Uhr aber stabil, von daher kann ich auch damit leben, wenn 
wirklich nur ich betroffen bin.

[Ph L. (filo)]

Hallo zusammen,

ich habe die letzten Tage meine erste WordClock zusammengebaut und 
musste nun leider feststellen, dass ein Kurzschluss zwischen Ground und 
5V ist.
Ich vermute den Fehler entweder "im" Shield oder auf dem STM32. 
Sichtbare Lötstellen sind alle schon als Fehlerquelle ausgeschlossen.
Ist es denn allgemein möglich, dass Leiterbahnen im Shield irgendwo 
kurzgeschlossen sind?

Des Weiteren ist auch der 3.3V Pin auf dem STM32 in Kontakt mit Ground.
Aus diesem Grund denke ich, dass ich vielleicht den Microcontroller beim 
Löten gegrillt habe.
Würde mich über eine professionelle Einschätzung freuen.:)

[Günter H. (gnter_h534)]

Ph L. schrieb:
> Würde mich über eine professionelle Einschätzung freuen.

Dafür wären (detailreiche) Bilder der Löt- und auch der Bestückungsseite 
der Platine hilfreich.

[0xef (Gast)]

Frank M. schrieb:
> Somit hat der Timer-Interrupt in main.c die niedrigste Priorität und
> diejenige in ws2812.c die höchste Priorität.

Stimmt, das hatte ich überlesen. Allerdings haben die UART's auch prio0 
und damit die höchste...

Auch kann ich keinen Aufruf von NVIC_SetPriorityGrouping(0) aus 
core_cm3.h bzw. core_cm4.h finden. Nicht, dass hier 'spezielle' MCU's am 
werkeln sind, welche da ein explizites setzen brauchen.
(mehr info: 
http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/Cihehdge.html#BABIJABJ 
)

@Mirco, @X.O.:
Danke für die Videos, das hilft ungemein. Das Riesenboard von X.O. sieht 
hammergeil aus! (Ist da ein Original STM32F103c8t6 drauf? oder evtl ein 
GD32... clone?)
Anbei hier eine TESTVERSION-2.6.2 mit folgenden Modifikationen:
- ws2812 berechnet 2 LED's am Stück (Mehr 'Luft' fürs IRQ-handling)
- pause der ws2812 verdreifacht (ich möchte 'komische' LED's als Ursache 
ausschliessen)
- IRQ-Prio der UARTS auf 3 abgesenkt (von 0). Damit darf der DMA-IRQ 
diese unterbrechen.

Danke fürs testen und rückmelden.

0xef

[0xef (Gast)]

Noch ein kleiner Info-brocken:
Ich hab mir mal das errata vom stm32f103c8t6 angesehn und dabei zwar 
viel interessantes, aber nichts relevantes gefunden. Also einen 
(bekannten und vom Hersteller veröffentlichten) Hardwarebug auf 
MCU-Seite könnte man auszuschließen versucht sein.

0xef

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> Stimmt, das hatte ich überlesen. Allerdings haben die UART's auch prio0
> und damit die höchste...

Stimmt. Aber das dürfte für das Phänomen keine Rolle spielen, denn durch 
eine Helligkeitsregelung (wie mit der Taschenlampe im Video) wird keine 
explizite UART-Kommunikation angestoßen.

Es wird aus main.c dann aufgerufen:

display_set_display_brightness (ldr_value, FALSE, FALSE);

wobei die beiden FALSE-Parameter dafür sorgen, dass die neue Helligkeit 
weder im EEPROM abgespeichert noch als Aktualisierungs-Info über den 
UART an den ESP8266 geschickt wird.

> - ws2812 berechnet 2 LED's am Stück (Mehr 'Luft' fürs IRQ-handling)

Sinnvoll. Du kannst mir gern die dafür notwendigen Änderungen schicken.

> - pause der ws2812 verdreifacht (ich möchte 'komische' LED's als Ursache
> ausschliessen)

Ok. Aber ich glaube nicht, dass dies hier das Problem ist.

> - IRQ-Prio der UARTS auf 3 abgesenkt (von 0). Damit darf der DMA-IRQ
> diese unterbrechen.

Das ist sinnvoll - auch wenn es sich hier kaum um den zu findenden 
Fehler dreht, s.o.

[Frank M. (ukw) (Moderator)]

Frank M. schrieb:
> Es wird aus main.c dann aufgerufen:display_set_display_brightness
> (ldr_value, FALSE, FALSE);
>
> wobei die beiden FALSE-Parameter dafür sorgen, dass die neue Helligkeit
> weder im EEPROM abgespeichert noch als Aktualisierungs-Info über den
> UART an den ESP8266 geschickt wird.

Leider ist das nur die halbe Wahrheit. Bei größeren 
LDR-Helligkeitsschwankungen wird der aktuelle LDR-Wert doch an den 
ESP8266 geschickt, damit dieser die aktuelle LDR-Helligkeit im 
Webinterface anzeigen kann. Das ist wichtig für die Kalibrierung.

Auszug aus main.c:

            if (ldr_raw_value + 16 < last_ldr_raw_value || ldr_raw_value > last_ldr_raw_value + 16)         // difference greater than 16
            {
                debug_log_printf ("ldr: old raw brightnes: %d new raw brightness: %d\r\n", last_ldr_raw_value, ldr_raw_value);
                last_ldr_raw_value = ldr_raw_value;
                var_send_ldr_raw_value ();
            }

Den letzten Befehl "var_send_ldr_raw_value ();" könnte man testweise mal 
auskommentieren. Ich halte diesen für einen heißen Kandidaten. Die 
UART-Prio-Korrektur könnte dieses Problem also doch tatsächlich lösen.

P.S.
Die debug_log_printf()-Calls sind nur in der Debug-Variante aktiv, sonst 
werden sie durch den Preprocessor komplett eliminiert.

[Mirco D. (bpoh_voodoo)]

0xef schrieb:
> Danke fürs testen und rückmelden.


So habe deine neue Version drauf.
Jetzt hüpft es anders

Siehe Video

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> So habe deine neue Version drauf.
> Jetzt hüpft es anders

Ja, komplett anders. Von einer Verschiebung um 1 oder 2 Stellen kann man 
hier gar nicht mehr reden.

Hattest Du mal meine Version von gestern abend probiert?

Beitrag "Re: WordClock mit WS2812"

(ich bin eher für moderate Tests, wenn man zuviel auf einmal ändert, 
dann weiß man am Ende gar nicht mehr, woran es gelegen hat).

[Mirco D. (bpoh_voodoo)]

siehe

Beitrag "Re: WordClock mit WS2812"

das Video war von der 2.6.3pre1

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> Beitrag "Re: WordClock mit WS2812"

Achso, das Video hatte ich mir zwar angeschaut, aber ich hatte nicht 
erkannt, dass das eine direkte Antwort auf meinen Beitrag war...

Ich habe im Update-Path "Test" mal eine Pre2-Version abgelegt. Diese 
unterdrückt das Übertragen der Helligkeit per UART zum ESP. Allerdings 
kann man dann den LDR nicht mehr kalibrieren... also nicht tun, bitte 
nur Testen ;-)

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> also nicht tun, bitte
> nur Testen ;-)

Dein Wunsch ist mir Befehl.

Leider keine Änderung zur pre1.

Ergänzungsinfo LDR
Ich benutze den "A 906032" von Reichelt und habe entsprechend R1 = 10K 
eingesetzt. R2 ist unbestückt auf dem Shield.

[Harald L. (howy075)]

Hallo,
ich lese jetzt schon eine zeit lang mit wegen des "springen" Problems.
Meine Uhr verhält sich bei jedem Minutenwechsel so wie im Video zu sehen 
ist.
Jetzt meine Frage, ist dieses Verhalten normal oder das von euch 
beschriebene Problem?
Bei jedem 5 Minuten Wechsel läuft die Animation normal durch.
Helligkeitssensor ist verbaut aber deaktiviert.
Es handelt sich um die wc12h-stm32f103-ws2812-grb.

Grüße
Howy

[X. O. (overflow)]

0xef schrieb:
> @X.O.:
> Danke für die Videos, das hilft ungemein. Das Riesenboard von X.O. sieht
> hammergeil aus! (Ist da ein Original STM32F103c8t6 drauf? oder evtl ein
> GD32... clone?)

Ja, es ist ein original STM.

[Frank D. (frank512)]

Hi,

nachdem meine Uhr lief, waren alle in der Familie begeistert.
Aber sie hat manchmal "Display" Fehler :-( (siehe Bild, sollte 
normalerweise alles in blau sein)

Man konnte durch aus und wieder ein den Fehler beheben, aber nun nicht 
mehr.

Leider habe ich keine Idee woran das liegen kann, bzw., wo ich mit der 
Suche ansetzen soll.

Hat jemand eine Idee?



Mein Version von der Uhr:
WordClock12h mit
STM32F103C8T6 Mini-Development Board
ESP8266
DS3231
als 3,3V Netzteil habe ich AMS1117LDO 800MA

[Marco R. (majestick)]

Hallo Frank D.,
Hallo Harald,

habt ihr beide den ca. 1,8K PullUp Widerstand der LEDs eingebaut? 
Welches Board wird verwendet (Version)?

Aus eigener Erfahrung kann ich hier nur empfehlen, nochmals alle Masse 
Verbindungen der LEDs zu prüfen. Hatte erst vor 2 Tagen eine Uhr da, bei 
der an einer Minuten LED die GND Leitung vergessen wurde und der Fehler 
sah wie auf dem Bild von Frank D. aus.
Witziger Weise trat der Fehler auch nur bei bestimmten Farben auf.

Möglich wäre aber auch eine defekte LED, hier z.B. das T, da in den 
WS2812 das Signal in jeder LED aufbereitet und weitergeleitet wird, muss 
hier nur eine nicht ganz sauber arbeiten schon können Fehlfarben und 
Sprünge möglich sein. Und leider musste ich feststellen das die 
aktuellen LEDs aus China nicht mehr so gut laufen, wie die die ich vor 
ungefähr 1,5 Jahren bestellt habe. Sprich die LED ausfälle häufen sich. 
Im Gegensatz zu meiner ersten Uhr die immer noch an der Wand hängt und 
nie wieder angefasst werden musste.

Ich kann euch hier nur empfehlen mal nur Teile des LED Streifens zu 
benutzen und den Display Test öfters laufen zu lassen.

Viel Erfolg

Gruß
Marco

[Frank M. (ukw) (Moderator)]

Mittlerweile glaube ich auch, dass der Fehler nicht in der Software zu 
finden ist. Ich habe mittlerweile von vielen Leuten per Mail die 
Mitteilung bekommen, dass die aktuelle Version bei ihnen stabil läuft. 
Auch bei mir ist das Springen der Buchstaben nicht im geringsten 
reproduzierbar.

Außerdem haben 0xef und ich hier mehrere Testversionen bereitgestellt, 
um
"verdächtige" Abschnitte in der Software abzuchecken. Sämtliche Tests 
waren nicht erfolgreich. Es konnte keine Ursache in der Software 
entdeckt werden. Zudem kann man annehmen, dass ein Software-Fehler bei 
allen auftritt und nicht bei einzelnen. Beim Shield v3 hat auch noch 
niemand einen derartigen Fehler (Springen der Buchstaben) gemeldet.

Daher nehme ich an, dass die Ursache eher im individuellen 
Hardware-Aufbau liegt.

Deswegen mal eine Checkliste:

1. Alle GND-Verbindungen sauber vorhanden?

2. Ist ein 1,8K (oder 1,5K) Pullup an DIN der ersten WS2812-LED?

3. Ist ein 220 Ohm Serienwiderstand zwischen dem Data-Pin und DIN der 
ersten WS2812-LED? Wenn ja, diesen bitte brücken.

4. Die Data-Leitung zu DIN sollte möglichst kurz gehalten (max. 30-40cm) 
werden. Je kürzer, desto besser.

5. Die Data-Leitung sollte nicht in unmittelbarer Nachbarschaft zu 
anderen Datenleitungen wie LDR, TSOP und DS18xxx geführt werden. Die 
Data-Leitung sollte auch zusammen mit GND mittels zweipoligem Kabel an 
die erste LED geführt werden. Ich persönlich verwende dafür ein 
2-poliges oder 3-poliges Flachbandkabel, indem ich einfach 2 Leitungen 
vom vorhandenen 16-pol. Flachbandkabel abtrenne. Beim 2-poligem Kabel 
verwende ich GND und Data, beim 3-poligem +5V, Data und GND dafür.

6. Das Netzteil zur Versorgung der Stripes sollte mindestens einen Strom 
von 4A leisten können. Die Versorgungsspannung der Stripes sollte 
mindestens in jeder zweiten Zeile neu eingespeist werden. Die 
Versorgungsspannung sollte auch sehr nahe an 5V (4,9V-5,1V) sein. 
Größere Abweichungen führen zu Fehlern. Am besten misst man die Spannung 
während des Display-Tests einmal am Anfang der LED-Kette und einmal am 
Ende. Bei zu großen Differenzen klappt das nicht mit der 
Zwischeneinspeisung der Spannung in jeder zweiten Zeile. Unbedingt 
überprüfen!

7. Wurden WS2812-LED-Stripes verwendet, auf denen auch 
Entkoppelkondensatoren für jede(!) LED verlötet sind? Es gibt durchaus 
China-Anbieter, welche weniger oder gar keine Entkoppelkondensatoren für 
ihre Stripes verwenden.

[Harald L. (howy075)]

Hallo Marco,
Also der Wiederstand ist verbaut, Board ist Version 3, also die neueste.
Verbindungen sind alle in ordnung, auch beim Displaytest leucchten alle 
Led's richtig.
Ich habe eine zweite uhr (zumindest die Elektronik) aufgebaut und dort 
ist der selbe "hüpfer" bei den minutenwechsel.
Software ist die aktuelle.
Hab von diesem auch ein Video gemacht.

Grüße
Howy

PS.: Die Uhr ist auch so der Hammer und ich danke allen die dazu 
beigetragen haben. Der kleine Bug stört mich jetzt auch nicht wirklich. 
Aber wäre halt noch eine steigerung wenn der auch noch beseitigt wäre.

[0xef (Gast)]

anbei eine TESTVERSION von v2.6.2:
- 9 LED's auf einmal berechnen statt einer.
  (wenn ich nicht komplett daneben liege, sollte also die erste Zeile 
einer WC24h nicht springen (der rest hoffentlich auch nicht))

Ich kuck gerade noch die Interrupts durch und lade dann eine Version mit 
deaktivierten Interrupts hoch. Ich möchte endlich wissen, wieso ich das 
Problem nicht reproduzieren kann und ob andere interrupts an dem Problem 
beteiligt sind.

0xef

[Harald L. (howy075)]

Frank M. schrieb:
> Mittlerweile glaube ich auch, dass der Fehler nicht in der Software zu
> finden ist. Ich habe mittlerweile von vielen Leuten per Mail die
> Mitteilung bekommen, dass die aktuelle Version bei ihnen stabil läuft.
> Auch bei mir ist das Springen der Buchstaben nicht im geringsten
> reproduzierbar.
>
> Außerdem haben 0xef und ich hier mehrere Testversionen bereitgestellt,
> um
> "verdächtige" Abschnitte in der Software abzuchecken. Sämtliche Tests
> waren nicht erfolgreich. Es konnte keine Ursache in der Software
> entdeckt werden. Zudem kann man annehmen, dass ein Software-Fehler bei
> allen auftritt und nicht bei einzelnen. Beim Shield v3 hat auch noch
> niemand einen derartigen Fehler (Springen der Buchstaben) gemeldet.
>
> Daher nehme ich an, dass die Ursache eher im individuellen
> Hardware-Aufbau liegt.
>
> Deswegen mal eine Checkliste:
>
> 1. Alle GND-Verbindungen sauber vorhanden?

Habe ich alle nachkontrolliert und sind in Ordnung

>
> 2. Ist ein 1,8K (oder 1,5K) Pullup an DIN der ersten WS2812-LED?

Ja ist bei beiden verbaut

>
> 3. Ist ein 220 Ohm Serienwiderstand zwischen dem Data-Pin und DIN der
> ersten WS2812-LED? Wenn ja, diesen bitte brücken.

Ist soviel ich herausgefunden habe beim Board V3 nicht vorgesehen

>
> 4. Die Data-Leitung zu DIN sollte möglichst kurz gehalten (max. 30-40cm)
> werden. Je kürzer, desto besser.

Gerade noch mal gekürzt, jetzt unter 30 cm
>
> 5. Die Data-Leitung sollte nicht in unmittelbarer Nachbarschaft zu
> anderen Datenleitungen wie LDR, TSOP und DS18xxx geführt werden. Die
> Data-Leitung sollte auch zusammen mit GND mittels zweipoligem Kabel an
> die erste LED geführt werden. Ich persönlich verwende dafür ein
> 2-poliges oder 3-poliges Flachbandkabel, indem ich einfach 2 Leitungen
> vom vorhandenen 16-pol. Flachbandkabel abtrenne. Beim 2-poligem Kabel
> verwende ich GND und Data, beim 3-poligem +5V, Data und GND dafür.

Bei meiner testversion kein LDR und kein Tsop und DS18xxx testweise 
direkt angelötet

>
> 6. Das Netzteil zur Versorgung der Stripes sollte mindestens einen Strom
> von 4A leisten können. Die Versorgungsspannung der Stripes sollte
> mindestens in jeder zweiten Zeile neu eingespeist werden. Die
> Versorgungsspannung sollte auch sehr nahe an 5V (4,9V-5,1V) sein.
> Größere Abweichungen führen zu Fehlern. Am besten misst man die Spannung
> während des Display-Tests einmal am Anfang der LED-Kette und einmal am
> Ende. Bei zu großen Differenzen klappt das nicht mit der
> Zwischeneinspeisung der Spannung in jeder zweiten Zeile. Unbedingt
> überprüfen!

Netzteil 10A
>
> 7. Wurden WS2812-LED-Stripes verwendet, auf denen auch
> Entkoppelkondensatoren für jede(!) LED verlötet sind? Es gibt durchaus
> China-Anbieter, welche weniger oder gar keine Entkoppelkondensatoren für
> ihre Stripes verwenden.

Jede LED hat einen kondensator.

Grüße
Harald

PS meine Konfiguration ist: wc12h-stm32f103-ws2812-grb mit Board V3
Nochmals herzlichen Dank an dich!

[Marco R. (majestick)]

Hallo Harald,

wie werden die LEDs mit Strom versorgt? In dem 2. Video sieht man das 
der 16pol Anschluss nicht verwendet wird.

Kannst du vielleicht einfach mal testhalber die Minuten LEDs rausnehmen 
und DOUT vom Board direkt an die erste LED des Strips an klemmen? bzw. 
dann auch mal erst beim 2. Strip anfangen?

Habe wie gesagt mittlerweile schon einige Fehlerbilder gesehen und bei 
mir waren es meist LEDs, die defekt waren.


Bei deiner Testversion sind kein LDR und TSOP angeschlossen, die 
alternativ Widerstände/ Schaltung ist drin? Sehe in dem Video die 
Drahtbrücke für den TSOP nicht und den R2 für den LDR.
Bzw. kann es im Video nicht wirklich erkennen.

Gruß
Marco

[0xef (Gast)]

anbei eine TESTVRSION bei der die LED's synchron upgedated werden.
Idee dahinter: falls das Problem ausgelöst wird before ws2812_refresh 
aufgerufen wird, hüpft die Anzeige weiterhin, sonst nicht.
Den zugehörigen Patch hänge ich auch dran, damit jeder nachvollziehen 
kann, was hier anders ist.

0xef

[0xef (Gast)]

So und noch ne Testversion (falls die vorige noch Hüpfer drin hat.)

Hier sind jetzt auch die IRQ's mit abgeschaltet.
Wenn diese Version noch hüpft weiss ich nicht mehr weiter....

0xef

[0xef (Gast)]

Frank M. schrieb:
> Mittlerweile glaube ich auch, dass der Fehler nicht in der Software zu
> finden ist.

Ich bin noch verwirrt ob der Tatsache, dass mit V2.4 noch alles 
funktioniert zu haben scheint. Ich tippe zwar auch eher auf 
'grenzwertige' Hardware, aber dennoch frage ich mich, wass denn nun bei 
V2.5+ das Fehlerbild auslöst und bei V2.4 nicht? Vielleicht haben wir 
irgendwo ein marginal knappes timing drin (aka race-condition) und bei 
v2.4 hat der compiler irgendwo einen takt länger/kürzer gebraucht und 
das Problem trat dadurch nicht auf, jetzt aber schon. Da der Fehler auf 
meiner Hardware nicht nachstellbar ist, muss eine 'Hardware-abhängige' 
Komponente an dem Fehler beteiligt sein. Und die finde ich nicht.

0xef

PS.: Da fällt mir noch was ein: Kann bitte mal jemand die v2.6.2 für 
[wc12h|wc24h]-stm32f103c8-ws2812-grb mit der laut Artiekl empfohlenen 
emBitz IDE bauen und kucken, ob das Problem damit auch auftritt? Nicht, 
das es der Wechsel des Compilers ist... (glaube ich zwar nicht, aber 
ausschließen wäre gut.)

[Mirco D. (bpoh_voodoo)]

0xef schrieb:
> anbei eine TESTVRSION bei der die LED's synchron upgedated werden.
> Idee dahinter: falls das Problem ausgelöst wird before ws2812_refresh
> aufgerufen wird, hüpft die Anzeige weiterhin, sonst nicht.
> Den zugehörigen Patch hänge ich auch dran, damit jeder nachvollziehen
> kann, was hier anders ist.
>
> 0xef

Die tut es !!!
Fehler ist bis dato nicht aufgetreten

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> Da fällt mir noch was ein: Kann bitte mal jemand die v2.6.2 für
> [wc12h|wc24h]-stm32f103c8-ws2812-grb mit der laut Artiekl empfohlenen
> emBitz IDE bauen und kucken, ob das Problem damit auch auftritt? Nicht,
> das es der Wechsel des Compilers ist..

Diese Möglichkeit schoss mir auch schon durch den Kopf, obwohl ich 
selber auch die Hex-Dateien des gcc unter Linux verwende. Aber sicher 
ist sicher. Im Anhang ist die mit EmBitz erzeugte Version.

@Mirco: Kannst Du die bitte testen?

EDIT: Hat sich wohl überschnitten, hat sich dann wohl erledigt ;-)

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> @Mirco: Kannst Du die bitte testen?

Hab mir trotzdem den Spaß gemacht. Kompiler können wir ausschließen.
Auch hier ist der Fehler drin!

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> anbei eine TESTVRSION bei der die LED's synchron upgedated werden.
> Idee dahinter: falls das Problem ausgelöst wird before ws2812_refresh
> aufgerufen wird, hüpft die Anzeige weiterhin, sonst nicht.

Laut Mirco liegt es daran. Im Patchfile ist dann die Stelle zu sehen:

     ws2812_dma_start();
+
+    while (ws2812_dma_status != 0)
+    {
+        ;                                                        // wait until DMA transfer is ready
+    }

Das Warten auf das Ende des Komplett-Transfers macht natürlich alle 
Vorteile eines DMA-Transfers zunichte: Man kann während des Transfers 
nicht weiterarbeiten. Daher kann diese Änderung keine Lösung sein - 
jedenfalls nicht für sich allein.

Aber ich beginne zu verstehen, was da passiert:

Früher mit großem DMA-Buffer:

   display.c schreibt in LED-Buffer
   ws2812.c konvertiert die LED-Buffer-Daten in DMA-Buffer
   DMA liest asynchron ausschließlich aus DMA-Buffer
   display.c arbeitet währenddessen(!) weiter und schreibt in LED-Buffer

Das ergibt aber kein Problem, da LED-Buffer und DMA-Buffer voneinander 
getrennt sind.

Jetzt läuft es seit einiger Zeit mit kleinem DMA-Buffer aber so:

- display.c schreibt in LED-Buffer
- ws2812.c konvertiert nur wenig LED-Buffer-Daten (rgb_buf) für 
DMA-Buffer
- DMA liest asynchron aus DMA-Buffer und wird gleichzeitig mit neuen 
konvertierten Daten aus LED-Buffer gefüttert.
- display.c arbeitet währenddessen(!) weiter und schreibt in LED-Buffer

Und hier haben wir den Konflikt: Es kann vorkommen, dass in den 
LED-Buffer geschrieben wird, während der DMA-Interrupt noch 
LED-Buffer-Daten für den DMA-Transfer vorbereitet. Das gibt dann Salat.

Für mich gibt es nur eine Lösung:

Den LED-Buffer rgb_buf 2x vorsehen, einmal für die aktuelle Übertragung 
und einmal für die kommende. Dann kann die obige Blockung wieder weg.

[Frank M. (ukw) (Moderator)]

Frank M. schrieb:
> Für mich gibt es nur eine Lösung:
>
> Den LED-Buffer rgb_buf 2x vorsehen, einmal für die aktuelle Übertragung
> und einmal für die kommende. Dann kann die obige Blockung wieder weg.

Ich habe das Double-Buffering mal eingebaut. Die anhängende Version 
blockt nicht mehr, verwendet aber 2 LED-Buffer (rgb_buf).

@Mirco: Kannst Du nochmal testen? Danke.

[0xef (Gast)]

Frank M. schrieb:
> Und hier haben wir den Konflikt: Es kann vorkommen, dass in den
> LED-Buffer geschrieben wird, während der DMA-Interrupt noch
> LED-Buffer-Daten für den DMA-Transfer  vorbereitet. Das gibt dann Salat.

Das sollte aber nur ein 'Tearing' effekt geben, keinen Positionswechsel.
(Die RGB Werte für Pixel X stehen immer an der gleichen Stelle und die 
DMA-Routine hat ja ihren eigenen Zeiger, woher sie ihre aktuellen Daten 
liest. Und der wird nur bei starten des transfers zurückgesetzt.
Das war ja auch eine meiner Vemrutungen, dass dieser Zeiger kurz nach 
dem start des DMA-transfers zurückgesetzt wird.
-> die IRQ-Routine gar nicht hängt, sondern die ersten paar Pixel 
zweimal ausgibt.)

An sich fände ich double-buffer auch besser. Da kann man auch noch 
überlegen, ob man den Puffer immer kopiert, oder nur abwechsend 
beschreibt.
Ersteres braucht mehr Zeit (kann man mit einem DMA etwas abpuffern), bei 
letzterem muss man höllisch aufpassen, alle LED's zu aktualisieren, 
sonst gibts Geisterbilder... (und das initiale Löschen braucht auch 
Zeit...)

Im Moment wäre ich 60:40 für abwechselndes Pufferbenutzen.
Da ist die Logik relativ einfach:

 Puffer löschen -> alle Element reinmalen -> ws2812 triggern -> zum 
anderen Puffer umschalten
und alles wieder von vorn.

0xef

PS.: beim rumkopieren kann die CPU 32bit-weise die eine Hälfte kopieren, 
ein gleichzeitig gestarteter MEM2MEM DMA die andere Hälfte.
Ich meine gelesen zu haben, dass bei zeitgleichem Zugriff von DMA und 
CPU beide gleich oft drankommen. Ich kann das nochmal raussuchen.

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> An sich fände ich double-buffer auch besser. Da kann man auch noch
> überlegen, ob man den Puffer immer kopiert, oder nur abwechsend
> beschreibt.

Ich habs umgesetzt mit wechselndem Index, da braucht man den Buffer 
nicht zu kopieren. Da er immer vollständig beschrieben wird, sollte es 
auch keine Geisterbilder geben. Testversion hängt oben dran, die 
Source-Änderungen habe ich Dir zur Begutachtung bereits per Mail 
geschickt.

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> Frank M. schrieb:
>> Für mich gibt es nur eine Lösung:
>>
>> Den LED-Buffer rgb_buf 2x vorsehen, einmal für die aktuelle Übertragung
>> und einmal für die kommende. Dann kann die obige Blockung wieder weg.
>
> Ich habe das Double-Buffering mal eingebaut. Die anhängende Version
> blockt nicht mehr, verwendet aber 2 LED-Buffer (rgb_buf).
>
> @Mirco: Kannst Du nochmal testen? Danke.

Hi Frank,

Leider völlig andere Effekte.
siehe Video

Ich kriege nur nicht in den Schädel, warum das dann nicht bei allen 
auftritt.
Liegt es vielleicht an etwas unterschiedlichen STM32F103 Boards?

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> Leider völlig andere Effekte.

Erstmal danke, ich teste die Änderung heute abend mal mit meiner Uhr. 
Offenbar habe ich da noch auf die Schnelle einen Fehler eingebaut. Es 
war jetzt auch erstmal nur ein schneller Hack.

Immerhin haben wir den Grund gefunden, das ist schon mal eine Menge 
wert. Damit sollte es mir auch möglich sein, diesen gezielt durch 
Manipulation an der Software zu reproduzieren.

Mirco D. schrieb:
> Ich kriege nur nicht in den Schädel, warum das dann nicht bei allen
> auftritt.

Das verstehe ich auch nicht. Meine Uhr läuft mit der 2.6.2 schon eine 
Ewigkeit, ohne dass einmal dieser Effekt aufgetreten wäre. Ich kann mir 
nur vostellen, dass hier mehrere Bedingungen zusammenkommen müssen, bis 
dieser Effekt zutage tritt. Bei der Vielzahl von möglichen Hard- und 
Software-Konfigurationen ist das Thema schon ziemlich komplex.

[0xef (Gast)]

Ich bin noch nicht überzeugt, dass double-buffering die Ursache 
beseitigt.
Und diese Ursache muss was mit Hardware zu tun haben, sonst hätten mehr 
Leute das Problem. Und wenn es mit blockierender Ausgabe funktioniert 
hat, wird die 'störende Aktion' nach dem ws2812_refresh Aufruf 
ausgelöst.
Jetzt muss ich mich mal durch den Code wühlen und versuchen den Auslöser 
weiter einzukreisen. Das könnte aber noch ein wenig dauern, da ich den 
Code lange nicht so gut kenne wie z.B. Frank....

Nichtsdestotrotz ist double-buffering einzubauen eine gute Idee.
Aber bis wir auf des Pudels Kern stoßen könnte es das eigentliche 
Problem verschleiern...

0xef

@Mirco D.: Was meinst du mit unterschiedlichen STM32F103 Boards?
Ich habe dieses hier:
https://www.aliexpress.com/item/x/32555258029.html
(von anderen Verkäufern, aber alle, die ich habe sehen aus wie das 
verlinkte)

[X. O. (overflow)]

Ich hatte die 2.6 heute nichnals an einer anderen Uhr getestet und die 
läuft ohne Probleme.
Ich werde die Liste von Frank nochmals durchgehen was sich da zwischen 
den beiden Uhren unterscheidet. Werde mal den LDR ausmessen.
Melde mich spåter

[Frank M. (ukw) (Moderator)]

X. O. schrieb:
> Ich hatte die 2.6 heute nichnals an einer anderen Uhr getestet und die
> läuft ohne Probleme.

Sehr aufschlussreich. Bitte stelle die Konfiguration an dieser Uhr exakt 
so ein wie auf der Uhr, wo der Fehler auftritt. Also insbesondere die 
Animationen, Farben usw.

> Ich werde die Liste von Frank nochmals durchgehen was sich da zwischen
> den beiden Uhren unterscheidet.

Gute Idee!

Eigentlich ist es ja ganz spannend, diesem merkwürdigen Fehler 
hinterherzujagen. Aber langsam wünsche ich mir ein Ergebnis herbei ;-)

[0xef (Gast)]

Frank M. schrieb:
> Eigentlich ist es ja ganz spannend, diesem merkwürdigen Fehler
> hinterherzujagen. Aber langsam wünsche ich mir ein Ergebnis herbei ;-)

Hallo Frank,

Ich glaube (mal wieder) ich habs!

in display.c wird an verschiedenen Stellen led_refresh aufgerufen,
(mal für die Statusled, mal die Minuten, mal die Matrix, mal das 
ambilight)
aber diese Teile lassen sich nicht unabhängig updaten (weil ja alle leds 
in einer Kette hängen). Was, wenn durch die rapide Änderung des 
LDR-Wertes mehrere solcher updates kurz nacheinander kommen?

Also hab ich mir den ws2812_refresh nochmal zur Brust genommen:
Er wartet braf, bis der IRQ ws2812_dma_status auf 0 setzt und triggert 
dann einen neuen Durchlauf. Was wenn das doch (für spezielle LED's) zu 
zeitig kommt? Dann würden die neuen LED-Daten nicht bei der ersten LED 
angenommen, sind an der letzten Kettenposiion angehängt. Was wenn das 
vorige update kein volles war? z.B. nur die Statusled? und danach ein 
volles? Dann müssten alle Pixeldaten verrutscht dargestellt werden (und 
den Puffer zu verdoppeln würde das Problem nur verschärfen: genau das 
ist ja passiert!)

Also hab ich mir nochmal die DMS-IRQ Routine im WS2812 angesehen:

    if (DMA_GetITStatus(WS2812_DMA_CHANNEL_IRQ_HT))                                 // check half-transfer interrupt flag
    {
        DMA_ClearITPendingBit (WS2812_DMA_CHANNEL_IRQ_HT);                          // reset flag
        ws2812_setup_dma_buf (0);
    }
    if (DMA_GetITStatus(WS2812_DMA_CHANNEL_IRQ_TC))                                 // check transfer complete interrupt flag
    {
        DMA_ClearITPendingBit (WS2812_DMA_CHANNEL_IRQ_TC);                          // reset flag

        if (current_dma_buf_pos < current_data_pause_len)
        {
            ws2812_setup_dma_buf (1);
        }
        else
        {
            DMA_Cmd (WS2812_DMA_STREAM, DISABLE);                                   // disable DMA
            ws2812_dma_status = 0;                                                  // set status to ready
        }
    }

Zum einen wird auf die möglich Pause Bedingung nur im TC aber nicht im 
HT Zweig geprüft. Zum anderen: wenn der HT-Zweig alle LED's (+pause) 
BERECHNET hat wird beim nächsten TC IRQ der DMA disabled und das 
Status_flag zurückgesetzt. Allerdings sind zum diesem Zeitpunkt noch bis 
zu 2*24 Bits im DMA-Puffer (die eigentlich noch ausgegeben werden 
müssten). Der DMA könnte also potentiell bis zu max 60. us (eine LED 
braucht 30us) zu früh restarten. Das könnte als Reset-Pause für manche 
LED's dann zu kurz sein.

Dazu passt, dass das springen der Buchstaben (soweit ich mich erinnere) 
bei der wc24h und nicht der wc12h auftritt. Bis die wc24h alle LED's mit 
daten gefüttert hat, ist die main wahrscheinlich(er) schon wieder in 
einer _refresh und wartet auf das Ende des DMA.

Meinen 'improved' WS2812 reichen auch 10us Reset-Puls (ausprobiert mit 
anderem Programm), aber wahrscheinlich nicht allen Ws2812...

anbei ein möglicher Quickhack nebst Testfile.

Änderungsvorschlag:
Immer volle updates machen. Egal wieviele Ambilight LED's der User 
konfiguriert, wir haben eh den RGB-Puffer für die maximalanzahl, da 
können wir auch alle LED-Daten ausgeben. Die laufen dann halt ins leere, 
aber das ganze reduziert die Bandbreite an möglichen Fehlerursachen.
Außerdem die noch im DMA-Puffer liegenden Daten berücksichtigen.

Oder als poor-mans-hack: vor dem restarten des DMA delay_us(50) 
einbauen.

0xef

PS.: (Ich weiss, dass beim F401) TIM1 nach einer einstellbaren Anzahl 
ticks die Arbeit automatisch einstellen kann. Ich kuck mal, ob a) das 
TIM2 auch kann oder b) beide synchron laufen können und TIM1 dann TIM2 
abschalten kann (nach Ende der Pause). Und wie das beim F103 aussieht.
Falls wir Pech haben, müssen wir TIM1 für die LED-Ausgabe nehmen (und 
wieder umverdrahten). Aber erstmal Datenblatt wälzen....

[0xef (Gast)]

Sorry kleiner Denkfehler: es sind max 24Bits noch im DMA-Puffer die 
verschluckt werden könnten (also 30us). Die minimale Pause wäre dann nur 
20us und das reicht aber wahrscheinlich trotzdem nicht allen LED's.
Der Rest der Argumentation bleibt davon unberührt...


0xef

[Harald L. (howy075)]

Hallo,
#Marco
Du hattest recht, beim Board hatte ich noch Fehler, diese habe ich jetzt 
behoben (siehe Foto).
Leider hat sich das Verhalten nicht geändert, habe mal eine 
Serienaufnahme gemacht und angehängt.
Inzwischen habe ich ein wenig herumprobiert, habe versucht das Ambilight 
zu verändern...
Hat es schlimmer gemacht, danach war nicht nur beim umschalten Chaos, 
sondern besagtes Chaos blieb bestehen...

grüße
Harald

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> Zum einen wird auf die möglich Pause Bedingung nur im TC aber nicht im
> HT Zweig geprüft. Zum anderen: wenn der HT-Zweig alle LED's (+pause)
> BERECHNET hat wird beim nächsten TC IRQ der DMA disabled und das
> Status_flag zurückgesetzt.

Darüber muss ich nochmal nachdenken, denn ich bin mir da nicht ganz 
sicher, dass dies wirklich ein Problem ist. Im Falle eines HT-Interrupts 
ohne Prüfung wird vielleicht am Ende ws2812_setup_dma_buf() einmal 
zuviel aufgerufen, aber auch nicht mehr. Aber was bewirkt das? 
Eigentlich nichts, höchstens dass der DMA-Buffer am Ende noch mit 0-Bits 
gepadded wird - was ja auch erwünscht ist. Beim TC muss ich den 
DMA-Buffer nicht nochmal mit 0en füllen, denn er ist es bereits durch 
den HT. So war jedenfalls damals mein Gedankengang.

Wie gesagt: Ich denke aber nochmal genauer über die HT <-> TC-Behandlung 
nach und werde Deine Argumente prüfen.

Ich habe die Double-Buffering-Methode eben nochmal am lebenden Objekt 
getestet und habe den Fehler meines Quick-Hacks von heute nachmittag 
gefunden. Du hattest Recht: Der Speicher muss beim Umsetzen des 
RGB-Buffer-Indexes tatsächlich kopiert werden, weil natürlich nicht 
immer alle LED-Positionen neu gesetzt werden. So wurde auf meiner Uhr 
nur jeder zweite Frame komplett dargestellt und das Display flackerte 
bei jedem Refresh deutlich sichtbar.

Ich habe daher nochmal einen memcpy eingebaut:

    current_rgb_buf_idx     = next_rgb_buf_idx;
    next_rgb_buf_idx        = next_rgb_buf_idx ? 0 : 1;
+    memcpy ((WS2812_RGB *) rgb_buf[next_rgb_buf_idx], (WS2812_RGB *) rgb_buf[current_rgb_buf_idx], WS2812_MAX_LEDS * sizeof (WS2812_RGB));

Danach lief es auf meiner Uhr wieder wie gewohnt richtig. Auch nach 
Setzen des Ambilight auf eine ungerade Anzahl von LEDs (ich teste 
momentan an einer WC12h) konnte ich das Display nicht aus der Ruhe 
bekommen.

@Mirco: Anbei die korrigierte Double-Buffer-Testversion. Sollte es mit 
dieser immer noch nicht sauber laufen, werde ich mich nochmal auf die 
Ausführungen von 0xef stürzen...

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> @Mirco: Anbei die korrigierte Double-Buffer-Testversion. Sollte es mit
> dieser immer noch nicht sauber laufen, werde ich mich nochmal auf die
> Ausführungen von 0xef stürzen...

Moin Frank,

so erstmal scheint die Anzeige in Ordnung.
Ich kann das Verhalten des LDR jedoch nicht testetn, da dieser 
anscheinend tot gelegt ist in dieser Version. Es kommen keine Werte im 
UI an. Auch reagiert die Uhr nicht auf Helligkeits Änderungen.

PS Nach einem nochmaligen Reset geht nun der LDR und...


....


Trommelwirbel


....


es scheint das Problem gekillt zu haben.


Applaus!!!!!!!


Danke Frank.

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> es scheint das Problem gekillt zu haben.

Danke fürs Testen :-)

Ich werde das Double-Buffering auch noch in den SK6812-Source einbauen, 
denn dort könnte dasselbe Problem auftreten. Dann gibts eine 2.6.3 - und 
ein Problem weniger.

[0xef (Gast)]

0xef schrieb:
> anbei ein möglicher Quickhack nebst Testfile.

Sorry, das Patchfile erzeugen ging irgendwie schief.
Eingedampft auf das wesentliche stünde da:

     current_led_offset      = 0;
-    current_data_pause_len  = DATA_LEN(n_leds) + PAUSE_LEN;
+    current_data_pause_len  = DATA_LEN(n_leds) + 2 * WS2812_BIT_PER_LED + PAUSE_LEN;
     current_leds            = n_leds;

Wobei 1x WS2812_BIT_PER_LED reichen würde.

Ich versuch das nachzumessen, bin aber gerade als Kinderbetreuung 
ausgelastet.

0xef

PS.: Franks memcpy im double-buffering entschärft das timing problem 
natürlich erheblich. Ich würde trotzdem das Timing korrigieren.

[X. O. (overflow)]

Mirco D. schrieb:

> Trommelwirbel
>
> ....
>
> es scheint das Problem gekillt zu haben.
>
> Applaus!!!!!!!
>
> Danke Frank.

Selbes Bild bei mir. :)

Die letzten Änderungen scheinen es echt gebracht zu haben und das 
Problem mit den verschobenen Bildern zu beheben.
Ich hatten den obigen WC24h Testcode mal auf die WC12h geflasht und das 
Dimmen funktioniert damit jetzt wie es soll.
Ohne Springen der Wörter bei Helligkeitsänderungen.


Die Verschaltung des LDR hatte ich mir auch nochmals angesehen. Recht 
viel schlauer bin ich noch nicht. Auf meinem Board habe ich einen 
GL5528, wäre Baugleich zum A 906032, der hier in Kombi mit dem 10k 
Widerstand auch mal erwähnt wurde. Den 10k hatte ich auch für R1 
verwendet.
Wo ich nicht ganz durchblicke ist, dass Torsten in im WC Artikel bei 
beiden Schematics schreibt, dass man R2 weglassen kann. Soweit macht das 
ja auch Sinn. In den Bildern mit den bestückten Platinen ist aber gerade 
R1 nicht bestückt. Lässt man R1 weg funktioniert die Helligkeitsregelung 
doch überhaupt nicht.

Morgen werde ich nochmals den LDR komplett entfernen und PA5 direkt mit 
einem Netztteil ansteuern, um auszuschließen dass es nicht doch an dem 
GL5528 liegt, den ich verwende.

[Günter H. (gnter_h534)]

X. O. schrieb:

> Wo ich nicht ganz durchblicke ist, dass Torsten in im WC Artikel bei
> beiden Schematics schreibt, dass man R2 weglassen kann. Soweit macht das
> ja auch Sinn. In den Bildern mit den bestückten Platinen ist aber gerade
> R1 nicht bestückt. Lässt man R1 weg funktioniert die Helligkeitsregelung
> doch überhaupt nicht.

Die Angaben in den Schaltplänen sind richtig: Wird kein LDR verwendet, 
muss R2 bestückt werden. Das ist im Artikel auch im Kap. 2.6 (Hardware 
- LDR) so beschrieben.

Die Bilder mit den bestückten Shields sind vielleicht "unglücklich" und 
damit verwirrend: Darauf ist eine mögliche Variante abgebildet, wenn 
kein LDR verwendet werden soll - der LDR-Eingang des Mikrocontrollers 
wird über R2 auf
+ 3,3 V gelegt.

[Marco R. (majestick)]

Harald L. schrieb:
> Du hattest recht, beim Board hatte ich noch Fehler, diese habe ich jetzt
> behoben (siehe Foto).

Zumindest können wir dies nun als Ursache ausschließen.

> Leider hat sich das Verhalten nicht geändert, habe mal eine
> Serienaufnahme gemacht und angehängt.

Super, so bekommt man noch mal einen besseren überblick.

Wenn ich das richtig sehe, geht du Links mit +5V an den Strip und Rechts 
mit Masse dran, richtig? Hatte ich auch mal bei einer Uhr versucht, gab 
aber auch nur Probleme und habe beides auf beiden Seiten angeschlossen 
und damit das Problem gelöst.
Auf jeden Fall würde ich für eine direkte Masse Verbindung der Minuten 
LEDs sorgen, bzw. s.u.

> Inzwischen habe ich ein wenig herumprobiert, habe versucht das Ambilight
> zu verändern...
> Hat es schlimmer gemacht, danach war nicht nur beim umschalten Chaos,
> sondern besagtes Chaos blieb bestehen...

Was hast du genau verändert?
Wird der Ambilight Strip zwischendrin auch noch mal mit Strom versorgt? 
oder nur am Anfang und am Ende?

Ok, wenn ich das richtig sehe, läuft die Masseverbindung der Uhr und dem 
Board vor dem Board zusammen, korrekt? Zieh hier bitte mal vom STM 
(Board) eine GND Verbindung zum Strip, am besten mit der LED Leitung.

Dann wäre es super zu wissen, wie verhält sich die Uhr wenn du einfach 
mal z.B. die Minuten LEDs ausbaust und die LED Leitung direkt an das "E" 
anschließt, bzw. auch erst z.B. in der 2. Zeile anfängst?

Viel Erfolg,

Gruß
Marco

[Frank M. (ukw) (Moderator)]

X. O. schrieb:
> Die letzten Änderungen scheinen es echt gebracht zu haben und das
> Problem mit den verschobenen Bildern zu beheben.

Prima, freut mich. Die neue Version 2.6.3 ist jetzt auch online.

Einziger Punkt:

 - Bugfix: Flackern bzw. versetztes Ausgabe der Display-LEDs durch
   Double-Buffering behoben.

[0xef (Gast)]

0xef schrieb:
> Ich versuch das nachzumessen, bin aber gerade als Kinderbetreuung
> ausgelastet.

So, hab mal das Timing vermessen:
mit originaler v2.6.2 ist die kleinste RESET-time die ich finden konnte 
48us, mit meinem obig vorgeschlagenem Patch 52.8us.
Ich kann mir zwar nicht vorstellen, dass es ws2812 gibt, denen 48us 
nicht reichen, vermute aber dennoch, dass das hüpfen damit zu tun hat.

0xef

PS.: Nebenbei sind mir noch ein paar merkwürdige mini-updates (nur 
24bit) aufgefallen, bei denen kurz nacheinander (110us) vällig andere 
Daten übertragen werden. Kommt allerdings nur kurz nach dem Einschalten 
und wird ca. 500ms später mit full-updates eh wieder berichtigt.

PPS.: @Frank: Wäre es eine Idee, das Doublebuffering in display.c zu 
verschieben? sonst musst du das im Prinzip auch noch bei den APA102 
duplizieren....

PPPS.: verwendeter Patch für ws2812.c:

     current_led_offset      = 0;
-    current_data_pause_len  = DATA_LEN(n_leds) + PAUSE_LEN;
+    current_data_pause_len  = DATA_LEN(n_leds) + WS2812_BIT_PER_LED + PAUSE_LEN;
     current_leds            = n_leds;

[0xef (Gast)]

Nachtrag:
mit originaler v2.6.3 ist das kleinste Reset ca. 220us. Also definitiv 
groß genug. Und da double-buffering eine richtig gute Idee ist, sollten 
war alles so lassen. (man könnte verwegenerweise sogar versuchen, die 
eigentlich richtige pause in ws2812.c ganz wegzulassen, da das 
rumkopieren vom double-buffering eh länger braucht. Aber so, wie es 
jetzt ist ist, ist es erstmal gut.)

0xef

[Frank M. (ukw) (Moderator)]

0xef schrieb:
> So, hab mal das Timing vermessen:

Danke für die Messungen! :-)

> Ich kann mir zwar nicht vorstellen, dass es ws2812 gibt, denen 48us
> nicht reichen, vermute aber dennoch, dass das hüpfen damit zu tun hat.

Nein, die Ursache hatte ich schon erklärt: In 2.6.2 wurde in rgb_buf 
geschrieben, während die ISR diese noch abgearbeitet hat:

Beitrag "Re: WordClock mit WS2812"

Mit der Länge der Pause warst Du einfach auf dem falschen Dampfer, 
deshalb hat das Double-Buffering das Problem vollständig gelöst. Und der 
memcpy ist leider nötig, weil sonst der "andere Teil" des rgb_buf nicht 
den aktuellen IST-Zustand widerspiegelt.

> PPS.: @Frank: Wäre es eine Idee, das Doublebuffering in display.c zu
> verschieben? sonst musst du das im Prinzip auch noch bei den APA102
> duplizieren....

Nein, in apa102.c wird kein kleiner DMA-Buffer benutzt, sondern 
weiterhin ein großer für alle LEDs, sodass kein Update während der 
DMA-Übertragung mehr passiert. Ich habe mir die RAM-Optimierung für 
apa102 verkniffen, weil dort die SPI-Daten wesentlich kleiner sind. Hier 
wäre eine die RAM-Ersparnis gar nicht so groß gewesen.

0xef schrieb:
> mit originaler v2.6.3 ist das kleinste Reset ca. 220us.

Weia, ich hätte nicht gedacht, dass der memcpy() so lang braucht. Nicht 
so schön. Ich muss mal überlegen, ob man das optimieren kann...

[Mirco D. (bpoh_voodoo)]

Hallo zusammen,

nachdem nun alles läuft ,wie es soll nur nochmal zu Sicherheit:
Wo ist genau auf dem alten Schield R1 und R2 für den LDR?

@Frank
einen kleinen Wunsch hätte ich noch bezüglich des LDR.
Kannst du sowas wie eine Mittelwertbildung einbauen, damit der etwas 
träger wird?

Meinetwegen ganz einfach ein gewichtetes Mittel:

ldr_value = ((x * ldr_oldvalue) + ldr_new_value)/(x+1)


Beim vorbeilaufen ändert sonst die Uhr umgehend die Helligkeit,
die Sonne geht aber so schnell nicht unter ;-)
ist aber nicht so wichtig.
x könnte man ja auf der LDR Seite konfigurierbar machen, so wie die 
Helligkeitswerte zwischen 0 bis 15.

MfG
Mirco

[Günter H. (gnter_h534)]

Mirco D. schrieb:

> Wo ist genau auf dem alten Schield R1 und R2 für den LDR?

Die Bauteilbezeichnungen habe ich in das Bild eingetragen.

[Waleri (Gast)]

Hallo an alle,

mir ist aufgefallen dass es bei raus genommenem Haken "Permanent display 
of "ES IST"", es um 16 Uhr trotzdem angezeigt wird.
Kann das jemand nachvollziehen?
Mir ist das bis jetzt nur Mittags um 4 Uhr aufgefallen.

Kann ich das Selbs irgendwo im Code ändern?

Gruß Waleri

[Ph L. (filo)]

Günter H. schrieb:
> Dafür wären (detailreiche) Bilder der Löt- und auch der Bestückungsseite
> der Platine hilfreich.

Danke für die Antwort. Anbei die Bilder.

[Mirco D. (bpoh_voodoo)]

Günter H. schrieb:
> Die Bauteilbezeichnungen habe ich in das Bild eingetragen.

Dann ist ja doch alles wie es soll bei mir. Ich war nun etwas unsicher.

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> einen kleinen Wunsch hätte ich noch bezüglich des LDR.
> Kannst du sowas wie eine Mittelwertbildung einbauen, damit der etwas
> träger wird?

Der Punkt steht bereit auf der Liste der geplanten Features für 2.7.0 im 
Artikel:

https://www.mikrocontroller.net/articles/WordClock_mit_WS2812#Geplante_Features_f.C3.BCr_Version_2.7.0

"FIR-Filter für automatische Helligkeitsregelung"

[Günter H. (gnter_h534)]

Ph L. schrieb:

> Anbei die Bilder.


Hallo "Ph",

viele der Lötstellen sehen nicht wirklich gut aus: Grün ist wohl ok, 
gelb eher nicht und rot wahrscheinlich nicht. Die Markierungen haben 
keinen Anspruch auf Vollständigkeit. Auch scheinen noch einige 
Lötzinnreste auf der Platine zu sein.

Viele der Lötstellen sind von Leiterbahnen mit Massepotential umgeben 
und bei der Größe deiner (sorry) "Lötklekse" kann trotz Lötstopplack ein 
Kurzschluss verursacht werden.

Vorschlag: Spreche jemanden an, der einige Erfahrung im Löten hat. 
Vielleicht kann der das Shield noch "retten" und du kannst direkt sehen, 
was beim Löten wichtig ist.

Zum AMS1117: Du hast den Baustein im SOT-223-Gehäuse direkt auf das 
Shield gelötet. Zwar richtig angeschlossen - es fehlen aber die 
Kondensatoren an Ein- und Ausgang und vor allem: Die "Unterseite" des 
ICs liegt auf 3,3 V, ob da der Lötstopplack gehalten hat, ist fraglich.

Gemeint sind da solche "Module" wie z. B. 
http://www.ebay.de/itm/252237092737?clk_rvr_id=1196973484702&rmvSB=true

Die Links im Artikel sind leider nicht ganz eindeutig.

Hier

Beitrag "Re: WordClock mit WS2812"

kannst Du in dem Bild unten links ein solches Modul im eingebauten 
Zustand sehen.

Viel Erfolg
Günter

[Dario C. (dario)]

Hallo,

aus gegebenem Anlass teste ich teste gerade das OTA.
Habe zwei Uhren, bei einer ging es, bei der anderen
kommt:

 Updating STM32 firmware...
 Downloading wc12h-stm32f103-ws2812-grb.hex... done.
 Start Bootloader
 Trying to enter bootloader mode...
 Timeout
 Trying to enter bootloader mode...

Wo muss ich suchen?

[Ph L. (filo)]

Wow, danke Günter für die ausführliche Hilfe.
Wäre vielleicht ganz clever gewesen die ersten Lötversuche nicht gleich 
auf dem Shield zu starten. :/
Im Prinzip hat alles funktioniert, hatte auch schon den STM32 und das 
WLan Modul geflasht, nur die Stromversorgung der LEDs macht Probleme.
Zu den Kondensatoren des AMS1117, ich dachte das sind der 100nF und 
4,7µF auf dem Shield? Brauche ich da noch zusätzliche Kondensatoren?

Falls jemand noch ein Shield übrig hat, welches er mir verkaufen kann 
würde ich mich über eine PN freuen.

[0xef (Gast)]

0xef schrieb:
> PS.: Nebenbei sind mir noch ein paar merkwürdige mini-updates (nur
> 24bit) aufgefallen, bei denen kurz nacheinander (110us) vällig andere
> Daten übertragen werden.

Korrektur: mit 24MHz nachgemessen passt alles. Da wird wohl nur die 
Statusled auf schwarz gesetzt.
(Merke: wer nur mit MHz sampled kann pulsbreiten nur auf +/-250ns genau 
messen - ggfs. zu wenig um bei ws2812 protokoll ne 0 von ner 1 zu 
unterscheiden....)

0xef

[Frank M. (ukw) (Moderator)]

Dario C. schrieb:
> aus gegebenem Anlass teste ich teste gerade das OTA.
> Habe zwei Uhren, bei einer ging es, bei der anderen
> kommt:
>

>  Updating STM32 firmware...
>  Downloading wc12h-stm32f103-ws2812-grb.hex... done.
>  Start Bootloader
>  Trying to enter bootloader mode...
>  Timeout
>  Trying to enter bootloader mode...
>

> Wo muss ich suchen?

Der Bootloader des STM32 antwortet nicht. Dafür kann es mehrere 
Möglichkeiten geben, daher meine Frage: Ist das Shield v3 oder ein 
umgebautes älteres? Wenn letzteres, solltest Du nochmal die zusätzlich 
nötigen Verbindungen vom ESP zum STM32 prüfen, also:

1. GPIO4 zu BOOT0 des STM32
2. GPIO13 an PA9
3. GPIO15 an P10
4. GPIO14 an RESET

Handelt es sich um das Mini-Dev-Board oder ein Nucleo? Bitte mehr 
Angaben.

[Dario C. (dario)]

Komisch, ich habe zweimal die identischen Bauteile verwendet.

- STM32F103C8T6 Mini Development Board
- Shield v3
- ESP-12F

Das was nicht geht habe ich gerade von der Wand genommen und 
nachgemessen:

> 1. GPIO4 zu BOOT0 des STM32
> 2. GPIO13 an PA9
> 3. GPIO15 an P10
> 4. GPIO14 an RESET

2-4: OK

Aber nicht GPIO4, sondern GPIO5 ist mit BOOT0 verbunden.
Vorausgesetzt das Pinout des ESP-12F ist so wie im Schaltplan
WC_MiniDev_Shield_v3_Schaltplan.png:
<pre>
Reset       TX
ADC         RX
CH_PD    GPIO5
GPIO16   GPIO4
GPIO14   GPIO0
GPIO12   GPIO2
GPIO13  GPIO15
VCC        GND
</pre>

Und es ist kein Kurzschluss zwischen GPIO5 und GPIO4.

[Dario C. (dario)]

So, habe die andere Uhr auch von der Wand genommen und siehe da,
auch die ist nicht so verdrahtet, wie es im Schaltplan steht:
Es ist der dritte Pin (GPIO5) mit Boot0 verbunden und nicht der vierte 
(GPIO4).

Da diese aber funktioniert, habe ich bei der anderen nochmal an alle 
vier Verbindungen nachgelötet und jetzt geht sie auch.

Bleibt die Frage, ob nun der Schaltplan falsch ist, oder zumindest die
Position der Pins nicht mit den Positionen auf dem Board übereinstimmen?

Kann das jemand bestätigen?

Dario.

[Günter H. (gnter_h534)]

Ph L. schrieb am 04.04.2017:

> musste nun leider feststellen, dass ein Kurzschluss zwischen Ground und
> 5V ist.
> Ich vermute den Fehler entweder "im" Shield oder auf dem STM32.
> Sichtbare Lötstellen sind alle schon als Fehlerquelle ausgeschlossen.
> Ist es denn allgemein möglich, dass Leiterbahnen im Shield irgendwo
> kurzgeschlossen sind?
>
> Des Weiteren ist auch der 3.3V Pin auf dem STM32 in Kontakt mit Ground.
> Aus diesem Grund denke ich, dass ich vielleicht den Microcontroller beim
> Löten gegrillt habe.

Ph L. schrieb am 08.04.2017:

> Im Prinzip hat alles funktioniert, hatte auch schon den STM32 und das
> WLan Modul geflasht, nur die Stromversorgung der LEDs macht Probleme.

Nach meinem Verständnis widersprechen sich die beiden Aussagen.
- Gibt es den "Kurzschluss" immer oder nur dann, wenn die LEDs an das 
Shield angeschlossen sind?

- Was heißt: "Im Prinzip hat alles funktioniert, hatte auch schon den 
STM32 und das WLan Modul geflasht..."? Ist (oder war) die Hardware über 
WLAN erreichbar?

- Welche Stromaufnahme haben die LEDs alleine? Etwa 80 mA pro 100 LEDs 
(alle Pixel aus) sind normal.

> Zu den Kondensatoren des AMS1117, ich dachte das sind der 100nF und
> 4,7µF auf dem Shield? Brauche ich da noch zusätzliche Kondensatoren?

- Das Shield für das Mini-Dev-Board ist für ein Modul wie z. B. dieses

http://www.ebay.de/itm/5PCS-AMS1117-3-3-3-3V-DC-DC-Step-Down-Power-Module-Buck-Module-LDO-800MA-/381599529100?hash=item58d91ab88c:g:5PMAAOSw-RRXDJnk

ausgelegt - dieses Modul sollte auch eingesetzt werden.

- Bevor Du mit einem neuen Shield wieder anfängst: Die Verwendung von 
Wannenstecker, Schraubklemmen usw. macht schon Sinn und sollte umgesetzt 
werden.

- Und - wirklich Löten üben, z.B. so wie hier:

https://wiki.raumzeitlabor.de/wiki/L%C3%B6ten_lernen

Viel Erfolg
Günter

[Frank M. (ukw) (Moderator)]

Dario C. schrieb:
> So, habe die andere Uhr auch von der Wand genommen und siehe da, auch
> die ist nicht so verdrahtet, wie es im Schaltplan steht:
> Es ist der dritte Pin (GPIO5) mit Boot0 verbunden und nicht der vierte
> (GPIO4).

Ja, es hat sich herausgestellt, dass in der Eagle-Lib für den ESP-12F, 
die Torsten für das Shield verwendete, ein Bug ist. Den zunächst 
auffälligen Fehler, der hier auch in diesem Thread auffiel, war, dass 
GPIO4 und GPIO5 von der Pin-Position im Schaltplan her vertauscht war. 
Torsten nahm an, dass es sich lediglich um die Bezeichnungen der Pins 
handelte und hat kurzerhand die Beschriftung beider Pins ausgetauscht.

Aber das war nicht der Fehler: Im Schaltplan vertauscht Eagle die beiden 
Pins, aber nicht im Schaltungs-Layout. Daher hat Torstens Änderung 
nichts bewirkt, lediglich, dass die Verbindung augenscheinlich von GPIO4 
ausgeht, aber auf der Platine dann doch von GPIO5. Das ist aber erst 
aufgefallen, als die Platinen schon bei Torsten waren bzw. ich dann eine 
der Platinen als erster in den Händen hatte und direkt die Uhr aufbaute 
und getest habe. Ich habe dann kurzerhand die ESP-Software angepasst: 
diese schaltet nun beide Pins, also GPIO4 und GPIO5 synchron. Nur so 
blieb die Kompatibilität zu den bisher umgebauten Shields mit separatem 
ESP-12F gewährleistet.

Kurzum: Das ist normal. Auf den v3-Shields wird GPIO5 verwendet, obwohl 
im Schaltplan GPIO4 steht. Geschaltet werden beide Pins, so dass es mit 
GPIO4 als auch mit GPIO5 funktioniert. Ist zwar schade, dass dadurch ein 
freier Pin am ESP wegfällt, ist aber auch nicht wirklich tragisch.

> Da diese aber funktioniert, habe ich bei der anderen nochmal an alle
> vier Verbindungen nachgelötet und jetzt geht sie auch.

Na prima. Manchmal hilft Nachlöten tatsächlich ;-)

[X. O. (overflow)]

Frank M. schrieb:
> X. O. schrieb:
>> Die letzten Änderungen scheinen es echt gebracht zu haben und das
>> Problem mit den verschobenen Bildern zu beheben.
>
> Prima, freut mich. Die neue Version 2.6.3 ist jetzt auch online.
>
> Einziger Punkt:
>
>  - Bugfix: Flackern bzw. versetztes Ausgabe der Display-LEDs durch
>    Double-Buffering behoben.


Hi Frank, meine obige Aussage hatte sich ja auf deine Wc24h 2.6.3pre 
Version bezogen die ich probehalber mal auf der WC12h getestet hatte. 
Wollte eben die 2.6.3 auf die WC12h aufspielen:

--> mit wc12h-stm32f103-ws2812-grb.hex springt die Anzeige nach wie vor
--> mit wc24h-stm32f103-ws2812-grb.hex springen die Leds nicht (zum 
Testen aufgespielt)

Ich habe jetzt mal die WC24h Variante der 2.6.2 auf die WC12h 
aufgespielt und auch dort springt nichts.

Blöde Frage, aber mit 2.4 läuft noch alles ohne Probleme. Bei den neuen 
Variante tritt auf meiner WC12h das springen auf. Und nur mit der WC12h 
Variante. WC24h dimmt wie sie soll. Passt da vielleicht was nicht?

[Frank M. (ukw) (Moderator)]

X. O. schrieb:
> Wollte eben die 2.6.3 auf die WC12h aufspielen:
>
> --> mit wc12h-stm32f103-ws2812-grb.hex springt die Anzeige nach wie vor
> --> mit wc24h-stm32f103-ws2812-grb.hex springen die Leds nicht (zum
> Testen aufgespielt)

Merkwürdig. Verstehe ich erstmal nicht.

> Ich habe jetzt mal die WC24h Variante der 2.6.2 auf die WC12h
> aufgespielt und auch dort springt nichts.

Meinst Du hier wirklich die 2.6.2 oder war das ein Vertipper und Du 
meintest die 2.6.3?

> Blöde Frage, aber mit 2.4 läuft noch alles ohne Probleme.

Die 2.4 benutzt auch noch den großen DMA-Buffer, der einen Großteil des 
RAMs des STM32F013 gefressen hat.

[X. O. (overflow)]

Nein, ich meinte schon 2.6.2.

[Frank M. (ukw) (Moderator)]

Das wird ja immer rätselhafter. Komischerweise kann ich nichts von 
alledem reproduzieren. Ich habe jetzt mal die Pause von 48µs auf über 
die geforderten 50µs verlängert. Obwohl ich kaum glaube, dass dieses was 
bringt, weil 0xef ja herausgefunden hat, dass die Pausen sowieso minimal 
220µs sind, habe ich die Datei hier mal angehängt.

Wie äußert sich das Springen? Versatz um 1 oder 2 LEDs oder flackern 
alle LEDs?

[Frank M. (ukw) (Moderator)]

Und hier nochmal dieselbe Variante mit EmBitz statt unter Linux 
compiliert. Bitte beide testen.

[0xef (Gast)]

Frank M. schrieb:
> weil 0xef ja herausgefunden hat, dass die Pausen sowieso minimal
> 220µs sind

Hallo Frank,

das war für die wc24h. Die wc12h messe ich morgen mal nach, komme heut 
nimmer dazu.

0xef

[Ph L. (filo)]

Günter H. schrieb:
> Nach meinem Verständnis widersprechen sich die beiden Aussagen.
> - Gibt es den "Kurzschluss" immer oder nur dann, wenn die LEDs an das
> Shield angeschlossen sind?

Den Kurzschluss gibt es dauerhaft.

> - Was heißt: "Im Prinzip hat alles funktioniert, hatte auch schon den
> STM32 und das WLan Modul geflasht..."? Ist (oder war) die Hardware über
> WLAN erreichbar?

Ja, ich hatte die Hardware schon als Client konfiguriert und konnte per 
IP im Browser darauf zugreifen.

> - Welche Stromaufnahme haben die LEDs alleine? Etwa 80 mA pro 100 LEDs
> (alle Pixel aus) sind normal.

Habe ich noch nicht gemessen, dazu müsste ich erst was basteln um die 
Streifen zu versorgen, das Shield geht ja momentan nicht.

> - Bevor Du mit einem neuen Shield wieder anfängst: Die Verwendung von
> Wannenstecker, Schraubklemmen usw. macht schon Sinn und sollte umgesetzt
> werden.

Wannenstecker und Schraubklemmen habe ich nur zur Fehlersuche 
abmontiert.

> - Und - wirklich Löten üben, z.B. so wie hier:
>
> https://wiki.raumzeitlabor.de/wiki/L%C3%B6ten_lernen
>
> Viel Erfolg
> Günter

das ist ne Idee :D Danke!

[0xef (Gast)]

0xef schrieb:
> das war für die wc24h. Die wc12h messe ich morgen mal nach, komme heut
> nimmer dazu.

Bei der wc12h finde ich ca. 183us als kürzeste Pause.
Der Datentransfer bei einem full-update (längste sequenz, die ich 
gefunden habe) dauert ca. 5.3ms.


Bei der von Frank bereitgestellten version (unter linux compiliert) 
finde ich 167us als Pause (Frank hat eine neuere toolchain, evtl. ist da 
das memcpy schneller?). Die Windows version hat 178us.

Zum Vergleich habe ich immer die gleiche Pause genommen....
(zwischen Full-update und minuten-led update nach der langen 
Einschaltpause von knapp 4s.)

Vom draufkucken her gebe beide Versionen 'identisch aussehende' 
led-daten aus und sollten sich identisch verhalten.

0xef

PS.: Ich bin überrascht, dass die Toolchain so einen starken Einfluss 
hat. Muss ich meine wohl updaten..

[Frank M. (ukw) (Moderator)]

0xef schrieb:

> Bei der wc12h finde ich ca. 183us als kürzeste Pause.
> Der Datentransfer bei einem full-update (längste sequenz, die ich
> gefunden habe) dauert ca. 5.3ms.

Danke fürs Nachmessen. Dann können wir eine zu kurze Pause auf jeden 
Fall ausschließen.

> Bei der von Frank bereitgestellten version (unter linux compiliert)
> finde ich 167us als Pause (Frank hat eine neuere toolchain, evtl. ist da
> das memcpy schneller?). Die Windows version hat 178us.

Möglich. Woran es sonst liegen könnte, weiß ich nicht.

> Vom draufkucken her gebe beide Versionen 'identisch aussehende'
> led-daten aus und sollten sich identisch verhalten.

Ehrlich gesagt, bin ich nun absolut ratlos. Es scheint ja nun bei allen 
zu funktionieren, die damit Probleme hatten. Nur bei X.O. mit seiner 
eigenen All-On-One-Platine nicht. Ich selbst habe mal testweise in 
display.c alle ws2812-refresh-Aufrufe verdoppelt, um die 
Software/Hardware zu stressen. Aber selbst dann konnte ich meine WC12h 
nicht aus der Ruhe bringen.

@X.O.: Hast Du noch eine WC24h, die mit Streifen aufgebaut ist? Dann 
könntest Du die Gegenprobe machen und die WC12h-SW mal darauf testen.

[Bernhard S. (b_sa)]

Nur mal 'ne kurze Frage am Rande:

Ich bastle mir gerade eine Abschaltung der Spannungsversorgung zu meinen 
V1 Shields. Bei dieser gelegenheit wollte ich dann auch gleich den 
Pullup fur die Datenleitung mit einbauen, kann ja nicht schaden. In 
Schaltbildern der aktuellen Shields habe ich gesehen, dass der Pullup 
direkt an die +5V geht. Das bedeutet aber doch, dass auch bei 
abgeschalteten Stripes an dem DI Spannung anliegt. Sollte man die nicht 
auch an die geschaltete Versorgungsspannung der Stripes anschließen?

OK, wenn ich den Widerstand direkt an die Stripes löte, dann habe ich eh 
die geschaltete Betriebsspannug dran.

Grüße
Bernhard

[0xef (Gast)]

Bernhard S. schrieb:
> Das bedeutet aber doch, dass auch bei abgeschalteten Stripes an dem DI
> Spannung anliegt.

Hallo Bernhard,

Wenn der stripe abgeschaltet wird, bleibt der entsprechende pin der mcu 
fix auf low. Also kein Saft an Din. Den dann eigentlich unnötigen 
querstrom durch den pullup könntest du tatsächlich sparen, wenn du ihn 
an die geschalteten 5V der stripes anschliesst. Habe ich bei mir auch so 
(glaube ich mich zu erinnern).

0xef

[X. O. (overflow)]

Frank M. schrieb:
> Das wird ja immer rätselhafter. Komischerweise kann ich nichts von
> alledem reproduzieren. Ich habe jetzt mal die Pause von 48µs auf über
> die geforderten 50µs verlängert. Obwohl ich kaum glaube, dass dieses was
> bringt, weil 0xef ja herausgefunden hat, dass die Pausen sowieso minimal
> 220µs sind, habe ich die Datei hier mal angehängt.
>
> Wie äußert sich das Springen? Versatz um 1 oder 2 LEDs oder flackern
> alle LEDs?

https://www.youtube.com/watch?v=xPTQp6aVeEw

Hier ein Video mit der obigen Version. Es schaut so aus, als ob sich die 
ganzen Wörter verschieben. "Es ist" hatte ich eingeschaltet. Was 
auffällt ist, dass sich der Minutenpunkt nicht verschiebt.
Was man auf dem Video nicht sieht, wenn die Verschiebung auftritt(und 
nur dann) wird in der Ambilightanzeige auf der Rückseite nochmals die 
Uhrzeit von vorne dargestellt. Die Minutenpunkte werden dabei zweimal 
hintereinander dargestellt, beginnend bei Led119 und Led123, also 
jeweils 4 Leds. Ab Led127 gehts dann mit "Es" weiter, bei Led130 "ist" 
usw. usw.
Wenn nicht gedimmt wird funktioniert auch die Ambilight Anzeige mit der 
umlaufenden Sekundendarstellung ganz normal.

> Und hier nochmal dieselbe Variante mit EmBitz statt unter Linux
> compiliert. Bitte beide testen.

Die Version hat keine Veränderung gebracht

> @X.O.: Hast Du noch eine WC24h, die mit Streifen aufgebaut ist? Dann
> könntest Du die Gegenprobe machen und die WC12h-SW mal darauf testen.

Leider habe ich keine hier, ich habe aber mal die WC24h Variante auf die 
WC12h aufgespielt. Die erste Led leuchtet nicht, da sie ja die Status 
Led wäre, "Es" sind Led 2+3 und "ist" 5+6+7. Wie man sieht funktioniert 
das Dimmen und es verschiebt sich nichts.

https://www.youtube.com/watch?v=f31rA0XimEY

Muss man das jetzt verstehen, dass es das eine mal funktioniert und das 
andere mal nicht? :)
Wenn die WC24h Version auch nicht funktionieren würde(oder ältere SW 
Variaten z.B. 2.4.0), würde ich mir ja direkt sagen, da ist irgendwas 
mit der Platine im Argen, aber so? Keine Ahnung was da los ist.


> Ehrlich gesagt, bin ich nun absolut ratlos. Es scheint ja nun bei allen
> zu funktionieren, die damit Probleme hatten. Nur bei X.O. mit seiner
> eigenen All-On-One-Platine nicht.

Ich bin auch ziemlich ratlos :)  Ich habe auch noch eine größere WC12h 
gebaut. Funktioniert tadellos mit 2.6.
Mich würde es zwar interessieren was da nicht passt, aber da ich 
anscheinend echt der Einzige bin der sich bis jetzt gemeldet hat können 
wir es zwecks meiner ja auch mal so belassen. 2.4.0 funktioniert soweit 
ja ganz gut.
Vielleicht tritt das Verhalten ja irgendwann doch noch bei irgendjemand 
anderem auf.

[0xef (Gast)]

Hallo X.O.,

hast du einen Logikanalysator zur Hand?
Saleae, USBee oder einen china-klon reichen völlig.
Falls ja, wie sieht das Datensignal an der ersten Led aus?
wie vor+nach der ersten die Probleme macht und wie vor den Ambilight 
leds?
(Normal+problemfall)

0xef

Ps.: Falls du noch keinen hast: die Dinger sind echt praktisch um 
komische timingprobleme zu debuggen, kauf dir doch einen (<10€).

[X. O. (overflow)]

0xef schrieb:

> Ps.: Falls du noch keinen hast: die Dinger sind echt praktisch um
> komische timingprobleme zu debuggen, kauf dir doch einen (<10€).

Ich habe mir jetzt so einen Saleae Clone bestellt. Schaut gut aus.

[Frank M. (ukw) (Moderator)]

X. O. schrieb:
> Die Minutenpunkte werden dabei zweimal hintereinander dargestellt,
> beginnend bei Led119 und Led123, also jeweils 4 Leds. Ab Led127 gehts
> dann mit "Es" weiter, bei Led130 "ist" usw. usw.

Das sieht so aus, als ob die WS2812 die Pause nicht erkennen, womit der 
Datenstrom wieder auf Position 0 (erste LED) zurückgesetzt wird. 
Entweder ist die Hardware ein Problem oder die Software - kann aber auch 
eine Kombination aus beiden sein.

Da Du eine extra Platine für die komplette Elektronik und keine 
Streifenplatinen benutzt, ist der Gedanke, dass die Hardware 
"problematisch" ist, nicht ganz von der Hand zu weisen.

Daher meine Fragen dazu:

1. Ist der "Angstwiderstand" in Reihe zu DI der ersten LED drin? Wenn 
ja, brücke den bitte.

2. Welchen Wert hat Dein Pullup an DI der ersten LED?

3. Hat jede WS2812 einen eigenen Entkoppelkondensator (typ. 100nF)? 
Diese sind zwingend notwendig.

4. Wie hoch ist die Betriebsspannung an der ersten LED? Wie hoch ist die 
Betriebsspannung einer mittleren und dann noch an der letzten LED?

5. Wie lang ist die Datenverbindung zur ersten LED? Sind da noch andere 
Datenleitungen auf der Platine nahe bei DATA für die erste LED?

Jetzt zur Software: Es könnte natürlich sein, dass aus irgendeinem Grund 
die Pausenzeiten nicht eingehalten werden. Das könnte zum Beispiel ein 
Überschreiber im RAM sein.

Bitte mach mal von jedem TAB im Webinterface eine Hardcopy, damit ich 
exakt Deine Konfiguration nachstellen kann.

[X. O. (overflow)]

Frank M. schrieb:
> X. O. schrieb:
>> Die Minutenpunkte werden dabei zweimal hintereinander dargestellt,
>> beginnend bei Led119 und Led123, also jeweils 4 Leds. Ab Led127 gehts
>> dann mit "Es" weiter, bei Led130 "ist" usw. usw.
>
> Das sieht so aus, als ob die WS2812 die Pause nicht erkennen, womit der
> Datenstrom wieder auf Position 0 (erste LED) zurückgesetzt wird.
> Entweder ist die Hardware ein Problem oder die Software - kann aber auch
> eine Kombination aus beiden sein.
>
> Da Du eine extra Platine für die komplette Elektronik und keine
> Streifenplatinen benutzt, ist der Gedanke, dass die Hardware
> "problematisch" ist, nicht ganz von der Hand zu weisen.
>
> Daher meine Fragen dazu:
>
> 1. Ist der "Angstwiderstand" in Reihe zu DI der ersten LED drin? Wenn
> ja, brücke den bitte.

Ist auf der Platine gebrückt, macht aber keinen Unterschied

> 2. Welchen Wert hat Dein Pullup an DI der ersten LED?

1,5 kOhm

> 3. Hat jede WS2812 einen eigenen Entkoppelkondensator (typ. 100nF)?
> Diese sind zwingend notwendig.

Ja, vorhanden 100nF

> 4. Wie hoch ist die Betriebsspannung an der ersten LED? Wie hoch ist die
> Betriebsspannung einer mittleren und dann noch an der letzten LED?

An allen Stellen 3,28V . Versorgung mit 5V Labornetzteil macht keinen 
Unterschied

> 5. Wie lang ist die Datenverbindung zur ersten LED?

Zwischen der 4 und 5 Led werden es schon gute 40cm sein. Ich habe jetzt 
aber mal die Datenleitung im unteren Bereich der Platine aufgetrennt und 
Led 1 dort angelötet, dass die Verbindung nur mehr circa 20 cm lang ist. 
Selbes Verhalten. Die Minutenpunkte bleiben stehen während dem Dimmen 
und die folgenden Wörter springen.

>Sind da noch andere
> Datenleitungen auf der Platine nahe bei DATA für die erste LED?

Nein, eigentlich nicht.


> Jetzt zur Software: Es könnte natürlich sein, dass aus irgendeinem Grund
> die Pausenzeiten nicht eingehalten werden. Das könnte zum Beispiel ein
> Überschreiber im RAM sein.
>
> Bitte mach mal von jedem TAB im Webinterface eine Hardcopy, damit ich
> exakt Deine Konfiguration nachstellen kann.

Habe ich angehängt und kannst du gerne testen. Wenn ich den 
Logicanalyzer da habe finde ich vielleicht auch mehr raus.

[Frank M. (ukw) (Moderator)]

X. O. schrieb:
> An allen Stellen 3,28V .

Die WS2812 brauchen 5V und nicht 3,3V. 3,28V sind definitiv zuwenig. 
Nach Berichten mit zu geringer Betriebsspannung äußert sich dies zunächt 
in Farbverfälschungen, dann mit Anzeigefehlern bis zum Totalausfall - je 
nachdem, wie tief man runtergeht.

Ich hätte also nicht damit gerechnet, dass die überhaupt noch gehen.

> Versorgung mit 5V Labornetzteil macht keinen Unterschied

Hm.

[X. O. (overflow)]

Sorry verschrieben. An den WS2812b lagen 5. 28V an.

[0xef (Gast)]

X. O. schrieb:
> An allen Stellen 3,28V . Versorgung mit 5V Labornetzteil macht keinen
> Unterschied

Aua!
Das sollte so nicht sein. Entweder netzteil zu schwach oder ein 
schaltungsfehler. Ams1117 richtigrum drin?

0xef

Ps.: Für mich sieht das auch so aus als ob die ws2812 den resetpuls 
nicht korrekt erkennen. Aber bei 3.28V wundert mich da nix, die brauchen 
halt ihre 5V!s

[0xef (Gast)]

X. O. schrieb:
> Sorry verschrieben. An den WS2812b lagen 5. 28V an.

Sorry, hab ich zu spät gesehen. Ändert sich was, wenn du nur mit 5V 
reingehst?

0xef

[Günter H. (gnter_h534)]

Auf der "All-in-one"-Platine gibt es laut BOM einen 
AMS1117-3.3V-Spannungsregler (V176) für die gesamte "3.3 V-Schiene". Bei 
Verwendung des STM32-Mini-Dev-Boards gibt es einen 3.3 V-Regler auf dem 
Board und einen zusätzlichen für das EPS8266-Modul (und die 
Peripherie).

Könnte das eine Rolle spielen?

[Peter G. (ingrimsch)]

Peter G. schrieb:
> Wenn ich kommende Woche ein wenig Leerlauf habe würde
> ich die Anleitung ins Wiki übertragen und auch deine Bilder übernehmen

Hat zwar doch etwas länger gedauert, aber heute hatte ich endlich mal 
etwas Luft. Ich hoffe die Formatierungen im Wiki sind OK so, falls es 
Darstellungsprobleme bei euch gibt kann das ggf. ja jemand korrigieren, 
der mit der Syntax schon mal richtig gearbeitet hat. ;-)

Danke nochmal an Günter H. für Anleitung und Bilder!

[X. O. (overflow)]

0xef schrieb:
> X. O. schrieb:
>> Sorry verschrieben. An den WS2812b lagen 5. 28V an.
>
> Sorry, hab ich zu spät gesehen. Ändert sich was, wenn du nur mit 5V
> reingehst?
>
> 0xef

Das Schaltnetzteil, das die 5.28V liefert ist ziemlich schrottig, aber 
5V vom Labornetzteil machen auch keinen Unterschied.

Da hilft wohl nur noch mit einem Logic Analyzer und Ozi mal die Pegel 
von den WS2812b durchzumessen.

Günter H. schrieb:
> Auf der "All-in-one"-Platine gibt es laut BOM einen
> AMS1117-3.3V-Spannungsregler (V176) für die gesamte "3.3 V-Schiene". Bei
> Verwendung des STM32-Mini-Dev-Boards gibt es einen 3.3 V-Regler auf dem
> Board und einen zusätzlichen für das EPS8266-Modul (und die
> Peripherie).
>
> Könnte das eine Rolle spielen?

Soweit richtig erkannt, habe jetzt parallel noch ein Labornetzteil mit 
3.3V direkt am ESP12F angehängt und es bringt keine Veränderung. Zudem 
wird der ASM1117 nichtmal lauwarm.
Den AMS würde ich ausschließen.

[0xef (Gast)]

Nachdem ich jetzt spasseshalber die v2.4.2 (svn:r77) mal gebaut und 
vermessen habe, verstehe ich, warum diese keine Probleme macht.
bei der wc12h (v2.4.2, f103,ws2812-grb) ist die kleinste Pause 111us, 
bei der wc24h 3.59ms (ja, ms!). Das Muster der 'Datenpakete' (nach dem 
initialem blank, der ca. 3s danach und vor der 'Einschaltanimation') ist 
auch anders als in späteren Versionen und unterscheidet sich signifikant 
zwischen wc12h und wc24h.

@X.O. Wenn du die v2.4.2 der wc12h aufspielst: geht dann alles, oder 
existiert das Problem auch und nur nicht bei der wc24h?

Das alles erklärt aber noch immer nicht, wieso deinenn LED's die 
inzwischen recht großzügigen Reset-pulse nicht reichen. Allerdings ist 
zwischen einigen 100us (111..232us jetzt) und vorher 3590us doch ein 
deutlicher Unterschied.

Frage1: hast du den pullup kurz vor der ersten LED, oder nahe am STM?
(Theorie: wenn der PULLUP an der LED ist, die Leitung lang und dünn, 
(und schlimmstenfalls noch Franks Angstwiderstand drin) könnte das LOW 
level recht hoch liegen und die Datenleitung leichter Störungen 
einfachen, (WS2812, die den neuen Datensatz übernehmen z.B.), so dass 
ggfs. die erste LED diese Störimpulse aufnimmt und dann weiterreicht...)

Frage2: Was passiert wenn du einen KLEINEN C (<<60pF) zwischen DIN und 
Masse schaltest? (Macht das einen Unterschied ob an der LED bzw. dem 
STM?)
(Gedanke hier: filtern wir die Störimpulse. der C darf aber nicht zu 
groß werden, sonst verschmieren die Flanken zu stark, dann müsste der 
PULLUP kleiner werden, dann passt der L-Pegel vielleicht noch 
weniger..... probier mal einen für Quarze typischen 'Balast-C' 
(12..22pF))

Weiter debuggen können wir wohl erst, wenn dein LA da ist....
(Ich empfehle ja sigrop/pulseview als software, da ist ein WS2812 
decoder schon mit bei.)

0xef

[X. O. (overflow)]

0xef schrieb:

> @X.O. Wenn du die v2.4.2 der wc12h aufspielst: geht dann alles, oder
> existiert das Problem auch und nur nicht bei der wc24h?

habe jetzt nochmals die WC12h 2.4.2 aufgespielt und nochmals genauer 
hingeschaut. Um genau zu sein funktioniert die Anzeige der Minutenpunkte 
und Wörter richtig. Mir ist aber gerade erst aufgefallen, dass die 
Minutenpunkte bei Led115 (und entsprechend 116,117,118, je nachdem 
wieviele gerade an sind)während des Dimmens dort nochmals dargestellt 
werden. Der Rest der Ambilightanzeige passt dann auch wieder. Und die 
Sekundenled läuft auch wie sie soll, auch während dem Dimmen wird dort 
nichts verschoben oder sonstwas angezeigt. (außer halt die 
Minutenpunkte, die verschwinden in der Ambilightanzeige wieder sobald 
die Helligkeit wieder stabil ist)
Ist mir leider erst jetzt aufgefallen.

> Das alles erklärt aber noch immer nicht, wieso deinenn LED's die
> inzwischen recht großzügigen Reset-pulse nicht reichen. Allerdings ist
> zwischen einigen 100us (111..232us jetzt) und vorher 3590us doch ein
> deutlicher Unterschied.
>
> Frage1: hast du den pullup kurz vor der ersten LED, oder nahe am STM?
> (Theorie: wenn der PULLUP an der LED ist, die Leitung lang und dünn,
> (und schlimmstenfalls noch Franks Angstwiderstand drin) könnte das LOW
> level recht hoch liegen und die Datenleitung leichter Störungen
> einfachen, (WS2812, die den neuen Datensatz übernehmen z.B.), so dass
> ggfs. die erste LED diese Störimpulse aufnimmt und dann weiterreicht...)

Der Pullup ist nah am STM und der 200Ohm Widerstand auch mit dran.
Ich hatte schonmal den LOW Pegel gemessen und der ist wirklich nicht 
sehr sauber

> Frage2: Was passiert wenn du einen KLEINEN C (<<60pF) zwischen DIN und
> Masse schaltest? (Macht das einen Unterschied ob an der LED bzw. dem
> STM?)
> (Gedanke hier: filtern wir die Störimpulse. der C darf aber nicht zu
> groß werden, sonst verschmieren die Flanken zu stark, dann müsste der
> PULLUP kleiner werden, dann passt der L-Pegel vielleicht noch
> weniger..... probier mal einen für Quarze typischen 'Balast-C'
> (12..22pF))

Der Quickfix mit einem 15pF Kondensator hat nichts gebracht. Evtl. 
müsste ich mal ein paar Kombinationen durchtesten und messen. Ich hatte 
auch mal einen Pullup direkt an Led 1 probiert.

> Weiter debuggen können wir wohl erst, wenn dein LA da ist....
> (Ich empfehle ja sigrop/pulseview als software, da ist ein WS2812
> decoder schon mit bei.)

Denke ich auch, in der Zwischenzeit werde ich aber nochmals mit einem 
Oszi alles durchmessen.
Als LA habe mir erstmal nur einen billigen Saleae Clone geholt. Bin 
gespannt wie gut der funktioniert.

> 0xef



Und Danke auch mal für eure Hilfe

[0xef (Gast)]

X. O. schrieb:
> Der Pullup ist nah am STM und der 200Ohm Widerstand auch mit dran.
> Ich hatte schonmal den LOW Pegel gemessen und der ist wirklich nicht
> sehr sauber

Lass mal die 200Ohm weg (brücken).
Außerdem versuch mal mit DICKEN Drähten sowohl an der ersten led als 
auch am ams 5v UND Masse einzuspeisen. Nicht dass aufgrund deiner 
Leiterbahnführung die (Masse/Vcc) Pegel verschieben.
(Insbesondere wenn dein Oszi kein sauberes Low findet.)

0xef

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> Kurzum: Das ist normal. Auf den v3-Shields wird GPIO5 verwendet, obwohl
> im Schaltplan GPIO4 steht. Geschaltet werden beide Pins, so dass es mit
> GPIO4 als auch mit GPIO5 funktioniert. Ist zwar schade, dass dadurch ein
> freier Pin am ESP wegfällt, ist aber auch nicht wirklich tragisch.

Müssen wir denn die Kompatiblität aufrecht erhalten. Wer ist denn von 
dem GPIO 4 Bug betroffen? Nur die V2 Shield Umbauler?
Ich kann meinen Umbau ggf. anpassen.

[Frank M. (ukw) (Moderator)]

Mirco D. schrieb:
> Müssen wir denn die Kompatiblität aufrecht erhalten. Wer ist denn von
> dem GPIO 4 Bug betroffen? Nur die V2 Shield Umbauler?

Ja. Aber ich kenne mindestens einen, der seine Uhr bereits verschenkt 
hat ;-)

Im Moment ist keine Not an Pins. Daher muss das nicht jetzt entschieden 
werden.

[Mirco D. (bpoh_voodoo)]

Frank M. schrieb:
> Ja. Aber ich kenne mindestens einen, der seine Uhr bereits verschenkt
> hat ;-)

Ok, dennoch würde ich vorschlagen das vorsichtshalber im Wiki auf GPIO5 
anzupassen, damit alle die ihren V2 Shield noch auf ESP-12 Umbauen, das 
nach dem V3 Schema tun. Falls die Entscheidung doch irgendwann fällt, 
sind es dann nicht noch mehr Betroffene, oder?

[Marco R. (majestick)]

Mirco D. schrieb:
> Ok, dennoch würde ich vorschlagen das vorsichtshalber im Wiki auf GPIO5
> anzupassen, damit alle die ihren V2 Shield noch auf ESP-12 Umbauen, das
> nach dem V3 Schema tun. Falls die Entscheidung doch irgendwann fällt,
> sind es dann nicht noch mehr Betroffene, oder?

Alternativ können auch V3 Nutzer den Pin um löten ;) Es soll einige 
geben die sich Adapterplatinen erstellt haben, bei dem GPIO04 genutzt 
wird.

Frage ist wie viele V3 Platinen im Umlauf sind, und wie viele Platinen 
umgebaut wurden.

Ich persönlich hätte hier, wenn die Software jetzt nur GPIO05 nutzen 
würde, ein großes Problem, da ich auf die meisten Uhren keinen direkten 
Zugriff mehr habe.

Denke es ist hier eher vollkommen Egal, welcher Pin genutzt wird. Die 
Software unterstützt beide und es sind noch genügen Pins am ESP12 frei. 
Mal ganz abgesehen davon das die anderen so oder so nicht rausgeführt 
sind und hier eh gebastelt werden müsste, sofern sie den für irgendetwas 
mal gebraucht würden.


Grüße
Marco

[Günter H. (gnter_h534)]

Marco R. schrieb:

> Ich persönlich hätte hier, wenn die Software jetzt nur GPIO05 nutzen
> würde, ein großes Problem, da ich auf die meisten Uhren keinen direkten
> Zugriff mehr habe.

Dem kann ich mich voll anschließen. OTA wurde umgesetzt, damit die Uhren 
an der Wand bleiben können und jetzt doch wieder umlöten?

Ok, das mit den Platinen aus der Sammelbestellung ist "dumm gelaufen", 
aber das parallele Ansteuern von GPIO04 und GPIO05 ist eine praktikable 
Lösung und ist drei Wochen lang (fast) keinem aufgefallen.

Gruß
Günter

[Rainer G. (ergerd)]

Ich habe meine erste WordClock12h gebaut, komme nicht weiter und hoffe 
auf einen Tipp.
Meine Ausstattung:
WS2812 RGB LED Stripe im Spezial-Raster für WordClock12h
STM32 MiniDevelopmentBoard Shield V3.0
STM32F103C8T6

Was geht:
WLAN-Verbindung zur Clock.
Upload der STM32 Firmware per OTA.

Was nicht geht:
Die LEDs der Clock leuchten an einigen Buchstaben schwach, kaum zu 
sehen, bilden aber keine Wörter, ändert sich auch nicht bei Test 
Display.
Die Einstellung auf der WebSite der Clock werden grundsätzlich nicht 
gespeichert.
In manchen Feldern stehen komische Zeichen (siehe Anhang).
In den Comboboxen steht i.d.R. nichts (siehe Anhang).

Was könnte das Problem sein?

Danke und Grüße
Rainer

[Thomas H. (supergrobi)]

Rainer G. schrieb:
> In manchen Feldern stehen komische Zeichen (siehe Anhang).
> In den Comboboxen steht i.d.R. nichts (siehe Anhang).

das könnte das gleiche Problem sein, das ich auch hatte.
Das Update/die Initialisierung des EEPROMs wurde abgebrochen oder ist 
fehlgeschlagen. Deshalb sind dort Werte hinterlegt, mit denen die Uhr 
nichts anfangen kann...

ob deswegen jedoch einige Buchstaben schwach oder gar nicht leuchten 
kann ich nicht sagen. Bei mir hat sich beim Senden der Werte an das ESP 
Modul der STM aufgehängt. Auf das WEB interface konnte ich noch 
zugreifen, da das ja autark im ESP läuft. Die Werte im WEB Interface 
waren natürlich auch Käse.
Teilweise ist der STM auch in einer laufenden Animation "gestorben", so 
daß einige LEDs nur noch mit geringer Helligkeit leuchteten...

Falls möglich, versuch mal ein anderes (neues) EEPROM Modul zu 
verwenden.

[Marco R. (majestick)]

Hallo Rainer,

was steht den unter "Main" ist der EEPROM Online?

Mal über UART mitgelauscht was das log so sagt? (Falls nicht hier bitte 
nur RX verbinden)

Evt. mal die Version 2.5 (oder älter) auf das STM flashen, dabei sollte 
eigentlich der EEPROM überschrieben werden. Sofern hier der Fehler 
liegt.

Gruß
Marco

[Andreas I. (andy5macht)]

Ich möchte mich auch mal zu Wort melden!
Zuerst einmal vielen Dank an Torsten Giese für das super verpackte 
Packet mit "Party-Pizzen" :D

Die erste Uhr ist auch schon aufgebaut. (12h mit V3 und WS2812)
Flashen und aufbauen funktionierte auch soweit. (STM: v3.6.3 / ESP: 
v3.6.4)
Ich habe nur einen Fehler in der Anzeige:
Die ersten 4 LED´s (Minuten) werden immer 1:1 an die nächsten 4 weiter 
gegeben (1=5...2=6 usw) erst danach (ab der 9. LED) kommt "ES IST 
usw..."
wisst ihr wie ich meine?
Edit:
- wenn ich die Zeit manuell einstelle passt es für eine Minute.
- wenn ich eien Reset ausführe passt es ebenfalls bis zum 
Minutenwechsel.

In den Logs ist nichts verdächtiges zu sehen:

power_init() called
switching power on

Welcome to WordClock Logger!
----------------------------
Version: 2.6.3
rtc is online
ws2812: external pullup detected
eeprom is online
current eeprom version: 0x00020600
ESP8266 LOGGER
read rtc: We 2017-04-12 19:57:07
esp8266 now up
(- setup UDP)
(- local port: 2421)
(- setup server UDP)
(- local port: 2424)
(FIRMWARE 2.6.4)
(- connected to AP)
(AP AndyWLAN)
(MODE client)
(IPADDRESS 192.168.0.38)
info: ip address = 192.168.0.38
esp8266 now online
--> time "192.53.103.103"<0d><0a>
(OK time)
(TIME 3701008635)
read rtc: We 2017-04-12 19:57:44
RTC temperature: 23
(- new client)
read rtc: We 2017-04-12 19:58:45
RTC temperature: 23
read rtc: We 2017-04-12 19:59:45
RTC temperature: 23
read rtc: We 2017-04-12 20:00:45

[0xef (Gast)]

Hallo Andreas,

Könnte ähnliche Ursache haben wie bei X.O.
kannst du mal die 2.4.x version auf dem stm versuchen?
Ich denke, dass beides durch die inkrementellen Updates ausgelöst wird 
(zwischen diesen sind die reset-pulse meist kürzer als zwischen den full 
updates. Und wenn dein erste Minutenled die pause nicht als solche 
erkennt, werden die minuten 'doppelt' angezeigt. Der Unterschied zu X.O. 
ist, dass es bei dir reproduzierbar scheint, auch wenn ich dieses 
Problem noch nicht nachstellen konnte).
Die eigentliche Ursache hält sich leider noch versteckt :(
Hast du Zugang zu einem Logikanalysator (oder wenigstens ein oszi)?
Sind die Leitungen zwichen leds und stm kurz? Abblockkondensatoren dran?
Versorgungsspannung? (Störimpulse)? Wie hoch ist der ruhe-pegel an Din 
der ersten Led? Pullup: wie groß? Angstwiderstand: ja/nein? Leds 
regelmä0ig mut 5v und massse versorgt?

0xef

Ps.: bin derzeit Unterwegs (keine hw dabei) und erst in 2 wochen zurück, 
kann also gerade nix testen.

[Andreas I. (andy5macht)]

Bisher hängt noch alles an einem Strang.
(5cm Kabel - nur am Anfang eingespeißt)
- C´s sind drauf.
- Kein Angstwiderstand
- Pullup=1,8k

Edit: mit der 2.4.1 springt die Anzeige nicht!

Am Oszi werde ich gleich mal Eingangsspannung und Datenleitung prüfen.

[0xef (Gast)]

Andreas I. schrieb:
> mit der 2.4.1 springt die Anzeige nicht!

Das hatte ich nach deiner Fehlerbeschreibung vermuted.

Hilft es den pullup auf 3k3 zu vergrößern? (oder 4k7?)

0xef

[Andreas I. (andy5macht)]

Ich habe keinen anderen Pullup ausprobiert, weil sich beim Messen mit 
dem Oszi ganz klar herausgestellt hat, dass das Datenpacket, welches die 
Minuten aktualisiert die Anzeige um genau 4 LED´s verschiebt.
Für mich ein Software-Bug. Hoffentlich helfen euch diese Hinweise!

es passiert auch direkt, wenn man:
Animation=None => Save drückt. (vorher Andere einstellen)

Temperatur wird (ohne Animation) ebenfalls "verrückt" ausgegeben.
Laufschrift(Ticker) wird (ohne Animation) korrekt ausgegeben.

Eine Animation rückt alles wieder gerade.

[Rainer G. (ergerd)]

Thomas H. schrieb:
> Falls möglich, versuch mal ein anderes (neues) EEPROM Modul zu
> verwenden.

Treffer. Nun kann ich sie konfigurieren und sie läuft sie auch, 
allerdings nur zwei, drei Minuten, dann kommen irgendwie die Worte 
durcheinander. Von "Es ist" wird z.B. nur das "s" aus dem ersten Wort 
und "st" aus dem zweiten beleuchtet, ähnlich bei den anderen Worten.

Woran könnte das liegen?

Danke und Grüße
Rainer

[Andreas I. (andy5macht)]

könnte es sein, dass die Anzeige ebenso wie bei mir um 4 Zeichen/LED´s 
versetzt ist? Hört sich für mich so an.
Led 1=5, 2=6 usw.?

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Ich habe keinen anderen Pullup ausprobiert, weil sich beim Messen mit
> dem Oszi ganz klar herausgestellt hat, dass das Datenpacket, welches die
> Minuten aktualisiert die Anzeige um genau 4 LED´s verschiebt.

Das hört sich für mich folgendermaßen an:

1. Es werden Daten für die 4 Minuten-LEDs rausgeschickt.
2. Die Pause nach den 4 LEDs ist zu kurz, so dass....
3. die nachfolgenden Daten hinten "angeklebt" werden.

Kannst Du das Oszi-Bild hier mal anhängen und den Pausen-Abstand nach 
den ersten 4 Minuten-LEDs ausmessen?

> Für mich ein Software-Bug.

Leider für mich bis jetzt nicht reproduzierbar :-(

Das ist alles dasselbe Problem welches X.O., Du und Rainer haben.

> Hoffentlich helfen euch diese Hinweise!

Das hoffe ich auch. Langsam wirds gespenstisch...

[Andreas I. (andy5macht)]

das heißt dass bei einem "Minuten-Update" nur Daten für die ersten 4 
LED´s rausgeschickt werden?!
Dieses Paket sollte dann ja um einiges kürzer sein, als ein "normales" 
Paket für die gesamte Anzeige.
Irgendwie verstehe ich die Logik noch nicht ganz. (das Datenblatt der 
LED´s habe ich gelesen)
Mein Verständnis:
- Pro LED 24bit, danach >50us Low => danach Daten für nächste LED usw.
- Wenn die Daten für die Minuten kommen, dann ist vor der 
Datenübertragung seeeehr lange Pause und danach auch wieder. 
(Minuten-Takt eben)
Welche Pause-Zeit meint ihr denn sei zu kurz?

Alle anderen Ausgaben funktionieren ja, für mich sieht es eher so aus 
als ob das Datenpaket falsch zusammengeschnürt wird...

PS: zur Info:
Es Zuckelt nichts, es Wackelt nichts. Es wird beim Minuten-Update die 
Anzeige um 4 LED´s versetzt ausgegeben bis eine Animation kommt. Bis zum 
Minuten-Update stimmt die Anzeige dann wieder.
Das ist mit meinem Setting zu 100% wiederholbar.

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Mein Verständnis:
> - Pro LED 24bit, danach >50us Low => danach Daten für nächste LED usw.

Nein.

Ein Datenblock definiert sich aus N x 24 Bit + 1 x Pause (>50µs). Die 
Pause bewirkt, dass die LEDs ihren Zähler zurücksetzen und den 
gewünschten RGB-Wert ausgeben.

Damit bedeutet ein Block für alle 4 Minuten:

  4 x 24 Bit + 1 x Pause.

Ein Block für das ganze Display (ohne Ambilight) bedeutet:

 114 x 24 Bit + 1 x Pause.

> Welche Pause-Zeit meint ihr denn sei zu kurz?

Wenn die Pause im Paket für die Minuten-LEDs...

  4 x 24 Bit + 1 x Pause.

zu kurz ist, dann wird das Paket für 114 LEDs von den LEDs selbst 
hintenangehängt, weil sie ihren Zähler nicht zurücksetzen. Dann 
erscheinen die 4 Minuten-LEDs nochmal in der Anzeige dahinter. Genau 
das hast Du doch geschildert, oder?

Also: die LEDs "sehen" ein Paket von 118 LEDs + 1 x Pause. Mich 
interessiert der Datenabstand zwischen den 4x24 Bit und den 114x24 Bit. 
Eigentlich sollte dieser größer als 50µs sein.

[Andreas I. (andy5macht)]

Ok. Wenn die Daten für die Minuten allein geschickt werden, dann bleibt 
der Rest der Anzeige bestehen, richtig?
Dann kann ich mir nicht vorstellen, dass nur dieses Paket geschickt 
wird, weil vor und nach dem "Minuten-Paket" sind etliche Sekunden pause.

Könnte es nicht sein, dass ein Paket für die gesamte Anzeige (incl 
Minuten) eintrifft und direkt danach ein 4er Paket für die Minuten und 
diese Daten werden von den LED´s zusammengepackt?
=> dann wäre das Minuten-Paket eigentlich überflüssig und könnte 
weggelassen werden.

PS: auf dem Oszi sieht man "nur" ein Paket, davor und danach wie gesagt 
etliche Sekunden pause.
Nur die positive Flanken sind ganz schön verschliffen. Werde euch 
nachher ein Bilchen davon schicken.

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Könnte es nicht sein, dass ein 4er Paket für die Minuten eintrifft und
> direkt danach ein Paket für die gesamte Anzeige (incl Minuten) und diese
> werden von den LED´s zusammengepackt?

Ja, das kann passieren.

> => dann wäre das Minuten-Paket eigentlich überflüssig und könnte
> weggelassen werden.

Das ist eine ganz andere Sache. Der Grund dafür ist folgende speziell 
für die WC12h:

Die Regel lautet hier:

1. Aktualisiere jede Minute alle Minuten-LEDs
2. Aktualisiere alle 5 Minuten das Display (evtl. mit Animation)

Dadurch passiert folgendes:

Minute 1: Aktualisiere die 4 Minuten
Minute 2: Aktualisiere die 4 Minuten
Minute 3: Aktualisiere die 4 Minuten
Minute 4: Aktualisiere die 4 Minuten
Minute 5: Aktualisiere die 4 Minuten
          + Aktualisiere das Display (evtl. mit Animation)

Da man beim Aktualisieren aus protokollspezifischen Gründen immer bei 
der ersten LED anfangen und nicht "mittendrin" aufsetzen kann, werden 
halt alle 5 Minuten ein kleines Paket (4 LEDs + Pause) und ein großes 
(114 LEDs + Pause) geschickt.

Klar, das kann man für Minute 5 optimieren, obwohl das auch nicht 
trivial ist. Die 5 Minuten-LEDs sind nicht-animiert, das Display 
allerdings schon. Aber darum geht es ja nicht, denn das muss trotzdem 
funktionieren. Sonst ist da ein Fehler. Und den gilt es zu finden. 
Reingekommen ist er offenbar mit der RAM-Optimierung: Bis Version 2.4 
wurde ein kompletter DMA-Buffer für alle LEDs verwendet (bis zu 11 KB je 
nach Variante), ab Version 2.5 wird ein klitzekleiner DMA-Buffer für 
lediglich 2 LEDs benutzt, der während des Transfers laufend aktualisiert 
wird. Das spart bis zu 11 KB RAM, macht aber alles viel komplizierter. 
Komischerweise ist der Fehler erst mit der Version 2.6 aufgefallen. Das 
Problem ist: Den Fehler haben nur einige wenige Leute, bei den meisten 
funktioniert es einwandfrei - wie zum Beispiel bei mir.

Andreas I. schrieb:
> Für mich ein Software-Bug.

Tja, das ist die Frage. Eigentlich müsste bei einem Software-Bug das 
jeder reproduzieren können. Dem ist aber nicht so.

Andreas I. schrieb:
> Nur die positive Flanken sind ganz schön verschliffen.

Wie groß ist der von Dir benutzte Pullup?

[Günter H. (gnter_h534)]

Frank M. schrieb:

> Den Fehler haben nur einige wenige Leute, bei den meisten
> funktioniert es einwandfrei - wie zum Beispiel bei mir.

Wenn ich das richtig verfolgt habe, sind bisher

- nur WC12h betroffen,
- zwei der Uhren mit dem Fehler verwenden Stripes mit Sonderabstand 
(Andreas und Rainer),
- eine der Uhren ist mit Einzel-WS2812b bestückt (X.O.).

Sind da verschiedene "Chargen" im Umlauf, die ggf. empfindlich auf das 
Timing reagieren und die beschriebenen Fehler zeigen?

[Andreas I. (andy5macht)]

Das habe ich verstanden.
Vielen Dank für die Aufklärung.
Allerdings habe ich nach wie vor die Vermutung, dass bei Minute 1-4 
nicht nur die Minuten Pakete ankommen - wie könnte sonst die gesamte 
Anzeige verschoben werden?

Aktuell habe ich 1,8k.
Werde aber noch größere werte Testen und je dazu ein Oszi Bild Posten, 
wenn ich wieder zu Hause bin.

[Frank M. (ukw) (Moderator)]

Günter H. schrieb:
> Wenn ich das richtig verfolgt habe, sind bisher
> - nur WC12h betroffen,

Ja, sieht so aus. Die vorher gemeldeten WC24h haben sich spätestens mit 
der Version 2.6.3 in Luft aufgelöst.

> - zwei der Uhren mit dem Fehler verwenden Stripes mit Sonderabstand
> (Andreas und Rainer),

Wie meinst Du das? Du meinst die speziellen Stripes von Torsten? Soviel 
ich weiß, hat er davon mehrere hundert Meter verschickt. Wenn die ein 
Problem hätten, dann wären es hier nicht nur 3 Leute.

> - eine der Uhren ist mit Einzel-WS2812b bestückt (X.O.).

Ja. Mehr Uhren, die den Fehler haben, sind auch nicht bekannt.

> Sind da verschiedene "Chargen" im Umlauf, die ggf. empfindlich auf
> das Timing reagieren und die beschriebenen Fehler zeigen?

Andreas und Rainer müssten da mal nähere Angaben machen, zum Beispiel 
die Länge der Datenleutung zur ersten LED und von der letzten 
Minuten-LED zur ersten Display-LED. Die Angabe, welches Shield und 
welche Shield-Version sie verwenden, ob es sich STM32F4xx oder STM32F103 
handelt, fehlt auch. Ebenso die Angabe über den 220 Ohm Angswiderstand 
in der Datenleitung.

[Andreas I. (andy5macht)]

Datenleitung 1.LED: ca 5cm.
Datenleitung 5.LED: kein bzw. an einem Stück / Neuerdings abgetrennt mit 
20cm dazwischen => kein Unterschied.

STM32F103 Shield V3.
Angstwiderstand: 0Ohm ;)

[Günter H. (gnter_h534)]

Frank M. schrieb:
> Wie meinst Du das? Du meinst die speziellen Stripes von Torsten?

Ja.

> Soviel
> ich weiß, hat er davon mehrere hundert Meter verschickt. Wenn die ein
> Problem hätten, dann wären es hier nicht nur 3 Leute.

Mir ist die Mindestbestellmenge für die Sonderfertigung in Erinnerung - 
aber auch die könnten ja inzwischen verschickt sein...

Mir geht darum, bei der Fehlersuche keinen Aspekt zu übersehen.

[Andreas I. (andy5macht)]

Anbei die versprochenen Oszi-Bilder.

A: Datenpacket einer Animation
B: Datenpacket(e) bei dem Minutenupdate => was ist das denn?
C: Pause nach dem großen Paket aus Bild B (166us)
D: Pause vor dem großen Paket aus Bild B (166us)
E: Einzelner Puls eines Pakets

alles mit 1,8k Pullup und den restlichen bereits genannten Settings.
Edit: mit 4,7k als Pullup ist es genau das gleiche Spiel. (nur die 
Flanke sieht dann noch viel schlechter aus)

Edit2: es liegt wirklich definitiv an den LED´s!
Ich habe eben ein Stück WS2812b (60LED/m) Parallel an den Strang 
gehängt.
Diese springt nicht! Der im Sondermaß von Torsten springt!

Edit3: gleich mal eine weitere Rolle von Torstens LED´s ranhängen...
Fazit: bei beiden Streifen von Torsten gibt es den Versatz um 4 LED´s
Bei meinem Streifen, der bereits Jahre hier rumliegt gibt es kein 
Versatz.

[Rainer G. (ergerd)]

Andreas I. schrieb:
> könnte es sein, dass die Anzeige ebenso wie bei mir um 4 Zeichen/LED´s
> versetzt ist? Hört sich für mich so an.
> Led 1=5, 2=6 usw.?

Stimmt, jetzt wo du es sagst :-)

Frank M. schrieb:
> Die Angabe, welches Shield und
> welche Shield-Version sie verwenden, ob es sich STM32F4xx oder STM32F103
> handelt, fehlt auch. Ebenso die Angabe über den 220 Ohm Angswiderstand
> in der Datenleitung.

Datenleitung 1.LED: ca 35cm.
Datenleitung 5.LED: ca 8cm.

STM32F103 Shield V3.
Angstwiderstand: Keine Ahnung, ist das der R2? Unbestückt.

Grüße
Rainer

[Andreas I. (andy5macht)]

Hier noch ein paar Oszi-Bilder mit Version 2.4.1
F: Pause vor dem großen Paket aus Bild G/H (102us)
G: Pause nach dem großen Paket (1,12ms) das ist fast Faktor 10! zur 
2.6.x
H: Datenpaket beim Minutenupdate

Rainer G. schrieb:
> STM32F103 Shield V3.
> Angstwiderstand: Keine Ahnung, ist das der R2? Unbestückt.

Angstwiderstand steht nicht in der Beschreibung vom Shield => also wirst 
du keinen haben.

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Edit2: es liegt wirklich definitiv an den LED´s!
> Ich habe eben ein Stück WS2812b (60LED/m) Parallel an den Strang
> gehängt.
> Diese springt nicht! Der im Sondermaß von Torsten springt!

Das ist ja endlich mal eine Erkenntnis! Ich habe auch welche von Torsten 
erhalten. Wegen Urlaub werde ich aber erst in einer guten Woche dazu 
kommen, diese zu testen.

Es liegt also nicht an den Pausen, sondern offenbar am Timing der Bits 
selbst. Die WS2812 und die WS2812B haben ein etwas unterschiedliches 
Timing, nämlich:

 *          WS2812          WS2812B
 *   T0H    350 ns          400 ns
 *   T1H    700 ns          800 ns
 *   T0L    800 ns          850 ns
 *   T1L    600 ns          450 ns

Alle Timings haben eine Toleranz von +-150ns.

Um den Code für beide Varianten einheitlich zu halten, habe ich folgende 
Timings gewählt:

 *   T0H    470 ns
 *   T1H    800 ns
 *   T0L    800 ns
 *   T1L    470 ns

Diese haben den Vorteil, dass sie symmetrisch sind, d.h. eine Bitlänge 
ist immer gleich lang, nämlich:

          T0H + T0L = T1H + T1L = 470 + 800 ns = 1270 ns

Das vereinfacht den Umgang mit einer PWM als Signalerzeuger erheblich.

Für eine WS2812B ist alles im grünen Bereich, jedoch könnte eine 
empfindliche WS2812 (ohne B) 470ns (statt 350ns) für T0H fast schon zu 
lang und T1L mit 470ns (statt 600) zu kurz ansehen. Die Toleranz von 150 
ns wird zwar eingehalten (Abweichung ist 120-130ns) und bisher ist alles 
gutgegangen, aber vielleicht ist es hier anders. Vielleicht sind ja 
Torstens LEDs keine WS2812B, sondern "intolerante" WS2812 ohne B.

Eins fällt mir aber noch dazu ein: X.O. benutzt definitiv nicht Torstens 
LEDs, er hat ja eine eigene Platine und keine Streifen.

Ich kann in den nächsten Tagen mal eine Testversion machen mit anderen 
Timings. Hat jemand einen Vorschlag für Werte, die beiden LED-Typen 
gerecht werden und trotzdem die Symmetriebedingung

          T0H + T0L = T1H + T1L

einhalten? Am schlimmsten ist die Asymmetrie bei der WS2812 mit T0H = 
350ns und T1L = 600 ns.

Finden wir keine symmetrischen Werte, wirds richtig eklig, ist aber auch 
machbar durch Verdoppelung des DMA-Buffers mit gleichzeiger Verdoppelung 
der CPU-Last während des Transfers.

@Andreas: Kannst Du mal messen, wie genau die gewählten 470ns und 800ns 
eingehalten werden?

[Andreas I (Gast)]

Ich glaube ja eher dass die Pause zwischen den Display und den Minuten 
Daten die Ursache für das Springen der LEDs ist. Springen immer um genau 
4 LEDs...
Bei Version 2.4.x war das 1,12ms und wird als neues Datenpaket erkannt.
Bei Version 2.6.3 ist das 166us und wird als weitere Daten erkannt.
Was meint ihr zu dieser Theorie?

[Frank M. (ukw) (Moderator)]

Zusatz, siehe WS2812 Ansteuerung:

"Die Herstellerangaben für das genaue Timing des Protokolls weichen 
teilweise zwischen unterschiedlichen Datenblattrevisionen ab. In der 
Praxis hat sich allerdings gezeigt, dass die Bauteile relativ tolerant 
gegenüber kleinen Timingfehlern sind."

In diesem Artikel werden andere Timings empfohlen:

                Zeit High           Zeit Low 
Kodierung "0"   0.35 µs ±150 ns     0.9 µs ±150 ns
Kodierung "1"   0.9  µs ±150 ns     0.35 µs ±150 ns

Jedoch ist T1L mit 350ns hier definitiv "raus" für die geforderten 600 
ns für T1L. Hier ist die Abweichung mit satten 250 ns definitiv daneben.

Aber vielleicht stimmen der Wert von T1L=600ns ja gar nicht, den ich 
damals in irgendeinem Datenblatt gefunden habe, als ich den Treiber für 
die WS2812 entwickelte? Denn mir kommt diese Asymmetrie ziemlich 
spanisch vor. Das 1-Bit mit 600+800 = 1400ns ist definitiv ein ganzes 
Stück länger als das 0-Bit mit 350+800=1150ns.

Ich werde daher die Werte mal so abändern, wie im Artikel empfohlen. Bis 
auf die T1L=600ns für die WS2812 ohne B wird dieses beiden LED-Typen 
gerecht. Am Wochenende schicke ich dann mal ein Update zum Test.

[Frank M. (ukw) (Moderator)]

Andreas I schrieb:
> Ich glaube ja eher dass die Pause zwischen den Display und den Minuten
> Daten die Ursache für das Springen der LEDs ist. Springen immer um genau
> 4 LEDs...
> Bei Version 2.4.x war das 1,12ms und wird als neues Datenpaket erkannt.
> Bei Version 2.6.3 ist das 166us und wird als weitere Daten erkannt.
> Was meint ihr zu dieser Theorie?

Das glaube ich eher nicht, obwohl mir dieser Gedanke vor ein paar Tagen 
auch schon durch den Kopf schoß:

Die Pause muss mindestens 50µs lang sein, das findet sich in allen 
Datenblättern. 166µs ist das Dreifache der geforderten Zeit und ist 
daher mehr als genug.

[Andreas I (Gast)]

Die WS2812 mit 4Pins sind doch immer die WS2812B
Die Version ohne B hat 6 Pins meine ich zu wissen. Ich wollte mit der 
Aussage "es sind die LEDs" auf Charge Bzw Toleranz der Pause Zeiten 
hinweisen.

[Frank M. (ukw) (Moderator)]

Andreas I schrieb:
> Die WS2812 mit 4Pins sind doch immer die WS2812B

Achso? Das wusste ich nicht.

> Die Version ohne B hat 6 Pins meine ich zu wissen. Ich wollte mit der
> Aussage "es sind die LEDs" auf Charge Bzw Toleranz der Pause Zeiten
> hinweisen.

Es wäre trotzdem nett, wenn Du die Pegelzeiten mal ausmessen würdest. 
Wie gesagt: Ich habe gestern auch von Torsten eine Rolle mit den LEDs 
bekommen, kann sie aber erst wg. Urlaub am übernächsten Wochenende 
testen. Dann werden wir spätestens eine Lösung finden - vorausgesetzt, 
ich kann dann endlich diesen Effekt reproduzieren.

[Andreas I (Gast)]

Ah ich hatte dann einen Denkfehler. Dachte die 50us müssen zwischen den 
Daten zweiter LEDs vorhanden sein. Aber es steht ja Reset da....Also ist 
das die Pause die es braucht um als ganz neues Datenpaket erkannt zu 
werden. Alles klar
Ich komme leider erst Montag wieder an mein Oszi

[Andreas I. (andy5macht)]

Über eine Testversion mit längerer Pause für die Minuten würde ich mich 
aber trotzdem freuen. Vielleicht sind die Biester ja weit entfernt vom 
Datenblatt.... Sieht auf den ersten blick so verdächtig aus... Das würde 
ich echt gern ausschließen. Und alle anderen Bits werden ja wunderbar 
erkannt... Also mich lässt der Gedanke mit der Pause nicht los.

[Thomas (Gast)]

> Für eine WS2812B ist alles im grünen Bereich, jedoch könnte eine
> empfindliche WS2812 (ohne B) 470ns (statt 350ns) für T0H fast schon zu
> lang und T1L mit 470ns (statt 600) zu kurz ansehen. Die Toleranz von 150
> ns wird zwar eingehalten (Abweichung ist 120-130ns) und bisher ist alles
> gutgegangen, aber vielleicht ist es hier anders. Vielleicht sind ja
> Torstens LEDs keine WS2812B, sondern "intolerante" WS2812 ohne B.

Torstens LEDs sind definitiv WS2812B, 4 statt 6 Pins.
Siehe auch 
https://www.mikrocontroller.net/attachment/203903/ws2812_compared.jpg

Die Betroffenen könnten mal die 5V Versorgung der LEDs genauer prüfen, 
ist hier alles in Ordnung?

Gruß Thomas

[Enrico F. (0xef)]

Erstmal großen Dank an Andreas fürs nachmessen!
Kannst du evtl. einen zweiten kanal des oszi hinter die mintenled 
anschliessen und beide simultan aufnehmen?
Da müsste man sehr schön sehen können, dass nach einem reset die ersten 
n*24 bit fehlen weil sie von den dazwischenliegenden led als eigene 
daten interpretiert werden. Ist denen der reset zu kurz, kommen die 
nächsten daten durch. Auch wärs super mal das timing der ausgegebenen 
bits anzusehen.

Da sich die led-timings zwischen v2.4 und v2.6 nicht geändert haben, die 
reset timings aber schon, ist klar dass dieser unterschied der auslöser 
sein muss.
Warum manche ws2812 jetzt einen deutlich längerenn resetpuls brauchen 
erklärt dies jedoch erstmal nicht.

Ich danke, dass wir am 'kompatibelsten' aus der Misere kommen, wenn 
diese mini-updates entfallen ( zumahl deren daten mit dem folgenden 
fullupdate eh gleich wieder überschrieben werden).
Entweder permanent mit 64Hz fullupdates (also alle 15.6ms für ca. 6ms 
Daten übertragen,  restliche Zeit pause) oder nur dann, wenn es sein 
muss, aber nur mit 64 hz prüfen.

Wenn Frank keine Einwände erhebt würde ich nächste Woche mal eine 
entsprechende Testversion basteln und bereitstellen (bin derzeit 
unterwegs).

Ich werde mal mein altes setup rauskramen, mit dem ich damals das timing 
meiner ws2812 durchgemessen habe. Ich würde gern einige der 
problematischen leds damit 'durchklingeln', vielleicht ergibt das was.
(Wenn dabei rauskäme, dass die resetzeiten aus dem datenblatt stimmen 
muss es eine andere Ursache geben).
Details per PN.

0xef

[Christian S. (duffbeer2000)]

So, nachdem ich vorgestern die Shields und Zwischenplatten erhalten habe 
sind beim Löten ein paar Fragen aufgetaucht:
1. Ist es Absicht das die zusätzlichen Teile für den Nucleo(Quarz und 
die 2 Kondensatoren) nicht im Warenkorb sind?
2. Bei der aktuellen Lieferung der Zwischenböden sind die Löcher der 
Magnete nicht ganz durchgebohrt, war das so gewollt!?

Gruß
Duff

[Rainer G. (ergerd)]

Thomas schrieb:
> Die Betroffenen könnten mal die 5V Versorgung der LEDs genauer prüfen,
> ist hier alles in Ordnung?

Ich habe da 4,82 V

Grüße
Rainer

[Wolfgang L. (gangl)]

Hallo

ich habe genau das selbe Problem mit den Minutenpunkten!

Aktueller Bestand : LED WS2812B mit Nucleo Board V3 /Shild V3 neueste 
Software.

Es ist nur alle 4-5 Minuten eine sauber Uhrzeit zu lesen!

Wo kommt den der Angstwiderstand rein? Und wie groß sollte er sein?

[Günter H. (gnter_h534)]

Wolfgang L. schrieb:

> Wo kommt den der Angstwiderstand rein? Und wie groß sollte er sein?

Der "Angstwiderstand" ist auf der aktuellen V3 der Shields nicht mehr 
berücksichtigt.

(Es war ein 220 Ohm-Widerstand zwischen dem WS2812-Anschluss des Boards 
und "WS2812-Data" auf dem Shield.)

> Es ist nur alle 4-5 Minuten eine saubere Uhrzeit zu lesen!

Die Behebung dieses Fehlers ist in Arbeit, siehe Beiträge weiter oben.

[Enrico F. (0xef)]

Hallo Wilfgang,

> Aktueller Bestand : LED WS2812B mit Nucleo Board V3 /Shild V3 neueste
> Software.
Nucleo-F401 oder F411? Meinst du v2.6.3?
Ws2812 von Torsten oder andere Bezugsquelle?

0xef

[Wolfgang (Gast)]

Frank M. schrieb:
> 1. Die Uhr hängt zwar in einem WLAN, aber dieses ist gar nicht mit
>    dem Internet verbunden - aus welchen Gründen auch immer.

Manche Leute verdrängen gerne, dass es auf deutlich mehr als 70% der 
Oberfläche der Erde mit Internet nicht so richtig gut bestellt ist, wenn 
man mal von Satellitenverbindung absieht.

Da wäre ein GPS Interface, also NMEA über serielle Schnittstelle und 
evtl. optional 1PPS Sekundenpulsauswertung eine Möglichkeit für die 
genaue Zeit.

[X. O. (overflow)]

Frank M. schrieb:
> Eins fällt mir aber noch dazu ein: X.O. benutzt definitiv nicht Torstens
> LEDs, er hat ja eine eigene Platine und keine Streifen.

Ja,  es sind nicht Torstens Leds, aber auch WS2812b. Evtl. gibts da ja 
wirklich Toleranzen beim Timing.
Ich bin ehrlich gesagt aber auch noch nicht dazu gekommen die Pegel und 
Signale mit einem Oszi oder SignalAnalyzer nachzumessen ob da alles 
sauber ist.
2.4 funktioniert noch komplett richtig(ohne Serienwiderstand), ab 2.5 
gibts Probleme. Ohne Pull-Up von circa 4kohm oder kleiner geht in beiden 
Fällen gar nichts.

Wolfgang schrieb:
> Da wäre ein GPS Interface, also NMEA über serielle Schnittstelle und
> evtl. optional 1PPS Sekundenpulsauswertung eine Möglichkeit für die
> genaue Zeit.

Die Genauigkeit der Zeit sollte mit dem DS3231SN eigentlich kein Thema 
mehr sein oder hast du anderweitige Beobachtungen gemacht, dass die Uhr 
merklich vor oder nach gehen würde?
Und die Umstellung von Sommer auf Winterzeit erspart dir leider auch der 
GPS Empfänger  nicht,  da GPS die Zeitumstellung nicht kennt.

[Wolfgang L. (gangl)]

Enrico F. schrieb:
> Nucleo-F401 oder F411? Meinst du v2.6.3?
> Ws2812 von Torsten oder andere Bezugsquelle?

Servus nochmal,

ich habe das Nucleo F411RE V3 und die Software V2.6.3 ESP V2.6.0

Die LED´s sind von Thorsten WS2811B!

wie komme ich denn an eine ältere Software Version die läuft?

Wir bauen die Uhr mit 6 Arbeitskollegen! Ich bin der erste der die Uhr 
fertig hat. Bis auf das verschieben der LED´s funktioniert alles 
einwandfrei. Werde sofort berichten wenn der fehler bei meinen Kollegen 
auch auftritt.

[X. O. (overflow)]

Wolfgang L. schrieb:

> wie komme ich denn an eine ältere Software Version die läuft?

Wie heißts immer so schön, das Internet vergisst nichts. :P
Ende Dezember hatte Torsten die 2.4 erstellt. Probier mal die aus. Bei 
mir hats damit funktioniert und Funktionsmässig ist die auf einem guten 
Stand.

https://www.mikrocontroller.net/articles/Spezial:Dateien?limit=500&ilsearch=&user=Ukw&offset=20161228233923

[Wolfgang L. (gangl)]

X. O. schrieb:
> Wie heißts immer so schön, das Internet vergisst nichts. :P
> Ende Dezember hatte Torsten die 2.4 erstellt. Probier mal die aus. Bei
> mir hats damit funktioniert und Funktionsmässig ist die auf einem guten
> Stand.
> 
https://www.mikrocontroller.net/articles/Spezial:Dateien?limit=500&ilsearch=&user=Ukw&offset=20161228233923

Perfekt, mit 2.4 ist das verschieben der Minuten weg!
Vielen Dank

[Simon K. (heinzschulze)]

Hallo zusammen,

und erstmal Frohe Ostern!

Auch ich konnte das Verschieben der Minuten mit der V2.6.3 beobachten, 
nachdem ich meine erste Uhr gestern fertig gestellt hatte.

Meine HW: WC12h, Mini-Development Board, Shield V3 und die WS2811 aus 
der letzten Sammelbestellung.

Die SW V2.4 eingespielt und die Zeit wird korrekt angezeigt. Somit ist 
erstmmal alle OK und meine Frau zufrieden.

Melde mich freiwillig als Tester, falls eine neue SW bereit steht.

Gruß
Simon

PS: Danke für das große Engagement aller Beteiligten, vorallem an Frank 
und Torsten!

[Andreas I. (andy5macht)]

Nachdem die Feiertage sich dem Ende neigen bin ich wieder in der Nähe 
meiner Hardware.
Also eben nochmal das Oszi bewegt euch die gewünschten Infos zu 
entlocken.
Die Bilder bzw. Dateinamen sprechen wohl für sich.
Eine zusätzliche Info:
- Die zeiten der einzelnen Bits unterscheiden sich überhautp nicht 
zwischen Version 2.4.1 und 2.6.3
Die Zeiten sind:
- Gesamt High-Bit: 1,28us
- Gesamt Low-Bit: 1,28us
- High-Bit hightime: 800ns
- High-Bit lowtime: 480ns
- Low-Bit hightime: 480ns
- Low-Bit lowtime: 800ns

Interessant sind demnach eher die Bilder A und H:
Darauf sieht man, dass am Anfang des großen Datenpakets auf Bild A die 
ersten Daten fehlen => werden richtig von den ersten 4 LED´s 
"geschluckt".
Auf bild H ist das nicht der Fall.
Daraus kann man schließen, dass die LED´s die kleinen Minutenpakete und 
das große Displaypaket "zusammenlegen" und nicht als "neues" Paket 
verstehen.

[Enrico F. (0xef)]

Andreas I. schrieb:
> Also eben nochmal das Oszi bewegt euch die gewünschten Infos zu
> entlocken.

Hallo Andreas,
vielen Dank für diese Info! Damit ist zwar nicht klar warum manche 
Ws2812b längere resets brauchen, aber manche tun es. Und das bit-timing 
ist nicht Schuld.
Ich bin noch auf Familienbesuch und versuche übermorgen eine Testversion 
bereitzustellen. Vorher gehts bei mir leider nicht...

0xef

[Florian R. (florifranzl)]

Hallo zusammen,

Anfängerfrage (davon kommen sicherlich demnächst noch mehr, da es jetzt 
endlich mal ans Werk gehen soll bei mir, nachdem die Sammelbestellungen 
eingetroffen sind):

Ich bestelle gerade bei Reichelt die Komponenten. Ich habe bisher nur 
mit Litze mit 1mm² Kabelquerschnitt gearbeitet, aber auch noch nichts im 
Bereich Mikrocontroller gemacht. Passt das für dieses Projekt, oder 
empfiehlt sich da mehr/weniger aus irgendwelchen Gründen?

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Darauf sieht man, dass am Anfang des großen Datenpakets auf Bild A die
> ersten Daten fehlen => werden richtig von den ersten 4 LED´s
> "geschluckt".
> Auf bild H ist das nicht der Fall.

So richtig eindeutig ist das für mich auf Bild H aber nicht zu 
erkennen...

Wie dem auch sei: Hier eine Testversion mit einer Pause von mind. 250 
µs, also dem Fünffachen der laut Datenblatt geforderten Pause von 50µs.

Ich bin gespannt.

[Günter H. (gnter_h534)]

Florian R. schrieb:

> Anfängerfrage (davon kommen sicherlich demnächst noch mehr,

Nur zu!

> Ich bestelle gerade bei Reichelt die Komponenten. Ich habe bisher nur
> mit Litze mit 1mm² Kabelquerschnitt gearbeitet, aber auch noch nichts im
> Bereich Mikrocontroller gemacht. Passt das für dieses Projekt, oder
> empfiehlt sich da mehr/weniger aus irgendwelchen Gründen?

Für die Verkabelung in der Uhr ist 1 mm² aus meiner Sicht zu viel: Die 
ist zu wenig flexibel, das wird alles zu "dick".

Meine WC12h habe ich mit 0,14 mm²-Litze verkabelt, lediglich für das 
("Verlängerungs"-)Kabel vom 5 V-Netzteil zur Uhr habe ich Zwillingslitze 
0,5 mm² verwendet, bei einer WC24h sollte man da 0,75 mm² vorsehen.

Schau Dir dazu die Bilder im Kapitel "Mechanik" des Artikels an und 
achte auf kurze Kabellängen, speziell beim Flachbandkabel, da haben die 
einzelnen Adern üblicherweise einen Querschnitt von 0,09 mm².

Viel Erfolg
Günter

[Andreas I. (andy5macht)]

Ging mir ebenfalls so.
Habe mit 0,75qmm von Stripe zu Stripe Verkabelt (5V/GND) und diese 
Verbindung ist zu dick, weil die Aluplatte dann nicht mehr eben auf dem 
Holz aufliegt.
Ich werde es ebenfalls ändern müssen auf z.b. 0,14qmm

Frank M. schrieb:
> Andreas I. schrieb:
>> Darauf sieht man, dass am Anfang des großen Datenpakets auf Bild A die
>> ersten Daten fehlen => werden richtig von den ersten 4 LED´s
>> "geschluckt".
>> Auf bild H ist das nicht der Fall.
>
> So richtig eindeutig ist das für mich auf Bild H aber nicht zu
> erkennen...
>
> Wie dem auch sei: Hier eine Testversion mit einer Pause von mind. 250
> µs, also dem Fünffachen der laut Datenblatt geforderten Pause von 50µs.
>
> Ich bin gespannt.

Ich habe die Bilder mal noch bearbeitet, daran sieht man den Unterschied 
besser.
Ich werde direkt nach Feierabend prüfen ob die verlängerte Pause 
ausreicht.

[Florian R. (florifranzl)]

Günter H. schrieb:
> Für die Verkabelung in der Uhr ist 1 mm² aus meiner Sicht zu viel: Die
> ist zu wenig flexibel, das wird alles zu "dick".
>
> Meine WC12h habe ich mit 0,14 mm²-Litze verkabelt, lediglich für das
> ("Verlängerungs"-)Kabel vom 5 V-Netzteil zur Uhr habe ich Zwillingslitze
> 0,5 mm² verwendet, bei einer WC24h sollte man da 0,75 mm² vorsehen.
>
> Schau Dir dazu die Bilder im Kapitel "Mechanik" des Artikels an und
> achte auf kurze Kabellängen, speziell beim Flachbandkabel, da haben die
> einzelnen Adern üblicherweise einen Querschnitt von 0,09 mm².
>
> Viel Erfolg
> Günter

Danke, das hätte ich nicht gedacht, dann bestell ich mir 0,14mm²-Litze.
Das 16-polige Flachbandkabel war ein guter Hinweis, das hatte ich noch 
nicht im Warenkorb. Die Lochrasterplatine ist mir in dem Kapitelteil 
auch noch aufgefallen, da hab ich auch noch eine einfache in den 
Warenkorb gepackt (lieber mit Beschichtung, als ohne?). Fällt jemandem 
sonst noch etwas ein, dass nicht in der Einkaufsliste aufgeführt ist, 
aber benötigt wird? Die Versandkosten bei Reichelt sind ja im Gegensatz 
zu den Artikelwerten sehr hoch.
Ggf. macht es Sinn, für diese Dinge noch eine Zeile in der Tabelle zu 
ergänzen, das benötigte Standardequipment, welches der regelmäßige Löter 
vielleicht eh im Fundus hat, aber jemand wie ich noch nicht.

[duffbeer2000 (Gast)]

Also die Lochrasterplatine brauchst meines wissens nicht, da der 
Wannenstecker inzwischen ja bereits auf der Platine untergebracht ist.
Wenn du den Nucleo benutzt (weiß ja nicht welche Uhr du baust) solltest 
du dir noch nen Quarz und 2x 22pf Kondensatoren besorgen:

https://www.reichelt.de/Quarze/8-0000-HC49U-S/3/index.html?ACTION=3&LA=5700&ARTICLE=32845&GROUPID=3173&artnr=8%2C0000-HC49U-S

https://www.reichelt.de/Vielschicht-SMD-G0603/NPO-0603AAF-22P/3/index.html?ACTION=3&LA=5700&ARTICLE=193759&GROUPID=3166&artnr=NPO+0603AAF+22P

Gruß
Duff

[Frank M. (ukw) (Moderator)]

Florian R. schrieb:
> Das 16-polige Flachbandkabel war ein guter Hinweis, das hatte ich noch

Ich verkable alles grundsätzlich mit dem Flachbandkabel. Einzelne Litzen 
kann man sehr einfach davon abtrennen.

[Florian R. (florifranzl)]

duffbeer2000 schrieb:
> Also die Lochrasterplatine brauchst meines wissens nicht, da der
> Wannenstecker inzwischen ja bereits auf der Platine untergebracht ist.

Danke, macht Sinn, in der Einkaufsliste sind auch Stecker und Buchse, 
also keine Platine mehr. Dann sind da Text und Bild wohl auch mal zu 
aktualisiseren.

Ich baue die einfache Standard-WC12h mit MiniDevBoard.

[Andreas I. (andy5macht)]

Frank M. schrieb:
> Andreas I. schrieb:
>> Darauf sieht man, dass am Anfang des großen Datenpakets auf Bild A die
>> ersten Daten fehlen => werden richtig von den ersten 4 LED´s
>> "geschluckt".
>> Auf bild H ist das nicht der Fall.
>
> So richtig eindeutig ist das für mich auf Bild H aber nicht zu
> erkennen...
>
> Wie dem auch sei: Hier eine Testversion mit einer Pause von mind. 250
> µs, also dem Fünffachen der laut Datenblatt geforderten Pause von 50µs.
>
> Ich bin gespannt.

Trommelwirbel...es funktioniert schonmal viel besser. Ab und an sehe ich 
noch ein Hüpfen, aber nicht zu 100% beim Minutenupdate wie bei der 2.6.3
Evtl. sollte noch etwas mehr zeit bzw. auch ein kleiner Puffer mit drin 
sein?

Edit: ich habe jetzt geschätzt zu 75% keine Verschiebung mehr. Die 
restlichen 25% teilen sich in Verschiebungen um 1-4 LEDs

[X. O. (overflow)]

Frank M. schrieb:

> So richtig eindeutig ist das für mich auf Bild H aber nicht zu
> erkennen...
>
> Wie dem auch sei: Hier eine Testversion mit einer Pause von mind. 250
> µs, also dem Fünffachen der laut Datenblatt geforderten Pause von 50µs.
>
> Ich bin gespannt.


Hallo Frank,

Perfekt :)

Also bei mir funktionierts damit. Komplett ohne Aussetzer, irgendwelche 
Verschiebungen oder sonstwas. Genau so wie es soll.

Vielen Dank

[Frank M. (ukw) (Moderator)]

Dann ist das aber eindeutig ein Bug in den LEDs. Am Wochenende kann ich 
dann selbst mit Torstens LEDs testen und dann die optimale Pausenlänge 
empirisch bestimmen. Vielleicht mache ich das auch in der Weboberfläche 
konfigurierbar.

[Harald L. (howy075)]

Hallo,

SUPER!!! die Uhr springt nicht mehr und macht genau was sie soll!!!

Habe es mit jedem verschiedenen Ambilight versucht und funktioniert nun 
top!

Sowohl bei meiner Uhr als auch bei meinem Testaufbau.

grüße
Harald

[Andreas I. (andy5macht)]

Ich nehme das mit den 25% Sprünge zurück!
Mein Testaufbau (mit den parallel geschalteten älteren WS2812B) hatte 
wohl für Unstimmigkeiten bei den LED´s gesorogt - hier sind die neueren 
von Torsten gehüpft, die älteren allerdings nicht.
Nichtsdestotrotz habe ich die Uhr jetzt fertig und den alten LED 
Streifen natürlich nicht mehr dran und siehe da: alles perfekt.

Vielen Dank, Frank!!!

[Rainer G. (ergerd)]

Hallo Frank,

ich schließe mich an, auch meine Uhr läuft jetzt, ich konnte keine
Verschiebungen mehr feststellen.

Vielen Dank und viele Grüße
Rainer

[Andreas B. (alidi)]

Hallo,

ich habe die Teile aus der Sammelbestellung erhalten und fange jetzt
mit dem Bauen an.
Folgende Fragen stellen sich mir deshalb:
a. Kann ich den Thread so einrichten, dass die neuesten Mitteilungen
zuerst erscheinen, ich also nicht jedesmal beim Aufrufen an das Ende 
gehen muss ?
b. Wie suche ich innerhalb des Threads ?
c. Wie suche ich innerhalb der Bastelanleitung ?
d. Werden die Magnete in den nicht durchgebohrten 8mm Löchern in den 
Zwischenböden von Wordclock12h und Wordclock24h von hinten eingebaut?
oder muß ich durchbohren ?
e. Wo wird das Nucleoboard Shield STM Basis im Zwischenboden 
Wordclock12h plaziert ? Die Taschen sind zu schmal.
f. Wieviel Meter 16pol Flachbandkabel 0,14mm² brauche ich für die 
Wordclock12h und Wordclock24h?

Ich freue mich auf die Antworten.
An dieser Stelle möchte ich den "Treiber" dieses Projektes danken.
Andreas/Alidi

[Andreas I. (andy5macht)]

Ich konnte doch noch ab und zu ein Hüpfen erzeugen und zwar wenn ich bei 
Tetris eine oder mehr Zeilen "abgebaut" habe.
Vermutlich sind wir noch etwas knapp an der Grenze zum Optimum.

[X. O. (overflow)]

Andreas B. schrieb:
> Hallo,
>
> ich habe die Teile aus der Sammelbestellung erhalten und fange jetzt
> mit dem Bauen an.
> Folgende Fragen stellen sich mir deshalb:
> a. Kann ich den Thread so einrichten, dass die neuesten Mitteilungen
> zuerst erscheinen, ich also nicht jedesmal beim Aufrufen an das Ende
> gehen muss?

In den Einstellungen kannst du zumindestens einstellen, dass der Treadh 
in kürzere Seiten veteilt wird.
Weiters kannst du in den Titel des letzten Posts klicken und diesen Link 
als Bookmark ablegen. Dann landest du wenigstens beim aktuell letzten 
Post. Musst du halt alle paar Tage/Wochen aktualisieren.

> b. Wie suche ich innerhalb des Threads ?

Den ganzen Thread auf einer Seite darstellen und mit der Browsersuche 
durchsuchen.

> c. Wie suche ich innerhalb der Bastelanleitung ?

Genau gleich. Im Prinzip würde ich dir aber mal raten die 
Bastelanleitung von Anfang bis Ende durchzulesen. Das hilft immens beim 
Bauen. Hatte ich zu Beginn auch nicht gemacht und hier deshalb oft genug 
unnötige Fragen gestellt. Lese es einfach durch. Spart auch dir selbst 
Zeit.
Alles was unklar ist wird hier dann schon beantwortet.

https://www.mikrocontroller.net/articles/WordClock_mit_WS2812

[Frank M. (ukw) (Moderator)]

Andreas I. schrieb:
> Ich konnte doch noch ab und zu ein Hüpfen erzeugen und zwar wenn
> ich bei Tetris eine oder mehr Zeilen "abgebaut" habe.
> Vermutlich sind wir noch etwas knapp an der Grenze zum Optimum.

Dann mache ich morgen noch eine 300us Version. Dann sollte der Spuk 
endlich vorbei sein.

[Enrico F. (0xef)]

Frank M. schrieb:
> Dann mache ich morgen noch eine 300us Version. Dann sollte der Spuk
> endlich vorbei sein.

Hallo Frank,

nachdem du jetzt schneller warst, wäre dies eine Gelegenheit die 
eigentlich überflüssigen mini-uodates, die das Problem erst zum 
Vorschein brachten, loszuwerden?

Ich meine uodates nur der Minutenleds gefolgt von einem update der 
wörtermatrix (welches ja die Minutenleds auch updated)?

0xef

[Günter H. (gnter_h534)]

Andreas B. schrieb:

> e. Wo wird das Nucleoboard Shield STM Basis im Zwischenboden
> Wordclock12h plaziert ? Die Taschen sind zu schmal.

Im Artikel steht dazu: "STM32F103C8T6 Mini-Development Board:
Dieses Board wird für die "klassische" 10x11 WordClock12h empfohlen".

> f. Wieviel Meter 16pol Flachbandkabel 0,14mm² brauche ich für die
> Wordclock12h und Wordclock24h?

Die Uhren haben eine Größe von 45 cm x 45 cm, kurze Leitungslängen sind 
erstrebenswert. Also müssten 50 cm vom Wannenstecker auf dem Shield bis 
zu den LED-Stripes locker reichen, nochmal 50 cm für die weitere 
Verkabelung
--> 1 m.

[Frank M. (ukw) (Moderator)]

Enrico F. schrieb:
> Frank M. schrieb:
> Dann mache ich morgen noch eine 300us Version. Dann sollte der Spuk
> endlich vorbei sein.
>
> Hallo Frank,
>
> nachdem du jetzt schneller warst, wäre dies eine Gelegenheit die
> eigentlich überflüssigen mini-uodates, die das Problem erst zum
> Vorschein brachten, loszuwerden?

Da dies eine ganz andere Schicht in der Software betrifft, möchte ich 
das im nächsten Update ungern tun. Die nächste 2.6.x soll eine stable 
Version sein. Software-Optimierungen, die eventuell wieder andere Löcher 
reissen, gehören in diie 2.7.0.

[Andreas I. (andy5macht)]

Darf ich mir für die 2.7er wünschen, dass bei Tetris kein weißer Rahmen 
um die Spielfläche gezogen wird? Dann ist (gerade bei der 12h Version) 
mehr Platz zum Austoben :D

[Gerhard D. (dittrg)]

Ich habe ein Paar Fragen zum Source Code 12h version
ich habe eine Frontplatte mit einem etwas anderen Layout.
Eine AM und PM Section und unten in der Mitte drei Buchstaben - SEK  für 
Sekunden. Kann man die Sekunden anzeigen so ändern das das nur über eine 
LED geht.
Bei einer anderen Uhr Version (nur mit esp8266) konnte ich das mit einer 
einfachen Abfrage realisieren
Sekunde = gerade dann LED an
Sekunde = ungerade dann aus

dann zwei neue Felder erstellen für Am, PM

und Vormittag - Nachmittag abfragen und anzeigen.

Ist unter Arduino Enviroment nicht ganz so schwierig.

Ich habe mir das Original mal unter embitz angeschaut , stehe aber noch 
etwas auf dem Schlauch.

Für einen Tip , wo  man den Quell Code ändern muss wäre ich sehr dankbar

[Gerhard D. (dittrg)]

Ich habe ein Paar Fragen zum Source Code 12h version
ich habe eine Frontplatte mit einem etwas anderen Layout.
Eine AM und PM Section und unten in der Mitte drei Buchstaben - SEK  für 
Sekunden. Kann man die Sekunden anzeigen so ändern das das nur über eine 
LED geht.
Bei einer anderen Uhr Version (nur mit esp8266) konnte ich das mit einer 
einfachen Abfrage realisieren
Sekunde = gerade dann LED an
Sekunde = ungerade dann aus

dann zwei neue Felder erstellen für Am, PM

und Vormittag - Nachmittag abfragen und anzeigen.

Ist unter Arduino Enviroment nicht ganz so schwierig.

Ich habe mir das Original mal unter embitz angeschaut , stehe aber noch 
etwas auf dem Schlauch.

Für einen Tip , wo  man den Quell Code ändern muss wäre ich sehr 
dankbar.

[Frank M. (ukw) (Moderator)]

Version 2.6.4 ist online mit folgenden Änderungen:

   - Verlängerung der Pausen für WS2812 auf 300us.
   - Verschäfte Plausibilitätsprüfungen für EEPROM-Inhalte, ggfls. RESET
     auf Standardwerte.

[Simon K. (heinzschulze)]

2 Daumen nach oben. Die 2.6.4 läuft und die Uhrzeit wird immer korrekt 
angezeigt.

Danke für die schnelle Abhilfe
Simon

[Andreas I. (andy5macht)]

Hier auf keine Auffälligkeiten mehr. Uhr läuft perfekt!
Vielen Dank!

[Hagen S. (Gast)]

Hallo an die Experten!

Ich habe mir offensichtlich beim ersten OTA-Update-Versuch den STM 
"abgeschossen" - zumindest läuft nix mehr (obwohl es doch bis eben so 
schön funktioniert hat... ;-(  )

Ich nutze ein Nucleo 411 mit dem V3 Shield. Alles hat funktioniert - 
also habe ich zum endgültigen Zusammenbau den ST-Link abgetrennt. Jetzt 
- nach dem fehlgeschlagenen Update - würde ich gern neu flashen...

Also: RX/TX Connector mit den PINs am Shield verbunden und noch Masse 
vom CN4 des ST-Link zum Shield. Danach dachte ich, ich könnte neu 
flashen - bekomme aber keinen Connect in der Software (USB-Fehler).

Danach gelesen und am Nucleo die Lötbrücken 62/63 gesetzt, die drei 
Drähte neu verbunden - kein Erfolg.

Wie muss ich das denn nun "richtig" anstellen?

[Horst B. (Gast)]

Hallo Hagen!

Hast Du wirklich den ST-Link so angeschlossen?
https://www.mikrocontroller.net/articles/Datei:STLink-to-Nucleo.png

[Christian S. (duffbeer2000)]

Ich habe jetzt meine erste Uhr in der neuen Bauweise fertiggestellt, es 
handelt sich um eine WC12 mit STM32F411RE Miniboard, dem Shield v3 und 
den LEDs aus der Sammelbestellung.
Zusätzlich verbaut habe ich folgendes: TSOP, LDR, DS1820 und die 
Spannungsabschaltung
Flashen hat alles wunderbar funktioniert.

Nun zu meinem Problem : Der BS170 der Spannungsabschaltung wird richtig 
heiß, da kann man kaum mit dem Finger ran. Jemand ne Idee was das sein 
könnte?

[Hagen S. (Gast)]

Horst B. schrieb:
>
> Hast Du wirklich den ST-Link so angeschlossen?
> https://www.mikrocontroller.net/articles/Datei:STLink-to-Nucleo.png

Auf dem Shield sind doch nur Anschlüsse für RX/TX und GND bzw. 5V 
vorhanden... Müssen die restlichen Leitungen ebenfalls angeschlossen 
werden? Dann direkt am Nucleo - weil auf dem Shield nicht vorhanden?

Viele Fragen...

[Christian S. (duffbeer2000)]

Nachtrag zu meiner Frage: Die 4 Minuten LEDs leuchten mit voller 
Leuchtstärke, alle anderen nur äußerst schwach.

[Andreas I. (andy5macht)]

hört sich für mich nach einem Kurzschluss an der Anzeige an.
Hast du mit den Lötstellen an/bei der Aluplatte gut aufgepasst?

[Ph L. (filo)]

Hallo zusammen,
ich habe heute meine erste Wordclock soweit fertiggestellt, dass 
eigentlich alles funktionieren müsste (ist lediglich noch nicht im 
Gehäuse verbaut).
Leider musste ich feststellen, dass zwar LEDs angehen, einige Worte 
jedoch um ein paar Zeichen verschoben sind. (siehe Anhang)
Außerdem ist auch die Zeit "eingefroren" und bleibt dauerhaft gleich.
Wenn ich die Uhr vom Strom nehme und neu anstecke, zeigt sie wieder eine 
andere Zeit (auch hier wieder verschobene Worte) und auch dann bleibt 
die neue Zeit weiterhin dauerhaft angezeigt.
Wäre klasse wenn mir jemand helfen könnte.

[Günter H. (gnter_h534)]

Christian S. schrieb:

> Der BS170 der Spannungsabschaltung wird richtig heiß, da kann man kaum
> mit dem Finger ran.

Das könnte eine "Lötbrücke" zwischen Pin 3 und Pin 4 des IRF9310 sein. 
Bittespeziell dort kontrollieren. Es ist fraglich, ob der BS170 
"überlebt" hat.

[Peter G. (ingrimsch)]

Ph L. schrieb:
> Leider musste ich feststellen, dass zwar LEDs angehen, einige Worte
> jedoch um ein paar Zeichen verschoben sind. (siehe Anhang)

Lässt sich leicht erklären: Du benutzt ein anderes Buchstabenlayout und 
keine der Frontplatten von diesem Projekt hier... ich meine ZWÖLFUNKUHR 
in der letzten Zeile ist das Layout der "echten" QLOCKTWO.

Vergleiche mal deine leuchtenden Buchstaben mit diesem Bild hier, dann 
dürfte es passen: 
https://www.mikrocontroller.net/wikifiles/4/42/Wordclock-frontplatte-v2.png

Gruß,
Peter

[Jan H. (Gast)]

Hagen S. schrieb:
> Auf dem Shield sind doch nur Anschlüsse für RX/TX und GND bzw. 5V
> vorhanden... Müssen die restlichen Leitungen ebenfalls angeschlossen
> werden? Dann direkt am Nucleo - weil auf dem Shield nicht vorhanden?
>
> Viele Fragen...

Hallo Hagen!

Das Nucleo sollte nach dieser anleitung umgebaut werden.

https://www.mikrocontroller.net/articles/WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo

Ist es so geschehen dann zieh das Shield ab vom Nucleo und verbinde den 
ST-Link so wie hier abgebildet ist.

https://www.mikrocontroller.net/articles/Datei:STLink-to-Nucleo.png

Dann Flashen, St-Link wieder entfernen, Shield wieder draufstecken und 
alles ist gut.
Vorausgesetzt der Rest stimmt. ;-)

[Hagen S. (Gast)]

Jan H. schrieb:
>
> Das Nucleo sollte nach dieser anleitung umgebaut werden.
>
> 
https://www.mikrocontroller.net/articles/WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo

Das ist passiert. Hat ja bis zum OTA-Updateversuch alles prima 
funktioniert.

> Ist es so geschehen dann zieh das Shield ab vom Nucleo und verbinde den
> ST-Link so wie hier abgebildet ist.
>
> https://www.mikrocontroller.net/articles/Datei:STLink-to-Nucleo.png

Also wirklich 8 (!) Verbindungen ziehen...?!? Ich habs mir etwas 
leichter vorgestellt...

Wozu sind denn dann RX/TX auf dem Shield herausgeführt?

[Hagen S. (Gast)]

Habe jetzt alle Verbindungen gezogen und den STM wiederbeleben können. 
SO kann man natürlich nichts debuggen - da er ja ausgebaut werden 
muss...

Habe das OTA-Update nochmal probiert und (auch mit der aktuellen 
Version) folgendes erhalten (bevor er dann wieder "stirbt"):

Updating STM32 firmware...
Downloading wc24h-stm32f411-ws2812-grb.hex... done.
Start Bootloader
Trying to enter bootloader mode...
Bootloader version: 3.1
Flash now unprotected
Trying to enter bootloader mode again...successful
Erasing flash (extended method)... successful!
Checking HEX file...
error: cannot open file
Flashing STM32...
error: cannot open file
End Bootloader
Done. Please Reset your STM32 now!

Irgendwelche Ideen?

[Andreas M. (andiator)]

Hallo Hagen,
welchen ESP hast Du, den 1er oder den 12er und welche FW-Version ist da 
drauf?
Könntest Du probeweise eine andere STM FW (12h) über OTA probieren?

@Frank M. (ukw)
hmm, wäre es vielleicht sinnvoller zuerst die HEX-Datei zu prüfen, bevor 
man den Erase macht? Dann würde wenigstens die Uhr noch gehen :)

MfG,
Andreas

[Christian S. (duffbeer2000)]

Günter H. schrieb:
>> Der BS170 der Spannungsabschaltung wird richtig heiß, da kann man kaum
>> mit dem Finger ran.
>
> Das könnte eine "Lötbrücke" zwischen Pin 3 und Pin 4 des IRF9310 sein.
> Bittespeziell dort kontrollieren. Es ist fraglich, ob der BS170
> "überlebt" hat.

Ich habe jetzt mal den IRF9310 und BS170 entfernt und jeweils einen 
neuen eingelötet, Lötbrücken kann ich keine entdecken. Allerdings wird 
der BS170 sofort wieder heiß.

Anbei mal Bilder vom Ursprungszustand. Noch ne Idee?

[Frank M. (ukw) (Moderator)]

Andreas M. schrieb:
> @Frank M. (ukw)
> hmm, wäre es vielleicht sinnvoller zuerst die HEX-Datei zu prüfen, bevor
> man den Erase macht? Dann würde wenigstens die Uhr noch gehen :)

Da hast Du vollkommen recht. Blöd gelaufen. Ich werde die Reihenfolge 
umdrehen.

Dieser Fehler:

  error: cannot open file

könnte evtl. von einem nicht oder falsch formatierten SPIFFS herrühren. 
Ich glaube, es ist sinnvoll, hier noch eine Schaltfläche "Format SPIFFS" 
einzubauen. Ich schreibs mal auf die TODO-Liste.

[Günter H. (gnter_h534)]

Christian S. schrieb:

> Ich habe jetzt mal den IRF9310 und BS170 entfernt und jeweils einen
> neuen eingelötet, Lötbrücken kann ich keine entdecken. Allerdings wird
> der BS170 sofort wieder heiß.
>
> Anbei mal Bilder vom Ursprungszustand. Noch ne Idee?

Ja. Den IRF9310 um 180° drehen. Im Bild ist er falsch herum eingelötet.

Beim aktuellen Aufbau sind Pin 3 und Pin 4 auf der Platine durch den 
IRF9310 kurzgeschlossen, deshalb wird der BS170 heiß.

Den Bestückungsplan aus dem Artikel kennzeichnet die doppelte Linie die 
Seite mit Pin 1. Ich habe diesen Plan um einen roten Punkt ergänzt - 
vielleicht wird damit die Ausrichtung des IRF9310 deutlicher.

Viel Erfolg
Günter

[Andreas M. (andiator)]

Frank M. schrieb:
> könnte evtl. von einem nicht oder falsch formatierten SPIFFS herrühren.

Könnte sein, schwer zu sagen. Ein Knopf "Format" würde nicht schaden, es 
sei denn wir kommen auf die Idee andere Daten da zu speichern ;)
Bei der Gelegenheit könnte man auch das "EEPROM Formatieren" einbauen?

MfG,
Andreas

[Hagen S. (Gast)]

Andreas M. schrieb:
> Hallo Hagen,
> welchen ESP hast Du, den 1er oder den 12er und welche FW-Version ist da
> drauf?

Es ist der 12er und der hat (wird auch so angezeigt) die 2.6.4 drauf. 
Dort scheint OTA zu funktionieren - zumindest ist nach dem Druck auf den 
Button wieder 'aufgewacht' :-)

Gruß...

...Hagen

[Hagen S. (Gast)]

Frank M. schrieb:
>
> Dieser Fehler:
>
>   error: cannot open file
>
> könnte evtl. von einem nicht oder falsch formatierten SPIFFS herrühren.
> Ich glaube, es ist sinnvoll, hier noch eine Schaltfläche "Format SPIFFS"
> einzubauen. Ich schreibs mal auf die TODO-Liste.

Was genau ist denn "Format SPIFFS"? In der Anleitung steht nichts von 
einem entsprechenden Schritt... Hab ich was übersehen oder hätte ich 
noch was tun müssen?

[Christian S. (duffbeer2000)]

> Ja. Den IRF9310 um 180° drehen. Im Bild ist er falsch herum eingelötet.
>
> Den Bestückungsplan aus dem Artikel kennzeichnet die doppelte Linie die
> Seite mit Pin 1. Ich habe diesen Plan um einen roten Punkt ergänzt -
> vielleicht wird damit die Ausrichtung des IRF9310 deutlicher.
>
> Viel Erfolg
> Günter

Also so langsam aber sicher macht mich die Uhr fertig ;) Ich habe den 
IRF gedreht und den BS nochmal gegen einen neuen getauscht. Danach war 
das Problem mit dem heißen BS erledigt. Das einzige Problem das 
weiterhin bestand war das die LED alle bis auf die Minuten-LED zu 
schwach geleuchtet haben. Nachdem ich die Uhr jetzt eine Stunde ohne 
Strom liegen lassen habe war das Problem beim einstecken zuerst behoben. 
Dann habe ich sie wieder ausgesteckt und das Problem war wieder da. Das 
Webinterface sieht auch sehr komisch aus, Beispiele in den Bildern. Ich 
kann die Uhr nicht stellen, auch wenn ich die Zeit online abrufe ändert 
sich nichts. Die Dropdown Menüs sind alle leer. Inzwischen bin ich etwas 
ratlos.