Drehgeber im BCR

  • Hallo Peter,


    danke für den Hinweis zum BCR Code. Habe mir das entsprechende File heruntergeladen. Mich interessiert die Einarbeitung des 60m-Bandes.

    Die Baugruppe PIC und Umgebung habe ich schon mehrmals aufgebaut, bisher keine Probleme mit den Drehgebern. Wenn dieser mal defekt geht

    muss er eben ausgetauscht werden, sind doch nicht für die Ewigkeit konzipiert, abgefahrene Reifen am Auto werden doch auch bei Erfordernis

    gewechselt , oder gibt es noch Leute, die wie vor zig Jahren ihre Reifen runderneuern.


    wünsche schönes WE


    73 de

  • Hallo Andreas,

    hier der Ausschnitt von der Interruptroutine. Es werden nur die Impulse gezählt und keine Berechnungen durchgeführt. Deshalb ist das schon so, wenn z.B durch das Prellen 100 Impulse entstehen werden die gezählt und durch die Schrittverdopplung sind das sogar 200 Impulse, da der Interrupt auf fallende und steigende Flanke reagiert (siehe Quelltext unten). Die Berechnung der neuen VFO-Frequenz geschieht dann in der Hauptschleife. Ich brauch ja nur testen ob Impulse angefallen sind. Je nach Anzahl der Impulse in positive oder negative Richtung wird die neue Frequenz eingestellt.

    Der Widerstand 4,7k wird nicht viel bringen. Intern ist im PIC an allen RB-PIN schon ein Pull-Up 10k. Ich habe mal die BCR-PDF Aufbauanleitung gelesen. Das einfachste ist C79 (1nF) und C80 (1nF) auslöten und durch 100nF ersetzen. Die beiden Leiterzüge von den Cs zum Drehgeber auftrennen und 2x 100 Ohm einlöten. Wenn das nicht funktioniert, kannst du ja weiter probieren. Aber das ist nur ein Vorschlag von mir, weil ich damit gute Ergebnisse erzielt habe. In meinem neuen Stationswattmeter habe ich das auch so realisiert.


    Schaltbild Drehgeber Stationswattmeter


    Ich hoffe das hilft weiter.


    vy 73 Andreas, DL4JAL

  • Hallo,

    ich melde mich gleich noch mal. Peter wird sicherlich nichts dagegen haben wenn ich den Quellcode heraus gebe. Wenn das der "BCR-Gemeinde" etwas nützt. Aber wie gesagt das Projekt ist schon 15 Jahre alt. Mit den modernen PICs geht das alles besser und einfacher.

    Die Quelltexte sind alle unter Linux erstellt und kompiliert worden. In der "makemc.sh" sind die Befehle für die Kompilierung ersichtlich (gpasm und gplink). Unter Windows wird es nicht zu kompilieren gehen. Das ist aber nur eine Vermutung von mir.


    mc.zip


    vy 73 Andreas, DL4JAL

  • Hallo Andreas


    Vielen Dank für Dein Zip-Archiv. Habe es mir zur "Weiterbildung" mal angesehen.

    Ich werde da nicht einsteigen - zum einen habe ich kein BCR, zum anderen hatte ich noch nie mit PICs gearbeitet. War bis Anfang der 90er 7 Jahre als Hard- und Firmwareentwickler für 8051-Systeme tätig. Als ich hobbymäßig vor einigen Jahren wieder eingestiegen bin lief mir als erstes das MSP430 launch pad über den Weg und dabei ist es dann geblieben.....und die MSPs programmier ich inzwischen nahezu ausschliesslich in C.


    Aber jetzt haben alle Interessenten eine Steilvorlage für Variationen. Die Umstellung auf eine IDE im Windows-Umfeld dürfte da das kleinste Problem sein.


    Martin

  • Hallo,

    in meinem Eigenbautransceiver verwende ich einen PIC18F4550. Der Drehgeber geht auf die Portpins RB4 und RB5, welche bei jeder Zustandsänderung einen Interrupt auslösen. Die Interruptroutine wertet die alten Zustände (die von der vorhergehenden Interruptroutine) und die neuen Zustände aus. Das ergibt 2x2 Bit = 16 Möglichkeiten. 4 von ihnen bedeuten Aufwärtszählen, 4 weitere Abwärtszählen. Weitere 4 bedeuten es hat sich nichts geändert, möglicherweise ist der Kontakt zurückgeprellt, bevor der neue Zustand ausgelesen werden konnte, der Zählerstand bleibt wie er ist. Bei den letzten 4 Möglichkeiten haben sich beide Bits geändert, das kann nur passieren, ein eine Zustandsänderung übersprungen wurde. Hier ist nicht feststellbar, ob das links- oder rechtsrum passierte. Also bleibt auch hier der Zählerstand, wie er war. Getestet habe ich das anfangs nicht mit einem Drehgeber, sondern durch das Zusammenhalten von Drähten, was natürlich entsetzlich prellte. Zu erkennen war das aber nur durch das Flackern der durch einen niedriger priorisierten Interrupt betriebenen LED-Multiplexanzeige. Bei der Frequenz traten keine Sprünge auf, hier wurde höchstens auf der letzten stelle wie oben schon erwähnt, hin und her gesprungen.

    Hier der entsprechende Codeschnipsel


    decf WREG ; 0 if it was 0001

    bz hpi_dec_f

    decf WREG ; 0 if it was 0010

    bz hpi_inc_f

    decf WREG ; 0 if it was 0011

    decf WREG ; 0 if it was 0100

    bz hpi_inc_f

    decf WREG ; 0 if it was 0101

    decf WREG ; 0 if it was 0110

    decf WREG ; 0 if it was 0111

    bz hpi_dec_f

    decf WREG ; 0 if it was 1000

    bz hpi_dec_f

    decf WREG ; 0 if it was 1001

    decf WREG ; 0 if it was 1010

    decf WREG ; 0 if it was 1011

    bz hpi_inc_f

    decf WREG ; 0 if it was 1100

    decf WREG ; 0 if it was 1101

    bz hpi_inc_f

    decf WREG ; 0 if it was 1110

    bz hpi_dec_f


    Alle 4 Zustandsänderungen pro Periode bewirken einen Frequenzschritt, bei Drehgebern mit zwei bzw. vier Zustandsänderungen pro Rastung dürfte man das rechte bzw. die beiden rechten Bits nicht für die Frequenzeinstellung verwenden.


    Bernd

  • Hallo Bernd,

    den "RB Port Change Interrupt" zu nehmen ist auch eine gute Idee. Ich werde nur aus deinem Code nicht so richtig schlau. Da fehlt mir jetzt der Zusammenhang. Es ist nicht immer so einfach sich in einen anderen Code hinein zu denken.


    vy 73 Andreas, DL4JAL

  • Nochmal Danke, Andreas!


    Ich konnte auf Anhieb kompilieren! sudo apt-get install gputils, dann musste ich noch LINKERSCRIPT=/usr/share/gputils/lkr/16f877a_g.lkr) ändern, und schon lief die Sache. So leicht hatte ich mir das nicht vorgestellt! Cool! In meinem Fall Debian Jessie, funktioniert vielleicht auch unter Ubuntu.


    Zwei kleine Bitten hätte ich noch an Dich:


    a) Mich interessiert, welche Version der Sourcen das jetzt ist. Version 1.6, richtig?


    b) Bist Du noch so nett, zu überprüfen, ob deine Datei mc.hex (gerne von vor ein paar Jahren) dieselbe SHA256 hat, die bei mir rausgekommen ist?

    Code
    1. $ sha256sum mc.hex
    2. f305609270c253750b459b912be9836ff27b22804f05c0b189892e7b405eb536 mc.hex

    Du schreibst noch etwas pessimistisch:

    Unter Windows wird es nicht zu kompilieren gehen.

    Doch, keine Bange! Zumindest, wer als Windowsuser bereit sind, sich Docker zu installieren, der kann das auch auf Windows kompilieren. Wer es nicht weiß: "Docker" bedeutet, dass man ein kleines Linux unter Windows laufen lässt. Damit geht das bestimmt! Zumindest das Compilieren. Wie man die fertige .hex - Datei dann auf den PIC brennt, ist eine andere Frage.


    Wenn da irgendjemand Interesse hat, kann ich schnell mal eben das Nötige zusammenstellen (definitiv noch dieses Jahr 😉). Das ist eine Fingerübung. Ich mach sowas auf dem Job auch dauernd.


    Es grüßt (sehr zufrieden mit dieser Entwicklung)


    Andreas, DJ3EI

  • Hallo Andreas,

    da habe ich mich nicht ausführlich genug ausgedrückt. Ich meine unter Windows "MPLAB X IDE". Das läuft nicht. Zum Brennen benutze ich "PicKit3". Das funktioniert unter Linux mit "MPLAB IPE" oder unter Windows mit der SW auf meiner Seite: SW_PicKit3.

    Der Source ist Version 1.16 (steht auf Zeile 2526). Wenn ich neu kompiliere ist die Prüfsumme wie bei dir. Allerdings weichen die alten Prüfsummen ab. Das ist eigentlich klar, da habe ich sicherlich im Quelltext irgend etwas modifiziert. Aber frage mich bitte nicht was. Das ist viele Jahre her. Ich kontrolliere die Prüfsummen nie. Wenn nach dem Kompilieren "Kompilieren: Fehlerfrei!" steht ist alles in Ordnung. Das reicht mir. Ältere Versionen habe ich auch noch wenn du etwas vergleichen willst.


    vy 73 Andreas, DL4JAL