Show predictions on old sondes

[TheSkorm]

It looks like we hide predictions when there's been no new data and the alt is less than 600m, however this might not be where the sonde finally lands.

Do we even want to hide predictions for landed sondes? The predictor tries pretty hard to not generate bogus landed predictions so it might be safe to remove this logic (plus other places?) not sure?

https://github.com/projecthorus/sondehub-tracker/blob/master/js/tracker.js#L1707

[smwnwrght]

If I've understood the code correctly, the line you've referenced is the logic for changing the icon from 'parachute' to 'landed'.

It looks like there is separate logic for turning off predicted landing sites: if the altitude of the sonde is greater than 350 m keep it, otherwise remove it.

https://github.com/projecthorus/sondehub-tracker/blob/4b53da0682f3fe71fefe421be73c6e5d6f73fc3f/js/tracker.js#L1725C1-L1725C43

Currently 'in the field' we are doing ad-hoc calculations based on last known vertical and horizontal speed.

e.g.

• last known sonde data was h -5m/s, v 15 m/s, alt 600m
• ground level is 300m, so 300m left to fall
• sonde travelling 3 times faster horizontally than vertically, so will travel 900m

Based on the premises (which I think are both true) that...

1. it is probably favourable to have a Sondehub-generated landing site prediction, rather than performing this type of calculation.
2. the landing site prediction has no knowlege of the current landing site. Therefore I assume the target is at sea level (0m altitude)?

...my suggestion is that for landed sondes, the UI should display the prediction line as a 'search line', but remove the target symbol.

[darksidelemm]

Tawhiri (the predictor engine) will predict down to ground level (based on the SRTM dataset), so the last position will be at local ground level (at least, fairly close). So if we can display the last prediction, that'll probably be the best information we have (of course in many cases the GFS model is inaccurate at low altitudes...)

[smwnwrght]

My apologies Michaela, you are correct about the way sondes are identified as 'landed'.

This logic follows through to updatePredictions() which calls removePrediction():

https://github.com/projecthorus/sondehub-tracker/blob/4b53da0682f3fe71fefe421be73c6e5d6f73fc3f/js/tracker.js#L4837

https://github.com/projecthorus/sondehub-tracker/blob/4b53da0682f3fe71fefe421be73c6e5d6f73fc3f/js/tracker.js#L4849

I have forked and run updated code locally. Predictions on old sondes look mostly reasonable. What's the best way to share the updated code? (I'm new to github).

[darksidelemm]

The PR is now merged into testing, so will be visible at testing.v2.sondehub.org

I think that we should make use of the ground level estimate (e.g. take the last altitude from the last prediction, and this is the ground level), and use this to: a) Set whether the landing icon is used or not (e.g. set a threshold of maybe less than 100m above local ground level) b) Remove predictions if the last position is maybe less than 50m above local ground level.

[smwnwrght]

Thanks Mark, that's great!

As an alternative solution...

Sondehub currently considers a sonde 'landed' if either:

1. it has (a) gone up (b) has negative ascent_rate ie is descending and (c) is under 350 meters altitude, or
2. it is (a) under 650 meter altitude and (b) has no position update for more than 30 minutes

On your suggestion, generally sondes lose connection a long time before 100m above ground level. I think position updates are a better determinant of whether a sonde has landed. I would suggest if either of these are going to be amended it would be (2) rather than (1).

It appears sondes manage to relay position updates once a second even at low altitiudes. So these cutoffs could be - for example - (a) under 1000m and (b) no position update for 1 minute.

[darksidelemm]

Not sure on that. The tracker shows the last known position of the sonde, and all state changes are driven by the arrival of new data (either sonde telemetry, or predictions).

If that's in the air, then we should be showing the sonde as being in the air. If it's close to ground (by whatever means we determine), then it should be shown as landed. I don't think we should change the state of anything without any new data coming in.

I think just the better knowledge of what ground level actually is will improve things a lot.

[smwnwrght]

OK so a bit of testing and I am fairly confident that currently the state is based partly on timing - but only when the page is loaded.

After 30 minutes, this balloon goes from parachute

to landed after >30 minutes (updating the icon requires a page refresh)

I assume that on page reload sondehub treats the latest data as 'new data'.

I think that intuiting that a balloon has probably landed - despite no new data - is preferable to just showing the last known status of the balloon which will almost always be 'parachute'.

There are several possible methods for intuiting when a balloon has landed, and I agree that being under 100m above ground level is probably better than what is currently used.

However just using this metric would mean that a lot of balloons still display parachutes long after they have landed.

After a bit of consideration, I wonder if a clever way of donig this would be to assume that it's landed if the current time is after the most recent predicted landing time.

[smwnwrght]

Looks like the API for prediction data is only called during panTo(), which occurs whilst a user is 'following' a vehicle e.g. after they have clicked on a balloon.

https://github.com/projecthorus/sondehub-tracker/blob/4b53da0682f3fe71fefe421be73c6e5d6f73fc3f/js/tracker.js#L1182

Therefore the majority of balloons won't have prediction data available.

Sorry this is now encroaching on #302...!

[smwnwrght]

Some potentially reasonable criteria for minimally polling the predictions API.

1. poll API for ground level, either a. if burst, on page load b. if not burst, on burst
2. poll API again for landing time when within 1km of ground level
3. assume landed if a. current time is after predicted landing time b. some catchall criteria

Would love your thoughts @darksidelemm.

[darksidelemm]

It all has to happen as packets arrive - I don't think there's anything that goes through the vehicle list at regular intervals and does any 'cleanup'.

We do have a separate API that can be used to get ground level if necessary, but I think getting the data from predictions is the best approach.

[smwnwrght]

Thanks, that makes sense.

It would be doable during updateVehicleInfo if there's some solid check that the balloon is definitely descending right?

Like this

// it's safe to assume the balloon has burst if the sonde is some distance x lower than its highest point

var x = 100 // for example

var burst = (newPosition.gps_alt < vehicle.max_alt - x)

If you're happy with this approach, I can try to implement it.

...

This would also be a more robust way to decide which icon to display (balloon / parachute) compared to the current check which sometimes leads to slow-falling sondes showing as balloons:

[darksidelemm]

I would prefer to keep the ascent rate check. If you only go by a comparison with max altitude then balloons that are floating slowly down (and then sometimes back up) will show up with a parachute, which is not really correct. The current -3m/s descent rate threshold could possibly be narrowed a little, maybe to -2m/s, but I wouldn't want to change it much more than that.