Verbindungsabbrüche bei Tethering über WLAN (R6 Mark II)

[zen]

Hallo zusammen, vielleicht kann jemand helfen oder seine Erfahrungen zu dem Thema teilen. Vielen Dank im Voraus.

Das Problem: ich bekomme beim Tethering über Wireless sporadische Verbindungsabbrüche bei Verwendung der EOS Utility (v3.18.5.13, Windows 10 Pro 22H2). Kamera Firmware (1.4.0).

Am Funkkontakt kann es nicht liegen, weil sich Kamera und Fritz!Box (7590AX) im gleichen Raum befinden, nur 1,5 m auseinander stehen und keine Wand dazwischen ist.

Im Fotogeschäft sagte man mir, Tethering mit live Bild liefe auch nur mit Capture One zufriedenstellend. Die Software mag ich aber nicht von der Bedienung her und ist mir zu teuer.

Deshalb versuche ich weitgehend mit USB zu arbeiten, da verheddert es sich nur manchmal. Manchmal gibts Meldungen, die Kamera wäre noch "busy".

Aber das geht leider nur in der Nähe meines Rechners, denn so ein USB-C 3.2 Kabel ist nur 1,5 m lang.

Hat jemand Tethering über Wireless stabil am laufen? Muss auch nicht unbedingt EOS Utility sein.

Eine Vorschau auf einem 24" Monitor wäre für manche Sachen schon komfortabel, wenn man mit verschiedenen Einstellungen experimentiert.

Danke!

bearbeitet 6. August 2024 von zen

[Gast]

@zen Mit welcher WLAN Netzfrequenz ist denn deine Kamera in der Fritz!Box angemeldet? 2,4 GHz oder 5 GHz? 

[Gast]

vor einer Stunde schrieb shepherd:

@zen Mit welcher WLAN Netzfrequenz ist denn deine Kamera in der Fritz!Box angemeldet? 2,4 GHz oder 5 GHz? 

Kann die Kamera 5 GHz? Die Frage ist eher, ob die Software auf dem neuesten Stand aller updates ist.

[Gast]

vor 6 Minuten schrieb Barni:

Kann die Kamera 5 GHz? Die Frage ist eher, ob die Software auf dem neuesten Stand aller updates ist.

Die R6 Mark II kann 2,4 und 5 GHz. Und wenn man im 2,4 GHz Netz bei max. 54Mbit/s unterwegs ist, kann es bei der Übertragung großer Datenmengen schon mal zum Stau kommen.

[Yubi]

Also ich habe schon mehr mehrfach mit EOS Utility auf einem Laptop und meiner R5 Bilder übertragen. Entfernung 2-5m. Das Busy hatte ich dabei auch mehrfach. Das erklärte ich mir dadurch, das die Kamera die Bilder auf dem Laptop speichert und erst nach der Übertragung wieder bereit ist. Das Übertragen dauerte 1.5-2 sek. Bei Reihenbildern etwas inkommod aber eben mit Bordmitteln ohne zusätzliche Software und Kosten machbar. Da die R6 neuer ist nehme ich an das das Tethering mindestens so schnell wie bei mir funktioniert. 

Ist die Gegenstelle denn ebenfalls schnell ? Was für ein Protokoll unterstützt der Laptop? WLAN 802.11 b/g/n/ac/ax ? Mein Schleppi kann ax und das merkt man auch. (z.B. wenn Windows updates möchte). Das kann auch ein Flaschenhals für den Datentransfer sein. 

Verbindungsabbrüche hatte ich auch. Manchmal, wenn ich die Aufnahmen kontrolliert habe trennten sich die gekoppelten Geräte auch schon mal (time out?).

[zen]

vor 7 Stunden schrieb shepherd:

@zen Mit welcher WLAN Netzfrequenz ist denn deine Kamera in der Fritz!Box angemeldet? 2,4 GHz oder 5 GHz? 

 

Hi @shepherd danke für Deine Antwort. Die R6 verbindet sich manchmal mit einem entfernten Fritz Mesh Repeater 6000 im 5 GHz Band und da gibt es anscheinend wirklich nur einen geringen Durchsatz von 2-4 Mbit/s. Nun dachte ich schon, das wäre vielleicht die Ursache, aber selbst bei der Verbindung mit der Fritzbox im gleichen Raum im 5 GHz Band gibt es auch Verbindungsabbrüche, jedoch ist hier der Durchsatz mit rund 35 MBit/sec deutlich höher. Aus der Mesh Übersicht die Verbindung copy/pasted:

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Dabei werden um die 35 Mbit/sec. übertragen. Trotzdem gab es gerade wieder einen Disconnect.
Hier ein screenshot von meinem Gadget, das den Netzwerk Durchsatz anzeigt.

 

vor 5 Stunden schrieb Barni:

Kann die Kamera 5 GHz? Die Frage ist eher, ob die Software auf dem neuesten Stand aller updates ist.

Hi @Barni: Die Kamera kann 5 GHz, siehe oben und Kommentar von Shepherd. Die Kamera hat die aktuelle Firmware und auch die EOS Utility ist auf dem letzten Stand. Die Software-Versionen hatte ich oben angegeben.

 

vor 5 Stunden schrieb shepherd:

Die R6 Mark II kann 2,4 und 5 GHz. Und wenn man im 2,4 GHz Netz bei max. 54Mbit/s unterwegs ist, kann es bei der Übertragung großer Datenmengen schon mal zum Stau kommen.

So viel scheint aber gar nicht übertragen zu werden.
Die R6 unterstützt 802.11n und sollte mit 802.11n und TCP Protokoll ungefähr 70-90 Mbit/sec Durchsatz erreichen können, egal ob 2.4 oder 5 GHz Band.
Was ich sah, waren gerade mal unter 40 Mbit/sec. Egal ob nur Lifebild übertragen wird oder noch zusätzlich eine Aufnahme übertragen wurde.

 

vor 4 Stunden schrieb Yubi:

Also ich habe schon mehr mehrfach mit EOS Utility auf einem Laptop und meiner R5 Bilder übertragen. Entfernung 2-5m. Das Busy hatte ich dabei auch mehrfach. Das erklärte ich mir dadurch, das die Kamera die Bilder auf dem Laptop speichert und erst nach der Übertragung wieder bereit ist. Das Übertragen dauerte 1.5-2 sek. Bei Reihenbildern etwas inkommod aber eben mit Bordmitteln ohne zusätzliche Software und Kosten machbar. Da die R6 neuer ist nehme ich an das das Tethering mindestens so schnell wie bei mir funktioniert. 

Ist die Gegenstelle denn ebenfalls schnell ? Was für ein Protokoll unterstützt der Laptop? WLAN 802.11 b/g/n/ac/ax ? Mein Schleppi kann ax und das merkt man auch. (z.B. wenn Windows updates möchte). Das kann auch ein Flaschenhals für den Datentransfer sein. 

Verbindungsabbrüche hatte ich auch. Manchmal, wenn ich die Aufnahmen kontrolliert habe trennten sich die gekoppelten Geräte auch schon mal (time out?).

Die sporadischen Abbrüche passieren, auch wenn gerade kein Bild gemacht wird. Es ist kein Laptop in Verwendung, sondern ein gut optimiertes Silent System für Gaming und Recording mit geringen DPC Latenzen. Bilder siehe unten.

Das System:
Mainboard: Supermicro X10SRi-F (Server Mainboard)
CPU: Intel Xeon E5-1680v4 (BTW, vor einem Jahr für rund €160 günstig bei eBay geschossen, der 8-Kerner kostete früher mal €1750)
DRAM: 64 GB ECC
GPU: nVidia MSI RTX 4070 Ventus 3X E, 12 GB
LAN Adapter: Intel X710-DA2 (2x SFP+) 10 Gbit, angeschlossen an QNAP 10Gbit Switch
SSD: Samsung 870 EVO 4 TB

Das Netzwerk ist folgendermaßen aufgebaut:

                                                                                                                      VDSL250
                                                                                                                            |
PC#1(meiner)---10Gbit---[OM4 fiber]---QNAP 10G Switch---1Gbit Kupfer---Fritzbox7590AX (Mesh-Master)----WLAN-Mesh---2x Fritz!Repeater 6000 (Küche+Zimmer dahinter)
PC#2(Family)---10Gbit---[OM4 fiber]----/                                                                               |
                                                                                                                                               +---Canon R6 Mark II                              

Wo ich das alles tippe, sehe ich mehrfach die Verbindung abrauchen, ohne dass ich die EOS Utility überhaupt bediene.
Die Kamera versucht anscheinend automatisch, wieder eine Verbindung herzustellen, denn die EOS Utility wird im Hintergrund ohne mein Dazutun neu gestartet.

Grüße
Zen

P.S.: Das System hat geringe DPC Latenzen (LatencyMon Messung), CPU Cores werden also nicht durch schlechte Treiber zu lange blockiert.

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for  0:06:11  (h:mm:ss) on processors 0,1,2,3,4,5,6,7,8,9,10 and 11.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        SUPERMICRO
OS version:                                           Windows 10, 10.0, version 2009, build: 19045 (x64)
Hardware:                                             Super Server, Supermicro
BIOS:                                                 BIOS Date: 06/09/21 11:40:18 Ver: 05.0000B
CPU:                                                  GenuineIntel Intel(R) Xeon(R) CPU E5-1680 v4 @ 3.40GHz
Logical processors:                                   16
Processor groups:                                     1
Processor group size:                                 16
RAM:                                                  65404 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI):                             3401 MHz
Reported CPU speed (registry):                        340 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO DPC LATENCIES
_________________________________________________________________________________________________________
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.

Highest measured interrupt to DPC latency (µs):       130,673032
Average measured interrupt to DPC latency (µs):       9,737032


_________________________________________________________________________________________________________
 REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs):              34,541765
Driver with highest ISR routine execution time:       Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Highest reported total ISR routine time (%):          0,001783
Driver with highest ISR total time:                   Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in ISRs (%)                          0,001848

ISR count (execution time <250 µs):                   294297
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-1000 µs):               0
ISR count (execution time 1000-2000 µs):              0
ISR count (execution time 2000-4000 µs):              0
ISR count (execution time >=4000 µs):                 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs):              154,120
Driver with highest DPC routine execution time:       tcpip.sys - TCP/IP-Treiber, Microsoft Corporation

Highest reported total DPC routine time (%):          0,022602
Driver with highest DPC total execution time:         Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in DPCs (%)                          0,045145

DPC count (execution time <250 µs):                   442516
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-10000 µs):              0
DPC count (execution time 1000-2000 µs):              0
DPC count (execution time 2000-4000 µs):              0
DPC count (execution time >=4000 µs):                 0


_________________________________________________________________________________________________________
 REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count:                 greenshot.exe

Total number of hard pagefaults                       817
Hard pagefault count of hardest hit process:          238
Number of processes hit:                              18


_________________________________________________________________________________________________________
 PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       5,644438
CPU 0 ISR highest execution time (µs):                34,541765
CPU 0 ISR total execution time (s):                   0,109861
CPU 0 ISR count:                                      294238
CPU 0 DPC highest execution time (µs):                154,120
CPU 0 DPC total execution time (s):                   2,612370
CPU 0 DPC count:                                      429992
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       0,399511
CPU 1 ISR highest execution time (µs):                1,126471
CPU 1 ISR total execution time (s):                   0,000033
CPU 1 ISR count:                                      59
CPU 1 DPC highest execution time (µs):                39,490
CPU 1 DPC total execution time (s):                   0,001280
CPU 1 DPC count:                                      235
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       0,532823
CPU 2 ISR highest execution time (µs):                0,0
CPU 2 ISR total execution time (s):                   0,0
CPU 2 ISR count:                                      0
CPU 2 DPC highest execution time (µs):                133,670882
CPU 2 DPC total execution time (s):                   0,010703
CPU 2 DPC count:                                      2250
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       0,465582
CPU 3 ISR highest execution time (µs):                0,0
CPU 3 ISR total execution time (s):                   0,0
CPU 3 ISR count:                                      0
CPU 3 DPC highest execution time (µs):                53,408235
CPU 3 DPC total execution time (s):                   0,004591
CPU 3 DPC count:                                      912
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s):                       0,580858
CPU 4 ISR highest execution time (µs):                0,0
CPU 4 ISR total execution time (s):                   0,0
CPU 4 ISR count:                                      0
CPU 4 DPC highest execution time (µs):                138,960
CPU 4 DPC total execution time (s):                   0,036437
CPU 4 DPC count:                                      5551
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s):                       0,400458
CPU 5 ISR highest execution time (µs):                0,0
CPU 5 ISR total execution time (s):                   0,0
CPU 5 ISR count:                                      0
CPU 5 DPC highest execution time (µs):                9,156176
CPU 5 DPC total execution time (s):                   0,000020
CPU 5 DPC count:                                      3
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s):                       0,493531
CPU 6 ISR highest execution time (µs):                0,0
CPU 6 ISR total execution time (s):                   0,0
CPU 6 ISR count:                                      0
CPU 6 DPC highest execution time (µs):                82,777353
CPU 6 DPC total execution time (s):                   0,004780
CPU 6 DPC count:                                      842
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s):                       0,397713
CPU 7 ISR highest execution time (µs):                0,0
CPU 7 ISR total execution time (s):                   0,0
CPU 7 ISR count:                                      0
CPU 7 DPC highest execution time (µs):                32,528235
CPU 7 DPC total execution time (s):                   0,001686
CPU 7 DPC count:                                      722
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s):                       0,526287
CPU 8 ISR highest execution time (µs):                0,0
CPU 8 ISR total execution time (s):                   0,0
CPU 8 ISR count:                                      0
CPU 8 DPC highest execution time (µs):                106,936176
CPU 8 DPC total execution time (s):                   0,008619
CPU 8 DPC count:                                      1153
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s):                       0,378830
CPU 9 ISR highest execution time (µs):                0,0
CPU 9 ISR total execution time (s):                   0,0
CPU 9 ISR count:                                      0
CPU 9 DPC highest execution time (µs):                43,930882
CPU 9 DPC total execution time (s):                   0,000152
CPU 9 DPC count:                                      47
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s):                       0,462143
CPU 10 ISR highest execution time (µs):                0,0
CPU 10 ISR total execution time (s):                   0,0
CPU 10 ISR count:                                      0
CPU 10 DPC highest execution time (µs):                48,142647
CPU 10 DPC total execution time (s):                   0,003674
CPU 10 DPC count:                                      646
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s):                       0,421295
CPU 11 ISR highest execution time (µs):                0,0
CPU 11 ISR total execution time (s):                   0,0
CPU 11 ISR count:                                      0
CPU 11 DPC highest execution time (µs):                39,102647
CPU 11 DPC total execution time (s):                   0,000897
CPU 11 DPC count:                                      163

bearbeitet 6. August 2024 von zen

[Gast]

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Eine Fritz!Box in der geschlossenen untersten Schublade eines Schreibtisches oder einer Garderobe zu betreiben, ist aus meiner Sicht ein denkbar ungünstiger Ort. Die Fritz!Box heizt sich im laufenden Betrieb aufgrund mangelnder Luftzirkulation auf und drosselt ihre Leistung. Und eine geschlossene Schublade mit unter Spannung stehenden Netzteilen behindert die integrierten Antennen der Fritz!Box und stört sowohl die Sende- als auch die Empfangsleistung.

bearbeitet 7. August 2024 von shepherd

[Franky S.]

Hallo @zen,

Wir haben die gleiche Fritz Box, und vor einiger Zeit ähnliches erlebt- sporadische Einbrüche bei wlan Datentransfer. Es dauerte immer einige Zeit, bis die Datenrate beim Übertragen anstieg. 

Bin dann in die Einstellungen der Fritz Box gegangen, und siehe da, im Energiespar Management war der Punkt "Energiesparmodus" angeklickt:

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Ist wohl bei einem früheren Fritz update so standardmäßig eingestellt, warum auch immer. Habe das dann wieder umgestellt, und seitdem laufen Übertragungen verzögerungsfrei. 

Und, ja, die Fritz Box wird im Betrieb schon warm, auch bei uns, wo sie frei auf einem Bord steht. Der Platz in der Schublade, noch dazu mit switch und allerlei Kabeln, könnte in der Tat thermische Probleme bereiten, und das wlan beeinträchtigen. 

[zen]

Dankeschön für Eure Nachricht und Kommentare.
Aber es scheint wohl doch ein Applikationsproblem zu sein, denn mit dem andere Fotobearbeitungsprogramm lief es deutlich besser.

Arbeite zwar selbst im IT/Netzwerkbereich und hätte das eine oder andere eh in diese Richtung kommentiert. Aber ich wollte Eure Arbeit auch damit honorieren, dass ich dann doch mal heute Morgen beim AVM Support angerufen habe, um verschiedene Dinge auszuschließen bzw. AVM das gegenchecken zu lassen.
Die waren wirklich sehr nett und haben sich fast 25 Minuten dafür Zeit genommen. Alle Achtung!

 

@shepherd 

Du hast recht, der Aufstellungsort ist nicht ideal und der AVM Support teilte mir mit, dass die Fritzbox am besten bei Wandaufhängung abstrahlen würde.
Eine WLAN Ausleuchtung ergab aber, dass die erreichte Signalstärke trotz nicht idealer Aufstellung völlig in Ordnung ist, das bestätigte mir auch der AVM Support.
Siehe die Screenshots, die ich mit dem AVM Tool „Fritz!App WLAN“ mit Smartphone durchgeführt habe.
Letzten Endes kommt es auf die Signalstärke an, was noch an der Antenne des Clients ankommt.

Messung: ich habe das Smartphone also an der Stelle hingelegt, an der die Kamera vorher stand und auch mal links und rechts davon.
Ergebnis: die Signalstärke liegt noch im Bereich -30dBm - -50 dBm, was als sehr starkes Signal bezeichnet werden kann, somit ideal für alle Anwendungen.
Bei der WLAN-Messung über diese App kamen Durchsatzraten von über 250 Mbit/sec raus, was weit über dem liegt, was die Kamera für die Übertragung bei 802.11n benötigt.
Beim Download von Bildern von der Kamera komme ich sogar auf einen Durchsatz von 70-80 Mbit/sec. Bei dem Livebild werden anscheinend nur 35 Mbit/sec benötigt.

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Was die Temperaturen anbelangt sind sie seitens AVM nicht optimal, aber noch deutlich entfernt von Werten, bei denen man sich Sorgen machen müsste.
Jedenfalls nichts, was in irgendeiner Form die Leistung der Fritzbox schmälern würde.
Wenn der rote Balken erreicht wird, dann könnte langsam die Hardware Schaden nehmen und schneller abnutzen.
Nichtsdestotrotz habe ich ein paar Gummimuffen zusätzlich als Abstandshalter eingesetzt, damit von unten noch mehr Luft an das Gerät kann.
Das Thermometer zeigt die Temperatur auf dem Gerät.
Zusammenfassend gesagt: auch lt. AVM Support nichts, worüber man sich Sorgen machen müsste und erklärt die Abbrüche in keinster Weise.
Vermutlich ein Applikationsproblem (seitens Canon).
Denn .. mit dem anderen Programm funktionierte es deutlich besser, wenn ich mich recht entsinne auch komplett störungsfrei.

@Franky S.

Die Energieeinstellungen habe ich überprüft. Es war überhaupt keine Einstellung selektiert. Wer weiß, vielleicht war GUI inkonsistent nach einigen Updates. Ich habe die jetzige CPU Auslastung mit den 2 möglichen Einstellungen verglichen und komme zu dem Schluss, dass ich vorher auch ausgeglichen, also kein Energiesparen, aktiv  hatte, denn die CPU Auslastung war gleich und wurde nur bei Energiesparen deutlich geringer.

Hier ein paar Ansichten aus der AVM WLAN App.

 

 

[Gast]

vor 49 Minuten schrieb zen:

Vermutlich ein Applikationsproblem (seitens Canon).
Denn .. mit dem anderen Programm funktionierte es deutlich besser, wenn ich mich recht entsinne auch komplett störungsfrei.

Dann weißt du jetzt ja Bescheid. Nicht die Fritz!Box und ihre Positionierung sind schuld, sondern vermutlich Canons App, die du nutzt. Wem glaubst du mehr: AVM oder Canon?😉

90 Grad Celsius in der AVM CPU halte ich schon für ziemlich heiß...🤔 Meine läuft bei 50-60 Grad Celsius - und das in einer sommerlich temperierten Dachgeschosswohnung.

bearbeitet 7. August 2024 von shepherd

[zen]

vor 18 Minuten schrieb shepherd:

Dann weißt du jetzt ja Bescheid. Nicht die Fritz!Box und ihre Positionierung sind schuld, sondern vermutlich Canons App, die du nutzt. Wem glaubst du mehr: AVM oder Canon?

90 Grad Celsius in der AVM CPU halte ich schon für ziemlich heiß...😉

Das ist aber keine Glaubensfrage 😉
Im Übrigen, es gibt heutzutage viele Komponenten (auch CPUen, GPUen), die hohe Temperaturen von über 80 oder 90 °C in den Specs haben.
Wenn AVM sagt, das ist so weit okay, dann ist das erst einmal okay.

Und vor allem .. unter Capture One funktionierte es doch in diesem Setup ohne Abbrüche.
Ergibt also keinen Sinn, hier auf Temperaturen als Haupt-Fehlerursache zu vermuten.

Was Canon anbelangt, haben die so etwas wie einen Heiligenschein für Dich auf oder wie soll ich Deine Aussage deuten? 😉

Leistenschneider sagte von vorneherein im Verkaufsgespräch, als ich nach Tethering über WLAN fragte, es würde mit der Canon eigenen EOS Utility über Wireless nicht zuverlässig funktionieren. Ihrer Erfahrung ginge das nur mit Capture One. Und das kann ich - Stand jetzt - auch leider nur bestätigen,

Mit meiner Anfrage hier im Forum wollte ich hauptsächlich herausfinden, ob es anderen auch so geht oder wo es vielleicht funktioniert und wenn ja, warum.
Nach meinem Urlaub wollte ich dann vielleicht mal einen Case bei Canon öffnen, wenn ich genügend Zeit dafür habe.

Auf jeden Fall vielen Dank für Eure Meinung und Antworten soweit.

Falls jemand noch ein Tool kennt, das auch gut funktionieren könnte, nur zu ...

Merci.

[Gast]

vor 8 Minuten schrieb zen:

Was Canon anbelangt, haben die so etwas wie einen Heiligenschein für Dich auf oder wie soll ich Deine Aussage deuten? 😉

Nein. Canon hat natürlich keinen Heiligenschein für mich auf. Mir ist von Canon auch schon mal was verreckt. Von AVM allerdings auch. Den telefonischen Kundendienst von AVM finde ich sehr kompetent. Vor allen Dingen bekommt man sofort jemanden in die Leitung, der einem weiterhilft, wenn es Probleme gibt. Bei Canon meiner Erfahrung nach nicht. Wahrscheinlich weil ich nicht zahlendes Mitglied im CPS bin. Persönlich traue ich AVM mehr über den Weg als Canon.

[Gr3if]

Wenn ich am Wochenende mal Zeit habe würde ich das einmal testen.

Hast du 2,4 und 5ghz mit 2 SSIds? nicht das die Fritzbox einen Switch auslöst und dabei die Software auf die Nase klatscht?

[zen]

vor 32 Minuten schrieb Gr3if:

Wenn ich am Wochenende mal Zeit habe würde ich das einmal testen.

Hast du 2,4 und 5ghz mit 2 SSIds? nicht das die Fritzbox einen Switch auslöst und dabei die Software auf die Nase klatscht?

Danke für Deine Antwort. Das spielt sich alles im 5 GHz Band ab, Übertragungsrate liegt bei rund 25 MBit, wie Du rechts an dem Netzwerk Gadget sehen kannst. Hier mal ein Screenshot.

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Ich habe einen Sniffertrace mitgeschnitten und nach dem TCP Stream zwischen Kamera und Rechner gefiltert. Siehe unten.

RST (Reset) und ACK (Acknowledgment) Paket in der TCP-Verbindung signalisieren, dass eine Seite die Verbindung abrupt beenden möchte. Dies kann aus verschiedenen Gründen geschehen. In diesem Fall weist das RST-Paket darauf hin, dass die Canon R6 Mark II die bestehende Verbindung mit dem Rechner unerwartet beendet hat.

Das müsste Canon weiter Troubleshooten, warum es zu einem Reset bei einer laufenden Session kommt. Ich bin ja lt. Fotogeschäft kein Einzelfall. Und dass es besser geht, zeigt die Applikation Capture One.

 

[Gr3if]

Jo das riecht dann nach einem Thema für Canon bin ich total dabei. Ansonsten wäre imho noch eine Möglichkeit mit dem PC das Wlan der Kamera zu joinen. Dann ist zwar nebenher kein Internet mehr am PC, aber wenn die Verbindung dann stabil ist?

[zen]

vor 20 Stunden schrieb Gr3if:

Jo das riecht dann nach einem Thema für Canon bin ich total dabei. Ansonsten wäre imho noch eine Möglichkeit mit dem PC das Wlan der Kamera zu joinen. Dann ist zwar nebenher kein Internet mehr am PC, aber wenn die Verbindung dann stabil ist?

Prinzipiell eine gute Idee, aber ich halte es für sehr unwahrscheinlich, dass es etwas ändern würde.
Leistenschneider Düsseldorf sagte mir ja bereits, dass sie und Ihre Kunden die Erfahrung gemacht hätten, dass es mit der EOS Utility über Wi-Fi nicht stabil funktionieren würde, es ginge nur mit Capture One. Wohingegen eine Verbindung über USB3 keine Probleme bereitet, aber das USB-C Kabel ist leider nicht lang genug.
Hinzu kommt, dass der Rechner selbst nicht über Wi-Fi angebunden ist und ich auch keine Wi-Fi-Karte zur Hand habe. Diese könnte auch nicht im Rechner verbleiben, weil er bereits voll bestückt ist und jede der PCIe-Karten benötigt wird. Dabei ist das Server-Mainboard von Supermicro (X10SRi-F) schon sehr flexibel, was die Anzahl der PCIe Erweiterungssteckplätze und Ausstattung mit PCIe 3.0/2.0-Lanes anbelangt...

Da ich für den Case (wenn ich mal Zeit dazu finde) vermutlich ohnehin ein Netzwerk-Diagramm benötige, hier schon mal eins als Übersicht:

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

bearbeitet 27. August 2024 von zen

[zen]

Auch bei Verbindungen über den Fritz!Repeater das gleiche Verhalten, dass die Canon mit "RST" die TCP Session beendet.

Hallo, lieber Besucher! Als Mitglied würdest du hier ein Bild sehen…

Hier einfach kostenlos anmelden – Wir freuen uns immer über neue Mitglieder!

Zu dem Zeitpunkt sah das WLAN so aus und die Fritz!box hat folgende Verbindung zu den Mesh Repeatern.

 

[Gr3if]

Jo wie gesagt: Bin total bei dir. Man kann nur nach "Funky" Dingen schauen ob zb. das weiterleiten der Fritzbox im Mesh events triggert zb.

--> Canon Support mal direkt angeschrieben? Oder keine Lust?

Es gibt leider auch für die R6 keinen RJ45 Port, für die R5 gibt es da einen Griff/ Nachrüstoption.

[zen]

vor 10 Stunden schrieb Gr3if:

Jo wie gesagt: Bin total bei dir. Man kann nur nach "Funky" Dingen schauen ob zb. das weiterleiten der Fritzbox im Mesh events triggert zb.

--> Canon Support mal direkt angeschrieben? Oder keine Lust?

Es gibt leider auch für die R6 keinen RJ45 Port, für die R5 gibt es da einen Griff/ Nachrüstoption.

Danke für Deine Antwort.

Tut mir Leid, ich habe momentan keine Zeit dazu. Wenn Du es eilig hast, dann mach doch bitte selbst einen Case bei Canon auf.
Installier Dir auch Wireshark, Sniffer mal mit und schau Dir an, ob auch bei Dir die Kamera mit RST die Session bei einem Life Bild beendet.

Kurzer Kommentar zu Deiner Bemerkung. Also noch einmal zusammengefasst:
1. wenn das WLAN schuld wäre, dann würde die Kamera die TCP Session nicht ordentlich mit einem RST beenden
2. wie schon mal erwähnt, mit Capture One funktioniert das über das gleiche Wireless Netzwerk, also kann es kein Problem mit diesem Wi-Fi Netzwerk geben, das ist bei mir stabil.
3. Leistenschneider D'dorf sagte mir aus eigener Erfahrung und aus Kunden-Feedback: Tethering über Wireless würde nur mit Capture One stabil funktionieren, nicht aber mit der EOS Utility. Das gäbe Abbrüche und genau die haben wir ja auch. Habe ich selbst mit einer Demo von Capture One getestet, stimmt. Hilft mir aber nicht weiter, die Software gefällt mir von der Bedienung nicht. Nur fürs Tethering über Wireless werde ich sie nicht für teuer Geld kaufen.