Hallo, ich bin gerade am überlegen, ob/wie ich mein Korad 3005D mit einer Fernsteuerung ausstatten könnte (z.B. [ESP-Power](https://github.com/JackNewman12/ESP-Power)). Das Angebot der D Variante von Reichelt war damals zu verlockend... Ich habe dafür etwas recherchiert und bin drauf gekommen, dass in der D Firmware die rausgeführten GPIOs für die Kommunikation anscheinend softwaremäßig(?) deaktiviert sind- ich habe jedenfalls an meinen Vcc, GND, und RX bzw. TX Pins nichts anliegen. Jetzt habe ich dieses [Repo](https://github.com/S-LABc/KORAD-3005-Arduino-ESP8266) mit einer P Firmware gefunden. Für mich sehen die P und D Boards identisch aus- daher die Frage: könnte man den Speicherchip 24C64 "einfach" mit einer P Firmware programmieren und dann geht's? Hat das schon mal jemand gemacht?
Hallo Christoph, vielen Dank für deinen Beitrag. Interessant, weil ich mich gerade heute unabhängig von deinem Post auch genau mit dem Thema beschäftigte, ob ich mein 3005D irgendwie mit dem Computer steuern kann. Ich habe das Gehäuse mal aufgeschraubt und gesehen, dass J9 frei ist und ich habe sogar einen OptoKoppler mit CH340 angeschlossen, jedoch konnte ich mit den verschiedenen Befehlen keine Reaktion erhalten. Ich habe länger gegoogelt und einige Infos gefunden, jedoch nichts, was mich überzeugt hatte, dass ein Upgrade tatsächlich möglich ist. Eine erste Überlegung meinerseits: Die Firmware liegt doch nicht in dem EEPROM sondern im NUC Microcontroller. Der Memorydump auf der github Seite ist nicht die Firmware. (Sind auch nur 8kb) Viele Grüße Nils
Hallo Nils, vielleicht ist der Begriff Firmware etwas zu hoch gegriffen, aber der Controller muss sich doch beim Start sein Programm holen, das er ausführen soll (beim P mit dem Steuerprotokoll)? MMn ist das in dem EEPROM hinterlegt und 8kB klingen zwar nicht viel, aber der Controller hat auch nicht soo viele Aufgaben zu erledigen. Es geht mir aber wie dir: ich bin noch nicht so überzeugt, dass ich es ausprobieren würde...
:
Bearbeitet durch User
Hallo Christoph, nee, der Microcontroller läuft auch ohne EEPROM, ist wie Arduino oder Raspberry Pi Pico. Das Programm liegt im Flash Speicher des Microcontrollers. Mir ist nicht ganz klar, warum auf der Github Seite ein Dump des EEPROMs hochgeladen wurde. Jedenfalls ist dort auf Github auch das Manual vom NUC029 Microcontroller angegeben. Das hatte ich daraufhin als korrekt angenommen. Es ist aber tatsächlich der M054LDN von Nuvoton. Ich habe jetzt selber noch einmal etwas ausführlicher gegoogelt. Es gibt tatsächlich jemanden (Tony Mach), der angefangen hat, eine eigene Firmware zu schreiben: https://www.eevblog.com/forum/repair/korad-ka3005p-power-supply-calibration/100/ Leider hat er das vor 6 Jahren angefangen aber seit dem ist nichts mehr passiert. Die ersten Quellen sind zwar da, es fehlt aber noch vieles. Das ist noch kein Ersatz für die existierende Firmware. Man kann offenbar aber auch nicht einfach die Firmware aus einem 3005P extrahieren. Das ist vom Microcontroller Hersteller bzw. dem PSU Hersteller über Secure Keys unterbunden. Es ist aber ganz hilfreich, die Artikel auf dem eevblog mal durchzulesen, das erklärt ein wenig mehr. Viele Grüße Nils
Ich weiss natuerlich nicht wie der Hersteller so drauf ist, aber es ist viel ueberfluessiger aufwand zwei unterschiedliche Mainboards zu handeln die sich lediglich in der Firmware unterscheiden. Wuerde ich mir nicht antun. Andererseits muss jede dieser Kisten kalibriert werden. Also entweder automatisch oder von Hand. In beiden faellen wuerde die info serielle ja/nein dann im EEprom liegen. oder es gibt eine loetbruecke oder kodierwiderstand auf dem board. Also mit etwas mehr intelligente Phantasie an die Sache rangehen. .-) Vanye
Wurde denn schonmal ausprobiert, das 3005D mit einem seriellen Interface zu verbinden? Vielleicht unterscheiden sich die Geräte gar nicht in ihrer Firmware, sondern nur durch das Vorhandensein bzw. Nichtvorhandensein der Schnittstellenhardware? Vanye R. schrieb: > oder es gibt eine loetbruecke oder kodierwiderstand auf dem board. Wozu? Unterscheidet sich denn das Verhalten der beiden Geräte in der Frontpanelbedienung?
Harald K. schrieb: > Wurde denn schonmal ausprobiert, das 3005D mit einem seriellen Interface > zu verbinden? Vielleicht unterscheiden sich die Geräte gar nicht in > ihrer Firmware, sondern nur durch das Vorhandensein bzw. > Nichtvorhandensein der Schnittstellenhardware? Hallo Harald, hier (https://m0wut.com/2019/08/25/power-supply-hacking-part-1/) ist ein Blogbeitrag von M0WUT, der es ausprobierte und noch tw. Erfolg hatte: Zwar kein ID-String auf “*IDN?”, konnte aber noch mit “VSET?” die aktuell gesetzte Spannung auslesen. Ein Kommentar von paulgeering ("TLDR; the newer Tenma 72-10480 seem to have the remote control disabled in firmware.") deutet aber darauf hin, dass es Firmware Versionen gibt, bei denen das gänzlich abgeschaltet ist. Meine eigenen Test waren auch nicht erfolgreich (s.o.) - Kann aber natürlich sein, dass ich was falsch gemacht hatte. > Wozu? Unterscheidet sich denn das Verhalten der beiden Geräte in der > Frontpanelbedienung? Ich habe ein 3005D aber kein 3005P, aber nach meinem Wissen gibt's keine Unterschiede. Wenn eine Verbidung über die Serielle Schnittstelle aktiv ist, wird lediglich ein Ton ausgegeben und die Frontpanelbedienung wird für diesen Zeitraum deaktiviert. Viele Grüße Nils
Was mich ein bisschen stutzig macht, ist der weiter oben verlinkte Schaltplan der Interfaceplatine. Die scheint einen µC als USB-Device zu verwenden; an einer dessen UARTs ist ist die RS232-Schnittstelle angeschlossen, und eine andere UART wiederum ist über zwei Optokoppler mit der Hauptplatine verbunden. Vielleicht kümmert sich ja dieser µC schon um Teile des Protokolls; man müsste einen LA dranhängen und beide UARTs abhören, um zu sehen, ob da eine Vorverdauung stattfindet.
Harald K. schrieb: > Wozu? Unterscheidet sich denn das Verhalten der beiden Geräte in der > Frontpanelbedienung? Ich kenne nur die P-Version, die keine mir bekannten Einstellmoeglichkeiten fuer das Interface an der Front. Es waere technisch moeglich das beides dieselbe Firmware hat. Man darf nicht vergessen das teile so billig wie irgend moeglich hergestellt werden muessen sonst waer der Preis nicht moeglich! Aber wenn der hersteller ohne extra aufwand ein nachruesten ausschliesen kann so wird ihm das gefallen. Da liegt der Gedanke nahe das dies am Ende der Produktion beim kalibrieren geschieht und aus einen Flag im Eeprom besteht. Ich glaube im uebrigen das die Teile echt von Hand kalibriert werden, auch wenn uns das absurd erscheint. Ich schon Teile gesehen die waren so bescheiden kalibriert das ich mir das nur mit Handarbeit erklaeren kann. Vanye
Vanye R. schrieb: > und aus einen Flag im Eeprom besteht. Und wozu braucht es dieses Flag? Ob das Ding fernsteuerbar ist oder nicht, hängt daran, ob die dafür nötige zusätzliche Schnittstellenplatine im Gerät verbaut ist.
Hallo Harald > Ob das Ding fernsteuerbar ist oder nicht, hängt daran, ob die dafür > nötige zusätzliche Schnittstellenplatine im Gerät verbaut ist. Das wäre ja super! Es würde bedeuten, dass Christoph und ich unsere KA3005D ohne Firmwareänderung auf KA3005P aufrüsten können. Würde mir sehr gefallen. Aber bevor ich mich zu sehr freue, würde ich dich gerne fragen, warum du so sicher bist. Viele Grüße Nils
Nils B. schrieb: > Aber bevor ich mich zu sehr freue, würde ich dich gerne fragen, warum du > so sicher bist. Vorbemerkung: Das ist 'ne Hypothese. Warum aber sollte es anders sein? Es wäre zusätzlicher Aufwand in der Fertigung, der über das Weglassen von Teilen hinausgeht. Die Hauptplatine beider Geräte ist identisch; man könnte als Bestückungsoption J9 bei den Geräten ohne Schnittstelle weglassen. Hier Beitrag "Re: Korad 3005D zeigt keinen Momentanstrom mehr an" ist ein 3005D abgebildet, da ist J9 sogar bestückt. Das ist ein Centartikel. Also scheinen die Hauptplatinen identisch zu sein. Was wäre auch für den Hersteller gewonnen, da µCs mit unterschiedlicher Firmware einzusetzen? Sollen "böhse HackerZ" davon abgehalten werden, sich da eine Platine ranzubasteln? Und dafür eigens zwei Firmwarevarianten pflegen?
Harald K. schrieb: > Und dafür eigens zwei Firmwarevarianten pflegen? Ich schrieb ja auch schon das ich das fuer unwahrscheinlich halte. Aber irgendwann muss man einfach mal die Aermel hoch krempeln und zum Schraubendreher greifen wenn man Hacker werden will. Ich meine wir waren ja nicht so sparsam und haben das Problem nicht. .-) Vanye
Da ich sowohl ein KA3005P als auch ein KA3005D besitze, habe ich es jetzt einfach mal ausprobiert, also das COM-Board der P-Variante an die D-Variante angeschlossen. Resultat: Geht nicht! Ob das nun aber an einer anderen Firmware oder möglicherweise nur an einer fehlenden Lötbrücke oder 0-Ohm Widerstand liegt, weiss ich nicht, so genau habe ich mir die Unterschiede der Boards nicht angeschaut. (Sie wurden mit 8 Jahren Abstand gekauft, sind also sowieso nicht völlig identisch.) Selbst wenn es ginge, wäre ein weiteres Problem, dass das COM-Board aus einer eigenen Trafowicklung versorgt wird - und die ist am KA3005D nicht vorhanden (oder vielleicht wurden die Drähte auch einfach nur abgeknippst, ich konnte jedenfalls keine sehen.) Gruß, Bernd
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_20231206_145708.jpg
470 KB
Ich habe einen ESP32 mit Micropython direkt an die serielle Schnittstelle am J9 angeschlossen. (siehe angehängtes Foto). Das Netzteil liefert über J9 auch gleich 3.3V, das passt also sehr gut. Über Webrepl habe ich mich dann mit dem ESP32 verbunden und kann die Serielle Schnittstelle am ESP32 bedienen.
1 | >>> from machine import UART |
2 | >>> u=UART(2,9600,rx=13,tx=12) |
3 | >>> u.init() |
4 | >>> u.write('VSET?');u.any()
|
5 | 5 |
6 | 0 |
Bisher habe ich noch keine Antwort vom KA3005D erhalten, mir ist aber folgendes aufgefallen: Ich hatte zunächst UART2 des ESP32 genommen (GPIO16, GPIO17). Ich erhalte kein Buzzer vom Netzteil ABER: Die Eingabe ist gesperrt. Genau so, wie wenn die Schnittstelle die Kontrolle übernommen hat. Allerdings habe ich alle möglichen Befehle ausprobiert und bekomme keine Antwort. ABER: (2. Aber) Nachdem ich die ersten 15 beliebigen Zeichen gesendet habe, bekomme ich ein Buzzer vom Netzteil und die Bedienung ist wieder freigegeben. Und der Lüfter läuft leise ... Ich habe noch einiges mehr ausprobiert - aber ohne Erfolg und komme jetzt erstmal nicht weiter. Viele Grüße Nils P.S. Irgendjemand macht sich hier die Mühe und bewertet jeden einzelnen Beitrag als nicht lesenswert. :-)
Nils B. schrieb: > P.S. Irgendjemand macht sich hier die Mühe und bewertet jeden einzelnen > Beitrag als nicht lesenswert. :-) Das ist ein Bot irgendeines Spinners. Der "bewertet" nach einer gewissen Zeit (1-10 Minuten) grundsätzlich alle neuen Beiträge negativ. Einfach ignorieren.
Nils B. schrieb: > Allerdings habe ich alle möglichen Befehle ausprobiert und bekomme keine > Antwort. Hm, haest du denn auch die Doku zu den Befehlen gelesen? Es ist jetzt schon ein paa Jahre her das ich das getan habe, aber ich bin mir relativ sicher das es da auch noch einen \n oder \r bedarf. Vanye
Hallo, gibt es schon Neuigkeiten zur Schnittstelle? Ich habe auch ein KA3005P nur die Schnittstelle reagiert nicht bei mir. Ich habe schon die Spannungsversorgung und die Optokoppler überprüft. TX vom PC kommt beim Mikrocontroller RX an, mit 3,3V Pegel. Wenn ich den Stecker vom Mainboard abziehe und TX mit RX brücke, kommt das Signal auch zurück zum PC. Schnittstellenboard ist soweit OK. Wenn alles wieder zusammengebaut ist, bekomme ich keine Antwort vom Netzteil. Es reagiert auf keinen Befehl. Lediglich die Bedingung am Netzteil ist gesperrt nachdem man etwas gesendet hat. Nach kurzer Zeit (ca. 5 Sekunden) ist die Bedienung wieder möglich. Bei einer andere Baud Rate verhält es sich auch so.
> gibt es schon Neuigkeiten zur Schnittstelle? Was soll es da neues geben? Die Kisten sind alt, die Schnittstelle funktioniert. > Ich habe auch ein KA3005P nur die Schnittstelle reagiert nicht bei mir. Wo ist dann das Problem? > Bei einer andere Baud Rate verhält es sich auch so. Und mit der richtigen? Bei mir geht es so:
1 | void SerialHandler::sendString(QString data) |
2 | {
|
3 | AntwortString.clear(); |
4 | serial->write(data.toLocal8Bit().constData(),data.length()); |
5 | serial->flush(); |
6 | |
7 | }
|
8 | |
9 | serial->setBaudRate(QSerialPort::Baud9600); |
10 | serial->setDataBits(QSerialPort::Data8); |
11 | serial->setParity(QSerialPort::NoParity); |
12 | serial->setFlowControl(QSerialPort::NoFlowControl); |
13 | serial->setStopBits(QSerialPort::OneStop); |
14 | |
15 | MyString = "*IDN?"; |
16 | |
17 | sendString(MyString); |
> Lediglich die Bedingung am Netzteil ist > gesperrt nachdem man etwas gesendet hat. Das ist gut. Das heisst das dein Netzteil Daten empfangen hat. Nur an deinem Datenformat stimmt noch was nicht. Vanye
Danke für die Antwort. Die Einstellungen habe ich geprüft, leider keine
Reaktion auf "*IDN?" oder einen anderen Befehl.
serial->setBaudRate(QSerialPort::Baud9600);
serial->setDataBits(QSerialPort::Data8);
serial->setParity(QSerialPort::NoParity);
serial->setFlowControl(QSerialPort::NoFlowControl);
serial->setStopBits(QSerialPort::OneStop);
Nur die Bedienung bleibt gesperrt. Habe die original Software und
Arduino Serial Monitor benutzt. Nur den Befehl, und den Befehl mit /r /n
am Ende.
> Nur den Befehl, und den Befehl mit /r /n am Ende.
HM..ich hatte eigentlich auch gedacht das die das am Ende haben wollen,
ist aber schon ein paar Jahre her das ich das programmiert habe, aber
siehst du da oben ein CRLF? Probier mal ohne.
Und ansonsten haeng mal dein Oszi auf die Schnittstelle. Mag ja sein das
dein Computer was anders sendet wie du glaubst.
Vanye
Markus schrieb: > Danke für die Antwort. Die Einstellungen habe ich geprüft, leider keine > Reaktion auf "*IDN?" oder einen anderen Befehl. > > serial->setBaudRate(QSerialPort::Baud9600); > serial->setDataBits(QSerialPort::Data8); > serial->setParity(QSerialPort::NoParity); > serial->setFlowControl(QSerialPort::NoFlowControl); > serial->setStopBits(QSerialPort::OneStop); > > Nur die Bedienung bleibt gesperrt. Habe die original Software und > Arduino Serial Monitor benutzt. Nur den Befehl, und den Befehl mit /r /n > am Ende. Wie hast du den PC mit dem Korad verbunden? Das Korad hat einen RS232 Treiber auf dem Interface, der die TX und RX Signale invertiert. Wenn du da mit einem der üblichen USB-UART Interfaces rangehst, wird das so nicht funktionieren, da deren Ausgangssignale nicht invertiert sind.
Markus schrieb: > Danke für die Antwort. Die Einstellungen habe ich geprüft, leider keine > Reaktion auf "*IDN?" oder einen anderen Befehl. > > serial->setBaudRate(QSerialPort::Baud9600); > serial->setDataBits(QSerialPort::Data8); > serial->setParity(QSerialPort::NoParity); > serial->setFlowControl(QSerialPort::NoFlowControl); > serial->setStopBits(QSerialPort::OneStop); > > Nur die Bedienung bleibt gesperrt. Habe die original Software und > Arduino Serial Monitor benutzt. Nur den Befehl, und den Befehl mit /r /n > am Ende. Hallo, das ist backslash \r \n . Gruß Sven
https://www.eevblog.com/forum/testgear/korad-ka3005p-io-commands/ Ich zitiere mal; The KORAD actually takes no line ending. If you have one set in your serial terminal, unset it. Sending a line ending will result in an unrecognized command, which is kindly responded to with nothing. Das entspricht auch dem was ich oben selber sende. Wenn man mal so drueber nachdenkt eigentlich merkwuerdig weil man sich fragt woran es erkennt das ein Kommando fertig uebertrangen wurde und nun bearbeitet werden soll. Vermutlich geht das ueber eine Pausenzeit. Anstatt sich die Finger wund zu programmieren ist das erstmal der moment wo hterm echt nuetzlich ist. .-) Vanye
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.