The underlying function used for calculating Latitude and Longitude -also used in other places inside the radiosonde app- was returning a positive value always.
But it needs to cope with negative values also (i.e. Lat and Lon)
Fixed by just changing the returning value into int32_t (even if the calculation is done in uint32_t, the actual sign is passed thru when returning the calculated value -those are the same 4 bytes, interpreted either as (before) unsigned or (now) signed)
I think the Jammer deserves a green icon, since it actually does it job pretty well.
Then there is a Jitter parameter. It allows to introduce a jitter from 1/60th of a second up to 60/60th of a second (a full one). It will delay / move forward either the TX or the cooldown period for a maximum of a half of the time you choose as jitter.
Meaning: If I choose 60/60th, a full second of jitter, it will produce a random number from 1 to 60.
Then it will calculate jitter = 30 - randomnumber
THen it will "add" that (positive or negative) time to the time counter for the next jitter change of state.
Discord User jteich did some investigation (Thanks!) and helped me understanding this rather obscure parameter:
Internally, is called "TRIGGER", and is passed into the baseband when configuring the desired spectrum sample rate.
Please forgive me in advance if this explanation is not 100% correct. It's only my interpretation, based on my own observation and jteich's comments over Discord chat.
This trigger parameter apparently determines the amount of data over time used for calculating the signal's power inside each specttrum's bin, before considering it "done".
In short, if you lower this resolution value then the cascade will tend to be rendered a bit faster, while kind of blind to tiny signals.
On the other hand, a bigger value will help rendering and distinguishing different signals on the cascade.
Too big a value can easily clutter up the cascade. But then it may be a "blessing" when inspecting higher freuqencies -where hackrf is more deaf"
The default value of 32 is quite decent. But then, now you can experiment with it. Cheers
Added a PRESETS.TXT file (inside /LOOKINGGLASS folder).
Also optimized the way the spectrum signal is integrated into the cascade.
Added provision for ranges lower than 240MHz but I am afraid that at this time it will not be advisable to lower ranges any more than 240MHz, since some artifacts and frequency running - moving out of place- occurs.
I can only hope that someone with a better understanding of hackrf's inner code can fix this issue and perhaps enhance the scanning speed.
I found some "original commenting" inside the code:
// TODO: Move more low-level radio control stuff to M4. It'll enable tighter
// synchronization for things like wideband (sweeping) spectrum analysis, and
// protocols that need quick RX/TX turn-around.
Which makes me think that there are things "missing" from the portapack side of the code, for allowing serious speed sweeping. So I am concluding that with current "portapack framework" this might be "the best possible thing".
It is to be noted that the "new" internal sweep mode code is signed by:
* Copyright 2016 Mike Walters, Dominic Spill
*
* This file is part of HackRF.
Maybe Mike or Dominic can be contacted and hopefully lend a hand on enhancing this code.
- Now we have variable CLKOUT.
- CLKOUT can be set between 10kHz and 60MHz.
(The output signal will become mostly sine shape when reaching 50MHz.)
- Click on freq setting field to change tuning step.
Added a nicer MARKER (thanks to XSX(H1) contributor for the suggestion)
Fixed a bug that made the screen scroll from top, when using a popup "window" and returning (like, when pressing the DC VOLTAGE enable / disable" button on top bar) THanks to GregoryFenton for the testing and bug spotting!
Capable of showing a cascade with full bandwidth scan. You can select Min and Max Mhz for the cascade.
You can move a marker so to (aproximately) know a particular frequency on the cascade. If you press the select button, the app will jump into the RX -> AUDIO app, already tuned into the just "marked" frequency.
This first version SURELY has space for lots of optimizations and improvement in general.
Several old bugs squashed.
On the APRS side, most notably, SSID numbers where shifted left twice, instead of once, and bits 5,6 where not properly set.
On AX.25 side, the bit stuffing part of the encoder was not placing the zero bit on the right place.
Finally, I changed APRS icon from ORANGE to GREEN, since even this may be a simple app, now it's doing its work as intended.
Values where left bit-shifted upon being entered by the user, so resulting SSID being transmitted was a different number. This shifting was happening both on Source and Destination SSID values.
* No device freeze when you try to close app while it's transmitting
* Bypassed 100 .wav files limit by implementing paging functionality
* Removed useless progressbar and implemented page info line instead
Moved the MIC TX RX into the main menu.
Changed scanner color from yellow to green, since it is kind of rounded up into an acceptable functionality.
Also, did a bit of cleanup on the code spacing inside the menues.
Also added the fields "DateTime" which just shows the raw timestamp that portapack assigned the last packet received, in the format: YYYYMMDDHHMMSS ... And "Frame" which shows the packet # (or frame) for correlating with other software / verify that there are new packets being received.
Also moved a string function for returning rounded-up decimals, originally inside the whipcalc tool app, into the string_format functions library, because I used that function on TEMP and HUMIDITY values inisde the radiosonde app.
Finally, the whole UI has its widgets moved a bit, giving space for these new parameters.
Thanks @euquiq for a more common solution to the bug.
Added RX gain control.
Now we have full gain controls!
Merged PTT and Voice activation into one option selector.(allowing RIGHT BUTTON to work with PTT off)
This patch addresses the issue detected in: https://github.com/eried/portapack-mayhem/issues/159
This patch will revert the behavior of the function to_string_short_freq
into using spaces on the left of the integer part of the frequency (as it did originally).
When upgrading the scanner app, I did change the behavior of this function eliminating those spaces, so I could gain some characters-worth of space inside the scanner, but I failed to detect that it introduced some lack of padding on the rx->audio app.
Now, it is back as before, and I also did update the scanner so it can cope with the "extra spaces" this function now adds (again).
A bug that enabling audio RX resets the TX gain (perhaps because that changing to receiving mode modifies some registers) inspired me to add this gain control.
Commented out some steps which don't require for the VU meter to work again.
Moved some widgets for gain control.
Added CRC calculation for Vaisala radiosondes.
Added a Checkbox on APP for turning ON / OFF CRC. When CRC on, malformed packets are ignored.
Connected existing CRC function for METEOMAN sondes, using the same "CRC" checkbox logic.
Added the Vaisala RS41 data packet decoding.
Changed the default freq from 402.0 to 402.7 Mhz, since it is more popular freq.
Lowered the frequency stepping, so it is easier to fine-tune the exact freq center, if needed.
Sonde's Serial ID is passed into the VIEW MAP, so now the sonde is labelled on the map.
Earlier code did not start with squelch totally open, but a tiny bit closed. (now at app loading, squelch is truly set up with the same value it shows on screen).
I also hardcoded the NFM sampling rate and baseband bandwidth. It seemed "the right thing to do".
You can enable RX and adjust VOLUME and SQUELCH into your liking.
Sadly enough, you will NOT be able to use VOICE ACTIVATION when RX is enabled (to ensure there will be NO audio feedback defeating the VA sensing)
A "bug" that won over me, but perhaps and hopefully other coder can easily fix: The Vumeter will momentarily "dissappear" when enabling RX. But it will reappear as soon as you start TX. Or when you turn off RX.
I enabled the PEAK LEVEL MARK on the Vumeter, so you can easily see in which level your input voice / signal is peaking and regulate the MIC gain accordingly in an easier / more robust way.
Side enhancement: Took off the dark green, yellow and red coloring from the vumeter when no signal is present, and replaced it with dark_grey. I know that some coloring is "eye-candy" but the vu-meter is more readable with this new contrast.
