Ubbe
Member
1098 have probably other values for the squelch than TRX-2. The 8 on TRX-2 are normally the lowest setting that closes squelch after it has opened.
/Ubbe
/Ubbe
The 8 squelch will probably receive signals too noisy to be decoded and will hesitate on that CC too long until it will continue to scan.
First check that you can successfully decode the signal while entering the voice channel manually to monitor it stationary. If that works you can then adjust parameters for scanning.
The dwell time depend on how many control channels you have in the system. I would recommend 0.3 sec per CC that you can hear at one time. If you hear 3 CC then use 1 sec, if you hear 6 CC then use 2 sec.
If the system doesn't use, or rarely use, the slot 2 on the CC I recommend that you remove the CC frequencies. TRX uses dwell time per system, not per site as 536, so it depends on how many simultaneous carriers with DMR signalling you scan and how many TGs you lock out. If you monitor all TGs then the default 1 sec will be more than sufficient. If you lock out a lot of TGs and only monitor a couple, then you need to calculate how many simultaneous active voice channels you can receive and multiply with 0.3 sec and if the system often gets fully loaded with voice traffic then you also need to have the CC channels in scan and must also consider 0.3 sec per CC.
For testing purposes you can easily try a 5 sec dwell time just to be sure that you do not have a dwell problem. But as I have mentioned, check that you can monitor the voice channel manually that the 536 uses when you do not get anything when the TRX are scanning.
/Ubbe
It shows that T during the delay period for the systems TG, not your scanners. It indicates that the TRX hit that frequency between PTTs and will probably be solved by using a longer dwell time.
If it skipped the frequency while someone where talking then you could try and enter the voice channels 3 times after each other in that site. It will give the TRX 3 times longer time to try and decode the signal.
Do both things and if it works then do only one thing to see what was most effective and then try and reduce dwell time and number of duplicate frequencies to find the most effective way to scan the system.
TRX doesn't care what type of DMR system it is, it just scans all voice channels you have programmed for active calls and when one users let go of his PTT the TRX scans all channels you have programmed in the system for that TG to appear again during the scanners delay time and when the timer runs out it continues to scan other systems.
/Ubbe
Try adc at 0 or +2
ADC?
DSP and ADC settings do nothing for DMR systems.
If it's ok with you, can you attach a saved cdat backup file to a message and we can check if there are any settings that could relate to your problem?
It could be some local RF problem. Do you have all scanners connected to the same antenna or do each scanner only use the included clip on antenna?
It could be some file transfer problem as the TRX and EZscan doesn't indicate when a trashed file have been transfered, there's no checksum control. I have had problems that where solved by entering the same values again but manually on the scanner. Everything looked okay when checking the data on the scanner but entering them again cleared the problem.
Try and make a new system manually on the scanner and enter the frequencies directly on the scanner, don't bother getting the names correctly as its only for testing and enter only a wildcard for TG and radio id.
Laptops usually have a SD card reader/writer. You can move the SD card to you laptop for programming to get a more secure, and faster, connection.
/Ubbe
DSP and ADC settings do nothing for DMR systems.
If it's ok with you, can you attach a saved cdat backup file to a message and we can check if there are any settings that could relate to your problem?
It could be some local RF problem. Do you have all scanners connected to the same antenna or do each scanner only use the included clip on antenna?
It could be some file transfer problem as the TRX and EZscan doesn't indicate when a trashed file have been transfered, there's no checksum control. I have had problems that where solved by entering the same values again but manually on the scanner. Everything looked okay when checking the data on the scanner but entering them again cleared the problem.
Try and make a new system manually on the scanner and enter the frequencies directly on the scanner, don't bother getting the names correctly as its only for testing and enter only a wildcard for TG and radio id.
Laptops usually have a SD card reader/writer. You can move the SD card to you laptop for programming to get a more secure, and faster, connection.
/Ubbe
Dmr is tdma digital format just the same as p25 and i havent seen or heard any official statement as to whistler saying those settings only effect p25, so please if you can back up your information a little more please let me know.
When you increase dwell time it scans the frequencies a lot more and increase the chance to hit the frequency at the sweet spot in the data stream. Seems to be extreamly difficult to decode that system with the TRX-2.
When you do hear a conversation, does it continue to monitor it until the user releases his PTT? Then the best solution would be to multiply the voice frequencies instead of a long dwell time. That way it will stay on the same frequency much longer and have time to decode properly.
/Ubbe
Michael, enter these frequencies and see what happens.
It most probably are a missing frequency problem but don't know why the 536s scans ok.
Maybe the Uniden and Whistler databases are different.
/Ubbe
854.0125
854.3875
856.2625
856.9375
857.2625
857.7375
857.9625
858.2625
858.9625
859.4375
859.9375