Welcome to Cross Manager! Cross Manager is software used to score bike races. It has many features including support for RFID chip readers. Full documentation is in the CrossMgrHtml directory or under Help in the application.
In addition to the application help files, there is a tutorial for CrossMgr here and an explanation of an RFID implementation using CrossMgrIpinj here.
The software consists of a set of executables. For Cyclocross, MTB CX, TimeTrial, Road and Criterium races, you will need:
If you are scoring Track races you will need:
CrossMgr was designed to work with RaceDB, a web-based database for competition management and race check-in. RaceDB handles race check-in including issue bib numbers and creating RFID tags on-the-fly. This eliminates most sources of administration error (missing/non-working/wrong RFID tag). Additionally, RaceDB supports a self-serve kiosk feature that allows riders to check-in with their tags automatically.
All applications are written in Python and compiled into machine code. Builds are made available for Windows and MacOSX. In order to publish results, an internet connection is required.
The minimum system requires are as follows:
As a user, you can install the CrossManager applications on Windows, Mac OSX, and Linux. Only x86 64 bit platforms are supported. The Windows and MacOSX versions are available as binary releases. See the Releases tab in the github repo for binaries.
You can still run on Linux too, but you have to run from the source code.
From the Releases tab, download the CrossMgr_x64_VERSION.exe file. Run the file and follow the on screen instructions.
When running the installer, Windows will likely complain that it is a unknown publish. Click the MORE INFORMATION link in that dialog, and then click the RUN ANYWAYS button. The install will proceed.
CrossMgrImpinj, TagReadWriter, CrossMgrAlien, CrossMgrVideo, SeriesMgr, PointsRaceMgr and SprintMgr follow the same install process. They will all install into the CrossMgr program group.
From the Releases tab, download the CrossMgr-VERSION.dmg file. From the finder, double click the DMG file to open it. Once the window comes up, you simply drag and drop the CrossMgr.app folder to your Applications directory. From the Applications folder, you can now run CrossMgr like any other Mac app
Most recent Mac OSX versions will require you to press CTRL before clicking on the app for the first time, and then clicking open. The app is a non-signed program that MacOSX will not open otherwise. This is only require the first time you run it. MacOSX will also ask a few questions when the program is run, and you must confirm with YES (Allow Networking, Access to Documents Directory, etc, etc.)
CrossMgrImpinj, TagReadWriter, CrossMgrAlien, CrossMgrVideo, SeriesMgr, PointsRaceMgr and SprintMgr follow the same install process.
Because MacOSX has added a lot of security to the system, some weird problems can occur that prevent the application from starting First, and foremost, because the apps are not signed, you must CTRL-CLICK the icon, and select Open from the pop up menu, and then click Open on the dialog box to start the application the first time Additionally, MacOSX will prompt the user for permissions to access the network, documents folder, etc... Sometimes, the splash screens for the application will cover this dialog box up, or it could end up behind the application. Unless you select ALLOW, the application can't work. For example, CrossMgr requires network access to run. Additionally, sometimes the application just won't start. Typically, it's icon will start to flash, and then nothing. To see why and what is happening, run the application from the command line from the app's MacOS directory. For example, for CrossMgr:
Python is set up to dump logs to stdout which usually indicates the problem. Sometimes, the problem of starting the application will just go away.
Follow the instructions for building CrossMgr on your system. Check the wxPython web page for specific instructions for how to install it on your distro.
There are two scripts to build CrossMgr and the associated tools. One for Linux/Mac and one for Windows Each platform has a build script to install the dependancies, build the binaries for the application, and package the programs.
| Script | Help Parameter |Purpose | |---------|---------|--------| | compile.sh | -h | Linux/MacOSX Build script | | compile.ps1 | -help | Windows build script |
Use the help parameter to find the available command line options. You can build programs individual or run parts of the build process individual using different command line options.
All platforms currently work with Python 3.7.x. Python 3.8 and newer is not yet supported by pyinstaller which freezes the python code to binary form.
Windows builds require InnoSetup V6.x from [https://www.jrsoftware.org/isdl.php]. If you do not have Inno Setup installed, the windows build will fail.
The build has been automated, and compile.sh/ps1 script does everything to enable the developer to build CrossMgr and the associated tools. However, you can also download the binary from the github Releases tab.
Linux dependancies are contained in the linuxdeps.sh script.
The build procedure for Linux and MacOSX platforms are as follows:
bash compile.sh -S
bash compile.sh -a -A
When the build is complete, the resultant DMG/AppImage files will be in the release directory. The above process is what the build.yml Workflow file (.github/workflows/build.yaml) uses to build the code on GitHub.
The build procedure for windows are as follows:
.\compile.ps1 -all -everything
When the build is complete, the resultant exe installer files will be in the release directory. The above process is what the build.yml Workflow file (.github/workflows/devbuild.yaml) uses to build the code on GitHub.
By default, the version of the programs is setup with -private in the name to indicate any local builds are alpha versions and not meant for distribution. Any local builds will receive this version number tag and it will be displays on startup and in the About dialog. Updating the version number for any one of the applications requires that this private tag remain intacted, or the build will fail on github. The private tag is replaced with the appropriate version by the build script on github on a development or release build.
With the workflow setup on Github, builds are automatic. Development is a two stream or branch system. The dev branch is where all development work occurs. Developers are encouraged to branch dev into feature and bugfix branches to do actual work, and then merge changes back into dev. Changes to the dev branch pushed to github are automatically built as a "Development Release" under the 'latest' tag. Only one development release is available at any one time. The purpose of the development release is to allow for beta testing of new code before it is released. The version number of all applications will be denoted with "beta" and the git short release number to ensure users can report issues against a specific version.
When code is complete, and ready for a production release, the code is merged back into master, and tagged with a semver style tag. The tag format must be in the format v3.0.0-2020010101010. The tag number is used to create the version number for each application. The build is setup to reject building a release where the tag is not this format. Developers should use the compile script to create the release to ensure a proper merge and tag is created. The build system automatically creates a release build on github when the tag is detected and places the binaries in the Releases tab on github.
Every time a build is run, github will build the code. The purpose of this build is to ensure the code will build on all platforms. When a release is added, it will appear in the releases tab, and github will run the workflow to build the code for MacOSX, Linux, and Windows.
To make a release, do the following:
bash compile.sh -r
You must be on the dev branch without any pending changes to make a release. If the version number of an application is to be incremented, it should be done in the dev branch, and checked in prior to making the release.
A build can also be forced by tagging the master branch. This is done with the -T option (Linux/Mac) and -tag (windows). You can only tag the master branch with this option.
I have an Invelion device, and I wrote the following Python script to fetch the passages:
``` import time import socket from datetime import datetime
def receive_data(sock): buffer = sock.recv(1024 * 4) buffer = buffer.hex() messages =  while len(buffer) > 0: index = buffer.find("a0") if index == -1: break message = buffer[index:index+42] messages.append(message) buffer = buffer[index+42:] return messages
def process_message(message): chip_code = message[34:38].upper() now = datetime.fromtimestamp(time.time()) now_str = now.strftime("%Y-%m-%d %H:%M:%S.%f")[:-3] file_name = chip_code + " " + now_str + ".txt" with open("passings/" + file_name, "a") as file: file.write(chip_code + " | " + now_str + "\n") file.close()
def client(host='192.168.0.178', port=4001): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_address = (host, port) print("Connecting to %s port %s" % server_address) sock.connect(server_address) try: readings, second, sends = , datetime.now().second, 0 while True: message = "A006FF8B010001CE" sock.sendall(bytes.fromhex(message)) sends += 1 messages = receive_data(sock) for msg in messages: size = int(msg[2:4], 16) if(size == 19): readings.append(msg) process_message(msg) old_second = second second = datetime.now().second if second != old_second: print("Second: %d" % second, "Sends: %d" % sends, "Readings: %d" % len(readings)) readings =  sends = 0 #time.sleep(1)
except socket.error as e: print("Socket error: %s" % str(e)) except Exception as e: print("Other exception: %s" % str(e)) finally: print("Closing connection to the server") sock.close()
I would like to integrate with CrossMgr, perhaps saving passes directly to the pass database. What would be the best format to deliver these tickets?
Open water swimming and Triathlon (swim) timing would be easier if one can somehow use a NFC reader with Cross Mgr. The option with U-Tags are there to use with the normal RFID readers, but are quite expensive. NFC bracelets are cheap and with swimmers it is easy to channel them close to a NFC reader. Can also be use for Trail Running at intermediate reads on the trail.
Also fixes a bug where team results would be uploaded to the same filename as the individual results.
If there is only a 'Name' field, and the contents aren't comma-separated, split on the last space in the name if there is one, or failing that, treat the entire thing as LastName. A minor convenience for working with Excel files that have come from somewhere other than CrossMgr. This also allows SeriesMgr to reliably read its own Excel output, where the names aren't always comma-separated.
(Hopefully I've made this pull request against the 'dev' branch correctly.)
A small feature to allow the user to edit the race names as they're displayed/output by SeriesMgr. This means you can make the naming of races consistent across a series by making changes on the Races screen, rather than having to rename the race files. This is particularly useful if you're a habitual user of lower case and dashes or underscores in filenames, but want mixed case and spaces in the final output...
Adds support for a 'Machine' field to CrossMgr, SeriesMgr and CrossMgrVideo, for sports with an engineering aspect to the competition. (See https://github.com/esitarski/CrossMgr/issues/50.) I've used 'Machine' as it seemed like the broadest term that would encompass bikes, trikes, velomobiles, pedal cars, wheelchairs, soapbox racers, skateboards, etc.
In CrossMgr this is a single line of code :) All it does is allow a 'Machine' field to be imported from Excel, and displayed / outputted as appropriate.
The changes to SeriesMgr are a lot more involved. The field is handled broadly like 'Team', with its own aliases and so on. Where a rider uses more than one machine over the course of a series, they are ranked in order of frequency and pretty-printed in an appropriate manner.
CrossMgrVideo accepts the 'Machine' data from CrossMgr and stores it in the list of triggers (this is particularly useful in HPV racing where the design of the machines is the primary identifying feature). It's also added to exported photos, when present.