Add dongle id to metadata
gdt opened this issue · comments
In trying to understand reception issues, I am looking at a json pulled from MQTT which comes from two dongles, which are on two computers in two places. I of course don't think that's odd. Basically I want an id in the message that tells me which dongle it is from. I am ok with it being on me to assign ids uniquely, and of course I'm doing that already -- that's how I keep track of notes about behavior, and which one needs which frequency calibration. But I want to be able to graph signal levels from the basement dongle vs those from the 1st floor dongle separately; I have two on one freq where I need it to hear everything.
So I'd like to add in a device key-value entry, which has what's in the -d arg. (Perhaps somebody later would make a -doutput arg that gives a value for the key, separately, so that same-text-different-device args can be separated.) FWIW, I have -d values like :00001001, which are not 1, but otherwise just serial numbers.
I personally don't see a reason not to include metadata, and would also like to see a -M all, but that's a separable issue beyond the scope of this one. So I guess it's -M device.
Before I think about writing code, is that agreeable? If not, any suggestions for how downstream processing can know which dongle was the receiver.
Or is this what -K is for? It does seem to work, at the expense of duplicating, but that's easier than writing code.
Yes, tagging records with additional data is what -K is for. Using -K device=00001001 should work. Or automation like
-K device=$(rtl_eeprom 2>&1 |grep Serial.number: |cut -c 17-)
The automation won't work because of multiple dongles, but I already have it all scripted so adding -K is easy. I guess when I use manual gain I should put that in as well. (It's on my list to run with varying gains and see what that does to the signal/noise levels.)
I'm going to call using -K good enough for me to not want to either push on this or write code (even though it's a little aesthetically displeasing compared to actually logging what I think is useful metadata).
We have the general structure available to change the SDR connection through the HTTP-API. A Template (like FILE and PATH currently) to expand to the current SDR info might be useful. Not sure which fields from the SDR though.
Interesting, so maybe this should stay open.
In general, I find -M foo awkward, compared to just asking for metadata and getting it all. I can't really make a case for someone caring about some and being upset at the rest.