mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #829] ESP32 and GoPro Hero 6 CONNECTION LOST #695
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#695
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alinscodes on GitHub (Feb 18, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/829
Hi.
I have established a connection where the ESP32 connects to the wifi hotstop of the GoPro but it loses connection after exactly 10 minutes and I don't know how to stop that.
The ESP32 connects to the hotspot created by the GoPro. I use http commands to control the GoPro.
I sent http command to record and after 10 minutes the connection fails and I can't stop the gopro from recording with another http command.
Why is this happening and how can I stop the connection from getting cut.
The connection is lost exactly after 10 minutes, is the GoPro the problem where it goes into some kind of sleep mode or turns off wifi and turns on bluetooth?
Thanks
@tablatronix commented on GitHub (Feb 19, 2019):
You are connecting to what to what exactly?
@mindforger commented on GitHub (Feb 19, 2019):
this may need more Details
who is the AP in this Scenario, how are you sending the requests?
There is a lot room for assumptions to make here :)
edited: the template when opening an issues is there for a reason
@tablatronix commented on GitHub (Feb 19, 2019):
Heh “between” means nothing here.
@alinscodes commented on GitHub (Feb 19, 2019):
first time using this sorry, I added more detail
@alinscodes commented on GitHub (Feb 19, 2019):
is that better?
@mindforger commented on GitHub (Feb 19, 2019):
From the gopro forum
Out of luck i guess, some people claim the 7 behaves better
@alinscodes commented on GitHub (Feb 19, 2019):
@mindforger it happens even when it is recording, to fix the problem it is wasn t recording I would wake it up and put it to sleep every 5 minutes, because it turns of wifi when it is sleeping too, but after 10 minutes exactly after recording starts it loses connection
@mindforger commented on GitHub (Feb 19, 2019):
@alinscodes this is a known issue and even happens when directly connected via the phone
but that issue with the 6 aside, is it a capacitive touch? can one stimulate the touch with pure electronics and without moving parts?! would be a funny idea to put a virtual finger on the display and fake a touch every 5 minutes or so XD
@alinscodes commented on GitHub (Feb 19, 2019):
@mindforger the GoPro will be put on commercial UAV, so that idea sounds funny but stupid for this application haha, so the HERO 7 doesn't have this problem ?
I also fixed this using a silly solution, saving the video after 9 minutes and starting it again after 1 second to keep the wifi connection alive
@KonradIT commented on GitHub (Feb 19, 2019):
Are you sending a Keep Alive packet every 3 seconds? This keeps the GoPro on and the WiFi active. Alternatively try connecting to the GoPro via BLE.
@mindforger commented on GitHub (Feb 19, 2019):
i have read people writing this but please don't go out and buy one on my comment here, check the gopro forums first for more insight, I just did a quick search for your issue there to get hints
@KonradIT commented on GitHub (Feb 19, 2019):
Literally all GoPros have this problem. It's probably that @alinscodes is not sending the keep alive message periodically.
@tablatronix commented on GitHub (Feb 20, 2019):
Do gopros have a io port that you could make a device that keeps it awake by sending harmless commands? Like fake button presses, shrug
@alinscodes commented on GitHub (Feb 20, 2019):
@KonradIT I leave it to sleep and then I send WoL packet when I wake it up in order to save battery power. But if I wait more than 10 minutes it loses connection so I try wake it up and put it to sleep every 5 minutes but the problem is when I record for more than 10 minutes it loses connection too, therefore every 9 minutes during recording I have to send command to stop recording and start again,
@alinscodes commented on GitHub (Feb 20, 2019):
@mindforger that was the information I needed, now I have to work around that gopro issue to make it do whatever I need.
@alinscodes commented on GitHub (Feb 20, 2019):
@tablatronix you can t really send WoL packet when it is recording can you?
@mindforger commented on GitHub (Feb 20, 2019):
did you try to use a HTTP keepalive?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive
this would include to not drop the TCP from the request and requires to set a keep-alive flag in the request header as far as i remember (had this stuff in college last time, so can not give insight, but maybe that helps?)
PS: maybe it also requires the gopro to support this, which maybe not the case
PPS: since you are the author of this topic, you can close it whenever you feel so yourself :)
@tablatronix commented on GitHub (Feb 20, 2019):
Sounds like this is a hardware level sleep, keep alive is probably not going to help
@alinscodes commented on GitHub (Feb 20, 2019):
yeah, not going to help, I fixed it by waking it and putting it back to sleep every 5 minutes, and then when it is recording for long duration I stop recording and start again every 9 minutes to keep wifi connection alive.
thanks guys for your replies. I appreciate it.
@KonradIT commented on GitHub (Feb 20, 2019):
Just in case someone stumbles across this issue and wants to solve this problem:
I'm the maintainer of multiple GoPro API related repositories so I've had this issue before and I know how to solve it. GoPro cameras, when the WiFi is turned on, can either be turned on or off. When the camera is turned off, the WiFi turns off after 10 minutes (in the case of HERO6 and onward, older cameras keep the WiFi on indefinitely). Bluetooth is kept on for roughly an hour in case you need to wake it up (via BT commands of course).
When the camera is turned on with wifi on, the client needs to send a keep-alive message every 2.5 seconds to avoid the camera from killing the wifi uplink after 10 minutes of inactivity. If that message is not sent the camera will turn off after a few minutes and then the wifi will be deactivated after 10 minutes. This is a measure to save power.
@tablatronix commented on GitHub (Feb 20, 2019):
Sounds easy enough, sending a keepalive using esp8266 is outside the scope of this library, BUT if anyone wants to follow up and post keep alive solutions here feel free for posterity.
@mindforger commented on GitHub (Feb 20, 2019):
Should be easy to combine, thank you @KonradIT
@alinscodes commented on GitHub (Feb 21, 2019):
@KonradIT is the keep alive message something different from sending WoL packets?
and where would I put this command and how would I send it to GoPro if I am using http commands to communicate with it ? I am a begginer so I out appreciate your help.
@KonradIT commented on GitHub (Feb 21, 2019):
Yes it's different. This weekend I plan to add some more code to GoProControl and fnally get to work on gopro32 (a BLE client for ESP32 to control multiple gopro cameras).
@alinscodes commented on GitHub (Feb 21, 2019):
@KonradIT could you direct me to an example of sending this keep alive message from esp32 to gopro please
@KonradIT commented on GitHub (Feb 21, 2019):
@alinscodes commented on GitHub (Feb 21, 2019):
Is that the keep alive message?
@KonradIT commented on GitHub (Feb 21, 2019):
That is the keep alive message. Please continue this issue on my ESP8266 library fork or my ESP32 BT library project
@KonradIT commented on GitHub (Feb 21, 2019):
8554 is the port where we send the keep alive messages and we receive the UDP live stream.