search

boatbod / op25

Fork of osmocom OP25 by boatbod
311 stars 97 forks source link

DMR freezes after a few minutes #140

Closed srs4511351 closed 2 years ago

srs4511351 commented 2 years ago

I have a Raspberry Pi 4 running DietPi 64 bit Debian Buster. With op25 cloned and compiled on 12/6/2021, DMR (multi_rx.py) works for a few minutes, then it freezes, only when there is a plot window open. P25 (rx.py) works and does not freeze with or without a plot. Smartnet (multi_rx.py) does not freeze with a plot.

DMR does not freeze with symbol plot on a Raspberry Pi OS 64-bit Bullseye system, op25 cloned and built on 11/11/2021.

On the DietPi 64 bit Debian Buster system, I uninstalled the 12/6/2021 version, then copied the 11/11/2021 version to the DietPi 64 bit Debian Buster system and deleted the build folder. I compiled and installed this version. Now, DMR works well with the symbol plot running.

Are there recent changes to op25 that may cause this?

Is there a version number that I can use to help identify the versions I tried?

----Steve

boatbod commented 2 years ago

Sounds like there is a crash occurring in the python code. Please take a look in the stderr.2 log and post the portion containing the "Traceback" message.

srs4511351 commented 2 years ago

There is no "Traceback" in the stderr.2 log. Is there something I have to do to get multi_rx.py to add the traceback? I have Python 3.9.2 After it freezes, I can press Ctrl-C to stop the program. After that, it displays in stderr.2: Ctrl-C detected FATAL: exception not rethrown

Edit: During one of the times that it froze while receiving a signal, I noticed that data continued to come in for a while after the symbol plot froze. After that, there were no more packets shown in the log, even though there were more sent from the repeater after that time.

----Steve

boatbod commented 2 years ago

Ok, well if it's not crashing I wonder what is happening. Turn the logging up to "-v 11" and let it run until it hangs. Maybe something useful will be in the log file.

srs4511351 commented 2 years ago

I tried-v 14 and -v 99 I didn’t see anything I thought was useful. I could attach the file.

It seems to me that it isn’t crashing, but filling up the queue to the symbol plot and waiting. You would be more likely to know if it could be what is happening. It doesn’t freeze without the plot.

——Steve

boatbod commented 2 years ago

Plots do consume lots of cpu, but usually if this is the issue you'd see an ever-growing series of "O" characters write to the console. I can't really think of something specific to plots that would cause DMR to hang but not P25, especially without the evidence of a traceback. Is it any plots or just one particular one that causes the problem?

srs4511351 commented 2 years ago

With "-v 11" and the FFT plot, there were a few "O" characters and it froze much sooner. FFT typically takes more CPU time. With the symbol plot, there were a no "O" characters and it lasted longer before freezing. With the datascope plot, there were a no "O" characters, but it froze.

One difference with rx.py is that I can press a number key to open, change or close a plot. When there are too many "O" characters displayed, closing and opening the plot used to get it started again. rx.py doesn't freeze now due to "O" characters, so I no longer need to do that.

----Steve

boatbod commented 2 years ago

Both rx.py and multi_rx.py terminal support the same number keys for dynamically turning the plots on and off. Seeing any "O" characters is a bad sign and indicates the cpu cannot keep up with processing demands. The FFT plot is the highest utilization followed by the Mixer plot because both require many fft computations. I'd recommend avoiding leaving them on when you're not actively using them.

srs4511351 commented 2 years ago

With the DMR configuration, the plot is specified in the config file. Pressing number keys have no effect on which plot, if any, is displayed. That is true when the config file has the plot parameter removed, is null or has a plot specified.

There are no "O" characters displayed with my usual symbol plot. I believe that the CPU is keeping up in this case.

Even with the symbol plot running, the system cloned and built on 11/11/2021 works well. I want to keep the symbol plot running since I can't get the number keys to work.

----Steve

boatbod commented 2 years ago

If you pulled the software from the boatbod github repo on 11/11/21 then it absolutely should have the capability for dynamic plots. i.e. same behavior in rx.py as multi_rx.py. The only thing I can think is perhaps your config does not have the terminal enabled? Please post or attach the relevant cfg.json file so I can take a look.

srs4511351 commented 2 years ago

The boatbod github repo on 11/11/21 is working and does not freeze. The one that I am working with now was pulled on 12/6/2021. It is the one that is freezing. I assume that it still has the keyboard plot feature.

I have attached my .json file, but I had to rename it in order to attach it. I don't see a section for a terminal in it. Maybe you can help with that.

In any case, it is beside the original point, that the newer code is freezing in some sort of relation to the plot display.

dmr_cfg.json.txt

boatbod commented 2 years ago

Try adding the "terminal" section to your config. dmr_cfg.json.txt

srs4511351 commented 2 years ago

I added the terminal section that you provided. It works now and does not freeze on the newer version from 12/6/2021. That still doesn't explain why identical installations consistently fail with the version downloaded on 12/6/2021. This was on 2 different Debian systems. I am not getting "0" characters printed even on the fft plot! I hope it handles the AMBE packets. As long at is is working this way, I am OK with it.

The DMR example files do not have a terminal section, so I thought is was not needed.

----Steve