Wireless investigations - page 8 - General Discussion and Assistance - CHDK Forum  

Wireless investigations

  • 72 Replies
  • 35087 Views
*

Offline reyalp

  • ******
  • 14083
Advertisements
I retried with the black screen trick. The sx280 seems fully working with that, I'm able to switch play<->rec, shoot.
Nice.
Quote
The M10 doesn't fully enter rec mode, shows playback screen but mode list gets populated. *If I half-press, it asks whether I want to disconnect. If I say no, it remains connected and nothing changes, otherwise connection breaks and cam enters real rec mode. Did not look for that variable yet.

edit:
*That happens to match what you described above.

edit2:
Poking the variable (0x8adc, @FC341E6C in m10 101d) resolves the problems, play<->rec switch, shooting works.
Thanks. That matches what happens on my cams.

Poking the variable has some odd side effects on my cams: On both sx710 and g7x, a bunch of menu items in the Canon settings menu are set to defaults and greyed out. Most obvious is the "mute" option, which is turned of, but looking more closely a bunch of others are too, including "AF point zoom", date / time, and on G7X "Night display". Additionally, on g7x, some func menu settings seem to be set to default (ISO becomes auto for example) and WB seems be auto, even though it shows "daylight" selected.

This makes me worry a bit about the possibility of corrupting flash params, although it seems to return to normal on reboot. I haven't tried changing settings that are still changeable.

edit:
Moved wifi specific discussion from https://chdk.setepontos.com/index.php?topic=14294.0
« Last Edit: 02 / April / 2021, 19:00:42 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14083
Re: Wireless investigations
« Reply #71 on: 18 / April / 2021, 23:12:55 »
My windows system stopped responding to camera UPnP requests, so I tried using the scripts. Attachment in the earlier post updated with minor tweaks to work on windows native python (msys2 msys already worked out of the box, I assume WSL would as well)

Note switching from windows native to the script changes the UUID seen by the camera. I had to delete my existing connection to the system from the camera UI before it was recognized.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14083
Re: Wireless investigations
« Reply #72 on: 25 / December / 2023, 22:12:19 »
Linking discussion of the mobile app pairing process (and lack of need thereof for some cameras) and shooting using Canon's PTP commands form @RaduP's thread https://chdk.setepontos.com/index.php?topic=14822.0 and adding more CHDK specific comments here:

Additional background in https://julianschroden.com/post/2023-05-28-controlling-properties-using-ptp-ip-on-canon-eos-cameras/

Summary:
* Canon's mobile apps appear to use PTP/IP
* M3 and SX730  and apparently some non-PowerShot EOS models can use the connect mobile device option without any additional UPnP glue, you can just start a PTP/IP connection from the pairing screen. The "friendly name" provided on PTP/IP startup is then "paired" with the camera (unlike the computer flow, where these values appear to be ignored and the UPnP ones used instead). Other cameras (Elph130, G7X, SX710) appear to still expect unknown UPnP or mDNS responses
* On M3 and SX730, setting device property 0xd1b0 (CANON.DPC.EOS_EVFOutputDevice) to 8 with  0x9110 (CANON.OC.EOS_SetDevicePropValueEx) switches the camera to Canon remote shooting mode, and 0 switches back. Shooting can be accomplished with other operations discussed in the thread.
* The cameras that require pairing in the mobile flow do an SSDP MSEARCH for "urn:schemas-canon-com:service:MobileConnectedCameraService:1" rather than "upnp:rootdevice"

While trying to get this to work on my cameras, I ended up exploring the firmware handling of PTP "device properties" a bit. Addresses below for SX730, 100d

In handle_PTP_OC_CANON_EOS_SetDevicePropValueEx (fc151104), the function FUN_fc3217c4 looks up a structure defining the device property. The first parameter is the property ID, the second receives a pointer to the structure. Return is lsb == 0 on success.
A function pointer in the returned structure is used to do the actual set operation.
The property structures are stored in circular linked list, searched by FUN_fc32203a

FUN_fc3217c4 is called by both the Canon extension and standard device property PTP handlers. This function is quite simple and can be called directly with call_func_ptr to inspect the associated structure outside of the context of a PTP call (though property handlers may only be registered when PTP is active).

There is presumably a function to register the device properties, which might provide a way to identify the callbacks in the sigfinder. edit: I think the property registration function is FUN_fc321f48

Other thoughts:
The response required to pair through the mobile option may be identifiable by strings, by comparison to the known strings for the computer option. OTOH, the pairing can be done on a wireless LAN, so anyone who has the app and an affected camera could probably get it quickly from with a packet capture.

The camera log may provide clues about where the pairing process diverges between the cameras that require it and those that don't.

Shooting with Canon's PTP commands may be useful, but complicated to integrate with other CHDK / chdkptp processes, since it expects to be entirely managed by the app using PTP commands. FWIW, SX730 did capture CHDK DNG for a remote shot.

Similar, using 0xd1b0 to switch to rec mode is not immediately very useful, as CHDK's keyboard based shooting breaks the connection, so integrating it with script would be complicated.

A related area that might be worth exploring is Canon's live view. While AFAIK it's low res jpeg, it should require far less bandwidth than CHDK's raw stream, which is basically unusable over the 54 mbit 802.11b/g interfaces on these cameras.
« Last Edit: 25 / December / 2023, 23:52:50 by reyalp »
Don't forget what the H stands for.

 

Related Topics