send null when lat/long not provided in CLI, not -9999/-9999 - closed in 7ce55f020b
cache locations and fill in values when locations aren't parsed out of packets
Sometimes packets have no SSID, so we need to avoid sending even an empty string - closed in ad5f2ccd0d
Closes #10.
- [x] add location of spotter (more command line argument(s))
- [x] only include location if values aren't -9999
- [x] allow negative numbers in lat/lon CLI https://docs.rs/clap/latest/clap/builder/struct.Arg.html - closed in 21499a93d9
- [x] send null when lat/long not provided in CLI, not -9999/-9999 - closed in 7ce55f020b
- [x] cache locations and fill in values when locations aren't parsed out of packets
- [x] Sometimes packets have no SSID, so we need to avoid sending even an empty string - closed in ad5f2ccd0d
Had a thought about a missing piece as I was falling asleep, now I can't remember it!
EDIT: Remembered, it was that I didn't check the lat/lon values against 9999 before sending them on.
Had a thought about a missing piece as I was falling asleep, now I can't remember it!
EDIT: Remembered, it was that I didn't check the lat/lon values against 9999 before sending them on.
Are these values too long? Spothole doesn't seem to pick up all the locations.
`"dx_latitude":47.94133333333333,"dx_longitude":-97.02683333333333,`
curl seems to work:
`curl --request POST --header "Content-Type: application/json" --data '{"dx_call":"M0TRT","time": 1761415746, "freq":14200000, "comment":"Test spot please ignore", "de_call":"M0TRT", "dx_latitude":47.94133333333333, "dx_longitude":-97.02683333333333}' https://spothole.w1cdn.net/api/v1/spot
`
Oh things got simpler; you can send an empty string to json lat/lon and it will be interpreted as a bad location by spothole. I thought I would have to send a specific None or null or empty number (whatever that looks like).
Oh things got simpler; you can send an empty string to json lat/lon and it will be interpreted as a bad location by spothole. I thought I would have to send a specific `None` or `null` or empty number (whatever that looks like).
Location caching is next. Deciding whether to finish off this PR with only sending spots with parsed locations (so the map always works) or to leave it as everything for now (and the map locations will be overwritten by UI frames with no location data).
Location caching is next. Deciding whether to finish off this PR with only sending spots with parsed locations (so the map always works) or to leave it as everything for now (and the map locations will be overwritten by UI frames with no location data).
We discussed #11 on Matrix: https://matrix.to/#/!bVjIHuavAgnyyjeDTM:matrix.farpn.net/$bryXVDi7prNeZBnEZwKjf9ysMh19A2D1V-ilO8zbnz0?via=matrix.farpn.net&via=matrix.org&via=im.xoo.sh
We really should submit dx_ssid as integer rather than string though.
Ian has updated Spothole to account for SSIDs: https://git.ianrenton.com/ian/spothole/issues/68#issuecomment-759.
I have updated https://spothole.w1cdn.net with the changes.
We really should submit `dx_ssid` as integer rather than string though.
Sometimes packets have no SSID, so we need to avoid sending even an empty string (added to punchlist)
- Sometimes packets have no SSID, so we need to avoid sending even an empty string (added to punchlist)

Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #10.
21499a93d97ce55f020bad5f2ccd0dHad a thought about a missing piece as I was falling asleep, now I can't remember it!
EDIT: Remembered, it was that I didn't check the lat/lon values against 9999 before sending them on.
Are these values too long? Spothole doesn't seem to pick up all the locations.
"dx_latitude":47.94133333333333,"dx_longitude":-97.02683333333333,curl seems to work:
curl --request POST --header "Content-Type: application/json" --data '{"dx_call":"M0TRT","time": 1761415746, "freq":14200000, "comment":"Test spot please ignore", "de_call":"M0TRT", "dx_latitude":47.94133333333333, "dx_longitude":-97.02683333333333}' https://spothole.w1cdn.net/api/v1/spotI think I was running on two machines at once, one only with locations and one with all UI frames. This was messing up the mapping.
Oh things got simpler; you can send an empty string to json lat/lon and it will be interpreted as a bad location by spothole. I thought I would have to send a specific
Noneornullor empty number (whatever that looks like).You can also send lat/lon as strings:
curl --request POST --header "Content-Type: application/json" --data '{"dx_call":"W1CDN","time": 1761447599, "freq":14200000, "comment":"Test spot please ignore", "de_call":"W1CDN", "dx_latitude":"47.94133333333333", "dx_longitude":"-97.02683333333333"}' https://spothole.w1cdn.net/api/v1/spotAnd spothole will parse/map right:
Location caching is next. Deciding whether to finish off this PR with only sending spots with parsed locations (so the map always works) or to leave it as everything for now (and the map locations will be overwritten by UI frames with no location data).
We discussed #11 on Matrix: https://matrix.to/#/!bVjIHuavAgnyyjeDTM:matrix.farpn.net/$bryXVDi7prNeZBnEZwKjf9ysMh19A2D1V-ilO8zbnz0?via=matrix.farpn.net&via=matrix.org&via=im.xoo.sh
Leaving this running for a while to see if location caching works, but fewer 20m packets in the dark.
I opened a ticket with Ian to see about differentiating SSIDs in Spothole code: https://git.ianrenton.com/ian/spothole/issues/68.
Ian has updated Spothole to account for SSIDs: https://git.ianrenton.com/ian/spothole/issues/68#issuecomment-759.
I have updated https://spothole.w1cdn.net with the changes.
We really should submit
dx_ssidas integer rather than string though.Not sure I completely understand, but clap must be handling empty references.