IRIS Repair coding Basic Principles Basics of IRIS

IRIS Repair coding: Basic Principles

Basics of IRIS Coding (1) IRIS coding has in most cases two, quite distinct, areas: SYMPTOM AREA The SYMPTOM area is intended to describe the set’s malfunction, AS PERCEIVED BY THE USER or any other casual observer. It requires no specific technician know-how to be filled out, and it uses the • Condition code • Symptom Code DIAGNOSIS AREA The DIAGNOSIS area is intended FOR THE TECHNICIAN, to describe where the defect was located, and the actions that were taken by him to repair the set. It uses the • Section- & (optionally) PCB Code • Part Reference(s) • Defect Code(s) • Repair Flag

Basics of IRIS Coding (2) In some cases , when no technical fault was found on a set , IRIS coding has 3 , quite distinct, areas: SYMPTOM AREA • Condition code • Symptom Code DIAGNOSIS AREA • Defect Code(s) • Repair Code(s) NTF SYMPTOM AREA The NTF Symptom is intended for cases when No Technical Fault was found , to describe the reason why the owner / user of the set considered the set faulty. It uses the • Non-Technical Fault code • Inserted into the SECTION CODE area of Diagnosis area

IRIS Coding card - Symptom area T N I A L P M O C S ’ R E M O T S U C When looking at the IRIS coding card, the Front side (the famous matrix) represents the ‘Symptom’ area ….

IRIS Coding card - Diagnosis area A I SD IS S O N G ’ N A I NIC H C E T …whereas the Back side, (with the Section-, Repair- and Defect codes, represents the ‘Diagnosis’ area

IRIS Coding Card , NTF area R O ( N O ) I T N P SIO E C LU R E NC P S ’ O R C E S ’ M N O A T I S C CU HNI C E T And finally , in cases of Non-Technical Fault , similar to the Symptom Matrix , a NTF matrix page has been added

The Symptom Code Logic

IRIS Coding card - Symptom area The Symptom code should describe the problem as it can be perceived by any of the five senses, based on simple questions which the enduser can answer, like: • What exactly did (or did you not) see, hear, feel, smell, taste, …. ? • Does this phenomenon occur all the time, or under certain conditions? Nobody should expect a technical analysis from a customer, so it is important to define only symptoms that anybody can perceive and describe.

Get the Symptom from the Source! F F The customer’s symptom description is the key for both the Dealer and Servicer to handle the repair promptly and efficiently Therefore, it is most important to get this description directly from him (the source), and bring it along to the next step (the Repairer). Therefore, whoever receives a repair from a customer should be familiar with IRIS symptom coding and use it. (cartoon relay run)

Symptom coding by the Technician ? Looks like a resource conflict on the SCSI bus master ! When I pushed ‘save’, it suddenly exploded ! By lack of symptom from Customer- or Reception-side, it is often necessary that the technician has to verify the symptom (by testing the set’s properation at the work bench), and then enters the Symptom code himself. But in such a case he/she also should take the same point of view of a customer : WHAT DO I SEE , HEAR , FEEL , SMELL , . . . He should NOT try to make an ‘on-the-spot’ diagnosis !

Symptom code “correction” F In some cases it can also be necessary that a technician will: * “enhance” the original customer claim, e. g. by adding a condition code. * or he may even have to “correct” it, if it was clearly a wrong one. But of course also in such case , the basic idea of symptom coding should remain intact. Examples of good technician corrections: 1. Customer claim: There’s no picture on my TV; this will be coded at reception into 1310. Technician however finds that in fact the set does not switch on power at all. He consequently corrects to : No Power (code 1110), or better: No Power on AC (code 1111) 2. Customer claim: Hiss noise from my cassette; this will be coded at reception to 1542. Technician finds out this is correct but in fact only appears in one channel. He consequently corrects to: E 542

Basic Symptom Matrix structure Problem Type Problem Area

Symptom Code structure Questions: Byte 1: Under which circumstances? (condition) Byte 2: Which main function group? (area of problem) Byte 3: Which type of malfunction? (type of problem) Byte 4: Which malfunction exactly? (problem specification)

The Diagnosis Code Logic

Diagnosis Area F F F By entering a suitable combination of different code types, a technician can give nearly full details concerning the performed repair. For each aspect of repair , a specific code is available By combining the (user) symptom area and the (technician) diagnosis area, a complete picture of the repair can be obtained, and a symptom/ cause analysis can be performed.

Section Identification F F Consist of 3 -byte Section codes indicate in which part of the set the intervention(s) was (were) performed To make them easier to remember, the 3 -byte codes form so-called ‘mnemonics’ based on the english section names Section codes are easiest to understand when comparing them to a set’s block diagram

Example of Section codes in a CD player Optical Pickup

Part Identification F F Consists of Partnumber, Reference Number, and (optionally) Mounted Circuit Board code These codes are manufacturer dependant. * Partnumber is the part order code(s) of replaced part(s) * Ref. is the position reference of the part acted upon (replaced, adjusted, or else) as published in the service documentation. It is specially necessary if one partnumber is used on different positions. * PCB is the name or code of the board on which the component is located F Lengths of these codes can vary , they should be aligned from left side

Defect Identification F F F “Defect Codes” specify the type of defect(s) that was (were) found by the technician. Mechanical as well as Electrical codes are defined. They always refer immediately to the part identified on the same line. However, some types of Defect codes can also be “selfstanding”, i. e. not related to a specific part. One of those “independent” Defect codes is “No Problem Found”; reasons for this can be further specified.

Repair Identification F F F Repair Codes identify the actions performed by the technician Most common types of repair, like replacement, cleaning, alignment etc. must be referenced to specific components. Also here, a number of ‘self-standing’ Repair codes exist, e. g. software upgrading, return without repair, estimation of repair, upgrading, etc. .

Parts Quantity F Quantity field will indicate how many of a particular part have been replaced. * Logically, a quantity of more than ‘ 1’ usually only refers to ‘common’ parts, which have no specific position code of their own (e. g. screws, washers, …) * In case another action than replacement was taken, ‘quantity’ field must be ‘ 0’ (zero) or left blank.

Parts Flag F The “Flag” is an indication of the “most important” part * Usually, several different parts are replaced during one repair, although mostly just one part is found to be the real cause of the symptom. * In case different symptoms are available, one “most important” part should be flagged per symptom.

The Non Technical Fault codes

NTF repairs (Non Technical Fault) F F F The possibility exists that for a variety of reasons , the user thinks a set is at faulty , he/she brings it to a servicer , and it appears after checking that there is no real technical fault. In these cases , it is useful to try and find out what the cause was for the user to consider his set faulty. For that reason , the NTF table was developed. After consultation with the user , it is possible to codify the cause of the problem , enter it into the system and use if for the same purposes and with same benefits as symptom codes. The NTF code table is developed according to the same principles as the Symptom code table , as a matrix

NTF repairs (Non Technical Fault) Problem Area Problem Reason

NTF repairs (Non Technical Fault) F How to insert the NTF code into the IRIS String ? * A normal symptom code is inserted (ex : no power : 111) * When no problem is found , a correct defect code can be inserted (ex: Defect code 4, No problem found, customer misunderstanding) * The repair code is also known as Y (return without repair) * The NPF code , either after consultation with the user , or by the technician when he is certain , is then inserted into the Section Code Area (ex: NTF code 121 : No battery fitted) * When processing the IRIS codes , the Defect code , and/or Repair code will indicate if the contents of the Section code is a real section , or an NTF code , there is no ambiguity.

Some typical repair examples F F A Video recorder is brought in and customer claims “Set has no colour; sometimes my tapes are damaged”; the receptionist codes these symptoms as respectively “ 1410” and “ 1660” The technician’s actions: * When playing a test tape, he sees that the first symptom is indeed present. * He suspects IC 101 in the Colour processing circuit, and replaces it; this doesn’t seem to solve the problem however. * After further troubleshooting, he finds a badly soldered resistor R 123 in the same circuit, which apparently by simple resoldering solves the problem. * Next he tackles the second symptom and checks the mechanism; he sees that cassette unloading sometimes blocks, apparently due to a worn guide (ref. 513) in the threading mechanism. * He replaces the guide in question, and also cleans the tape path. Testing reveals that also this problem is solved.

How this example is coded 1412 = (constantly) no colour in playback CPA = colour processing, analog the flags indicate the parts that were found to be the cause of each symptom defect unknown A = replaced D = resoldered THR = threading mechanism T = bad contact 2626 = (intermittently) irregular unloading of tape A = worn out TPT = tape path section Note that first original symptom code was extended, and the second one corrected, by the technician! E = cleaned

No parts used F F F When no parts are used , some fields are even more important for analysis Defect , Repair code as well as Section code should now give a good view on the problem and solution. Suppose a cassette deck is damaging tapes , the customer claims this. The technician finds the torque needs adjusting , and no parts need to be replaced. Correct and complete encoding will now make all the difference for later analysis.

F Poor coding : we can only know “some adjustment” took place F Better coding : Torque Potentiometer now we know exactly which adjustment was done Alignment

Reference of microphone F Misaligned Alignment In the above example , the reference to the microphone , along with the correct MIC section code give us the information which part was not correctly aligned.

Symptom problem F F Following is an example how NOT to use symptom coding. Suppose the customer did not give a clear symptom , Or the person who was at the frontline did not take care properly The result can be rather bad.

Microphone Power problem Battery cover, screw , connector cover , case assy , antenna ring Antenna This symptom does NOT match any of the parts !! Maybe it was entered as such at reception, but the technician should have corrected it

The same repair with corrected codes gives a lot more information !!