Differences in the data the mock interface outputs vs the live one.

[swampmonster]

I've been trying to get livetime to support signal strength from delta5 but since when
--mock is used that data is not there they would like the mock interface to be changed
to match the live one.

I figured i'd check in and see if there was any interest in merging such a change
or if this repo is more or less completely idle at this point.

I'm willing to write the code myself and submit a pull request if there's interest.

[scottgchin]

Sorry been out of town. I'm not sure I follow what you mean

[swampmonster]

Sorry been out of town. I'm not sure I follow what you mean

If i run the timing server with —mock the json it outputs is missing a few fields that are present when I run it “live”.

I had a discussion with live timings support about making use of the rssi_raw data to indicate the signal strength at a pass in their interface and they said that for them to add that the output from the timing server in —mock mode has to actually be representative of the data being sent when the system is “live”.

From memory when a pass is triggered while in —mock it only outputs the node and the freq while in normal working conditions it also outputs rssi_raw, rssi_peak and one or two more fields.

So my idea was to just add those values in to the simulated pass output with random data so that it mirrors what is sent during a “live” pass.

[swampmonster]

I was poking around the code this morning because i was bored and i noticed that the code to do this is already in here it just isnt used in the timingserver.

https://github.com/scottgchin/delta5_race_timer/blob/master/src/delta5server/server.py#L710

Compared to:
https://github.com/scottgchin/delta5_race_timer/blob/master/src/timingserver/server.py#L243

Which emits a hardcoded json object with less data.
It looks on the surface like just changing the call in the timingserver to be the same as the other one would work but im not 100% sure on that.