Hast du die Möglichkeit, vor den ATMega noch direkt einen größeren Elko (100µF) und vielleicht einen 100n zum Säubern und Glätten der Spannung zu hängen?
Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle
Moderator: Co-Administratoren
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
-
- Beiträge: 5449
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 739 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Ich werde das Gerät nochmal direkt an ein Labornetzteil hängen (12V). Kann sein, dass das erst nächste Woche wird.
Die 3,3V werden mit einem Linearregler LM1117-3,3 aus den 12V erzeugt, die 3,3V am ATmega ist mehrfach mit 100n + 1µF + 100µF abgeblockt, der CC1101 mit einer 3-fach Kombination aus 22pF + 10nF + 10µF (alles Keramik).
Die 3,3V werden mit einem Linearregler LM1117-3,3 aus den 12V erzeugt, die 3,3V am ATmega ist mehrfach mit 100n + 1µF + 100µF abgeblockt, der CC1101 mit einer 3-fach Kombination aus 22pF + 10nF + 10µF (alles Keramik).
-
- Beiträge: 5449
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 739 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Noch eine Frage: Aktuell sehe ich im Monitoring jetzt sehr häufig die Meldung "Packet too short: 6", wie es ausieht, bei HmIP-Messages, die oft länger als 29 bytes sind.
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
"too short" beobachte ich bei mir nicht, nur gelegentliche "Packet too big :30", und gelegentliche RXxx mit oder ohne fehlgeschlagener CRC-Pruefung.
-
- Beiträge: 5449
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 739 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Das Protokoll stammt von der Steckdose ID 01D802. Die ID 01D803 ist die zweite umgeflashte und im Test befindliche Steckdose.
Die Paketlänge habe ich auf 0x1D gesetzt.
Die Paketlänge habe ich auf 0x1D gesetzt.
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Habe ich ggue der Version auf Github nicht veraendert, steht also bei mir auf 0x1E.
-
- Beiträge: 5449
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 739 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Was mich hier stutzig macht:
Das Protokoll scheint absolut korrekt zu sein, im Abstand von 1 min wird das Gerät aus- und eingeschaltet. Es erkennt die Message anscheinend korrekt und scheint die Bestätigung auszugeben. Es erfolgen von seiten der CCU auch keine Sendewiederholungen, so als wäre die Kommunikation korrekt gewesen. Es gab auch keine Fehlermeldung Kommunikationsstörung.
Dennoch wird in der CCU keine Statusänderung erkannt.
Oder sitze ich hier nur einem Problem von CCU-Historian auf und jage hinter einem falschen Fehler her? Werde mal noch per Programm den Status zusätzlich überwachen.
Das Protokoll scheint absolut korrekt zu sein, im Abstand von 1 min wird das Gerät aus- und eingeschaltet. Es erkennt die Message anscheinend korrekt und scheint die Bestätigung auszugeben. Es erfolgen von seiten der CCU auch keine Sendewiederholungen, so als wäre die Kommunikation korrekt gewesen. Es gab auch keine Fehlermeldung Kommunikationsstörung.
Dennoch wird in der CCU keine Statusänderung erkannt.
Oder sitze ich hier nur einem Problem von CCU-Historian auf und jage hinter einem falschen Fehler her? Werde mal noch per Programm den Status zusätzlich überwachen.
Zuletzt geändert von Matsch am 17.03.2023, 13:12, insgesamt 1-mal geändert.
-
- Beiträge: 5449
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 739 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Bei mir stand noch 0x17 drin, habe nicht nochmal upgedated.
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Bei mir laeuft nur das Programm zum Ein- und Ausschalten, ich logge den Zustand nicht separat, sondern warte (bislang ohne Ergebnis) auf Kommunikationsfehler.
- stan23
- Beiträge: 2038
- Registriert: 13.12.2016, 21:14
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Altmühltal
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 336 Mal
- Kontaktdaten:
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Auf jede HmIP-Message kommt ein kurzes HmIP-ACK mit 6 Byte: es enthält nur die Sender- und Empfängeradresse.
Diese 6 Byte sind aus AskSinPP-Sicht zu kurz.
Du kannst einfach diese Zeile auskommentieren:
https://github.com/pa-pa/AskSinPP/blob/ ... age.h#L164
Viele Grüße
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)