WiFi module stability issue (streaming / app connection interruptions)

[VProdAustria]

Model: Hero 11 Black (latest v2.12.70 Labs-FW) Issue: Loosing WiFi connection while streaming after random time (Streaming started with Labs QR code)

Details: The camera is randomly cancelling the connection while streaming. It can happen after a few minutes - BUT: Normaly its happening after an hour up to three or four hours. Tested also while actively getting cooled by a fan (so no overheating issue). The camera is then automatically in a loop of reconnecting / waiting for a new connection - But the camera is loosing the WiFi completely (fimrware or hardware issue).

Tested on multiple cameras (not just on one) + checked if the cameras are reachable over WiFi. It is not the case as soon as the fault is happening. The cameras are completely unreachable. Btw.: That would also explain the massive issues people have with streaming over the QUIK app (with random disconnects) - The WiFi on the cameras side is just gone / not working anymore. Possibly a general issue with the camera.

Is there a possible fix for that (on your / GoPro Labs side)? If not - Then please fwd to the main developers if needed. Thx. (Btw.: Sadly I have now four GP11 Hero Black cams lying here which I cannot use for streaming because of that issue.)

[dnewman-gpsw]

I haven't have heard of this, nor are there other reports of the WiFi going off line, but I have asked for some testing.

[VProdAustria]

Thx for the fast reply. Before trying to restart + repeat the whole code to overcome the WiFi issues like in #495 I used this code: oW1mVr1080!W!GLC!4N>r0!R17~!4R

Whats the intention? -> It Auto-Repeats the whole command as long as the initial streaming is not starting. As long as the stream + REC is ok and running its in the endless loop jumping back to position 17. THOUGH: That code was way more useful before the new firmware update a few days ago. Now its only needed anymore with no WiFi connection established. Every other case is now getting catched anyways by the live streaming start / implementation (as its also trying to re-connect if its loosing the connection while streaming + it also starts blindly streaming even with no internet connection - Just needs an active WiFi connection).

Btw. also set: WAKE=2, BYPS, BITR=5, 64BT=2500

[dnewman-gpsw]

This part is confusing me: "That code was way more useful before..." What changed? Something got better or worse?

[VProdAustria]

It got better. Before it did not start streaming in all conditions (and went into the repeat loop more often). Depending on: WiFi available, Internet available, Server available + pre-condition: Stream was running already or not. (Now more conditions are getting catched by the streaming itself. Not a big difference overall / bottom line (regarding the outcome) - But its good to see that more conditions get catched now by the streaming implementation ^^. LG

[dnewman-gpsw]

That is good news.

For the ultra-rare WiFi fail try oW1mVr1080!W!GLC!4N>r0!R16!1OR

Using an internal battery, and an always on power source.

I don't believe you should need a "soft" reset, as I'm not convinced it is why you are losing credentials (my tests are still run fine.)

[VProdAustria]

Hello again.

Hmm. In your code the ~ is missing. Should it not be: "oW1mVr1080!W!GLC!4N>r0!R16~!1OR" instead of "oW1mVr1080!W!GLC!4N>r0!R16!1OR" (?)

And is the jumping position not the 17? The code always worked with jumping position 17. Is the 1st symbol the 0 or the 1?

Btw.: Tested already a similar solution reg. WiFi fail restart -> The issue is: In the new implementation (of the new firmware) the live streaming itself tries to reconnect and never stops recording. It keeps up rolling (so I never get out of the endless loop / goto where I ask if its still recording or not). Therefor as soon as the WiFi module freezes and is not reachable anymore aka not sending anymore, its then stuck recording but not streaming anymore (always trying to reconnect over a frozen WiFi module).

Also tried already WiFi off / on at certain times (each hour or half hour). But that stops the streaming loop completely and it fails / stops due to that fault. No repeats and no continued code execution. It would be maybe possible to not record and check for an active connection instead. But I did not find a way in GoPro labs to read out the WiFi state.

Could test it without recording if there is a way to ask for an active WiFi connection (or to ask for an active stream). Though it would be great to be able to record too while streaming. Is there a way to ask GoPro labs if there is an active live stream or WiFi connection? LG

[dnewman-gpsw]

First position is zero.
~ is not needed here.

the pseudo code:

  starLS();
loop:
  Sleep(4s)
  if(recording)
  {
     goto loop;
  }
  reboot();

Only gets to reboot() if it is not recording, no else (~) needed.

It is possible to add a test for WiFi connection, maybe livestream. First I have to reproduce the failure, as testing for a condition that happens so rarely is a pain.

[VProdAustria]

Ah. That makes sense then (about ~ and pos 0). Thx.

About testing -> Just let it run over a few hours (over a night up to 12 hours is for example a perfect test). Sadly the WiFi module is buggy / freezing after a random time frame. Sometimes earlier - Sometimes later. LG

[dnewman-gpsw]

I did see one network error after about 2 hours of livestream, unfortunately I wasn't able to confirm the cause or whether network credentials were lost (they were fine when I rebooted.)

I have made a FW patch with two new system variables: n - network connected, n:L - livestreaming.

So you can now do this: oW1mVr1080!W!GLC!4N>n0!R16!1OR This will reboot only if the network fails.

Or you could try oW1mVr1080!W!GLC!4N>n:L0!R16!1OR which reboots if the livestreaming stops.

Specs: n:L - return 1 or -1 for livestreaming true or false n - return -1 or the length of the current connected SSID. So >n0 will indicate a network connection.

FW: https://www.dropbox.com/t/TgBuJmG9i2KQKZpe

[VProdAustria]

Sadly it does not work / help. Tested those four conditions:

1.) Network check + Recording while streaming !SAVEboot=oW1mVr1080!W!GLC!4N>n0!R16!1OR Fails - Network check is not working. Its jumping directly to the reboot altough the stream is running. (Actively checked that the stream is running on the server side.)

2.) Network check + NO Recording while streaming !SAVEboot=oW1mVr1080!W!GL!4N>n0!R16!1OR Same behaviour as in pt.1 (thought to test it too without REC as an active recording maybe changes the behaviour).

3.) Stream=active check + REC !SAVEboot=oW1mVr1080!W!GLC!4N>n:L0!R16!1OR Fails too - Stream keeps running in endless loop trying to reconnect = Still getting shown as being active I guess!

4.) Stream=active check + NO REC !SAVEboot=oW1mVr1080!W!GL!4N>n:L0!R16!1OR Same behaviour as in pt.3 (again tested it without REC active to be sure that its not interfering / changing behaviour).

Important: I also tested with lost internet connection + lost WiFi connection seperately. Point being -> The fault is triggering the same behaviour, that it tries to reconnect in an endless loop. So it has to work in those conditions too (lost WiFi / Internet triggered manually). LG

[dnewman-gpsw]

Two of those scripts are wrong, but it not the cause.

oW1mVr1080!W!GLC!4N>n0!R16!1OR oW1mVr1080!W!GL!4N>n0!R15!1OR oW1mVr1080!W!GLC!4N>n:L0!R16!1OR oW1mVr1080!W!GL!4N>n:L0!R15!1OR

I don't the Linux networking errors are being communicate well to Labs. Reconnecting is still live, as I'm seeing reported. I will continue to explore.

Here is a faster way to see the status in real-time "!MBOOT="!Lboot"!SAVEboot=oW1mVr1080!W!GL"net $n live $n:L Rec $r">n:L0!R15!1OR"

[VProdAustria]

Ah yeah - Right. Forgot about adapting the goto / jump points. (Too much testing around lately ^^). But it made no difference no. Thx for your support and for the status output hint. Will try it out.