Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] ReInit after "TX SPI Timeout" #2438

Open
robsy opened this issue Nov 30, 2024 · 3 comments
Open

[Request] ReInit after "TX SPI Timeout" #2438

robsy opened this issue Nov 30, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@robsy
Copy link

robsy commented Nov 30, 2024

Is your feature request related to a problem? Please describe.

Sometimes my OpenDTU (CMT2300a) gets an infinitive "TX SPI Timeout", result is that there is no longer communication between OpenDTU and the inverter. So after every request to the inverter the message "TXI SPI Timeout" comes, and there is no automatic way out. I found a very simple way to get the communication working again:
Increase or Decrease the TX power for 1 (eg. if set "normally" to 15: change to 14 or 16). Immediately afterwards the communication restart without any problems. Setting the TX power back to original value has no negative effect.

Describe the solution you'd like

Just an idea:

  • create an option like "step TX power to reinit SPI"
  • count directly consecutive SPI TX Timeout failures (reset counter if an "normal" communication happens)
  • if counter is above a e.g. 5 (or any other value) change the TX power by 1
  • if SPI communication is "reestablished" change back TX power to original value

Describe alternatives you've considered

My first thought was that the power supply is not stable, but after putting some High-C MLCC and Low-Impedance Elcos to 5V and 3,3V line there is no improvement (also not by changing USB cable and USB supply). Monitoring 5V and 3,3V by an high-res Oscilloscope showed not abnormalities.

Additional context

Because of my limited experience of C++ (my daily-business are 8 bit controller with hardware-related programming C and assembler), I'm not sure if I could program my idea correctly. I will try and (maybe) come back with a pull request (or only a raw-patch to discuss).

@robsy robsy added the enhancement New feature or request label Nov 30, 2024
@schlimmchen
Copy link
Contributor

You stabilized the power rails, which is good, but how does the rest of your setup look like? This sure does sound like a hardware issue, like loose cabling, or high capacitance on at least one SPI line, or serial resistance.

BTW: The thing that does the trick is probably not the increase or decrease of the TX power, but restarting the SPI "driver" when applying the new TX power setting. That's a guess, I have not looked at the code, but I am confident that there is some kind of re-initialization going on.

@stefan123t
Copy link

stefan123t commented Dec 5, 2024

@schlimmchen yes increasing / decreasing the Transmit power for the RF radio chip may require the code to re-initialize the radio module.

I am also unsure whether this works just by resetting the radio stack on the software side or it may also reinitialize the whole communication including the Channel Change Command to each and every inverter in the settings / configuration.

I think that @robsy may have found a nice hack / workaround to one of the most dreaded issues upstream. E.g. this #2278 but also many other issues upstream come to my mind.

@tbnobody and @LennartF22 could you look at this too ?

@khschmidt
Copy link

khschmidt commented Dec 12, 2024

Hallo Stefan,

das hat mit dem von mir beschriebenen Verbindungsabbruch beim HMS 1600-4T wohl nichts zu tun.
Bei mir kommt auch kein SPI Timeout Fehler, => unbedingt einen Stützelko von 100uF auf die 3,3V Versorgung setzen, damit beim Sendepuls die Spannung nicht allzu sehr einbricht.

Das war natürlich das erste was ich versucht habe, Power rauf und speichern, auch Neustart und gänzlich von der Spannungsversorgung nehmen und neu starten hat nichts gebracht. Ich habe auch eine 2. DTU aufgebaut und es mit der versucht, alles erfolglos. Nur der sofortige Frequenzwechsel auf das Nachbarband hat bei mir zum Erfolg der sofortigen Verbindungsaufnahme geführt, siehe #2278 (comment)

Aber ich werde das beim nächsten Verbindungsabbruch nochmals testen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants