Hallo zusammen, Für ein Projekt möchte ich einen DA-Wandler ansteuern. Angenommen ich möchte einen parallelen 10-Bit DA-Wandler mit 10MSamples/s ansteuern und noch einiges berechnen (QAM/QPSK-Modulation) von Daten, LPDC/RS-Codes, Scrambling, vielleicht auch OFDM. Geht dies mit dem neuen Raspberry Pi4? In diversen Tests ist von 50KHz in Python die rede, wobei dies mehr als eine Verdoppelung gegenüber dem RPI3 ist. Auf dieser Seite: https://codeandlife.com/2015/03/25/raspberry-pi-2-vs-1-gpio-benchmark/ Wird für den RPI2 bereits eine Geschwindigkeit von 40MHz angegeben, welche beim RPI1 noch bei 22MHZ lag. Extrapoliert man dies nach dieser Seite: https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks So müssten in C (theoretisch) > 100MHz möglich sein. Von daher die Frage, ob ihr es für möglich haltet auf dem RPI4 konstant mit 10MHz dessen Ausgänge umzuschalten und nebenbei auch noch einige Berechungen des Signals durchzuführen. Hintergrund ist die Idee, digitale Daten auf VHS-Kassetten Speichern zu wollen. Diese bieten 3MHZ Bandbreite, bei einem SNR von 40dB könnten damit (laut Shannon) 72GByte Daten auf eine 240Min Kassette geschrieben werden. Grüße und einen schönen Abend, Matze
Matze schrieb: > Von daher die Frage, ob ihr es für möglich haltet auf dem RPI4 konstant > mit 10MHz dessen Ausgänge umzuschalten und nebenbei auch noch einige > Berechungen des Signals durchzuführen. Kann ich mir nur genau dann vorstellen, wenn du’s ohne Betriebssystem nutzt. Oder ein Echtzeit-OS, das die dafür benötigten Zeiten auf der gegebenen Hardware garantieren kann. Matze schrieb: > Hintergrund ist die Idee, digitale Daten auf VHS-Kassetten Speichern zu > wollen. Diese bieten 3MHZ Bandbreite, bei einem SNR von 40dB könnten > damit (laut Shannon) 72GByte Daten auf eine 240Min Kassette geschrieben > werden. Es gab mal VHS-Streamer. Haben sich nicht durchgesetzt, und Kassetten sind auch immer schwerer zu finden. Aber ein LTO-Laufwerk der Generation 400GB/Band (unkomprimiert) ist heute schon für wenig Geld zu haben, wenn’s dir eher um das Speichern, als um das Basteln gehen sollte. Von deinen 72GB, wenn sie denn möglich sind, geht sowieso nochmal ein Haufen für Fehlerkompensation weg – wer mal alte VHS-Videos gesehen hat, weiß, warum ;)
:
Bearbeitet durch User
Ähm, 72GB? Das ist ja gar nichts, und dafür Bandsalat???
> 72GByte Daten
Deine Rechnung ist zu optimistisch.
Ich kann mich eher an praktisch erreichbare Werte von wenigen
GB erinnern, wenn es denn ueberhaupt soviel war.
Und 4 Stunden warten will heute eigentlicha auch keiner mehr.
Und zuverlaessig war es auch nicht.
Bei 72 GB koennte man ja noch DAT-Streamer nehmen.
Die sind erheblich kleiner, einfacher anzuschliessen,
aber leider genauso unzuverlaessig.
Freunde dich mit LTO an. Allerdings braucht LTO schon
eine gewisse Mindestdatenrate um optimal zu funktionieren.
Rechner die noch mit 72 GB zufriedenzustellen sind, werden
die im allgemeinen nicht erreichen.
Matze schrieb: > Hintergrund ist die Idee, digitale Daten auf > VHS-Kassetten Speichern zu wollen. Diese bieten > 3MHZ Bandbreite, bei einem SNR von 40dB könnten > damit (laut Shannon) 72GByte Daten auf eine > 240Min Kassette geschrieben werden. Graue Theorie. VHS ist Schrägspurverfahren; das Problem ist meines Wissens nicht die Bruttodatenrate, sondern die Synchronisation.
Jack V. schrieb: > Kann ich mir nur genau dann vorstellen, wenn du’s ohne Betriebssystem > nutzt. Oder ein Echtzeit-OS, das die dafür benötigten Zeiten auf der > gegebenen Hardware garantieren kann. OK, genau an der Stelle habe ich auch die meisten bedenken, dass es eben nicht möglich ist die Zeiten dauerhaft einzuhalten. Dann wäre der nächste Schritt wohl ein System welches ein FPGA dazwischen hat, dies kann die Daten etwas Puffern. Die Signalform selbst müsste man dann auch im FPGA generieren können, Timings sind dann kein Problem. Die Codierung würde wohl am beinfachsten immer noch in C auf dem RPI gerechnet. Der beste Weg die Daten zu FPGA zu bringen ist wohl Ethernet, 100Mbit dürften dann ausreichend sein. Was dann auch noch reicht im einen DAC ausreichend schnell zu versorgen. Jack V. schrieb: > Es gab mal VHS-Streamer. Haben sich nicht durchgesetzt, und Kassetten > sind auch immer schwerer zu finden. Aber ein LTO-Laufwerk der Generation > 400GB/Band (unkomprimiert) ist heute schon für wenig Geld zu haben, > wenn’s dir eher um das Speichern, als um das Basteln gehen sollte. Von > deinen 72GB, wenn sie denn möglich sind, geht sowieso nochmal ein Haufen > für Fehlerkompensation weg – wer mal alte VHS-Videos gesehen hat, weiß, > warum ;) Ja, es geht ums Basteln, wenn es am Ende 10GByte sind würde ich es schon als recht gelungen ansehen. Und hätte dabei einiges dazugelernt... oerks schrieb: > Deine Rechnung ist zu optimistisch. > Ich kann mich eher an praktisch erreichbare Werte von wenigen > GB erinnern, wenn es denn ueberhaupt soviel war. > Und 4 Stunden warten will heute eigentlicha auch keiner mehr. > Und zuverlaessig war es auch nicht. Es gibt durchaus Anwendungen bei denen (relativ) egal ist wie lange die Übertragung dauert. Z.b. kann ein H264 Video bereits angesehen werden, bevor die Datei komplett auf das Zielgerät kopiert ist. Angenommen man holt sich einen solchen Film von der Digitalen-VHS und die Datenrate der VHS entspricht mindestens der Code-daten-rate so kann der Film sofort begonnen werden. Zusätzlich hat man nach dem Ansehen des Films, den ganzen Film auf den PC kopiert. Bezüglich Fehlerkompression danke ich dass es einigermaßen viel zu tun gibt, jedoch bin ich auch erstaunt wie gut die Qualität von VHS welche 1995 aufgenommen wurden, heute noch ist. Egon D. schrieb: > VHS ist Schrägspurverfahren; das Problem ist meines > Wissens nicht die Bruttodatenrate, sondern die > Synchronisation. Da werd ich mich noch weiterinformieren... Insgesamt würde ich es als längerfristiges Hobbyprojekt ansehen. Schonmal schönen Dank für eure Antworten :)
Nimm den Composite Video out des Raspberry. Da ist alles drin, DAC und Frame Sync. Die nächste Frage ist, wie wird das zurückgelesen? Da braucht es den entsprechenden ADC bzw. Framegrabber.
In der ct gab es in den Neunzigern mal so etwas für den PC Druckerport, das sollte ungefähr 7GB auf eine Kassette speichern können. Ansonsten würde ich etwas Manchester-Code ähnliches verwenden (z.B. 2 invertierte "Pixel" je Bit), damit die Gesamthelligkeit gleich bleibt und die AGC nicht zu regeln anfängt. Zur Sicherheit könnte man den Datenblock zweimal übereinander im Frame (nebst Prüfsumme) speichern. Jörg
VHS schrieb: > Nimm den Composite Video out des Raspberry. > Da ist alles drin, DAC und Frame Sync. > Die nächste Frage ist, wie wird das zurückgelesen? > Da braucht es den entsprechenden ADC bzw. Framegrabber. Hm, ich denke die Daten als "Bilder" zu speichern ist nicht grade der ideale Ansatz. Ich es sollten schon mehrere Bits je Symbol untergebracht werden. Sprich QPSK oder zumindest BPSK. In FM wird da nicht so viel möglich sein, grade wenn es noch echte Bilder darstellen soll. Joerg W. schrieb: > In der ct gab es in den Neunzigern mal so etwas für den PC Druckerport, > das sollte ungefähr 7GB auf eine Kassette speichern können. Ansonsten > würde ich etwas Manchester-Code ähnliches verwenden (z.B. 2 invertierte > "Pixel" je Bit), damit die Gesamthelligkeit gleich bleibt und die AGC > nicht zu regeln anfängt. > Zur Sicherheit könnte man den Datenblock zweimal übereinander im Frame > (nebst Prüfsumme) speichern. Ja, von diesem Artikel habe ich auch gelesen, 7GB sind ja schon einiges. Es gibt auch einen Artikel der Computerwoche von 1984 in dem für ein Interface geworben wird, mit dem 92MByte auf einer 160Min-Kassette gespeichert werden können. Ich halte es für möglich beide Varianten zu übertreffen. Grundsätzlich würde ich vorsehen eine Modulationsart wie QPSK oder 8PSK zu wählen, je nachdem was der Kanal eben her gibt. Dadurch wäre die Amplitude Konstant, eine AGC würde mich so nicht stören. Ich bin mir nicht sicher in wie fern z.b. Sync-Siganle aufgezeichnet werden müssen, aber generell würde ich den Kanal mit sehr unterschiedlichen Übertragungseigenschaften je Frequenz sehen. Zum einen steht das Helligkeitssignal mit 3MHz Bandbreite zur Verfügung, weiterhin gibt es das Farbsignal mit etwa 400KHz sowie 2x Audio mit je ca 20KHz. Dies gibt insgesamt eine Bandbreite von ~3,44MHz. Insgesamt ist es demnach sinnvoll mit 4 Einzelsignalen in den VHS-Recorder hinein zu gehen. Dementsprechend wären auch 4 ADC's mit den entsprechenden Eigenschaften zur Rückgewinnung der Information vorgesehen. Bei 10GByte auf 240Min wären es dann etwa 700KByte/Sec die aufgezeichnet werden sollen. Macht etwa 1,62Bit/(Sec*Hz), bei einem SNR von "nur" 10dB kann bereits das Doppelte gespeichert werden. Habt ihr konkrete Gründe/Ideen, warum 10GByte auf 240Min nicht realisierbar sein sollten/könnten?
Matze schrieb: > Habt ihr konkrete Gründe/Ideen, warum 10GByte auf 240Min nicht > realisierbar sein sollten/könnten? Dropouts. Bandfehler. Da fehlt dann einfach mal ein halbes Frame. Für analoges Video nicht weiter problematisch, für digitale Aufzeichnung fatal. Das Bandmaterial war eben dafür nicht gedacht im Gegensatz zu DAT oder Video-8, was von vornherein schon digital arbeitet. Daran sind damals auch die ganzen Bastellösungen gescheitert. Klar, mit Interleaving und FEC kannst Du einiges machen, aber das ist dann noch viel mehr Aufwand, und die Netto-Kapazität sinkt. fchk PS: Dazu kommt noch, dass VHS-Kassetten nicht mehr neu hergestellt werden und das 20 oder 30 Jahre alte Material seine besten Jahre auch schon hinter sich hat. Es wird mit den Jahren nicht besser.
:
Bearbeitet durch User
Es scheint vielleicht etwas übertrieben, aber als DAC wäre der ADV7123 gut geeignet. Er kann 240MSamples@10Bit hat gleich 3 Ausgänge müsste noch von Hand bestückbar sein und ist für 13€ beschaffbar. Mit 2 Stück wäre man voll-versorgt. Und als beste Eigenschaft, er kann direkt 75Ohm Kabel Treiben ;) https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7123.pdf Als ADC kämme der MAX1186 in frage. Mit 40MS und 10Bit sollte er auch gut ausreichen. Gibt nicht viele Alternativen ohne BGA die beschaffbar sind. https://www.maximintegrated.com/en/products/analog/data-converters/analog-to-digital-converters/MAX1186.html
dann sieh dir erst einmal an, wie VHS funktioniert. Alles, was nicht als Helligkeit darstellbar ist, wird per se nicht aufgezeichnet. Auch aus QPSK wird da nur noch ein AM-Signal.
VHS schrieb: > dann sieh dir erst einmal an, wie VHS funktioniert. > Alles, was nicht als Helligkeit darstellbar ist, wird per se nicht > aufgezeichnet. Auch aus QPSK wird da nur noch ein AM-Signal. Ja, dachte ich mir auch schon und das dies ein größeres Problem darstellt, kann auch gut sein. Die Helligkeit ist ja immerhin schon FM, die Farbe ist wohl AM. Tatsächlich fehlt mir momentan das wissen genau vorherzusagen zu können wie ein Signal somit umgewandelt wird. Genauere Infos scheinen da auch nicht so leicht zu finden zu sein. Bleibt eventuell nur Try&Error...
muss man überhaupt mit einer analogen Kurve aufs Band schreiben? Beim C64 (klar ist jetzt kein Schrägspurverfahren) wurde einfach der Abstand zwischen den Nullpunkten einer fallenden Kurve per Schmitt-Trigger ausgewertet. 3 MHz auszuwerten sollte heutzutage kein Problem sein. Auch muss man bei diesem Anwendungsfall keine 2 Halbbilder zusammensetzen, also das 1te Halbbild enthält die ersten Daten und das 2te eben die nächsten. Könnte man da nicht einfach ein digitales(Rechteck)-Signal unter Umgehung von den Filtern auf die Schreibköpfe geben? Da hier Verzerrungen nicht so die Rolle spielen sollte man das Band noch weiter aussteuern können.
Ich möchte ein paar KB dauerhaft Speichern und Lagern können, und überlege mir so etwas mit Audio-Kasetten zu bauen. Es wurde ja damals sehr viel Entwicklung in diese Bänder gesteckt aber Mittlerweile werden keine Consumer-VHS Geräte und kaum Audio-Kasetten mehr gebaut. Damit das auch noch in 15 Jahren "einfach" lesbar ist, würde ich die Daten mit einen 4-Track-Head "direkt" per SPI lesen/schreiben und an UART weitergeben/empfangen. 1xClock 2xDaten und ein PartyBit auf dem Tape. Einfach mit zwei Tonlagen für High und Low. Keine besonderen Modulationen. Das kann jedes Billiggerät mit jeder Soundkarte und man braucht sich keine Sorgen wegen Laufzeiten Sync und Unterschieden mehr zu machen, und man weiß auch noch in +20 Jahren was zu tun ist. Man könnte es ganz einfach in Schieberegister reinlaufen lassen - oder es per Hand hören und Aufschreiben. Performance und Effektivität Mal beiseite gelegt. Das geht solange bis das Band zerfallen ist.
4-Spur Kopf (links) und 2-Spur Kopf (rechts). Wenn man nur 2 Channels verarbeiten kann, braucht man eben mehrere Durchgänge, oder verzichtet auf das zweite Bit und aufs PartyBit.
Matze schrieb: > Von daher die Frage, ob ihr es für möglich haltet auf dem RPI4 konstant > mit 10MHz dessen Ausgänge umzuschalten und nebenbei auch noch einige > Berechungen des Signals durchzuführen Konstant geht da gar nichts, weil auf dem Ding ein Betriebssystem läuft dass dein Programm zeitweise unterbricht. Für kontinuierliche Ein-/Ausgabe brauchst du I/O Module mit Pufferspeicher oder direktem Speicherzugriff, so wie man das von klassischen Soundkarten und Grafikkarten her kennt.
Hab nochmal überlegt und VHS ist echt Mist und extrem Fehleranfällig! Aber mit einem halbwegs modernen elektronischen Kassettendeck mit "Remote" (Chinch) kann mann es gleich vom PC bzw der Software "Fernsteuern", wenn dessen Protokoll bekannt ist. (Es ist in der Regel aber schon bekannt!) Da kommen dann Features wie z.B eine Titelnummer (Datei) direkt wählen bzw überspringen zu können. Man muss gar nichts mehr machen, außer noch den 4-Track Head mit einbauen. Oder gleich ein entsprechendes Deck finden! Ich will mein Teac-Deck noch nicht zerrupfen. Die Mechanik, den Kopf beim Seitenwechsel zu drehen, ist lustig. Gruß
Tim S. schrieb: > Ich möchte ein paar KB dauerhaft Speichern und Lagern können, und > überlege mir so etwas mit Audio-Kasetten zu bauen. Es wurde ja damals > sehr viel Entwicklung in diese Bänder gesteckt aber Mittlerweile werden > keine Consumer-VHS Geräte und kaum Audio-Kasetten mehr gebaut. Hast Du Bedarf, oder ist das Bastelei der Bastelei willen? Ich meine, bei ebay werden gerade LTO-3 Laufwerke für 25 bis 60€, teilweise mit SAS Controllerkarte verkauft. Die machen 400GB unkomprimiert auf ein Band. fchk
Bitte 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.