RTL Serial Number Not Being Accepted
Dewey3 opened this issue · 13 comments
I noticed that when I've tried the last couple revisions of TrunkRecorder, it's not liking the RTL=######## in my config json file. I've gotten around this by just using the device number, RTL=0 , RTL=1 , RTL=2 , etc. This has not been a problem so far since the Nooelec dongles that I use all have the same PPM, but how would I differentiate between the SDRs if they had different PPM values? (BTW, not related to this or TrunkRecorder, I've noticed that Nooelec's latest NESDR SMArt dongles, the v5, all are giving me a PPM of -2 while all of the previous version were spot on at 0).
It should work pretty much as you've described it. For instance, this is in my config to turn the bias t on for a specific SDR stick with the configured serial of 41. (formatting is important, no extra spaces in the device string)
"driver": "osmosdr",
"device": "rtl=41,bias=1",
Custom serials can be a little flaky when setting them with rtl_eeprom. I've had the most compatible results when just using a simple numerical serial instead of alphanumerics or special characters. Even though you can set it that way, no all SDR software seems to handle a serial string like Nooelec-10.
Thanks. The problem I am having is that I must now use device number... 0, 1, 2, etc... instead of the dongle serial number. The problem with that is I don't know how to determine what dongle is what... 0, 1, 2, etc... if I have to address the dongles separately, such as, if different dongles have different PPMs. In creating the serial numbers with rtl_eeprom I've always used "standard" serial numbers by using the date I received the dongle. In the case of multiple dongles received on the same date, I just sequence the date by one. I just happened to have received three more v5 NESDR SMArt yesterday, their serial numbers are 20240116, 20240117, and 20240118. That way, I never have to worry about serial number collisions, especially since I have dongles going back to 2014 and 2015. Thanks again.
I have seen the same issue and as a new user it was quite frustrating trying to troubleshoot why my config.jason file kept failing. As I new user I have been experimenting and see that the device designation, when using multiple dongles, changes depending on which USB port they are plugged into. I agree that it is necessary to have the software recognize the RTL-SDR device serial number.
Can you post the output with serial numbers from rtl_test and the exact device config strings you're using in your config.json?
Can you post the output with serial numbers from
rtl_testand the exact device config strings you're using in your config.json?
Here you go. The only change that I make to my dongles is serial number.
Can you post the output with serial numbers from
rtl_testand the exact device config strings you're using in your config.json?
I just realized you asked for rtl_test and I gave you rtl_eeprom , sorry. Here's rtl_test . The lost 32 bytes popped up immediately when I started rtl_test . I let it continue to run for about three minutes, and it never threw any more errors.
Attached is my production PG Co, MD config file that works without flaw on the 9/15/2022 TR version. I use the exact same json file when I test the latest releases of TR with the only change being the Talkgroups.csv file due to the change with new versions of TR.
{
"ver": 2,
"defaultMode": "digital",
"captureDir": "/home/truser/recordings",
"logFile": true,
"frequencyFormat": "mhz",
"logLevel": "error",
"debugRecorder": false,
"sources": [{
"center": 770318750.0,
"rate": 2048000.0,
"error": 0,
"gain": 29.7,
"digitalRecorders": 7,
"driver": "osmosdr",
"device": "rtl=20210302",
"ppm": 0
},{
"center": 771706250.0,
"rate": 2048000.0,
"error": 0,
"gain": 29.7,
"digitalRecorders": 7,
"driver": "osmosdr",
"device": "rtl=20210303",
"ppm": 0
},{
"center": 773181250.0,
"rate": 2048000.0,
"error": 0,
"gain": 29.7,
"digitalRecorders": 7,
"driver": "osmosdr",
"device": "rtl=20210304",
"ppm": 0
}],
"systems": [{
"shortName": "2A8",
"type": "p25",
"control_channels": [772481250,772906250,773231250,773881250],
"modulation": "qpsk",
"squelch": -60,
"talkgroupsFile": "2A8-TR.csv",
"compressWav": false,
"audioArchive": false,
"transmissionArchive": false,
"callLog": false,
"analogLevels": 6,
"digitalLevels": 2,
"recordUnknown": true,
"recordUUVCalls": true,
"hideEncrypyed": false,
"hideUnknownTalkgroups": false,
"minDuration": 0,
"minTransmissionDuration": 0,
"talkgroupDisplayFormat": "id_tag"
}],
"plugins":[{
"name": "rdioscanner_uploader",
"library": "librdioscanner_uploader.so",
"server": "http://192.168.1.100:3000",
"systems": [{
"shortName": "2A8",
"apiKey": "00000001-0000-0000-0000-0000000002A8",
"systemId": 1
}]
}]
}
Can you run rtl_test from inside the same machine you're trying to run trunk-recorder on and show the config that uses a device that's listed in the rtl_test output?
I'm not as Linux proficient, so let me know if there's something missing. This is from the Kali Linux box running TR, but I get the exact same problem on my RPi4/8GB.
{
"ver": 2,
"defaultMode": "digital",
"captureDir": "/home/kuser/recordings",
"logFile": true,
"frequencyFormat": "mhz",
"logLevel": "error",
"debugRecorder": false,
"sources": [{
"center": 381006250.0,
"rate": 2048000.0,
"error": 0,
"gain": 22.9,
"digitalRecorders": 9,
"driver": "osmosdr",
"device": "rtl=0",
"ppm": -2.0
}],
"systems": [{
"shortName": "580A0-006",
"type": "p25",
"control_channels": [380275000,380575000,380875000,381737500],
"modulation": "qpsk",
"squelch": -60,
"talkgroupsFile": "TalkgroupsFile.csv",
"compressWav": false,
"audioArchive": false,
"transmissionArchive": false,
"callLog": false,
"analogLevels": 6,
"digitalLevels": 2,
"recordUnknown": true,
"recordUUVCalls": true,
"hideEncrypyed": false,
"hideUnknownTalkgroups": false,
"minDuration": 0,
"minTransmissionDuration": 0,
"talkgroupDisplayFormat": "id_tag"
},{
"shortName": "580A0-015",
"type": "p25",
"control_channels": [380450000,380762500,381075000,381425000,381700000],
"modulation": "qpsk",
"squelch": -60,
"talkgroupsFile": "TalkgroupsFile.csv",
"compressWav": false,
"audioArchive": false,
"transmissionArchive": false,
"callLog": false,
"analogLevels": 6,
"digitalLevels": 2,
"recordUnknown": true,
"recordUUVCalls": true,
"hideEncrypyed": false,
"hideUnknownTalkgroups": false,
"minDuration": 0,
"minTransmissionDuration": 0,
"talkgroupDisplayFormat": "id_tag"
}],
"plugins":[{
"name": "rdioscanner_uploader",
"library": "librdioscanner_uploader.so",
"server": "http://127.0.0.1:3000",
"systems": [{
"shortName": "580A0-006",
"apiKey": "10000000-0000-0000-0000-000000000001",
"systemId": 1
},{
"shortName": "580A0-015",
"apiKey": "10000000-0000-0000-0000-000000000001",
"systemId": 1
}]
}]
}
What happens if you use "device": "rtl=20240116",?
What happens if you use
"device": "rtl=20240116",?
Sorry Tad, in my rush to post the info before I shutdown for the night, I inadvertantly attached the wrong json. The problem happens with my multiple dongle configs. The "device=serial number" is how I have always done it, but that is what does not work with the newer versions of TR. When I get home today I will attach the right json and a copy of the error the led me to use "rtl=0" instead of the serial number.
@tadscottsmith ; my apologies again, I guess lightning can strike the same place twice and each time I think it has been my fault through coincidence. I got everything all fired up so I could give you the information you asked for and as soon as I started TR, sure enough, I got an error. However, this time instead of just blindly changing the RTL= from device serial numbers to 0 and 1 (which do work), I decided to run rtl_eeprom. Well, it looks like one of my USB cables I use to connect the dongles is loose or faulty as RTL_eeprom only showed one dongle. So this time instead of replacing the serial numbers with 0 and 1, I pushed harder on the USB cables snuggling them up against the dongles. I ran RTL_eeprom again, saw both dongles, started TR, and it ran using the serial numbers. So somehow in my futzing with the config.json file, I managed to also fix the USB connection with I changed the RTL= to 0 and 1` on the previous two or three occasions.