dl9rdz / rdz_ttgo_sonde

266 stars 93 forks source link

Another lofty feature request #33

Open MikeTango opened 3 years ago

MikeTango commented 3 years ago

Hi,

i was thinking about a permanent installation for radiosonde decoding. The current model is "attach a boatload of precise SDRs to a raspi and run your favourite flavor of software, all of which come with gaps in the features". This approach is complicated, power-hungry and expensive. With the ESP32 TTGO / T-Beam we do have an inexpensive, tiny piece of hardware that runs for ages on a e-cig battery and needs (hopefully) only a few minor adjustments in the software that would enable it to:

This would result in a device that could be deployed with a big battery and a cheap 4G modem in a tupperware container, running days at a time in a remote place, merrily streaming sonde info into the internet, or being attached to an antenna on a building without any grounding issues. It could be put on a platform that gives you a reception advantage (kite, tethered balloon, rc plane), be your main sonde chaser while still updating the usual websites, given to your friends and put in their attic, using their wifi as a feed, or deployed in that cabin in the woods to extend the reception network, just with a USB charger dongle.

Anyone up to the task?

dl9rdz commented 3 years ago

You can configure the channel hopping without software modification in screens.txt (never tested it, but it should work), at least close to what you want. There is a timer for just time (so you can switch channel after X seconds) and another timer for "time with continuously successfully decoded frames" (so you can switch channel after X seconds with only successful decoded frames). Its not exactly what you want, but very close.

The default configuration in the decoder display is

timer=-1,-1,N
timeaction=#,#,0

(N is replaced by the norx timeout value from the web config), which means it stays on that display forever, unless nothing is received for N seconds, in which case it goes back to display 0 (scanner))

You can replace that with, for example,

timer=-1,5,N
timeaction=#,+,0

to force the software to go to the next frequency after successfully decoding 5 frames in a row (or timer=5,-1,N, timeaction=+,#,0 to do so after 5 seconds independent of whether something was decoded or not)

Successfully decoded results can be dumped via TCP or UDP. This has been tested with APRSdroid (TCP) and dxlaprs software (aprsmap, etc.; UDP).

There is only one caveat: My software does not do filtering as rigorous as other software does. This is why I intentionally do not advocate feeding the output to aprs.fi or other public sites. For sonde types that do not send their ID on each frame, and multiple sondes active on the same frequency (we have this for example with DFM in military trainings), data might get sent out with the wrong ID, etc. For your own portable use that is no problem, but you don't want to feed invalid data to public sites.

MikeTango commented 3 years ago

Nice, that should do the trick, i think i can send it to my own server and do the cleanup there with regex.

The default configuration in the decoder display is

timer=-1,-1,N timeaction=#,#,0

Do you mean the default display (1)? It's set to -1,-1, 20000 and i can not change that in the web config, am i having a stupid?

dl9rdz commented 3 years ago

No nice way in the web GUI, but you can access/modify via http://rdzsonde.local/edit.html?file=screens.txt Just make sure not to mess up anything, invalid content in the file will break things in a potentially fatal way, make flashing the TTGO necessary... see https://github.com/dl9rdz/rdz_ttgo_sonde/wiki/Advanced-display-configuration

The documentation says the timer is in milliseconds, not seconds, so (if my memory was wrong and the configuration right), instead of "5" in the example above you should use "5000"....

LukePrior commented 3 years ago
  • dump the resulting decoded frames via API or other means on the wifi.

You can now upload data to SondeHub with the latest version.

73-de-LZ commented 2 years ago

I thing it is the right thread to report a little bug in devel20220123 and not open a new issue. When in Config/OLED/TFT display configuration/No-RX-timeout in seconds = 33 or more seconds, scanning after loosing a signal is not restarted. If i put 32 or less, everything work as expected. When i use a TTGO in hunting mode in my car i would like to be set to 2 or more minutes, because it is handy to not stop manually on sonde of interest and when moving it is normal to loose the signal from time to time. I suppose it is something caused by the type of variable, maybe it is int and overflow at 32768 milliseconds, then minus is interpreted as -1 = stop scan forever . Anyway, not a major issue. Thanks for the great project!!!

dl9rdz commented 2 years ago

Indeed, got spot, thanks. Values are in fact stored in milliseconds in a 16bit int internal, which does not make that much sense. A fix will likely make it into one of the next updates.