New Contributor
•
3 Messages
Vecima Tuning Adapter Won't Initialize with Ceton infiniTV 6 USB - Cox Las Vegas
About a month ago, in July 2024, I was furnished a new tuning adapter, a Vecima HSC-1-H high split converter / tuning adapter, to replace a Cisco STA1520 that I've had since at least 2013. I understand this is to ensure continued functionality when the cable plant in the Las Vegas, Nevada area switches over to high split SDV. The tuning adapter is paired to a Ceton infiniTV 6 USB external tuner, which has a CableCARD.
After self-install and diagnostics over the phone failed, a service technician was dispatched. Despite having a visit from a Cox technician, we haven't been able to figure out a solution to the problem.
The infiniTV has an internal webpage configuration and status interface. There is a page for Tuning Adapter specifically. Under TR Status, the status gets stuck as "Waiting for Initialization." Under the CableCARD menu, the CableCARD appears to pair and authorize without issue, reflecting "Validated, validation message is received, authenticated, and the IDs match those in the current binding" under "Card authorization." In the log menu, the infiniTV shows that it's getting stuck in what appears to me to be an initialization cycle for the tuning adapter. I've copied some of the log below where a number of the entries repeat and time out.
Jan 1 00:07:57 ocur[21]: ocur: found tuning resolver @ 1:3
Jan 1 00:07:58 ocur[21]: ocur: claimed tr[1:3] read_ep 81 write_ep 02
Jan 1 00:07:58 ocur[21]: ocur: Doing initial USB reset
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] cancel failed -5
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] cancel failed -5
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] cancel failed -5
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] cancel failed -5
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] cancel failed -5
Jan 1 00:07:58 ocur[21]: libcetontrif: trif[6] Waiting 20 seconds for init_rsp
Jan 1 00:07:58 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:07:58 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:08:18 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 1)
Jan 1 00:08:19 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:08:19 ocur[21]: libcetontrif: trif[6] Waiting 20 seconds for init_rsp
Jan 1 00:08:19 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:08:25 ocur[21]: ocur: accumulating new channel map (413) into old channel map (415)
Jan 1 00:08:25 ocur[21]: ocur: accumulated channel map same as old
Jan 1 00:08:39 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 2)
Jan 1 00:08:40 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:08:40 ocur[21]: libcetontrif: trif[6] Waiting 20 seconds for init_rsp
Jan 1 00:08:40 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:09:00 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 3)
Jan 1 00:09:01 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:09:01 ocur[21]: libcetontrif: trif[6] Waiting 30 seconds for init_rsp
Jan 1 00:09:01 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:09:31 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 4)
Jan 1 00:09:32 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:09:32 ocur[21]: libcetontrif: trif[6] Waiting 40 seconds for init_rsp
Jan 1 00:09:32 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:10:12 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 5)
Jan 1 00:10:13 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:10:13 ocur[21]: libcetontrif: trif[6] Waiting 50 seconds for init_rsp
Jan 1 00:10:13 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:11:03 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 6)
Jan 1 00:11:04 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:11:04 ocur[21]: libcetontrif: trif[6] Waiting 60 seconds for init_rsp
Jan 1 00:11:04 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:12:04 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 7)
Jan 1 00:12:05 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:12:05 ocur[21]: libcetontrif: trif[6] Waiting 70 seconds for init_rsp
Jan 1 00:12:05 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:13:15 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 8)
Jan 1 00:13:16 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:13:16 ocur[21]: libcetontrif: trif[6] Waiting 80 seconds for init_rsp
Jan 1 00:13:16 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:14:36 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 9)
Jan 1 00:14:37 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:14:37 ocur[21]: libcetontrif: trif[6] Waiting 90 seconds for init_rsp
Jan 1 00:14:37 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
Jan 1 00:16:07 ocur[21]: libcetontrif: WARNING: trif[6] init req timeout, requesting reset (failures 10)
Jan 1 00:16:08 ocur[21]: ocur: WARNING: Clearing dynamic OCTA map on 6
Jan 1 00:16:08 ocur[21]: libcetontrif: trif[6] Waiting 100 seconds for init_rsp
Jan 1 00:16:08 ocur[21]: ocur: WARNING: tr[1:3] submit failed -1
I still have the old Cisco tuning adapter. For what it's worth, it pairs and initializes with the Ceton infiniTV just fine, though it loses WMDRM Pairing every night and has to be manually rebooted and reinitialized to regain WMDRM Pairing. But at least I can still get the Cisco tuning adapter to work with the infiniTV.
Given that the infiniTV and CableCARD seem to be working just fine, and continue to work with the old Cisco tuning adapter, I think I can confidently say the issue is something with the configuration of the new Vecima tuning adapter and it not wanting to initialize and pair with the infiniTV.
Any ideas from more knowledgeable technicians, Cox?
DustinP
Moderator
•
1.1K Messages
1 year ago
Hello swmcdonald86, Thank you for these details. We may need to have a field technician visit return to further ascertain the issue. Is there a signal amplifier attached to the coaxial cable between the wall and the Vecima Tuning Adapter? If so, then I don't recommend bypassing that as it would have been determined necessary by a field technician. If there is an issue impacting power levels, then this can cause an issue.
0
0
swmcdonald86
New Contributor
•
3 Messages
1 year ago
No, there is no signal amplifier anywhere on site. Power levels don't seem to be an issue. When the previous technician was on site, he commented that power levels were in spec.
I know it's not a perfect comparison, but an Arris TM3402 that is run from the same wall outlet shows signal levels as follows: downstream power levels between 0.1 dBmV and -3.4 dBmV on frequencies ranging from 117 to 873 MHz; upstream power levels between 44 dbmV and 48.5 dBmV on frequencies ranging from 16.9 to 29.9 MHz.
The wall outlet is fed to a three-way splitter, with one coax going to the tuning adapters (whether it be the Cisco or Vecima tuning adapter), which then continues on through the tuning adapter to the infiniTV tuner (only one at at time between the Cisco and Vecima tuning adapters), and the third goes to the TM3402. The last technician swapped a two-way splitter for the three-way splitter so both tuning adapters could be fed with input at the same time, thinking that the Vecima just needed more time to download a firmware upgrade.
There is no change in behavior if I go back to a two-way splitter and feed only one tuning adapter at a time, though unsurprisingly the signal levels I can see through the TM3402 improve slightly, but again, with the three-way splitter in place, the signal levels don't appear to me to be a primary concern.
So with all of that above and what the technician said last time (and everything working when the Cisco tuning adapter is be used), I'm thinking signal levels being a root cause is unlikely and it's really a problem with the Vecima tuning adapter or some configuration on the back end. But I'm happy to be proved wrong.
2
0