scan disabled in v2.28

[reppr]

What was the problem with the scan?
I see the commit 'Disable Scan & BLE'

Looking forward to see it back again
Guess you will make it even better...

Thanks in advance

[Hamberthm]

What was the problem with the scan? I see the commit 'Disable Scan & BLE'

Looking forward to see it back again Guess you will make it even better...

Thanks in advance

Hi! In the meanwhile, maybe you want to try the fork I maintain with Scan and two mods added by me: Fast Autoscan in visible range and seamless mode, check here.

[reppr]

Thank you for your reaction on my question.
The reason I ask is not that I would want the scan enabled as soon as possible, but I would like to know what the plans are.

I am writing my own UI, mainly based on touch morse input and can still call scanning by tapping 'S'.
The code is still there, just does not appear in the Menu using the rotary switch or the serial 'Remote' interface.

[max-arnold]

What was the problem with the scan?

There are no problems with the scan feature per se, it just needs more work. The main thing I want to change is how it is visualised, so it works in both UI Layouts. I'd also like to take a look at what Humberto did in his fork for seamless scanning.

And finally, summer is short here in Siberia, I do not want to spend it in front of my computer. I'd like to take a break :)

[reppr]

Thanks a lot for your reply. That's the type of information I was asking for.
Yes, and enjoy your summer, the computer can wait a bit ;)

[Cormel980]

Look at the implementation of -ETM- in the firmware http://www.hjberndt.de/dvb/pocketSI4735DualCoreDecoder.html
I evaluate it in relation to FM, it looks great, it is convenient to use. The concept itself repeats the implementation in Tecsun-pl330, only there it is remembered. On FM, the levels do not change much over time.

In vain do not output rssi and s/n, because of this it is difficult to improve the reception location by moving the receiver.

[reppr]

@Hamberthm I played around with your fork a bit and think it is an interesting concept. I need more time to study it, because I run into some problems which I want to check again. Some of it was probably caused by me: accidentally I did not erase the flash and might have messed it up before by experimenting with my own code... will erase it next time. I have seen the following symptoms: Strange step sizes. The scan starting when I did not want and did not expect it. The button becoming unresponsive. The screen going completely off. I will have to take a closer look in the next days. I think in the end it would be best to have only one scan entry in one place of the menu. It would then lead to the selection of the desired scan type, which can change depending the situation. I think In my short test I might have activated both (your versions and the existing one) at the same time...

[Hamberthm]

Hi! That's strange, I don't experience any of those issues. Have you compiled the code on you own? Or used the binary flasher I posted?

[reppr]

I used arduino-cli
~/bin/arduino-cli compile -v --clean -e -p /dev/ttyACM0 -u ats-mini

[Hamberthm]

Mm I'm not familiar with that, I use Arduino IDE. Anyway it could very well be the settings, do a flash erase before programming. The settings are stored differently than the official release due to the addition of the two new entries for Fast Autoscan, so there could be conflicts and memory corruption. Also, try the binary flasher already precompiled by me: https://github.com/Hamberthm/ats-mini/releases/tag/v0.2

[reppr]

It does not compile in the Arduino IDE on my system, the arduino-cli works fine. Your flasher is not programmed for Linux, I do not have Windows here.

I recompiled it again and it worked a bit better then the first time. I still had thouse huge step sizes (like 50k on shortwave) seen before and after a few minutes the screen went completely off, so I wanted to erase the flash first. To my big surprise nothing worked, the receiver always rebooted a few seconds after switching it on, long before the screen even went on.

I could flash different software versions, they all uploaded well, but the boot loop showed up with every firmware I tried. So I was sure it was a hardware problem, but I was wrong...

I finally found a way to erase the flash using esptool and could load and run my own or the original firmware version again without problems. After erasing the flash once more I tried your version and it worked well now. Yes, I got many false positives, but they were probably induced by the serial connection, so I did not care about that for a first test. The other problems did not show up again.

There is one thing that annoyed me: If i found something I wanted to listen to, more often then not the autoscan interrupted my reception after a couple of seconds. This happened also when searching the menus and the like, autoscan should not interrupt and block these functions.

In my usage pattern the old scan implementation is worth keeping in the software, in other cases your approach will be better.
I do not speak yet about fine tuning levels, steps, speed or appearance, more about the algorithm when to do the scan.
All three scan types do work now, but need some fine tuning.

[max-arnold]

The Scan feature was released in 2.30 https://github.com/esp32-si4732/ats-mini/releases/tag/v2.30