RTLAMR stops logging data after running for a couple of hours to a few days

[WB0OCV]

I am running the Windows version of RTLAMR after compiling the latest version with the go programming language using the following command:
go install github.com/bemasher/rtlamr@latest
I start rtl_tcp.exe and then RTLAMR. The program will run fine for a period ranging anywhere from an hour up to several days before it stops logging data and crashes. After it crashes, rtl_tcp stays open and lists some diagnostics. Here is an excerpt of the diagnostics recorded:

client accepted! DESKTOP-7G4IHBM 63234
set freq 912380000
set sample rate 2359296
set gain mode 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
...
...
ll+, now 175
ll+, now 176
ll+, now 177
comm recv bye
Slilg+n,a ln ocwa u1g7h8t
,w oerxkietri nsgo!c
ket bye
Signal caught, exiting!
all threads dead..
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

The program starts logging fine, and will cycle back and forth a few times between logging entries of "ll+, now1" and "ll-, now 0". Eventually, the entires will start incrementally increasing from "ll+, now 1" to "ll+ now 2" to "ll+, now 3" etc, all the way up to "ll+, now 177", after which RTLAMR will stop logging and shut down. The rtl_tcp.exe prgram remains active, and will resume logging entries after I restart RTLAMR.

Can anyone interpret the reason behind the incremental counting of the "ll+, now xxx" as well as the other entries of:

comm recv bye
Slilg+n,a ln ocwa u1g7h8t
,w oerxkietri nsgo!c
ket bye
Signal caught, exiting!
all threads dead..
listening...

Thanks in advance.
Ken -- WBØOCV

[bemasher]

When samples aren't read from rtl_tcp fast enough, it begins buffering them in a linked list, ll+ means the linked list grew. This usually happens when -msgtype=all or -msgtype=r900 is used on underpowered hardware. You'll want to set -msgtype to only the messages you actually need for your meters, or decrease -symbollength.

Note that decreasing -symbollength also decrease sampled bandwidth, which will affect how many channels you'll see messages on.

-msgtype=scm: comma-separated list of message types to receive: all, scm, scm+, idm, netidm, r900 and r900bcd
-symbollength=72: symbol length in samples (8, 32, 40, 48, 56, 64, 72, 80, 88, 96)

I just released a new minor version with some updates to how sample blocks are read and consumed, including a warning when consumption rate is less than configured sample rate. Feel free to give that a try.

https://github.com/bemasher/rtlamr/releases/tag/v0.9.5

[WB0OCV]

Thanks Doug. I suspect the issue is my use of the "-msgtype=r900" option. Here is the command line I am using in the batch file to log data coming from the water meter in my house:

rtlamr -msgtype=r900 -filterid=1550360264 -format=csv >> "D:\Ham_Radio\Water_Meter\water_use.csv"

Using these settings, here is what the 'raw' unformatted datastring received form the meter looks like:

{Time:2026-04-26T05:41:03.375 R900:{ID:1550360264 Unkn1:0xA3 NoUse:33 BackFlow:0 Consumption: 9906524 Unkn3:0x00 Leak: 1 LeakNow:0}}

I have a question: If you don't specify a -symbollength=xx value, does the program default to a maximum value of 96 channels?

I'll try downloading and compiling the latest version, and also look into adding a -symbollength option as well. Thank you for the prompt response to my question, and for this wonderful piece of software. Have a great day.

Ken -- WBØOCV