Spricht etwas grundsätzlich dagegen, digitale Videosignale zum
Übertragen von Messdaten zu verwenden? Im Videosignal sind z.B.
Audiodaten eingebettet, die nach meiner Rechnung 24Mbps ausmachen. Die
allein würden schon 25% der Bandbreite bereitstellen, die ich benötige.
Ich hätte ein Netzwerk von mehreren Sensorplatinen, die Daten mit
100MB/s senden. Ethernet war vorgeschlagen, aber die Distanz sind nur 4m
und da dachte ich, da ohnehin eine Überwachungskamera Verwendung findet,
könnte ich die Daten dort einbauen.
Vieviel Platz ist in einem HDMI-Videosignal noch übrig?
Ich denke auch darüber nach, generell so eine Verbindung einzusetzen,
weil ich denke, dass die Übertragungschips preiswert sein müssten. Gibt
es Kabel und Stecker, die gegen Abziehen gesichert sind? Oder wäre da
Displayport besser?
Lordi schrieb:> Im Videosignal sind z.B.> Audiodaten eingebettet, die nach meiner Rechnung 24Mbps ausmachen.
Wohl kaum. Die Rechnung solltest du mal vorzeigen. Kann nur falsch sein.
Vermutlich die unkomprimierte Datenrate berechnet. Über's Netz gehen die
Daten aber komprimiert. Kompressionsfaktoren im Bereich 10..100 sind für
heutige Audiokompressoren üblich.
> Ich hätte ein Netzwerk von mehreren Sensorplatinen, die Daten mit> 100MB/s senden. Ethernet war vorgeschlagen, aber die Distanz sind nur 4m> und da dachte ich, da ohnehin eine Überwachungskamera Verwendung findet,> könnte ich die Daten dort einbauen.
Kannste knicken.
Moin,
Die "nur 4m" sind ein ganz schlechtes Argument gegen Ethernet.
Lordi schrieb:> Vieviel Platz ist in einem HDMI-Videosignal noch übrig?
Kommt drauf an (Wie dein exaktes Videotiming aussieht, also wieviel
Platz in den Blankingphasen ist).
Lordi schrieb:> weil ich denke, dass die Übertragungschips preiswert sein müssten.
Wie kommtste denn auf so ein schmales Brett? Insbesondere, wenn du da
Spezialfaxen machen willst, wie irgendwelche anderen Signale noch mit zu
uebertragen.
HDMI ist eine Konsumerschnittstelle in Konsumerqualitaet, d.h. da ist
nix (standardisiertes) mit irgendwelchen Verriegelungen. Nochdazu
gesegnet mit so tollen Sachen wie HDCP (proprietaer, teuer) und auch
EDID (Da kommt regelmaessig Freude auf, wenn mal eine bestimmte
Quellen/Senken-Kombi sich komisch verhaelt und man gerne wuesste,
warum...).
Nimm Ethernet, das ist guenstig und wird von allem Moeglichen
unterstuetzt.
Gruss
WK
c-hater schrieb:> Wohl kaum. Die Rechnung solltest du mal vorzeigen.
Gemäß der Spezifikation müssten 32 Kanäle in 48kHz gesendet werden
können. Dann kommen noch irgendwelche header-Daten meine ich.
> Vermutlich die unkomprimierte Datenrate berechnet. Über's Netz gehen die> Daten aber komprimiert.
Woher Daten beim streaming kommen ist eigentlich egal. Ich brauche die
Bruttoinformationsrate. Und die ist ja da.
Dergute W. schrieb:> > gesegnet mit so tollen Sachen wie HDCP (proprietaer, teuer) und auch> EDID (Da kommt regelmaessig Freude auf, wenn mal eine bestimmte> Quellen/Senken-Kombi sich komisch verhaelt
Muss ich das benuzten? Nach meiner Kenntnis fordert die Quelle die
EDID-Daten und Codes für HDCP an, schaltet dann um oder ab, wenn sie
nichts findet.
Für 2 Chips (Transmitter und Receiver) hätte ich einen 1000er Preis vom
Bestücker zu unter 23,-. Zwei Ethernet-PHYs sind nicht viel billiger.
Und ich muss noch MAC-Funktionalität implementieren.
Moin,
Lordi schrieb:> Muss ich das benuzten? Nach meiner Kenntnis fordert die Quelle die> EDID-Daten und Codes für HDCP an, schaltet dann um oder ab, wenn sie> nichts findet.
Naja, ohne HDCP gehts schon, klar. Aber ohne EDID verlierst du schon
einen grossen Teil dessen, was eigentlich der Plan bei HDMI war: Ein
Vollhonk steckt 2 Geraete zusammen und's geht.
Aber tatsaechlich erschwert die EDID die Problemsuche, macht
Mauschelloesungen bei Signalverzweigungen noetig, etc.
> Für 2 Chips (Transmitter und Receiver) hätte ich einen 1000er Preis vom> Bestücker zu unter 23,-. Zwei Ethernet-PHYs sind nicht viel billiger.
Was kaufst du fuer EthernetPhys? Die sollten eher so bei <5EUR pro
Stueck sein. Der Mouser hat z.b. vom KSZ9031 so viele, dass er sie fuer
EUR 2.30 einzeln verkauft. Bei Micrel steht der fuer USD 1.87 bei 5k
Abnahme. Und das sind schon die Gigabit-Phys. Wenn du deinen Krempel in
Fast Ethernet quetschen kannst, wirds noch billiger.
> Und ich muss noch MAC-Funktionalität implementieren.
Da wirst du aber wohl auch deutlich mehr und guenstigere Chips finden,
die das machen, als wenn du irgendwelche Zusatzdaten in HDMI reinbasteln
willst.
Gruss
WK
Wie wäre es denn damit, auch die (Überwachungs-)Kamera(s) über Ethernet
laufen zu lassen? Das ist heute Industriestandard und funktioniert auch.
Und wieso hat Dein Ethernet nur eine maximale Kabellänge von 4m. Nach
Standard dürfen bis zum nächsten Gerät 100m sein.
Und selbst wenn, dann könnte man nicht einfach einen Miniswitch in der
Nähe der Sensoren platzieren?
svensson schrieb:> Und wieso hat Dein Ethernet nur eine maximale Kabellänge von 4m.
Er verwendet gar kein Ethernet, sondern möchte:
Lordi schrieb:> digitale Videosignale zum> Übertragen von Messdaten zu verwenden
Ich würde aber auch nicht zu einer Consumer-Schnittstelle raten.
Eher CoaxPress oder CameraLink
svensson schrieb:> Und wieso hat Dein Ethernet nur eine maximale Kabellänge von 4m.
Die Abstände sind so vorgegeben. Im Mittel 2-3m, 4m ist die Obergrenze.
Dergute W. schrieb:> Mauschelloesungen bei Signalverzweigungen
Welche Lösungen meinst du da? Wo müsste gemauschelt werden?
> Was kaufst du fuer EthernetPhys?
Das stimmt natürlich. Da muss ich den Einkäufer nochmals kontaktieren,
was er da gesucht hat.
> Da wirst du aber wohl auch deutlich mehr und guenstigere Chips finden,> die das machen, als wenn du irgendwelche Zusatzdaten in HDMI reinbasteln> willst.
Bei MACs als Chip bin ich nicht so fündig geworden. Die dürften im
Übrigen in der Preiskalkulation drin sein und wegfallen, wenn ich einen
HDMI Chip nehme. Der kann dann auch die Daten reinfummeln. Daten ins
Video geht dann natürlich nicht. Das sehe ich ein. Wenn, dann wohl Daten
als Video.
Lordi schrieb:> Bei MACs als Chip bin ich nicht so fündig geworden. Die dürften im> Übrigen in der Preiskalkulation drin sein und wegfallen, wenn ich einen> HDMI Chip nehme. Der kann dann auch die Daten reinfummeln. Daten ins> Video geht dann natürlich nicht. Das sehe ich ein. Wenn, dann wohl Daten> als Video.
Das ist ein ziemlicher Nonsense. Nimm mal den Entwicklungsaufwand einer
solchen Frickellösung mit dazu, dann sieht die Nummer ganz anders aus.
Wenn Insellösung, dann eher noch "bare metal" LVDS oder CameraLink.
Und wenn man's sauber machen will, eben Ethernet. Da gibt's fertige
Refdesigns mit FPGA und Phy.
Aus Erfahrung kann ich sagen, dass die komplette Entwicklung eines
solchen Stacks weniger Aufwand macht als HDMI, von den Problemen mal
abgesehen zu den Chips die vollständigen Datenblätter zu kriegen (bei
Stückzahlen u. 1000).
HDMI usw. haben doch furchtbare Stecker. Eine mögliche Alternative wäre
z.B. SDI:
https://de.wikipedia.org/wiki/Serial_Digital_Interface
SDI eignet sich ganz hervorragend für die Datenübertragung in einer
Richtung und wird z.B. auch dann eingesetzt, wenn schon irgendwo ein
Koaxialkabel verlegt ist und die Bild- oder Datenübertragung nun
"digitalisiert" werden soll.
Nichtsdestotrotz ist heutzutage aber Ethernet in den meisten Fällen die
mit Abstand preisgünstigste und einfachste Lösung, um Daten zu
übertragen. Insbesondere kann man dann Standardkomponenten für die
Verkabelung und Verteilung einsetzen.
Im HDMI ist 100er-Ethernet bereits vorgesehen (HEC). Musst nur zusehen,
wie du die Ethernetdaten in deinen HDMI-Chip rein- bzw rausbekommst -
viel Spaß ...
Moin,
Lordi schrieb:> Bei MACs als Chip bin ich nicht so fündig geworden.
Hm. Tja. Sind halt in so ungefaehr fast jedem µController drinnen, der
bisschen groesser ist als AVR oder die kleinen STM32. Alles was ein
(RG)MII Interface hat. Gibts auch fuer FPGAs; braucht nur eine Handvoll
Flipflops und LUTs.
> Die dürften im> Übrigen in der Preiskalkulation drin sein und wegfallen, wenn ich einen> HDMI Chip nehme. Der kann dann auch die Daten reinfummeln. Daten ins> Video geht dann natürlich nicht. Das sehe ich ein. Wenn, dann wohl Daten> als Video.
Klar kann ich mir auch mit einem Buegeleisen ein Schnitzel braten. Aber
trotzdem nimmt man eher eine Pfanne und einen Herd fuer sowas.
Irgendwie per FPGA wird man's schon schaffen, "beliebige" Daten als
"Video" aufzubereiten und ueber HDMI zu schicken und auf der anderen
Seite wieder so rauszufieseln.
Aber warum sollte man sich so einen Scheiss antun? Um Daten zu
uebertragen gibts doch schon was:Ethernet. Alles was damit zu tun hat
ist standardisiert, man kriegts en gros und en detail fast schon in
jedem Laden nachgeschmissen, muss nicht Mitglied in irgendwelchen
Organisationen werden, die Specs liegen offen, es gibt
Softwareunterstuetzung, etc. bla.
Lordi schrieb:> Welche Lösungen meinst du da? Wo müsste gemauschelt werden?
Es gibt ja HDMI Splitter zu kaufen. Aber wenn ich ein HDMI Signal habe,
was ich an 2 Monitore verteilen moechte, dann kann ich der HDMI Quelle
nur die EDID eines Monitors geben. Fuer den 2. muss ich davon
ausgehen, dasses schon irgendwie passt. Tuts meistens. Aber nicht immer.
Bei Ethernet nehm' ich einen Allerweltsswitch und kann so viele
Teilnehmer anschliessen, wie dranpassen. Wenn ich was an alle schicken
will, mach' ich's z.b. per Multicast.
Alles was mit SDI zu tun hat, ist gegenueber Ethernet wucherteuer. Ich
kann Daten als Ancillary Data reinbauen, aber auch nur in den
Blankingphasen. Als Video zu verschicken ist auch voellig irre vom
Aufwand her.
OK, die Stecker haben Verriegelungen - Vorteil :-)
Gruss
WK
Dergute W. schrieb:> Alles was mit SDI zu tun hat, ist gegenueber Ethernet wucherteuer. Ich> kann Daten als Ancillary Data reinbauen, aber auch nur in den> Blankingphasen. Als Video zu verschicken ist auch voellig irre vom> Aufwand her.
Ich habe selbst schon an einem Projekt gearbeitet, bei denen SDI-Treiber
an jeweils einem FPGA verwendet wurden, jedoch ohne das ganze
Fernsehprotokoll. Nur die Nutzdatenrate von 1,475 GS und ein
gleichspannungsfreier Leitungscode waren wichtig.
