The latest BMML that runs reliably is Windows XP 32bit.
I looked for the pinout, but no. Unfortunately, there are no such details in the documentation 
The absence of cables is a mystery to me. I would understand that someone took the PC away.
See the screen for the cable. But if you don’t have the cable, the partnumber is useless.
I will measure it and send you the pinout
I would be extremely interested in that, and/or any description (official or reverse engineered). Not urgent.
I have the S38228-Z43-A150-4 cable now from another EWSD. What is the difference between Z42 and Z43?
bingo 
Z42 and Z43 are interchanged in documentation, so the difference will probably be minimal.
Anyway, your cable is exactly what I have, so it’s the right one. Connection at position IOP:UNI - P1
Here one more picture from the teardown. More complete documentation including timelapse videos will be released at a later point.
This is the dump of inquiry data from both HDs:
root@scsi:~# sg_inq /dev/sdc --hex
00 00 00 02 42 3b 00 00 1e 46 55 4a 49 54 53 55 20 …B;…FUJITSU
10 4d 41 47 33 31 38 32 4c 43 20 20 20 20 20 20 20 MAG3182LC
20 35 32 31 30 20 20 20 20 35 30 30 32 33 35 34 37 5210 50023547
30 40 23 30 38 37 39 38 00 00 00 00 00 00 00 00 00 @#08798…
root@scsi:~# sg_inq /dev/sdd --hex
00 00 00 02 42 3b 00 00 1e 46 55 4a 49 54 53 55 20 …B;…FUJITSU
10 4d 41 47 33 31 38 32 4c 43 20 20 20 20 20 20 20 MAG3182LC
20 35 32 31 30 20 20 20 20 35 30 30 32 33 34 34 30 5210 50023440
30 40 23 30 38 37 39 38 00 00 00 00 00 00 00 00 00 @#08798…
I wonder if the “Vendor Unique” field “3547@#08798” and “3440@#08798” has some meaning. Or is it just the “Drive Serial Number” field " 5002" that is required to be accepted by the EWSD?
More inquiry data would be helpful.
ok i will try If I can’t do it from a win machine, I’ll have to try if my controller will work under linux, maybe…give me some day…
Linux is what I prefer. Then you can use “sg_inq /dev/sdX --hex” to dump the drive’s inquiry data. replace sdX with the actual drive’s device. (sudo apt-get install sg3-utils)
I would suggest to connect the drive prior powering on the machine, so you don’t have to re-scan the SCSI bus.
Sure, if I had a linux machine with the necessary scsi interface, it would be the easiest. So far I use 2 machines with dos and windows XP, where I do operations with these disks. If I couldn’t read it, I would do it like this.
But it’s not necessary, surprisingly it works even on Windows. In the attachment from 2 discs. I can read more if needed…
MDD1:
1.1.2004 03:59:58.406 Execute "Inquiry (12h)" command, command support data (CMDDT) 0, enable vital pr
1.1.2004 03:59:58.406 oduct data (EVPD) 0, page code 0x00 (0), allocation length 0x00FF (255), CDB len
1.1.2004 03:59:58.406 gth 6, CDB (hex) 12 00 00 00 FF 00
1.1.2004 03:59:58.421 Input Dump data size 0x00000040 (64) byte(s), dump data (hex):
1.1.2004 03:59:58.421 00000000: 00 00 02 42 3B 00 00 1E 46 55 4A 49 54 53 55 20 ...B;...FUJITSU
1.1.2004 03:59:58.421 00000010: 4D 41 47 33 31 38 32 4C 43 20 20 20 20 20 20 20 MAG3182LC
1.1.2004 03:59:58.421 00000020: 35 32 31 30 20 20 20 20 35 30 30 32 31 30 35 36 5210 50021056
1.1.2004 03:59:58.421 00000030: 40 23 30 38 37 39 38 00 00 00 00 00 00 00 00 00 @#08798.........
1.1.2004 03:59:58.421 Received 64 bytes of inqury data
1.1.2004 03:59:58.421 Peripheral Qualifier: 0x0 (0)
1.1.2004 03:59:58.421 Peripheral Device Type: 0x0 (0)
1.1.2004 03:59:58.421 Removable Medium (RMB): 0
1.1.2004 03:59:58.421 Device-type Modifier: 0x0 (0)
1.1.2004 03:59:58.421 ISO Version: 0x0 (0)
1.1.2004 03:59:58.421 ECMA Version: 0x0 (0)
1.1.2004 03:59:58.421 ANSI-approved Version: 0x2 (2)
1.1.2004 03:59:58.421 Asynchronous Event Notification Capability (AENC): 0
1.1.2004 03:59:58.421 Terminate I/O Process (TrmIOP): 1
1.1.2004 03:59:58.421 Response Data Format: 0x2 (2)
1.1.2004 03:59:58.421 Additional Length: 0x3B (59)
1.1.2004 03:59:58.421 Relative Addressing (RelAdr): 0
1.1.2004 03:59:58.421 Wide Bus 32 (WBus32): 0
1.1.2004 03:59:58.421 Wide Bus 16 (WBus16): 0
1.1.2004 03:59:58.421 Synchronous Transfer (Sync): 1
1.1.2004 03:59:58.421 Linked Command (Linked): 1
1.1.2004 03:59:58.421 Command Queuing (CmdQue): 1
1.1.2004 03:59:58.421 Soft Reset (SftRe): 0
1.1.2004 03:59:58.421 Vendor Identification: FUJITSU
1.1.2004 03:59:58.421 Product Identification: MAG3182LC
1.1.2004 03:59:58.421 Product Revision Level: 5210
1.1.2004 03:59:58.421 Vendor Specific: 20 20 20 20 35 30 30 32 31 30 35 36 40 23 30 38 37 39 38 00
1.1.2004 03:59:58.421 "Inquiry (12h)" command completed, adapter status 0 <Success>, SCSI status: 0x00
1.1.2004 03:59:58.421 <Good>, execution time 382 mcs
MDD2:
1.1.2004 04:04:29.828 Execute "Inquiry (12h)" command, command support data (CMDDT) 0, enable vital pr
1.1.2004 04:04:29.828 oduct data (EVPD) 0, page code 0x00 (0), allocation length 0x00FF (255), CDB len
1.1.2004 04:04:29.828 gth 6, CDB (hex) 12 00 00 00 FF 00
1.1.2004 04:04:29.875 Input Dump data size 0x00000060 (96) byte(s), dump data (hex):
1.1.2004 04:04:29.875 00000000: 00 00 02 02 5B 00 00 1A 46 55 4A 49 54 53 55 20 ....[...FUJITSU
1.1.2004 04:04:29.875 00000010: 4D 41 57 33 30 33 32 4E 43 38 20 20 20 20 20 20 MAW3032NC8
1.1.2004 04:04:29.875 00000020: 37 33 30 33 44 42 4C 34 50 37 31 30 30 37 34 33 7303DBL4P7100743
1.1.2004 04:04:29.875 00000030: 40 23 32 31 45 36 30 00 00 00 00 40 0B 54 01 3C @#21E60....@.T.<
1.1.2004 04:04:29.875 00000040: 01 9B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .›..............
1.1.2004 04:04:29.875 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1.1.2004 04:04:29.875 Received 96 bytes of inqury data
1.1.2004 04:04:29.875 Peripheral Qualifier: 0x0 (0)
1.1.2004 04:04:29.875 Peripheral Device Type: 0x0 (0)
1.1.2004 04:04:29.875 Removable Medium (RMB): 0
1.1.2004 04:04:29.875 Device-type Modifier: 0x0 (0)
1.1.2004 04:04:29.875 ISO Version: 0x0 (0)
1.1.2004 04:04:29.875 ECMA Version: 0x0 (0)
1.1.2004 04:04:29.875 ANSI-approved Version: 0x2 (2)
1.1.2004 04:04:29.875 Asynchronous Event Notification Capability (AENC): 0
1.1.2004 04:04:29.875 Terminate I/O Process (TrmIOP): 0
1.1.2004 04:04:29.875 Response Data Format: 0x2 (2)
1.1.2004 04:04:29.875 Additional Length: 0x5B (91)
1.1.2004 04:04:29.875 Relative Addressing (RelAdr): 0
1.1.2004 04:04:29.875 Wide Bus 32 (WBus32): 0
1.1.2004 04:04:29.875 Wide Bus 16 (WBus16): 0
1.1.2004 04:04:29.875 Synchronous Transfer (Sync): 1
1.1.2004 04:04:29.875 Linked Command (Linked): 1
1.1.2004 04:04:29.875 Command Queuing (CmdQue): 1
1.1.2004 04:04:29.875 Soft Reset (SftRe): 0
1.1.2004 04:04:29.875 Vendor Identification: FUJITSU
1.1.2004 04:04:29.875 Product Identification: MAW3032NC8
1.1.2004 04:04:29.875 Product Revision Level: 7303
1.1.2004 04:04:29.875 Vendor Specific: 44 42 4C 34 50 37 31 30 30 37 34 33 40 23 32 31 45 36 30 00
1.1.2004 04:04:29.875 "Inquiry (12h)" command completed, adapter status 0 <Success>, SCSI status: 0x00
1.1.2004 04:04:29.875 <Good>, execution time 348 mcs
Compared to other (non EWSD) drives, I don’t see anything special. Maybe the “Vendor Unique” 1056@#08798 and 0743@#21E60 or the Product ID “MAG3182LC” or “MAW3032NC8” is somewhere checked. I could not find any of these strings on my drive’s data.
OK, so we probably won’t find out more now. Use only one disk for experiments, leave the other one disconnected for APS backup reasons. DIAGMDD can then be used to test converters on the second free, empty SCSI bus. I also have one of the converters (SCSI2SD) but I don’t know if this would be able to support another inquiry answer. On the wiki they write Vendor, Product ID, Revision, and Serial number may be changed, but I don’t know what revision I have… At the time of building the EWSD, I didn’t have the converter yet, so there were no such attempts.
If you think of anything else I could try, write.
So what does DIAGMDD show on EWSD approved drives and what on non EWSD drives? (I don’t want to see the output, just want to know what roughly the difference is.)
It reports that the disk is defective. I don’t remember now exactly if there is a more detailed reason. The correct disk will pass without error, and it can then be put into ACT state, where file synchronization will start.
My rebuild videos so far:
Enjoy!
Nice, In a few days there will be the first calls .-)
Here is the LTG with one GPN:YE and one OCE:N for announcements. I want to use LTGN(B) instead. Is it possible to put OCE:N into it? I have multiple LTGN(B) with GPN:YE and PHMA for V5.2 signaling. The construction manual sais (clause 3.5.2.2) that LTGN(B) can have OCE:N.
LTGN in this shelf C can have 2 sister boards next to each other. That’s why ocaneqs were put in these C. Since you don’t have anything else with ocaneq, probably no IN functions were used. In this case, you can put the ocaneq as a sister board to the LTGN in shelf B. But not now. in LTG there will be a different loadtype. Feel free to leave this small shelf disconnected, then some LTG will be reconfigured and only then will ocaneq be inserted.
But I would only do it if you really don’t have the space anymore. If it is free, I would leave this C shelf there in case you ever wanted to add, for example, a DTMF receiver during a call.
What is the name of the card that does DTMF during a call?
VPU. If you have it, it’s on this shelf. It can still be together with ocaneq in LTGP shelf B. I don’t know which one you have for LTGP
I have no VPU. The specs say that it does voice recognition. I have two MOTOG. (modem with tone generator)
