Amateurfunk Forum - Archiv

Fragen und Antworten zum Thema Funk


Impressum

Verantwortlich für dieses Angebot gemäß § 5 TMG / § 55 RStV:
Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Datenschutzerklärung

Diese Datenschutzerklärung klärt Sie über die Art, den Umfang und Zweck der Verarbeitung von personenbezogenen Daten (nachfolgend kurz „Daten“) innerhalb unseres Onlineangebotes und der mit ihm verbundenen Webseiten, Funktionen und Inhalte auf (nachfolgend gemeinsam bezeichnet als „Onlineangebot“). Im Hinblick auf die verwendeten Begrifflichkeiten, wie z.B. „Verarbeitung“ oder „Verantwortlicher“ verweisen wir auf die Definitionen im Art. 4 der Datenschutzgrundverordnung (DSGVO).

Verantwortlicher

Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Arten der verarbeiteten Daten:

- Meta-/Kommunikationsdaten (siehe Abschnitt „Erhebung von Zugriffsdaten und Logfiles“)

Kategorien betroffener Personen

Besucher und Nutzer des Onlineangebotes (Nachfolgend bezeichnen wir die betroffenen Personen zusammenfassend auch als „Nutzer“).

Zweck der Verarbeitung

- Zurverfügungstellung des Onlineangebotes, seiner Funktionen und Inhalte
- Sicherheitsmaßnahmen.

Verwendete Begrifflichkeiten

„Personenbezogene Daten“ sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung (z.B. Cookie) oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.

„Verarbeitung“ ist jeder mit oder ohne Hilfe automatisierter Verfahren ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten. Der Begriff reicht weit und umfasst praktisch jeden Umgang mit Daten.

„Pseudonymisierung“ die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden.

Als „Verantwortlicher“ wird die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet, bezeichnet.

„Auftragsverarbeiter“ eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Maßgebliche Rechtsgrundlagen

Nach Maßgabe des Art. 13 DSGVO teilen wir Ihnen die Rechtsgrundlagen unserer Datenverarbeitungen mit. Sofern die Rechtsgrundlage in der Datenschutzerklärung nicht genannt wird, gilt Folgendes: Die Rechtsgrundlage für die Einholung von Einwilligungen ist Art. 6 Abs. 1 lit. a und Art. 7 DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer Leistungen und Durchführung vertraglicher Maßnahmen sowie Beantwortung von Anfragen ist Art. 6 Abs. 1 lit. b DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer rechtlichen Verpflichtungen ist Art. 6 Abs. 1 lit. c DSGVO, und die Rechtsgrundlage für die Verarbeitung zur Wahrung unserer berechtigten Interessen ist Art. 6 Abs. 1 lit. f DSGVO. Für den Fall, dass lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person eine Verarbeitung personenbezogener Daten erforderlich machen, dient Art. 6 Abs. 1 lit. d DSGVO als Rechtsgrundlage.

Sicherheitsmaßnahmen

Wir treffen nach Maßgabe des Art. 32 DSGVO unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen, geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Zu den Maßnahmen gehören insbesondere die Sicherung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten durch Kontrolle des physischen Zugangs zu den Daten, als auch des sie betreffenden Zugriffs, der Eingabe, Weitergabe, der Sicherung der Verfügbarkeit und ihrer Trennung. Des Weiteren haben wir Verfahren eingerichtet, die eine Wahrnehmung von Betroffenenrechten, Löschung von Daten und Reaktion auf Gefährdung der Daten gewährleisten. Ferner berücksichtigen wir den Schutz personenbezogener Daten bereits bei der Entwicklung, bzw. Auswahl von Hardware, Software sowie Verfahren, entsprechend dem Prinzip des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO).

Zusammenarbeit mit Auftragsverarbeitern und Dritten

Sofern wir im Rahmen unserer Verarbeitung Daten gegenüber anderen Personen und Unternehmen (Auftragsverarbeitern oder Dritten) offenbaren, sie an diese übermitteln oder ihnen sonst Zugriff auf die Daten gewähren, erfolgt dies nur auf Grundlage einer gesetzlichen Erlaubnis (z.B. wenn eine Übermittlung der Daten an Dritte, wie an Zahlungsdienstleister, gem. Art. 6 Abs. 1 lit. b DSGVO zur Vertragserfüllung erforderlich ist), Sie eingewilligt haben, eine rechtliche Verpflichtung dies vorsieht oder auf Grundlage unserer berechtigten Interessen (z.B. beim Einsatz von Beauftragten, Webhostern, etc.).

Sofern wir Dritte mit der Verarbeitung von Daten auf Grundlage eines sog. „Auftragsverarbeitungsvertrages“ beauftragen, geschieht dies auf Grundlage des Art. 28 DSGVO.

Übermittlungen in Drittländer

Sofern wir Daten in einem Drittland (d.h. außerhalb der Europäischen Union (EU) oder des Europäischen Wirtschaftsraums (EWR)) verarbeiten oder dies im Rahmen der Inanspruchnahme von Diensten Dritter oder Offenlegung, bzw. Übermittlung von Daten an Dritte geschieht, erfolgt dies nur, wenn es zur Erfüllung unserer (vor)vertraglichen Pflichten, auf Grundlage Ihrer Einwilligung, aufgrund einer rechtlichen Verpflichtung oder auf Grundlage unserer berechtigten Interessen geschieht. Vorbehaltlich gesetzlicher oder vertraglicher Erlaubnisse, verarbeiten oder lassen wir die Daten in einem Drittland nur beim Vorliegen der besonderen Voraussetzungen der Art. 44 ff. DSGVO verarbeiten. D.h. die Verarbeitung erfolgt z.B. auf Grundlage besonderer Garantien, wie der offiziell anerkannten Feststellung eines der EU entsprechenden Datenschutzniveaus (z.B. für die USA durch das „Privacy Shield“) oder Beachtung offiziell anerkannter spezieller vertraglicher Verpflichtungen (so genannte „Standardvertragsklauseln“).

Rechte der betroffenen Personen

Sie haben das Recht, eine Bestätigung darüber zu verlangen, ob betreffende Daten verarbeitet werden und auf Auskunft über diese Daten sowie auf weitere Informationen und Kopie der Daten entsprechend Art. 15 DSGVO.

Sie haben entsprechend. Art. 16 DSGVO das Recht, die Vervollständigung der Sie betreffenden Daten oder die Berichtigung der Sie betreffenden unrichtigen Daten zu verlangen.

Sie haben nach Maßgabe des Art. 17 DSGVO das Recht zu verlangen, dass betreffende Daten unverzüglich gelöscht werden, bzw. alternativ nach Maßgabe des Art. 18 DSGVO eine Einschränkung der Verarbeitung der Daten zu verlangen.

Sie haben das Recht zu verlangen, dass die Sie betreffenden Daten, die Sie uns bereitgestellt haben nach Maßgabe des Art. 20 DSGVO zu erhalten und deren Übermittlung an andere Verantwortliche zu fordern.

Sie haben ferner gem. Art. 77 DSGVO das Recht, eine Beschwerde bei der zuständigen Aufsichtsbehörde einzureichen.

Widerrufsrecht

Sie haben das Recht, erteilte Einwilligungen gem. Art. 7 Abs. 3 DSGVO mit Wirkung für die Zukunft zu widerrufen

Widerspruchsrecht

Sie können der künftigen Verarbeitung der Sie betreffenden Daten nach Maßgabe des Art. 21 DSGVO jederzeit widersprechen. Der Widerspruch kann insbesondere gegen die Verarbeitung für Zwecke der Direktwerbung erfolgen.

Löschung von Daten

Die von uns verarbeiteten Daten werden nach Maßgabe der Art. 17 und 18 DSGVO gelöscht oder in ihrer Verarbeitung eingeschränkt. Sofern nicht im Rahmen dieser Datenschutzerklärung ausdrücklich angegeben, werden die bei uns gespeicherten Daten gelöscht, sobald sie für ihre Zweckbestimmung nicht mehr erforderlich sind und der Löschung keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Sofern die Daten nicht gelöscht werden, weil sie für andere und gesetzlich zulässige Zwecke erforderlich sind, wird deren Verarbeitung eingeschränkt. D.h. die Daten werden gesperrt und nicht für andere Zwecke verarbeitet. Das gilt z.B. für Daten, die aus handels- oder steuerrechtlichen Gründen aufbewahrt werden müssen.

Nach gesetzlichen Vorgaben in Deutschland, erfolgt die Aufbewahrung insbesondere für 10 Jahre gemäß §§ 147 Abs. 1 AO, 257 Abs. 1 Nr. 1 und 4, Abs. 4 HGB (Bücher, Aufzeichnungen, Lageberichte, Buchungsbelege, Handelsbücher, für Besteuerung relevanter Unterlagen, etc.) und 6 Jahre gemäß § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB (Handelsbriefe).

Hosting und E-Mail-Versand

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, E-Mail-Versand, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieses Onlineangebotes einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Meta- und Kommunikationsdaten von Besuchern dieses Onlineangebotes auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieses Onlineangebotes gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO (Abschluss Auftragsverarbeitungsvertrag).

Erhebung von Zugriffsdaten und Logfiles

Wir, bzw. unser Hostinganbieter, erhebt auf Grundlage unserer berechtigten Interessen im Sinne des Art. 6 Abs. 1 lit. f. DSGVO Daten über jeden Zugriff auf den Server, auf dem sich dieser Dienst befindet (sogenannte Serverlogfiles). Zu den Zugriffsdaten gehören Name der abgerufenen Webseite, Datei, Datum und Uhrzeit des Abrufs, übertragene Datenmenge, Meldung über erfolgreichen Abruf, Browsertyp nebst Version, das Betriebssystem des Nutzers, Referrer URL (die zuvor besuchte Seite), IP-Adresse und der anfragende Provider.

Logfile-Informationen werden aus Sicherheitsgründen (z.B. zur Aufklärung von Missbrauchs- oder Betrugshandlungen) für die Dauer von maximal 7 Tagen gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken erforderlich ist, sind bis zur endgültigen Klärung des jeweiligen Vorfalls von der Löschung ausgenommen.

Vom Websiteinhaber angepasst
Erstellt mit Datenschutz-Generator.de von RA Dr. Thomas Schwenke




 [ 12 Beiträge ]  Gehe zu Seite 1,
Autor Nachricht
 Betreff des Beitrags: PC-Uhr synchronisieren mit einstellbarem Versatz
Liebe Funk-Kollegen,

ich arbeite gerade an einem SDR Empfänger, den ich am Antennen-Fußpunkt installieren möchte.
Die Daten vom SDR werden über WLAN zu einem PC am anderen Ende der Wohnung übertragen.
Das ganze hat ca. 2 - 3 s Laufzeit im Vergleich zum Lautsprecher-Ausgang meines "analogen" RX.

Diese Laufzeit ist für SSB und RTTY/PSK31 kein Problem.
Das ganze läuft soweit schon stabil.

Für WSPR macht das aber Probleme.
Läuft WSPR auf dem PC direkt an der Antenne, dann kann ich alles dekodieren.
Wenn ich aber die Daten übers WLAN and den anderen PC schicke, dann ist die Laufzeit wohl zu lange.
WSPR verlangt ja immer nach einer genauen PC-Uhr.
Die habe ich (PC hängt über Dimension4 am Netzwerk-Zeit-Server (NTP) und läuft synchron zum DCF77-Funkwecker).

Mein Problem:
Wie bekomme ich auf dem PC einen einstellbaren fixen Versatz (1 - 3 s) der Zeit hin?
D.h. der PC ist dann immer z.B. 3 s später als die Zeit auf dem NTP.

Hat jemand von Euch eine Idee ?

Gruß,

Thomas, DL2WB


  
 
 Betreff des Beitrags:
Dein Timeserver müsste den Client einzeln mit einer 3 Sekunden späteren Zeit versorgen, was aber so eigentlich nicht gewollt ist.

NTP-Server sind dafür da, um eine möglichst genaue Uhrzeit im Netzwerk zu verteilen und die Netzwerklatenz wird dabei herausgerechnet, sodass alle Uhren möglichst Synchron laufen.

Ich würde an Deiner Stelle eher daran ansetzen, dass Du die Netzwerk-Latenz so gering wie möglich machst, sprich verkabeltes Ethernet einsetzt.

Die Bindung der Dekodierung an eine genaue Netzwerkzeit unter 3 Sekunden Versatz ist im Protokoll schon per Design kaputt... Man setzt sowas nicht ein, wenn man weltweit kommunizieren möchte, da man nie sicherstellen kann, dass beide Kommunikationspartner die gleiche UTC-Zeitbasis haben.

Tut mir leid, wenn ich das so sagen muss, aber dieser Mode scheint schon von der Auslegung her kaputt zu sein, auch wenn man damit sehr leise Signale lesen kann.

vy 73!

Sven


  
 
 Betreff des Beitrags:
Moin,
[quote]Die Bindung der Dekodierung an eine genaue Netzwerkzeit unter 3 Sekunden Versatz ist im Protokoll schon per Design kaputt... Man setzt sowas nicht ein, wenn man weltweit kommunizieren möchte, da man nie sicherstellen kann, dass beide Kommunikationspartner die gleiche UTC-Zeitbasis haben.
[/quote]
Auf Grund dieser Expertise wird jetzt sicherlich das GPS-Design nebst einiger anderer Kommunikationssysteme noch einmal grundlegend neu überdacht werden..
[quote]
Tut mir leid, wenn ich das so sagen muss, aber dieser Mode scheint schon von der Auslegung her kaputt zu sein, auch wenn man damit sehr leise Signale lesen kann.
[/quote]
Tut mir leid, wenn ich das so sagen muß, aber wenn die 2 sec Toleranz von WSPR nicht ausreicht, ist doch allenfalls die EME-reife Übertragungsstrecke beim TE "kaputt"..

Wenn es unverändert bei der WLAN-Strecke bleiben muß,
könnte man als 'workaround' versuchen:

-die Zeit vom ntp-Client am RX-PC nur crongesteuert auslesen und mit einem experimentell zu ermittelnden Offset die eigene Systemuhr auf die benötigte "Mondzeit" einstellen lassen.
-im WSPR-Quellcode versuchen, die richtige Stelle zu finden und den benötigten Zeitversatz selbst einzubauen.

73


  
 
 Betreff des Beitrags:
ich würde auch erstmal am Netzwerk ansetzen, irgendwo müssen ja die Zeiten herkommen (evt. Paketverluste?)

Kannst mehr zur verwendeten Hard- und Software sagen?


73, Sebastian, DM5HS


  
 
 Betreff des Beitrags:
Hallo zusammen,
danke für Eure Einschätzungen!
Ich musste erst einmal nachschlagen, was "Cron-Steuerung" ist ...

Die benutze Hard- und Software ist wie folgt:

Ursprünglich wollte ich einen Raspberry Pi als Host benutzen.
Dann habe ich mich eines alten Laptops erinnert, den ich noch im Archiv hatte:

[u:lz3ku240][b:lz3ku240]Host[/b:lz3ku240] (also derjenige, der die Daten sendet):[/u:lz3ku240]
- Siemens Scenic Laptop, Pentium 400 MHz, 256 MB RAM, Win XP SP3;
WLAN-stick BIG120 im Access Point Mode; 2.4 GHz WPA2 AES "150Mbps" an USB 2.0;
SDR-RX: RTL2832 DVB-T-stick an USB 2.0;
Programm rtl_tcp.exe (ist bei SDR# inklusive)
CPU-Last ca. 20 % im Betrieb bei Streamen
WLAN-Nettodatenrate ca. 4 Mbps

[u:lz3ku240][b:lz3ku240]Client [/b:lz3ku240](also derjenige, der die Daten empfängt und auswertet):[/u:lz3ku240]
- FSC Scenic S, 1.4 GHz Pentium, 1024 MB RAM, Win XP SP3;
WLAN-stick BIG120 im Station Mode; 2.4 GHz WPA2 AES "135Mbps" an USB 2.0;
Programm SDR#
CPU-Last ca. 70 % bei Demodulation

Entfernung der beiden PCs im ersten Test ca. 1 m

Betreibe ich den SDR-stick direkt am USB des client, dann hat SDR# alleine eine Rechenzeit von gefühlt 1 - 2 s (Vergleich mit Analog-Radio).
Damit funktioniert WSPR noch zuverlässig.
Über WLAN kommt dann noch einiges hinzu.

Ich mache bei Gelegenheit noch eine Laufzeit-Messung:
- SDR über USB
- SDR remote über WLAN
- SDR remote über LAN.

Dann berichte ich wieder.

Grüße aus dem Allgäu,
Thomas, DL2WB


  
 
 Betreff des Beitrags:
[quote]Moin,
[quote]Die Bindung der Dekodierung an eine genaue Netzwerkzeit unter 3 Sekunden Versatz ist im Protokoll schon per Design kaputt... Man setzt sowas nicht ein, wenn man weltweit kommunizieren möchte, da man nie sicherstellen kann, dass beide Kommunikationspartner die gleiche UTC-Zeitbasis haben.
[/quote]
Auf Grund dieser Expertise wird jetzt sicherlich das GPS-Design nebst einiger anderer Kommunikationssysteme noch einmal grundlegend neu überdacht werden..
[/quote]

Du vergisst, dass die GPS-Satelliten eine entsprechend hochgenaue Zeitbasis (Caesium-Fontäne) an Bord haben und somit zeitlich miteinander quasi-synchron laufen.

Das Problem beim TE ist die Latenz durch die digitale Signalverarbeitung auf dem Laptop mit dem RX-Stick, der WLAN-Strecke und dem Rechner, der mit der SDR-Software die Dekodierung vornimmt.

Diese Latenzen in Summe sind größer als 2 Sekunden und bewirken, dass es nicht mehr möglich ist die Aussendungen zu Dekodieren.

Ohne jetzt WSPR im Detail zu kennen, möchte ich behaupten, dass eine synchrone Uhrzeit nicht zwingend notwendig sein wird, um eine Aussendung korrekt zu dekodieren, sondern die verwendete Software macht das nur zur Bedingung. - Wenn dies so sein sollte, so gehören dem Entwickler die Finger gebrochen, denn sowas ist schlicht und ergreifend Unfug!

Wenn allerdings bei WSPR irgendwelche Informationen im Datenstrom mit der Uhrzeit korrelieren müssen, damit die Dekodierbarkeit gegeben ist, so sprechen wir hier von einer synchronen Übertragung. In diesem Fall muss sichergestellt werden, dass Quelle und Senke eine in gewissen Grenzen gleiche Zeitbasis/Takt haben. Sollte WSPR so funktionieren, ist es für eine Notfall-Kommunikation oder einem Einsatz unter tropischen Bedingungen weitab von Telefon und Internet nicht zu gebrauchen.

vy 73!

Sven


  
 
 Betreff des Beitrags:
[quote]

[u:3hl4d0bx][b:3hl4d0bx]Host[/b:3hl4d0bx] (also derjenige, der die Daten sendet):[/u:3hl4d0bx]
- Siemens Scenic Laptop, Pentium 400 MHz, 256 MB RAM, Win XP SP3;
WLAN-stick BIG120 im Access Point Mode; 2.4 GHz WPA2 AES "150Mbps" an USB 2.0;
SDR-RX: RTL2832 DVB-T-stick an USB 2.0;
Programm rtl_tcp.exe (ist bei SDR# inklusive)
CPU-Last ca. 20 % im Betrieb bei Streamen
WLAN-Nettodatenrate ca. 4 Mbps
[/quote]

das sieht für mich schon bißchen nach Flaschenhals aus, kannst aus dem Taskmanager noch die anderen Werte bekanntgeben (Arbeitsspeicher, Festplattenaktivität, Auslagerungsdatei)


73, Sebastian


  
 
 Betreff des Beitrags:
Ich denke mal K1JT wird für seine Entwicklungen nicht umsonst von allen Seiten hochgelobt und mit Preisen bedacht. Wenn Joe Taylor da eine Zeitkonstante einbaut hat das sicherlich seinen Sinn.

Ist ja auch kein Problem mit der entsprechenden Software weltweit alle Rechner sekundengenau laufen zu lassen nur diese Streaming von, sowieso schon Latenzbehafteten, Geschichten wie SDR-Sticks auf einen weiteren Rechner verstärkt das Problem.

Mit meinem Flex am Haupt-PC habe ich trotz dieser Zeitvorgaben (ich machte JT6M, JT65A und JT9 derzeit) keine Probleme mit der Latenz wobei diese natürlich vom System her schon geringer ausfällt weil die DSP Geschichte im Flex anläuft und nicht in der Soundcard des Rechners.

Der Knoten ist vermutlich die geringe Leistungsfähigkeit der beiden eingesetzten Rechner. Die Prozessorlast des "Endrechners" lässt darauf schliessen. Um mit meinem SDR vernünftig arbeiten zu können habe ich bei mir seinerzeit von AMD 64 3200+ (2 GHz Singlecore mit Prozessorlasten je nach Programmeinsatz bis zu 80 %) gegen einen AMD FX 4100 (4 x 3,6 GHz, 8 GB Ram) eingetauscht. Prozessorlast bei nur SDR und entsprechender Steuer- und Dekodiersoftware meist immer unter 10 %. Ich halte diese alten P4 Schätzchen für solche Anwendungen schlichtweg für ungeeignet.

cu :wink: :wink:


  
 
 Betreff des Beitrags: Re: PC-Uhr synchronisieren mit einstellbarem Versatz
[quote]
Mein Problem:
Wie bekomme ich auf dem PC einen einstellbaren fixen Versatz (1 - 3 s) der Zeit hin?
D.h. der PC ist dann immer z.B. 3 s später als die Zeit auf dem NTP.
[/quote]

Es gibt Software, die es erlaubt, einen Offset einzustellen. Vielleicht hilft Dir dies weiter?

Beispiel:

http://www.top4download.com/pc-atomic-s ... gwpgu.html


  
 
 Betreff des Beitrags:
Hallo,
[quote]
Das Problem beim TE ist die Latenz durch die digitale Signalverarbeitung auf dem Laptop mit dem RX-Stick, der WLAN-Strecke und dem Rechner, der mit der SDR-Software die Dekodierung vornimmt.
[/quote]

Eben. Dort liegt das Problem, und dort muß es auch gelöst werden.
[quote]
Ohne jetzt WSPR im Detail zu kennen, möchte ich behaupten, dass eine synchrone Uhrzeit nicht zwingend notwendig sein wird, um eine Aussendung korrekt zu dekodieren, sondern die verwendete Software macht das nur zur Bedingung. - Wenn dies so sein sollte, so gehören dem Entwickler die Finger gebrochen, denn sowas ist schlicht und ergreifend Unfug!
[/quote]
Du unterstellst ganz einfach, daß der enge Zeitrahmen zur [b:30ec78rw]synchronen Dekodierung[/b:30ec78rw] benötigt würde, tatsächlich geht es jedoch um ein

[color=green:30ec78rw]protocol designed for probing potential propagation paths with low-power transmissions[/color:30ec78rw]

Vor diesem Hintergrund (globale Kartierung der KW-Ausbreitung) ist sofort einzusehen, daß man dem Anwender keine Freiheit lassen kann, seine Systemuhr z. B. 30 sec neben der UTC-Schiene laufenzulassen.

[quote]
Sollte WSPR so funktionieren, ist es für eine Notfall-Kommunikation oder einem Einsatz unter tropischen Bedingungen weitab von Telefon und Internet nicht zu gebrauchen.
[/quote]

wenn unter diesen Bedingungen ein Rechner mit dieser Software laufen kann, sollte wohl auch der Einsatz eines TCXO, der eine tägliche Zeitabweichung von unter 2 sec sicherstellt, kein unüberwindbares Hindernis sein. KW-Normalzeitaussendungen sind nach wie vor verfügbar.

In einem Punkt gebe ich Dir recht:
es sollte wenigstens möglich sein, eine Station in einem 'slave'-Modus auf die Zeit einer zeitgenauen Gegenstation zu synchronisieren.

73


  
 
 Betreff des Beitrags:
Habe die Laufzeiten aufgenommen.
Messtechnisch sind sie doch etwas anders als geschätzt...
Die Samples vom SDR sind einstellbar, 250 kSamples heißt, dass ein 250 kHz breiter Bereich im Spektrum angezeigt werden kann.

SDR über USB:
250 kSamples: 270 ms
1000 kSamples: 300 ms
2000 kSampels: 340 ms
2400 kSamples: 540 ms

SDR über TCP über WLAN:
250 kSamples: 850 ms
1000 kSamples: 850 ms

Der Host beim WLAN hat folgene Daten:
Physikalischer Speicher: 262 M
Verfügbar: 107 M
System Cache 64 M

Ich mache es jetzt so, dass ich den Client einmalig über NTP synchronisiere und danach händisch die Zeit um 1 s zurückdrehe.
Die Zeitabweichung über 3 Stunden Laufzeit ist für meinen kurzzeitigen Betrieb ausreichend.

Damit kann ich nun gut arbeiten
Danke Euch allen für die wertvollen Kommentare!

Grüße aus dem Allgäu.

Thomas, DL2WB


  
 
 Betreff des Beitrags:
Beim WLAN ist das Protokoll (Kanalbreite, ...) und der Pegel entscheidend für die Übertragungsrate. 850msec ist ja fast schon Briefpost :-) .
73 Peter


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum