JMBE Audio Issues - 0.4B8+ P25-PII Mac OSX Mojave - Repeat/echo and Gabled
184 views
Skip to first unread message
Ron Benoit
Apr 20, 2020, 11:28:48 PM4/20/20
to sdrtrunk
Hi Dean,
Weird issues on the iMac after moving up to B8+ and 1.0.4. Started to get replication/duplication issues and gabled audio. Regressing to 1.0.0 resolved most the repeat issues, but not the garbled audio.
Not sure how much of this is JMBE related... this P25 started acting funny around B6 and the 1.0.4 upgrades... but definitely noted the echo/replay problem on B8/1.0.4. However, even on 1.0.0, still get issues.
No Problems on the z840 workstation with the other P25 systems - which are all C4FM and PI (0.4.0 + 1.0.4).
Also since 0.4.0, new debug entry: 20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]
Not seeing any L2 drops or sync drops - SNR is pretty good... no Channel Denies. MOST OF THE TIME the audio is fine, especially with 1.0.0. So it doesn't seem to be a PI v PII issue. Also the control channel doesn't drop or show any signs of issues. Ocasionally I'll have issues when the tuners are on the edge of a control channel change... which I'm assuming is based on signal strength? Only one control channel is active at any given interval, but SDRT rotates between most of the six control channels over 24 hours.
This is the Westy P25 PII Simulcast that takes 3 dongles - https://www.radioreference.com/apps/db/?sid=7771. I also had to set to mono to prevent both speakers from being engaged on one channel.
9:58:50.396 INFO i.g.d.log.ApplicationLog - Application Log File: /Users/ron/SDRTrunk/logs/sdrtrunk_app.log [18MB/512MB 3%]
19:58:50.424 INFO i.g.d.log.ApplicationLog - [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - ******************************************************************* [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - **** sdrtrunk: a trunked radio and digital decoding application *** [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - **** website: https://github.com/dsheirer/sdrtrunk *** [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - ******************************************************************* [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Memory Logging Format: [Used/Allocated PercentUsed%] [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Name: Mac OS X [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Arch: x86_64 [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Version: 10.14.6 [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Host CPU Cores: 8 [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Host Max Java Memory: 512 MB [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Storage Directories: [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Application Root: /Users/ron/SDRTrunk [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Application Log: /Users/ron/SDRTrunk/logs [19MB/512MB 3%]
19:58:50.432 INFO i.g.d.log.ApplicationLog - Event Log: /Users/ron/SDRTrunk/event_logs [19MB/512MB 3%]
19:58:50.433 INFO i.g.d.log.ApplicationLog - Playlist: /Users/ron/SDRTrunk/playlist [19MB/512MB 3%]
19:58:50.433 INFO i.g.d.log.ApplicationLog - Recordings: /Users/ron/SDRTrunk/recordings [19MB/512MB 3%]
19:58:51.331 INFO i.g.d.util.ThreadPool - Application thread pool created with [8] threads [23MB/512MB 4%]
19:58:51.331 INFO i.g.dsheirer.gui.SDRTrunk - Home path: /Users/ron/SDRTrunk [23MB/512MB 4%]
19:58:51.334 INFO i.g.d.p.SystemProperties - SystemProperties - loaded [/Users/ron/SDRTrunk/SDRTrunk.properties] [24MB/512MB 4%]
19:58:51.334 INFO i.g.d.p.SystemProperties - SystemProperties - application properties loaded [/Users/ron/SDRTrunk/SDRTrunk.properties] [24MB/512MB 4%]
19:58:51.487 INFO i.g.d.s.SettingsManager - SettingsManager - loading settings file [/Users/ron/SDRTrunk/settings/settings.xml] [10MB/512MB 2%]
19:58:51.797 INFO i.g.d.s.r.RecordingSourceManager - RecordingSourceManager - discovered [0] recording configurations [23MB/512MB 4%]
19:58:51.832 INFO i.g.d.s.t.TunerManager - LibUSB API Version: 16777478 [24MB/512MB 4%]
19:58:51.833 INFO i.g.d.s.t.TunerManager - LibUSB Version: 1.0.22.11312 [24MB/512MB 4%]
19:58:51.833 INFO i.g.d.s.t.TunerManager - discovered [20] attached USB devices [24MB/512MB 4%]
19:58:51.838 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0DC4:00DB] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.838 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:0813] Hub Device [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:9227] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:1107] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:1112] Miscellaneous Device [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:9127] Hub Device [24MB/512MB 4%]
19:58:51.840 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:2813] Hub Device [24MB/512MB 4%]
19:58:53.422 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 5 Max Rate:38400000 bps [26MB/512MB 5%]
19:58:54.976 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 6 Max Rate:38400000 bps [27MB/512MB 5%]
19:58:56.522 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 3 Max Rate:38400000 bps [27MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05A6:0009] Communications Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0626] Hub Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0610] Hub Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0626] Hub Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:0813] Hub Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05AC:8511] Miscellaneous Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [047F:AC01] Unknown Device - Class 0 [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:2813] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0610] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0A5C:4500] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - ------------------------------------------------------------- [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus - Potential Maximum Data Rates [28MB/512MB 5%]
19:58:56.529 INFO i.g.d.s.t.TunerManager - USB Bus [20] Rate [115200000] bits per second [28MB/512MB 5%]
19:58:57.209 INFO i.g.d.icon.IconManager - loading icons file [/Users/ron/SDRTrunk/settings/icons.xml] [44MB/512MB 8%]
19:58:57.389 INFO i.g.d.p.PlaylistManager - Loading playlist file [/Users/ron/SDRTrunk/playlist/default.xml] [22MB/512MB 4%]
19:58:57.501 INFO i.g.dsheirer.gui.SDRTrunk - starting main application gui [27MB/512MB 5%]
19:58:58.043 INFO i.g.d.s.t.u.USBMasterProcessor - Starting USB master processor thread [41MB/512MB 8%]
19:58:59.548 INFO i.g.d.c.c.ChannelAutoStartFrame - Starting [6] channels now - user invoked [66MB/512MB 12%]
19:58:59.665 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.4.jar] [68MB/512MB 13%]
19:58:59.678 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.4 [68MB/512MB 13%]
19:58:59.678 INFO i.g.d.a.c.m.ImbeAudioModule - JMBE audio conversion library IMBE CODEC successfully loaded - P25-1 audio will be available [68MB/512MB 13%]
19:58:59.695 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [69MB/512MB 13%]
19:58:59.885 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [78MB/512MB 15%]
19:58:59.955 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [86MB/512MB 16%]
20:05:06.333 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [363MB/512MB 71%].
19:58:50.424 INFO i.g.d.log.ApplicationLog - [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - ******************************************************************* [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - **** sdrtrunk: a trunked radio and digital decoding application *** [19MB/512MB 3%]
19:58:50.429 INFO i.g.d.log.ApplicationLog - **** website: https://github.com/dsheirer/sdrtrunk *** [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - ******************************************************************* [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Memory Logging Format: [Used/Allocated PercentUsed%] [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Name: Mac OS X [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Arch: x86_64 [19MB/512MB 3%]
19:58:50.430 INFO i.g.d.log.ApplicationLog - Host OS Version: 10.14.6 [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Host CPU Cores: 8 [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Host Max Java Memory: 512 MB [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Storage Directories: [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Application Root: /Users/ron/SDRTrunk [19MB/512MB 3%]
19:58:50.431 INFO i.g.d.log.ApplicationLog - Application Log: /Users/ron/SDRTrunk/logs [19MB/512MB 3%]
19:58:50.432 INFO i.g.d.log.ApplicationLog - Event Log: /Users/ron/SDRTrunk/event_logs [19MB/512MB 3%]
19:58:50.433 INFO i.g.d.log.ApplicationLog - Playlist: /Users/ron/SDRTrunk/playlist [19MB/512MB 3%]
19:58:50.433 INFO i.g.d.log.ApplicationLog - Recordings: /Users/ron/SDRTrunk/recordings [19MB/512MB 3%]
19:58:51.331 INFO i.g.d.util.ThreadPool - Application thread pool created with [8] threads [23MB/512MB 4%]
19:58:51.331 INFO i.g.dsheirer.gui.SDRTrunk - Home path: /Users/ron/SDRTrunk [23MB/512MB 4%]
19:58:51.334 INFO i.g.d.p.SystemProperties - SystemProperties - loaded [/Users/ron/SDRTrunk/SDRTrunk.properties] [24MB/512MB 4%]
19:58:51.334 INFO i.g.d.p.SystemProperties - SystemProperties - application properties loaded [/Users/ron/SDRTrunk/SDRTrunk.properties] [24MB/512MB 4%]
19:58:51.487 INFO i.g.d.s.SettingsManager - SettingsManager - loading settings file [/Users/ron/SDRTrunk/settings/settings.xml] [10MB/512MB 2%]
19:58:51.797 INFO i.g.d.s.r.RecordingSourceManager - RecordingSourceManager - discovered [0] recording configurations [23MB/512MB 4%]
19:58:51.832 INFO i.g.d.s.t.TunerManager - LibUSB API Version: 16777478 [24MB/512MB 4%]
19:58:51.833 INFO i.g.d.s.t.TunerManager - LibUSB Version: 1.0.22.11312 [24MB/512MB 4%]
19:58:51.833 INFO i.g.d.s.t.TunerManager - discovered [20] attached USB devices [24MB/512MB 4%]
19:58:51.838 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0DC4:00DB] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.838 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:0813] Hub Device [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:9227] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:1107] Unknown Device - Class 0 [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:1112] Miscellaneous Device [24MB/512MB 4%]
19:58:51.839 INFO i.g.d.s.t.TunerManager - USB Bus [64] Device [05AC:9127] Hub Device [24MB/512MB 4%]
19:58:51.840 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:2813] Hub Device [24MB/512MB 4%]
19:58:53.422 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 5 Max Rate:38400000 bps [26MB/512MB 5%]
19:58:54.976 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 6 Max Rate:38400000 bps [27MB/512MB 5%]
19:58:56.522 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0BDA:2838] LOADED: RTL2832 SDR/R820T 3 Max Rate:38400000 bps [27MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05A6:0009] Communications Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0626] Hub Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0610] Hub Device [28MB/512MB 5%]
19:58:56.523 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0626] Hub Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:0813] Hub Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05AC:8511] Miscellaneous Device [28MB/512MB 5%]
19:58:56.524 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [047F:AC01] Unknown Device - Class 0 [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [2109:2813] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [05E3:0610] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus [20] Device [0A5C:4500] Hub Device [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - ------------------------------------------------------------- [28MB/512MB 5%]
19:58:56.525 INFO i.g.d.s.t.TunerManager - USB Bus - Potential Maximum Data Rates [28MB/512MB 5%]
19:58:56.529 INFO i.g.d.s.t.TunerManager - USB Bus [20] Rate [115200000] bits per second [28MB/512MB 5%]
19:58:57.209 INFO i.g.d.icon.IconManager - loading icons file [/Users/ron/SDRTrunk/settings/icons.xml] [44MB/512MB 8%]
19:58:57.389 INFO i.g.d.p.PlaylistManager - Loading playlist file [/Users/ron/SDRTrunk/playlist/default.xml] [22MB/512MB 4%]
19:58:57.501 INFO i.g.dsheirer.gui.SDRTrunk - starting main application gui [27MB/512MB 5%]
19:58:58.043 INFO i.g.d.s.t.u.USBMasterProcessor - Starting USB master processor thread [41MB/512MB 8%]
19:58:59.548 INFO i.g.d.c.c.ChannelAutoStartFrame - Starting [6] channels now - user invoked [66MB/512MB 12%]
19:58:59.665 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.4.jar] [68MB/512MB 13%]
19:58:59.678 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.4 [68MB/512MB 13%]
19:58:59.678 INFO i.g.d.a.c.m.ImbeAudioModule - JMBE audio conversion library IMBE CODEC successfully loaded - P25-1 audio will be available [68MB/512MB 13%]
19:58:59.695 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [69MB/512MB 13%]
19:58:59.885 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [78MB/512MB 15%]
19:58:59.955 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [86MB/512MB 16%]
20:05:06.333 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [363MB/512MB 71%].
(this error occurred when switching JMBE audio Lib versions - I would ignore).
objc[88700]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff92f913d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x15fa66f50). One of the two will be used. Which one is undefined.
20:16:25.196 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [332MB/512MB 64%]
20:16:25.205 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [334MB/512MB 65%]
20:16:25.205 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [334MB/512MB 65%]
20:16:25.212 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [335MB/512MB 65%]
20:16:25.212 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [335MB/512MB 65%]
20:16:25.218 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [337MB/512MB 65%]
20:16:25.218 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [337MB/512MB 65%]
20:16:25.224 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [337MB/512MB 65%]
20:16:25.224 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [337MB/512MB 65%]
20:16:25.231 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [339MB/512MB 66%]
20:16:25.231 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [339MB/512MB 66%]
20:16:25.240 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [341MB/512MB 66%]
20:16:25.240 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [341MB/512MB 66%]
20:16:25.247 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [343MB/512MB 67%]
20:16:25.247 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [343MB/512MB 67%]
20:16:25.254 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [343MB/512MB 67%]
20:16:25.255 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [343MB/512MB 67%]
20:16:25.262 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [346MB/512MB 67%]
20:16:25.262 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [346MB/512MB 67%]
20:16:25.269 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [347MB/512MB 67%]
20:16:25.269 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [347MB/512MB 67%]
20:16:25.276 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [348MB/512MB 68%]
20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]
20:26:49.383 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [415MB/512MB 81%]
objc[88700]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff92f913d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x15fa66f50). One of the two will be used. Which one is undefined.
20:16:25.196 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [332MB/512MB 64%]
20:16:25.205 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [334MB/512MB 65%]
20:16:25.205 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [334MB/512MB 65%]
20:16:25.212 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [335MB/512MB 65%]
20:16:25.212 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [335MB/512MB 65%]
20:16:25.218 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [337MB/512MB 65%]
20:16:25.218 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [337MB/512MB 65%]
20:16:25.224 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [337MB/512MB 65%]
20:16:25.224 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [337MB/512MB 65%]
20:16:25.231 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [339MB/512MB 66%]
20:16:25.231 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [339MB/512MB 66%]
20:16:25.240 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [341MB/512MB 66%]
20:16:25.240 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [341MB/512MB 66%]
20:16:25.247 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [343MB/512MB 67%]
20:16:25.247 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [343MB/512MB 67%]
20:16:25.254 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [343MB/512MB 67%]
20:16:25.255 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [343MB/512MB 67%]
20:16:25.262 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [346MB/512MB 67%]
20:16:25.262 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [346MB/512MB 67%]
20:16:25.269 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [347MB/512MB 67%]
20:16:25.269 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.0.jar] [347MB/512MB 67%]
20:16:25.276 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.0 [348MB/512MB 68%]
20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]
20:26:49.383 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [415MB/512MB 81%]
I enabled channel recording on the tuners, and after about 30 minutes, it hung SDRT... I noted the CPU went hot (SDRT at 450% CPU) for about 5 minutes before it hung... looks like major GCs/memory leak. I have never had SDRT crash on me on the Mac before, but I also haven't enabled channel recordings before either. I do have the JVM memory set for 512M, but not in -server mode.
Can definitely confirm that enabling audio recordings causes OOM:
21:18:07.490 INFO i.g.d.a.c.m.JmbeAudioModule - Loading JMBE library from [/Users/ron/SDRTrunk/jmbe-1.0.4.jar] [116MB/512MB 22%]
21:18:07.497 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.4 [118MB/512MB 23%]
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.desktop/java.awt.image.DataBufferInt.<init>(Unknown Source)
at java.desktop/java.awt.image.Raster.createPackedRaster(Unknown Source)
at java.desktop/java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
at java.desktop/java.awt.image.BufferedImage.<init>(Unknown Source)
at java.desktop/sun.java2d.loops.GraphicsPrimitive.convertFrom(Unknown Source)
at java.desktop/sun.java2d.opengl.OGLGeneralBlit.Blit(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.updateSurfaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.replaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceData.getSourceSurfaceData(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.renderImageScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.tryCopyOrScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.awt.image.ImageRepresentation.drawToBufImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.ValidatePipe.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at io.github.dsheirer.spectrum.WaterfallPanel.paintComponent(WaterfallPanel.java:308)
at java.desktop/javax.swing.JComponent.paint(Unknown Source)
at java.desktop/javax.swing.JComponent.paintToOffscreen(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at java.desktop/javax.swing.RepaintManager.paint(Unknown Source)
at java.desktop/javax.swing.JComponent._paintImmediately(Unknown Source)
at java.desktop/javax.swing.JComponent.paintImmediately(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.base/java.security.AccessController.executePrivileged(Unknown Source)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.desktop/java.awt.image.DataBufferInt.<init>(Unknown Source)
at java.desktop/java.awt.image.Raster.createPackedRaster(Unknown Source)
at java.desktop/java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
at java.desktop/java.awt.image.BufferedImage.<init>(Unknown Source)
at java.desktop/sun.java2d.loops.GraphicsPrimitive.convertFrom(Unknown Source)
at java.desktop/sun.java2d.opengl.OGLGeneralBlit.Blit(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.updateSurfaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.replaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceData.getSourceSurfaceData(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.renderImageScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.tryCopyOrScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.awt.image.ImageRepresentation.drawToBufImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.ValidatePipe.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at io.github.dsheirer.spectrum.WaterfallPanel.paintComponent(WaterfallPanel.java:308)
at java.desktop/javax.swing.JComponent.paint(Unknown Source)
at java.desktop/javax.swing.JComponent.paintToOffscreen(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at java.desktop/javax.swing.RepaintManager.paint(Unknown Source)
at java.desktop/javax.swing.JComponent._paintImmediately(Unknown Source)
at java.desktop/javax.swing.JComponent.paintImmediately(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.base/java.security.AccessController.executePrivileged(Unknown Source)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "USB Event Processor" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
21:18:07.497 INFO i.g.d.a.c.m.JmbeAudioModule - JMBE audio conversion library loaded: JMBE Audio Conversion Library v1.0.4 [118MB/512MB 23%]
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.desktop/java.awt.image.DataBufferInt.<init>(Unknown Source)
at java.desktop/java.awt.image.Raster.createPackedRaster(Unknown Source)
at java.desktop/java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
at java.desktop/java.awt.image.BufferedImage.<init>(Unknown Source)
at java.desktop/sun.java2d.loops.GraphicsPrimitive.convertFrom(Unknown Source)
at java.desktop/sun.java2d.opengl.OGLGeneralBlit.Blit(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.updateSurfaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.replaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceData.getSourceSurfaceData(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.renderImageScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.tryCopyOrScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.awt.image.ImageRepresentation.drawToBufImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.ValidatePipe.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at io.github.dsheirer.spectrum.WaterfallPanel.paintComponent(WaterfallPanel.java:308)
at java.desktop/javax.swing.JComponent.paint(Unknown Source)
at java.desktop/javax.swing.JComponent.paintToOffscreen(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at java.desktop/javax.swing.RepaintManager.paint(Unknown Source)
at java.desktop/javax.swing.JComponent._paintImmediately(Unknown Source)
at java.desktop/javax.swing.JComponent.paintImmediately(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.base/java.security.AccessController.executePrivileged(Unknown Source)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.desktop/java.awt.image.DataBufferInt.<init>(Unknown Source)
at java.desktop/java.awt.image.Raster.createPackedRaster(Unknown Source)
at java.desktop/java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
at java.desktop/java.awt.image.BufferedImage.<init>(Unknown Source)
at java.desktop/sun.java2d.loops.GraphicsPrimitive.convertFrom(Unknown Source)
at java.desktop/sun.java2d.opengl.OGLGeneralBlit.Blit(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.updateSurfaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceDataProxy.replaceData(Unknown Source)
at java.desktop/sun.java2d.SurfaceData.getSourceSurfaceData(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.renderImageScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.tryCopyOrScale(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.awt.image.ImageRepresentation.drawToBufImage(Unknown Source)
at java.desktop/sun.java2d.pipe.DrawImage.scaleImage(Unknown Source)
at java.desktop/sun.java2d.pipe.ValidatePipe.scaleImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.drawImage(Unknown Source)
at io.github.dsheirer.spectrum.WaterfallPanel.paintComponent(WaterfallPanel.java:308)
at java.desktop/javax.swing.JComponent.paint(Unknown Source)
at java.desktop/javax.swing.JComponent.paintToOffscreen(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at java.desktop/javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at java.desktop/javax.swing.RepaintManager.paint(Unknown Source)
at java.desktop/javax.swing.JComponent._paintImmediately(Unknown Source)
at java.desktop/javax.swing.JComponent.paintImmediately(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.desktop/javax.swing.RepaintManager$4.run(Unknown Source)
at java.base/java.security.AccessController.executePrivileged(Unknown Source)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "USB Event Processor" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Let me know what you need. the WAV files are huge for 5-10 minutes of recording of mostly dead air, so something doesn't seem right (2-4 GB?... that seems completely crazy)
I suspect this is a one off P25 system with weird issues... not sure how much we want to invest in debugging.
Best, -Ron
Dean Sauer
Apr 21, 2020, 12:20:06 AM4/21/20
to sdrtrunk
On Monday, April 20, 2020 at 11:28:48 PM UTC-4, Ron Benoit wrote:
Hi Dean,Weird issues on the iMac after moving up to B8+ and 1.0.4. Started to get replication/duplication issues and gabled audio. Regressing to 1.0.0 resolved most the repeat issues, but not the garbled audio.Not sure how much of this is JMBE related... this P25 started acting funny around B6 and the 1.0.4 upgrades... but definitely noted the echo/replay problem on B8/1.0.4. However, even on 1.0.0, still get issues.No Problems on the z840 workstation with the other P25 systems - which are all C4FM and PI (0.4.0 + 1.0.4).
Does the problem system run on this setup? with no issues?
Any changes in antenna hardware? coax? any storms for possible antenna/coax issues?
Also since 0.4.0, new debug entry: 20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]Not seeing any L2 drops or sync drops - SNR is pretty good... no Channel Denies. MOST OF THE TIME the audio is fine, especially with 1.0.0. So it doesn't seem to be a PI v PII issue. Also the control channel doesn't drop or show any signs of issues.
I would record BITS files and submit for review.
Ocasionally I'll have issues when the tuners are on the edge of a control channel change... which I'm assuming is based on signal strength? Only one control channel is active at any given interval, but SDRT rotates between most of the six control channels over 24 hours.
CC rotation is at the whim of the settings of the controller...
It can be set to be ONE channel unless the base is taken down, fails etc..
It can be forced to rotate every x y period... could be 24 hours.. could be 20 minutes... Its actually really a better thing to do so.. hence why the EDACS system that is about to implode in my area has repeaters which are burnt to a crisp from being the CC for months if not years of use.. even if rated for 100% duty cycle
When SDRT looses sync if its setup for multiple CC's then it rotates after the fail period expires.
Let me know what you need. the WAV files are huge for 5-10 minutes of recording of mostly dead air, so something doesn't seem right (2-4 GB?... that seems completely crazy)I suspect this is a one off P25 system with weird issues... not sure how much we want to invest in debugging.
If you get big recording files then its likely not getting the data to end the calls and lumping lots of traffic calls into ONE or more BIG files till it gets the right signal to stop..
DId you play these to see if its multiple calls????
Run the BITS recording on the system for a while when this occurs and submit.
Ron Benoit
Apr 21, 2020, 1:23:47 AM4/21/20
to sdrtrunk
On Monday, April 20, 2020 at 10:20:06 PM UTC-6, Dean Sauer wrote:
On Monday, April 20, 2020 at 11:28:48 PM UTC-4, Ron Benoit wrote:Hi Dean,Weird issues on the iMac after moving up to B8+ and 1.0.4. Started to get replication/duplication issues and gabled audio. Regressing to 1.0.0 resolved most the repeat issues, but not the garbled audio.Not sure how much of this is JMBE related... this P25 started acting funny around B6 and the 1.0.4 upgrades... but definitely noted the echo/replay problem on B8/1.0.4. However, even on 1.0.0, still get issues.No Problems on the z840 workstation with the other P25 systems - which are all C4FM and PI (0.4.0 + 1.0.4).
Does the problem system run on this setup? with no issues?
Checking.... there isn't a lot of traffic tonight :(... but from what I have heard in the last 15 mins running Westy on both systems, No Problem on the z840, get drops on the Mac.
Any changes in antenna hardware? coax? any storms for possible antenna/coax issues?
No. This is Denver... we have the weirdest weather and weather phenomenon in the country. Seriously. LOL. I do see this P-25 affected by weather sometimes... not the others. I never thought I would see moderate range skip in the 850 Mhz range... crazy.
Also since 0.4.0, new debug entry: 20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]Not seeing any L2 drops or sync drops - SNR is pretty good... no Channel Denies. MOST OF THE TIME the audio is fine, especially with 1.0.0. So it doesn't seem to be a PI v PII issue. Also the control channel doesn't drop or show any signs of issues.
I would record BITS files and submit for review.
BITS files? Weird... recorder config was set to MP3, but generated WAV.
Ocasionally I'll have issues when the tuners are on the edge of a control channel change... which I'm assuming is based on signal strength? Only one control channel is active at any given interval, but SDRT rotates between most of the six control channels over 24 hours.
CC rotation is at the whim of the settings of the controller...
It can be set to be ONE channel unless the base is taken down, fails etc..
It can be forced to rotate every x y period... could be 24 hours.. could be 20 minutes... Its actually really a better thing to do so.. hence why the EDACS system that is about to implode in my area has repeaters which are burnt to a crisp from being the CC for months if not years of use.. even if rated for 100% duty cycle
When SDRT looses sync if its setup for multiple CC's then it rotates after the fail period expires.
Ahhh... was wondering about that. OK, looks like these CCs rotate about 4-8 hrs. But not to ALL the control channel... seems to vary by site. Something seems very strange though... Talk channels REUSE existing idle CCs. Do the idle CC's become available as TCs? So the bottom line is I don't get new TCs.... I get new TCs using the existing idle CC Freqs... this must be a Simulcast feature I'm assuming.
Let me know what you need. the WAV files are huge for 5-10 minutes of recording of mostly dead air, so something doesn't seem right (2-4 GB?... that seems completely crazy)I suspect this is a one off P25 system with weird issues... not sure how much we want to invest in debugging.
If you get big recording files then its likely not getting the data to end the calls and lumping lots of traffic calls into ONE or more BIG files till it gets the right signal to stop..
OK... so the audio files are suppose to be generated per conversation? yeah that's definitely not happening.
DId you play these to see if its multiple calls????
I did not. There wouldn't have been more than one minute of total audio recorded during the 10-15 min window before it hung/OOM. So I assumed there was something seriously wrong with the files.
Run the BITS recording on the system for a while when this occurs and submit.
Not sure by what you mean with BITS recordings, but I have Audio Hijack Pro on the Mac available to record files... let me see what I can generate in the next coupe days.
I haven't given up on the z840 USB debugging for 4+ dongles, but I'm waiting for ubuntu 20.04 to become stable with the latest and greatest kernel and libvirt libs. I tried to enable SDRT in KVM to run multiple instances, but found that KVM completely trashed dongle SNR (noise went through the roof) ... which to be honest I can't explain (technically it should be a straight passthrough from the kernel). Which brought up an interesting question? Has anyone dockerized SDRT yet? It would be interesting to test direct USB driver access in dockers... and since you don't need networking, it should be pretty straight forward (just need to spec the USB devices in CLI for each instance).
Best, -Ron
Douglas Welch
Apr 21, 2020, 2:15:09 AM4/21/20
to sdrtrunk
could your echo be a regional channel broadcast on two channels. when ever police get in a chase here in my metro they patch the regular channel to a regional channel for all cities to hear and i hear both at same time.
real annoying but i can see why it happens. not sure it could be fixed in software anyway.
I use stereo setting so i hear two channels one on left speaker and one on right speaker
did you try to compile latest jmbe lib its at 1.0.4 now, 1.0.2 works good also
I dont record so it may not help.
Ron Benoit
Apr 21, 2020, 3:07:52 AM4/21/20
to sdrtrunk
OK... found the bits files settings... You need both Demod and Traffic Channel Demod?
Also, for some reason I'm not getting AMBE tones. Didn't mention it previously as tones are not that important to me... but if you were to debug, do you need CODEC frames as well?
Let me set this up on the z840 as well so you have something to compare (although it's going to be a lot of files)/
sdrtrunk
Apr 21, 2020, 4:52:14 AM4/21/20
to sdrtrunk
Ron,
Can you give the application more memory than 512MB? The CPU thrashing at the end is likely due to the max RAM constraint being applied. Java will hammer the CPU trying to do garbage collects as it runs out of memory.
>>> 20:21:31.445 DEBUG i.g.d.r.AudioRecordingManager - Audio Segment detected with NO TO identifiers [353MB/512MB 68%]
I added this log message when I redesigned the audio handling subsystem. This happens when there's a call that has audio, but no TO Talkgroups were attached to the audio segment. Could be a really short call, or a bad decode. The audio module will extract the audio frames all the time, but the decoder module may have thrown out the messages that carry the audio if there were CRC errors.
Regarding the Phase II AMBE tones ... do you have a way to check if tones are being sent? Maybe another scanner or application? If you know for certain that there should be audio tones in specific Phase II calls where JMBE didn't decode the tones, you can turn on the traffic channel .bits recording and send me the bits files and I'll figure out why it's not working.
cheers,
Denny
On Monday, April 20, 2020 at 11:28:48 PM UTC-4, Ron Benoit wrote:
Dean Sauer
Apr 21, 2020, 8:13:23 AM4/21/20
to sdrtrunk
Checking.... there isn't a lot of traffic tonight :(... but from what I have heard in the last 15 mins running Westy on both systems, No Problem on the z840, get drops on the Mac.
Record the BITS files on both at the same time if you can and submit to the dev so he can review and compare/contrast....
Any changes in antenna hardware? coax? any storms for possible antenna/coax issues?No. This is Denver... we have the weirdest weather and weather phenomenon in the country. Seriously. LOL. I do see this P-25 affected by weather sometimes... not the others. I never thought I would see moderate range skip in the 850 Mhz range... crazy.
Weather can do weird things... and 850Mhz skip is not uncommon.. sit in the right spot in the AM and a trunked site 50+ miles is commonly available and it will trunk quite nicely... same as will a system over 400+ miles away under the right conditions...
Ahhh... was wondering about that. OK, looks like these CCs rotate about 4-8 hrs. But not to ALL the control channel... seems to vary by site. Something seems very strange though... Talk channels REUSE existing idle CCs. Do the idle CC's become available as TCs? So the bottom line is I don't get new TCs.... I get new TCs using the existing idle CC Freqs... this must be a Simulcast feature I'm assuming
The idea behind trunking is to REUSE the SPARSE frequencies for calls...You will have 1 CC and x traffic channels. Actually you can do whats called in EDACS parlance a SCAT which is basically a SINGLE channel that acts as CC and voice channel... when a unit keys up the CC goes down and the channel isused for voice/data and then goes back to CC... P25 can do this too... it has another name....I unfortunately have just called any of these SCAT sites... AEP had a number of these in some very rural areas of their coverage since it was so lightly used for radio in these areas...
When a CC is rotated then it becomes just another channel for traffic grants or data calls.
Some system may rotate the CC more than others...even with solid state systems its really better to rotate...
Basically in EDACS any channel could potentially be the CC as the radios were and the protocol is to scan all for CC the infamous CC SCAN you will hear users complain about... when they are in a bad spot or it fails etc.. Thats actually what the radio will display "CC SCAN" till it locks up on one.. good bad or wrong. Motorolas system and P25 do similar in that its a defined setup for the CC Look at the details tab it will show what channels are potentially going to be used for the CC
SOME systems those channels MAY NEVER be used for anything BUT CC... thats an option.. I know of one that does this right now.. the channels listed for CC are CC only EXCEPT UNTIL LOADING reaches a point it needs them..
OK... so the audio files are suppose to be generated per conversation? yeah that's definitely not happening.
The recordings should be a match for each grant so it should not be one big huge file.
DId you play these to see if its multiple calls????I did not. There wouldn't have been more than one minute of total audio recorded during the 10-15 min window before it hung/OOM. So I assumed there was something seriously wrong with the files.
Did you play the big huge files it generated earlier??? I am betting its probably many many many calls all llumped into one...
I haven't given up on the z840 USB debugging for 4+ dongles, but I'm waiting for ubuntu 20.04 to become stable
Been on 20.04 since Jan... no issues for me.... I had to do testing for somethings which are about to get done.. new box build day is coming up... WOOT WOOT..
with the latest and greatest kernel and libvirt libs.
Ummm.. I think you will need to back port kernels from the HWE? repo to get the latest kernel. as ESR kernels are only shipped with ESR releases.. there was lots of whinning from some on a few groups about this.. so if you want 5.6? then you will need to pull that in from there as
I tried to enable SDRT in KVM to run multiple instances, but found that KVM completely trashed dongle SNR (noise went through the roof) ... which to be honest I can't explain (technically it should be a straight passthrough from the kernel).
Hmmmm.. yeah... that should definitely not be an issue in there v. something else...hmmmm...
Which brought up an interesting question? Has anyone dockerized SDRT yet? It would be interesting to test direct USB driver access in dockers... and since you don't need networking, it should be pretty straight forward (just need to spec the USB devices in CLI for each instance).
My work has been aimed at LXC for
rtl_airband mainly to it can be sent to a LXC in the background...
my own python setup combined with rtl_fm to do some decoding again goal to get it in the background more
OP25 was a candidate for this as well but with SDRT now having PII support that streams... I going to dump OP25, mostly for that side of things.. for some testing I do its nice live plot of things comes in handy.
SDRT would pose the issue of X11.. and I am not sure how much or what part of X11 provides JUST the X11 networking core to send X11 out the SSH connection or via XPRA...
The other issue is what you mention at the end the USB definitions.. I figure that some UDEV steps on the host to ensure that SDR x is assigned to /dev/bus/usb/00y each time... thats been my hold up as I am no UDEV guru.
I can get LXC to pass it or multiples through when they are defined in the config file, but if there were to be any change, while there shouldn't be its possible, then the mapping would be wrong and cause failures...
Its on my very very very very long list of stuff to work on....
I run SDRT via X11 forwarding but thats a fragile system should there be a glitch on the LAN and it will.would take SDRT down.. for some testing its fine.. thats where XPRA comes in but I've got some issues in re XPRA and testing it.. right now.
Ron Benoit
Apr 21, 2020, 10:09:57 AM4/21/20
to sdrtrunk
On Tuesday, April 21, 2020 at 6:13:23 AM UTC-6, Dean Sauer wrote:
Checking.... there isn't a lot of traffic tonight :(... but from what I have heard in the last 15 mins running Westy on both systems, No Problem on the z840, get drops on the Mac.
Record the BITS files on both at the same time if you can and submit to the dev so he can review and compare/contrast....
It's going to be tricky because this is intermittent on the Mac.... and yeah, I see files being created like crazy... so it's going to take some time to review all the files and find meaningful matches.... (I went to bed and just let things record).
Ahhh... was wondering about that. OK, looks like these CCs rotate about 4-8 hrs. But not to ALL the control channel... seems to vary by site. Something seems very strange though... Talk channels REUSE existing idle CCs. Do the idle CC's become available as TCs? So the bottom line is I don't get new TCs.... I get new TCs using the existing idle CC Freqs... this must be a Simulcast feature I'm assuming
The idea behind trunking is to REUSE the SPARSE frequencies for calls...You will have 1 CC and x traffic channels. Actually you can do whats called in EDACS parlance a SCAT which is basically a SINGLE channel that acts as CC and voice channel... when a unit keys up the CC goes down and the channel isused for voice/data and then goes back to CC... P25 can do this too... it has another name....I unfortunately have just called any of these SCAT sites... AEP had a number of these in some very rural areas of their coverage since it was so lightly used for radio in these areas...
When a CC is rotated then it becomes just another channel for traffic grants or data calls.
Some system may rotate the CC more than others...even with solid state systems its really better to rotate...
Basically in EDACS any channel could potentially be the CC as the radios were and the protocol is to scan all for CC the infamous CC SCAN you will hear users complain about... when they are in a bad spot or it fails etc.. Thats actually what the radio will display "CC SCAN" till it locks up on one.. good bad or wrong. Motorolas system and P25 do similar in that its a defined setup for the CC Look at the details tab it will show what channels are potentially going to be used for the CC
SOME systems those channels MAY NEVER be used for anything BUT CC... thats an option.. I know of one that does this right now.. the channels listed for CC are CC only EXCEPT UNTIL LOADING reaches a point it needs them..
Makes sense... understand trunking ok... just wasn't expecting static CC's to be reused, especially over so much spectrum (11 Mhz between lowest and highest CC). Looks like different sites are showing different PRI/SEC combos for Westy.
I haven't given up on the z840 USB debugging for 4+ dongles, but I'm waiting for ubuntu 20.04 to become stable
Been on 20.04 since Jan... no issues for me.... I had to do testing for somethings which are about to get done.. new box build day is coming up... WOOT WOOT..
with the latest and greatest kernel and libvirt libs.
Ummm.. I think you will need to back port kernels from the HWE? repo to get the latest kernel. as ESR kernels are only shipped with ESR releases.. there was lots of whinning from some on a few groups about this.. so if you want 5.6? then you will need to pull that in from there as
Sorry, should watch my wording. Not the bleeding edge version of the kernel... just the next big stable release... This is my production firewall, DNS, host server... I don't try to screw with it much outside of security patches.
I tried to enable SDRT in KVM to run multiple instances, but found that KVM completely trashed dongle SNR (noise went through the roof) ... which to be honest I can't explain (technically it should be a straight passthrough from the kernel).
Hmmmm.. yeah... that should definitely not be an issue in there v. something else...hmmmm...
Yeah that really surprised me. Still thinking about it. My waterfall display for the other P25 systems is crystal clear... very strong SNR... went to complete crap with KVM. Really blew away my idea of testing KVM with 6 dongles :(
Which brought up an interesting question? Has anyone dockerized SDRT yet? It would be interesting to test direct USB driver access in dockers... and since you don't need networking, it should be pretty straight forward (just need to spec the USB devices in CLI for each instance).
My work has been aimed at LXC for
rtl_airband mainly to it can be sent to a LXC in the background...
my own python setup combined with rtl_fm to do some decoding again goal to get it in the background more
OP25 was a candidate for this as well but with SDRT now having PII support that streams... I going to dump OP25, mostly for that side of things.. for some testing I do its nice live plot of things comes in handy.
SDRT would pose the issue of X11.. and I am not sure how much or what part of X11 provides JUST the X11 networking core to send X11 out the SSH connection or via XPRA...
The other issue is what you mention at the end the USB definitions.. I figure that some UDEV steps on the host to ensure that SDR x is assigned to /dev/bus/usb/00y each time... thats been my hold up as I am no UDEV guru.
I can get LXC to pass it or multiples through when they are defined in the config file, but if there were to be any change, while there shouldn't be its possible, then the mapping would be wrong and cause failures...
Its on my very very very very long list of stuff to work on....
I run SDRT via X11 forwarding but thats a fragile system should there be a glitch on the LAN and it will.would take SDRT down.. for some testing its fine.. thats where XPRA comes in but I've got some issues in re XPRA and testing it.. right now.
Excellent! I DID try using X11 and it did work... but the bandwidth usage of the waterfall bitmap pushes the local net to 600Mb... seems to work fine w/o waterfall. UDEVs shouldn't be a problem in static configs, but yeah, will be if folks move the dongles. it's gets worse by OS/tool versions... so I'm not sure it's worth the Python code to try to parse lsusb or other tools to create/move the UDEV files. I think manual UDEV work isn't that big a request for users if they plan to use LXD. I don't need X11 functionality... god no... won't be doing things like displaying on one system, playing on another. The z840 is set-up as both a workstation and server (which is why I don't use VMware on this host). I'm not sure you really want to get into X11... it's a beast.
FYI... I did find WMI driver errors for the dongles when they are loaded. This seems to be an HP BIOS issue, with others reporting the same error on HP HW. The WMI (Windows Management Interface) errors should not affect the dongle functionality... it's just probing to see if they have the functionality... Otherwise, the kernel seems to be fine with the dongles.
Busy day today, so it might be a bit on those files. Best, -Ron
Dean Sauer
Apr 21, 2020, 12:18:55 PM4/21/20
to sdrtrunk
It's going to be tricky because this is intermittent on the Mac.... and yeah, I see files being created like crazy... so it's going to take some time to review all the files and find meaningful matches.... (I went to bed and just let things record).
ZIP up the files into GOOD WORKING system no issues and another from the MAC with the issues.. to see what the problem is.. but if its working ON ONE BOX but NOT on another... that points to:
1) RF differences between the setups?
2) Box issues???? OS or something that causes an issue???
Ahhh... was wondering about that. OK, looks like these CCs rotate about 4-8 hrs. But not to ALL the controlneeds them..
Makes sense... understand trunking ok... just wasn't expecting static CC's to be reused, especially over so much spectrum (11 Mhz between lowest and highest CC). Looks like different sites are showing different PRI/SEC combos for Westy.
Theres lots and lots foibles to this...The reason stuff is spread out is because of Rebanding.. nexhell was kicked out of the band to their own pollution zone aka the CSMR from 862-869.. the same holds true for the SouthernLINC system which is a mixed use public like nexhell was and Southern Corp the electric company to use for their radios.. as iDEN aka nexhell is err was basically trunking with phone patch in simpler to use format...
So now PS LMR is basically between 851-861, 861-862 is a guard band which you can ELECT to have a channel in ... 862-869 is the CSMR band which is basically limited to Sprint and Southern and it gets complicated in the Southern CSMR to co-ordrinate I am not sure how SL and Spinrt/Tmetro or what ever their name is today are dealing with this.. and how SL customers who wanted/needed to keep PTT worked out.. SL was/is/did convert to LTE and there are ways of doing PTT like stuff there.. I am not sure what SL did/doing in regards to their own PTT needs over that... My understanding was they moved to LTE for all of it.. Ericcson was doing this... I know that not being able to hear local utilities would PO me quite quickly as I like to know what they are up to! Especially my yokles but most have been locked out of Alabama Power etc for decades.. LTE also lets them move their smart meters etc. to one network etc.. Think of it as sort of FirstNet type thing....
There are some other quirks to the way PS was moved around.. and depending on spectrum needs in that region.. There are still SMR systems like LTR, etc. in some areas that occupy parts of the 850Mhz spectrum but they are NOT PERMITTED to utilize CDMA, LTE cellularized type systems it has to go BACK TO THE ORIGINAL SMR setups ie: LTR or similar trunking tech. .
sSorry, should watch my wording. Not the bleeding edge version of the kernel... just the next big stable release... This is my production firewall, DNS, host server... I don't try to screw with it much outside of security patches.
The *buntus are using the 5.4.x branch which is considered ESR and thats their rules.. I think mines at 5.4.0.18?? or something.. I need to update now that the beta is out ... I don't follow along on kernels unless there is an issue for CPU's I use.. which by using the 5.4 on the very newish laptop I gifted myself... avoids issues that have shown up in 5.6... That one of the reasons I am never in too much of a rush to get the latest greatest new hotness on CPU's etc..
Yeah that really surprised me. Still thinking about it. My waterfall display for the other P25 systems is crystal clear... very strong SNR... went to complete crap with KVM. Really blew away my idea of testing KVM with 6 dongles :(
Wonder if this has something to do with USB under KVM and might be a path to some underlying issues in the Great USB Issue hunt???
Never really tried KVM.. ESXi, and sadly I don't have a box with that I can play with right now its all in use with suff I am not touching.. no how no way... LXC.. I already know that vbox can barely run a USB printer let alone SDR.. VMWare Player does bettter but its not up to it either...
Which brought up an interesting question? Has anyone dockerized SDRT yet? It would be interesting to test direct USB driver access in dockers... and since you don't need networking, it should be pretty straight forward (just need to spec the USB devices in CLI for each instance).
My work has been aimed at LXC for
rtl_airband mainly to it can be sent to a LXC in the background...
my own python setup combined with rtl_fm to do some decoding again goal to get it in the background more
OP25 was a candidate for this as well but with SDRT now having PII support that streams... I going to dump OP25, mostly for that side of things.. for some testing I do its nice live plot of things comes in handy.
SDRT would pose the issue of X11.. and I am not sure how much or what part of X11 provides JUST the X11 networking core to send X11 out the SSH connection or via XPRA...
The other issue is what you mention at the end the USB definitions.. I figure that some UDEV steps on the host to ensure that SDR x is assigned to /dev/bus/usb/00y each time... thats been my hold up as I am no UDEV guru.
I can get LXC to pass it or multiples through when they are defined in the config file, but if there were to be any change, while there shouldn't be its possible, then the mapping would be wrong and cause failures...
Its on my very very very very long list of stuff to work on....
I run SDRT via X11 forwarding but thats a fragile system should there be a glitch on the LAN and it will.would take SDRT down.. for some testing its fine.. thats where XPRA comes in but I've got some issues in re XPRA and testing it.. right now.Excellent! I DID try using X11 and it did work... but the bandwidth usage of the waterfall bitmap pushes the local net to 600Mb... seems to work fine w/o waterfall.
I must be the only person on the planet who immediately disables that waterfall/spectrum.. Time and place for it.. once I turn a box loose on a system.. no need for it.. I guess others like the pretty squiggles.. I guess I am just to set in my ways to get it.. time and place then .. disabled.... its a CPU hog and BW on the LAN as you found out...
UDEVs shouldn't be a problem in static configs, but yeah, will be if folks move the dongles. it's gets worse by OS/tool versions... so I'm not sure it's worth the Python code to try to parse lsusb or other tools to create/move the UDEV files.
If you get the things on plugged in and then the box is on a UPS (all mine are) then its not an issue... as like I said once you've got them set... BUT I would want a way that should something happen and a reboot was needed manually or something happened to require it that the box would recover on its own with out me involved.. My NWR Pi recovers on its own should the rtl_fm process fail, whatever..
I think manual UDEV work isn't that big a request for users if they plan to use LXC.
My issue is creating the UDEX rules period.. I know what to add to the LXC config.. but getting something that would ensure whats in there matches what the device gets given in the event of a reboot or something.
I work only with LXC.. LXD makes changes to things.... and does things a little different.. things I don't like...to me seems like splitting work again it has some nice add ons if you need them like moving a container.. but the cons on some things to me outweigh something I might use 1 if ever.
I don't need X11 functionality... god no... won't be doing things like displaying on one system, playing on another.
I do.. Thats pretty much how 98% of my systems are setup... this session right now is on a box nowhere near me.
I can XDMCPSSH my box and work like I was sitting at it... home or away... and most of the stuff except my main system is headless.
The z840 is set-up as both a workstation and server (which is why I don't use VMware on this host). I'm not sure you really want to get into X11... it's a beast.
I don't think you need all of X11 to do the forwarding..I've reviewed some setups for this in LXC running other GUI stuff.. and its a couple of libs to do it. the base X11 setup... not that much.. but using XPRA as its name sake screen for X11 may add a lot of overhead.. we'll see..
Ron Benoit
Apr 21, 2020, 2:25:12 PM4/21/20
to sdrtrunk
Hey Dean, upon looking at the issues on the Mac with the Westy P25, let's drop this issue and consider it closed:
1). No Problems on the z840 with Westy, so I'll just run Westy on the Z840, and State of Colorado DTRS and FRCC P25 systems on the Mac. Really need to spend a few hrs to see if I can get one of these configs onto the Rasp Pi 3B (need and extra pair of ext speakers). This is an intermittent issue on the Mac, so I don't think it's a AMBE or SDRT bug... except for the missing tones, which isn't a big deal (to me). (we can open a separate thread to track this is you want, but it's way down the bucket list and this is just one small municipal P25 system).
2). The z840 has the PCI USB 3.1 powered card... dongles straight into the card.. so the SNR is great. Both Mac and z840 are using the same length coax and same 800 Mhz antennas and basically the same dongles. But the Mac is using a powered USB3 hub with a lengthy cable... doesn't have the same SNR as the z840, but it's not that bad and the C4FM systems seem to do OK.
3). There might be a bug in how I set up recordings initially. I didn't use the recording tab. I hit the "record" button in the "tuner" tab. I thought this would default to MP3 (it was set to MP3 in prefs). It generated the WAV files and the OOM/hangs. So you may have some debugging with the "record" button in the tuner tab. I didn't have any issues when enabling bits decoding in the recording tab.
4). I'll let you spend some time on more pressing and actual issues while I spend some time on my end. Keep up the great work!
On a Personal Note... you should be teaching undergraduate and graduate classes in Public Service Radio history, theory, and policy... as well as Public Safety Systems radio engineering... your background and expertise is extremely difficult to find and pass on. Any good college should be delighted to have someone with your background and expertise on faculty. Where's the book Dean... where's the book? You know if you grab a few undergrad and grad students, you could have a thousand moving feet to help out with design and testing of a number of projects I know you care about (open source hardware/sw). I used to know a number of EE Docs/Nerds at CU-Boulder that I could see get really excited about the possibilities. Boulder/Denver got a hell of a lot of hardware comm tech nerds... probably the highest concentration in the country (this is not an exaggeration... just take a look at a map of the top government research labs, telecom/satellite providers, academic research, military contractor, and strategic military installations). I would think there would be a couple dozen or so that would go giddy over the opportunity to reshape Public Safety radio in the US to make it cheap, easy, interchangeable, self-healing, secure, and reliable. It seems like a good time for a wave of disruption in this long battle of Public Safety radio fiefdoms (of course we need to revamp the FCC... but that's another issue altogether).
The work already done in SDR is remarkable... kudos to all of you for tackling the hurdles and getting highly functional free SW into the hands of the average Joe who may be enlightened (or dishearten) to find out how public safety systems work and the dedication of the people trying to keep them healthy and safe (and get some radio engineering lessons in the process). I'm hoping it's a real boom to rural area volunteer agencies as far as recruitment, funding, and addressing the expenses and inadequacies of current systems. Open Source should allow for a technical solution... it doesn't necessarily eliminate the upper layers of the stack - Economics, Politics, and Religion, but it will greatly help with the educational impact.
Best, -Ron
Dean Sauer
Apr 21, 2020, 6:00:51 PM4/21/20
to sdrtrunk
On Tuesday, April 21, 2020 at 2:25:12 PM UTC-4, Ron Benoit wrote:
Hey Dean, upon looking at the issues on the Mac with the Westy P25, let's drop this issue and consider it closed:1). No Problems on the z840 with Westy, so I'll just run Westy on the Z840, and State of Colorado DTRS and FRCC P25 systems on the Mac. Really need to spend a few hrs to see if I can get one of these configs onto the Rasp Pi 3B (need and extra pair of ext speakers). This is an intermittent issue on the Mac, so I don't think it's a AMBE or SDRT bug...
My gut was thinking it was something between hardware especially when one box would do one thing and another does something else.. been there done that on many a things.. including SDRT with the Harris system... I basically rebuilt everything form antenna down to the dongle to ensure that PROPER SIGNAL was available.
except for the missing tones, which isn't a big deal (to me). (we can open a separate thread to track this is you want, but it's way down the bucket list and this is just one small municipal P25 system).
I would send a bug report to the dev on the tones.. do you know what they are from something else that you can hear them on???
I know DTMF and QCII on P25 are coming out .. as the PII FD is spitting them out on SDRT...
Hmm.. need to run a test on the after hours alerting on the other department as they use an alert tone on it... and
I think there might be an issue with the alert warble that is used in certain high priority multi station responses... I am trying to track that down...
On a Personal Note... you should be teaching undergraduate and graduate classes in Public Service Radio history, theory, and policy... as well as Public Safety Systems radio engineering... your background and expertise is extremely difficult to find and pass on.
I don't know about that.. I learned all this the hard way.. REAL LIFE.. and from having to to deal with agencies across many jurisdictions and states, counties etc.. that brings a harsh reality to things.. that while there are many many similarities to the way things are done there are just as many differences.. Look at LASO the way they dispatch and the radio procedure alone drive me batty... floating dispatchers on channels.. OH absolutely not! NEVER EVER! No way you get people who know the ins and outs of a 8000sq mile county! NO WAY! And I got news for 99% of the public the BS you see on shows like 9-1-1 even in LA is absolute total BS! Totally kooklyweirodwood!
I think Denny does an excellent, no ausgezeichnet job... (there is just not a good enough English word fo describe it) job with this software.. I was never into the FFT stuff.. When I started on this journey DSP's had just become sort of main stream for stuff..some modems were using them,as they filtered down from defense industries... and was used as part of my senior EE project.. .I am glad to contribute testing and insight into the radio systems to help this for all. And I get the benefit from it... a ausgezeichnet program to stream and watch over systems.. It really compares quite nicely to SIteLens for some things.. if in the future some other logging etc. is added it could probably give that $30K per license software a run for it!
I;ve got the wounds physically, mentally, and career wise for those who didn't want to heed and learn on things.. some things are not going to change in the way PS radio works.. and one of those is PTT.. its a safety issue... Period.. I know several areas which do silent dispatching to thwart the public.. They put THEIR OWN IN JEOPARDY by doing this! Thats why you VOICE CALLS! They also FORGET who the BOSS IS! The PUBLIC IS THE BOSS! Now there are some who want to abuse that which is another debate, rant, tirade... But all too many forget who PAYS the BILLS and ** SALARIES ***!!!
Data has made PS units regardless of types a lot more effective... For many on this list they have no idea about what a biophone is.. now days its done mostly on cellularized data... No idea of the HEAR channel is nor the SECODE alerting used... there are remants in my area of some of that and the numbering.. if if you know it. :)
As older V/UHF systems are retired and upgraded alot of the functions disappear ie: SECODE went to CTCSS for each hospital... or maybe DTMF.. or went to a TG for each... some its just a FREE FOR ALL TG.. I won't mention any names on who is doing just a FUSTER CLUCK!...
Radio can play a vital integral part and it can be just as integral of a failure too! We had that... recently lots of compounding factors.. radio played its part... over reliance on data versus VERBAL ANNOUNCEMENTS.. Even the "audit/investigations" report missed on some of the ways that this failure resulted and suggesting MORE USE OF DATA ie: POCSAG PAGERS for updates versus VERBAL ANNOUNCEMENTS! You can't read no flipping pager in a TURNOUT GEAR!
Ron Benoit
Apr 21, 2020, 7:58:01 PM4/21/20
to sdrtrunk
On Tuesday, April 21, 2020 at 4:00:51 PM UTC-6, Dean Sauer wrote:
On Tuesday, April 21, 2020 at 2:25:12 PM UTC-4, Ron Benoit wrote:Hey Dean, upon looking at the issues on the Mac with the Westy P25, let's drop this issue and consider it closed:1). No Problems on the z840 with Westy, so I'll just run Westy on the Z840, and State of Colorado DTRS and FRCC P25 systems on the Mac. Really need to spend a few hrs to see if I can get one of these configs onto the Rasp Pi 3B (need and extra pair of ext speakers). This is an intermittent issue on the Mac, so I don't think it's a AMBE or SDRT bug...
My gut was thinking it was something between hardware especially when one box would do one thing and another does something else.. been there done that on many a things.. including SDRT with the Harris system... I basically rebuilt everything form antenna down to the dongle to ensure that PROPER SIGNAL was available.
Yeah I know how diligent you are on the basics... I'm a firm believer as well. Of course, just as I was think this was a HW diff/issue, I started to see the same problems on the z840.
So basically the same issues for Westy:
1). No Tones - Not sure what they are using, not hearing a thing. Whatever they are, they appear to take some time... like 8-10 secs for single station. (based on "standby for tones" and actual dispatcher info). I'm assuming they are adding a warble at the end. I hate the use of "standby tones" on relatively slow channel - just another waste of time. But the tones seem long. Same issue on both Mac and z840.
2). Replication - rare but does occur. Affects both dispatch and field units. Seems to occur near CC changes.
3) Stereo Channel - same units coming out both speakers at the same time. Resolved by placing into Mono mode, but then I loose dual channel capabilities.
4) Garble - very rare on the z840, so probably related some HW diffs/signal issues and possibly weather.
I'll set-up mbe files for Westy... which mbe files do you need? A little of a bitch as I have to set-up on at least 4 channels.
except for the missing tones, which isn't a big deal (to me). (we can open a separate thread to track this is you want, but it's way down the bucket list and this is just one small municipal P25 system).
I would send a bug report to the dev on the tones.. do you know what they are from something else that you can hear them on???
I know DTMF and QCII on P25 are coming out .. as the PII FD is spitting them out on SDRT...
Hmm.. need to run a test on the after hours alerting on the other department as they use an alert tone on it... and
I think there might be an issue with the alert warble that is used in certain high priority multi station responses... I am trying to track that down...On a Personal Note... you should be teaching undergraduate and graduate classes in Public Service Radio history, theory, and policy... as well as Public Safety Systems radio engineering... your background and expertise is extremely difficult to find and pass on.
I don't know about that.. I learned all this the hard way.. REAL LIFE.. and from having to to deal with agencies across many jurisdictions and states, counties etc.. that brings a harsh reality to things.. that while there are many many similarities to the way things are done there are just as many differences.. Look at LASO the way they dispatch and the radio procedure alone drive me batty... floating dispatchers on channels.. OH absolutely not! NEVER EVER! No way you get people who know the ins and outs of a 8000sq mile county! NO WAY! And I got news for 99% of the public the BS you see on shows like 9-1-1 even in LA is absolute total BS! Totally kooklyweirodwood!
Yeh but that's why you need to pass on all that practical experience. Dean's Book on How Not to Build an major metro PSAP environment! Schools of Public Policy, Public Safety, EMS and Fire, Disaster... teaching the future leaders (even EE programs) need to hear about these issues... or better yet, how to do it optimally. This is how we finally got EMD adopted in most places, and even System Status Management... it came through training and education pipelines. Folks aren't going to change things if they don't know they are broken, or that there is a better way of doing it. As part of my undergrad at UMBC, we had to write statewide EMS plans, featuring details on all 15 components... including statewide 9-1-1 (all funded by NHTSA/EMS and DOT 401/402 funds), PSAPS, and Statewide Public Safety Radio Communications Systems. Luckily, we had experienced, seasoned adjunct faculty deeply familiar with the issues and roadblocks of building statewide and national systems (usually the original designs and builders themselves, even the original fed and state legislators and admins from the 70's) that prepared your future local and state admins. Unfortunately... getting a good course in PSAP/radio network design wasn't readily available (we didn't have an EE program at the time)... one thing missing in the curriculum. You could fill a very important need in that area throughout the country.
I think Denny does an excellent, no ausgezeichnet job... (there is just not a good enough English word fo describe it) job with this software.. I was never into the FFT stuff.. When I started on this journey DSP's had just become sort of main stream for stuff..some modems were using them,as they filtered down from defense industries... and was used as part of my senior EE project.. .I am glad to contribute testing and insight into the radio systems to help this for all. And I get the benefit from it... a ausgezeichnet program to stream and watch over systems.. It really compares quite nicely to SIteLens for some things.. if in the future some other logging etc. is added it could probably give that $30K per license software a run for it!
Sounds like a plan. There are many examples of individuals pushing their pet projects to become policy... or at least defacto standards.
I;ve got the wounds physically, mentally, and career wise for those who didn't want to heed and learn on things.. some things are not going to change in the way PS radio works.. and one of those is PTT.. its a safety issue... Period.. I know several areas which do silent dispatching to thwart the public.. They put THEIR OWN IN JEOPARDY by doing this! Thats why you VOICE CALLS! They also FORGET who the BOSS IS! The PUBLIC IS THE BOSS! Now there are some who want to abuse that which is another debate, rant, tirade... But all too many forget who PAYS the BILLS and ** SALARIES ***!!!
I'm willing to bet I have more arrows that you :). Yeah, paying the price seems to come with the territory with the passionate ones... most of whom have burned out, but you still seem to have a good amount of passion left!
Data has made PS units regardless of types a lot more effective... For many on this list they have no idea about what a biophone is.. now days its done mostly on cellularized data... No idea of the HEAR channel is nor the SECODE alerting used... there are remants in my area of some of that and the numbering.. if if you know it. :)
Oh Yeah, HEAR still operates in Boulder County (it's on Broadcastify) and I definitely remember SECODE from my days. Albeit I'm not sure where things stand in the area on Amateur Radio... seems to have lost a lot of momentum since the Internet went commercial and outside of the old-timers still running on Healthkit tube sets (ok... some digital), not sure what the future it has in store. I rarely see mobile 10m rigs, and finding a 40 or 80m in backyards or towers seems to be getting rarer (even though I have a neighbor on the corner with both).... haven't had any RFI so I'm grateful.
As older V/UHF systems are retired and upgraded alot of the functions disappear ie: SECODE went to CTCSS for each hospital... or maybe DTMF.. or went to a TG for each... some its just a FREE FOR ALL TG.. I won't mention any names on who is doing just a FUSTER CLUCK!...
Radio can play a vital integral part and it can be just as integral of a failure too! We had that... recently lots of compounding factors.. radio played its part... over reliance on data versus VERBAL ANNOUNCEMENTS.. Even the "audit/investigations" report missed on some of the ways that this failure resulted and suggesting MORE USE OF DATA ie: POCSAG PAGERS for updates versus VERBAL ANNOUNCEMENTS! You can't read no flipping pager in a TURNOUT GEAR!
TG are like public IPv4 IP addresses, you can never get enough, and if they become available (and you don't necessarily need them), you grab them anyway. This is human behavior. (think toilet paper).
See this is what I mean... you won't find any kick back from me, I agree with you completely. BUT, these are the type of things that need to be articulated and but down as best common practices someplace. Until they are, they are not BCP! Yeah the public will digest whatever it is fed, and unfortunately TV in the last 30 years has really messed up their perspective.... yeah it's hard to believe that most people actually believe that crap is real.
Maybe you could entice Last Week Tonight with John Oliver to do a piece on "PSAPs: the Hidden Killer in our Modern Society".... hey, even Front Line might be interested if you have good stories and hard facts.... albeit they are a bit tied up with T these days.
Hang in there. -Ron
sdrtrunk
Apr 23, 2020, 2:08:38 AM4/23/20
to sdrtrunk
Ron, if you record the traffic channel .bits files for a period when you know this tone is being transmitted but not being heard and zip them up and send. I have a script that will run through all of them and tell me which ones have tones in them.
Denny
Ron Benoit
Apr 23, 2020, 7:07:21 AM4/23/20
to sdrtrunk
Hi Denny,
Sorry about the number. There should definitely be tone outs in these files... someplace. But unfortunately there was a call drought for a few hours, and then CC rotations (6 channels)... so it's like whack a mole on capturing these things. Also on one of those files at 22:41 hrs there was a repeat event (duplicate) for one word at the end of the transmission. The repeat issue is new... and very rare. Only happens on this P25 system.... and on both the z840 and Mac. It could be RF, but in two years of listening, have never heard it before.
having problems with WAV files as well. For some reason only big giant wav files are being created (Linux), and they don't have audible transcripts... just what sounds like carrier.
Thanks! -Ron
sdrtrunk
Apr 24, 2020, 4:30:08 AM4/24/20
to sdrtrunk
Ron,
I downloaded the file and the .bits recordings are all from Phase 1 decoder. I'll try to look at these this weekend, but the weekend hopper might be full.
Regarding the tone outs issue ... the files you sent are all Phase 1.bits recordings. Phase 1 uses the IMBE vocoder which doesn't have specific tone support. IMBE just encodes the tones as voice. Phase II AMBE vocoder is the one that has support for encoded tones and those get generated differently than normal voice frames.
Denny
Ron Benoit
Apr 24, 2020, 12:14:58 PM4/24/20
to sdrtrunk
Sorry about the waste of time Denny. Let's close out this issue. Thanks again for looking into this. Best, -Ron
Reply all
Reply to author
Forward
0 new messages