update priority channel approach

john- / ham2mon

GNU Radio based SDR scanner for narrow band FM demodulation

GNU General Public License v3.0

2 stars 0 forks source link

update priority channel approach #11

Open lordmorgul opened 9 months ago

lordmorgul commented 9 months ago

Capture updated priority channel code from lordmorgul fork master branch

I will work transferring the updated channel priority approach from my fork master branch. It has been tested for a couple weeks and seems ready to bring into a new branch here and test. It lets fewer demodulators run simultaneously to have several priority channels, as long as the channels are not frequently all in use.

lordmorgul commented 7 months ago

@john- seems I failed to accept the collab invite, thought I did that but it was still showing and too old. Please redo that.

lordmorgul commented 7 months ago

lordmorgul/ham2mon - priority demod assignment commit here to be manually pulled https://github.com/lordmorgul/ham2mon/commit/a059c00fa6deadb62abbf3b110f4b968d10a6e5b

john- commented 6 months ago

Per comments in the pull request for this feature I took a look at an alternate approach for this enhancement. I think I got the idea behind it and it is documented as a use case in the README.

https://github.com/john-/ham2mon/tree/priority_handling_alternate_squashed

I tested the following scenarios:

master branch, feature branch with no priority file, and feature branch with priority file (2 entries)
one demodulator vs three demodulators
with and without audio classification

I did not test with sound through speakers only with recording.

Of course, more testing is required and confirmation that it at least minimally addresses the requirement.

john- commented 6 months ago

This is now part of the master branch. Closing ticket.

lordmorgul commented 6 months ago

Sounds good, I will get this and test live listening to a repeater thru speakers.

john- commented 6 months ago

Sounds good.

The master branch includes a bunch of other changes as well. If there are problems it should be possible to go to previous commits to better isolate things.

lordmorgul commented 6 months ago

Testing Master today there is an issue with "tmp" directory not being included in git so new deployment does mot have it. Soon as a signal is classified as voice program crashes when tmp is not found. Creating tmp locally fixed it.

Channel priority seems to be working for Case 3 priority listening. Will keep doing more testing.

john- commented 6 months ago

Thanks for the feedback.

I will look at the tmp dir issue. What is odd is that the code removes the directory on exit so there is code to create it if it does not exist. Clearly there is something weird going on.

john- commented 6 months ago

This code hasn't changed in a while but maybe this line is failing for some reason: https://github.com/john-/ham2mon/blob/74fececd1d36758735db544e0c51b03660a7c626/apps/receiver.py#L461

john- commented 6 months ago

I did a clean git pull and master branch. I ran ham2mon with audio classification and it did not error out due to missing wav/tmp directory. I reopened this issue. Can you reproduce it? If so maybe we need some debugging code to figure it out.

lordmorgul commented 6 months ago

For my crashes it was creating the directory in 'apps/tmp' instead of 'apps/wav/tmp' that made it stop crashing. The code attempts to always work in 'apps/wav/tmp' first then move to 'apps/wav' so I'm not sure why that error came up trying to write to the higher tmp.

john- commented 6 months ago

Yeah that is odd. Maybe just watch it for now.

At some point we should move the file writing to the newer pathlib. That should clean up the code in this area. I also want to get rid of the .replace calls which bother me.