Forum: Mikrocontroller und Digitale Elektronik Raspberry PI 4 IO-Performance für 10-Bit/10MSamples/s ADC ausreichend?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Matze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jack V. (jackv)


Bewertung
1 lesenswert
nicht lesenswert
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
von _Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ähm,


72GB?

Das ist ja gar nichts, und dafür Bandsalat???

von oerks (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von VHS (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
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

von Matze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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
von Matze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von VHS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Tim S. (Firma: tsx) (freak_ts) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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ß

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.