F+4 / F+* again :(

[ea7hjb]

Hello, I found some weird things on these two functions again. I understand they must be becoming PITA already, so do what you can, when you want, of course, but I think these are one of the few most valuable characteristics the QS has: the frequency hunter, so, having them running fine is pure gold.

1) If ENABLE_CODE_SCAN_TIMEOUT=0/1 and ENABLE_FREQ_CODE_SCAN_TIMEOUT=1 and using F+4, if timeout is reached and CODE is NOT found, only option offered is "* repeat", no "M save". And even pressing M it doesn't work. 2) Anyhow, if cycle completes, after pressing "M" to save it always offer to save on Memory Channel number 1, even if in VFO mode.

Two more things: Menu and F+4/F+* are calling "CDCSS" what I think it should be called "DCS"?

And if ENABLE_PWRON_PASSWORD = 1 on Makefile, there is a compile error:

app/uart.c: In function 'cmd_051D': app/uart.c:355:78: error: 'cmd_051D_t' has no member named 'bAllowPassword'; did you mean 'allow_password'? 355 | if ((Offset < 0x0E98 || Offset >= 0x0EA0) || !g_password_locked || pCmd->bAllowPassword) | ^~~~~~ | allow_password app/uart.c:356:38: error: 'cmd_051D_t' has no member named 'Data' 356 | EEPROM_WriteBuffer(Offset, &pCmd->Data[i write_size]); | ^~ app/uart.c:339:18: error: unused variable 'data' [-Werror=unused-variable] 339 | const uint8_t data = (uint8_t *)&pCmd + sizeof(cmd_051D_t); // point to the RX'ed data to write to eeprom | ^~~~ cc1.exe: all warnings being treated as errors make: *** [app/uart.o] Error 1

Thank you for your time, as always.

[OneOfEleven]

Sorry about that, I got side tracked with updating the aircopy functions.

I've gone all through the freq/ctcss/cdcss search code, I think I've fixed all the problems, seems to work well now.

Let me know if you spot anything that doesn't seem quite right or could simply be improved. You are right, it is a key part of what the radios can be made to do.

Leave this issue open if you can until we're sure it's as good as it can, otherwise I'll forget what needs doing. Comes with age ;)

[OneOfEleven]

The rounding up of RF frequency to the nearest step size needs redoing.

[ea7hjb]

Hello, thank you for your time, I will test it right away.

Regarding the rounding... it is really necessary such effort? I mean, when you pass the "hunted" frequency to the VFO/memory, it gets rounded to the nearest on the current step size.

[ea7hjb]

Just tested and seems to work fine. The ENABLE_CODE_SEARCH_TIMEOUT=0 only affects to the F+* and not the F+4 (which I think is perfect and makes sense! don't touch it! :P), but I think it could be of help to specify it a bit more in the Readme.md. Some people were asking about it in the ES QS Telegram group because they didn't understand well the two different timeouts.

Weirdly enough, when using the F+4, if you transmit until the FREQ is found, and quickly release the PTT before CODE appears on screen, the code is also found but not shown, then when pressing "M" to save, the tone is shown on screen (so the QS found it, uh? bad boy!), but, it will not be saved. It's like he is not sure hahaha. I'm only telling you this as of curiosity, so we can understand how these things works, but for me (and I think most of the people) the F+4/F+* is perfect right now, and not needed to be touched anymore.

Btw, the compile error when ENABLE_PWRON_PASSWORD = 1 still there, Just for your information. Seems like a variable has been renamed.

Thank you!

P.D.: Test was done with bc416c7. Didn't see your new one! P.D. 2: Tested new 7f7c949 and things seems to continue fine :)

[OneOfEleven]

That's a bug I've just fixed, the part where it doesn't really find a code but shows a random one when you go to save the result.

[OneOfEleven]

Regarding the rounding... it is really necessary such effort? I mean, when you pass the "hunted" frequency to the VFO/memory, it gets rounded to the nearest on the current step size.

No it wasn't rounding properly, it was using an incorrect step size to round too. but now it should round to the proper step size, the step size that's set for the actual RF band and VFO (upper/lower) that the detected frequency was found in (not the one your VFO is previously set too).

[ea7hjb]

That's a bug I've just fixed, the part where it doesn't really find a code but shows a random one when you go to save the result.

Curiously, out of the many test I ran, it always ramdonly not-found the right code haha. How weird this thing is...

Well, this function is working like a charm now. What else can we ask? perhaps using the limited FSK capability of the Quansheng to be able to hunt digital transmissions? DMR/NXDN 4FSK? Erm... ok ok, I will wake up already :D

Thank you again for your time and attention.

[OneOfEleven]

Well, FSK4 it can't do, so that's DMR, fusion etc it can't do.

But what it can do is AX.25, it can act as a node, a terminal etc, but that's another time.