Dear @ABG, (and @TIMAI2),
thanks a lot for your suggestions. This is a good idea, and I didn't think on it, before. I will take a look on that also.
As a matter of fact I'm still continuing the investigation (the problem is still present) and I was thinking about a "timing" problem.
Just a few words to explain a bit more what is the "strange behaviour" that I'm facing with.
My app is intended to manage the endurance races (i.e. rallies) done with an ancient car (Lancia Fulvia 1.3 HF dated 1967) owned by a friend of mine.
We have put two Hall sensors of the rear wheels of the car and with a couple of Arduino boards, a Nano to interface the Hall sensors, in order to be capable to get the Hall inputs in real time, without nothing else to do, and an ESP32 to send the pulses via BT to the app running on a Lenovo pad (8" display/Android 9).
We have used two Arduino boards because the Hall sensors are analogue ones, so the Nano (like a Schmitt trigger) acquires the voltages generated by the Halls, then squares them to generate a true pulse, The Nano is linked to the ESP32 by two wires, in order to rise two interrupts to the ESP32 on the falling edge of the pulses. The ESP32 counts the pulses (interrupts) and sends the counts to the app via BT every 500 ms (together with some status bits; in total, less than 20 bytes).
In parallel we have also enabled the GPS of the Lenovo pad so to have two different sources for both speed and distance. My app is then capable to work with each source singularly or both, depending on the settings that we write into a configuration file.
This has worked fine for many months, but recently (the Android updates are locked, in order to avoid any surprise) the behaviour has changed: while using only the GPS source, the algorithm works fine, but when I use only the Hall sensors, the same algorithms fails : the sequence (flow) of the overall app seems unpredictable.
The main difference between the two situations is that when I use only the GPS input, the 10 ms clock for polling the BT input is not enabled. In other words: when the Hall source is enabled, every 10 ms the clock fires and looks for incoming data from the BT (if no data is available the clock exits immediately).
Another difference is that when I use only the GPS, the data (position and speed) updating rate is slower: i.e. 1000 ms (1 s) and is generated by a different Clock block that is the "timer tick" of the app, always running.
What is troubling me is that everything has worked fine for months, but now not!!!
Obviously I don't believe in ghosts, so most probably there is something that I've done in some recent modifications that is generating the mess, but though I try to make a step by step investigation, I'm not reaching a stable result, yet.
For example: thinking about a "timing shift", I've removed a SOUND block, that I used to give an audible feedback to a pushbutton (supposing that the SOUND block is keeping for itself the CPU 'till the sound has finished to play), and the Hall algorithm happily started to work fine again as in the past 
. Then, for a counter-proof, I put again the SOUND and it failed again. So I thought: "I got it !!!", but by removing again the SOUND block, it continued to fail 
so it seems that the SOUND block is not the true root cause.
In my offsetminded experience of old embedded software engineer, the unpredctable behavious were caused typically by memory or timing overlaps, stack overflows, interrupts' addresses not mapped...other nightmares...
So, to try to detect the cause, I'm writing on a file some flags (like buoys: "passed from here") and I see that, when I use the Hall inputs, the flow of flags is different with respect to the one of the GPS. So my thoughts are: either there is a decision variable that is overlapped (or wrongly set) or there is a timing which is not respected...or...
The challenge continues...(and the headache too 
)
Obviously any hint is much appreciated, .
Tschuess, Ugo.
, an unpredictable behaviour sometimes was caused by an "overlap" of RAM variables (in embedded systems featuring a very little amount of RAM memory) ... 
) As an exercise, some months ago I've written a trial app that behaves exactly in that way (effectively I've called it "Scheduler" ) but I've seen with an oscilloscope that there were no significant improvement in the time slots precision.
), therefore I'm now crawling against the river current to find the bug 
