Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 31.03.2023, 13:34

jp112sdl hat geschrieben:
30.03.2023, 13:36
So klein ist der nicht. Ich hab mir vor ein paar Wochen ein Rigol DS1104Z Plus + RPL1116 LogicProbe gegönnt.
ok, feines gerät. dann betrachte ich folgende beobachtung mal als problemchen.
bei D0 kommt es manchmal beim setzen auf low zu einer verzögerung. wenn sie auftaucht, ist sie scheinbar konstant.
rhs nachbau_some_delays.jpg
das werd ich am Wochenende mal prüfen.
dann könntest du vielleicht auch mal versuchen, ob du ein weiteres problem nachstellen kannst.

manchmal bleibt der rhs "hängen", wenn die zustandsänderungen der 3 schalter zu schnell aufeinander folgen:
a) eine änderung der 3 taster am MSP430 wird dann nicht mehr registriert/gemeldet.
b) die led bleibt bei zustandsänderung dann dunkel oder reagiert anders.
c) der configtaster erzeugt aber weiterhin eine anlernmessage und orangenes blinken.
d) vermutlich bleibt wegen c) nur der MSP430 hängen oder wacht nicht mehr auf.

im normalen einsatz passiert es eigentlich nur, wenn man den fenstergriff in einem zug um 2 positionen ändert.
am besten reproduzieren kann ich es mit dem batteriedeckelkontakt, indem ich den geöffneten deckel schnell schliesse und wieder öffne. ein reboot (batterie raus/rein) löst natürlich das problem.

Dann müsste das _delay_us wohl auch nach jedem PORTC &= ~_BV(PC3); kommen.
oder einfach komplett aus dem if/else komplex entfernen und grundsätzlich für die ersten 25 durchläufe als erstes nach dem "//WAIT WHILE H" ausführen.

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 01.04.2023, 15:49

hallo jerome,

ich habe gerade mal versucht die neue funktion poweroff() zu verstehen.
soweit ich verstehe, schaltest du mit "DDRC=B00001001" den anschluss PC3 vom avr auf "ausgang", um 17 bit daten an den msp zu senden. am ende der funktion wird PC3 mit "DDRC=B00000001" wieder auf "eingang" zurückgeschaltet. dies passiert doch aber viel zu spät, so dass wir 25 bit auf die leitung schreiben. das umschalten müsste doch nach 17 bit passieren.
der spike muss doch nicht übertragen werden, sondern entsteht "automatisch" durch das beidseitige umschalten der leitung an PC3.

mich wundert nun aber, dass dein logic analyzer das signal D2 ab bit 18 trotzdem sauber darstellt. hier müssten doch nun eigentlich avr und msp beide auf die leitung schreiben.

oder verstehe ich hier etwas völlig falsch?

gruss frank

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 01.04.2023, 15:55

frank! hat geschrieben:
01.04.2023, 15:49
oder verstehe ich hier etwas völlig falsch?
Es war nur eine Vermutung von mir, dass 17 Bit geschrieben und 8 Bit gelesen werden.

Beim Schreiben von 17Bit auf den RHS und Umschalten auf INPUT passiert während der verbleibenden 8 Takte nur leider nix.
Da kam nix vom MSP zurück.
Deshalb ist die Sequenz zum RHS entweder eine andere als beim SCI... oder die schreiben tatsächlich 25Bit.

Ich bin noch nicht dazu gekommen, mich damit weiter zu beschäftigen.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 01.04.2023, 19:04

frank! hat geschrieben:
30.03.2023, 13:04
oder: was passiert dann bei konfiguriertem EVENT_DELAYTIME (0-7620)? wacht er dann bei statuswechsel erst auf, legt sich wieder hin, und wacht nach EVENT_DELAYTIME nochmal auf?
und bei MSG_FOR_POS_A,B,C kann man "NO_MSG" konfigurieren, sodass er dann gar nicht aufwachen müsste. oder wird nur die funkmessage verhindert?
Oh weh, es wird immer verwirrender.

Also das Einfache vorweg: Bei NO_MSG kommt trotzdem eine Kommunikation zwischen MSP und AVR zustande:
NO_MSG.png
Jetzt zu der EVENT_DELAYTIME. Interessant ist, dass man sie in der WebUI für jeden der 3 Kanäle separat konfigurieren kann. Es zieht aber immer nur der zuletzt gesetzte Wert für alle 3 Kanäle. Setze ich Kanal 1 auf 2 Sekunden und Kanal 2 auf 5 Sekunden, ist für alle 3 Kanäle 5 Sekunden konfiguriert.

Sende ich Konfigurationsdaten "EVENT_DELAYTIME" und "CYCLIC_INFO_MSG", dann sieht es so aus:
DS1Z_QuickPrint2.png
210ms D8 und D10 HIGH
DS1Z_QuickPrint3.png
danach 10 Bit Kommunikation.
Offenbar nur vom AVR zum MSP.

Dann sind 5 Sekunden Pause.
Anschließend das bekannte Telegramm
DS1Z_QuickPrint1.png
jedoch sieht es nach Hinten raus anders aus.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 01.04.2023, 19:10

Die Sendeverzögerung ist wohl gut durchschaubar.
Hab mal 1, 2 und 3 Sekunden nacheinander gesetzt.
DS1Z_QuickPrint5.png
DS1Z_QuickPrint6.png
DS1Z_QuickPrint7.png

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 02.04.2023, 16:22

Also die Meldeverzögerung lässt sich beim RHS analog zum SCI auf den MSP430 schreiben und das funktioniert auch. :idea:

Bei der zyklischen Meldung kommt nach wie vor keine Antwort vom MSP430 zurück.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 02.04.2023, 20:54

jp112sdl hat geschrieben:
02.04.2023, 16:22
Also die Meldeverzögerung lässt sich beim RHS analog zum SCI auf den MSP430 schreiben und das funktioniert auch. :idea:
cool.
hast du beim sci auch mal geschaut, ob beim einlegen der batterie, also beim booten, der msp mit der eingestellten delaytime initialisiert wird?
Bei der zyklischen Meldung kommt nach wie vor keine Antwort vom MSP430 zurück.
eventuell stimmt das timing noch nicht und das umschalten auf INPUT auf der datenleitung kommt etwas zu spät.
vielleicht macht der msp vor dem umschalten eine messung auf der datenleitung und bricht seine umschaltung ab, wenn noch ein High existiert.

kannst du den spike beim sci mal vergrössern und die zeit von der fallenden flanke am 18. puls auf D9 bis zum beginn des spike (fallende flanke) messen? oder beginnt der spike sogar vorher schon?
wann kommt der spike dann bei deinem rhs? früher oder später?
wie sieht der abbruch aus und mit welchem code arbeitest du?


die codierung der zeiteinstellung der zyklischen status meldung funktioniert wahrscheinlich so:
das 17. byte hat die niedrigste wertigkeit, also wird "00000010100111101" übertragen, dezimal 1341.
der msp hat einen festen faktor von 64, das ergibt 85824 sek.
somit fehlen 576 sek zu 86400 sek (24std). 576 sek entsprechen 9 min und 36 sek.

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 03.04.2023, 18:41

frank! hat geschrieben:
02.04.2023, 20:54
hast du beim sci auch mal geschaut, ob beim einlegen der batterie, also beim booten, der msp mit der eingestellten delaytime initialisiert wird?
Jap, wird.
frank! hat geschrieben:
02.04.2023, 20:54
kannst du den spike beim sci mal vergrössern
Hier mit 500µs Raster:
spike500us.png
und noch feiner mit 10µs Raster:
spike10us.png
frank! hat geschrieben:
02.04.2023, 20:54
wann kommt der spike dann bei deinem rhs? früher oder später?
So sieht es aus, wenn ich an der L-Flanke von D1 auf INPUT umschalte:
rhs200us.png
Der Pegel bleibt dann L.
Die Vermutung war/ist ja, dass dann halt innerhalb von 1-2µs (siehe Bild darüber) der Pegel wieder H wird, indem der MSP nun sendet und nicht mehr der AVR. Aber das passiert nicht.

Wenn ich irgendwann mal einen Heißluftlöter habe, dann würde ich sogar mal den 328P des SCI austauschen, um den MSP mal mit eigenem Code zu bespaßen. Oder ich müsste die Leitungen zwischen 328P und MSP auftrennen und an einen eigenen AVR hängen...
Ich möchte nur den originalen SCI nicht kaputt machen bzw. überschreiben.
frank! hat geschrieben:
02.04.2023, 20:54
wie sieht der abbruch aus und mit welchem code arbeitest du?
Das habe ich jetzt damit erzeugt:

Code: Alles auswählen

      DDRC=B00001010;
      for (uint8_t i=0; i < 26; i++) {
        PORTC |= _BV(PC1);                //SET OUT    H
        while (!(PINC & (1 << PC2)));     //WAIT WHILE L
        PORTC &= ~_BV(PC1);               //SET OUT    L
        while (PINC & (1 << PC2));        //WAIT WHILE H
             if (i == 6)  PORTC |=  _BV(PC3);
        else if (i == 7)  PORTC &= ~_BV(PC3); 
        else if (i == 8)  PORTC |=  _BV(PC3); 
        else if (i == 9)  PORTC &= ~_BV(PC3); 
        else if (i == 11) PORTC |=  _BV(PC3); 
        else if (i == 15) PORTC &= ~_BV(PC3); 
        else if (i == 16) PORTC |=  _BV(PC3);
        else if (i == 17) { PORTC &= ~_BV(PC3); DDRC=B00000010; _delay_us(700);}
        else if (i < 25) _delay_us(700);
      }
      
      DDRC=B00000010;
      
frank! hat geschrieben:
02.04.2023, 20:54
die codierung der zeiteinstellung der zyklischen status meldung funktioniert wahrscheinlich so:
das 17. byte hat die niedrigste wertigkeit, also wird "00000010100111101" übertragen, dezimal 1341.
der msp hat einen festen faktor von 64, das ergibt 85824 sek.
somit fehlen 576 sek zu 86400 sek (24std). 576 sek entsprechen 9 min und 36 sek.
Klingt plausibel.

Möglicherweise ist das auch erst beim SCI so umgesetzt worden und beim RHS war die Zeit noch fix und der zyklische Timer wird über ein komplett anderes Bit-Muster einfach nur aktiviert... :|

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 03.04.2023, 20:29

bingo!!!

Code: Alles auswählen

2023.04.03 20:15:48.845 0: HMLAN_Parse: hmlan1 R:E196BD8   stat:0000 t:383AB00E d:FF r:FFCB     m:0D A241 196BD8 1ACE1F 010564
2023.04.03 20:19:06.390 0: HMLAN_Parse: hmlan1 R:E196BD8   stat:0000 t:383DB53C d:FF r:FFCA     m:0E A210 196BD8 1ACE1F 0601640E35
2023.04.03 20:22:24.135 0: HMLAN_Parse: hmlan1 R:E196BD8   stat:0000 t:3840B9D9 d:FF r:FFC8     m:0F A210 196BD8 1ACE1F 0601640E3A
2023.04.03 20:25:42.037 0: HMLAN_Parse: hmlan1 R:E196BD8   stat:0000 t:3843BE76 d:FF r:FFCB     m:10 A210 196BD8 1ACE1F 0601640E35

Code: Alles auswählen

    void powerOff() { // wu=192s
      DDRC=B00001010;                     //SET OUTPUT   (Data)
      for (uint8_t i=0; i < 26; i++) {
        PORTC |= _BV(PC1);                //SET OUT    H (Aout)

        while (!(PINC & (1 << PC2)));     //WAIT WHILE L (Mout)
        PORTC &= ~_BV(PC1);               //SET OUT    L (Aout)
        if (i == 17) {
            _delay_us(100);
            PORTC &= ~_BV(PC3);           //SET OUT    L (Data)
            DDRC=B00000010;               //SET INPUT    (Data)
        }

        while (PINC & (1 << PC2));        //WAIT WHILE H (Mout)
        if (i == 15)  PORTC |=  _BV(PC3); //SET OUT    H (Data)
        if (i < 25) _delay_us(700);
      }
      DDRC=B00000010;                     //SET INPUT    (Data)
     
      hal.led.ledOff();
      hal.radio.setIdle();
      LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
    }

jp112sdl
Beiträge: 12083
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 03.04.2023, 21:21

frank! hat geschrieben:
03.04.2023, 20:29
bingo!!!
Mit deinem Code sieht es so aus:
DS1Z_QuickPrint8.png
Und da du ja bewiesen hast, dass damit zyklisch eine Nachricht gesendet wird, scheint der MSP beim RHS tatsächlich nix zu quittieren, wie es beim SCI der Fall ist.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“