Hallo Forum, ich hab eine Anfangsfrage im Bereich nichtäquidistanter Abtastung. Mein Analogsignal (x/y-Position) wird auf einem Rechner abgetastet und über UDP Messages zu einem zweiten Rechner geschickt. Der Sender liefert keine Zeitstempel. Die übertragenen Meßwerte sind schon auf diesem Rechner nicht äquidistant. Auf der Empfängerseite wird ebenfalls nicht mit einem äquidistanten Takt gelesen. Das Signal soll geglättet dargestellt werden. Die Frequenz des Analogsignals ist im Vergleich zu der Anzahl der gelieferten Datenpakete gering. Könnt Ihr mich mal in die richtige Richtung stoßen, wie die Rekonstruktion und Glätttung auf der Empfangsseite angegangen werden muß? Danke im voraus Wolfgang R.
Einfach interpolieren und fertig....was willste ohne zeitliche Zuordnung sonst machen? Was soll denn mit dem Signal nach der "Glättung" geschehen?
Ganz offen gesagt, wieder einmal eine Frage unter falscher Flagge. Der Kernpunkt ist nicht das die Samples nicht äquidistant sind, sondern das die Zeitinformation nicht mehr vorhanden ist. Sag uns doch mal was das für Messungen sind und was Du damit anfangen willst. Dann kann man evtl. doch noch gezieltere Hinweise geben. Ansonsten würde ich sagen: Zeitstempel auf Senderseite hinzufügen. Aber das wäre wohl zu einfach.
Hmm schrieb: > Ganz offen gesagt, wieder einmal eine Frage unter falscher Flagge. > > Der Kernpunkt ist nicht das die Samples nicht äquidistant sind, sondern > das die Zeitinformation nicht mehr vorhanden ist. stimmt > > Sag uns doch mal was das für Messungen sind und was Du damit anfangen > willst. Dann kann man evtl. doch noch gezieltere Hinweise geben. Der Quellrechner berechnet ein Flugverhalten. In einem zweiten Rechner soll damit eine Außensicht gesteuert werden. Auf den ersten Rechner habe ich keinen Einfluß, aber seine Daten sind nicht so gut (glatt), wie ich es für die Außensicht benötige. > > Ansonsten würde ich sagen: Zeitstempel auf Senderseite hinzufügen. Aber > das wäre wohl zu einfach. ich muß erstmal sehen, ob ich es auf der Empfängerseite einigermaßen lösen kann
Wunder gibt es nicht, oder, um es drastischer zu sagen, man kann aus Scheiße kein Gold machen. Irgendwelche Daten werden irgendwann gemessen, irgendwann übertragen und kommen irgendwann an. Das ist Scheiße. Ehrlich gesagt, ich würde mir mit solchen Daten keine Mühe geben und sie einfach wegwerfen. Besonders, wenn es um irgendeinen Hobby-Arduino-Scheiß geht. Ist es was berufliches, und wenn das Wegwerfen aus nicht-technischen Gründen nicht geht (Kunde macht einen Aufstand), würde ich die Daten irgendwo speichern und dem Kunden vor die Füße knallen "viel Spaß bei der Auswertung". Geht das auch nicht, weil der Kunde immer noch meckert, wird jeder Datensatz beim Empfang mit einem fortlaufender Zähler versehen und fälschlich angenommen, dass die Daten in einem (unbekannten) gleichmäßigen Abstand gemessen wurden. Der Kunde darf sich dann aussuchen, welche sinnlose Interpolation er haben möchte. Noch immer nicht gut genug und Kunde zahlt noch? Dann wird jedem Datensatz beim Empfang ein Zeitstempel verpasst, der zwar nicht stimmt, aber der Kunde will es so. Die unsinnigen Abstände werden in einer sinnlosen Interpolation verwurstet, die der Kunde sich aussuchen darf. Nicht gut genug? Zurück zum Anfang - dem Kunden vor die Füße knallen und viel Spaß wünschen. Kunde stampft mit dem Fuß auf und will immer noch? Dann wird ihm eine Takt-Regenerierung programmiert und in Rechnung gestellt. Das ist zwar auch ziemlich sinnlos, wenn die Messungen gar nicht in einem definierten Takt vorgenommen wurden, aber wenn es bezahlt wird?
Mischmasch schrieb: > Dann wird ihm eine > Takt-Regenerierung programmiert und in Rechnung gestellt. Das ist zwar > auch ziemlich sinnlos, wenn die Messungen gar nicht in einem definierten > Takt vorgenommen wurden, aber wenn es bezahlt wird? Tja... wenn man wenigstens die Zeitstempel hätte, könnte man die Messwerte als B-Spline interpolieren o.ä. und dies dann in regelmäßigen Abständen samplen, um regelmäßige halbwegs genaue Werte zu erhalten. Aber so kann ich nur meinem Vorredner zustimmen...
Mischmasch schrieb: > Irgendwelche Daten werden irgendwann gemessen, irgendwann übertragen und > kommen irgendwann an. Das ist Scheiße. Nein, viel besser! Ein unbekanntes, nicht periodisches Signal wird gemessen. Die Messpunkte erfolgen in unregelmäßigen, unbekannten Abständen. Die Werte werden dann per UDP versendet, kommen nach einer unbestimmten Zeit in einer unbekannten Reihenfolge mit unbestimmten Abstand an. Eine unbekannte Anzahl Messwerten kommt garnicht an. Berechne den ursprünglichen Abstand der Messwerte. Du kannst ja noch nichtmal sagen, ob überhaupt Messungen angestellt werden wenn grade keine Pakete kommen, du hast ja keine Möglichkeit das rauszufinden. Komme wieder, wenn du irgendeines der undefiniert, unbekannt oder unregelmäßig aus dem obigen Text streichen kannst.
Guest schrieb: > Mischmasch schrieb: >> Irgendwelche Daten werden irgendwann gemessen, irgendwann übertragen und >> kommen irgendwann an. Das ist Scheiße. > > Nein, viel besser! Wie, besser als Scheiße? :-) > Die Werte werden dann > per UDP versendet, Den Teil hatte ich glatt übersehen. > kommen ... in einer > unbekannten Reihenfolge ... an. Eine unbekannte > Anzahl Messwerten kommt garnicht an. Ja, das macht es dank UDP wirklich spannend. Irgendwas passiert oder auch nicht. Dafür gibt es eine allgemein bekannte Lösung: 42
Wolfgang Rostek schrieb: > Könnt Ihr mich mal in die richtige Richtung stoßen, wie die > Rekonstruktion und Glätttung auf der Empfangsseite angegangen werden > muß? Guest schrieb: > Du kannst ja noch nichtmal sagen, ob überhaupt Messungen angestellt > werden wenn grade keine Pakete kommen, du hast ja keine Möglichkeit das > rauszufinden. Es gibt immer einen Weg. In diesem Fall mittels Statistik. Das System hat, da eine Maschine, mit hoher Wahrscheinlichkeit ein deterministisches Verhalten. Das wie gilt es herauszufinden. Mittels Vergleich der Messdaten mit den Empfangsdaten lässt sich herausfinden wie sich das ganze Verhält und eine herausfinden mit welcher Wahrscheinlichkeit die Daten plausibel sind . Damit kann man sicherlich keinen Herzschrittmacher zertifizieren, aber evtl. ist das auch gar nicht nötig. Das so was aufwändiger ist als im ersten PC die Software zu belauschen und nen Zeitstempel parallel zu übertragen steht auf einem anderen Blatt. Aber es geht ja auch nicht um rationale Überlegungen ;-).
Wolfgang Rostek schrieb: > Der Quellrechner berechnet ein Flugverhalten. In einem zweiten Rechner > soll damit eine Außensicht gesteuert werden. Auf den ersten Rechner habe > ich keinen Einfluß, aber seine Daten sind nicht so gut (glatt), wie > ich es für die Außensicht benötige. Dann lass auf deinem zweiten Rechner eine Zustandsmodell vom Flugverhalten laufen, dass die Daten vom ersten Rechner als (störüberlagerte) Messwerte bekommt und damit den (geglätteten) Zustand als Basis für die Außenansicht liefert.
Danke, in die Richtung habe ich noch nicht gedacht. Periodisch exakt ist übrigens der Transmitter Prozeß auf dem ersten Rechner. Nur das darüber liegende Flugdatenmodell ist nicht besonders gut (glatt). Für seine Zwecke ausreichend, aber nicht mehr in Verbindung mit einer Außensicht Visualisierung.
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.