Am Mittwoch, 30. Dezember 2020, 05:25:54 CET schrieb Sonali Warunjikar:
> On Wed, Dec 30, 2020 at 12:38:53AM +0100, Karsten Hilbert wrote:
> > I agree. It seems quite likely to be more setup of the device.
> To be precise I do not know how to issue two back to back 'S' without a
> 'C' occurring in between.
> 1.007.001 S Ii 0002
> 1.007.000 S Ci 0342 c0 83 0008 0000 0342
> That's the only difference left between the two traces. Does it look like
> multithreading is required for it - i.e. issue 'S Ii' with a timeout and
> in parallel (but after 'S Ii' is issued) do rest of the things and then
> sync with 'C Ii'?
> On the face of it, it's weird if multithreading is required for a serial
> communication where there is one link and two devices at both ends of it.
> But may be the device is designed to not respond to Ii until it sees those
> Cis (or timeout).
> Will try anyway.
shouldn't it be possible to find "repetition" when taking images - if feasible ? It should be possible to at least identify (even with fuzzy start and end) "data blocks". Once data blocks are identified the "stuff inbetween" should be most interesting to identify what happens. Given that nothing happens in "idle state", this should identify the communication from end of image acquistion to "next image". Theoretically replaying that should trigger a new image acquisition.
The key seems to be understanding what exactly is going on.
A piece from the person the reverse engineered the Kinect
likely, there are more recent hardware, software solutions but ...
Step 1: get dataHardware loggers:
TotalPhase Beagle 480
BusDog – Windows USB filter driver http://code.google.com/p/busdog/
Step 2: understand data
Download/extract TotalPhase Data Center for your platform:http://www.totalphase.com/products/datacenter/
Get USB trace from someone who bought a Beagle 480:git clone git://github.com/adafruit/Kinect.gitIOpenKinect/USBlogs/enuminit.tdcwith Data Center