Home - etemu/satar GitHub Wiki

Satar Node Quick Guide:

You need at least one SatarNode to capture events. Each node has up to two inputs (at pin 2 and 4) which can be monitored. If the input is armed and a state change is detected, the ISR (Interrupt Service Routine) sets a flag and notes the time.

A packet for the SatarServer is then forged and send out, via the W5100 or the ENC28J60, you should define either of them as present in the firmware (#define W5100, #define ETHERCARD).

The http/GET request packet arrives at SatarServer's satar.php and is then stored in the given SQL database, which is defined by the SatarServer/config/config.php. It is also forwarded to the SatarServerRuby via http/POST. Both the database server and the SatarServerRuby reply with a status code, which are in turn stripped down (due to the low ressources at the nodes) and forwarded to the Node which sent the request.

The SQL database stores all incoming packets - no processing is happening there, this is mainly as a backup and for redundancy, if someone trips over the cable or a (preferably non nuclear) EMP is happening nearby.

A race is started via SatarServerRuby's web interface. Each racing run has its own $raceID, an unsigned int starting at 1. If no race has been set active, but there are incoming race events from armed hardware nodes, then raceID 0 (zero) is used, e.g. for testing the system or training runs.

SatarServerRuby processes the incoming packets, stores them in a Redis database instance and updates the web ui accordingly. Every connected web client can have a look at the incoming packets at the debug window. Special views for race officials who can enter the race starter's unique ID ( $uID or simply ID) are present via the filter function. Just filter the packets for the corresponding events and nodes. E.g. every hardware event packet from node 42 corresponds to a starting participant, while node 43 monitors the finish line.

If a matching pair of two entries with the same $uID and both, a packet from the start node and the finish node are present in the temporary Redis instance RidersInRace$raceID, we have a successful pair and can combine them: The resulting time is calculated ( $TimestampFinish - $TimestampStart ), written to Redis in RaceResults$raceID_, the dito named MySQL table, and immediately shown on the web ui's results subpage fed by the aforementioned Redis table.

The approximate minimum run time $raceMinInterval and maximum run time $raceMaxInterval (with enough headroom for the slowest participants) can be set in the web interface.

If there is no matching counterpart for one entry during the specified $raceMaxInterval, the entry is marked with a $timedOut flag. This is especially useful, if someone DNF (Did Not Finish) or the current run is aborted/paused. Lonely timed out event packets can be flushed out of the RidersInRace$raceID table with a button in the web interface.

The $raceMinInterval helps with matching the incoming events if more than one participant is in race. SatarServerRuby monitors all events and suggests a $uID for an incoming event from the node at the finish line at the user interface.