LTE cell scanning quits application after long scans

Hi,

I am using Spike v4.04 in monitoring stations in conjunction with a BB60D and using it to record long term results regarding interference. The basic spectrum analysis is rock solid and I have uptime of hundreds of days days in many cases, but if I scan cells I find the app sometimes quits after a few hours – I think probably related to the number of cells the software asserts. In some cases during propagation enhancements many coastal cells from hundreds of kilometres are visible and this perhaps compounds the issue. To mitigate I save often and reset the cell list but it can be annoying as I have to make a bet on the timing. I tried with later versions in a test environment with fewer cells and have had the similar issues but perhaps over longer timescales. Is this something that could be improved?

On a related note I am looking to update many mobile monitoring systems to add automated cell scanning via SCPI, and NR support is becoming pretty important. Any plans to have NR support in the cell scanning as well as LTE?

Regards,

Cyprien

Cyprien,

Does the assert give you any other information? Sometimes a line number? I might be able to use that to track down why it’s happening.

No immediate plans for NR support.

Hi Andrew,

The application doesn’t give a messagebox with any debug info if that is what you mean – the process just terminates without trace.

Cyprien

[Andrew]

Cyprien,

Is it always after a long session? Or can it happen at any time (e.g. 2 minutes after starting the measurements)?

Additional question, do you notice any sort of increase in memory usage by the application after making LTE measurements over long periods. Trying to rule out a memory leak as well.

Thanks for your help in trying to narrow it down.

• This reply was modified 3 weeks, 1 day ago by Andrew.

Hi Andrew,

The time is not fixed but it may take several hours or days. As far as I can tell it has never crashed when I have a small number of cells in the list with steady state propagation conditions. I think the issue is manifest when the number of cells scanned and recorded is quite large suring propagation enhancements as the actual number of cells signals can be large, but also entries appear appear in the list with blanked supplementary information as presumably SIB1 is corrupt due to the fading conditions/interference. I have not monitored the memory because the length of time involved but I can take a look. Any advice on how to set-up automated logging to get useful debug information?

Cyprien

[Author]

Posts