AL7LI
I hope I'm not duplicating a thread but I did a search and found nothing similar.
My 7 month old OpenSpot2 stopped transmitting. It is receiving fine and all indications look normal none of the configuration settings have changed. I have tried it as Server and Client both point to point with another OpenSpot2 acting as Client and Server; and as Client connecting to my IP connector. The IP connector shows me connected and the Status log shows all the pings and pongs but when I key up the radio the OpenSpot2 flashes green like normal but the IP connector server never shows me in the Last Heard log. I have checked the radio and I am hitting the DMR parrots just fine. I have tried a factory reset and reinitialized it. It still won't transmit. Any ideas or do I need to send it in for repair?
Thanks,
AL7LI
HA2NON
Please make sure you connect to the correct server. Also look at the log on the server side to find out what it is receiving.
AL7LI
Using the SharkRF IP connector protocol server and looking at the dashboard, I am connected. There is another station connected and he is shown in the last heard log when he transmits and I can hear him. When I try to answer back, my OpenSpot2 flashes green as normal but he can't hear me nor do I show up in the last heard log on the server dashboard.
On the client side, the log shows the normal handshaking but when I transmit there are errors posted as follows as long as I'm keyed up.
11:23:12 srfipconn-client: got pong
11:23:14 dmrcalltracker[0]: cc mismatch (got 13 expected 1)
11:23:15 dmrcalltracker[0]: cc mismatch (got 5 expected 1)
11:23:15 dmrcalltracker[0]: cc mismatch (got 5 expected 1)
11:23:16 nvmm: net check
11:23:16 nvmm: net check ok (14 ms)
11:23:16 dmrcalltracker[0]: cc mismatch (got 5 expected 1)
11:23:19 srfipconn-client: ping sent
11:23:19 srfipconn-client: got pong
I searched for the error in the troubleshooting section and got no results.
Please advise and thank you,
AL7LI
Tyrbiter
Looks like the Colour Code in your codeplug is not set to 1, which is what the server is expecting.
AL7LI
After searching this site again and reading suggestions, I tried bumping the receive freq offset up 100 Hz (from 0) and now it shows up on the server dashboard. I will try it next chance it get. Hope this fixed it. Thanks.
AL7LI
Tyrbiter
After searching this site again and reading suggestions, I tried bumping the receive freq offset up 100 Hz (from 0) and now it shows up on the server dashboard. I will try it next chance it get. Hope this fixed it. Thanks.
AL7LI
Could be a high BER due to Rx frequency offset, the fact that the CC kept being misinterpreted as different values does suggest that.
AL7LI
Thanks, It makes sense.
HA2NON
Using the openSPOT2's DMR AutoCal can help you determine the correct RX offset for your transceiver.
ktower
I'm having similar issues to OP:
12:00:29 dmrcalltracker[0]: cc mismatch (got 13 expected 1)
12:00:29 dmrcalltracker[0]: cc mismatch (got 5 expected 1)
12:00:30 dmrcalltracker[0]: cc mismatch (got 13 expected 1)
12:00:30 dmrcalltracker[0]: cc mismatch (got 15 expected 1)
But I can usually resolve the issue by rebooting the OS2.
12:03:23 dmrcalltracker[0]: grp voice call started, dst: 9996 src: 3149965 id: dcac36c272fceed0
12:03:23 nvmm-csd: looking up id 9996 type 2
12:03:23 nvmm-csd: no csd
12:03:23 nvmm-csd: looking up id 3149965 type 0
12:03:23 nvmm-csd: no csd
12:03:24 dmrcalltracker[0]: call ended, dur 1.1s ber 0.9% loss 0.0% rssi -46
I've run the AutoCal and it indicates that no RX offset is warranted.
Any thoughts on next steps for troubleshooting?
HA2NON
If DMR AutoCal does not work for you, then try manually changing the RX offset on the Modem page in +-100Hz steps. If you still have issues, then switch both RX and TX frequencies and re-do AutoCal (and/or RX offset change).