ALGE has just released a Timy demo on the USB connection. Have not done much more than see it work. Little steps!
Original Post
Replies sorted oldest to newest
Hi, where did ALGE post the demo? After a brief look on their web page I didn't locate any update. Cheers, J
http://www.alge-timing.com/alge-e.htm
On the downloads page under pc software about 1/2 way down the page
On the downloads page under pc software about 1/2 way down the page
The demo works here in our shop. We will be encouraging the software developers to in corporate this in their offerings in the near future.
There are later versions of the USB interface available and we would like to encourage people to try them.
Developers software
www.alge-timing.com/alge/download/software/TimyUSB.exe
www.alge-timing.com/alge/download/software/TimyUSBdriver.zip
www.alge-timing.com/alge/download/software/TimyUSBDemoCBuilderSource.exe
Demo Software
www.alge-timing.com/alge/download/software/algeusb.exe
Developers software
www.alge-timing.com/alge/download/software/TimyUSB.exe
www.alge-timing.com/alge/download/software/TimyUSBdriver.zip
www.alge-timing.com/alge/download/software/TimyUSBDemoCBuilderSource.exe
Demo Software
www.alge-timing.com/alge/download/software/algeusb.exe
Fred, you can "encourage the software developers to incorporate this in their offerings" all you want, but don't hold your breath. As you know, I love Albert & Roman, and I adore bomb-proof ALGE equipment in general, but USB is just plainly and clearly a STUPID idea for a timer interface. Dumb, dumb, dumb. So don't look for USB Timy support in Skunkware any time soon. It's a waste of my time, and of my customers' time chasing the problems USB will inevitably cause.
The two interfaces _perfectly_ suited are serial and TCP/IP (network). Serial is dying a slow painful death, so we are left with networking. USB isn't even on the list of technically sound options.
AMB, for instance, offers simultaneous access via serial and TCP/IP to their industry-leading Tran-X Decoders. As a matter of fact, a Tran-X Decoder is, in and of itself, a TCP/IP _server_ (not merely a client or an ad-hoc), so that up to _four_ clients can attach and receive data _simultaneously_ from an AMB Decoder.
FinishLynx, also the undisputed leader in their industry (digital photofinish), offers a TCP/IP interface, and _only_ a TCP/IP interface, to their cameras as well.
Neither of the above companies have even attempted to touch USB with a ten-foot pole, as USB has severe distance limitations, USB has _huge_ stability problems, USB is extremely finicky to set up, and a stable USB configuration - once arrived at - can be ruined by an unstable one on the same PC. Furthermore, ALGE's particular implementation of USB depends on an Active-X driver which is a "black box" to an applications programmer (me).
As proof of the idiocy of USB for the mission-critical timing interface, I offer the following experiment:
1) Using any timer with a serial interface, run your favorite timing software. At a moment of your choosing, turn the timer off, or yank the serial cable. Wait a while, then re-attach or turn the timer back on. All will be fine.
2) While surfing the internet, yank the TCP/IP connector out of your PC or turn your modem/router off. Wait a while, then re-attach. All will be fine.
3) Now for USB. To perform this test, you don't even have to be running application software. Just turn on a USB device that's configured into your Windows setup, like a printer or a router. Leave Windows open on your desktop. Now yank the cable or turn the device off.
If you're running Windows 9x, your PC will probably crash.
If you're running NT, you can't perform this experiment IN THE FIRST PLACE because NT doesn't support USB _at all_.
If you're running Win2k, your PC may crash, it may not, but if it stays up it will give you all sorts of angry messages, and when you plug the device back in, it will not be recognized unless you either re-boot or, if you have the technical expertise, you diddle the Windows Device Mangler.
If you're running Windows XP, the experiment may or may not work, depending on how much time elapses between when you yank the device and when you re-attach.
I begged and pleaded with ALGE to offer a network interface to the Timy or to ANY of their timing products. They looked at me like I was speaking Swahili.
The timing device manufacturing company which comes to market with a viable timer bearing a TCP/IP interface will win this market. I, for one, would go out and buy such a timer (at retail prices if necessary) for my own use, and I would throw the serial timers I've got in my office - of all brands - into the nearest trash can.
Currently several professional Skunkware customers (including myself) are using serial-to-IP converters to access all their serial devices, such as timers, GAZ displays, tape printers, etc, via network. It is just OBVIOUSLY the way to go. At US Open tennis, for example, I use a 16-channel Moxa serial/IP protocol converter to convert umpire Palmtop data into network packets from 13 courts simultaneously. In doing so, I eliminated three muxes, approximately two miles of serial cabling, and all sorts of physical and logical limitations as to where certain mission-critical PCs had to be located around Arthur Ashe Stadium. The weak point in this setup, of course, is that the protocol converter can conceivably die. But you know what? TCP/IP is so flexible that you can use multiple redundant converters flowing through multiple redundant switches, so if one pathway dies for whatever reason, data finds another pathway _by itself_ - a feature built into the basic design of TCP/IP. The ONLY single point of failure remains that exclusive serial or USB interface between the timer and whatever.
Aaaaaaaaaaaaaaaaaaargh!!!!!!!!!!!!
The two interfaces _perfectly_ suited are serial and TCP/IP (network). Serial is dying a slow painful death, so we are left with networking. USB isn't even on the list of technically sound options.
AMB, for instance, offers simultaneous access via serial and TCP/IP to their industry-leading Tran-X Decoders. As a matter of fact, a Tran-X Decoder is, in and of itself, a TCP/IP _server_ (not merely a client or an ad-hoc), so that up to _four_ clients can attach and receive data _simultaneously_ from an AMB Decoder.
FinishLynx, also the undisputed leader in their industry (digital photofinish), offers a TCP/IP interface, and _only_ a TCP/IP interface, to their cameras as well.
Neither of the above companies have even attempted to touch USB with a ten-foot pole, as USB has severe distance limitations, USB has _huge_ stability problems, USB is extremely finicky to set up, and a stable USB configuration - once arrived at - can be ruined by an unstable one on the same PC. Furthermore, ALGE's particular implementation of USB depends on an Active-X driver which is a "black box" to an applications programmer (me).
As proof of the idiocy of USB for the mission-critical timing interface, I offer the following experiment:
1) Using any timer with a serial interface, run your favorite timing software. At a moment of your choosing, turn the timer off, or yank the serial cable. Wait a while, then re-attach or turn the timer back on. All will be fine.
2) While surfing the internet, yank the TCP/IP connector out of your PC or turn your modem/router off. Wait a while, then re-attach. All will be fine.
3) Now for USB. To perform this test, you don't even have to be running application software. Just turn on a USB device that's configured into your Windows setup, like a printer or a router. Leave Windows open on your desktop. Now yank the cable or turn the device off.
If you're running Windows 9x, your PC will probably crash.
If you're running NT, you can't perform this experiment IN THE FIRST PLACE because NT doesn't support USB _at all_.
If you're running Win2k, your PC may crash, it may not, but if it stays up it will give you all sorts of angry messages, and when you plug the device back in, it will not be recognized unless you either re-boot or, if you have the technical expertise, you diddle the Windows Device Mangler.
If you're running Windows XP, the experiment may or may not work, depending on how much time elapses between when you yank the device and when you re-attach.
I begged and pleaded with ALGE to offer a network interface to the Timy or to ANY of their timing products. They looked at me like I was speaking Swahili.
The timing device manufacturing company which comes to market with a viable timer bearing a TCP/IP interface will win this market. I, for one, would go out and buy such a timer (at retail prices if necessary) for my own use, and I would throw the serial timers I've got in my office - of all brands - into the nearest trash can.
Currently several professional Skunkware customers (including myself) are using serial-to-IP converters to access all their serial devices, such as timers, GAZ displays, tape printers, etc, via network. It is just OBVIOUSLY the way to go. At US Open tennis, for example, I use a 16-channel Moxa serial/IP protocol converter to convert umpire Palmtop data into network packets from 13 courts simultaneously. In doing so, I eliminated three muxes, approximately two miles of serial cabling, and all sorts of physical and logical limitations as to where certain mission-critical PCs had to be located around Arthur Ashe Stadium. The weak point in this setup, of course, is that the protocol converter can conceivably die. But you know what? TCP/IP is so flexible that you can use multiple redundant converters flowing through multiple redundant switches, so if one pathway dies for whatever reason, data finds another pathway _by itself_ - a feature built into the basic design of TCP/IP. The ONLY single point of failure remains that exclusive serial or USB interface between the timer and whatever.
Aaaaaaaaaaaaaaaaaaargh!!!!!!!!!!!!
Firewire is not any different that the USB problems so pointed out by James. Today I was doing photofinish for a Crit race and with 2 laps to go, the firewire cable came unplugged! The computer did not seem to care, but the program just sat there like nothing happened, including NOT capturing any pictures! Rebooted the program, restarted another race and still no capture. I had to restart the computer (Win XP) before I could get the photocamera to come alive via firewire! (This took about 7 minutes to restart and get it up running again.) Lesson learned.....DON'T touch anything and secure EVERYTHING. Just wish the Firewire has those cool screws like serial 9 pin connectors!
New USB drivers and updated Com to File and TIMY USB Update programs were released this week. I have installed and performed some of the tests that TMS details above. Testing was done with a Dell Laptop running XP pro.
I found that while running Com to File with the TIMY conected via USB you CAN unplug and then reconnect the TIMY without any problems. There is no spooling of data so anything that happens while TIMY is unplugged is only captured to the TIMY. When it gets plugged back in to USB the program instantly re-connects and performs normally.
I still wish for the option to upload start times as with the TDC, maybe soon. BTW there are some specific instructions for changing to the nue programs, be sure to read the instructions on the download page
I found that while running Com to File with the TIMY conected via USB you CAN unplug and then reconnect the TIMY without any problems. There is no spooling of data so anything that happens while TIMY is unplugged is only captured to the TIMY. When it gets plugged back in to USB the program instantly re-connects and performs normally.
I still wish for the option to upload start times as with the TDC, maybe soon. BTW there are some specific instructions for changing to the nue programs, be sure to read the instructions on the download page