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