Now the processing of the information from the RFID module (processing of the recorded chips) is not done in the thread but in an extra process that has a higher priority set. The motivation was faster (and less unaffected) processing of the information from the RFID module.
Addition of the possibility to test the connection settings from the slave device to the master device. This feature is available from the Basic Configuration edit on the Upload tab.
Addition of a function to set or reset the counters that store the last uploaded chip log or start on the master device. This functionality is available from the Basic Configuration edit on the Upload tab. It is only relevant for multiple devices communicating with each other.
When a chip log(s) or start(s) is(are) deleted, the entry with the highest id is now checked against the counter of the last entry sent to the master device. Again, this is only relevant if the device is set as a client and is sending its data to the master device.
Minor fix in checking the saved data from the Edit Racers feature – if a racer had the Incomplete flag set it was unnecessarily checking the Year of Birth field.
Fix on the race start page – so that after starting a race, if it is an interval race, a query appears when trying to exit the page. This is to prevent a person e.g. if he/she is with a tablet out of wifi range from missing the countdown of the racers in case he/she accidentally runs over and should refresh the page.
Addition of buzzer support for beeping when a unique chip is detected. The beep is independent of the time tolerance setting for recording the chip entry into the database. By default, the beep is made when a chip is logged. The time tolerance is set to 1 second to avoid unnecessary beeping when a given chip is recorded repeatedly. If multiple unique chips are recorded at the same time, the device will beep accordingly. To avoid overflow – e.g. after a large number of chips have been recorded, the maximum queue limit for beeps is set to 10.
