Priority demod assignment #12
Conversation
rebase to python3 changes from ta6o
On branch py3-updates Changes to be committed: modified: apps/cursesgui.py modified: apps/ham2mon.py new file: apps/lockout-example.txt modified: apps/parser.py new file: apps/priority-example.txt modified: apps/scanner.py Modified detection of builtins functions for python2 and python3 (only tested on 3 so far). Modified priority and lockout file list parsing for python2 and python3 builtin filter function call. Added params for min_db and max_db as -N and -M respectively set from command line. Revised step size on spectrum min/max to 5, preference take it or leave it, may revise to a command line flag. Created example format file with simple entry set for priority and lockout files.
On branch py3-updates Changes to be committed: modified: README.md Revised description to include new min/max spectrum level switches and contributors.
Changes to be committed: modified: README.md Attribution for ta6o python3 fixes adopted in pull request
…ight in color (green if tuned, yellow if lockout). modified spectrum display characters used to visually separate under threshold (-), above threshold (*) and above maximum (+) as well as use colors blue, green, and red respectively. Committer: Andrew Farris <andrew@cirithungol.localdomain> On branch gui-devel Changes to be committed: modified: cursesgui.py modified: ham2mon.py modified: receiver.py modified: scanner.py
…rase instead of clear and call cursor set no cursor. Committer: Andrew Farris <lordmorgul@gmail.com> Changes to be committed: modified: cursesgui.py
… users, bold and dim white window titles, work to be done enumerating the colors better such as 'border_color' and 'text_color' where the color pairs are define so that would change in one location versus every call. Changes to be committed: modified: cursesgui.py
Added min/max frequency calculation to estimate the bandwidth covered by current sample rate and center frequency. Added display for min/max to receiver window. Adjusted alignment in receiver window. Separated lockout and priority file display to two lines in receiver window. Added framework for log file display but currently commented out. Log framework will initially text file note of channel active at time with a min time interval of logging. BUG remaining on Fedora 32 Python 3.8.6 there are randomly printed zeros showing up around the screen, has not been fixed by attempting to move cursor to fixed location after window draw and cannot isolate source of the zeros printed. Seems to print in spectrum and channel windows most but can appear in border, maybe lockout, not sure ever seen in receiver window. On branch gui-devel Changes to be committed: modified: cursesgui.py modified: ham2mon.py modified: receiver.py modified: scanner.py
… (long running demod fix) and kibihrchak (logger)
Changes to be committed: modified: apps/cursesgui.py modified: apps/ham2mon.py modified: apps/parser.py modified: apps/scanner.py
…ve channel logging timeout to not flood log file, apparnetly still too frequency so needs fixed, does log active channels as well as demodulators turned on and off Changes to be committed: modified: ../README.md modified: cursesgui.py modified: ham2mon.py modified: parser.py modified: scanner.py
…ctive channel outputs reduced to correct excessive active log entries, but still has excess entries for off channels (seems not only when demodulator is cleared but repeats Changes to be committed: new file: errors.py modified: ham2mon.py modified: scanner.py
…dd dB, timeout or channel indicator and the demodulator number that is turned on or off. Attempted fix of catch exception correctly for LogError. Changes to be committed: modified: ham2mon.py modified: scanner.py
…ter based on capabilities changes from john-, minimal testing, from john/gain_changes_and_long_xmit_kill branch with updates for python3, made killed demod resume set frequency so new file is created but assigned channel remains assigned and a demod on it
modified: receiver.py
modified: receiver.py
…d min file size with default 0, so setting min file size to 10000 will delete any demodulator output wav files that are less than 10k bytes in size when the demodulator is stopped. This may not take effect when ctrl-c is used to stop the program but should when "Q" is pressed since all demodulators are stopped in that case before shutdown. Changes to be committed: modified: ham2mon.py modified: parser.py modified: receiver.py modified: scanner.py
Changes to be committed: modified: ham2mon.py
…ction to display help Changes to be committed: modified: README.md modified: apps/parser.py
…old code, corrected missing parameter descriptions and test script outputs. On branch Gain-changes-and-long-xmit-kill Changes to be committed: modified: README.md modified: apps/cursesgui.py modified: apps/ham2mon.py modified: apps/parser.py modified: apps/receiver.py modified: apps/scanner.py
new file: ham2mon_processor_usage_2.png
Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services new file: priority-frs1 new file: priority-frs2 new file: priority-gmrs new file: priority-gmrsri new file: priority-uhf new file: priority-vhf new file: ../ham2mon_processor_usage_2.png
Multiple fixes for version updates gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.9.5.0 Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services Revised handling of /dev/null wave file sink by creating a null sink Revised error handling by adding OS and base catch blocks, commented out for testing in this comm
Added freq_low and freq_high tuner limits (in addition to max_freq and min_freq) limited by the sampling Added freq_low and freq_high to gui, command line switches, and demod setup Modified some logic on set frequency and wav filename, separated out function for set_file_name from set_center_freq General cleanup of some comments and code organization, removed last_center member from BaseTuner as never used modified: cursesgui.py modified: ham2mon.py modified: parser.py modified: receiver.py modified: scanner.py
modified: ../README.md
…y to calculate desired low and high freq tuning bounds with given low_freq and high_freq Fixed error in Scanner test code from old gain code upgrades Edited ham2mon to add new param Fixed logic of removing channels that are below low_bound and above high_bound modified: ham2mon.py modified: scanner.py
…ls only, calling channels only in vhf for 2m and uhf for 70cm examples
Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services new file: priority-frs1 new file: priority-frs2 new file: priority-gmrs new file: priority-gmrsri new file: priority-uhf new file: priority-vhf new file: ../ham2mon_processor_usage_2.png
Multiple fixes for version updates gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.9.5.0 Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services Revised handling of /dev/null wave file sink by creating a null sink Revised error handling by adding OS and base catch blocks, commented out for testing in this comm
Added freq_low and freq_high tuner limits (in addition to max_freq and min_freq) limited by the sampling Added freq_low and freq_high to gui, command line switches, and demod setup Modified some logic on set frequency and wav filename, separated out function for set_file_name from set_center_freq General cleanup of some comments and code organization, removed last_center member from BaseTuner as never used modified: cursesgui.py modified: ham2mon.py modified: parser.py modified: receiver.py modified: scanner.py
modified: ../README.md
…y to calculate desired low and high freq tuning bounds with given low_freq and high_freq Fixed error in Scanner test code from old gain code upgrades Edited ham2mon to add new param Fixed logic of removing channels that are below low_bound and above high_bound modified: ham2mon.py modified: scanner.py
…ls only, calling channels only in vhf for 2m and uhf for 70cm examples
Fixed error in Scanner test code from old gain code upgrades Added center_freq to constructor params for Scanner to provide ability to calculate desired low and high freq tuning bounds with given low_freq and high_freq Fixed logic of removing channels that are below low_bound and above high_bound Added freq_low and freq_high tuner limits (in addition to max_freq and min_freq) limited by the sampling Added freq_low and freq_high to gui, command line switches, and demod setup Modified some logic on set frequency and wav filename, separated out function for set_file_name from set_center_freq General cleanup of some comments and code organization, removed last_center member from BaseTuner as never used Multiple fixes for version updates gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.9.5.0 Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services Revised handling of /dev/null wave file sink by creating a null sink Revised error handling by adding OS and base catch blocks, commented out for testing in this comm Added priority example files for FRS and GMRS, amatuer 2m and 70cm radio services Updated change log history including miweber67 contribution manually captured
remove unused code
… few remaining bugs (currently crashes with a list access error, but saving work done) modified: receiver.py modified: scanner.py
:w Changes to be committed: modified: ham2mon.py modified: receiver.py modified: scanner.py
|
I spot checked this pull and a lot of the changes are already in my my master branch. Do you know how we can have a pull request that is just the priority demod assignment? I guess my concern is that if I just merge this than it will revert code that needs to stay the same. I will also try to figure out how to make this work a little smoother because when I originally merged your master branch it was a lot of manual work I would like to avoid doing again. Update: I seems like the priority handling has been in your master branch since before I did the merge of your code into my master branch. If this is true than I must have skipped over it when I did my merge. Although I find it surprising I did this I have done stranger things :) |
|
Based on the priority demod assignment code being in your master branch for quite a while I don't see how to make this merge be any easier. I will take a look at merging it over the next few days. |
|
I am obviously struggling with priorities myself hah. I did this pull to test the water, I suspected it would be hard to isolate, and if I had been more deliberate with commits could cherry pick. But as is I think it is a manual merge. I planned to do it since familiar with what is meant to be there but may not be able to this week. |
|
I will make an attempt at the merge and report back later this week. |
|
In the pull request and my try to create a new one there is something odd: It looks like the code being compared to is not my github master. For example, in the README.md changes it has this: However, the master version already has these lines correct. It looks like it is comparing to the upstream Any idea why? |
|
I think I have the merge of this pull request complete (currently in a separate branch). It seems like the priority option is working but not fully sure of the expected results. The screen shot seems to show a priority channel in the channel list that is not being actively tuned. However, when I run the merge and your master it does not operate this way. I may need some assistance confirming things work or something explaining how it is supposed to work. |
|
I see an issue with the priority demodulation assignment code as it exists in your repository. The code as I merged it was not doing what I expected so looked at your repo before and after the addition of this enhancement. With a test file your master branch generates thousands of audio files when it should only generated 30 or so. Your master branch before the enhancement works as expected (mostly). Here is the approach I used to generate a test IQ file and to replay it in ham2mon: I can provide more details if needed. |
|
Thanks for pointing this out, I just verified it doing the same and had not seen that in what I had in the separate branch. Sorry that I missed that. |
|
Thanks for confirming and offering to assist. Before you do anything I think I may have a different approach to handle this enhancement. This is the correct use case, right: If so I have something that seems to work but is much different than your branch. After I do some more testing maybe you can look at this to see if it addresses it? If this is not a good path we can look at the small file problem. |
|
Note that for Use Case 3 having priority assigned from file is one reason to assign demod, next reason would be select the strongest signal in instantaneous bandwidth. The reason for one of the many frequency lists getting added was to add a prioritized list by power using the amplitude in spectrum to set power associated with each channel during scanner loop. So not demod could be set by 1) in priority list, 2) highest power. |
Correct me if I am wrong but these are two separate things:
Priority from file is in the branch listed in this issue: https://github.com/john-/ham2mon/issues/11 If you can check how this approach works and put comments there that would be great. Note: I do have a branch that builds off this which puts the letter "P" after those CHANNELS that were priority scanned. This helps visualize what it is doing. This branch is documented here: https://github.com/john-/ham2mon/issues/16 For priority based on channel strength we can create a separate enhancement. If you agree create the ticket otherwise let me know and I will do it. |
2 participants
Requires manually working merge into a new branch