fixing last things about goprocontrol HOT 56 CLOSED

I have to admit that i also would prefer to have the library as much as possible plug&play, the idea to leave the user choose its library is nice but not everyone knows which library should they get

Anyway there is something strange, all the examples compile and run on my esp32 why is your not working? Which error do you get?
Edit: i saw now the last commenti, put also the sketch you wrote

from goprocontrol.

Good news!

This works on my HERO7 Black and Fusion:

......

IPAddress server(10,5,5,9);
void setup() {
....
}
void loop() {

  if ((WiFi.status() == WL_CONNECTED)) { 
    Serial.println("sending");

    if (client.connect(server, 80)) {
      Serial.println("connected");
    String request = "/gp/gpControl/command/shutter?p=1";
    client.println("GET " + request + " HTTP/1.1");
    client.println("Host: 10.5.5.9");
    client.println("Connection: Keep-Alive");
    client.println();
    }
    

  }

  delay(1000);

}

from goprocontrol.

Re: isOn(), I don't have a HERO3 anymore but I remember /bacpac/sd or /camera/sx or /camera/se not responding when the camera was off.

from goprocontrol.

It's your repo, so you make the rules :)

Good that finally the ESP32 is supported!

Fine by me to delete Constants.h, I thought this would be easier for debugging and pushing to GitHub.

http.end() is for ending the HTTP request.

from goprocontrol.

I thought this would be easier for debugging and pushing to GitHub

I completely agree, this way we don't have to overwrite each own SSID and password, we could keep it until we are heavily working on the lib, but I am pretty sure that some newby would find it not so easy 😆

I completed the first part of the rework:

• added the _ before the private variables (it is a kind of c/cpp tradition)
• renamed some variables and functions for readability
• added ability to change the Serial port for debug
• updated gitignore (I may have done some error so check if it is working properly before pushing!)
• removed almost all the part of code about HERO and HERO2, i guess that almost no one have these camere nowadays

http.end() is for ending the HTTP request.

yep the problem is that that line won't ever been read because there is a return before it, i think it should go after _debug_port->println(payload); tell me what do you think about
also really the variables httpCode and payload doesn't appear to be very useful because we don't use them so we should be able to delete them

If you was thinking to buy a non-esp board i could add again the code!

Tell me if you have any problem with the esp32 boards 😃

from goprocontrol.

okkkkk the settings are now reworked for a safer use! before it was possible to do something weird like setOrientation(VR_4K); now it would raise an error, I achieved it with a quite ugly part of code using enum but at least it works 😅

I added some nice looking tables in the readme!

I am having some doubts about the link between video resolution and frame rate: are them linked or not? from your repo i see that when i set a video resolution i set also a frame rate. But so what do i cange when i change directly the frame rate?

from goprocontrol.

Regarding video resolution and framerate;

• HERO3, 3+ cameras: Video Resolution will change the frame rate as well as per the API but you can also set a different Frame rate afterwards.
• HERO4 and newer: set video resolution and framerate separately.

from goprocontrol.

okkkk interesting! so i guess that in a HERO4 or later if i try to set the video resolution to 4k and the frame rate to 240 i would get a bad request or similar, correct?

with the last commit (in case we would like to remove it's id is c5b1ea7) I removed the possibility for HERO3 to choose video resolution and frame rate at the same time, now it is more similar to the newer cameras: first you set the video resolution then you set the frame rate

from goprocontrol.

Perfect!

so i guess that in a HERO4 or later if i try to set the video resolution to 4k and the frame rate to 240 i would get a bad request or similar, correct?

Exactly

Regarding the MKR boards, seems like WiFiClient is used

Regarding sending the keep alive command, seems it's not possible due to the board being single core, but we might be able to use the loop() function.

from goprocontrol.

Regarding sending the keep alive command, seems it's not possible due to the board being single core, but we might be able to use the loop() function.

Exactly, it would be the easiest approach, really the esp boards could be used with freeRTOS but I don't know how to set it up and i suspect it wouldn't be so easy so I would definitely go for a simple keepAlive() function at the end of the loop(). What do you suggest to send to the gopro as command for this function?

Regarding the MKR boards, seems like WiFiClient is used

Yesterday i tired to support these other boards but i faced few problems since the wifi API is standard but the http client is not (the HTTP functions unfortunately are different from esp* and other boards). Instead of using the HTTPClass of esp32 and esp8266 it would be better to use a different library that could work for all the client instances, like this one: https://github.com/arduino-libraries/ArduinoHttpClient

Also I think that for best maintainability we should leave the user choose which wifi library should be used, for example (pseudocode):

#include <GoProControl.h>
#include <YourWiFiLibrary.h>
YourWiFiClass client
GoProControl(client, ssid, pwd, camera);

This way the user, depending on his hardware, could include the correct library and we wouldn't have to fight with #ifdef and precompiler flags to detect the correct board. Also, meanwhile new boards and wifi library are pubblished we won't have to change a single line of code and we could focus only on the new HERO commands

Anyway have you tried the esp32? it looks far away faster to me!

from goprocontrol.

@KonradIT now the http requests are based only on the lib ArduinoHttpClient soon the lib would be ready to run on all the boards. Before i could continue there are a few things i should know:

1. do you know if there is a way to ask to the gopro if it is turned on?

2. how should be used the comfirmPairing() is it needed? with my camera i guess not, and anyway it is not working (i get a strange error and the camera stop working when i use it)

3. in hero4 and newer cameras the UDP request and the mac address are ALWAYS needed to start the connection with the wifi? or are them just a feature?

4. could you write me a point by point of what is needed to start a connection with the newer cameras? (example: sendWol > comfirm pairing > ect)

5. how should work the bluetooth with these cameras?

6. after how much time the gopro closes the connection with wifi/bluetooth? and which command do you suggest to send?

P.S: I added a function to keep the communication alive and an example showing the use of the freeRTOS use (not completed)

from goprocontrol.

Hi, I have an ESP32 board and it's indeed faster.

• confirmPairing() is used to confirm a pairing for the first time on HERO5 and newer
• The mac address is needed to send the Wake on LAN command, this is to turn the camera on
• For newer camera: check if http://10.5.5.9/gp/gpControl/status can connect (HTTP 200), if not then Wake on LAN -> then check again after a few seconds. if yes http code is 200 you can issue commands normally.
• I've been exploring bluetooth and wrote a blog post about new BT capabilities in GoPro cameras. Basically there are two modes:
  • The Pairing mode: Since HERO5 cameras, when you want to connect a phone to it for the first time you need to put the camera in pairing mode, this starts a BT server with a few characteristics such as Camera Name, camera Password and a WRITE characteristic to send commands to. This BT server is only activated when the camera is in pairing mode, so it's a pain to use it (because you have to swipe, go to connection > new connection > GoPro App and then wait). But it's proven that it works well, you can send GATT commands using gattool (list of commands here) and gatt-python works relatively well with the camera. You can try these codes with a HERO5 or newer camera
  • Undocumented BLE client mode: When GoPro had the developer program active they made a new mode for cameras which is Bluetooth mode, it's not really mentioned anywhere but it allows the camera to connect to an arbitrary server as soon as it turns on, and it will always try to connect when the Wireless mode (Wireless mode !== WiFi) is on. More about this mode on my blog post.

I've been trying to send GATT commands to the camera when it's on BLE client mode but cannot do it on the ESP32. Would be nice. As mentioned in the goprowifihack docs, we can turn off WiFi via bluetooth so the camera does not get warm and most importantly the battery lasts much longer.

• On WiFi: The camera needs a Keep Alive command to be sent every 2 seconds in order to stay on. Otherwise after a couple of minutes it turns off. Keep Alive command is shown here: https://github.com/KonradIT/gopro-py-api/blob/master/goprocam/GoProCamera.py#L70

I'll try out the ESP32 code. The ESP8266 does not support two threads due to it being single core right?

from goprocontrol.

from goprocontrol.

• confirmPairing() is used to confirm a pairing for the first time on HERO5 and newer

Great, that is why it wasn't working for my camera 😆
EDIT: i see that it would be possible also for hero4 I will try to do all

• For newer camera: check if http://10.5.5.9/gp/gpControl/status can connect (HTTP 200)

Perfect, I will use it! That is a pity that I can't know if the hero3 is turned on or off 😫

• I've been exploring bluetooth and wrote a blog post about new BT capabilities in GoPro cameras. Basically there are two modes:

ok I would really love to do it even if doesn't seem to be so easy but I would like to suggest to leave it outside for the moment and focus on the basic workings, meanwhile i will buy a new camera 😆

• On WiFi: The camera needs a Keep Alive command to be sent every 2 seconds in order to stay on. Otherwise after a couple of minutes it turns off. Keep Alive command is shown here: https://github.com/KonradIT/gopro-py-api/blob/master/goprocam/GoProCamera.py#L70

I will add it in the next commit, anyway is it possible that this is only on newer cameras? I am pretty sure that mine stays on

I'll try out the ESP32 code. The ESP8266 does not support two threads due to it being single core right?

as @telemething said it supports it but (from our point of view) the technical answer is no, because the esp8266 arduino framework isn't based on freeRTOS, see here

from goprocontrol.

ok with this last push i almost finished with the structure of the library. I wrote some function for the BLE and adding support for it shouldn't be too hard but since i don't have any new gopro i can't do it

the library should work for all the board except for the boards which used the ESP01 with AT commands, I will check if i am able to do something for them

I didn't worked on the confirmPairing() for the HERO4, but now the HERO5 should work

most notably the new constructor: now you could pass to it the mac address and other parameters for the WoL

now the isOn() function should work with HERO4 and newer

same for the keepAlive() it should work, i didn't do nothing for the HERO3 because the connection stays alive for more then 6 minutes (i didn't test the maximum), it is enough in my opinion

15:39:06.600 -> Camera connected
15:39:06.600 -> Client connected
15:39:07.604 -> HTTP request: http://10.5.5.9/camera/SH?t=xxxxx&p=%00
15:39:07.639 -> Response: 200
15:39:07.639 -> Command: Accepted

15:46:51.718 -> Camera connected
15:46:51.718 -> Client connected
15:46:52.715 -> HTTP request: http://10.5.5.9/camera/SH?t=xxxxx&p=%01
15:46:52.715 -> Response: 200
15:46:52.749 -> Command: Accepted

as always i tested only on HERO3 and esp32 if you test them in your cameras please let me know, I am curios to know if the new stuff will work!

I think that i am not going to make any big changes soon so if you want to add more stuff feel free!

anyway I saw that a lot of arduino wifi examples uses a concept like the Constant.h so we should keep them 😅

What did you meant here #6 (comment) with the parse status?

from goprocontrol.

Parse status means get the http://10.5.5.9/gp/gpControl/status JSON content and determine if the camera is recording, current mode, battery, how many minutes left of video/how many pictures left, resolution, fps...

from goprocontrol.

Okkk i thought that this was "get status"! Tell me when you have time to test the changes 😁

from goprocontrol.

Regarding the new changes... For WiFi, I think we should make it as easy as possible to deploy on ESP8266 and ESP32, so the GoProControl.h should detect which board is being sent to and include the appropiate libraries. Been trying to run the new changes to no avail.

from goprocontrol.

Because I cannot run the new changes on my ESP32 or ESP8266.

We should probably leave the WiFiClient gopro_client; WiFiUDP udp_client; to the GoProControl.h and set that up depending on the board. Constructor should look like this:

GoProControl gp( GOPRO_SSID, GOPRO_PASS, CAMERA, gopro_mac_address)

from goprocontrol.

ArduinoHttpClient refuses to work: https://hastebin.com/ifimukopoy.sql

I'd say we go back to HTTPClient since it works with ESP32 and ESP8266.

from goprocontrol.

Exactly, even I could not figure out exactly what library I needed at the first try, and even with the correct library installed (ArduinoHttpClient) it still did not work.

from goprocontrol.

I modified the constructor to what you proposed + the name of the board (it is needed for the pairing)

and tested on:

• ESP32
• MKR1000
• MKR WiFi 1010
• MKR VIDOR 4000
• UNO WiFi Rev.2
• Arduino UNO

the only board where it does not compile is the esp8266 due for a strange problem with their core, i am opening an issue right now to ask for suggestion

done: esp8266/Arduino#5858 meanwhile I manage this if you want you could test the changes in the ESP32

from goprocontrol.

I just made a test to check the wifi speed of my hero3+esp32:
time to run 10x shoot: 19:10:48.306 - 19:10:58.513 = ~10 seconds
how does you camera perform?
I made it with the arduino ide enabling the timestamp in the serial monitor and sending AAAAAAAAAA but you can do it with other terminal tool (not sure if it is possible in platformio)

19:10:48.306 -> Camera connected
19:10:48.306 -> Client connected
19:10:49.333 -> HTTP request: http://10.5.5.9/camera/SH?t=xxxx&p=%01
19:10:49.333 -> Response: 200
19:10:49.333 -> Command: Accepted
..........................
19:10:57.484 -> Camera connected
19:10:57.484 -> Client connected
19:10:58.513 -> HTTP request: http://10.5.5.9/camera/SH?t=xxxx&p=%01
19:10:58.513 -> Response: 200
19:10:58.513 -> Command: Accepted

remember to remove the delay from the end of the example

from goprocontrol.

Compiles on ESP32 finally!

I get this now:

19:45:26.829 -> 19:45:26.829 -> Not connected 19:45:26.829 -> Camera not supported

I think the enums are not setting correctly, because _camera is 0.

from goprocontrol.

I am almost sure that this line is not working

copy this and replace that line:

_ssid = ssid;
	_pwd = pwd;
	_camera = camera;

	if (_camera == HERO3) // HERO3, HERO3+, HERO3BLACK, HERO3BLACK+
	{
		// URL scheme: http://HOST/param1/PARAM2?t=PASSWORD&p=%OPTION
		// example:	  http://10.5.5.9/camera/SH?t=password&p=%01

		_url = "http://" + _host + "/camera/";
	}
	else if (_camera >= HERO4) // HERO4, 5, 6, 7:
	{
		// URL scheme: http://HOST/gp/gpControl/....
		// Basic functions (record, mode, tag, poweroff): http://HOST/gp/gpControl/command/PARAM?p=OPTION
		// example change mode to video: http://10.5.5.9/gp/gpControl/command/mode?p=0
		// Settings: http://HOST/gp/gpControl/setting/option
		// example change video resolution to 1080p: http://10.5.5.9/gp/gpControl/setting/2/9)

		_url = "http://" + _host + "/gp/gpControl/";
	}

okkk found the problem: http://www.martinbroadhurst.com/calling-one-constructor-from-another-in-c.html

from goprocontrol.

goooooood news! the esp8266 was already working on the issue we found and it will be fixed soon esp8266/Arduino#5749 (comment) thanks @JAndrassy

from goprocontrol.

goooooood news! the esp8266 was already working on the issue we found and it will be fixed soon esp8266/Arduino#5749 (comment) thanks @JAndrassy

until then use esp8266 package 2.4.2

from goprocontrol.

Good! For some reason I get a 400 bad request

20:05:15.184 -> Not connected
20:05:15.184 -> Attempting to connect to SSID: KonradHERO7Black
20:05:15.184 -> using password: dude2903
20:05:15.184 -> Attempt: 1
20:05:15.316 -> WiFi.status(): 6
20:05:15.515 -> Attempt: 2
20:05:16.179 -> WiFi.status(): 6
20:05:16.378 -> Attempt: 3
20:05:17.041 -> Connection failed
20:05:19.695 -> 
20:05:19.695 -> Not connected
20:05:19.695 -> Attempting to connect to SSID: KonradHERO7Black
20:05:19.695 -> using password: dude2903
20:05:19.695 -> Attempt: 1
20:05:19.695 -> Connected to GoPro
20:05:24.107 -> 
20:05:24.107 -> Camera connected
20:05:24.107 -> Client connected
20:05:25.136 -> HTTP request: http://10.5.5.9/gp/gpControl/status
20:05:25.136 -> Response: 400
20:05:25.136 -> Command: Unknown error
20:05:25.169 -> Client connected
20:05:26.164 -> HTTP request: http://10.5.5.9/gp/gpControl/command/shutter?p=1
20:05:26.164 -> Response: 400
20:05:26.164 -> Command: Unknown error

By the way the keep alive should be every 2 seconds to avoid spamming the camera too much.

from goprocontrol.

mmmm I am almost sure that the problem is is keepAlive try to decomment this line:

until then use esp8266 package 2.4.2

just tested, works perfectly!

from goprocontrol.

comment or decomment? I've tried both.

from goprocontrol.

sorry i meant comment, if the problem isn't there i am not sure where it could be, the request string seems good, but the gopro says it isn't 🤔

from goprocontrol.

Yeah it's weird, no problem with HTTPClient.

from goprocontrol.

What are the advantage of using ArduinoHttpClient as opposed to HTTPClient? Since ArduinoHttpClient breaks connections with HERO5, 7 and possibly any HERO4 and newer camera.

from goprocontrol.

ArduinoHttpClient will work with any wifi library, so the pros are mainly:

1. maintainability
2. no repetition of the code to support different HTTP libraries
3. it is going to become part of the official arduino API (the same as the WiFi class) so adopting it would be better for the future

The best things would be to file an issue on ArduinoHttpClient but I don't have any idea how to help the arduino's developers to find and fix this bug 😕 if you have any idea on how to do this it would be perfect

If not I suggest, for now, to use the built-in HTTPClient in the ESP* boards and in the others the ArduinoHttpClient, I am quite sure i can do some #define preprocessor to use the two libraries at the same time without any repetition of the code

example:

#if defined esp32 or esp8266
#define get GET
#endif
_http.get(request);

so one day (when and if the ArduinoHttpClient will fix the problem) we would just delete the define part and we would have all ready

P.S: i checked a few days ago the state of the BLE support on ESP32 and it is not perfectly ready yet, i saw a lot of issues of people having troubles to use it with the wifi, I would avoid to make too much effort on it for now. Let's wait and see how it goes

from goprocontrol.

@KonradIT just for my own curiosity do you have any way to check what actually send the _http.get(request) using the two libraries?

Also it would be very interesting to see exactly what the go pro app send to the camera
EDIT: done with https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture could you try this app and let me know what your phone sends to your camera?

mine:

GET /bacpac/PW?t=password&p=%01 HTTP/1.1
Host: 10.5.5.9:80
Connection: Keep-Alive

and this is the response:

HTTP/1.1 200 OK
Allow: GET 
Accept-Ranges: bytes
Cache-Control: no-cache
Cache-Control: no-store
Connection: Keep-Alive
Server: GoPro Web Server v1.0
Content-Type: application/octet-stream
Content-Length: 11

note the Keep-Alive this is why my camera doesnt't need the function keepAlive!

anyway i was thinking that the simplest way to do the http request would be to format them ourselves, no need to have any additional library, this should be enough:

client.print("GET " + request + " HTTP/1.1\r\n");
client.print("Host: " + _host + "\r\n");
client.print("Connection: Keep-Alive\r\n\r\n");

maybe the second line is not needed because we wrote the host inside the request, a few test should be done

from goprocontrol.

We can also read the response:

23:32:41.136 -> HTTP/1.1 200 OK
23:32:41.136 -> Content-Type: application/json
23:32:41.136 ->
23:32:41.136 -> {}
23:32:41.136 ->

from goprocontrol.

Great 😃 so maybe also newer camera can use the Connection: Keep-Alive!

Just to be sure if you could test the comunication between your phone and the camera it would be perfect, tomorrow i would do all the changes to make the request from the library exactly the same to the one from the phone

from goprocontrol.

Oh and my camera definitively needs the constant thread for Keep Alive.

from goprocontrol.

I talked too early ahahah 😂

from goprocontrol.

Sure, using packet capture:

GET /gp/gpControl/command/shutter?p=1 HTTP/1.1
Host: 10.5.5.9
Connection: Keep-Alive

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{}

from goprocontrol.

Okkk it is almost the same but the host is without the port (my app add ":80")

Are you able to see when the app sends the "GPHD:0:0:2:0.000000"? It could be interesting to check the formattatin of this message

from goprocontrol.

Yes, It's the same as we have it right now.

from goprocontrol.

done! All is working good in my camera, if in yours everything is ok I think we are ready to close the issue!

from goprocontrol.

Nice I'll give it an overall test tomorrow.

from goprocontrol.

2 problems still needing to be solved:

1. 13:52:58.821 -> E (99) FreeRTOS: FreeRTOS Task "keep_alive" should not return, Aborting now! in ESP32 RTOS .ino

2) gp.keepAlive() stalls server. I think if we ping /gp/gpControl/status every 5 seconds it should dothe job. (works now, I tested it again and it does send the keep alive every 2 seconds, good job!)

from goprocontrol.

#9 merged!

I am not really sure aboutn the error in freertos since i never used it, i wrote that sketch using this tutorial: https://techtutorialsx.com/2017/05/06/esp32-arduino-creating-a-task/

and googling the error i found https://www.freertos.org/implementing-a-FreeRTOS-task.html

so maybe adding vTaskDelete( NULL ); at the end of the task and putting the keepAlive inside a while should work, maybe!

edit: if we need we can change the keep alive time in Settings.h to 1500 (or other) milliseconds, it shoud be a safe interval

from goprocontrol.

#10 merged! I will make a small review of the code and clean a few function, especially i will rework the listen function and remove the String() class since it can bring to memory corruption, i added what you proposed to the todo list in the first post but, honestly, not having a camera it wouldn't be so easy for me 😅

from goprocontrol.

finishhhhhhh

so I made minimal changes to the code, mainly i edited the listenResponse() and small fixes around

I had to comment out the code for the BSSID because there was an issue of compatibility with the arduino API espressif/arduino-esp32#2613

I added a section in the readME for the next steps, if you want to make any of them https://github.com/aster94/GoProControl#to-do-list-and-known-issues

I wanted to ask you if this applies for all HERO4,5,6,7 and fusion cameras or is only for hero4? because in your repo the hero5 and newer point here

Also the function confirmPairing() is never called, i guess it should be called only once to pair a never connected before board/device, right? so we should do begin() -> confirmPairing() and then we could use the other functions. The following connection we could do only begin() without comfirmPairing() and it would work, correct?
https://github.com/KonradIT/goprowifihack/blob/master/HERO5/HERO5-Commands.md#pairing

from goprocontrol.

I wanted to ask you if this applies for all HERO4,5,6,7 and fusion cameras or is only for hero4? because in your repo the hero5 and newer point here

Technically yes, HERO6, 7 have double the framerates on each resolution except 720p, 960p and WXGVA.

Regarding pairing, it should be done when the camera is bought and turned on for the first time, this is to kick it into AP mode. This can also be done via the smartphone App.

from goprocontrol.

Regarding pairing, it should be done when the camera is bought and turned on for the first time, this is to kick it into AP mode. This can also be done via the smartphone App.

Great since the pairing process could be done from the smartphone app i would avoid passing the board_name field all the times. At the end the constructor could be without the mac_address and board_name fields, very neat!

from goprocontrol.

Yes even better.

from goprocontrol.

done 😃 now the mac_address is not needed anymore! except for the esp8266, because they have a limitation with the SDK (https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/station-class.html#bssid)

if you have the time to test the library tell me if you are able to turn on and off the camera! I didn't updated the version so you would need to manually download it, when you will confirm that all works i will update the version number

from goprocontrol.

Great! I'll test this afternoon

from goprocontrol.

Commit coming now that I tested everything on ESP32. Turing on does not seem to work yet when getting MAC address from camera via the board.

from goprocontrol.

good thanks! I will test this tomorrow!

from goprocontrol.

I run a few test:
all these are with camera connected but off:

• take a picture

HTTP/1.1 410 Gone
Allow: GET 
Accept-Ranges: bytes
Cache-Control: no-cache
Cache-Control: no-store
Connection: Keep-Alive
Server: GoPro Web Server v1.0
Content-Type: application/octet-stream
Content-Length: 1

�

• /bacpac/sd
  always respond with 200

• camera/sx

HTTP/1.1 403 Forbidden
Allow: GET 
Accept-Ranges: bytes
Cache-Control: no-cache
Cache-Control: no-store
Connection: Keep-Alive
Server: GoPro Web Server v1.0
Content-Type: text/plain
Content-Length: 15

403 Forbidden

• /camera/se

HTTP/1.1 403 Forbidden
Allow: GET 
Accept-Ranges: bytes
Cache-Control: no-cache
Cache-Control: no-store
Connection: Keep-Alive
Server: GoPro Web Server v1.0
Content-Type: text/plain
Content-Length: 15

403 Forbidden

The weird part was then from the last two request I always (both with camera on and off) get a reboot of the chip and i really can't understand whyyyy... I lost the last hour trying to figure it out with no luck, this is the output i got

Response code: 403

Stack smashing protect failure!

abort() was called at PC 0x400dbfc4 on core 1

Backtrace: 0x4008f6f4:0x3ffb1e80 0x4008f8f7:0x3ffb1ea0 0x400dbfc4:0x3ffb1ec0 0x400d235e:0x3ffb1ee0 0x400d2456:0x3ffb1f20 0x400d2707:0x3ffb1f50 0x400d19fb:0x3ffb1f80 0x4011f802:0x3ffb1fa0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:808
load:0x40078000,len:6084
load:0x40080000,len:6696
entry 0x400802e4

So for now i wasn't able to implement it ☹

from goprocontrol.