Too many transmitions counts of less then 10 second audio time...It is a delete nightmare

[patelkes]

Hi Shajen,

SDR-Scanner will become decent product if you nurture well....

Within 3 hrs of transmition activity there are hundred of transmitions which audio is less then 10 second. This looks select and delete nightmare in admin.

Please provide Auto-clean or Auto-delete on a criteria to be setup in "Admin" so that sdr-scanner system Auto-delete them in background. We do not wants to record tee, too and tow-tow and listen.

Please do urgently...Thank you.. Kesh

[shajen]

Thank you for donate!

The feature you requested is already done. Just change recording.min_time_ms in config.json. If you set 10000 only recordings that are longer than 10s will be stored.

[patelkes]

Thank you Shajen,

I was using min_recording_time_ms from old config.json publish in issue list no 1. Now I will use new one "recording.min_time_ms": 10000, and see the problem is fixed or not.

Can you please attached or publish latest sample config.json with correct syntax in this thread please...? Kesh VK2KES

[shajen]

Default config.json with change to saving only 10 seconds and longer recording. The only one modified value is recording.min_time_ms to 10000.

{
  "scanner_frequencies_ranges": [
    {
      "device_serial": "auto",
      "ranges": [
        {
          "start": 144000000,
          "stop": 146000000,
          "sample_rate": 2048000
        }
      ]
    }
  ],
  "ignored_frequencies": [],
  "devices": {
    "rtl_sdr": {
      "ppm_error": 0,
      "tuner_gain": 0.0,
      "offset": 0
    },
    "hack_rf": {
      "lna_gain": 0,
      "vga_gain": 0,
      "offset": 0
    }
  },
  "recording": {
    "max_noise_time_ms": 500,
    "min_time_ms": 10000,
    "min_sample_rate": 16000
  },
  "detection": {
    "frequency_grouping_size": 10000,
    "frequency_range_scanning_time_ms": 64,
    "noise_learning_time_seconds": 30,
    "noise_detection_margin": 10,
    "torn_transmission_learning_time_seconds": 60
  },
  "output": {
    "logs": "sdr/logs",
    "file_log_level": "info",
    "console_log_level": "info"
  },
  "cores": 4,
  "memory_limit_mb": 0,
  "mqtt": {
    "hostname": "sdr-broker",
    "port": 1883,
    "username": "admin",
    "password": "password"
  }
}

[patelkes]

Hi Shajen,

Some one published these setting on 18th Feb 2022 issue.

"recording": { "range_scanning_time_ms": 100, "max_silence_time_ms": 2000, "min_recording_time_ms": 1000, "sample_rate": 48000, "threads": 4, "enabled": true }, Are these still Valid? where is the list off all possible config settings?

[shajen]

No, the latest (and valid) config is in my previous post.

[patelkes]

Hi Shajen, Your help has totally fixed my previous issue (Too many Recording less then 10 seconds). Thank you very much.

How can I increase pause limit in recording?. Currently one recording is NOT more then 2 minutes and breaks and then record next one...some time it skip recording in a long talks, I have noticed...please help..Kesh VK2KES

[shajen]

Hi Shajen, Your help has totally fixed my previous issue (Too many Recording less then 10 seconds). Thank you very much.

No problem, enjoy the project :)

How can I increase pause limit in recording?. Currently one recording is NOT more then 2 minutes and breaks and then record next one...some time it skip recording in a long talks, I have noticed...please help..Kesh VK2KES

I have known this bug but unfortunately i don't have a solution for it. If I find solution I will notify you.

[jointerCZ]

I am not sure if my issue is related or not, but I do not want to create new thread. I was running it in VM, no issues, but when I tried to migrate to old Dell E4300, which is 2 cores of P9300, in case there is like 15 minutes continuous transmission, the recordings are chopped into 40-60s blocks, then about 40-60s is missing from recording. SW is the same (installed the same day) but on the E4300, there is this line in the logs seems to be more frequent:

sdr-sdr-scanner-1 | [2023-02-14 17:26:31.188468] [info ] [RingBuffer ] pop/push: 295686897664/295686897664 (1.00)

The E4300 does not have high CPU load, max 20%, so what it can be? It have mechanical HDD, but I did not checked if IO can be a problem. I am thinking getting Odroid H3+ for this (do not want to have PC consuming 130W running all the time).

[shajen]

@jointerCZ

The problem is that signal transmission is decode on single core. So if decoding is slower than incoming data then data will be accumulated in buffer. And for long transmission if the buffer is full then data data is dropped cause the same effect as you posted.

For now is only one way is to increase memory size. Change memory_limit_mb in config.json for bigger value.

[jointerCZ]

Seems reasonable, thanks. What the default value of 0 means? What values would make sense, if the system have 4GB of RAM? 256MB for example? The auto sdr seems to use about 500MB of virt memory on my VM.

[shajen]

0 mean no limit. 2 GB looks ok in your case.

[jointerCZ]

Hmm, still have low hopes the Dell E4300 with 2 cores of P9300 @ 2.26GHz will be able to handle it, as I do not think memory is the problem, but will test in next days.

On the other side, the VM just recorded 1,5h session via 1 SDR set to scan 6x 2MHz bands, so switching bands is not cause for that (I was not sure if that can be the reason) and as the SW is the same, it really have to be HW related.

[shajen]

Try to change cores in config.json to 2 (default is 4 what is too much for your processor).

[jointerCZ]

Seems like CPU load is very near 100% for both cores when there is a transmission to record. So Core 2 Duo P9300 at about 2.26GHz is not enough to run this.

Would this be enough? https://www.hardkernel.com/shop/odroid-h3-plus/ +2 more cores where it seems each core is about twice that fast then P9300 Optimal amount of memory for 2-3 RTL SDR?

[shajen]

Would this be enough? https://www.hardkernel.com/shop/odroid-h3-plus/ +2 more cores where it seems each core is about twice that fast then P9300 Optimal amount of memory for 2-3 RTL SDR?

I think it will be enough. I'm working on i5-6200U and everything works perfectly so N6005 should work event better. The number of cores defines the number of possible transmissions to decode in the same time. So 4 cores can decode 4 transmissions in the same time. The situation gets a bit more complicated if you connect more 'sdr` dongles. Every one scanner needs some resources to detect the transmissions (this is not decoding the transmission). But I think 4 cores will be enough to 2-3 sdr dongles.