linuxtrack
linuxtrack copied to clipboard
uglyDwarf
Data receive request timed out when using trackir5 device
I have a trackir5 device and I confirm it to work under Windows10. I want to set up track under my Archlinux. I tried both building linuxtrack 0.99.19 from source and using universal package 0.99.17_tir5v3. I set up trackir devices and extraced firmware as directed and log shows no error message. However when I clicked the 'start' button the tracking windows shows nothing. 3d view also won't respond to my head movement. I noticed two line of error in log:
`Problem writing data to TIR@ep 1! -7 - 0 transferred
Data receive request timed out! `
Any idea what is wrong?
The full log is attached. log.txt
Hello, can you try the current universal package that is here: https://github.com/uglyDwarf/linuxtrack/wiki/Downloads ? Kind regards, Michal
Can you try the following? Close / kill all linuxtrack related things (ltr_gui, ltr_pipe), go to the /tmp and remove all linuxtrack*.log files, then start the ltr_gui, try starting the tracking and then in the Misc pane press the package logs button? That way I should get the complete picture... One more thing - is the device plugged directly to the PC, or do you use some extension cord/hub? If so please try plugging it directly to the PC (preferably USB2 port, if you have one available)... Thank you, Michal
I can't use package logs because it says "couldn't create the package! please check that you have write access to the destination directory!" even I want to create the zip directly under my home.
If linuxtrack00.log contains all the infromation you need, I packaged it manually here: log.tar.gz
The device is plugged directly to my PC using a usb3 port as I don't have a usb2 port on my laptop.
This is strange - it seems everything is OK until the tracking is started...
I've seen reports on the NP's forums of TrackIR's strange behaviour when connected to the USB3 port- they recommend using USB2 ports if available... Just out of curiosity do you have a USB2 hub available? Could you try connecting it through that?
The only other thing I can think of is to try starting the tracking several times if the first attempt fails... Will keep you posted...
Kind regards, Michal
Hello, one more thing - may I try to ask you to run the ltr_gui like below and send me the log? (adjust the path as necessary)
LINUXTRACK_DBG=u ./ltr_gui
This will dump the actual communication and I'll see what is actualy happening... Thank you, Michal
Here's the result of LINUXTRACK_DBG=u log-all.tar.gz
The status LED works, and the 4 IR emitters flash for a brief moment at the start of tracking, but then go off.
I need to find a usb2 hub to further test it.
Hello, I'll try to go through the logs, but so far it seems that when the video is turned on, the next command times out... One more idea you could try more easily - what happens when you leave only the TrackIR plugged in? And by the way, when the TrackIR fails to work, isn't something interesting in the dmesg or a system log? I think I saw something interesting in the logs, will dig deeper and let you know if I find something... Kind regards, Michal
I unplugged all usb devices and then only plugged in the TrackIR (The webcam is on an internal usb port). The tracking still doesn't work. I attached the new log, however I didn't notice any interesting change from the previous one. log.tar.gz
dmesg also shows nothing but devices plugged out/in.
Hello, there is something funny going on in here... Looking at the status packet, everything should be good - the firmware is loaded, the checksum is correct and the device should be ready to go until the video should start... There is one thing that bothers me though - the configuration info is somewhat strange - there are values in there that I haven't seen before... It also looks that your device wad one of last version 2 devices (according to the serial number)...
At this point there is only one thing that I can think of, that might shed some light into the issue... Do you have an access to a windows machine, where you could install the TrackIR software along with the USBLyzer ( http://www.usblyzer.com/ )? The USBLyzer would allow you to capture the communication between the TrackIR and the software, which might indicate what are they doing differently... You can also install the Windows into the virtual machine if you prefer that way, then you can use the Wireshark on the host system to capture the communication... What I'd need is a full capture - start with unplugged TrackIR and TrackIR software not started, start the capture, plug the TrackIR in, then start the software, wait for the tracking to start then shut the TrackIR software down and stop the capture... I'm sorry for the inconvenience - at this point this is the only thing I can think of... Kind regards, Michal
Ok, I will try it when I have time to deal with a Windows system. I will keep you informed.
On Tue, Mar 21, 2017 at 2:14 PM, uglyDwarf [email protected] wrote:
Hello, there is something funny going on in here... Looking at the status packet, everything should be good - the firmware is loaded, the checksum is correct and the device should be ready to go until the video should start... There is one thing that bothers me though - the configuration info is somewhat strange - there are values in there that I haven't seen before... It also looks that your device wad one of last version 2 devices (according to the serial number)...
At this point there is only one thing that I can think of, that might shed some light into the issue... Do you have an access to a windows machine, where you could install the TrackIR software along with the USBLyzer ( http://www.usblyzer.com/ )? The USBLyzer would allow you to capture the communication between the TrackIR and the software, which might indicate what are they doing differently... You can also install the Windows into the virtual machine if you prefer that way, then you can use the Wireshark on the host system to capture the communication... What I'd need is a full capture - start with unplugged TrackIR and TrackIR software not started, start the capture, plug the TrackIR in, then start the software, wait for the tracking to start then shut the TrackIR software down and stop the capture... I'm sorry for the inconvenience - at this point this is the only thing I can think of... Kind regards, Michal
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uglyDwarf/linuxtrack/issues/129#issuecomment-287986744, or mute the thread https://github.com/notifications/unsubscribe-auth/ABlCOWrdphcTCS-9BoGw4-mIj56ngMsKks5rn2rigaJpZM4MhRyh .
This is the ulz file USBlyzer captured. I basically plugged TrackIR in, started the software, moved my head around, paused/resumed headtrack, then quit.
Thank you very much - will take a look at it and see what is going on in there... Kind regards, Michal
Hello, I'm sorry it is taking that long but we're in the middle of the apartment reconstruction, so the free time and energy are hard to come by nowadays... Anyway, so far I haven't been able to find any significant difference, other than it took more than 1.6 second to produce the first packet... Be it as it may, I'm still looking at it to make sure I didn't overlooked anything... Kind regards, Michal
Same issue, Mac OS X Catalina 10.15.5.
When starting the tracking window, trackir turns green but nothing is displayed.
Checking the logs, I see Data receive request timed out!
Using trackir 5 with latest firmware.
Hi,
Just received my shiny TrackerIR 5v2 and had very same issue but finally found the root cause, so it works for me now. I'll describe my analysis in much details here because if other people would have not the same but close issue, it may help them to track it too.
In my case the camera didn't want to work because it didn't light on its red IR LEDs, hence did "see" my hat reflector model. I suddenly confirmed that it actually worked by fiddling with ltr_gui's camera view and occasionally pointing it up to my room lamp, which had exactly 3 bulbs in even triangle, which finally triggered the camera to life sensing moves and turns. Then I compared its behaviour of pointing it back to model and realized that the model was not enough to reflect the beam back to camera, because why? Likely because there's no beam at all to be reflected. Something prevented IR transmitter to operate.
The remaining analysis was looking at source finding the sequence of enabling IR LEDs and comparing it with what I see in /tmp/linuxtrackNN.log after enabling debugging mode by 'export LINUX_DBG=u' command. The pattern of occurrence of the message 'Problem writing data to TIR@ep 1! -7 - 0 transferred' with subsequent data timeout very soon became very clear: it always happens after switching on video by 'Video_on' (0x14 0x00) command being issued to camera. Searching for this Video_on more in tir_hw.c I found out that in most places where Video_on was issued by
ltr_int_send_data(out_ep, Video_on,sizeof(Video_on));
call, there's a slight time delay was inserted after it like
ltr_int_usleep(120000); // delay time could vary
before issuing some next camera command. That was not the case for TIR5 (and, as I recall, for TIR4) camera. So, any next command after Video_on did fail, and one of such failure was switching on IR LEDs.
TO FIX the driver (TIR5V2 case):
- Find two functions in tir_hw.c: 'init_camera_tir5' and 'start_camera_tir5'.
- In each look for command 'ltr_int_send_data(out_ep, Video_on,sizeof(Video_on));' (2 places)
- Insert 'ltr_int_usleep(120000);' line after each of them
- Save/rebuild/install
- Enjoy your flying/shooting/gaming. :-)
Perhaps, some more experienced Github contributor can create a proper patch/pull request from my description. I'm not much used to this git ecosystem (I created this account only to report my findings here) and already killed my two best days (and nights) on struggling to compile this project from sources (with hell lots of unmet deps) and then hunting for this mysterious bug. Now I want to finally going flying not keeping more programming. :-)
P.S. For compiling the project successfully, the patch from issue #168 must be applied.