I should have clarified that I was speaking of colloquialisms and the terminology is not technically correct.
NXDN One Frequency vs Conventional NXDN Programming
- Thread starter werinshades
- Start date
- Status
VE2ZPS
Member
Mr. Upman,
I reiterate my question with the outmost respect for you and for uniden,
- Does Uniden is planning to work on fixing this issue ? (and is it fixable) ?
If the answer is negative, I will simply get rid of the SDS100-SDS200 and return to my two 536 and get another 436
I reiterate my question with the outmost respect for you and for uniden,
- Does Uniden is planning to work on fixing this issue ? (and is it fixable) ?
If the answer is negative, I will simply get rid of the SDS100-SDS200 and return to my two 536 and get another 436
Right now, we have nothing to work on. The one log that was provided had a very weak signal. The receiver in the SDS200 is radically different than other scanners, and variability in performance is going to be most noted when the primary signal is very weak (as in the case logged). Under those conditions, sometimes it might be better, sometimes it might be worse. Same is true of any two receivers. Strong signal, both work well. Weak signal, one might be better or worse than the other, randomly.
Can you get logs using the SDS and BCDx36HP side by side? These use the same methods/code for these functions, so it is unusual that they would have different results.
Last edited by a moderator:
My 536hp file #2 was running simultaneously with the SDS 200 if it helps.
VE2ZPS
Member
So you want lots of videos demonstrating simultaneously the 536 and 200 (as I did in the short example on youtube below) ?
If so I can provide hours if it will help
. Debug files?
Video is nice, but debug file is needed for engineering review. Even video isn't quite useful, as it does not show RSSI, Noise, Frequency, or D-Error.
SDS200 RSSI was too low for reliable reception was all we could tell from it.
I'm confused though. I was receiving the transmissions on the 536hp and the SDS200 was also receiving them but intermittently. It was receiving reliable enough to receive and decode? Did you review the 536hp file? Both were receiving it on #2.
I don't have the tools to review log files. Engineering reviewed them. If the signal is weak, sometimes it will work and sometimes it won't.
Ok..it appears they reviewed log file #2 on the SDS200, saw the signal was weak (it isn't very strong, it's a 20 watt NXDN system 1 mile away), but both files were recorded simultaneously and the 536 was receiving and decoding it. I'm assuming they stopped after seeing signal strength and didn't review both files in their entirety?
VE2ZPS
Member
Both 200 and 536 are on debug files on the same systems -
The majority of these services are small-medium size fire dept so I will leave them long enough to have a variety of transmissions samples
VE2ZPS
Member
My debug files will come next week;
My 20 DMR/NXDN Test subjects are Fire department and when there's no fire; ... they dont talk much.
But many of them also use it for Public Works so I should be able to obtain more transmissions during the week. (unless major fire)
I could leave them on for days but I guess my Debug Files would be huge (even without much transmission)
My 20 DMR/NXDN Test subjects are Fire department and when there's no fire; ... they dont talk much.
But many of them also use it for Public Works so I should be able to obtain more transmissions during the week. (unless major fire)
I could leave them on for days but I guess my Debug Files would be huge (even without much transmission)
VE2ZPS
Member
My understanding is to the effect that as soon as we activate the "Debug Log to SD Card" function, it becomes impossible to track the number of hits with Proscan (both using WiFi or with the Cable) and the recording function ai also desactivated.
Therefore we submit Debug File for analysis without knowing the number of transmissions that were missed by the SDS200.
Can someone confirm please ?
In the meantime, here's my log from this morning, we can clearly see what was missed by the SDS200
.
Therefore we submit Debug File for analysis without knowing the number of transmissions that were missed by the SDS200.
Can someone confirm please ?
In the meantime, here's my log from this morning, we can clearly see what was missed by the SDS200
.
Last edited:
What I find interesting is under the NXDN TGID it doesn't show one but in the couple one channel NXDN systems I monitor, it comes up TGID 0. One of my earlier posts I was wondering if that's the issue...scanners were inconsistently ignoring TGID 0?
VE2ZPS
Member
Hi Werinshades,
The problem is not related to the signal; these transmissions are all from the same systems on both machine
This morning only, there are 723 transmissions missing on the SDS200 (57%)
BCD536: 1276 transmission
SDS200: 553 transmission
The problem is not related to the signal; these transmissions are all from the same systems on both machine
This morning only, there are 723 transmissions missing on the SDS200 (57%)
BCD536: 1276 transmission
SDS200: 553 transmission
I did see that, and very low RSSI. What I mean is TGID is 0 on one channel NXDN systems.
VE2ZPS
Member
Hi Upman,
Considering the nature of the services on my Single Frequencies, I was preparing long Debug Files but since I have already heard many transmissions on the 536 that were not captured by the SDS200 (on systems 22.02 and 23.04), I will start with these preliminary Debug Files (more to come)
They are simultaneously extracted from the 536 and 200.
BCD536: http://www.scanningteam.net/DebugFiles/190307DF536.zip
SDS200: http://www.scanningteam.net/DebugFiles/190307DF200.zip
Considering the nature of the services on my Single Frequencies, I was preparing long Debug Files but since I have already heard many transmissions on the 536 that were not captured by the SDS200 (on systems 22.02 and 23.04), I will start with these preliminary Debug Files (more to come)
They are simultaneously extracted from the 536 and 200.
BCD536: http://www.scanningteam.net/DebugFiles/190307DF536.zip
SDS200: http://www.scanningteam.net/DebugFiles/190307DF200.zip
- Status
Similar threads
SDS100/SDS200:
SDS100 DMR System will only decode private calls.
