UPDATE: Wireless timing with a Raspberry Pi

Hi,
I will return to this topic in a moment.
I have been using the system for over a year to my full satisfaction.
And now I decided to use my old netbook ASUS EEE PC as well. It runs Windows 7 32bit. But when I installed Ullr (0.1.16) it doesn't work.
A warning window says that python is not intended for this system. I'm not a programmer, but I thought of replacing the python folder with python-3.8.3-embed-win-32. No progress. Although the warning window no longer pops up, the script still won't start. What am I doing wrong? I'm a bad programmer. Can Ullr work on win 7 32bit?

@pepik posted:

I have a few more observations from using Ullr:
- On the timer side (RasperryPi Zero), it is better to define only one currently used device. If I leave more than one device in the "Devices" entry, there may be problems with data reception on the remote device side. ALGE Timy are particularly susceptible to this. A possible reason for this may be that we are using an identical Prolific 2303 USB converter, so all DCE devices are set up with the /dev/ttyUSB0 port

- I'm working with Ullr version 0.1.16. The higher version 0.1.17 doesn't want to work in Windows 10. The startup ends with this notification:

Unfortunately I can't program in Python, so I don't know what's wrong.

In the penultimate version 0.1.16 everything works as it should and I am satisfied. The hardware is stored in a plastic case with soft padding and only the cable to the timing device leads out. Before using it, I manually turn on the router and connect the raspberry to the powerbank. No more is needed.

That is strange! The stub module is not included in Ullr, so my guess is that it's an artifact from the packaging for Windows and something went wrong in that process. The packaging and distribution has been the most difficult part of this project, and I don't have a good Windows machine to do testing at the moment. Version 0.1.17 was pretty much exclusively UI updates, so you shouldn't be missing any functionality using 0.1.16. Thanks for the report, and hopefully I'll get some time to get back to these issues in the not too distant future!

I have a few more observations from using Ullr:
- On the timer side (RasperryPi Zero), it is better to define only one currently used device. If I leave more than one device in the "Devices" entry, there may be problems with data reception on the remote device side. ALGE Timy are particularly susceptible to this. A possible reason for this may be that we are using an identical Prolific 2303 USB converter, so all DCE devices are set up with the /dev/ttyUSB0 port

- I'm working with Ullr version 0.1.16. The higher version 0.1.17 doesn't want to work in Windows 10. The startup ends with this notification:

Unfortunately I can't program in Python, so I don't know what's wrong.

In the penultimate version 0.1.16 everything works as it should and I am satisfied. The hardware is stored in a plastic case with soft padding and only the cable to the timing device leads out. Before using it, I manually turn on the router and connect the raspberry to the powerbank. No more is needed.

@pepik posted:

This happened after copying one microSD card to another. So there was a takeover of the configuration file settings - mqtt broker and local device.
However, the communication was on an RPi with a different MAC address (albeit similar).
I stated this as an interesting observation, now I have the address in the config file matching the MAC address of the RPi, as you state in the instructions.
Thanks again for the great remote timekeeping tweak. Now I have to test it outdoors, in the hills and woods. But that will be more about the endurance of the whole set and the availability of GSM signal.

I remember why it's implemented this way. If Ullr is set to start on system power on, sometimes it will load before the network adapter and the MAC address won't be available. So, once it is found successfully it is stored to the config. This also gives you the option of choosing an arbitrary ID if you'd like. And if you don't set an ID in the file it will try again to find the MAC address.

Glad it's working for you. I'll be interested to hear how your testing goes!

@zhenry posted:

I would say coincidental! It's been a while so I can't remember the implementation exactly, but it's my recollection that getting an accurate MAC address with Python is not always easy and differs depending on operating system, architecture, and network adapter. I believe I had an issue with python finding different MAC addresses depending on wired/wireless connection, so I had Ullr save to file rather than attempt to find the address at start every time. There is probably a better way, I just haven't found it yet.

This happened after copying one microSD card to another. So there was a takeover of the configuration file settings - mqtt broker and local device.
However, the communication was on an RPi with a different MAC address (albeit similar).
I stated this as an interesting observation, now I have the address in the config file matching the MAC address of the RPi, as you state in the instructions.
Thanks again for the great remote timekeeping tweak. Now I have to test it outdoors, in the hills and woods. But that will be more about the endurance of the whole set and the availability of GSM signal.

@pepik posted:

After implementing the second measurement set with RasberryPi, I discovered an interesting feature:
To make my job easier, I simply copied the microSD card for the RPi. Even with the settings for Ullr.
To my surprise, all remote devices set to the MAC address of the first RPi worked in Ullr on the laptop without any problems. This is despite the fact that the second RPi has a different MAC physics adress. I even swapped the two RPi's and the data continued to be received on the laptop! See attached picture.

The cause was the original identification written in the Ullr configuration file.
Is that intentional, coincidental, or did I get something wrong? Of course I corrected the value in the Ullr configuration file for the second RPi and added new remote devices on the laptop side.

I would say coincidental! It's been a while so I can't remember the implementation exactly, but it's my recollection that getting an accurate MAC address with Python is not always easy and differs depending on operating system, architecture, and network adapter. I believe I had an issue with python finding different MAC addresses depending on wired/wireless connection, so I had Ullr save to file rather than attempt to find the address at start every time. There is probably a better way, I just haven't found it yet.

After implementing the second measurement set with RasberryPi, I discovered an interesting feature:
To make my job easier, I simply copied the microSD card for the RPi. Even with the settings for Ullr.
To my surprise, all remote devices set to the MAC address of the first RPi worked in Ullr on the laptop without any problems. This is despite the fact that the second RPi has a different MAC physics adress. I even swapped the two RPi's and the data continued to be received on the laptop! See attached picture.

The cause was the original identification written in the Ullr configuration file.
Is that intentional, coincidental, or did I get something wrong? Of course I corrected the value in the Ullr configuration file for the second RPi and added new remote devices on the laptop side.

@pepik posted:

The parts for the serial cable for ALGE Timy arrived today. I had some time to make it (I use crimped pins in the connectors, the cable will be exposed to rough handling outside).
And of course he immediately reconfigured the DCE (or rather added) the device in Ullr to the Raspberry Pi. Everything worked the first time, data willingly went to the laptop: Video here

That's awesome! Glad it worked, hope it can solve some problems for you in the field. Let me know how it goes.

Zach

The parts for the serial cable for ALGE Timy arrived today. I had some time to make it (I use crimped pins in the connectors, the cable will be exposed to rough handling outside).
And of course he immediately reconfigured the DCE (or rather added) the device in Ullr to the Raspberry Pi. Everything worked the first time, data willingly went to the laptop: Video here

@zhenry posted:

Hey, that's really cool! Glad you got it going, and thanks a lot for documenting all your efforts. I'd like to make the software easier to use with USB hubs etc. and also improve the documentation, but unfortunately my time for testing and work on it is low these days. Getting a report of your experience is a big help

Also, really interesting with the pin assignment issue. I would think that's something that could also be addressed in the software to save the need for more hardware. I'll have a think on that

Additionally I tried the HL440 connected via USB adapter PL2303 and USB Hub. It also works with the USB hub. Interestingly, the RPI only sees the PL2303 converter behind it and assigns it the correct port ttyUSB0.
Probably just an unsuitable serial cable for the Timy would be to blame. I have already ordered the material for its production and then I will try the ALGE Timy.
I also tried the translation from TGH HL440 to Tima. The time data arrives in the software set up for Timy, but it has no starting number.
And thank you for your support.

@pepik posted:

I finally found the bug.
The second device I tried was the TAG Heuer HL440. This device has a classic RS232 output for a computer and external printer. So I connected it via a USB adapter to a Raspberry Pi, redefined the local and remote devices in Ullr to HL440. The connection started working!

https://youtu.be/2_T7qzXS2nI

The only difference from ALGE is the lack of a serial cable. The USB converter is connected directly to the device.
With the ALGE Timy, I used the modem cable and "swapped" the pins with this adapter:

However, this will cause incorrect pin assignment. So I will have to get another cable for Timy3 (DB25<->DB9 female) and then try again.

Hey, that's really cool! Glad you got it going, and thanks a lot for documenting all your efforts. I'd like to make the software easier to use with USB hubs etc. and also improve the documentation, but unfortunately my time for testing and work on it is low these days. Getting a report of your experience is a big help

Also, really interesting with the pin assignment issue. I would think that's something that could also be addressed in the software to save the need for more hardware. I'll have a think on that

I finally found the bug.
The second device I tried was the TAG Heuer HL440. This device has a classic RS232 output for a computer and external printer. So I connected it via a USB adapter to a Raspberry Pi, redefined the local and remote devices in Ullr to HL440. The connection started working!

https://youtu.be/2_T7qzXS2nI

The only difference from ALGE is the lack of a serial cable. The USB converter is connected directly to the device.
With the ALGE Timy, I used the modem cable and "swapped" the pins with this adapter:

However, this will cause incorrect pin assignment. So I will have to get another cable for Timy3 (DB25<->DB9 female) and then try again.

@pepik posted:

I obeyed, removed the splitter, connected the Timy3 directly via the PL2303 converter. Timy3 (or the converter) is reported in RaspberryPI OS as ttyUSB0:

By excluding the USB hub I lost the ability to control the Raspberry Pi ZERO using the keyboard, but that's okay. I connected my laptop to the same network and control the RPI Zero using SSH (Putty terminal). On the Zero side I set up a connection to MQTT with the offered parameters and at the same time Timy3 on the ttyUSB0 port under the name "Timy". Online is green in the window, so I assume a working connection.

On the side of the laptop that runs under a different network, I first check the prepared virtual ports using the com0com application:

Yes, they're there. Still, I check the status directly in the com2com app:

OK, the ports match the assignment. So I'm running Ullr. I set up access to MQTT and I see Green Online lit, that's good. The connection is working even though I'm now on a different network. So I set up remote Timy under the name "START" with ID Zero and device ID "Timy":

Similarly, I set up my computer as a local DTE device that is connected to port 50:

I go into my timekeeping software - MsportPro and set the Timy timing device to port 51:

And that's where my efforts end. The program doesn't respond to incoming data on port 51.I get the same result in another program from ALGE - Timy Backup (writes data from Timy to a table). But even here I can't do anything with the COM port 51 settings. The data is not coming in.
Unfortunately, I can't figure out what I'm doing wrong.

Surprised you need all those connections between the two devices these days, we went to 3 wire serial connections back in the 80’s,  just rx, tx and ground.

@pepik posted:

Why not something like the Ubiquiti WiFi kit? Because I measure motorsports where the start and finish are a considerable distance apart. Typically Rally, Mountain Racing, Antique Car Rally etc.
Also for example car slalom, but there radio transmission is more suitable. Such as now TED2 from ALGE Timing.
And even in the case of a local WiFi network, it is necessary to address the sender and receiver when extending the RS232 line. And Ullr can do that.

I haven't had any luck with the Timy3 USB cable, and I haven't had any luck with the old TAG Heuer CP505 (serial cable plus USB converter).
Today I will have a serial cable to the Timy3 and also a TAG Heuer HL440 timekeeper. So I'll see if I can make any progress with the Ullr.

Why is that an issue, if you have line of sight the link can be several kilometres, they are quite often rated at more than 20 kilometres and it’s not as if the data rate is high for this application

I obeyed, removed the splitter, connected the Timy3 directly via the PL2303 converter. Timy3 (or the converter) is reported in RaspberryPI OS as ttyUSB0:

By excluding the USB hub I lost the ability to control the Raspberry Pi ZERO using the keyboard, but that's okay. I connected my laptop to the same network and control the RPI Zero using SSH (Putty terminal). On the Zero side I set up a connection to MQTT with the offered parameters and at the same time Timy3 on the ttyUSB0 port under the name "Timy". Online is green in the window, so I assume a working connection.

On the side of the laptop that runs under a different network, I first check the prepared virtual ports using the com0com application:

Yes, they're there. Still, I check the status directly in the com2com app:

OK, the ports match the assignment. So I'm running Ullr. I set up access to MQTT and I see Green Online lit, that's good. The connection is working even though I'm now on a different network. So I set up remote Timy under the name "START" with ID Zero and device ID "Timy":

Similarly, I set up my computer as a local DTE device that is connected to port 50:

I go into my timekeeping software - MsportPro and set the Timy timing device to port 51:

And that's where my efforts end. The program doesn't respond to incoming data on port 51.I get the same result in another program from ALGE - Timy Backup (writes data from Timy to a table). But even here I can't do anything with the COM port 51 settings. The data is not coming in.
Unfortunately, I can't figure out what I'm doing wrong.

@pepik posted:

I use the Prolific PL-2303 converter. Neither Windows OS nor Raspberry PI OS has a problem with it. It is reliable.

He is not completely unknown for Linux (and also Raspberry Pi OS) USB port from ALGE Timy. If I put in the command line:
lsusb
I get this:

But I don't know a way to use it as a serial port.

I think if everything is working correctly the timy USB should report as serial. Are you using a USB hub? That has caused issues for others in the past. Maybe try removing the hub, and controlling the pi via SSH?

I use the Prolific PL-2303 converter. Neither Windows OS nor Raspberry PI OS has a problem with it. It is reliable.

He is not completely unknown for Linux (and also Raspberry Pi OS) USB port from ALGE Timy. If I put in the command line:
lsusb
I get this:

But I don't know a way to use it as a serial port.

@pepik posted:

I haven't had any luck with the Timy3 USB cable, and I haven't had any luck with the old TAG Heuer CP505 (serial cable plus USB converter).

Today I will have a serial cable to the Timy3 and also a TAG Heuer HL440 timekeeper. So I'll see if I can make any progress with the Ullr.

What chipset is your converter cable, if you know? My old prolific cable worked out of the box, but I've heard problems with FTDI on the Pi. Sounds like perhaps a Linux driver issue, which are not always so straightforward.

Here's an article regarding the pi and FTDI drivers.

https://www.raspberrypi.org/fo...ewtopic.php?t=257630

Why not something like the Ubiquiti WiFi kit? Because I measure motorsports where the start and finish are a considerable distance apart. Typically Rally, Mountain Racing, Antique Car Rally etc.
Also for example car slalom, but there radio transmission is more suitable. Such as now TED2 from ALGE Timing.
And even in the case of a local WiFi network, it is necessary to address the sender and receiver when extending the RS232 line. And Ullr can do that.

I haven't had any luck with the Timy3 USB cable, and I haven't had any luck with the old TAG Heuer CP505 (serial cable plus USB converter).
Today I will have a serial cable to the Timy3 and also a TAG Heuer HL440 timekeeper. So I'll see if I can make any progress with the Ullr.

Why can you not use something like Ubiquiti WiFi kit that gives multiple km links at low cost so that the internet connect is not required or in places where an internet connect is impossible/difficult

All ALGE Timy have a DB25 multi-function connector that contains the signals for the serial link. This is how I connect the Tims to, for example, a modem.
But it would be a shame not to use the serial interface via USB. In Windows, a driver is needed.

@pepik posted:

A more reliable (and simpler) solution would be a button. The operator on the RPI timer side will not have access to the Ullr interface.
I've tried connecting to the ALGE Timy3 via a USB cable, but I can't figure out how it reports as a serial port in the RPI.
However, the Ullr is connected - it reports "green" online.

Nice! I'm not too familiar with the timy USB interface. If I'm remembering correctly it still uses RS232, just with a USB cable? I know depending on the chipset there are some driver issues getting USB/serial working on the pi. I would try running `lsusb` and `dmesg | tail` on the pi immediately after plugging in the Timy and see what you can find.

Also, I believe Wally (slykarma) has some experience connecting Timys to the pi zero

A more reliable (and simpler) solution would be a button. The operator on the RPI timer side will not have access to the Ullr interface.
I've tried connecting to the ALGE Timy3 via a USB cable, but I can't figure out how it reports as a serial port in the RPI.
However, the Ullr is connected - it reports "green" online.

@pepik posted:

Hey,
has anyone solved the system shutdown on the Raspberry PI Zero?

Glad you're finding the idea useful! The system shutdown is an issue I hadn't really thought about. I read that article, and the button looks like it could possibly be a good solution. I have my Pi stuff packed away at the moment so I'm not really able to test right now.

Another idea would be to add a feature to have Ullr shutdown the Pi. It seems like maybe a security issue to allow it remotely over mqtt, but perhaps it could be allowed on the webui from a device in the same network. Let me know what you think.

Hey,
has anyone solved the system shutdown on the Raspberry PI Zero? Even if the measurements are no longer running, simply disconnecting from the powerbank will not benefit the system or the microSD card.
Maybe a HW button connected between GND and GPIO21 (pin 39 and 40) would help, see here.
So start shutdown and then disconnect the powerbank.
I have a Rasperry Pi Zero, powerbank and MiFi on my desk since yesterday. This weekend I will try to set up communication between the Timy3 and the laptop (MSportPro).
Thanks for the inspiration, so far I've been using an industrial modem and an RS232 extension over a private (paid) VPN.
This (Ullr) is a simpler and much, much smaller solution.

Zach,

First off, thank you for generously sharing all your work with the timing community (Wally too).

In under 4 hours from UPS delivery to my first screenshots, I had a Timy and a CP520 sending/receiving data on both my local and remote computers.

Another 30 or 40 minutes today and I have data transferred to my timing software.

Super useful and I can think of plenty of potential for this to be deployed. On to laying out my Pelican case!

Matt

Thanks for the pictures Wally, and all the help and patience getting it going!

This is a simple, inexpensive cloud based system. We ran six race days with the Pi and Zach's software as the B system, feeding data to Split Second's Ski Club program. As mentioned in the Ullr documentation, second timer capability is not required for the system to work, and in fact we were able to race using three timers (start, intermediate, finish) in the Ski Club software once correct configurations were set.

In more than 800 starts, four pulses did not transmit to timing, due to two incidents of internet connection loss (these starts' TOD data were captured by the timer at the start).

Pictures below show the kit sent to the start each day. The repurposed retro timer case proved to be adequately weatherproof for ski racing conditions. Operators were instructed to make occasional checks for printer tape obstruction through the day; no problems were encountered.

• Alge Timy
• USB power bank, 10,000 mAh capacity
• "Mifi" cellular internet hotspot
• Raspberry Pi Zero W single board computer (out of sight below foam)
• USB-serial converter (out of sight below foam)

I am a complete Raspberry Pi/Linux rookie, but was able to install and run the software - with some help from Zach. I have about USD 100 invested so far, as I had some items already at hand.

• Pi Zero W starter kit $50
• USB power bank $15
• wifi hotspot, used $35

Much gratitude to Zach for his hard work on this project. It gives us as timers a lot of possibilities: to race or train where no hard wiring exists, or to quickly add intermediate timing locations. Point to point races can be run where wired connections do not exist; use GPS sync and the timers would never need to be brought to the same physical location.