Project

General

Profile

T-DisplayTel » History » Version 17

laforge, 11/02/2023 11:49 AM

1 2 laforge
h1. T-DisplayTel
2 1 laforge
3
This is probably the only ISDN Phone with built-in [[BTX]] Terminal that was ever made.
4
5
h2. Pictures
6
7 16 laforge
{{thumbnail(20221119_162730.jpg)}}
8
{{thumbnail(20221119_162855.jpg)}}
9
{{thumbnail(20221119_162815.jpg)}}
10
{{thumbnail(20221119_162801.jpg)}}
11
12 1 laforge
FIXME
13 2 laforge
14 8 laforge
h2. Hardware
15
16
The hardware consists of 3 circuit boards:
17
18 9 laforge
* Mainboard (527/393-86211b)
19 8 laforge
* Display Board
20
* Keyboard
21
22 9 laforge
h3. Mainboard (527/393-86211b)
23 1 laforge
24 9 laforge
The mainboard contains the main processor, RAM, Flash, EPROM as well as display + keyboard controller and ISDN interface.
25
26 14 laforge
{{thumbnail(20221001_103719.jpg,size=500)}}
27
28 8 laforge
h4. Main CPU
29
30
* 1x NEC uPD70236AGD-12 (V53A) 16bit CPU (I101) attachment:UPD70236_NECElectronics.pdf
31
* 1x Samsung KM29C010-15 128k x 8 CMOS Flash Memory (I281) attachment:KM29C010.pdf
32 13 laforge
* 1x TI TMS27C240-12 256k x 16 EPROM (I271) attachment:TMS27C240.pdf
33 17 laforge
** EPROM image (v2.2): attachment:DisplayTel_I271_24677_054_PROD_C_5293.bin
34
** EPROM image (v2.3): attachment:DisplayTel_I271_SWVER2.3_14111996_BC00_sernr7066.bin
35 8 laforge
* 2x Samsung KM658128ALG-8  28k x 8 PSRAM (I231, I241) attachment:KM658128.pdf
36
* 24.576 MHz XTAL
37
* TI TL770SACP Supply Voltage Supervisor
38
39
h4. Keyboard Interface
40
41
* 1x OKI M80C51F-368 8-bit 8051 controller with 4k mask ROM (LOEWE 349-025514) (I611) attachment:M80C51F.pdf
42
* 11.0592 MHz XTAL
43
* connects to keyboard via 2x8 header (W651)
44
45
h4. Display Interface
46
47
* 1x OKI M6355 Display Controller (I361)
48 10 laforge
** connects to Display via 14pin FPC (W371)
49
** 3 MHz XTAL
50 8 laforge
* 1x Samsung KM62256BLG-10 32k x 8 CMOS SRAM (I381) attachment:KM62256.pdf
51
* 1x Motorola 34063AP1 KDI DC/DC connverter controller (for display supply voltage)
52
53
h4. ISDN Interface
54
55 15 laforge
Looks pretty similar to one of the passive HiSax (HSCX/ISAC) ISA ISDN cards for PCs:
56
57
* 1x Siemens SAB 82526 HSCX-1 V2.1 attachment:SAB82526.pdf
58
* 1x Siemens PSB 2186N V1.1 ISAC-S TE attachment:PSB2186.pdf
59 8 laforge
60 11 laforge
h3. Keyboard (86227.050)
61
62 14 laforge
{{thumbnail(20221001_111335.jpg,size=500)}}
63
{{thumbnail(20221001_111347.jpg,size=500)}}
64
65 11 laforge
* 4x LED (directly connected to header)
66
* 2x TI HC164 8-bit shift register
67
* 16x Diode (mini-MELF)
68 8 laforge
69 12 laforge
h3. Display board (Hitachi LMG6917RPGR-X)
70 14 laforge
71
{{thumbnail(20221001_112344.jpg,size=500)}}
72
{{thumbnail(20221001_112406.jpg,size=500)}}
73 12 laforge
74
* 3x BD66285BFC Common Drivre IC(IC5, IC6, IC7)
75
* 3x HD66284BFC Column Driver IC (IC1, IC2, IC3, IC4)
76
* 1x 530003HEB-S (IC9)
77
* 1x TA 423 75902FB (IC8)
78 8 laforge
79 2 laforge
h2. Making the BTX / Datex-J terminal work
80
81
@laforge has been attempting to find out what needs to be done to get the BTX/terminal part of T-DisplayTel to work.
82
83
On the D-channel signaling side, it is establshing a normal _UDI (unrestricted digital information)_, no specific HLC/LLC.
84
85 4 laforge
The more interesting question is what it speaks on the B-channel.
86 2 laforge
87
h3. Accepting the call, dumping raw B channel
88
89
When accepting a call (from the simulated BTX server side), the T-DisplayTel unexpectedly doesn't send HDLC but some 0xff-padding based signaling:
90
91
<pre>
92
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
93
*
94
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff fb 05 7c 59  |..............|Y|
95
00000050  df ed f7 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
96
00000060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
97
*
98
00001f20  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff fb  |................|
99
00001f30  05 7c 59 df ed f7 ff ff  ff ff ff ff ff ff ff ff  |.|Y.............|
100
00001f40  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
101
*
102
00007ce0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff fb  |................|
103
00007cf0  05 7c 59 df ed f7 ff ff  ff ff ff ff ff ff ff ff  |.|Y.............|
104
00007d00  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
105
*
106
0000daa0  ff ff ff ff ff ff ff ff  ff ff ff ff fb 05 7c 59  |..............|Y|
107
0000dab0  df ed f7 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
108
0000dac0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
109
*
110
00013860  ff ff ff ff ff ff ff ff  7e 01 5f d6 77 fb fd ff  |........~._.w...|
111
00013870  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
112
*
113
00019620  ff ff ff ff ff ff fb 05  7c 59 df ed f7 ff ff ff  |........|Y......|
114
00019630  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
115
*
116
0001f3e0  ff ff ff ff 7e 01 5f d6  77 fb fd ff ff ff ff ff  |....~._.w.......|
117
0001f3f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
118
*
119
000251a0  ff fb 05 7c 59 df ed f7  ff ff ff ff ff ff ff ff  |...|Y...........|
120
000251b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
121
*
122
0002b310  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ab ab  |................|
123
0002b320  ab ab ab ab ab ab ab ab  ab ab ab ab ab ab ab ab  |................|
124
</pre>
125
126
So we see two messages, with a lot of 'ff' padding in between:
127
<pre>
128
fb 05 7c 59 df ed f7
129
7e 01 5f d6 77 fb fd
130
</pre>
131 1 laforge
132 7 laforge
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
133 4 laforge
<pre>
134
fffb057c59dfedf7ff => F 01 3f eb df F
135
ff7e015fd677fbfdff => F 01 3f eb df F
136
</pre>
137
138
so it's actually a repeat transmission of the same frame.
139 2 laforge
140
h3. establishing a call against an ISDN TA
141
142
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.
143
144
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.
145
146
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.
147
148
I'm attaching raw B-channel traces for both directions (attachment:displaytel-32-rx.raw and attachment:displaytel-32-tx.raw)
149 3 laforge
150
Interstingly, in this situation, the uplink from the Displaytel only contains a single, non-ff message:
151
152
<pre>
153
df a0 3e 9a fb b7 ef
154
</pre>
155 5 laforge
156
Decoded (bit order inversal + HDLC decode):
157
<pre>
158
F 01 3f eb df F 
159
</pre>
160 6 laforge
161
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.
Add picture from clipboard (Maximum size: 48.8 MB)