Questions on channel_log function

[john-]

There is currently an option to log active channels to a text file (Channel Detection Log File in README).

Some questions:

• One of the fields is hard coded to be "0". What is the intent of this?
• How is this log file being used by people?
  • I ask because the file format seems a little unwieldy (fixed field length vs CSV, JSON, YAML, etc
• Any reason why the code is in Scanner and not Receiver?
• Anyone using this feature?

[lordmorgul]

I do use the log but have had not much time spent doing what I intended with it. That code was one of my older adds I think came in with your first capture of my Master. It was a quick hack for me to explore what was needed and got deprioritized.

The goal was to extract data from it like the most frequently used repeaters nearby and what times of day they are active. Moving to a database instead of the file was an expected step I did not get to.

One of the more appealing databases would be InfluxDB because it is naturally time-series data that would plot nicely with Grafana. Any local file database would also work.

An issue with the log was that small variations of frequency center for the demodulator made it questionable which frequency was really in use where dense repeaters exist. I needed to also have the CTCSS tone detection working to detect and log the output tone and use that to help differentiate them.

[lordmorgul]

I will have to look again as to why it was in scanner. The intent was to log discussion timelines more than individual signals heard and not spam a log full of noise blips. The classification of signal type might greatly help reduce that issue and only log the right classified signals.

[john-]

Thanks for the information.

I do use the log but have had not much time spent doing what I intended with it. That code was one of my older adds I think came in with your first capture of my Master. It was a quick hack for me to explore what was needed and got deprioritized.

Having a log makes a lot of sense. I do this now outside of ham2mon (via parsing of recorded file names). That said I see the value in having ham2mon generate the log directly into text file and/or DB.

The goal was to extract data from it like the most frequently used repeaters nearby and what times of day they are active. Moving to a database instead of the file was an expected step I did not get to.

I see the hook for DB which makes sense.

One of the more appealing databases would be InfluxDB because it is naturally time-series data that would plot nicely with Grafana. Any local file database would also work.

Makes sense. Previously I have worked with PostgreSQL and a time series add-on but have no strong opinion. Having the place to hook in the alternate path works for me.

An issue with the log was that small variations of frequency center for the demodulator made it questionable which frequency was really in use where dense repeaters exist. I needed to also have the CTCSS tone detection working to detect and log the output tone and use that to help differentiate them.

I haven't dealt with any of that so thanks for the insight.

I will have to look again as to why it was in scanner. The intent was to log discussion timelines more than individual signals heard and not spam a log full of noise blips.

I want to prepare for doing the scans of frequency ranges beyond the bandwidth of the hardware.

I noticed that that the call to log the channel was 1) at the time of assigning a frequency to a demodulator, 2) stopping a demodulator, or 3) for active demodulators.

The classification of signal type might greatly help reduce that issue and only log the right classified signals.

I have no experience with CTCSS so let me know how these things relate if at all.

Based on one these things and how I interpret your response I was thinking of refactoring the code while recreating the existing functionality. Caveat: is it seems like there may be relevant events missed by the current code (not sure about this yet).

Also, I do want to work further with asyncio. It might not be a big benefit here but want to learn it for features to larger frequency ranges :)

[lordmorgul]

The call at assignment of demod was to log when channel became active. The call when un-assigning demod was to indicate no longer active (this could have both been done by setting a callback timer and waiting for the deactivate and then log start and duration, or start and end, with one log call. Writing to the IO twice was just simpler way to start.
The call at the active was more like debugging code than feature and was used to dump to the log what channels are active at the same time. This is basically overlap functionality and not needed. At the time of writing that I did not trust the priority to be working (which it wasnt), and the idea was I could catch all active at once and review for whether it was catching the intended priority signals.

[lordmorgul]

The hard coded zero was placeholder for using gain_db, the next column was threshold_db. The idea there was leaving a hint as to how strong the signal was but this isnt the best way. The peak amplitude of the demodulator is changing during the activity and the voice modulation so it would be a bit intensive to save off a max amplitude metadata during the demodulator being active. That would be another thing happening for every demodulator for every cycle of scanner loop.
So I just used threshold but that is meaningless since it should never assign the demod if signal is not above threshold.