Van callsigns are not properly ingested

[ascended121]

settings.json contains a setting for van callsigns, but according to Aravind this is non functional. Incorrectly configuring this setting causes the program to crash during initialization. If this setting is not in use, remove it until it is.

[nmrossomando]

I know you all are probably gone, but when you get a chance can you set up, induce this, and send me the result? This should not be possible. Literally, the code does nothing with that setting except read it, and the reader is robust to malformed inputs.

[ascended121]

Quinn was running tracking.... Paraphrasing him... "Aravind said they do work but the documentation says they don't work and not to touch it."

Quinn said the program would still run but wouldn't track anything.

[nmrossomando]

Van tracking has never worked and I never indicated to anyone that it did. Quinn was correct in his interpretation of the documentation. balloonCallsigns is the important setting.

"Not tracking anything" seems to be the same old issue of "the program looks like it froze". I doesn't do anything until it hears a packet on the radio...

[ascended121]

Can it updated to ping the radio every once in a while and to print something (maybe a period, something non intrusive) so that the user can tell it's still connected/working?

[nmrossomando]

It can't ping the radio (That's the radio's fault). If someone does find out how to talk to the radios, that's be cool, but I could never figure it out and the documentation isn't great.

It prints an "untracked callsign" message on radio receive of anything that isn't us (or more specifically, anything that isn't in the settings.) It's probably possible to hack a small timeout message into the routine. This seems to be a recurring issue, so that may be worthwhile.