Squelch value now goes from -90 to +20 and it's directly compared against the max_db parameter returned from each freq scanned by the radio subsystem, with no adjusts or manipulation (you adjust the number as will be used).
Less squelch means weaker signals will trigger it. (as expected).
There was a tiny cosmetic bug when you deleted a frequency from the scanning memory: The description was not erased from screen and you could see it while the scan did not resume.
There was another bug on the pause button: If you asked for another manual scan range when paused, the button kept the text "RESUME" (its text was not reset to "PAUSE" again).
Added buttons for:
Change scanning direction (ascending / descending)
Saving current freq into the SCANNER.TXT file
(Please notice that, on the other hand -for safety issues- the DEL FQ button, deletes the frequency only from the temp memory on the actual scanning session, but does NOT erases the freq. inside the SCANNER.TXT)
Also there are other bug fixes and scanning speed enhancements.
MIC TX button :Shortcut for jumping into TX -> MIC app.
FREQ DEL button: Deletes currently displayed frequency from temporary scanning memory. Ideal to get rid of those not wanted "noisy" freqs in the middle of a range scan.
Also, some code optimizations thrown in.
I changed width in pixels of the "fine-tune cursor" from 2 to 5 , and then re-centered the cursor, from 120 to 118 to accomodate the shift in width.
I was inspired by this old ISSUE on Havoc's repository, where at the end @furrtek commented the need to make the red tick bigger in the future (but forgot / was swamped with other ehnancements / issues):
https://github.com/furrtek/portapack-havoc/issues/172
When scanner finds a freq with high dbi, it locks into it "listening" a bit more (less than a second) for either confirm or discard it as an actual high dbi or just a spurious thing.
The big number frequency changes color accordingly: Grey = just scanning, yellow = locking in, Green = Found something, allowing the user to listen.
New ui_scanner, inspired on AlainD's (alain00091) PR: https://github.com/eried/portapack-mayhem/pull/80
It includes the following:
1) A big frequency numbers display.
2) A Manual scan section (you can input a frequency range (START / END), choose a STEP value from an available of standard frequency intervals, and press SCAN button.
3) An AM / WFM / NFM scan mode selector, changing "on the fly".
4) A PAUSE / RESUME button, which will make the scanner to stop upon you listening something of interest
5) AUDIO APP button, a quick shortcut into the analog audio visualizing / recording app, with the mode, frequency, amp, LNA, VGA settings already in tune with the scanner.
6) Two enums are added to freqman.hpp, reserved for compatibility with AlainD's proposed freqman's app and / or further enhancement. More on this topic:
ORIGINAL scanner just used one frequency step, when creating scanning frequency ranges, which was unacceptable. AlainD enhanced freqman in order to pass different steppings along with ranges. This seems an excellent idea, and I preserved that aspect on my current implementation of thisscanner, while adding those enums into the freqman just to keep the door open for AlainD's freqman in the future.
7) I did eliminate the extra blank spaces added by function to_string_short_freq() which created unnecessary spacing in every app where there is need for a SHORT string, from a frequency number. (SHORT!, no extra spaces!!)
8) I also maintained AlainD idea of capping the number of frequencies which are dynamically created for each range and stored inside a memory based db. While AlainD capped the number into 400 frequencies, I was able to up that value a bit more, into 500.
Cheers!
As shown in https://github.com/eried/portapack-mayhem/issues/88 ...
Tiny bug but probably responsible for badly forming datetime in several apps, as it is used in ACARS, POCSAG and ADSB_TX (and of course AIS RX)
Lowered the scale -10 ºC so it accomodates less than zero temperatures, present sometimes when cold starting the system.
Added 1 char for temperature label length.
Adjusted the max2837 sensor value -> ºC temp result, by normalizing the conversion to correctly display the standard 25ºC, mentioned in Datasheet.
