Forum Discussion

swmcdonald86's avatar
swmcdonald86
New Contributor
5 months ago

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?

vecima
  • DustinP's avatar
    DustinP
    Moderator
    5 months 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. 

  • swmcdonald86's avatar
    swmcdonald86
    New Contributor
    5 months 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.

    • Shaun_A's avatar
      Shaun_A
      Moderator
      5 months ago

      Hello swmcdonald86.  Thank you for that information. My name is Shaun and I will be assisting while Dustin is unavailable. So just to verify, the Vecima tuning adapter has NEVER worked since install, correct?  But you were left with the Cisco adapter that you can still actively use? If this is the case, then this may lean more towards a provisioning issue between the two where the cable card is still provisioned to the cisco adapter on our end. I would like to pull up your account to view a bit more specifics on this.  Can you send us an email to Cox.Help@cox.com with your full name and complete address? That way we can look into this further for you.  

      • swmcdonald86's avatar
        swmcdonald86
        New Contributor
        5 months ago

        Correct, the Vecima adapter has never worked. I was left the Cisco adapter which I can still actively use. I will send an email to this address shortly.