Selbstbau eines Tonbandgerätes
#51
In der ersten if-Zeile (Keine Warnung) wertet er das (c = 'x') gar nicht mehr aus, weil das (i <= 3) schon true ist.
VG Jürgen
Zitieren
#52
Ja, stimmt schon. Aber es gibt auch keinerlei Compiler-Warnung, wenn das insofern korrekt ist. Habe mal ein sehr überschaubares Beispiel gemacht, das genau dem Fehler entspricht, der mich soviel Zeit gekostet hat. (Nur dass die Eingabe natürlich nicht schön deutlich über die Eingabe, sondern irgendwie in den Sensoren kamt)

Code:
char c = 'a';
int i = 0;

void setup() {
  Serial.begin (9600);
}

void loop () {
  if (Serial.available()) {
    c = Serial.read ();
    Serial.println (c);
  }
  if ((c = 'x') && (i % 2 ))   // keine Warnung!!
    Serial.println ("hier"); 
  else
    Serial.println ("nicht");
  i += 1;
  delay (1000);
}
Egal, was man eingibt, es kommt immer abwechselnd "hier" und "nicht", der erste Teil der zusammengesetzten Bedingung ist immer wahr.
Für mich als alten Pascal-Fan wäre das eine Gelegenheit, mal über diese Kaugummi-Typisierung von C bzw C++ herzuziehen - verkneife mir das jetzt. Nur das: Warum kein explizites Type-Cast, wenn man es haben will?

Na egal, ich habs ja gefunden, und erstaunlich ist doch, welche Themen noch alle an so einer Bandmaschine dranhängen.

Hier läuft gerade zum 3. Mal ein Band insgesamt mit Bandzugregelung durch. Nachdem ich die Regelspannung (sprich den pwm-Wert) über einen "gleitenden Durchschnitt", z.Zt. über 3 Umdrehungen, laufen lasse, bleibt auch der Bandzughebel sehr schön ruhig und gleichmäßig, ohne diese Software-Dämpfung zappelt er in bestimmten Bereichen ganz schön herum. Klar, eine schöne schwingfähige Angelegenheit aus Motormasse und Federspannung des Bandzughebels. Vielleicht mache ich davon noch ein Diagramm und bringe es hier. So etwas sind jedenfalls für mich produktive Fehler und nicht so blöde Syntax-Geschichten.

Nebenbei mal die Kühlkörper-Temperatur bei diesem Dauerlauf gemessen. Die liegt bei bescheidenen 45 °C, da brauche ich mir darüber jedenfalls keine Sorgen zu machen.

Ansonsten -
MfG
Selbstbauer
Zitieren
#53
Ich schweife mal ab vom Threadtitel - ist ja auch nicht das erste Mal im Forum  Wink

(12.11.2020, 15:52)JUM schrieb: In der ersten if-Zeile (Keine Warnung) wertet er das (c = 'x') gar nicht mehr aus, weil das (i <= 3) schon true ist.

Das ist so nicht richtig.
In
Code:
...
i = 3;
...
if ((c = 'x') && (i <= 3))

steht ja ein && in der Mitte, d.h. beide einzelnen Teile müssen TRUE sein.

"TRUE" in C ist - wenn ein Wert zur bool'schen Auswertung direkt her genommen wird - alles was >0 ist.

Linker Teil:
Nach der Zuweisung c = 'x' steht in c der Integer-Wert 120dez und damit ein Wert >0, somit ist der erste Teil des log. "UND" == TRUE.

Rechter Teil:
Nach der Zuweisung i = 3 ist der rechte Teil des UND immer TRUE.

Somit ist defacto das ganze "If" immer TRUE
Code:
if (TRUE)
 hätte das gleiche bewirkt  Tongue

Schreibt man bspw
Code:
...
i = 3;
...
if ((c = 0) && (i <= 3))
und weißt c also den Integer-Wert 0dez zu, dann wird (c = 0) konstant gleich FALSE und damit das ganze UND nie TRUE.

@Selbstbauer:
Schmeißt Dein Compiler eine Warning oder einen Error ?
Und welchen genau ?
Gruß, Kuni
..............................

http://kuni.bplaced.net/
..............................
Zitieren
#54
Stimmt, Kuni, das && habe ich übersehen.
VG Jürgen
Zitieren
#55
Ich für meinen Teil würde für Neuentwicklung den Teensy4.1 verwenden. Der hat mehr Speicher.
Bei den nächsten Wahlen wähle ich die NSA, denn die sind die einzigen die sich um mich kümmern.
Zitieren
#56
Hallo Tonbandfreunde,

vielen Dank für eure Beiträge. Ich habe das Gefühl, dass ich die Software jetzt weitgehend im Griff habe. Die Sprache "C" bzw. "C++" ist halt auch ziemlich neu für mich. Es wird jetzt dort umfangreiche Aufräum- und Strukturierarbeiten geben. Dann werde ich entweder den Bandlängen-Zähler noch in den ersten Arduino reinpacken können oder einen zweiten dafür in Betrieb nehmen. Auf einen anderen Prozessor stelle ich deswegen nicht um. Da würde ich eher noch die Bandführung generell auf meine neueren Erkenntnisse umstellen.

Um mal wieder was für's Auge zu bieten, habe ich mal einen kleinen Film gemacht. War recht zeitaufwendig, vor allem, da dies meine erste halbwegs ernsthafte Beschäftigung mit dem Thema Video ist. Darum holpert es auch mit dem Schnitt und der Vertonung ein bisschen, aber vielleicht möchtet Ihr ihn trotzdem sehen. Wichtig und richtig war auf jeden Fall, auch dem linken Wickelmotor einen Sensor zur verpassen. Nach überschlägigen Betrachtungen wird der Prozessor auch 4 Reflektoren pro Motor vertragen, wenn beim Umspulen die Berechnung so umgeschaltet wird, dass weiterhin nur 1x pro Umdrehung geregelt wird. (Das könnte auch ruhig noch seltener passieren, soo schnell ändert sich der Wickeldurchmesser nun auch wieder nicht.)

Noch zum Filmchen: G**g** u. Co. möchte ich nicht unbedingt mit meinen Inhalten beschenken, deshalb nutze ich meine eigene HP. Da diese recht klein (und preiswert gehostet) ist, werde ich diesen "Content" dort nach einiger Zeit wieder löschen.

Aber nun erst mal den Link: Tonbandbau_Film

Der "Selbstbauer" ist mir im Gruß inzwischen zu lang, deshalb grüßt Euch ab sofort

MfG

Binse
Zitieren
#57
Beeindruckend das Filmchen !! Respekt !!

Manni
2 Dreher und ca. 38 Tonbandgeräte an drei Anlagen ............  Rolleyes
Zitieren
#58
Danke für die anerkennenden Worte!
Binse
Zitieren
#59
Hallo Binse,

super Leistung,
vielen Dank für den Film.
Gruß
Peter
Zitieren
#60
Ich bin in diesem Forum erst ganz neu aktiv, deshalb erst mal ein "Hallo" in die Runde. 

Binse, es ist für mich unfassbar Interessant, was Du hier zeigst. Ich bin wirklich beeindruckt. 

Danke für den Film!
Viele Grüße 
Manfred

"The warm sound of analog recordings is made of harmonic distortion and Tape hiss - I like it".
Zitieren
#61
Nochmal vielen Dank für die freundliche Anerkennung!

Bin halt gerade an der Software, da gibt es nicht viel zu sehen. Vielleicht höchstens den Test fürs Display.
   
Da werden gefühlt 1000e von Schriftarten und Größen angeboten, da kann man sich tot testen, was einigermaßen aussieht und nicht soviel Speicher braucht. Das kleine OLED frisst ca. 3/4 der Ressourcen, aber vielleicht passt es alles in einen Nano - ich arbeite daran!

MfG
Binse
Zitieren
#62
Hallo, Binse,
bin auch sehr beeindruckt! Danke für den Film.

LG
Mike
Zitieren
#63
Ich würde 2 Nanos nehmen, einen für das Display und den Counter und ggf. für einen IR-Empfänger, den 2. Nano dann für die Steuerung des Gerätes.
Wie du schon geschrieben hast, braucht das Display samt Schriftarten eine Menge Platz und wenn du dann noch ein bisschen Grafik, wie Linien usw. darstellen willst, ist der Kleine bald voll.
Viele Grüße
Eckhard

M15A; Revox A700, B77, A76, A77, A78; Braun TG1000; Uher 4400 Report Stereo IC; www.engelstrasse.de
Zitieren
#64
Wäre ein größerer Display nicht besser? Dann könnte mehr Sachen darstellen. VUs und Peakmeter, aktuelle Parameter (Geschwindigkeit, Pegel usw.), Bandsorte, BIAS-Einstellungen, ... Wenn man es übertreiben möchte, könnten wichtige Parameter am Anfang jedes Bandes gespeichert werden und die Maschine könnte anhand diesen sich selbst einrichten bzw. selbst testen (wie das Azimuth, z.B.). Siehe z.B. das vierte Bild hier: https://www.ebay.de/itm/STUDER-REVOX-All...3451868255

Gruß

Nelson
Zitieren
#65
Auch ich kann hier einfach nur sagen: Respekt! Tolle Sache!
Wo kriegt man heut zu tage eigentlich noch so viel Wissen über Bandmashinen her? Steuerung, Bandzug, Bandführung usw. Gibt es da noch irgendwo alte Literatur wo man etwas reinlesen kann (auch Kassette)?


mfG
yege
Zitieren
#66
Hallo Tonbandfreunde,



erst mal vielen Dank für Eure ermutigenden Beiträge!



Z.Zt. "kämpfe" ich noch weiter an der Software. Dafür zu sorgen, dass im normalen Vorlauf alles richtig zieht und bremst ist das eine, und es ist das leichtere Problem. Auch die verschiedenen Werte für die beiden Bandgeschwindigkeiten 19 u. 9,5 sind leicht einzusetzen, und schließlich habe ich auch noch die einzelnen Funktionen, wenn sie für den linken und rechten Motor symmetrisch sind, zusammengefasst und nur über verschiedenen Indizes mit den passenden Parametern versorgt. Das funktioniert soweit richtig rut.



Die Tücken liegen in den Anlaufvorgängen. Die Unterschiede zwischen vollen und leeren Spulen sind gewaltig, was den nötigen "Schwung" im Anlauf betrifft. Ich hatte erst versucht, die Geschichte durch einen sog. "gleitenden Durchschnitt" zu glätten, der mehrere Impulse zusammenfasst. Problem ist dabe, dass sich die korrekte Regelung dann nur sehr langsam einstellt. 



Jetzt bin ich auf die Idee gekommen, eine richtungsabhängige Einstellzeit zu verwenden. Es funktioniert im Grunde wie ein Stoßdämpfer - schnell einfedern, langsam wieder ausfedern. Das ließ sich relativ einfach verwirklichen, indem halt die Regelspannung von einer zur nächsten Messung nur einen bestimmten Betrag abfallen darf.



Damit kann ich für den Start einen guten mittleren Wert vorgeben, der für einen sicheren Anlauf sorgt. Bei kleinem Wickeldurchmesser sinkt dann der Wert in wenigen Umdrehungen auf den Sollwert ab, bei größerem Wickel steigt er zügig an. Das funktioniert jetzt auch. Dieses "Feintuning" dauert aber seine Zeit, da man praktisch nach jeder Parameteränderung einen ganzen Banddurchlauf mit möglichst vielen Stopps und Starts benötigt, und dann die Messungen auch noch auswerten muss, sonst sind sie sinnlos.

Verbessern lassen wird das Ganze noch, wenn ich weitere Reflektoren an den Motoren anbringe. Dann werden alle Steuerungsvorgänge wie die Ermittlung des richtigen Bremszeitpunktes oder des richtigen Aufwickel- und Abwickelmomentes entsprechend zügiger funktionieren. Allerdings muss der Arduino dann auch bei schnellem Umspulen noch mit der Verarbeitung nachkommen, sonst würde z.B. ein Stopp-Befehl gar nicht mehr ausgeführt werden. Ich werde dies noch testen, aber sinnvollerweise muss dann erst mal die direkte Bedienung am Gerät und nicht mehr die per PC installiert sein. Das wird jetzt mein nächstes Ziel (Und dann gibt es auch wieder Bildchen)



Die Befehle, welche die "inneren Zustände" des ganzen Programm-Geraffels an den PC melden, die Input-Schleifen für die Steuerbefehle usw. können dann natürlich per Compiler-Schalter ausgeschaltet werden, das könnte gerade genug Platz schaffen, um auch die Display-Steuerung noch auf den einen Nano zu stopfen. Ansonsten sollte der Display-Kram auf einen 2. Nano ausgelagert werden, wie schon angemerkt wurde. Der 2. Arduino und das Display hängen dann zwar an den gleichen Leitungen, aber das sollte eigentlich, da es sich um ein Bus-System (I2C heißt das glaube ich) handelt, kein Problem werden. Die Steuerung selber benötigt erstaunlich wenig Platz.



Ein größeres Display werde ich nicht vorsehen, der wichtigste Parameter, die Bandlänge, ist auch so bestens und weit genug abzulesen. Sollten noch weitere Anzeige-Bedürfnisse bestehen, gibt es halt ein 2. Display. Aussteuerungskontrolle? Bisher plane ich nur ein reines Wiedergabe-Gerät. Aber vielleicht, wer weiß? Jedenfalls geht es weiter mit dem Bau, wenn vielleicht auch zu langsam.



Auf die Frage nach meinem Wissenserwerb über Bandmaschinen kann ich nur sagen: Diese Geräte haben mich schon als junger Mensch interessiert, und ich habe, damals als Schüler, viele Billig-Tonbandgeräte für Kumpels (und meine eigenen) repariert. Vieles ist einfach sinnfällig, andere Dinge beruhen auch auf Erfahrungen, die ich beim Bau meines 1. Selbstau-Tonbandgerätes, ebenfalls noch als Schüler, gemacht habe. Dieses Ding lief damals so ca. 10 Jahre, und es lief viel.



MfG

Binse
Zitieren
#67
Hallo,

1. wenn zwei "Master" gleichzeitig auf den I2C-Bus zugreifen, "gewinnt" der physikalisch schnellere Chip, nicht der "wichtigere". Das kann zu unerwünschten Verzögerungen führen.
2. Es gibt Prozessoren, bei denen der I2C-Clock an den Prozessor-Clock gekoppelt ist. So zB bei Raspberry Pi. Das führt dazu, daß er den I2C-Bus schneller taktet, wenn er gleichzeitig ein Video darstellen soll, aber langsamer, wenn er nix anstrengendes zu tun hat. Das Verhältnis beträgt beim RaspiB3+ defaultmäßig 1:2.

MfG Kai
Zitieren
#68
O, Danke für die Info!
Ich denke mir das so: Nr. I sendet die Daten, bestehend aus Ziffern für das Zählwerk und Buchstaben als Befehlskürzel. Nr. 2 bereitet das entsprechend auf und sendet es aus, das OLED-Display ziegt es an. Nr. 1 geht nie auf Empfang und kann deshalb auch nicht gestört werden. Was passiert, wenn Nr. 2 mit seiner Ausgabe noch nicht fertig ist und Nr. 1 schon wieder auf Sendung geht, das weiß ich nicht und kann es auch nicht einschätzen. Denke, hier gilt: Versuch macht klug.

Was den I/O über USB betrifft, so ist der klar unterbrechbar. Ich sehe z.B., dass beim Senden der Daten an den PC keine Interrupts von den Motor-Sensoren verloren gehen, auch wenn die reine Anzeige am PC gelegentlich stockt. Wenn beim Umspulen etwa mit der Frequenz von
ca. 50 .. 55 Hz (Abwickelspule 35 und Aufwickelspule 20 U / sec) 7-stellige Zahlen einschließlich Kennbuchstaben und Leerstellen gesendet werden, ist das der Fall. Es zeigt sich aber, dass keinerlei Werte verloren gehen, das würde in der graf. Darstellung sofort auffallen.

Das dürfte erst dann problematisch werden, wenn der µP insgesamt überfordert wird. Ob das mit dieser Priorisierung nun tatsächlich an der I2C-Schnittstelle auch so funktioniert, weiß ich natürlich nicht.

MfG
Binse
Zitieren
#69
Hallo Tonbandfreunde,




nur mal ein kurzes Lebenszeichen über das Projekt - ich bin noch dran. Der Drahtverhau hat sich deutlich erweitert, hier ein Bild davon:



   



Es sind jetzt fast alle Pins des µP beschaltet, unten rechts sehen wir den Testaufbau für die Steuerung. Ich komme da mit lediglich 2 Pins aus - ein Poti wird mit "analogRead" ausgelesen, das Ergebnis auf den entsprechenden Befehl "gemappt", und bei Druck auf den Taster erfolgt die Übernahme des Befehls.
Außerdem gibt es noch Anschlüsse für eine Lichtschranke, die das Bandende erkennt, und natürlich für das OLED-Display.

Leider ist - warum auch immer - der 5-Volt-Spannungsregler auf dem Arduino kaputt gegangen. Das schränkt die "Treffsicherheit" des AD-Wandlers ein wenig ein, besonders beim letzten, mit der höchsten Spannung verknüpften Befehl. Die Spannung schwankt dann zwischen 4,66 Volt bei USB-Versorgung (läuft über eine Shottkydiode) und 4,3 Volt bei Versorgung über VIN (bei mir stabilisierte 9 V) Der Prozessor funktioniert aber trotzdem korrekt, es sind halt alle Schaltspannungen ein wenig zu niedrig. Die gesamte Stromaufnahme zwischen liegt zwischen 15 und 23 mA und damit im normalen Bereich.

Ich überlege jetzt, ob ich einfach mal externe 5 Volt über den 5-V-Ausgang des Arduino zuführe, oder eben doch einen neuen Nano da reinfummele, ist auch nicht besonders aufwendig.

Ansonsten: Guten Rutsch ins neu Jahr, wird ja dieses Jahr etwas ruhiger sein ...

Grüße, Binse
Zitieren
#70
Hallo Binse,

mein lieber Herr Gesangverein. Du bohrst ja keine dicken Bretter mehr. Du bohrst schon dicke Stämme.
Ich bewundere Deine Fähigkeiten im Umgang mit den logischen Baugruppen und deren Programmierung zur Beherrschung von Mechanik. Da bist Du ganz weit voraus.
Viel Glück für für Dich und Dein Projekt im Neuen Jahr

Mit den besten Grüßen

Manfred

und bleib schön gesund und coronanegativ
Zitieren
#71
Da schließe ich mich Manfred gern an.
Erstaunlich, was einige hier so drauf haben.
Das mit den Logik- Baugruppen ist irgendwie komplett an mir vorbei gegangen, leider auch Arduino und Co.

Dank Binse weiß ich aber jetzt wenigstens, was man damit u.a. anstellen kann.

LG
Mike
Zitieren
#72
Hallo Tonbandfreunde,

ich hoffe, Ihr seid alle gut im neuen Jahr angekommen. Erst mal vielen Dank an Mike und Manfred für die freundlichen Anmerkungen zu meinem Projekt!
Das ist wieder ein Stückchen voran gekommen.

   

Hier ist wieder die Steuerplatine noch einmal ausgebaut. Die Anpflanzungen mit den Steckerleisten links vom Arduino sind neu un dienen zum Anschluss eines Potis, eines Tasters, der Gabellichtschranke, der Geschwindigkeits-Umschaltung und des OLED-Displays. Bis auf das Display ist alles getestet und funktioniert.

   

Hier das Ganze von unten. Ich hatte ja weiter oben berichtet, dass der 5-Volt-Stabi auf dem Arduino kaputt gegangen ist. Mit dem Bypass von dem sowieso vorhandenem externen 5-V-Regler auf den eigentlich aus Ausgang gedachten 5-V-Pin (noch nicht mitfotografiert) funktioniert alles prima. So bin ich nochmal um den Austausch herumgekommen.

   

Auf der Rückseite wurde der ganze Kram angeklammert und getestet. Die Steuerung des Gerätes funktioniert jetzt auch ohne angeschlossenen Computer einwandfrei. Damit man weiß, was passieren wird; gibt es eine provisorische Skala. Der kleine Klick-Schalter hinter dem Poti dient zur Übernahme des eingestellten Befehls. Die Gabellichtschranke kommt in den Bandlauf und soll dann feststellen, wenn das Bandende ausläuft. Das Umschaltrelais für 19 / 9,5 ist noch nicht vorhanden, statt dessen zeigt die weiße LED den Zustand an. Bis jetzt ist dafür noch der alte manuelle Umschalter tätig. (Der Bandzug wird aber bereits entsprechend umgeschaltet.)

Die Software ist so weit und schon gut ausgetestet und auch optimiert. Wenn ich das ganze USB-Gedöns mit der Kontrolle  und Anzeige durch den PC ausschalte, gibt es wieder ordentlich Platz auf dem Ardu. Das wird vermutlich dann für die OLED-Ansteuerung reichen. Vorher werden ich evtl. noch weitere Reflektoren auf den Wickelmotoren anbringen und testen, ob der Ardu das vom Timing her "schafft". Die Software würde dadurch nicht komplizierter werden, nur ein paar Konstanten sind entsprechend zu ändern. Denn mehr Stützpunkte für die Bandzug-Regelung können nur gut sein. Vor allem der Zeitpunkt, wenn das Band nach dem Umspulen abgebremst ist und still steht, ließe sich dann viel genauer ermitteln, somit auch genauer die mechanische Feststellbremse setzen. Jetzt kann es noch kleine Schlaufen geben, wenn fast volle gegen fast leere Spule stehen. Bei einem anschließenden "Play" ohne händische Bandstraffung macht die Regelung dann komische Dinge. Auch ohne Schlaufen  wäre dann beim Start von "Play" der  Einschwingvorgang viel kürzer.
Danach geht es dann auf der Vorderseite weiter: Einbau des ganzen Krams, Ausrichtung der Köpfe, Gestaltung der Front, alles kann ja nicht offen bleiben. Vom Nf-Teil ganz zu schweigen, es gibt schon noch etwas zu tun. Solange das Interesse anhält, halte ich Euch auf dem Laufenden!

MfG, Binse
Zitieren
#73
Hallo liebe Tonbandfreunde,

hiermit melde ich mich mal wieder zu Wort und zitier mich gleich selbst:

Zitat:Wenn ich das ganze USB-Gedöns mit der Kontrolle  und Anzeige durch den PC ausschalte, gibt es wieder ordentlich Platz auf dem Ardu. Das wird vermutlich dann für die OLED-Ansteuerung reichen.

Ja, es passt schon, aber vorher hat mich der Compiler häufig mit Meldungen erfreut wie etwa diese: "105 % des Speicherplatzes für Daten sind belegt. Sie haben noch -5% frei ..."

Da habe ich erbittert um jedes Byte gekämpft. Z.B. endlos viele Zeichensätze für das Display ausprobiert. Und es gibt schier unendlich viele Fonts in noch mehr Varianten für das 126X64-OLED-Display. So braucht die "Times" bedeutend mehr Platz als die "Helvetica". Befremdlich ist auch, dass die setCursor(x,y)-Anweisung nicht nach Display-Punkten, sondern nach anderen, undurchsichtigen, vielleicht nach den Schriftgrößen ausgerichteten Punkten geht. Reines Try-and-Error-Programmieren. Auch der C++ Compiler der IDE ist für Überraschungen gut: So brachte die Auflösung der - an sich sehr eleganten - "switch-case"-Anweisung für die Decodierung der Kommando-Eingabe in eine Kette von IF-Anweisungen ordentlich viel Speicherplatz. Und dann gab es natürlich auch noch diverse selbstverschuldete Problemchen. So ist man ja gewöhnt, dass Tippfehler einem vom Compiler sofort schön rot umrandet oder wie auch immer unter die Nase gehalten werden. Und dann war da alles einwandfrei kompiliert, ein logischer Fehler im Programmablauf ebenfalls absolut auszuschließen und es funktionierte trotzdem nicht. Bis ich endlich auf den Trichter kam, dass hier ein Tippfehler in der Anweisung für die bedingte Compilierung vorlag, und diese KANN der Compiler nicht finden, da er gar nichts damit zu tun hat. Das macht der Präprozessor vorher ab, und es ist im Grunde reine Textverarbeitung.

So, nun genug Programmierer-Chinesisch. Also, es funktioniert nach Wunsch. Man dreht am Poti (Stufenschalter wäre auch möglich, aber ein schön leichtgängiges Drehknöpfchen hat schon auch was) und drückt kurz aufs schwarze Knöpfchen, um den eingestellten Befehl abzurufen. Wenn das Band gerade steht, tut er es gleich, anssonsten wird erst mal gebremst. und er erwartet noch einen weiteren Klick, um loszulegen. Zählwerk-Reset und Geschwindigkeits-Umschaltung funktionieren auch beim laufendem Band.

Ja, das ist der Stand. Ich habe ein kleines Mini-Filmchen davon gedreht und auf meine HP gestellt. Dort könnt Ihr es angucken und auch sehen, dass einiges an Arbeit noch vor mir steht. Ich werde den Videoclip trotz seiner Kürze nach einiger Zeit wieder von meiner Seite nehmen, aus den gleich Gründen wie beim letzten mal.

http://www.jodre.de/band_video2/index.html

Bis dahin viel Spaß und alles Gute, und Danke für Eure Aufmerksamkeit,

freundliche Grüße, Binse
Zitieren
#74
Hallo Binse,

es ist für mich immer wieder beeindruckend, was Du hier programmiertechnisch auf die Beine stellst.
Und dann wollte ich Dir noch ein lang anhaltendes Interesse signalisieren.
Ich würde mich weiterhin sehr freuen, wenn Du uns hier immer auf dem Laufenden hältst.

Die Besucherzahlen für Deine Beiträge in diesem Thema sind ja auch ein eindeutiger Beleg.

Ich wünsche Dir weiterhin gutes Gelingen und bleibe sehr neugierig.

Mit den besten Grüßen

Manfred
Zitieren
#75
Liebe Tonbandfreunde,

erstmal Dank an Manfred für den ermutigenden Beitrag - das ist jetzt schon wieder 'ne Weile her, aber eigentlich wollte ich ja gleich weiterschreiben, und dann sollte aber auch neues zu berichten sein ...
... aber auch wenn ich nicht wirklich am Projekt sehr viel weiter gekommen bin, so will ich mich doch mal wieder melden. Steht halt viel Fummelei jetzt an, und diese Gehäusebauerei ist auch nicht mehr ganz so spannend wie das Vorhergende.

Zunächst habe ich die Bedienelemente vorn draufgepflanzt. Irgendwo mussten sie ja hin. Zunächst musste aber das Display in ein Gehäuse. Man glaubt gar nicht, wieviel Zeit drauf geht, so etwas herzustellen.

   

Das Poti wurde schräg darunter gepflanzt. Darunter befindet sich die Lichtschranke für die Bandende-Erkennung und Abschaltung. Der kleine schwarze Druckknopf mit rotem Ring auf der unteren Schiene ist für die Kommandoübernahme.

   

Ich habe die Teile ein wenig hin und her geschoben, habe auch mal dieses oder jenes wieder zurückgebaut in der Hoffnung, ein halbwegs ansprechendes Design hin zu bekommen, aber so groß waren die Möglichkeiten gar nicht. Wenn die Hand beispielsweise am Drehknopf ist, will man ja beispielsweise nicht damit das Display verdecken. 

Man stellt am Display die gewünschte Funktion ein und übernimmt diese dann mit dem Klick-Schalterchen. Wenn das keinen Sinn macht (z.B. Umspulen -> Play) dann geht das Gerät in den passenden Bremsmodus. Am rechten und linken Rand sieht man bereits den Anfang der "Beplankung", denn das Gerät soll auch so etwas wie ein Gehäuse bekommen.

   

Oben habe ich, sozusagen als Anprobe,  mal das Lochblech-Material und einen Griff gelegt, was dann für einen oberen Abschluss und eine Tragemöglichkeit sorgen wird. Die Lochbleche sollten wohl ursprünglich, bevor sie der Pollin verramscht hat, als Lautsprecherabdeckung verwendet werden. Das ist ziemlich zähes und hartes Stahlblech, Blechschere ist nicht, man muss es mit einer kleinen Trennscheibe zerteilen. Wie man sieht, wartet da so noch einiges an Bastelei auf mic

MfG,

Binse
Zitieren
#76
Wenn das ohnehin alles digital ist, kann man die Bedienelemente, wie bei der Nagra T-Audio, auch auslagern. Bei der TA sind Bandgerät und Bedienelemente nur über einen (zwei) SUB-D Stecker miteinander verbunden.
Gerhard
Zitieren
#77
(15.02.2021, 10:53)Sonicman schrieb: ... kann man die Bedienelemente ... auch auslagern.
Ja, Gerhard, das habe ich mir auch überlegt. Andrerseits gähnte rechts neben der Tonwelle (aufgrund der ursprünglichen Planungen) so ein Loch. Das ist nun wenigstens etwas gefüllt. Für den Nf-Teil werden die Bedienelemente aber jedenfalls extern sein.
MfG, Binse
Zitieren
#78
Da könnte vielleicht eine Anzeige oder VU Meter hin und die komplette Bedienung dann extern. Aus ergonomischen Gründen würde ich Teile der Bedienung nicht auf verschiedene Orte verteilen.
Gerhard
Zitieren
#79
Ich lese hier interessiert mit, kann aber fachlich nichts dazu beitragen.
Eine Idee zum Bedienteil:
So eine Art "Wireless-Tastatur. Das Bedienfeld hat seinen Platz am Gerät und ist dort gut aufgehoben. Bei Bedarf kann es entnommen werden und zum Arbeitsplatz mitgenommen, das Gerät so fernbedient werden .

Gruß Gerald
Zitieren
#80
Ja, wenn man so beim "Brainsorming" ist - es gibt auch für kleines Geld fertige Fernbedienungs-Module, die sich auch mit demArduino verbinden lassen. Ja, was man so alles machen kann ist schon enorm.

Erst mal steht aber noch ein Versuch an, auf den Wickelmotoren jeweils einen weiteren Reflektor anzubringen und schauen, ob der µProzessor das noch "verkraftet". Die Einregelzeit beim Start würde sich dann verbessern, ebenso der Zeitpunkt für das Fallen der mechanischen Bremse bei Stop aus Schnellauf. Ich glaube, da ist noch Luft drin. Das Band stoppt zwar schlaufenfrei aus dem Umspulen heraus, kann dabei aber noch ein Stück in die jeweils andere Richtung laufen, je nach dem Verhältnis der Wickeldurchmesser. (Wickelmotoren, die mit DC bremsen, wären da leichter zu handhaben - das tun diese nun mal aber nicht. Bzw. so schwach, dass das bei vernünftigem Aufwand kaum nutzbar ist.

MfG, Binse
Zitieren
#81
Hallo Tonbandfreunde,

will mich mal wieder mit ein paar kleinen Neuigkeiten melden. Ich habe unter anderem getestet, durch höhere Abtastrate (2 Reflektoren an jedem Wickelmotor anstatt einem) eine feinere Auflösung und damit eine schnellere Einstellung beim Bandstart (Einschwingverhalten) zu erreichen, was nicht gelungen ist. Der µP schafft es einfach nicht. Eventuell findet Ihr die Ergebnisse jedenfalls interessant, jedenfalls bringe ich drei Aufzeichnungen, wieder mit Gnuplot, von meinen Versuchen.

   

Erläuterung: Hier wurde das Band zwei mal vor- und zurück gespult, einmal auf die sanfte, das zweite mal auf die schnelle Tour. Jeder Reflektor-Impuls sollte den Bandlängenzähler hochsezten, dieses wird über den seriellen Monitor an den PC gemeldet und aufgezeichnet. Somit sollte sich eine simple Gerade mit der Steigung 1 ergeben, bzw. beim Rückwärtslauf von -1. Wie man sieht, funktioniert das auch beim "langsamen Schnell-Lauf" einwandfrei (dass es trotzdem nicht stimmt, sehen wir später). Das kleine "Dach" beim "Fast Lauf" rührt daher, dass mir das Band von der Spule gelaufen ist und der Zähler natürlich weiter zählt, bis die Lichtschranke die mech. Bremse ausgelöst hat.

Beim "schnellen Schnell-Lauf" wird am Schluss des Rücklaufs die vermeintliche Gerade ein wenig "krumm" gebogen - irgend etwas kommt nicht mehr mit. Schauen wir uns das im Detail an:

   

Wir sehen, dass gelegentlich zwar weitere Umdrehungsimpulse gesendet werden, der Zähler aber nicht dazu kommt, weitererzählen, d.h. es werden schlicht Impulse übersprungen.

Ich habe dann mal Schieblehre (Wickelkern), Lineal (Außendurchmesser) und Mikrometerschraube (Banddicke) hergenommen und festgestellt, dass es 1554 Windungen auf der vollen Spule sein sollten. Da ja nun jede Umdrehung 4 Impulse produziert, sollte der Wert eigentlich deutlich über 6000 liegen! Tatsächlich liegen wir aber bei ca. 3/4, also 4500!

Bei nur zwei Reflektoren, also einem pro Motor wie vorher, bekomme ich bei einem vollen Durchgang die Anzeige von 3220, was ich als gute Näherung an die Messungen mit Lineal usw. sehe.

Da nun aber der Messaufbau schon mal stand, habe ich auch die gemeldeten Umdrehungszeiten bzw. die Zeiten zwischen den Impulsen aufgezeichnet. Als Plot, jeweils für den linken und den rechten Motor, sieht das so aus (Ausschnitt):

   

Oben sind erst einmal in lila und grün die Darstellung für "slow L und slow R". Es fällt auf, dass L (lila) eine relativ stetige Linie ergibt, während R (grün) ein gleichmäßiges Zick-Zack-Muster zeigt. Das rührt vermutlich daher, dass es mir hier nicht so gut gelungen ist, die Reflektormarke im halben Umfang anzubringen.

Auch die Linie für "fast L" ist wieder ziemlich gleichmäßig. Ich vermute, dass kommt daher, dass die Interrupt-Auswertung im Programmablauf VORHER erledigt wird. Die Bearbeitung von "fast R" ist dann völlig unzuverlässig und passiert mit großen Sprüngen. Dazu passt auch ganz gut, dass der Gesamtsumme 1/4 der Impulse fehlt - diese kann eben nicht mehr verarbeitet werden, obwohl der Interrupt stattfindet, der wird ja auch vorrangig bedient.

Zum Glück hatte ich die neuen Reflektoren nur provisorisch angebracht, somit ließen sie sich auch leicht wieder entfernen.

   

Im Grunde ist das kein großer Verlust, denn die reine Bandzugberechnung und damit der Gleichlauf wird davon nicht betroffen. Im Gegenteil, wenn die Impulse wegen schlechter Verteilung der Marken ungleichmäßig kommen, könnte er sich sogar verschlechtern.

Nun braucht das Gerätchen auch so etwas wie eine geschlossene Front. Also habe ich ein paar Leisten mit 2K-Kleber aufgeklebt, die dann "beplankt" werden sollen. Maßnehmen mit Pappschablonen. Den mittleren Teil habe ich schon fertig gestellt, oben mit Lochblech zwecks Belüftung. Also noch ein paar Bildchen zu diesem Thema:

   
   
   


MfG
Binse
Zitieren
#82
Kann das sein, daß Deine ISR länger braucht als der zeitliche Abstand zweier Interrupts ?
Gruß, Kuni
..............................

http://kuni.bplaced.net/
..............................
Zitieren
#83
Bei mir werkelt in einet M15A Fernsteuerung ein Arduino Nano, der pro Sekunde 32 Impulse bekommt.


// Interruptroutine, die bei jedem Zählimpuls aufgerufen wird
void pulse() {
  if (digitalRead(4)) t++; else t--;
  if ((t & 0x1f) == 0) show = true;
}


Am Pin 4 liegt die Richtung an. Da nur jede volle Sekunde angezeigt werden soll, wird show nur bei jedem 32. Impuls auf true gesetzt.
Diese kleine Routine zählt auch bei schnellem Vorlauf/Rücklauf exakt.
Viele Grüße
Eckhard

M15A; Revox A700, B77, A76, A77, A78; Braun TG1000; Uher 4400 Report Stereo IC; www.engelstrasse.de
Zitieren
#84
Vielen Dank für Eure Antworten!

@Kuni:
Ich denke, dass nicht die ISR selber der begrenzende Faktor ist. Die ist auch so kurz wie möglich. Man sieht es auch daran, dass gelegentlich, wenn es knapp wird, zwei mal hintereinander der gleiche Zählerstand angezeigt wird. Es wird also das Intr.Signal selber bearbeitet, die eigentliche Bearbeitung in der Hauptschleife kommt nicht mit.

@Eckhard:
Deine Lösung ist noch kürzer, freilich: dort muss nur gezählt werden. Bei mir müssen zusätzlich die micros() für die Berechnung der Umlaufzeit gespeichert werden. Ich hatte auch die Idee, das zu trennen und die Anzeige zu verlangsamen, bzw nur jeden 4. Wert anzuzeigen. Vielleicht könnte das klappen, ohne dass die Berechnung des Banzuges leidet, ist aber mit Sicherheit eine ziemlich aufwendige Fummelei. Ich zeige mal meine ISR, sie ist zwei mal vorhanden und belegt die beiden externen Interrupts 0 u. 1.
________
void isr_motL () {    // Isr linker Wickelmotor, Aufruf durch Int0
  t_neu[links] = micros();
  isr_was[links] = true;
  u_count += u_incr;
  ++ u_sig [links];
} // ENDE isr_motL
___________
Die bool. Variable signalisiert der Hauptschleife, dass hier was zu verarbeiten angefallen ist.
Die Variable u_incr ist natürlich je nach Drehrichtung +1 oder -1.
Der zusätzliche Zähler u_sig wird nur für den Startvorgang benötigt. Er ermöglicht es, das 1. Signal zu verwerfen. Das ist nötig, da die Reflektormarke zufällig entweder fast sofort oder auch erst nach einer knappen vollen Umdrehung "vorbei kommen" kann, was zu komischen Reaktionen der Regelelektronik führen kann ...
Das Ganze ist mit der Nummer entweder des linken oder des rechten Motors indiziert, damit es hinterher in einer kleinen Schleife abgearbeitet werden kann. Vermutlich würde es Laufzeit bringen, diese Schleife innerhalb der Main-loop "abzuwickeln", d.h. die gleiche Routine 2x hinzuschreiben, dann eben nicht mit indizierten, sondern fest benannten Variablen. Ich vermute aber sehr stark, das dieser Laufzeitgewinn gegenüber den Zeiten, die entweder im "seriellen Monitor" oder aber in der Streuerung des OLED-Displays verbraten werden, völlig bedeutungslos wäre.

Übrigens, falls Jemand das ganze Programm sehen möchte - ich hätte nichts dagegen es hier anzuhängen, dachte nur bisher, dass es kaum auf allgemeines Interesse stoßen wird. Also, wenn Interesse, bitte anfragen.

MfG, Binse
Zitieren
#85
Verwende in der A700 einen Arduino Nano der pro 10cm Band etwa 6 Impulse via Interrupt verarbeitet. Selbst bei schnellem Vor- und Rücklauf keine Falschzählung.
Der Fehler muss bei Dir woanders liegen. Selbst eine rotierende Festplatte mit 5400 Umdrehungen bestückt mit 2 Segmenten wird einwandfrei ausgelesen.
Bei den nächsten Wahlen wähle ich die NSA, denn die sind die einzigen die sich um mich kümmern.
Zitieren
#86
(28.02.2021, 13:44)arricchito schrieb: Verwende in der A700 einen Arduino Nano der pro 10cm Band etwa 6 Impulse via Interrupt verarbeitet.

OK- das sind überzeugende Werte. Müsste dann zunächst mal die Sensorwerte selbst untersuchen - relativ hochohmige Fototransistoren sind ja oft erstaunlich langsam. (obwohl ich diesbezüglich vorher schon rein überschlägige Tests gemacht habe. Aber eine kleine Frage noch: ist denn Dein Arduino Nano auch noch für die Anzeige via Display oder den seriellen IN- und Output über den USB-Anschluss zuständig?
Zitieren
#87
Hallo
Messe doch zunächst mal die Eingangsimpulse für den Arduino.
Wir verwenden ja die gleiche Reflexlichtschranke.
Bei mir waren die Impulse ohne Nachbearbeitung nicht verwendbar.

Gruß Mani
Besonders gerne repariere ich meine Philips, Braun, Akai und TEAC Geräte Big Grin
Keine Hilfe bei fehlender Rückmeldung
Zitieren
#88
(28.02.2021, 14:31)Selbstbauer schrieb:
(28.02.2021, 13:44)arricchito schrieb: Verwende in der A700 einen Arduino Nano der pro 10cm Band etwa 6 Impulse via Interrupt verarbeitet.

OK- das sind überzeugende Werte. Müsste dann zunächst mal die Sensorwerte selbst untersuchen - relativ hochohmige Fototransistoren sind ja oft erstaunlich langsam. (obwohl ich diesbezüglich vorher schon rein überschlägige Tests gemacht habe. Aber eine kleine Frage noch: ist denn Dein Arduino Nano auch noch für die Anzeige via Display oder den seriellen IN- und Output über den USB-Anschluss zuständig?

Ja! Selbiger betreibt ein umschaltbares OLED-Display (Zähler, Meter, Bandlaufzeit bei gewählter Geschwindigkeit). Zeigt zusätzlich noch beim Speed-Umschalten kurz die Geschwindigkeit an. Helligkeit einstellbar.  Nichtflüchtiger Speicher der Zählerstände und Parameter. Elaps Time beim Einschalten.
Vielleicht mache ich heute noch ein kurzes Video>!
Als Lichtschranke komt sowas zur Anwendung: https://www.pololu.com/product/4202


Angehängte Dateien Thumbnail(s)
   
Bei den nächsten Wahlen wähle ich die NSA, denn die sind die einzigen die sich um mich kümmern.
Zitieren
#89
Binse, Du kannst doch der Einfachheit halber mal Deinem uC das Signal von einem Signalgenerator zuführen.
Damit mal sicherstellen ob das Problem aus Deiner SW oder aus der Signalqualität rührt.
Ohne den Arduino zu kennen, aber so'n paar kHz sollten da eigentlich problemlos zu verarbeiten sein - so langsam wird der ja vermutlich auch nicht getaktet.

Ich sehe nicht mit welchen Typen Du in der ISR arbeitest. Am schnellsten sind uC's ja mit nativen Datentypen entsprechend der internen Bitbreite. Evtl. kannst Du die Ausführungszeit der ISR damit noch beschleunigen.

Ist die Hauptschleife zu langsam, dann solltest Du evtl ein Mini OS einbauen, bei dem in einem festen Zeitraster Tasks laufen können um damit sicherzustellen, daß die Ergebnisse aus der ISR bearbeitet sind, bevor der nächste Interrupt kommt.
DU kannst damit zeitkritisches von zeitlich unkritischem entkoppeln.
Gruß, Kuni
..............................

http://kuni.bplaced.net/
..............................
Zitieren
#90
Hi,
Danke für Eure Hinweise und Einwände, sie veranlassen mich zumindest, die Geschichte nochmal zu überprüfen.

Dazu habe ich zunächst mal eine Test-Lichtschranke aufgebaut, mit den gleichen Bauteilen und Materialien wie an den Wickelmotoren (Die LS: 12V UBetrieb, Vor-R LED: 2,2 kOhm, Kollektor Fototransistor 15 kOhm) Im Gerät selber ist dann noch eine Diode zur Begrenzung, um die Eingänge des µP zu entlasten, das kann ich aber beim Testen vernachlässigen.

So sieht das aus:
   
(Das ist der erste "echte" Einsatz meines neuen "Spielzeugs", eines Batterie-Speicher-O'scopes mit Tuchscreen) Es war einfacher so als am Bandgerät zu testen. Jedenfalls sieht man, dass die LS bei 23 Hz voll durchschaltet.

Und auch bei fast 10-facher Drehzahl tut sie das noch:
    (das Scope kann auch Screenshots)
Dieser Tage werde ich mal einen Test-Arduino anschließen und schauen, was passiert und was man machen kann.

MfG, Binse
Zitieren
#91
Du musst mit der richtigen Lastimpedanz testen. So geht das nicht.
Mit dem 10Mohm Tastkopf sieht alles gut aus.

Gruß Mani
Besonders gerne repariere ich meine Philips, Braun, Akai und TEAC Geräte Big Grin
Keine Hilfe bei fehlender Rückmeldung
Zitieren
#92
Doch, ist schon richtig. Der Arduino-Eingang ist sehr hochohmig, und die paar pF der Begrenzerdiode und der (abgeschirmten) Zuleitung fallen bei 20 .. 200 Hz auch nicht ins Gewicht. Selbst wenn das Signal etwas verschliffen wird - die Eingänge haben Trigger-Eigenschaften und schalten bei 1/3 u. 2/3 UB - das wird die Qellimpedanz auf jeden Fall schaffen!

Grüße, Binse
Zitieren
#93
Hallo Binse,

(28.02.2021, 10:18)Selbstbauer schrieb: Übrigens, falls Jemand das ganze Programm sehen möchte - ich hätte nichts dagegen es hier anzuhängen, dachte nur bisher, dass es kaum auf allgemeines Interesse stoßen wird. Also, wenn Interesse, bitte anfragen.

das würde mich schon interessieren - auch wenn ich nicht vorhabe, das gleich nachzubauen, wäre es interessant, sich einmal durchzudenken. Falls Du also nichts dagegen hast - immer gerne Smile. Du kannst es ja auch mit einer passenden Open Source-Lizenz versehen, wenn Du sicherstellen willst, dass darauf aufbauende Arbeit wieder öffentlich gemacht wird.

Viele Grüße
Andreas
Zitieren
#94
Hi Andreas,
danke für Dein Interesse, ja,  ich hänge den IST-Zustand des Programms (voll funktionsfähig) als Attatchment an. Musste es als Text umbenennen, da die Forumssoftware kein *.ino will, also in tb_steu-ino.txt umbenannt. Und einen Open-Source-Header habe ich auch oben drüber geklemmt.

Grüße, Binse


Angehängte Dateien
.txt   tb_steu-ino.txt (Größe: 16.65 KB / Downloads: 21)
Zitieren
#95
Hallo,

in dem Programm habe ich "auf die Schnelle" nicht entdeckt, wo Interrupts enabled und disabled werden.
Hast du daran gedacht, daß es allerlei Probleme geben kann, wenn man beim Zugriff auf Variable zB im Hauptprogramm, die von Interrupt-Routinen verändert werden (können), Interrupts nicht temporär disabled ?

MfG Kai
Zitieren
#96
Hallo Kai,

--- nö, habe ich nicht -

Danke für den Hinweis!!

Wenn genau bei der Verarbeitung der in der ISR gesetzten Werte (also hier vor allem der aktuellen "micros") diese sich ändern, da könnte schon allerhand Kuddelmuddel entstehen. Ich werde das dann doch wirklich mal mit Tongenerator-Input testen, wie hoch ich gegebenenfalls mit der Sensor-Frequenz gehen kann.

Die Bedienungstaste u. -Poti wird ja nun per Polling in der Main-loop abgefragt, deshalb muss im Gesamtablauf auch immer genug "Luft" bleiben.

MfG Binse
Zitieren
#97
Liebe Tonbandfreunde,

hier mal wieder ein paar Meldungen vom Selbstbau

1. Das Gerät hat so etwas wie ein Gesicht bekommen

Die Vorderseite wurde "beplankt". Eine größere Menge kleinerer Teile mussten ausgeschnitten, gesägt, befeilt, beschliffen, gebohrt und festgeschraubt werden, damit eine einigermaßen geschlossene Front entsteht, wobei auch die verschiedenen Ebenen irgendwie miteinander verbunden werden mussten. Am Drehknopf stellt man, wie schon in vorherigen Beiträgen beschrieben, die Funktion ein, der Knopf unten ist so etwas wie die "Enter-Taste". Sie hat ein unverfehlbares rotes Häubchen bekommen.

   

Das rote Deckelchen dazwischen sitzt auf einem Stück schwarzen Iso-Schlauch. Damit kann man die Lichtschranke schließen. Nur so ist es möglich, das Laufwerk auch ohne Band einzuschalten, was nicht nur für Fotos im Leerlauf gut ist sondern vor allem ganz praktisch beim Einlegen von Bändern oder auch beim Abspielen von Bändern mit Fehlstellen ist, bei denen sich sonst der Bandtransport unvermittelt ausschaltet.  Wichtig ist es auch beim Einlegen bei Bändern mit rotem Vorspannband. Ich musste feststellen, dass die Lichtschranke dort anspringt, offensichtlich geht das IR da hindurch wie durch Butter.

   

Hier sehen wir das Gerät von oben, mit dem neuen Tragegriff. Man hat immer Skrupel, mit der Bohrmaschine an solch einen an sich fertigen Aufbau zu arbeiten, aber ein stabiler Griff ist nun mal unverzichtbar. Ich nehme an, dass ich für die Seitenteile und das  "Dach" (wo dann auch wieder das Lochblech verwendet wird, welches wohl ursprünglich für Lautsprecherabdeckungen gedacht war), dass ich dafür dann weniger Zeit benötigen werde - nur gerade, rechtwinklige Flächen.

2. Die Geschwindigkeit der Reflektor-Lichtschranken

   

Zuerst habe ich untersucht, ob diese Lichtschranken an den Wickelmotoren eventuell selber ein begrenzender Faktor bei der Umdrehungsimpuls-Zählung durch den Arduino darstellen. Das Resultat ist ein klares Nein: Bei meinem Versuchsaufbaus sind locker 240 Hz drin, mehr gab das Motörchen nicht her, aber das ist schon weit mehr als die Wicklemotoren erreichen. Und die Impulse sind noch in voller Amplitude vorhanden (für den Arduino-Eingang werden sie durch eine Diode auf 5V begrenzt) Es zeigt sich auch, dass bei der gewählten Schaltung keinerlei Nachbearbeitung nötig ist, die Arduino-Eingänge haben ja selber Schmitt-Trigger-Eigenschaften.

   

3. Geschwindigkeit der Software

   

Hierzu wurden an die beiden Interrupt-Eingänge je ein Tongenerator angeschlossen und mithilfe der aktuellen Software untersucht, wie "hoch" man das Ganze drehen kann. Es zeigte sich - was eigentlich zu erwarten war - dass es ziemlich egal ist, in welchem Frequenzverhältnis die beiden Interrupts "befeuert" werden, und dass die Summe der beiden Frequenzen entscheidend ist. Mit einem Reflektor kommen im Gerät (schnelles Umspulen, ziehend: fast voller Wickel, gezogen: fast leerer Wickel) maximal knapp 35 Hz + 15 Hz vor. Bei den Tests war bei etwa 87 Hz (f1 + f2) Schluss. Klarerweise gibt es dann bei zwei Reflektoren pro Motor schon Schwierigkeiten. Die Tests zeigen bei dann, wie die gemeldete Periodendauer sich plötzlich verdoppelt, d.h. der jeweils nächste Interrupts wird schon ausgeführt, während die Zeitdauer des vorherigen noch gar nicht verarbeitet wurde. Das kann man auch recht gut auf dem "seriellen Plotter" der Arduino-IDE beobachten, genauer und wesentlich besser geht es dann wieder mit "gnuplot". (Aber eben nicht so einfach in "real time")

Ich denke, dass ich durch einige Änderungen und Optimierungen das mit den 2 Reflektoren hinbekomme, beispielsweise - entgegen der "reinen Lehre" für die ISR-Programmierung - etwas mehr an Berechnungen in den ISRs selber tun, die dann nicht mehr verfälscht werden können. Während es völlig egal ist, wenn diese - sowieso meist gleichen oder nur sehr gering geänderten - Werte ein paar msec später bei den Motoren ankommen. Ich wollte aber jetzt erst mal sichtbar weiter kommen.

4. Einstellungen und Fehlersuche.

Relativ zeitaufwendig habe ich dann die Bandzugeinstellungen für 19 u. 9,5 verfeinert. So können sie jetzt bleiben. Ein Problemchen war die Einstellung für 9,5. Irritierenderweise funktionierte die manuelle Einstellung der Motoren für 9,5 korrekt, während die Berechnung der Werte dazu führte, dass die Regelung völlig "ausflippte". Obwohl da die selbe Formel wie für die 19er Bandgeschwindigkeit arbeitet. Wie das? Nach längerer Suche fand ich endlich einen Integer-Überlauf, der nur bei den Parametern für 9,5 auftritt. Ziemlich dumm, weil da sogar eine Compiler-Warnung existierte, die aber infolge der etwas bescheuerten Grundeinstellung der Fenster der Arduino-IDE immer schön unsichtbar blieb...

MfG
Binse
Zitieren
#98
Hallo Tonbandfreunde,

ich danke Euch für das Interesse, das sich auch im Aufrufzähler anzeigt. Jetzt geht es mal ein Stückchen weiter, endlich habe ich mal den Drahtverhau mit Kabelbindern und Spiralschlauch verpackt, um Platz für die Nf-Platinen zu schaffen, ein Platinenhalter dafür wurde auch schon zusammen gezimmert.
   
Logischerweise kommt als nächstes der Wiedergabe-Verstärker dran. Ich habe zwar diverse Schaltbilder, meist mit Einzeltransistoren, angeschaut und versucht, so etwas wie ein durchschnittliches "Rezept" oder auch Konzept zu erkennen. Es ist nicht einfach und manchmal auch unmöglich, die oft verwirrend gezeichneten Stromlaufplänen mit -zig Schaltern und Konnektoren zu entwirren. Am schlichtesten scheint mir dieses Applikations-Beispiel zu sein. Ich habe mal versucht, das auf einen moderneren, symm. versorgten OpAmp umzusetzen, weiß aber nicht recht, ob das so stimmen könnte. Die Schaltung ist natürlich, z.B. weil Angaben zur Tonkopf-Induktivität fehlen, nicht besonders aussagefähig. Hier werde ich wohl - solange ich keine Bänder mit z.B. korrekt vorverzerrten Frequenz-Sweep bei verschiedenen Pegeln habe, erst mal rein nach Gehör und den vorhandenen Bänder vorgehen müssen. Ich denke, wenn ich so eine Art von ungefähr durchschnittlicher Entzerrung hinbekomme, dann kann ich den Rest je nach Band und Aufnahme mit einem Equalizer erledigen. Auf der Platine werde ich die entsprechenden RC-Netzwerke über Stecker anschließen, so dass sie leicht austauschbar sind.
   
Als IC käme wohl auch z.B. der TL081 mit J-Fet-Eingängen in Frage, aber wozu. Ich vermute mal, dass das Rauschen im Verhältnis zum Bandrauschen eine ziemlich untergeordnete Rolle spielt. Also, wenn sich jemand zu der Problematik "Wiedergabeverstärker" äußern möchte - Tipps oder evtl. auch Links auf entsprechende Verstärkerschaltungen werden gerne angenommen!

MfG

Binse
Zitieren
#99
Moin Binse,

ich lese hier schon lange interessiert mit. So ein Selbstbau würde mich auch reizen und vor der Elektronik wäre mir nicht bange. Aber deine Mechanik-Künste kann ich nur bewundern. Da würde mir wahrscheinlich irgendwann die Geduld ausgehen.

Ein Wiedergabeverstärker ist noch gut überschaubar. Die Rauschproblematik liegt etwa in der Größenordnung von MM-Phonoverstärkern: nicht wirklich schlimm aber auch nicht ganz ohne. Ein TL081 wird wohl doch noch hörbar was zum Bandrauschen dazugeben. Wenn man sich z.B. bei ICs umschaut, die auch gern für Phonoverstärker genommen werden, liegt man schon mal ganz richtig. Der NE5532 auf deinem Zettel ist da schon eine deutlich bessere Wahl. Bei dem Aufwand, den du treibst, würde ich mir einen LT 1028 gönnen. Der kostet bei r... zwar > 11 € pro Stück (als Einzel-OpAmp). Sein großer Vorteil aber ist, dass er auch geringes Funkelrauschen garantiert. Bei Standard - OpAmps führt das zu einem starken Rauschanstieg bei Frequenzen unter etwa 300 Hz. "Wer an sich selber spart, ist geizig."

Zur Entzerrung:
Die teilt sich in zwei Bereiche auf:

Der erste ist die Entzerrung des Normfrequenzgangs. Die kann man nach Lehrbuch bauen, das verhält sich korrekt nach der reinen Theorie, da muss und sollte man nichts probieren.

Der zweite ist die Kompensation der Verluste des Band-Kopf-Systems. Das hängt nur minimal vom Band ab, aber entscheidend vom Tonkopf.

Zum Ersten:
Das wird mit einfachen RC-Gliedern gemacht. Für 9,5 cm/s und NAB 19 cm/s sind 3180µs (50Hz) zu kompensieren und dann noch 90 µs für 9,5 bzw. 50 µs für 19. dazu reicht ein Schalter (S1 geschlossen bei 19). Im Bild macht das das RC-Netzwerk in der OpAmp - Gegenkopplung. (Die Widerstandswerte sind die theoretisch optimalen. Der nächst passende aus der E48-Reihe tut es auf jeden Fall.)

   

Zum Zweiten:
Hier braucht man was steileres. Das Bild zeigt, wie das in der B77 gemacht ist: Mit einem Resonanzkreis mit der Tonkopf - Induktivität. Der Parallel - C bestimmt die Resonanzfrequenz, der Parallel - R die Güte (d. h. die Breite der Resonanz). Bei anderen Herstellern findet man dazu z.B. einen LC - Saugkreis in der Gegenkopplung. Aber ohne was LC - mäßiges wirst du nicht auskommen (Natürlich gehen auch aktive RC- Filter, aber wirklich einfacher ist das auch nicht).
Was hast du denn für einen Tonkopf, in welchem Gerät wurde der eingesetzt? Ein Blick in die Original - Schaltung könnte da helfen.

So weit erst mal.

Liebe Grüße
Frank
In Rust We Trust!
T e s l a  B 1 1 6 (A.D.),  R E V O X  B 7 7
Zitieren
Hallo,

der LT1028 ist für nieder-ohmige Quellen optimiert.
Den Charts des Datenblatts kann man entnehmen, daß minimales Rauschen bei einer Quell-Impedanz um 300 Ohm erreicht wird.
Der Rausch-Strom ist relativ groß.( 1... 1.5 pA/Wurzel(Hz)). Damit liegt das Verhältnis von Rausch-Spannung zu Rausch-Strom bei en/in ~ 850 ... 1000 Ohm.
Ein Wiedergabekopf mit 270 mH hat bei 1 kHz ~ 1.7 kOhm, 3 kHz ~ 5.1 kOhm, 10 kHz ~ 17 kOhm.
Das paßt also nicht recht zusammen.
Man muß sich natürlich die Rauschspannung (bzw das Spektrum) nach Entzerrung ansehen und minimieren.
Der LT1028 ist aber in dieser Anwendung sicher sub-optimal.
Sein "Differential Mode Input Resistance" beträgt auch nur 20 kOhm. Das ist zwar nicht der Eingangswiderstand der Schaltung, aber doch weniger als bei einer klassischen Eingangsschaltung mit einem NPN Transistor wie zB in den Philips Tonbandgeräten N45xx.
Die Eingangs-Transistoren werden mit relativ hohem Kollektorstrom (900 µA) betrieben, die Basisströme sind mit 4.5 µA angegeben, werden allerdings aktiv kompensiert auf <30 nA.
Vermutlich "fährt" man mit einem einzelnen Low-Noise NPN-Transistor bei Kollektorströmen <300...500 µA und nach-geschaltetem OP besser (weniger Basisstrom, keine zusätzliche Rauschquelle durch den Kompensationsstrom).
An der o.a. Schaltung ist außerdem ungünstig die hohe DC-Verstärkung um 1000.
Der LT1028 hat zwar nur eine Offset-Spannung von maximal 40 µV, andere OPs können aber Offset-Spannungen von mVs haben. Daraus würden dann am Ausgang Volts. Übliche Gegen-Maßnahme ist ein ausreichend großer Kondensator in Serie mit R2.

MfG Kai
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste