[Request] Add Support for MCP2515 CAN moduls with 16Mhz Oscillator frequency

[ele-dev]

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

In the AC PSU section of the wiki it says, that with the SBC01 CAN Modul from JoyIt one could avoid the pain of modifying the cheaper alternative MCP2515 board from AZ-delivery. The Problem: It seems like there are two variants of the JoyiT Modul available for online purchase. One variant has a 16Mhz Oscillator frequency and does not work with open dtu! (I know it because I own this variant and tested it) The other variant, which looks completly the same by the way, uses 8MHz like the AZ delivery board too and is therefore compatible.

Describe the solution you'd like

The best solution would be to add support for the 16MHz variant of the JoyIt modul because I know from forum conversations that a few people (including myself) already purchased the wrong variant without knowing anything about these two different variants. I'm not an expert but I don't think adding support would be too much work.

Describe alternatives you've considered

If adding support for 16MHz oscillator modules is not an option at moment I would strongly suggest to fix the wiki page accordingly. Add a bold printed warning and mention the existence of these two variants and that only the 8MHz variant works! This way we could at least safe people in the future from having this problem of bying the wrong hardware and getting confused or upset about it for no reason.

Additional context

No response

[ele-dev]

I'm excited to hear the opinion of involved developers on this topic. Especially how much effort it would take to add support for the 16MHz variant.

[Manos1966]

Warning in Wiki added.

[Manos1966]

As completely unaware of low Level programming, may I ask, why does it make a difference whether it clocks at 16 instead of 8MHz?.

[Manos1966]

I just saw that the 8MHz oscillator cost 12ct per piece. If I receive the wrong board (with 16MHz), can I just swap the crystal? It looks very easy (even for me...)

[schlimmchen]

why does it make a difference whether it clocks at 16 instead of 8MHz?

Baud rate.

That chip only knows relative timing, i.e., its input clock. If it doubles while all else is the same, then it speaks at double the speed.

The prescaler needs to be doubled for the 16MHz model. Probably the CAN driver can already be configured (be told what the quarz frequency is) such that the correct prescaler is set. Probably 8MHz is hardcoded somewhere in OpenDTU-OnBattery.

Users would have to select which frequency is in use, and OpenDTU-OnBattery needs to tell the driver.

This is all based on assumptions after skimming the MCP2515 datasheet. However, my gut tells me I hit the nail on the head.

[schlimmchen]

can I just swap the crystal?

Yes.

It looks very easy (even for me...)

It is a little nasty as you probably will not be able to heat both pins at the same time to extract the old one. And the crystal does not bend. Here is my technique: Heat one pin of the crystal and lift the crystal a little on that side. Take away the heat and let the solder solidify. Repeat with the other side. Keep doing this until the crystal is out. Clean the holes with solder wick (Entlötlitze). Use flux if you have any. Clean the board with alcohol. Solder the new crystal. Orientation does not matter.

[Manos1966]

Thanks a lot @schlimmchen for the invaluable feedback! I added your explanations on the 8/16MHz difference in the Wiki (I am sure this will not be the last time we will experience such issues). Your explanations on unsoldering strengthened my Christian beliefs... I started praying that my boards will come with 8MHz already on them 🙈🙈😂😂😂

[Manos1966]

UPDATE I knew I am not a firm Believer... :D My Joy-it SBC-CAN01 boards from CONRAD arrived and they are 16MHz 👎 So it seems, there are no longer 8MHz boards available. I am waiting for the 8MHz oscillators now in order to test my re-resoldering skills...

Is this issue (8MHz/16MHz) something that can (and is it worthwhile the effort) be fixed inside OpenDTU-onBattery? (just asking before I start re-soldering).

[indie89]

Without exact insight in the onBattery Code and the function and meaning of the oscillator I'd say that we should try to solve that on a software side, otherwise almost everybode had to solder something on the CAN communication board (either for the 5V mod or for installing the 8MHz Oscillator)

I only see one case in which a software fix could not help: if the Huawei could only communicate with a Board including a 8MHz oscillator. Can somebody add some info about that? Thanks!

[ele-dev]

@indie89 I totally agree with you that a software patch would really be worth it since there is no way without soldering on these breakout boards to make it work at the moment, which is a clear disadvantage. And I can confirm that the Huawei PSU is not affected by the oscillator frequency of the module at all. I have the unmodified 16MHz JoyIt Module setup with a raspberry pi 4B and the communication to the PSU works very well. This setup runs for over a month now in my basement so no worries about that.

[CaCu15]

Maybe I'm wrong, but my first impression is, that this shouldn't seem to be a big deal:

The frequency is only used during initialization of the CAN bus. For the HUAWEI this initialization happens in

HuaweiCanCommClass::init (file Huawei_can.cpp)

    if (!_CAN->begin(MCP_STDEXT, CAN_125KBPS, MCP_8MHZ) == CAN_OK) {
        return false;
    }

This uses a #define "MCP_8MHZ" taken from the standard ARDUINO lib for the MCP CAN controller (see MCP_CAN. The constant MCP_8MHZ is defined in https://github.com/coryjfowler/MCP_CAN_lib/blob/master/mcp_can_dfs.h#L445 and I assume we need to replace this with "MCP_16MHZ" to support 16 MHz oszillators.

I propose to use a configuration item to select between 8 MHz and 16 MHz (instead of hard coding a single frequency)

[schlimmchen]

@CaCu15 Thanks for taking the time to find this. I was sure there was such a line of code. You are right, that should be config item. Can you implement it?

[CaCu15]

@schlimmchen : I'm afraid that it is not a good idea. The last time I wrote C source code is VERY long ago (>20 years). And that was plain C, not C++.

I can read & understand a lot of code, but coding my self is limited to a little bit of Node Red / Javascript and some scripting (bash). I could try, but that will take A LOT of time, as I have to make myself familiar with a IDE.

[ele-dev]

I am fluent in C++ but I don't have any experience with Vue.js or React.js and I haven't worked on C++ projects for ESP32 paltform either.

[schlimmchen]

No worries. Still, I think that we should always encourage people to try it themselves. We've had great success with that already. A little bit of help and the ball was rolling and there were successul merge requests.

Maybe I can do it next friday. In the meantime I could build a firmware with 16MHz hardcoded. Who could try it and confirm that it indeed works with a 16MHz quarz? @Manos1966 maybe?

[Manos1966]

Hallo @schlimmchen Ja, wenn du mir eine Hardcoded ESP32 Version schickst (ich kann nicht kompilieren) kann ich testen 👍 gute Gelegenheit meine Huawei endlich aus dem Schrank raus zu holen ;-)

[schlimmchen]

@Manos1966 Siehe https://github.com/schlimmchen/OpenDTU-OnBattery/releases/tag/2023.10.14-16mhz-quarz Vielen Dank fürs Ausprobieren.

[Manos1966]

Hallo @schlimmchen

Es hat nicht geklappt...

[Manos1966]

.... am Anfang 😜😜😜😜😜😜

Ich musste erst den Jumper schliessen (vielleicht weil meine CANbus Kabel zu dick mit 0,75mm2 sind).

Es funktioniert einwadfrei ! 🥇

Ich habe keine Befehle eingegeben, ich kenne mich nicht so gut aus. Ich habe das Standard Pinout benutzt von damals:

Ich muss noch das Relais (Pin33) addieren, so sieht es insgesamt aus:

[schlimmchen]

Sieht sehr gut aus. Sehr gescheit, dass du so ein Breakout-Board mit Schraubklemmen verwendest. 💪

Was macht der Jumper denn? Fügt der einen Abschlusswiderstand (120 Ohm?) ein?

Hast du den Gegentest gemacht? Wenn du zurück zur zuletzt veröffentlichten Firmware gehst, funktioniert es nicht mehr, obwohl sonst nichts verändert wurde?

[Manos1966]

Jumper denn? Fügt der einen Abschlusswiderstand (120 Ohm?) ein? Korrekt! Gegentest gemacht? Wenn du zurück zur zuletzt veröffentlichten Firmware gehst, funktioniert es nicht mehr. Korrekt!

A huge THANKS to @ele-dev (for initiating the discussion), @CaCu15 @indie89 for the contribution, and of course @schlimmchen for the quick fix!

Although I begin to think it is a "Verschwörung" so that I never learn how to solder things.... 😜

[Manos1966]

@ele-dev schreibst du ein Update im Akku-Doktor Forum (wo alles angefangen hat), oder soll ich?

[ele-dev]

@ele-dev schreibst du ein Update im Akku-Doktor Forum (wo alles angefangen hat), oder soll ich?

Darfst du gerne machen. Ist der Fix den du getestet hast denn schon gemerged bzw. in dem neusten Stable Release enthalten? Wenn nicht würde ich mit der frohen Botschaft im Forum vllt noch abwarten bis das released ist.

[schlimmchen]

Die Anpassung ist nur testweise mal gebaut worden. Es fehlt insb. das User-Interface zur Auswahl der Frequenz.

[Manos1966]

Kein Stress.

ich wollte nur ein Update schreiben. Wie in der Wiki, "Problem identifiziert, eine zukünftige Version wird mit beiden 8MHz/16MHz Version arbeiten können".

Damit die Leute kein Stress haben, 8MHz Platinen zu suchen...

[Manos1966]

Ich stelle eine (eigentlich zwei) Fragen hier, da ich das Wiring Diagram aufgrund der Joy-it Platine aktualisiert habe:

Frage 1: Relais! Falls ich ein 5V Relais um die R4850 ein- und auszuschalten benutze, das Power Signal (PIN 33) muss durch einen LevelShifter o. ADUM angeschlossen, Korrekt? (bzw, ist es ein Muss, eine Empfehlung wie beim Victron, oder brauche es gar nicht)?

Frage 2: Das Bild unten zeigt die meisten Optionen die existieren (Victron SmartShunt fehlt, nutzt aber das gleiche PIN-OUT wie Pylontech). Gezeichnet sind, so fern ich gefunden habe, die "Standard PINs" die die Programmierer geplant haben. Leider existiert eine Überschneidung: das LCD Display (SSD1306 o. ähnliches)

Die ursprüngliche Pläne die ich gefunden habe (und immer noch finde), zeigen: display": { "type": 2, "data": 21, "clk": 22

Dies ueberschneidet mit den "Standard" Victron Einstellungen: "victron": { "rx": 22, "tx": 21 urspruenlich, jetzt "victron": { "rx": 22, "tx": -1

Also, ungeachtet der Tatsache, dass kaum ein technisch Begabter Mensch (der auf OpenDTUonBattery so viele Systeme installiert hat), einen LCD Bildschirm braucht um seine OpenDTU zu monitoren: Gebe es Vorschläge, wo wir die Pins des LCD Bildschirms zeichnen sollten?

[CaCu15]

Hi @Manos1966

Zu Frage 1:

Frage 1: Relais! Falls ich ein 5V Relais um die R4850 ein- und auszuschalten benutze, das Power Signal (PIN 33) muss durch einen LevelShifter o. ADUM angeschlossen, Korrekt? (bzw, ist es ein Muss, eine Empfehlung wie beim Victron, oder brauche es gar nicht)?

Korrekt. Man kann das auch OHNE einen Level-Shifter versuchen, mit etwas Glück funktioniert es auch ohne. Im Falle eines Relais kann man das ja sehr einfach ausprobieren, weil es ja nur den Zustand ein/aus gibt. Bei einem komplexeren Protokoll wir dem Victron kann man das nicht so einfach ausprobieren...

Zu Frage 2: Das ist m.E. nicht so einfach. Da ist es nicht einfach mit einem anderen PIN getan. Mehrere der vom OpenDTU verwendeten Adapter (der MCP2515, der LRF24L01 sowie auch der CMT2300A und auch Displays) verwenden für den Anschluss einen "SPI Bus". Ein ESP32 hat m.W. nur 2 frei verfügbare SPI Busse. Der SPI unterstützt zwar prinzipiell mehrere SPI Clients an einem Bus, das muss dann aber auch in der SW entsprechend codiert sein. Aktuell sind in OpenDTU aber einige Module "hart" und exklusiv auf einen der SPI Busse codiert:

• Der MCP2515 ist auf den SPI 2 festgelegt, siehe https://github.com/helgeerbe/OpenDTU-OnBattery/blob/development/docs/hardware_flash.md#mcp2515-can-bus-module

Currently the SPI bus host is hardcoded to number 2. This may change in future. Please note: Using the Huawei AC charger in combination with the CMT2300A radio board is not supported at the moment.

• Auch der CMT2300A ist auf einen SPI fixiert, siehe https://github.com/helgeerbe/OpenDTU-OnBattery/blob/development/docs/hardware_flash.md#cmt2300a-radio-board--see-inverter-table-above-for-supported-inverters

The CMT2300A uses 3-Wire half duplex SPI communication. Due to this fact it currently requires a separate SPI bus. If you want to run the CMT2300A module on the same ESP32 as a NRF24L01+ module or a PCD8544 display make sure you get a ESP which supports 2 SPI busses. Currently the SPI bus host is hardcoded to number 2. This may change in future.

Manche Kombinationen von Controllern/Displays werden also im Moment einfach nicht unterstützt. Ich sehe das aber eigentlich wie Du: auf ein Display kann man gut verzichten, man kann die ganzen Infos viel besser z.B. in einer Smart Home Plattform (Home Assistant, ioBroker etc) anzeigen, als extra ein Display anzuschließen. Das ist wohl eher etwas für die, die OpenDTU (ohne 'on Battery') einfach als günstigen Ersatz für die offielle Hoymiles DTU einsetzen und nicht noch diverse andere Module da dran haben.

[Manos1966]

Currently the SPI bus host is hardcoded to number 2. This may change in future. Please note: Using the Huawei AC charger in combination with the CMT2300A radio board is not supported at the moment.

Das ist auch Gold-Wert! Ich hatte es bis jetzt nicht bemerkt 👍

[schlimmchen]

@Manos1966 Kannst du nochmal prüfen? https://github.com/schlimmchen/OpenDTU-OnBattery/releases/tag/2023.10.15-huawei-can-frequency-configurable Das ist ein Build des PR #500. Den würde ich auf "read for review" stellen, sobald das nochmal jemand geprüft hat, dass es so funktioniert. Am liebsten auch jemand, der einen 8MHz Quarz in Verwendung hat. Wen könnten wir da anhauen?

[Manos1966]

Hi @schlimmchen

Sorry, die neue Version funktioniert nicht :-(

Ich habe die erste Test Version wieder geladen und sie funktioniert.

Daher liegt es an die Version von heute.

Bild anbei (oben heutige Version, unten die Version von Freitag). Ich habe auch nirgendwo eine Einstellung um zwischen 8MHz und 16MHz zu schalten. Passiert es automatisch?

[schlimmchen]

Jo, da ist wohl die alte WebApp in deinen Browser ge-cache't... Lästig ist das.

Firmware aktualisieren, Webinterface laden, zu den AC Charger Einstellungen wechseln, Strg+F5 drücken, dann 16 MHz im Drop-Down wählen und speichern.

[Manos1966]

Oh man! wie ein blutiger Anfänger! 🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️[facepalm]

Jetzt konnte ich die Einstellungen sehen. 16MHz eingestellt, es funktioniert 🥇 vielen Dank @schlimmchen

Ich habe bis jetzt nur die Anzeige im Live View beobachtet. Ich habe nicht versucht Befehle an die R4850 zu geben oder sie mit dem Dynamischen Power Limiter steuern zu lassen (ich kenne mich nicht aus). Ich hoffe es reicht aus.

Jetzt brauchen wir nur einen Freiwilligen mit 8MHz Platine...

[indie89]

Jetzt brauchen wir nur einen Freiwilligen mit 8MHz Platine...

Geht auch eine Platine mit 5V Mod? Die müsste doch auch 8mhz sein, oder? Falls ja, könnte ich es heute Abend testen...

[schlimmchen]

Ich habe bis jetzt nur die Anzeige im Live View beobachtet. Ich hoffe es reicht aus.

Danke für deine prompte Unterstützung! Das reicht so. Hier gibts nur "funktioniert" oder "funktioniert nicht".

Geht auch eine Platine mit 5V Mod?

Ich weiß nicht, was damit gemeint ist. Aber wenn du bisher den Huawei Charger einsetzt und schon ohne meine Vorab-Firmware erfolgreich mit OpenDTU-OnBattery verbunden hast, dann muss dein CAN-Controller einer mit 8MHz Quarz sein.

[Manos1966]

Erschreckend, wie viele Optionen heute verfügbar sind... Ich habe alles(?) rein im Bild gepackt. Da ich nicht besseres wusste, habe die Infos in die Wiki Profiles platziert. Zur Zeit addiere ich Informationen aus Diskussionen "willkürlich" in die Wiki rein. Hauptsache, die Information verschwindet nicht im Forum (wenn die Diskussionen "geschlossen" werden).
Ich hoffe, eines Tages wird jemand sich um die Struktur der Wiki kümmern und eine bessere Arbeit machen als ich...

Deine Erklärungen CaCu15, habe unter addiert https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Device-Profiles#other-information

[Manos1966]

Hat jemand eine Idee warum die Joy-it Platine 5V auf beide Eingaenge braucht wenn sie mit Arduino verbunden wird, aber 3.3V and 5V beim Raspberry?

[schlimmchen]

Ich hab nicht genauer hingeschaut, aber ich behaupte, dass VCC1 die Versorgungsspannung des Boards und des CAN Controllers ist (immer 5V). Und VCC (ohne 1) ist die wohl Input/Output-Spannung des Boards. Da der RaspberryPi ein 3V3-basierter SoC ist, verträgt der nur 3V3 auf seinen Pins (MISO, MOSI, etc.). Arduino-Boards treiben und vertragen soweit ich weiß allesamt 5V auf ihren Pins.

Für die Verwendung mit einen ESP32 wäre es daher stimmig, die RaspberryPi-Konfiguration zu verwenden.

[CaCu15]

Genau, @schlimmchen , das ist auch mein Verständnis. Der Arduino arbeitet mit Logic-Leveln von 5V. Daher könnte man da auch einfach ein "einfaches" MCP2515 Board mit nur einer Spannungsversorgung verwenden anstelle eines Joy-IT Boards.

Der Sinn der für den ESP und/oder RaspPI vorgeschlagenen Modifikation des MCP2515 Boards ist ja gerade, die Spannungsversorgung zu trennen, die bei dem JoyIT Board schon "ab Werk" getrennt ist.

[Manos1966]

Der Sinn der für den ESP und/oder RaspPI vorgeschlagenen Modifikation des MCP2515 Boards ist ja gerade, die Spannungsversorgung zu trennen, die bei dem JoyIT Board schon "ab Werk" getrennt ist.

Aha! 👍

Hmm OK,

• dann habe ich Gluck gehabt, den Test erfolgreich abgeschlossen zu haben (es haette auch schief gehen koennen...)
• Gut, dass ich gefragt habe
• Sieht es den so richtig aus? (VCC1:5V, VCC:3.3V)

[indie89]

Geht auch eine Platine mit 5V Mod?

Ich weiß nicht, was damit gemeint ist. Aber wenn du bisher den Huawei Charger einsetzt und schon ohne meine Vorab-Firmware erfolgreich mit OpenDTU-OnBattery verbunden hast, dann muss dein CAN-Controller einer mit 8MHz Quarz sein.

8MHz: Funktioniert!

[schlimmchen]

8MHz: Funktioniert!

Sehr schön, danke für die Rückmeldung!

[Manos1966]

Erledigt!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.