Project

General

Profile

Actions

T-DisplayTel

This is probably the only ISDN Phone with built-in BTX Terminal that was ever made.

Pictures

20221119_162730.jpg 20221119_162855.jpg 20221119_162815.jpg 20221119_162801.jpg

FIXME

Hardware

The hardware consists of 3 circuit boards:

  • Mainboard (527/393-86211b)
  • Display Board
  • Keyboard

Mainboard (527/393-86211b)

The mainboard contains the main processor, RAM, Flash, EPROM as well as display + keyboard controller and ISDN interface.

20221001_103719.jpg

Main CPU

Keyboard Interface

  • 1x OKI M80C51F-368 8-bit 8051 controller with 4k mask ROM (LOEWE 349-025514) (I611) M80C51F.pdf
  • 11.0592 MHz XTAL
  • connects to keyboard via 2x8 header (W651)

Display Interface

  • 1x OKI M6355 Display Controller (I361)
    • connects to Display via 14pin FPC (W371)
    • 3 MHz XTAL
  • 1x Samsung KM62256BLG-10 32k x 8 CMOS SRAM (I381) KM62256.pdf
  • 1x Motorola 34063AP1 KDI DC/DC connverter controller (for display supply voltage)

ISDN Interface

Looks pretty similar to one of the passive HiSax (HSCX/ISAC) ISA ISDN cards for PCs:

Keyboard (86227.050)

20221001_111335.jpg 20221001_111347.jpg

  • 4x LED (directly connected to header)
  • 2x TI HC164 8-bit shift register
  • 16x Diode (mini-MELF)

Display board (Hitachi LMG6917RPGR-X)

20221001_112344.jpg 20221001_112406.jpg

  • 3x BD66285BFC Common Drivre IC
  • 3x HD66284BFC Column Driver IC (IC1, IC2, IC3, IC4)
  • 1x 530003HEB-S (IC9)
  • 1x TA 423 75902FB (IC8)

Making the BTX / Datex-J terminal work

laforge has been attempting to find out what needs to be done to get the BTX/terminal part of T-DisplayTel to work.

On the D-channel signaling side, it is establshing a normal UDI (unrestricted digital information), no specific HLC/LLC.

The more interesting question is what it speaks on the B-channel.

Accepting the call, dumping raw B channel

When accepting a call (from the simulated BTX server side), the T-DisplayTel unexpectedly doesn't send HDLC but some 0xff-padding based signaling:

00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff fb 05 7c 59  |..............|Y|
00000050  df ed f7 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001f20  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff fb  |................|
00001f30  05 7c 59 df ed f7 ff ff  ff ff ff ff ff ff ff ff  |.|Y.............|
00001f40  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00007ce0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff fb  |................|
00007cf0  05 7c 59 df ed f7 ff ff  ff ff ff ff ff ff ff ff  |.|Y.............|
00007d00  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0000daa0  ff ff ff ff ff ff ff ff  ff ff ff ff fb 05 7c 59  |..............|Y|
0000dab0  df ed f7 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0000dac0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00013860  ff ff ff ff ff ff ff ff  7e 01 5f d6 77 fb fd ff  |........~._.w...|
00013870  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00019620  ff ff ff ff ff ff fb 05  7c 59 df ed f7 ff ff ff  |........|Y......|
00019630  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0001f3e0  ff ff ff ff 7e 01 5f d6  77 fb fd ff ff ff ff ff  |....~._.w.......|
0001f3f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000251a0  ff fb 05 7c 59 df ed f7  ff ff ff ff ff ff ff ff  |...|Y...........|
000251b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0002b310  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ab ab  |................|
0002b320  ab ab ab ab ab ab ab ab  ab ab ab ab ab ab ab ab  |................|

So we see two messages, with a lot of 'ff' padding in between:

fb 05 7c 59 df ed f7
7e 01 5f d6 77 fb fd

If we re-order the bits of each byte and then HDLC decode (e.g. with https://gitea.osmocom.org/cellular-infrastructure/osmo-e1-recorder/src/branch/master/src/hdlc-test.c) we get

fffb057c59dfedf7ff => F 01 3f eb df F
ff7e015fd677fbfdff => F 01 3f eb df F

so it's actually a repeat transmission of the same frame.

establishing a call against an ISDN TA

Establishing call towards ISDN TA (US_Robotics_Sportster_ISDN_TA_Ext) and playing with the B-channel protocol on the TA, I can get a "proper" connection established when putting the TA into T.70-NL mode (ATB22). No success with HDLC, X.75 or V.120.

When the T.70-NL call is established, the DisplayTel cleaars its screen, and any characters sent by the TA are displayed on the screen. Great.

However, no characters are transmitted from the DisplayTel in the opposite direction. In fact, it doesn't even ever leave the 'ff' mode, i.e. no HDLC flag octets are sent by it. No keypress on the DisplayTel generates any non-ff data to be transmitted on the B-channel.

I'm attaching raw B-channel traces for both directions (displaytel-32-rx.raw and displaytel-32-tx.raw)

Interstingly, in this situation, the uplink from the Displaytel only contains a single, non-ff message:

df a0 3e 9a fb b7 ef

Decoded (bit order inversal + HDLC decode):

F 01 3f eb df F 

The same behavior can be observed when replacing the hardware ISDN TA with a software implementation: isdn4linux/ttyI0 in BTX mode (AT&X1) on Fritz!Card PCI.

Updated by laforge 3 months ago · 16 revisions

Add picture from clipboard (Maximum size: 48.8 MB)