Skytrak shot delay

[soccerdude]

Okay, so I have watched the recent SkyTrak/TGC videos from Hoosierdaddy, and they look awesome! Thanks Hoosierdaddy for taking the time to create and post those videos. The graphics look amazing.

The one thing, though, that bothers me is the 5 second wait. I know, I’ve posted about this before, but 5 seconds seems like an eternity. I thought for sure that once SkyTrak passed off the image processing/shot-rendering to a beefy PC that the shot to show time would improve, but that doesn’t seem to be the case. I wonder if ProTee United (Dennis) can offer some details/insight as to what might be taking so long to render the shot. As I understand it, the SkyTrak unit just takes the pictures and passes the images to the PC via USB. I can’t imagine this takes very long. And then the PC does everything else. I would imagine it would be ProTee’s interface that analyzes the images to calculate the ball speed, launch angle, back spin, side spin, and side angle. Then I imagine ProTee’s interface passes this data to TGC which uses it to determine the shot shape and render it to the screen. ProTee United, can you comment on whether these assumptions are correct, and how long each step in the process takes?

I know some of you have indicated that you get used to the delay and that it’s not a big deal, but for me I think it will be. It’s the last thing that’s preventing me from pulling the trigger on a SkyTrak. I am currently using an optishot (which has no delay) and so to move to ST/TGC (which I understand will be significantly better in every other way) with a 5 second delay will be difficult to get used to. Please note that I am not trying to bash ST or TGC. From what I’ve read and seen from all the posts here, I think they both look great, but I just want to get a better understanding of what is currently consuming the time so that I can get a feel for whether or not any significant improvement is possible in the future. I am a software developer (have been for 24 years) and so have a little knowledge of how programming works. Admittedly though, I am not an expert on image processing or 3D graphics. Hence, the above questions. Thanks in advance.

Again, I really appreciate all of the contributors to this forum. I have read most of the posts on this forum and have learned an absolute ton! I think I’m a golf sim forum addict cuz I’m on here reading all new posts every few hours. Anyways, thanks again for all of the great posts. Keep them coming. One of these days I’ll pull the trigger (on something other than my opti) and can become a contributor instead of just a consumer.

[ProTee United]

This is really something you need to ask SkyTrak_Seth. We did not develop the hardware.

[soccerdude]

So you're saying that's it's a SkyTrak hardware issue and not a software issue? i.e. that the majority of the 5 second delay is being caused by the ST unit itself and not your interface or TGC?

[ProTee United]

Again you need to ask Skytrak how this works exactly. We did not develop the hardware.

A ProTee Sensor System + cameras with TGC has approx 1 second delay.

[mhage]

If you watch his E6 videos, the delay is only 3 seconds. That's getting closer to usable.

[Ironstrokes]

Yea I'm curious about that too, I timed it and it was consistently a 6 second delay from the videos hoosier put up (thanks again for that too hoosier, great stuff!) on tgc and only 4 second delay on both e6 and perfect golf. So I'm guessing the software/game may have something to do with that but I know very little about the technical aspects of gaming. Would be interesting to know if this is the least that the delay can be by skytrak or if there is a way to improve it. Seth seems to be a bit busy again with not as many posts, but last time that happened a great update came out, so figuring it's probably much of the same going on there hopefully, but if there's time would love to know this delay science as well

[davray666]

Skytrak is not only passing along images that are then processed by the PC. It's actually easy to tap in to the data stream and check what data is passed between the Skytrak unit and the host. (PC or iPad)
It does pas on a lot of data after every shot and it could be cropped images on the essential regions, but in that case the data is scrambled to keep it secret.
I made an attempt to capture the stream in order to display the images like Vector pro does, but that attempt failed.
It's difficult to guess why old iPads are slower than new ones but it does indicate that some data processing is done on the host.

[codehead]

I would doubt that the image data is actually encrypted that would be a huge waste of processing power and time and I am not sure to what end. My guess would be that it is simply compressed to save bandwidth for the transfer. Have you tried just uncompressing it? I would guess it is using something like https://en.wikipedia.org/wiki/Zlib

[davray666]

I just recorded it and did a quick check if it was anything I could use "as is". It was not.
To do zlib style compression without dedicated HW support is very slow. So I doubt that's used.
If this is indeed image data then it's a reasonable assumption that it could be somehow compressed.
I am also sure that the content of the data could be somehow reverse engineered for those that have the time to do it.
I definitely don't. The reason I don't think it's image data is that there is very little pay load. Most of the (if I remember correctly) raw 150kB is protocol and various reoccurring header data.

[soccerdude]

K, so I'm getting more confused instead of less...

So this is what SkyTrak_Seth said in an earlier post:

"05-27-2015, 03:52 PM
There is no processing that happens on the unit itself, we're just sending images. With each new processor release (iPad and PC) it naturally gets faster, but we are always working to get the shot-to-show time down. We'll be working with each sim company to make sure it's as optimized as possible."

So, combining this with what ProTee United is saying above, "A ProTee Sensor System + cameras with TGC has approx 1 second delay. ", does that mean that it's the SkyTrak unit itself that is taking the rest of the 4 or 5 seconds just to transmit the images? That seems like a huge amount of time just to transmit images.

I would really like to know from either SkyTrak_Seth or ProTee United what each party does with respect to TGC, i.e. SkyTrak does this and sends this. Protee receives this and does this, and then sends this data into TGC which does this and this. Hopefully one or both can offer some more clarity. Thanks again in advance.

davray666, I really appreciate your input on how cameras and image processing works in general and the work you're doing with the protective case for the SkyTrak unit. It looks really great and seems to offer more protection than the official unit being built by SkyTrak.

[ProTee United]

Here is some video material to show how TGC and its SDK works.

http://golfsimulatorforum.com/forum/golf-simulator-brands-and-types/the-golf-club/39399-how-tgc-interacts-with-simulator-hardware

[nyb72]

How large are the image sizes? I imagine they would be pretty large files if you need something very high resolution to approximate spin. So I'm curious how long it takes for this data to complete its transfer.

[davray666]

The total data it does transfer takes no more than a few 100ms even on a slow WiFi connection. So that's not the problem. With USB it should be well below 100ms.

[MarkSC]

It's an issue with the Skytrak software or hardware. As Dennis said, the ProTee has a 1 second or less delay using the same SDK. Keep in mind that the delay exists even without TGC. My impression was that SkyTrak intentionally built in the delay for the launch monitor so that users on a range can hit the ball, watch the ball flight, and then check their iPad. If so, maybe they can provide a toggle off for the delay.

Another possibility is that it was a delay caused by the use of wifi to transmit the data and the relatively weak iPad CPU for the processing, but that should be fixed now that the sim option uses USB and a computer. That leaves two possibilities: either it is a hardware issue with the the SkyTrak, or it is just something they haven't gotten around to correcting yet in the firmware. I guess we'll know soon enough.

The Japanese version of SkyTrak has had sim options for a while now. Anyone know if it has the shot delay as well?

[JohnMeyer]

From this then I guess the delay from skytrak is the time taken for skytrak to process the differences between the images, and then convert that to a data string that is compatible with TGC. Where is that conversion done, again im guessing its on the host PC, not in the skytrak unit itself as when using higher end hosts the delay is reduced (ie using a iphone5 compared to an ipad air 2)

Is there therefore 3 stages to the process:
1 - Skytrak images captured and sent to host PC (completed by Skytrak Unit),
2 - Image analysed and converted to shot data suitable for IOS App ( completed by Skytrak Software/Skytrak Unit)
3 - IOS Data converted to TGC suitable data, (completed by TGC SDK)

I would think more likely the TGC SDK for Skytrak combines steps 2 and 3 above

Would be interesting to know exactly what data is passed from the Skytrak Unit to the software, if its just the images or "shot data", and what calculations are then required

I too was just putting it down the low powered IOS devices being used but as it nows appears that the same delay is still present on PC it is in my opinion a bit of drawback. With the processing power available there is no reason for any delay whatsoever really I wouldnt have thought. Other devices manage to do so, so should Skytrak IMO.

[soccerdude]

Thank you ProTee United for the videos and SDK documentation. They were very insightful. JohnMeyer, I think you're on the right track, except when it comes to ST and TGC, I don't think there's any IOS App involved - because there is no IOS hardware, i.e. there is only the SkyTrak unit and the PC, so no need to anything IOS related. Based on ProTee United's input, I now believe the following happens:

1) SkyTrak unit takes 2 pictures and sends them via USB to PC
2) SkyTrak has software running on the PC which receives the images sent from the SkyTrak unit. The SkyTrak software (running on the PC) processes the images to calculate the ball speed, launch angle, back spin, side spin, and side angle, which it then passes to the ProTee SDK
3) the ProTee SDK then passes this data to TGC which then renders the shot.

SkyTrak_Seth, can you confirm that this is what happens?

If so, then it would appear based on the < 1 second delay it takes for the shot to render in TGC when passing the shot data into the ProTee SDK (actually looks like a couple of tenths of a second from the time that the user presses enter and the shot flies), and @davray666's comment that it takes less than 100 ms (1/10 of a second) to pass the images from the SkyTrak unit to the PC, that the vast majority of the 5 or 6 second delay that we're seeing in @Hoosierdaddy's video is the SkyTrak image processing software that I am assuming is running on the PC. SkyTrak_Seth, can you either confirm or deny this?

Also, SkyTrak_Seth, if this is the case i.e. that the SkyTrak image processing software running on the PC is the source of the 5 second delay, would you mind telling us what language it is written in. If I had to guess, you probably used the same unity source code that you use in your IOS app for this. Thanks for helping us understand exactly where the slow-down is and what is happening at this point.

[Dax]

Just a curiosity thing, but for TM there is a fix when shots are slow to render and maybe something similar is at issue here, the fix is to disable the scanning of files by windows defender/ security. I would try this and see if it could be a similar issue for those that are doing the beta testing.