Posts by jrie

Eine Frage an die Elektronik Fachleute:

Ich will Optokoppler PC817 einsetzen. Anode an 3,3V, Kathode wird über einen Widerstand vom uC heruntergezogen auf (nahe) Masse. Emitter an Motherboard-Power-Minus und Collector an Motherboard-Power-Plus.

Die Schaltung auf dem Motherboard ist unbekannt. Wie groß sollte der Widerstand optimalerweise sein?

Martin hat 220 Ohm genommen: https://github.com/ranseyer/ST…all_ST-Link/Schematic.png

Argus wrote:

Es könnte vermutlich sein, das die Masse nicht das Bezugspotential für den Schalter bildet.

Vor etlichen Jahren hatte ich bei einigen Boards das auch mit meinen IR-Einschaltern festgestellt. Dort hatten beide Pins von Power-On des MB keinen Massebezug. Seitdem baue ich nur noch Optokoppler ein (mit ca. 200 - 300 Ohm auf CE Strecke bei On). Das hat bis jetzt dann überall funktioniert.

Argus wrote:

die 2x 200 Ohm könntest Du auch einsparen, indem Du den Flussstrom auf der Sendeseite durch höheren Vorwiderstand reduzierst. Dann wird die CE Strecke entsprechend hochohmiger. Idealerweise sollte sie aber 0 Ohm einem Schalter entsprechen.

Wie sieht denn deine Schaltung aus?

obelix wrote:

Mit der IRMP_STM32 Version funktioniert dieser

Was für einen Code liefert denn stm32IRconfig_gui im receive mode bei dieser Taste?

Und was hast du diesem Code in der stm32kbdIRconfig_gui zugewiesen?

Gib ihm mal den Pfad zum Bootloader mit, also z.B. st-flash --reset write /Pfad/boot.blueDev.bin 0x8000000

Hilft das?

habichthugo wrote:

Die Foto-TAN-Apps funktionieren (nach Installation) ohne SIM und Inet-Verbindung????

Genau. Meine jedenfalls.

Die Geräte, die man statt dessen kaufen kann, brauchen ja auch kein Netz.

https://www.heise.de/tipps-tri…rn-so-geht-s-3988965.html

"Ein Android-Gerät verfügt über zwei PINs: Die Geräte-interne PIN, mit der Sie Ihr Smartphone oder Tablet entsperren, und die PIN der SIM-Karte."

Ich benutze sogar ein Android 5 nur für die Foto-TAN. Ohne SIM, ohne WLAN.

Ohne Netz können auch keine Daten irgendwo hin gehen.

Das erinnert mich an "fix sometimes wrong audio PTS":
https://github.com/j1rie/softh…7e290d8e833caf25ae9106666

jojo61 wrote:

Ich schaue mal ob ich eine einfache Lösung finde um Audio "Stille" einzuschleusen. Nur so wird es langfristig stabil. Hast du evtl. eine Idee ?

Man kann sich das bei xine abgucken.

Einfache Player nehmen Audio auch als Taktgeber, schlauere Player haben einen eigenen Taktgeber.

Da bei softhddevice Audio als Taktgeber dient, hat man beim Syncen nur eingeschränkte Möglichkeiten.

Auch reufer hat in Bezug auf das rpihddevice irgendwo hier mal geschrieben, dass nur über Video zu syncen nicht immer hilft.

Ideal wäre es, aus softhddevice einen "schlauen Player" zu machen. Nur wer will sich die ganze Arbeit machen ...

jojo61 wrote:

Nur leider sind damit dann wieder die a/v sync Probleme da.

Das Problem ist das der Ton zu früh losläuft und dann das Bild den Ton nicht mehr einholen kann. Deswegen hatte ich es so prgrammiert das

der Ton erst dann loslaufen darf wenn das erste Frame vom Bild kommt. Das killt dann aber Radio. Den Ton zu verzögern ist gar nicht so einfach.

Den Thread einfach anhalten bringt nichts weil dann das Audiodevice eine Bufferunderrun bekommt und damit die Sync auch futsch ist. Also müsste ich stille "einschleusen" und das ist gar nicht so einfach je nachdem ob es AC3 oder Stereo gerade läuft.

Im Original PLugin wird dann einfach ein Frame verworfen um wieder näher an den Ton heran zu kommen. Aber irgendwie klappt das nicht immer weil gar nicht genug Frames zum verwerfen da sind. Da muss ich wohl nochmal nachdenken was ich da tun kann.

Als ich mich damals intensiv mit softhddevice beschäftigt habe, bin ich auch auf dieses Problem gestoßen und nach vielen Experimenten zu dem Schluss gekommen, dass softhddevice da einen Designfehler hat.

Das Konzept nur Video "wegzuschmeißen" funktioniert bei softhddevice manchmal nicht.

Ich glaube, dass es manchmal unerläßlich ist, auch Audio "wegzuschmeißen" (vielleicht reicht Stille einfügen ja auch).

Andere Player wie z.B. xine machen das auch und haben trotztdem keine Audioknackser.

Dass bei softhddevice Audio der Taktgeber ist plus der Sync-Mechanismus von softhddevice ergibt in gewissen Situationen ein nicht lösbares Problem.

Klicke in die debug messages , kopiere alles und füge es in einen Editor ein und poste das bitte.

Zusätzlich poste bitte auch das Ergebnis von "get eeprom", "save file".

für jede Karte. Wie unterscheiden sich die Attribute? Das kannst du dann für eine udev-Regel nutzen.

Dann bleiben dir die udev Attribute.

Schau mal hier.

berndb wrote:

xinelibout

Da könntest du mal Petri kontaktieren.

obelix wrote:

Und laut Hersteller ein "BlackPill"

Manche Angaben der chinesischen Hersteller haben mit der Realität wenig zu tun.

LED an PC13 => BluePill, siehe hier (unter "Differences").

Ist das tatsächlich ein STM32F303CCT6?

Meldet er sich auch so beim Bootloader flashen?

Geht denn jetzt Alles?

Was steht in der config.h unter "blue developer board" als IR_IN_PORT und IR_IN_PIN?!

Als Bootloader nehme ich nur noch diese (das aber nur nebenbei).

Sieht aus wie ein Maple Bootloader. Hast du den drauf gemacht, oder ist er Original?

Wenn Original, probier doch die M-Maple-Firmware. was sagt lsusb -vvv?

Wenn selber, nimm den passenden Bootloader.

Nimm lieber die blueDev-Firmware.