Communication (to rc-heli.de)

S32terminal: IP of the update server to be changed!

.

 

----------------------------------------------------------------------------------------------------------------------------------------

UltraGuard Button

https://www.rc-heli.de/board/showthread.php?t=269205

https://www.digikey.de/product-detail/de/panasonic-electronic-components/EVQ-PUD02K/P10850STR-ND/286337?enterprise=-1

.

 

----------------------------------------------------------------------------------------------------------------------------------------

Bzgl. der Frage zu R2 buffer v4 in rc-heli.de

https://www.rc-heli.de/board/showthread.php?t=249398

Zu einem BEC mit Design Flaw an Bufferv4: (getötet durch Voltage an seinem Ausgang, wenn off)

 

So ein BEC(ESC) gehört entsorgt, setzt man eigentlich nicht ein.

In meiner aktiven Zeit kannte ich nur ein BEC in einem ESC mit dem Flaw. Erinnere mich nicht mehr, welcher.

So ganz duster ist mir, als hätten die BEC von US Robotics auch diese Schwäche gehabt(?)...

 

Schutzmaßnahmen für solche Schwachblasen sollten nicht die Nutzbarkeit des Buffers negativ beeinflussen.

 

Ja, ein Buffer + R-Platine ist ein 4-Pol, - ist theoretisch die sicherste Lösung.

Ja, Bufferv4 ist ein 2-Pol.

Seit Mikroprozessoren, Einchiprechnern, Microcontrollers hat es oft keinen statischen Circuit mehr.

Schalttransistoren, Steuerung komplexerer Komponenten, flexibel verwendete Messpunkte schaffen veränderliche, adaptive Circuits.

Es bleibt aber ein 2-Pol.

 

Wie bei SARS CoV-2 muss man wissen, welches Organ eines BEC Organismus dessen Tod hervorrufen kann, - und, unter welchen Umständen.

So ein Wissen plus flexible circuitry kann u.U. Schutzmöglichkeiten schaffen, die praktisch nicht schlechter sind als Wandlung in 4-Pol mit idealer Diode.

Das ist hier der Fall:

  - Die flaw-belastete Komponente (Längs-FET eines Buck) kann nur Sterben, wenn hinter ihr im BEC alles voll entladen ist.

    Hier hilft eine state machine in der MCU: Hatte der BEC noch nie Ausgangsspannung, gebe ich keine charge voltage der Cs aus (Woher überhaupt?)

  - Somit ist es ein kurzzeitiger Peak Strom, der tötet.

    Bufferv4 hat alles an Switching, was es erlaubt, für den betreffenden Augenblick den Strom zu limitieren per Switching, ohne den Nutz-Load zu beeinträchtigen.

    Innerhalb von Mikrosekunden ist hinter der Schwachblase die Ladungssituation bereits untödlich geworden.

 

Das Blockschaltbild zeigt nur für obiges verwendbare Komponenten, nicht die Funktionalität in Software, natürlich.

Es ist nicht mein Design, sondern Marcellinus'.

 

P.S. Ein Optipower BEC Guard zwischen BEC und Buffer schützt natürlich am besten.

   Ich werde nie vergessen, wie Marcellinus ein Entwicklungsmuster einfach in die Steckdose bohrte, 230VAC.

    (Es kann zwar eigentlich nur -40V ab, aber der 50Hz Sinus macht theoretisch, dass es das überlebt,

     und es tat es zumindest in der einen Wildsau-Aktion. Spaß muss sein, sprach Wallenstein. :))

   Als EME funkender HAM war ich zwar gewohnt, mit 4kV zu machen bei x Ampere (bei Ausversehenkurzschluß ein Pistolenschuss :)),

   aber die Tests am Guard mit 1500V usw. haben trotzdem auch bei mir kurzes "Startzittern" verursacht. :)

BEC Guard

Pardon für das Aussehen der page, habe es barfuß per vi gemacht.

 

 

----------------------------------------------------------------------------------------------------------------------------------------

Bzgl. S32--Tribunus/FrSky Problem in rc-heli.de

https://www.rc-heli.de/board/showthread.php?t=268636

Zitat: "Leider kommt gar nichts an. Ich habe bei dem S32 einmal Testvalues ausgewählt, die kommen alle an."

Ergo: S32-->FrSky Tele ist ok. Was nicht funktioniert, ist Tribunus-->S32 Daten. Da weitersuchen.

Tribunus: protocol type setup: STANDARD (==0) - nicht unsolicited!

STANDARD: S32 fragt data items ab vom Tribunus, - während im unsolicited mode der ESC einfach stumpf Daten sendet,

keinen request empfängt. -- Die rote <+> Strippe NICHT anschließen, nur GND und Signal (gelb)!

 

----------------------------------------------------------------------------------------------------------------------------------------

Flashen von KOSMIK, JIVEpro

https://www.rc-heli.de/board/showthread.php?t=268794

Ja, Vorsicht! Es gibt keinen Bootloader mit Anti-Brick Feature, und die Flashing App hat einen Fehler!

(Ich beschrieb die Ursache dieses Fehlers sogar gegenüber K... Zugegeben, es ist eine Sache in Visual Basic, die nicht einfach erfassbar ist.)

Am besten die Hände vom PC lassen während des Flashen!

Es wäre einfach gewesen, 2 Pins des ESC z.B. mit SWD (Serial Wire Debug) alternativ zu belegen, um eine bricked MCU easy "befreien" zu können.

Das tat man aber nicht.. Ein KOSMIK muss dazu geöffnet und intern konnektiert werden, - einen JIVE muss man erst aufwändig ausschlüpfern.

--------------------------

Sorry, die neuerlichen, unsynchronierten Firmwareänderungen.. Man gab mir keine Chance, den mir unbekannten neuen Coder zu kontaktieren,

um zu erfahren, warum, und vor allem, WAS er änderte.

K kostete mich soo viel Zeit im Laufe der Jahre.. Ich "heilte" trotzdem immer wieder.., - der Historie von JLog geschuldet, siehe am Ende der page.

.

 

----------------------------------------------------------------------------------------------------------------------------------------

S32 - JIVE Pro

... https://www.rc-heli.de/board/showpost.php?p=3472044&postcount=16

Quote: "wenn der S32 an einem Jive läuft, dann kann er an einem Jive pro nicht laufen. Die beiden haben unterschiedliche Protokolle. Du benötigst für den S32 eine andere Firmware."

BS.. Es gibt immer nur EINE (aktuelle) Firmware für S32, die alles per S32terminal konfigurierbare unterstützt.

Nicht, dass Du auch ein falsch belegtes Anschlusskabel bekamst... https://www.rc-heli.de/board/showthread.php?t=263348

 

----------------------------------------------------------------------------------------------------------------------------------------

Nun doch mit benanntem Inhalt:  JLog Historie       ...und Grund für Punkt.