Raspberry PI 4 IO-Performance für 10-Bit/10MSamples/s ADC ausreichend?

Ä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.

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?

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...

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.