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.
It reads the antennas definition from a txt file:
WHIPCALC/ANTENNAS.TXT
Inside the textfile you place each antenna you own with the following sintaxis:
<antenna label> <elements length in mm, separated by a space>
For example:
ANT500 185 315 450 586 724 862
Input the required frequency, adjust the wave type (full / half / quarter, etc.) and the calculator will return the antenna length (metric and imperial) while also calculating how much you need to expand the fitting antennas you got defined on the txt.
It may return up to 8 matching antennas, which is more than enough (normally you will have 2, perhaps 3 telescopic antennas around for your portapack)
If by any chance your antennas txt got more than 8 antennas, and more than 8 matches the length of the freq / wave you want, it will only show the first 8 matching antennas and will warn you at the bottom that there are even more results (hidden).
All calculations now are rounded into the best integer, considering first decimal, so precision is double than the original antenna calculator app.
