Hallo, ich muss bei einem Motor mittels Referenzwinkelgeber die Winkelinformation mit einem Zeitstempel bestimmen. max.Drehzahl : 9000 U/min Messdauer: 15s Impulse/U: 5000 Die Messwerte sollen erst mal extern zwischengespeichert und nach Abschluss der Messung werden die Daten auf einem USB Stick abgeliefert. Auswertung der Messdaten erfolgt offline. Da dies alles Neuland für mich ist, wollte ich fragen ob jemand paar Tipps hätte was ich brauch und welchen Einplatinencomputer ihr mir empfehlen würdet der diese hohe Geschwindigkeit schafft.
Bitte detaillierte Angaben über deinen Geber! Schnittstelle, Interface, Typ, Hersteller...
750000 Zählungen/ Events pro Sekunde?! Plus Auswertung, Verarbeitung, Speicherung..... Ich bin raus!
Mirko schrieb: > Da dies alles Neuland für mich ist, wollte ich fragen ob jemand paar > Tipps hätte was ich brauch und welchen Einplatinencomputer ihr mir > empfehlen würdet der diese hohe Geschwindigkeit schafft. Einen Industrie PC.
Goldmedaille schrieb: > Schnittstelle, Interface, Typ, Hersteller... Schnittstelle: RS422 Incremental Encoder RI 36-H von Hengstler Korrektur : 3600 Impulse/U
Nennt mich doof, aber ich finde in der Produktbeschreibung des Sensors keinerlei Hinweis, wie die Daten übermittelt werden.
Stefanus F. schrieb: > Nennt mich doof, aber ich finde in der Produktbeschreibung des Sensors > keinerlei Hinweis, wie die Daten übermittelt werden. Das Datenblatt beschränkt sich auf das Wesentliche :) Genaueres steht im Gesamtkatalog ab PDF-Seite 335. https://www.hengstler.de/gfx/file/shop/encoder/201101_Hengstler_Katalog_Encoder_Drehgeber_de.pdf
Der liefert also tatsächlich nackte Impulse, nicht irgendwie als Daten aufbereitet. Mirko: Willst du die Flanken der Impulse mit Zeitangabe speichern oder wie hast du dir das gedacht?
Stefanus F. schrieb: > Nennt mich doof, aber ich finde in der Produktbeschreibung des Sensors > keinerlei Hinweis, wie die Daten übermittelt werden. Mir scheint als differenzielle Impulse, wie er sagt 3600 je Umdrehung * 9000 1/min mach 8,1 Mio Impulse zu messen in 15 Sec. oder pro Sekunde 540000 ... 540kHz Zeitstempel 1,8 Mikrosekunden Auflösung ... das wird mehr als sportlich ... Arduino ;) Schon die Zeitmessung wird interessant
:
Bearbeitet durch User
Stefanus F. schrieb: > Der liefert also tatsächlich nackte Impulse Also selbst wenn er per Interrupt nur auf ein Signal (z.B. A) und auf eine Flanke reagiert: 9000 U/min. * 3600 Impulse/U = 540000 Interrupts/sec. = 540 Interrupts/msec. Somit müsste ein Interrupt in 1,85 µsec. abgearbeitet sein... und der normale Softwareteil sollte ja auch noch "Zeit" abbekommen. Oder sehe ich da etwas nicht und rechne falsch?
Stefanus F. schrieb: > Der liefert also tatsächlich nackte Impulse, nicht irgendwie als Daten > aufbereitet. > > Mirko: Willst du die Flanken der Impulse mit Zeitangabe speichern oder > wie hast du dir das gedacht? Ich hab mir überlegt, dass eine Zweifachauswertung reichen sollte. Das heißt , dass ich bei jeder Flanke von A alle Kanalzustände(+Zeit) speichere. Oder würdet ihr mir empfehlen immer nur bei einem Doppelimpuls (Impuls auf A und B gleichzeitig) nur die Zeit abzuspeichern?
Adam P. schrieb: > Stefanus F. schrieb: >> Der liefert also tatsächlich nackte Impulse > > Also selbst wenn er per Interrupt nur auf ein Signal (z.B. A) und auf > eine Flanke reagiert: > > 9000 U/min. * 3600 Impulse/U = > 540000 Interrupts/sec. = > 540 Interrupts/msec. > > Somit müsste ein Interrupt in 1,85 µsec. abgearbeitet sein... > und der normale Softwareteil sollte ja auch noch "Zeit" abbekommen. > > Oder sehe ich da etwas nicht und rechne falsch? Deswegen will ich die Messwerte erst mal zwischenspeichern und hinterher auswerten, um die Zeit der Software so gering wie möglich zu halten.
Mirko S. schrieb: > Deswegen will ich die Messwerte erst mal zwischenspeichern und hinterher > auswerten, um die Zeit der Software so gering wie möglich zu halten. OK, aber willst du jeder Flanke einen Zeitstempel verpassen oder in welchem Abstand? Du müsstest ja auch ein Sys-Tick oder Timer haben der dir ein Zeitstempel überhaupt generiert (Diese Interrupts benötigen auch Zeit).
Ich würde dir den PSOC 5LP (oder ähnliches) empfehlen. http://www.cypress.com/products/32-bit-arm-cortex-m3-psoc-5lp Damit kannst du die Impulsmessung per programmierbarer HW machen. Damit ist die SW aus dem kritischen Timing raus.
Deine "Messwerte" sind also Zeitpunkte, und zwar reichlich viele. Du wirst dazu einen verdammt schnellen Mikrocontroller benötigen, mit verdammt viel Speicher. Die üblichen Bastlerprodukte (Arduino, STM32, Raspberyy Pi), die hier diskutiert werden, sind nach meiner Einschätzung allesamt nicht geeignet.
Und für 10$ gibt es schon ein Prototype-Board... http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and
> Und für 10$ gibt es schon ein Prototype-Board... Mit einem ARM Cortex-M3, ich lach mich tot. Vielleicht ist hier eine eine Logikschaltung angesagt, als ein klassisches Programm das von einer CPU abgearbeitet wird.
Goldmedaille schrieb: > 750000 Zählungen/ Events pro Sekunde?! Das ist doch nicht schwierig? Da nimmt man passende Hardware, oder einen µC, dessen Timer AB-Signale verstehen. STM32 können das. Da zählt die Hardware. Das dürfte problemlos bis in den MHz-Bereich gehen. Siehe auch: http://www.micromouseonline.com/2013/02/16/quadrature-encoders-with-the-stm32f4/
Moin, Bei dem Timing wuerd' ich schon eher auf Hardware setzen und keine reine SW Loesung anstreben. Vielleicht wuerde da noch was mit einer tricky Timerhardware, die zufaellig in irgendeinem µC rumoxidiert, gehen, aber wenn man da nicht gleich zufaellig schon was weiss, wirds wohl mit einem kleinen FPGA Board oder evtl. CPLD-Huckepackplatinchen oder aehnlicher konfigurierbarer Hardware doch mit den wenigsten Schmerzen machbar sein. Gruss WK
Stefanus F. schrieb: > Mit einem ARM Cortex-M3, ich lach mich tot. Schade, würdest du noch leben würde ich dir sagen, dass der µC eine programmierbare Logic auf dem Chip hat.
Als Nachtrag vielleicht noch: Es gibt spezialisierte IC, die die Zählarbeit übernehmen können. Zum Beispiel jenen: https://ichaus.de/upload/pdf/MD_factsheet_rev1en.pdf Damit ist JEDER µC tauglich. 750k Inkremente pro Sekunde sind im Übrigen Standardkram. Da braucht man nicht in Ogottogott-Starre verfallen.
Ich sehe das Problem eher beim Speicher. Wenn er die µC-Hardware zum zählen verwendet und sagt, ich möchte einen Interrupt nach einer Umdrehung, dann mag das ok sein, aber wenn er die Info jede Flanke haben will, nützt das Zählen mit dem Timer-Modul auch nix, Interrupt kommt dann trotzdem jede 1,85µs. Sagen wir mal wir haben ein schnellen µC gefunden, nun wollen wir aber Zeitstempel + evtl. Info ablegen. Wenn das wirklich bei jeder Flanke passieren soll: Tick-Cnt (ms) = uint32_t Tick-Cnt (µs der ms) = uint16_t Info-Byte = 2x uint8_t Sind wir bei 8 Byte und das kommt nun jede 1,85µs vor -> Das sind dann ca. 8MB je Sekunde.
soso... schrieb: > 750k Inkremente pro Sekunde sind im Übrigen Standardkram. Da braucht man > nicht in Ogottogott-Starre verfallen. Wenn er aber jedes Inkrement mitbekommen möchte um es mit Zeitstempel zu versehen?
soso... schrieb: > STM32 können das. Aber locker, man nimmt einfach einen 32Bit Timer und lässt diesen Incrementieren. Man zählt während der 15s die Überläufe, die ~alle 6s kommen und wertet nach 15s den Zählerstand + Überläufe aus. Wenn man will kann man sogar den internen Prescaler noch davor ballern. Anschließend das Ergebnis an den PC, evtl. sogar gleich mit Auswertung...
Adam P. schrieb: > Wenn er aber jedes Inkrement mitbekommen möchte um es mit Zeitstempel zu > versehen? Dann habe ich auch keine Lösung, ich denke man sollte dann lieber mit Überlegen weiter machen statt mir "brute-force" bzw. unbegrenzter Rechenleistung
Adam P. schrieb: > Mirko S. schrieb: >> Deswegen will ich die Messwerte erst mal zwischenspeichern und hinterher >> auswerten, um die Zeit der Software so gering wie möglich zu halten. > > OK, > aber willst du jeder Flanke einen Zeitstempel verpassen oder in welchem > Abstand? > > Du müsstest ja auch ein Sys-Tick oder Timer haben der dir ein > Zeitstempel überhaupt generiert (Diese Interrupts benötigen auch Zeit). Ich brauche den Winkel , die Drehrichtung und die Zeit. Wenn ich nur die aufsteigende Flanke benutze , kann ich zwar Winkel und Zeit bestimmen aber die Richtung nicht. Deswegen dachte ich , ich müsste beide benutzen.
Mirko S. schrieb: > Ich brauche den Winkel , die Drehrichtung und die Zeit. Wenn ich nur die > aufsteigende Flanke benutze , kann ich zwar Winkel und Zeit bestimmen > aber die Richtung nicht. Deswegen dachte ich , ich müsste beide > benutzen. Wenn dir eine Winkelauflösung von 1° reichen würde: Könntest du den Timer auf 10 Impulse konfigurieren (Signal A z.B) und dann den Status von A & B abfragen. Dann hättest du dein Winkel, deine Drehrichtung und je Grad einen Zeitstempel.
Mirko S. schrieb: > Ich brauche den Winkel , die Drehrichtung und die Zeit. Wenn ich nur die > aufsteigende Flanke benutze , kann ich zwar Winkel und Zeit bestimmen > aber die Richtung nicht. Deswegen dachte ich , ich müsste beide > benutzen. Die Richtung ergibt sich aus den Zählerständen. Denn AB geht ja Aufwärts und Abwärts. Dann gibts zwei Möglichkeiten: Du liest den Timer in einem bestimmten Raster aus (1ms zum Beispiel), und speicherst das im SRAM. Bei 32Bit Auflösung für die Position benötigt das etwa 60kBytes - kein Problem soweit. Oder du speicherst dir die Zeitstempel für eine bestimmte Inkrementenzahl. Nimmt man an, alle 400 Inkremente speicherst du einen Zeitstempel mit 32 Bit, wären das 112kBytes (wenn ich richtig gerechnet habe). D.h. du wirst schon die Auflösung vorgeben müssen, wenn man dir ein solches Board empfehlen soll. Ich vermute, jedes einzelne Inkrement genau zu erfassen, wird Overkill sein.
Adam P. schrieb: > Mirko S. schrieb: >> Ich brauche den Winkel , die Drehrichtung und die Zeit. Wenn ich nur die >> aufsteigende Flanke benutze , kann ich zwar Winkel und Zeit bestimmen >> aber die Richtung nicht. Deswegen dachte ich , ich müsste beide >> benutzen. > > Wenn dir eine Winkelauflösung von 1° reichen würde: > Könntest du den Timer auf 10 Impulse konfigurieren (Signal A z.B) und > dann den Status von A & B abfragen. > Dann hättest du dein Winkel, deine Drehrichtung und je Grad einen > Zeitstempel. Ich benötige eine Mindestauflösung von 0.1° .
Du willst also wirklich jede Änderung um 0,1° mit Zeitstempel und Richtung speichern? Dann solltest du wirklich erwägen, eine spezielle Hardware-Logik dazu entwickeln zu lassen (eventuell in VHDL).
Adam P. schrieb: > Sind wir bei 8 Byte und das kommt nun jede 1,85µs vor > -> Das sind dann ca. 8MB je Sekunde. SORRY, hatte mich da verrechnet! Es sind 4320000 Byte/sec. Trotzdem noch eine schöne Menge. Mirko S. schrieb: > Ich benötige eine Mindestauflösung von 0.1° . Also musst du doch bei den 3600 bleiben.
Stefanus F. schrieb: > Dann solltest du wirklich erwägen, eine spezielle > Hardware-Logik dazu entwickeln zu lassen (eventuell in VHDL). So sehe ich das langsam auch. ABER (nur mal so theoretisch): Mein Cortex-M4 läuft mit 64MHz und hat beim SysTick-Handler eine Laufzeit von 3,4µs, dieser inkrementiert nur die Uptime. Wenn du jetzt einen µC mit 300MHz hättest (SAM-Familie), dann wärst du um das 4,6875-Fache schneller (theoretisch). Somit würde der SysTick-Handler eine Laufzeit von 0,725µs haben. So würdest du in die 1,85µs den SysTick und dein Imp.-Interrupt unterbekommen, zwar sehr knapp aber evtl. machbar. Der müsste dann ein Info-Paket basteln und per DMA (PDC) an ein externes RAM schicken. Alles andere würde ja dann wie du sagst nach der Messung ablaufen und wäre nicht mehr Zeitkritisch.
:
Bearbeitet durch User
Hi M3 macht ja "nur" das SW Interface, den Rest macht der cpld vom PSoC - so der Plan. So weit mir bewusst hat der cpld Teil aber kein Bus master Interface, so dass die Daten nicht ohne CPU geschaufelt werden können. Aber die Flanke mit dem richtigen Zeitstempel zu synchronisieren könnte es doch gehen. Die CPU hat dann ein paar Zyklen Zeit die. Buffer zu lesen. Wenn's noch ein bisschen mehr sein darf, Ultra96 von Avnet hat gleich einen richtigen FPGA mit drin. Grüße Thorsten
Stefanus F. schrieb: > Du willst also wirklich jede Änderung um 0,1° mit Zeitstempel und > Richtung speichern? Dann solltest du wirklich erwägen, eine spezielle > Hardware-Logik dazu entwickeln zu lassen (eventuell in VHDL). Die Richtung brauch ich eigentlich nicht jedes mal speichern. Mir würde vermutlich sogar reichen die Richtung nur am Anfang oder jede 2s auszulesen. Ich muss mich da nochmal informieren.
Mirko S. schrieb: > Die Richtung brauch ich eigentlich nicht jedes mal speichern Das wäre aber keine "Datenersparnis", ja ok, vllt. 1Byte.
Stefanus F. schrieb: > Wie präzise müssen eigentlich die Zeitpunkte erfasst werden? Er sagte ja, Genauigkeit 0.1° ...da wird er schon jeden Impuls der 3600 berückstigen müssen.
> Er sagte ja, Genauigkeit 0.1°
Das bezieht sich auf den Winkel. Ich frage nach der Auflösung der Zeit.
Mit einer RTC, die Sekunden liefert käme man hier z.B. nicht weiter.
Jetzt magst du die Augen verdrehen, aber der Teufel steckt oft im
Detail.
Die Diskussion von Genauigkeit versus Auflösung habe ich bewusst noch
nicht begonnen.
Stefanus F. schrieb: > Wie präzise müssen eigentlich die Zeitpunkte erfasst werden? Ich möchte die Zeitpunkte nur aufnehmen um die Daten verifizieren zu können. Falls es zu einem Ausfall kommt kann ich dies analysieren, da ich die Zeitabstände habe.
Also würde dir auch folgendes reichen? - 1x Timestamp - Dann 1ms lang 540 Datenpakete - 1x Timestamp - usw. Oder doch genauer (jede 100µcs) oder ungenauer (jede Sekunde). Das beudetet: Nicht jedes Event (Impuls) benötigt ein Zeitstempel?
:
Bearbeitet durch User
Adam P. schrieb: > Also würde dir auch folgendes reichen? > > - 1x Timestamp > - Dann 1ms lang 540 Datenpakete > - 1x Timestamp > - usw. > > Oder doch genauer (jede 100µcs) oder ungenauer (jede Sekunde). > > Das beudetet: Nicht jedes Event (Impuls) benötigt ein Zeitstempel? Also erstmal Vielen Dank an alle für die Hilfe. Bin da gerade am überlegen wie genau ich das brauche. Ich melde mich dann morgen. Muss es nämlich abklären.
Mirko S. schrieb: > Bin da gerade am > überlegen wie genau ich das brauche. Alles klar, denn sonst könnte man es sehr weit runterbrechen: Bei jedem Impuls nur ein 2Byte Wert für den Winkel ablegen, nach 3600 Imp. (1x Umdrehung) die Richtung und den Zeitstempel kannst auch an die Umdrehung oder an ein fixes Intervall binden.
Adam P. schrieb: > Alles klar, denn sonst könnte man es sehr weit runterbrechen: [...] Wenn man's richtig durchdenkt, kann man's noch sehr viel "runterbrechen". Und erkennt: Es reichen zwei AVR8 für die Aufgabe aus, weil: 1) "Zeitstempel" braucht man keinen. Wenn der Code BEWEISBAR schnell genug Daten sammelt und wegschreibt, braucht man keinen Zeitstempel zur Kontrolle, dass er es auch wirklich tut. 2) Alles, was man tatsächlich speichern muss, ist jede Änderung eines der beiden Encoder-Kanäle, also im Kern: zwei Bit pro Encoder-Schritt. Oder besser: zwei Bit pro Sample einer hinreichend hohen Samplefrequenz, denn dann hat man auch das Timing mit drin (durch temporal äquidistante Samples) und damit letztlich sogar auch die Kontrollfunktion des unter 1) als Schwachsinn verworfenen Zeitstempels. Man zählt statt dessen einfach die Zahl der aufgezeichneten Samples und vergleicht mit dem Erwartungswert für den Messzeitraum. 3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn man den alten toten Säcken Shannon und Nyquist glauben darf (und ich glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal großzügig: ~1,2MHz Samplerate. 4) Gespeichert werden müssen, wie gesagt, zwei Bit/Sample, nämlich der Zustand der Kanäle A und B des Encoders, es passen also vier Samples in ein Byte. Damit beträgt die zu bewältigende Datenrate für's Wegschreiben der Daten 300kByte/s. Das ist für einen AVR8@20MHz keine besondere Herausforderung. Wenn da nicht noch die konkurrierende Aufgabe der Datengewinnung wäre... 5) Man erkennt das Problem und trennt den Job in zwei Teile für zwei AVR8. Einen kleinen, der die Daten timinggenau einsammelt, zu Bytes zusammenpackt und per SPI oder parallel an einen weiteren, größeren AVR sendet. Der hat dann den schon deutlich entspannteren Job, den Kram im RAM zu puffern und irgendwohin zu schreiben, z.B. auf eine SD-Card. Natürlich mit einem double-buffering-Mechanismus zur Entkopplung von Lesen und Schreiben. 6) Der Code für den kleinen AVR8 (irgendein Tiny) besteht aus vielleicht 30..40 Zeilen Assembler, wovon die meisten nur Initialisierung sind. Sehr überschaubarer Entwicklungsaufwand. Die minimale Anforderung ist: externer Takt bis 20MHz möglich (damit er taktmäßig vom großen mitversorgt werden kann). Ein blöder Tiny13 (sonst zu fast nix nutze) würde bereits diese Anforderung erfüllen. 7) Den großen AVR (hier kommt es vor allem auf viel RAM an, also z.B. 1284P) könnte man dann schon in C programmieren, hat dann aber das Problem mit der fehlenden Beweisbarkeit, dass der Code tatsächlich schnell genug ist. Ich würde also auch dafür Assembler empfehlen. Insgesamt aber: FPGA? Ich lach' mich tot. Industrie-PC? Ich lach mich tot. Kann denn hier niemand mehr wirklich denken, rechnen und programmieren?
> Damit beträgt die zu bewältigende Datenrate für's Wegschreiben > der Daten 300kByte/s. Das ist für einen AVR8@20MHz keine > besondere Herausforderung. Das ist soweit ich weiß, das Maximum was bisher als erreichbar gemeldet wurde - wenn der µC sonst nichts anderes zu tun hat. Gemein ist aber, dass SD Karten sich zwischendurch mal ganz erhebliche "Denkpausen" gönnen, vor allem beim Schreiben. Da könnte das bisschen interner RAM knapp werden.
Was willst du denn messen? Den encoder? Normale Motorkennlinien? Dann reicht es, ggf nur jeden 100ten Impuls zu "stempeln". Oder mikrovibrationen, also ob innerhalb von 10 Impulsen 2 Nanosekunden jitter sind. Ich glaube, wenn du uns die Aufgabe darlegst, zerfällt die HW zu einer BASIC-stamp
Weingut P. schrieb: > oder pro Sekunde 540000 ... 540kHz Zeitstempel 1,8 Mikrosekunden Schade nur daß die Schnittstelle des Sensors für maximal 300 kHz spezifiziert ist. Kein Wunder daß das zu Problemen führt. c-hater schrieb: > 3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn > man den alten toten Säcken Shannon und Nyquist glauben darf (und ich > glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der > maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal > großzügig: ~1,2MHz Samplerate. Naja, wenn man eindeutig Vorwärts und Rückwärtsrichtung des Quadratursignals erkennen können möchte sollte das mindestens das 8-10 fache des Einzeltaktes sein, -> ich würde mit 200ns oder 5 MHz abtasten wollen. Ich würde für eine einmalige Meßaufgabe (offline Auswertung) eher ein geeignetes 4-Kanal-Oszi verwenden. (der Sensor hat ja nicht nur A/B sondern auch noch mindestens den Index-puls). Man braucht für 20 Sekunden Aufzeichnungsdauer dann ca 400 MSamples in Summe für 4 Kanäle. z.B. das PicoScope 5444B oder das neue 5444D. Das 3406D ginge auch. Gruß Anja
Stefanus F. schrieb: > Das ist soweit ich weiß, das Maximum was bisher als erreichbar gemeldet > wurde - wenn der µC sonst nichts anderes zu tun hat. Hat er ja durch die Aufteilung der Aufgaben auch nicht mehr wirklich. Das Warten auf die trödelnde SD-Karte muss er ja bei sinnvoller Programmierung nicht per busy-wait machen. Er kann währenddessen natürlich lustig weiter Daten vom "Kleinen" puffern. > Gemein ist aber, dass SD Karten sich zwischendurch mal ganz erhebliche > "Denkpausen" gönnen, vor allem beim Schreiben. Da könnte das bisschen > interner RAM knapp werden. Kaum. Du hast im M1284P 16 kByte RAM. Das reicht bei double-buffering und 300kByte/s, um selbst die Aussetzer fast der lausigsten SD-Karten bewältigen zu können (sofern sie nicht bereits "totgeschrieben" sind, also ihr Endziel in ihrer Rolle als "Klopapier-Speicher" erreicht haben). 8kByte entspricht bei 300kByte/s ja immerhin 26ms Pufferkapazität. Eine kleine Ewigkeit...
Anja schrieb: > c-hater schrieb: >> 3) Nun muss man nur noch die Samplefrequenz passend wählen, also, wenn >> man den alten toten Säcken Shannon und Nyquist glauben darf (und ich >> glaube ihnen), dann genügt dafür etwas mehr als das Doppelte der >> maximalen Schrittrate von 3600*9000/60=540.000Hz, also sagen wir mal >> großzügig: ~1,2MHz Samplerate. > > Naja, wenn man eindeutig Vorwärts und Rückwärtsrichtung des > Quadratursignals erkennen können möchte sollte das mindestens das 8-10 > fache des Einzeltaktes sein, -> ich würde mit 200ns oder 5 MHz abtasten > wollen. OMG. Was lernt man heutzutage im Studium? Das war eine rein rhetorische Frage. Ich weiss natürlich, was ich von "Anja" zu halten habe...
> 8kByte entspricht bei 300kByte/s ja immerhin 26ms Pufferkapazität. > Eine kleine Ewigkeit... Ich meine mich zu erinnern, dass mehr als 100ms Puffer nötig sind.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.