Project Updates

New developments for the software suite including CrossMgr, RaceDB and SeriesMgr.

CrossMgr/RaceDB Project Moving to

posted Jun 16, 2020, 7:44 AM by Edward Sitarski   [ updated Jun 16, 2020, 7:46 AM ]

All downloads will be moving to github (the source code is already there).
Github makes it much easier to build updates.  Also, my Google Drive is getting full ;)

To install CrossMgr updates, follow the instructions on the Downloads page.
Similar for RaceDB updates which you can see here.

Github also supports an issues page which makes it much easier to manage suggestions and bugs.
This is especially important as we grow the project.
If you are interested in CrossMgr development, look at the issues page.  If you have a suggestion for a new feature, please enter it there.


CrossMgr and SeriesMgr 3.x.x Users: Time to Upgrade

posted Sep 3, 2019, 4:47 PM by Edward Sitarski

If you are running CrossMgr 3.x.x or SeriesMgr 3.x.x, please upgrade to CrossMgr 3.0.29 and SeriesMgr 3.0.4 (or later).
There have been some important bug fixes with RaceDB integration.

Regarding the 3 series versions, I am no longer seeing bug reports about the conversion to Python 3 (just bugs that were there before).  This stability is good news as Python 2 goes out of support in 2020.
This project turned out to be a lot more painful than expected, however, the upgrade ensures that the CrossMgr software will be available for years to come.
Thanks to all for the great feedback and patience.

Spanish and Italian CrossMgr

posted Jun 29, 2019, 8:28 AM by Edward Sitarski

I am looking for Spanish and Italian speakers who are willing to review the CrossMgr translation in those languages.
I used Google Translate to get a starting point, but Google does not know all the specific terms for timing and racing.
Reviewing the translation files is extremely easy - download a utility (poedit), make changes to a messages.po file, then send the file back to me.

If you are interested, please let me know.


Important: RaceDB and Python 3 Information

posted May 26, 2019, 10:33 AM by Edward Sitarski

RaceDB 3.0.0 has just been released.
If you have an existing install of RaceDB, you must read and follow the instructions:


If you have a new install of RaceDB, the ReadMe file is sufficient.

RaceDB-3-Upgrade.txt contains important one-time steps required to upgrade to the new version.
After you have upgraded, you can go back to the process described in ReadMe which is much easier.

I tried to make the upgrade process as safe and easy as possible.  It is possible to "bail-out" and revert to the previous version if something goes wrong.

Before upgrading, leave yourself some time to check things out.  I tried hard to test everything, but it is always possible that some aspect of your data causes a problem.
If you run into a problem, be sure to email me.
Issues should be easy to fix and will have a short turnaround.

The reality is that Python 2 is going out-of-support in Feb 2020.
Unfortunately, the conversion to Python 3 required 100's of changes - mostly to I/O handling.
These changes made it impossible to support the old upgrade process, making the one-time conversion necessary.
All future development and features will be available in the Race 3 series only.

Python Port Update

posted May 26, 2019, 6:09 AM by Edward Sitarski

I am pleased to report that CrossMgr, CrossMgrImpinj, SeriesMgr and PointsRaceMgr have been released in Python 3.
Other programs are in progress.

Python 3 Port

posted Feb 28, 2019, 8:35 AM by Edward Sitarski

With Python 2.7 going out of support in 2020, I will be upgrading all the CrossMgr software to Python 3.
This project will include:
  • CrossMgr
  • CrossMgrVideo
  • CrossMgrImpinj
  • CrossMgrAlien
  • TagReadWrite
  • SeriesMgr
  • RaceDB
The plan is to use the "six" module to make the source code compatible with Python 2.7 and Python 3 simultaneously.
This allows me to test the code in both Python 2.8 and Python 3 so that I can verify that the two versions work the same.
After 2020, the plan is to support Python 3 exclusively and drop support for Python 2.7.

Q: What does this mean to me?
A: If you install from windows, over the next few months there will be a new program version with a number 3.x.x.  It will install as usual.
The 3.x.x version will be backwards compatible with previous races and series.  You can read/write your existing files as usual.
The previous versions will continue to be available until 2020.  When the 3.x.x versions are available, bug fixes and new enhancements will only be available in the 3.x.x version.

Version 3.x.x programs and older versions will continue to interoperate.  For example, it will be possible to use 3.x.x CrossMgr races with previous versions of SeriesMgr or CrossMgrImpinj, or CrossMgr with RaceDB.

If you are running RaceDB, you can continue to run with Python 2.7 for 2020.  In 2021, you will need to upgrade to RaceDB 3.x.x and switch to Python 3.  If you have written scripts in Python 2.7, you will have to upgrade them to Python 3.  In most cases, this isn't difficult with 2to3.
The 3.x.x versions will be backwards compatible with your RaceDB database as usual.  You can continue to use your existing database.

More details:

As the underlying modules that support CrossMgr etc. will soon stop supporting Python 2.7, supporting Python 3 is important so that CrossMgr programs continue to be available for years to come.

The Python 3 conversion is not expected to change performance (maybe slightly faster) and mostly involves small syntactic and organizational changes.  However, there are some issues that have come up.

Python 3 only manipulates strings in uncode format, and reading/writing data externally must provide an explicit encoding (usually utf-8).  Python 2.7 was more flexible about this and could maintain regular strings and unicode internally (of course, this could cause other problems too).

A big challenge has been in reading/writing data to sockets and converting images to/from graphic representations (png, jpeg, etc.), and there are a number of idiosyncrasies to swear over ;)

For example, in Python 3, json.dumps( ...) returns a unicode string.  If you then try to write it to a socket with send(...), it fails as "send "requires "bytes" not "str".  A bit of a surprise because one generally writes json to a socket.
The solution is s.send( json.dumps(...).encode() ) which encodes the string to bytes in utf-8.  Fortunately, this two step approach also works in Python 2.7.  Unfortunately, I can't find a tool that can check this statically, so, lots of testing required cause the code just blows up if this happens.

Another issues is that open(fname, 'rb') opens a file returning bytes, not a str, and open(fname, 'r') returns str not bytes.  One has check every open call to check whether it is dealing with binary data (images, etc.) or text data in utf-8.  As CrossMgr creates lots of html, ftp, pdf, Excel, ... files there is a lot to check.  Again, I have not been able to find a tool to check for this (more testing...) 

Finally, you cannot put bytes into a StringIO - you must use a BytesIO.  This mostly impacts reading images, but, Python 2.7 has no Bytes object, so coding changes are required.

The good news so far is that this process has required me to do a line-by-line code review as well as run pylint.  This has resulted in fixing over 30 bugs (obscure) so far.  This should help with those once-in-a-while CrossMgr hangs.

More details to come as the process continues.

CrossMgr: Now with better Pulling

posted Dec 28, 2018, 8:32 AM by Edward Sitarski

Riders are not pulled (80% rule) in every race, but at the higher levels it has to be done (and it's a UCI rule).

In previous versions of CrossMgr, pulling was designed to be done real-time during the race.
An official would pull the riders in the 80% zone, then radio the pulled rider to the finish.
One entered the bibs into CrossMgr, record the last lap time, then mark the rider as pulled.

This doesn't always work.  Sometimes riders get pulled to quickly to be recorded in real time, or there is no radio connection with the 80% zone at all.  And, if it didn't work (or you got anything wrong), it was painful to fix in CrossMgr.

Officials have a standard form where they enter the Laps to Go and the Bibs in the order they were pulled.
It would be great to be able to enter this format directly into CrossMgr and see the results updated accordingly.  As usual, it should be easy to fix errors (wrong bib numbers, wrong laps to go) at any time.

This is now possible in the Pulled screen in CrossMgr.  Simply enter the Laps To Go and the Bib numbers pulled.
CrossMgr will take care of the rest.  Entries on the Pulled screen take precedence over recorded laps.  For example, if a rider is pulled but refuses to stop and records more lap times, these will not count in the rider's ranking.

Record a rider a pulled by mistake?  Or, recorded the pulled sequence wrong?  No problem!  Just fix it in the Pulled screen and the results will be fixed.

Available in CrossMgr 2.4.0.

CrossMgrImpinj 2.21.11: Greatly improved RFID accuracy

posted May 17, 2018, 6:23 PM by Edward Sitarski

Since CrossMgrimpinj was released, it used a "First Read" approach to recording a time.
It recorded the first read time of the tag as it approached the antenna

Unfortunately, the shape of the read zone of the antenna is not straight.  It looks more like this:
Image result for rfid antenna pattern

Two antennas on either side of the finish line overlap and make a straighter line.  However, the read zone is still not straight, so riders may not be reported in the same order as crossing the line.
And, this does not help with what we really want to know: the exact time the rider passes the antenna.

There has been considerable research trying to improve this using additional information from the reader.
In additional to the timestamp, the reader can return the PeakRSSI (Signal Strength), Phase Angle and Doppler Shift (more on those last two later).

Rather than just report the first read, the idea here is that we collect as many reads as possible as the tag crosses the read zone.  In the "E Phase" diagram above, imagine a rider crossing the read zone at speed and recording as many reads as possible.

We then combine all the reads together and compute at time when the tag actually crossed the finish line.

To see how this is done, let's start with PeakRSSI, or Signal Strength (measured in db).  This is the strength of the returned RF signal from the tag back to the reader.

The diagram below shows actual reads (dots) from 3 riders crossing a finish line.  As you would expect, the signal strength starts weak, increases to a maximum, then decreases.

Diagram courtesy of Stuart Lynne.

In a perfect world, the dots would line up on a parabola.  In reality, noise (multiple back scatter paths, internal reader error, etc.) means that the data is imperfect.
If the noise is random it should 'even out" over a number of samples.
So, if we find a parabola that is a "best fit" to the data using quadratic regression it should be very close to the "true" parabola.  These best-fit parabolas are shown in the diagram.

Once we have a parabola, we can get the time at its apex.  This is the "best estimate" where the tag crossed the antenna (i.e. the signal strength is strongest).  Interestingly, the "best estimate" time does not correspond to the time of any actual tag read.  Rather, it is a composite of a number of reads taken together (and hopefully ore accurate).

How does it perform in practice?

Experiments with criterium bunch finishes showed that the results agree with a camera much more accurately.  When they don't, the riders are very close.  Far fewer corrections to the results were required than First Read..

Things to consider:

Tag alignment is important!  Tags should be mounted rigidly on the bike so the flat side of the tag presents to the antenna.  If the tag is misaligned, its transmission strength could be skewed, and this will affect the accuracy of the result.

Antenna alignment is important!  Make sure the antennas are pointed properly.

The feature is now available in CrossMgrImpinj 2.21.11.  In the Advanced reader options, choose "Quadratic Regression".
PeakRSSI works with all LLRP readers.

Special thanks to Stuart Lynne and Andrew Paradowski for their help in developing this feature.

I plan to look at Phase Angle and Doppler Shift.  Unfortunately, these features are only available on Impinj readers.
So far, Phase Angle has proven difficult to analyse at it wraps around.  Doppler Shift could be noisy as the reader has to detect frequency changes relative to the speed of light.
Both techniques should be less sensitive to tag alignment, which could lead to more accuracy in the future.

RaceDB: New RFID Tag Check Workflow

posted Apr 1, 2018, 6:24 AM by Edward Sitarski

The latest version of RaceDB 1.32.73 supports a workflow requiring that each rider's RFID tag is checked before the registration is considered successful.

If the rider checked in via self-serve tag read, or if reg staff read the tag then the tag is considered "checked".
However, if the rider is identified by bib number, license or name, a tag check will be prompted for the reg staff.
Staff then press the "Check Tag" button and RaceDB will validate that the tag is working correctly.
Once a rider's tag has been checked at a Competition, reg staff won't be prompted again.

This ensures that the rider has his/her tag and that the tag is working before the race.

If you don't want tag checking, uncheck the "Do Tag Check" box in the "Competition Edit" screen.  This will return to the old functionality.

In the past, the greatest source of errors was in results (rider incorrectly +/- laps, unidentified riders, etc.).
CrossMgr error correction and RFID readers have greatly eliminated these problems.  Now, almost all race issues can be traced back to problems in registration..

RaceDB RFID workflow checking is one step closer to "the perfect race" - all riders have correct and working tags, correct and unique bib numbers, signed waivers, correct licenses with everyone is in the right category.

CrossMgrVideo: Low Light Camera Update (Success!)

posted Jan 29, 2018, 3:59 PM by Edward Sitarski

CrossMgrVideo (and CrossMgrCamera) would often record blurry photos at CycloCross races - even during what appeared to be bright conditions (the middle of an overcast day).  The images were almost useless as the bib numbers to too blurry to see and the riders were most unrecognizable.

Fortunately, with the rising popularity of automotive dash cameras, low-light usb video cameras are available at low cost.
I ordered this one on ebay for under $100 CDN with the IMX 322 sensor.  It took about 1.5 months to arrive.

Above are photos of some artwork taken with the low-light Sony IMX 322 and a conventional sensor at the same illumination.
The difference is highly encouraging (to say the least).  The low-light camera is much more sensitive, much more true to color, and has a much shorter exposure (less blurry for moving objects).
For other comparisons, see here and here.

The low-light camera shows the image more brightly than the human eye.  As I understand it, the Sony IMX 322 is being replaced with the newer Sony 291 STARVIS sensor, which is even better.  So, expect even better low-light cameras to be available in the future.

I noticed that the low-light camera runs hotter than the conventional one.  I recommend that the computer be on a power supply as the camera could drain the batteries quickly.

1-10 of 228