USB56KEMH2 does not decode Brazilian DTMF Caller ID

Networking, Serial, Bluetooth
1

I am troubleshooting Caller ID on a USB56KEMH2 connected directly to the analog FXS port of a ZTE K12. Caller ID works correctly on an Intelbras TS2512 phone on the same line, including Brazilian DTMF category handling, but the modem only reports RING and never DATE/TIME/NMBR/NAME.

Device: ATI3 = CX93001-EIS_V0.2013-V92; AT-PV = F201000100; Windows driver 2.0.23.0; AT+GCI? = 16 (Brazil).

Reproduced using a serial terminal. Tested AT+VCID=1, AT+VCID=2, AT-SCID=1/2, AT+VRID=0/1, reset/default initialization and multiple incoming calls. VRID always remains empty while RING detection works normally.

Does USB56KEMH2 support Brazilian Type-I/on-hook DTMF Caller ID? If so, which AT commands, firmware or settings are required? Is there a firmware update or known limitation with this Caller ID format?

2

I have now performed additional troubleshooting with a digital oscilloscope, and I have much stronger evidence about what is happening.

I measured the analog FXS output of the ZTE K12 directly with a FNIRSI DPOX180H.

The incoming Caller ID is definitely being transmitted as DTMF before the first ring.

The observed sequence is generally:

idle line → large DC/polarity transition → DTMF sequence → first ring

Measurements from the higher-resolution captures show:

  • valid dual-frequency DTMF tones;

  • approximately 83–85 ms tone duration;

  • approximately 168–169 ms from the start of one tone to the next;

  • measured frequencies consistently around 0.9–1.0% above the nominal DTMF frequencies;

  • the long capture contained numeric DTMF symbols; I did not observe any symbols from the 1633 Hz column (A/B/C/D) in that capture.

An analog Intelbras telephone connected to the same K12 line correctly displays the calling number.

I then made an A/B oscilloscope comparison with the USB56KEMH2 connected to the same line.

This is the important result:

Connecting the USB56KEMH2 does not materially alter the Caller ID waveform.

Compared with the baseline capture, with the modem connected:

  • DTMF frequencies are essentially unchanged;

  • tone duration remains approximately 83–85 ms;

  • interdigit timing remains approximately 168–169 ms;

  • amplitude/twist changes are negligible;

  • the DTMF sequence is still clearly present on the physical line.

Therefore the modem’s analog input is receiving an intact DTMF Caller ID signal. It is not loading or destroying the signal.

However, using a serial terminal directly — with no third-party software involved — the modem still reports only:

RING

There is no DATE, TIME, NMBR, NAME, or other Caller ID data.

The modem is:

ATI3: CX93001-EIS_V0.2013-V92
AT-PV: F201000100
AT+GCI?: 16 (Brazil)

I have already tested the documented Caller ID paths, including:

AT+VCID=1
AT+VCID=2
AT-SCID=1
AT-SCID=2
AT+VRID=0
AT+VRID=1

as well as the initialization used by the official Windows driver.

VRID remains empty, while ring detection works normally.

At this point the problem appears to be inside the Caller ID recognition/decoder logic of the modem firmware rather than in the application software or the physical telephone signal.

Could StarTech please confirm with the modem/firmware engineering team:

  1. Does firmware CX93001-EIS_V0.2013-V92 / F201000100 support Brazilian Type-I/on-hook DTMF Caller ID specifically?

  2. What exact DTMF framing does the Brazil (+GCI=16) profile expect?

  3. Does the decoder require A/C (or other A-D) start/end delimiters, DTAS, polarity reversal, or another trigger before accepting the DTMF sequence as Caller ID?

  4. Is there an AT command, OEM setting, firmware patch, or newer firmware required for this Caller ID format?

  5. Is there any diagnostic mode that can expose the DTMF digits detected by the analog front end before the Caller ID parser accepts or rejects the message?

I can provide the original oscilloscope waveform files and screenshots if they would be useful for engineering analysis.

3

Hello @Lambde,

I am sorry to hear that you are having trouble with USB56KEMH2.

I see that our team has created a case for you and has reached out by email. To avoid any confusion, we will continue to work with you there and can update this post once we determine a resolution.

Lukas T

4

An update after my direct support case with StarTech:

Unfortunately, StarTech Support has now informed me that Brazil is outside the regions in which this product is validated/supported, and on that basis they have refused to provide further technical clarification regarding this issue.

I have to say that I am disappointed with this outcome, particularly because this was explicitly a Brazilian DTMF Caller ID issue from the very beginning of the support case. StarTech was aware of the country and use case before requesting additional information and before escalating the case internally.

After that escalation, I specifically clarified that I was not asking StarTech to certify the product for Brazil or guarantee regulatory compliance in an unsupported market. My questions were about the technical behavior of the modem firmware itself, including:

  • why the firmware explicitly accepts the Brazil country profile +GCI=16;

  • what that profile actually configures;

  • whether firmware CX93001-EIS_V0.2013-V92 / F201000100 implements Brazilian Type-I DTMF Caller ID;

  • whether the observed behavior is a known firmware limitation or an undocumented configuration issue;

  • whether another firmware, patch, or OEM setting exists.

StarTech declined to answer those technical questions because Brazil is outside their support boundaries.

For anyone encountering the same problem, the troubleshooting results so far are:

  • the ZTE K12 physically transmits DTMF Caller ID before the first ring;

  • the signal has been captured and verified with a digital oscilloscope;

  • an Intelbras analog telephone on the same line decodes the Caller ID correctly;

  • connecting the USB56KEMH2 does not materially alter the DTMF waveform;

  • the modem detects ringing normally;

  • using a direct serial terminal, with no Caller ID software involved, the modem still produces only RING;

  • +VCID=1/2, -SCID=1/2, and +VRID=0/1 have all been tested, with VRID remaining empty;

  • +GCI=16 is accepted and reported by the modem as the active country profile.

Therefore, at this point I cannot determine whether Brazilian DTMF Caller ID is actually unsupported by the modem firmware or whether an undocumented configuration is required, because StarTech has chosen not to provide further technical information based on regional support boundaries.

I am documenting this here so that other users considering the USB56KEMH2 specifically for Brazilian Caller ID are aware of both the observed behavior and the support response.