RoboCore

"කැප්ටන්.. ප්ලේන් එක ස්ටේබල් නැහැ! අපි ඉන්නේ මාරම උසකින්.. රන්වේ එක කෙළවරේ තියෙන්නේ අඩි 250ක මහා ප්‍රපාතයක්! Go-Around කරන්න කැප්ටන්.. කරුණාකරලා ප්ලේන් එක ආයෙත් උඩට ගන්න!" සිංහලෙන් මෙහෙම කිව්වට මේක ඒ වෙලාවෙ මෙහෙම නෙවෙයි හොඳේ කිව්වෙ.

කොක්පිට් එක ඇතුළේ සහාය පයිලට් මරණ බයෙන් කෑගහනවා. හැබැයි ප්‍රධාන කැප්ටන්ගෙන් කිසිම සද්දයක් නැහැ. තත්පර ගණන් ගත වෙනවා. ප්ලේන් එක එකපාරටම රන්වේ එක දෙසට මහා වේගයකින් යනවා. මොකක්ද ඊළඟට වුණේ? හරි.. අපි මුල ඉඳන්ම බලමු මේ සත්‍ය ඛේදවාචකය.
මේක සිද්දවුණේ 2010 මැයි 22 වෙනිදා. ඩුබායි ඉඳන් ඉන්දියාවේ මංගලෝර් (Mangalore) බලා පියාසර කරමින් තිබ්බ Air India Express Flight 812 කියන Boeing 737-800 අති නවීන මගී ගුවන් යානයට. යානයේ මගීන් සහ කාර්ය මණ්ඩලය 166 දෙනෙක් ඉන්නවා. කවුරුත් දන්නේ නැහැ තමන්ගේ ජීවිත වල අන්තිම මිනිත්තු කිහිපයයි මේ දුවන්නේ කියලා.

1. මේ මුළු විනාශයටම මුල

ඇත්තටම මේ ෆ්ලයිට් එක පටන් ගන්න කලින්ම වැඩේ අනාගන්න පටන් අරන් තිබ්බේ. යානයේ ප්‍රධාන කැප්ටන් වුණු 55 හැවිරිදි සෙර්බියානු ජාතික සෙලැට්කෝ (Zlatko Glušica) මේ ෆ්ලයිට් එකට එන්න කලින් සති දෙකක නිවාඩුවක් ගත කරලා තමන්ගේ රටේ ඉඳන් ඇවිත් තිබ්බේ අනතුර වෙන්න දවස් දෙකකට කලින්.

ඔහුගේ සිරුරේ තිබ්බ Body Clock එක ඉන්දියාවේ වෙලාවට වඩා පැය 3 හමාරක් පස්සෙන් තිබ්බේ. දන්නවනෙ මේ සීන් එක. අපි අර සමහර වෙලාවට පාන්දර වෙනකන් ඇහැරල ඉන්න පුරුදු උනාම, අපි ඒකට හැඩගැහෙනවනෙ.. එතකොට අපි ඇහැරෙන්නෙ ගොඩක් දවල් වෙලා, අපේ ඇඟ හිතන්නෙ ඒ දවල් තමා උදේ කියලා.. ඒ කිව්වෙ දවල් 12 ට විතර ඇහැරුනාම ඇඟට අනුව නම් ඒක උදේ. ඒක තමයි මේ පයිලට්ට වෙලා තිබ්බෙ. ඒ මදිවට එදා රෑ එයාට ෆ්ලයිට් එකක් තිබ්බෙත් නැහැ, වෙන යාළුවෙක් වෙනුවට අන්තිම මොහොතේ තමයි මේකට සෙට් වුණේ. (ඔයාලට හිතෙන්න පුළුවන් ඇයි මෙහෙම අන්තිම මොහොතේ පයිලට්ලා මාරු කරන්නේ කියලා. 2010 දී Air India Express එකේ පයිලට්ලාගේ කාලසටහන් හැදුවේ modern software වලින් නෙවෙයි, නිකන්ම පෑනෙන් සහ කොළයෙන්! ඒ නිසා මේ වගේ අවුල් නිතරම වුණා).

යානය ඩුබායි වලින් පිටත් වුණේ පාන්දර 2.45ට විතර. වෛද්‍ය විද්‍යාවේ මේ පාන්දර 2 සිට 6 දක්වා කාලයට කියනවා Window of Circadian Low කියලා. තේරුණේ නැහැ නේද ඒක? හරි සරලවම කිව්වොත්, (මනුස්සයෙක්ගේ ඇඟේ තියෙන හෝමෝන සහ පද්ධති වල හැටියට දවස ඇතුළත මහන්සිය උපරිම වෙලා, අවධානය සහ ඒකාග්‍රතාවය බිංදුවටම බහින වෙලාව තමයි ඔය පාන්දර යාමය).

ඉතින් ප්ලේන් එක උඩට අරන් පැයක් විතර යද්දී මේ මහන්සිය කැප්ටන්ට උපරිමයටම වැදුණා. එයා සීට් එක පස්සට කරලා ඇස් දෙක පියාගත්තා.. තත්පර කිහිපයකින් කොක්පිට් එක ඇතුළේ කැප්ටන් ගොරවන සද්දය ඇහෙන්න ගත්තා! දැන් ප්ලේන් එක පාලනය කරන්න ඉතුරු වෙලා ඉන්නේ එකම එක පයිලට් කෙනෙක් විතරයි. සහාය පයිලට් (First Officer) හර්බින්දර් තනියම ATC එකට කතා කර කර, ප්ලේන් එකත් බලාගෙන පැය එකහමාරක් තිස්සේ ඩබල් ඩියුටි කරනවා. දැන් දෙන්නෙක්ගෙ වැඩේ කරන්නෙ එක්කෙනෙක්.

2. මංගලෝර් කියන මරණයේ රන්වේ එක

ප්ලේන් එක ලෑන්ඩ් කරන්න කිට්ටු වෙන්නේ මංගලෝර් වලට. ලංකාවේ අපේ කටුනායක වගේ නෙවෙයි, මංගලෝර් එයාර්පෝට් එක පිහිටලා තියෙන්නේ Tabletop Runway එකක් විදිහට. තේරුණේ නැහැ නේද ඒක? හරි සරලයි. ඒ කියන්නේ මහා උස් කන්දක් මුදුනක් විතරක් ඩෝසර් කරලා, සමතලා කරලා හදපු ධාවන පථයක්. ඒක සාමාන්‍ය රන්වේ එකකට වඩා පටුයි වගේම, ඒකේ කෙළවරේ තියෙන්නේ අඩි 250ක ලොකු ප්‍රපාතයක්! මේසයක් උඩ වගේ තමා වටෙන්ම ප්‍රපාත තියෙන්නෙ. ඒකයි ටේබල් ටොප් කියන්නෙ. මේවගේ ධාවන පථයක කිසිම දෙයක් වරදින්න බෑ.

ප්ලේන් එක ලෑන්ඩ් කරන්න සැතපුම් 80ක් තියෙද්දී සහාය පයිලට් විසින් අර නිදාගෙන ඉන්න කැප්ටන්ව හෙමින් ඇහැරවනවා. කැප්ටන් ඇහැරුණේ මාරම disoriented (නිකන් සිහිය විකල්ප වෙච්ච) ගතියකින්. මෙකට කියන්නේ Sleep Inertia කියලා. (ඒ කියන්නේ අපි තද නින්දකින් එකපාරටම ඇහැරුණාම, අපේ මොළයට Live තත්ත්වයක් ක්ෂණිකව තේරුම් ගන්න තත්පර ගණනාවක් යනවා, තීරණ ගැනීමේ හැකියාව සෑහෙන්න අඩු වෙනවා.. මතක් කරල බලන්නකො හොඳ සැප නින්දක ඉද්දි, කවුරුහරි හදිස්සියකට ඇහැරෙව්වම, ඇහැරුනාට පස්සෙ එකපාරට මේ කොහෙද ඉන්නෙ, කියල හිතෙනවනෙ, ප්‍රශ්නයක් එහෙම ඇහුවොත් එකපාරට උත්තර දීගන්නත් බෑනෙ. අන්න ඒ වගේ තමයි කැප්ටනුත් දැන්.).

කැප්ටන් ඇහැරෙද්දී ප්ලේන් එක තිබ්බේ ලෑන්ඩ් වෙන්න ඕන උසට වඩා සෑහෙන්න ඉහළින්. ඒ මදිවට එදා එයාර්පෝට් එකේ Area Radar එකත් වැඩ කළේ නැහැ. ප්ලේන් එක සාමාන්‍යයෙන් එන්න ඕන පාර මඟහැරිලා, රේඩියෝ signal වල ඇතිවුණු දෝෂයක් නිසා False 9-Degree Glide Slope එකක් පරිගණකයට අහු වුණා. (සාමාන්‍යයෙන් ප්ලේන් එකක් බිමට බහින්නේ අංශක 3ක වගේ සියුම් බෑවුමකින්. හැබැයි මේ කම්පියුටර් අවුල නිසා ප්ලේන් එක අංශක 9ක මහා දරුණු බෑවුමකින් කෙලින්ම පල්ලෙහාට විදින්න ගත්තා! අයියෝ අංශක 9 නම් පොඩීනෙ කියල හිතන්න එපා,, ප්ලේන් එකක් පහළට එද්දි air speed එක හරි විදිහට තියාගන්න නම් අංශක 3 ක වගේ පොඩි ඈන්ගල් එකකින් තමා පහලට එන්න ඕනෙ)

3. කොක්පිට් එක ඇතුළේ සිදුවීම

ප්ලේන් එක වේගයකින් පල්ලෙහාට යද්දී සහාය පයිලට් බය වුණා. එයා බෝඩ් එක බලලා කිව්වා "කැප්ටන් අපි ඉන්නේ මාරම උසක, රන්වේ එක කෙළින්ම පල්ලෙහා තියෙන්නේ, මේක ස්ටේබල් නැහැ" කියලා. ඊටපස්සේ කොක්පිට් එක ඇතුළේ automatic Alarms කෑගහන්න ගත්තා.. "SINK RATE! PULL UP!" කියලා.

සහාය පයිලට් මරණ බයට 3 වතාවක්ම කැප්ටන්ට කිව්වා "Go-Around කරන්න" (ලෑන්ඩ් කරන්නේ නැතුව ප්ලේන් එක ආයෙත් උඩට ගන්න. Go around කියන්නෙ ආපහු උඩට අරන් වටයක් ගහල හරි විදිහට land කරන්න එමු කියන එක) කියලා. හැබැයි කැප්ටන් තමන්ගේ නිදිමත නිසා සහාය පයිලට්ගේ අනතුරු ඇඟවීම් සියල්ලම සම්පූර්ණයෙන්ම නොසලකා හැරියා. ඔහු හිතුවා "මම මීට කලින් 16 පාරක් මෙතනට ප්ලේන් බස්සලා තියෙනවා, මට මේක කරන්න පුළුවන්" කියලා.

ප්ලේන් එක රන්වේ එකේ Threshold (පටන් ගන්න හරිය) පහු කරලා, අඩි 8000ක් දිග රන්වේ එකෙන් අඩි 5200ක්ම ඉවර වුණාට පස්සෙයි යානයේ රෝද බිම ගැටුණේ! හිතාගන්න පුලුවන්ද runway එකෙන් බාගයකටත් වඩා ඉවරයි, ඒ කියන්නේ මහා මගී ප්ලේන් එකක් නවත්වන්න ඉතුරු වෙලා තිබ්බේ අඩි 2800ක වගේ ඉතාම පුංචි පරාසයක් විතරයි.

4. අන්තිම තත්පරයේ මාරාන්තික තීරණය

රෝද බිම වැදිලා, යානය බ්‍රේක් කරලා නවත්වන්න බැරි බව තේරුණු සැනින් කැප්ටන් මාරාන්තික වැරැද්දක් කළා. ඔහු ඔන් කරලා තිබ්බ Thrust Reversers (මේ thrust reversers කියන්නෙ ප්ලේන් එකක එන්ජින් එකක තියන බලයම ප්ලේන් එක නවත්තන්න පාවිච්චි කරන එක. එන්ජින් එකේ පිටිපස්සෙන් පියන් දෙකක් වගේ ඇරිල තමයි මේක වැඩකරන්නෙ. කමෙන්ට් වල දාන්නම් ෆොටෝ එකක්) එකපාරටම off කරලා, යානය ආයෙත් අහසට ගන්න (Go-Around කරන්න) හිතාගෙන Engines වල Throttle එක ඉස්සරහටම තල්ලු කරලා Full power දුන්නා! හැබැයි අර කිව්ව පියන් දෙක වැහිලා ඉවර වෙන්න තත්පර කිහිපයක් යන නිසා,(මේ වගේ තීරණාත්මක අවස්ථාවක තප්පරයක් කියන්නෙත් මාර වටිනවනේ) ප්ලේන් එකට උඩට යන්න අවශ්‍ය වේගය ලැබුණෙත් නෑ, තිබ්බ බ්‍රේක් බලයත් නැති වුණා!

නමුත් ඒ වෙනකොට රන්වේ එක ඉවර වෙලා තිබ්බේ. ප්ලේන් එක රන්වේ එක කෙළවරේ තිබ්බ වැලි බාධකය කඩාගෙන ගිහින්, එතන තිබ්බ ILS ඇන්ටනා කුළුණක දකුණු තටුව වැදිලා සම්පූර්ණයෙන්ම කුඩු වුණා. තටුව කැඩුණු සැනින් යානය මහා ප්‍රපාතයෙන් පල්ලෙහාට පෙරළිලා, ක්ෂණයකින් ගිනි ගෙන අළු වෙලා ගියා.

166 දෙනෙක්ගෙන් බේරුණේ මගීන් 8 දෙනෙක් විතරයි. ඉතිරි 158 දෙනාම අඟුරුවෙලා ජීවිතක්ෂයට පත්වුණා. පස්සේ කරපු පරීක්ෂණ වලින් හෙළිවුණා කැප්ටන් අන්තිම මොහොතේ Full power නොදී දිගටම බ්‍රේක් කරගෙන ගියා නම් ප්ලේන් එක ප්‍රපාතයට වැටෙන්නේ නැතුව වැලි බාධකයේ නතර වෙන්න ඉඩ තිබ්බා කියලා!

මේ අනතුරෙන් පස්සේ තමයි ලෝකයේ ගුවන් සේවා නීති සම්පූර්ණයෙන්ම වෙනස් කරලා CRM (Crew Resource Management) කියන දේ අනිවාර්ය කළේ. ඒ කියන්නේ කොක්පිට් එක ඇතුළේ සහාය පයිලට් කෙනෙක් "Go-around" එකක් ඉල්ලුවොත්, ප්‍රධාන කැප්ටන් තමන්ගේ තීරණේ පස්සට දාලා ඒකට අවනත වෙන්න ඕනෙ කියන එක!

මම මේ Air India 812 යානය ප්‍රපාතයට වැටිලා තියෙද්දි ගත්ත ඇත්තම ඡායාරූපයක් කමෙන්ට් සෙක්ෂන් එකේ දාලා තියන්නම්. බලන්න ඔයාලා මීට කලින් මේ මංගලෝර් අනතුර ගැන අහලා තිබ්බද කියලා.

⚡

අපි අද කතාකරන්න යන්නේ නැව් අනතුරක් ගැන. එකම එක වයර් එකක් ඩැමේජ් වීමෙන් ඇතිවුණු පුංචි මෘදුකාංග දෝෂයක් (Software Bug) නිසා, මගීන් 1500ක් දාගත්ත මහා දැවැන්ත සුඛෝපභෝගී නැවක්, තමන් යන පාර සම්පූර්ණයෙන්ම වැරදිලා ගිහින් ගල් පරයක හැප්පුනු සත්‍ය කතාවක් ගැන.

දින වකවානුත් එක්කම කියනවා නම්, මේක සිද්දවුණේ 1995 ජූනි 10 වෙනිදා. Bermuda දූපත් වල ඉඳන් ඇමරිකාවේ Boston බලා යාත්‍රා කරමින් තිබ්බ "Royal Majesty" කියන මාරම සුඛෝපභෝගී, තට්ටු ගණනාවක විශාල නැවට. නැව ඇතුළේ කැසිනෝ, ස්විමින් පූල්, සුපිරි කෑම කමින් මගීන් 1500ක් මාරම සැහැල්ලුවෙන් නිවාඩුව ගත කරනවා. නැවේ කැප්ටන් ඇතුළු නාවික නිලධාරීන් කණ්ඩායමත් මාරම සැහැල්ලුවෙන් හිටියේ, මොකද නැව පාලනය වුණේ අති නවීන Auto-pilot පද්ධතියකින්. කවුරුත් දන්නේ නෑ රෑ කළුවරේම මුළු නැවම ලොකු අනතුරකට ලක්වෙන්නයි යන්නේ කියලා. බයවෙන්න එපා ටයිටැනික් වගේ නැව ගිලෙන්නෙ නෑ.

රෑ 10.25ට විතර එකපාරටම මුළු නැවම හොල්ලගෙන මහා සද්දයක් ආවා. නැව එකපාරටම ගැස්සිලා නතර වුණා. කැප්ටන් ඇතුළු නිලධාරීන් වහාම බ්‍රිජ් එකට (නැව පාලනය කරන ප්‍රධාන කාමරයට) දුවලා Screen ටික බැලුවා. හැමෝටම පුදුමයි, මොකද Screen එකේ පෙන්වන්නේ නැව තවමත් යන්නේ නියමිත ගැඹුරු මුහුදු මාර්ගයේමයි කියලා! හැබැයි ඇත්තටම නැව ගිහින් හැප්පිලා තිබ්බේ Nantucket කියන ප්‍රදේශයේ තියෙන, සාමාන්‍යයෙන් නැව් යන්නේ නැති නොගැඹුරු වැලි කන්දක (Rose and Crown Shoal එකක).

තේරුණේ නෑ නේද, පරිගණක තිරයේ නැව නියමිත පාරේ පෙන්වද්දී, ඇත්ත ලෝකයේදී නැව වෙන කොහේ හරි ගිහින් හැප්පුනේ කොහොමද කියලා? හරි, අපි පැහැදිළි කරගමු මෙතන වෙච්ච තාක්ෂණික අවුල.

මේ නැවේ තිබ්බා IBS (Integrated Bridge System) කියලා ගොඩක් වැදගත් system එකක්.. නැව යන්න ඕන පාර (Route එක) කලින්ම සිතියම් එක්ක මේකට දාලා තියෙන්නේ. මේකට නැව තියෙන තැන (Live location එක) හරියටම ලැබෙන්නේ නැවේ වහල උඩ (Fly bridge එකේ) සවි කරලා තිබ්බ GPS ඇන්ටනාවෙන්.
හැබැයි නැව ගමන පටන් අරන් පැය කිහිපයක් යද්දී, මේ GPS ඇන්ටනාවේ තිබ්බ පුංචි Cable එකක් ඇදිලා ගැලවිලා ඇන්ටනාව ක්‍රියාවිරහිත වුණා! පස්සේ හොයලා බලද්දී තමයි දන්නේ, මේ වයර් එක කිසිම ප්‍රොටෙක්ෂන් එකක් (Conduit/Casing) නැතුව නිකන්ම වහල උඩ දාලා තිබ්බ එකක් විතරක් නෙවෙයි, නැව පේන්ට් කරපු සේවකයෝ මේ වයර් එක උඩින් දෙපාරක්ම පේන්ට් ගාලත් තිබ්බා! ඒ නිසා වයර් එක දිරලා හෝ ඇදිලා තමයි ගැලවිලා තියෙන්නේ. (ඔයාලට මේ accident එකේ full accident report එක කැමතිනම් download කරන් බලන්න පුලුවන්, මොකද මේ ගැන National Transportation Safety Board එකෙන් full investigation එකක් කරල තියනවා.)

සාමාන්‍යයෙන් අපේ ෆෝන් එකේ GPS නැති වුණාම "GPS signal lost" කියලා වැටෙනවානේ. අන්න ඒ වගේ මේ නැවේ සිස්ටම් එකෙනුත් ලොකු Alarm එකක් ගහන්න ඕනේ. හැබැයි මේ system එකේ තිබ්බ එක පුංචි Bug එකක් නිසා, ඒක කිසිම සද්දයක් දැම්මේ නැහැ, වැරදීමක් පෙන්වුවෙත් නැහැ!

ඒ වෙනුවට සිස්ටම් එක ස්වයංක්‍රීයවම Dead Reckoning (DR) කියන Mode එකට මාරු වුණා. තේරුණේ නෑ නේද මොකක්ද මේ Dead Reckoning කියන්නේ කියලා? හරි සරලවම කියන්නම්. (හිතන්න ඔයා ඇස් දෙක පියාගෙන කාමරේක පියවර 10ක් ඉදිරියට යනවා කියලා, එතකොට ඔයා ඇස් පියාගෙන හිටියත් ඔයා දන්නවා ඔයා දැන් ඉන්නේ කොතනද කියලා. අන්න ඒ වගේ GPS නැති වුණාම, නැවේ අන්තිමට තිබ්බ Location එකයි, නැවේ වේගයයි, නැව හැරිලා තියෙන පැත්තයි පාවිච්චි කරලා "නැව දැන් මෙන්න මෙතන ඇති" කියලා පරිගණකය විසින්ම දන්නා ගණිත සූත්‍ර පාවිච්චි කරලා අනුමාන කරන එකට තමයි Dead Reckoning කියන්නේ. ඒ කියන්නෙ මේකෙදි බාහිර බලපෑම් සැලකිල්ලට ගන්නෙ නෑ.. ඒක නිසා ලොකේෂන් එක හරියන්නත් පුලුවන් වරදින්නත් පුලුවන්.මේක තේරුනේ නැත්තන් පහළින් කමෙන්ට් එකක් දාන්න පැහැදිළි කරන්නම්. ).

ඔන්න ඔතනදී තමයි ලොකුම අවුල සිද්දවුණේ. නැවේ Auto-pilot එක හැප්පෙනකම්ම තමන්ගේ නියමිත කෝණය වුණු අංශක 336 ම මාරම ලස්සනට තියාගෙන ගියා. හැබැයි පරිගණකය "නැව දැන් මෙතන ඇති" කියලා ලස්සනට පෙන්වුවාට, ඒ මෘදුකාංගයට එක දෙයක් ගණන් හදන්න බැරි වුණා. ඒ තමයි මුහුදේ තියෙන ප්‍රබල දියවැල් (Ocean Currents) සහ තද සුළඟ නිසා නැව පැත්තකට තල්ලු වෙන එක (අපි මේකට කියනවා Wind drift/Sea drift කියලා ). මෙන්න මේක තමයි dead reckoning වල තියන අවුල.

පැය 34ක් තිස්සේ පරිගණකය Screen එකේ පෙන්වුවේ නැව කෙළින්ම නියමිත පාරේ යනවා කියලා වුණත්, ඇත්ත ලෝකයේදී දියවැල් සහ සුළඟ නිසා නැව තමන්ගේ නියමිත පාරෙන් සැතපුම් 17ක් (17 Miles) පැත්තකට තල්ලු වෙලා (Drift වෙලා) ගිහින් තිබ්බා! අංශකයකින් බැලුවොත් මේක නිකන්ම අංශක 0.5ක වගේ පුංචි ලිස්සීමක්, හැබැයි මුහුදේ පැය ගණනක් යද්දී ඒ පුංචි අංශක භාගයේ වෙනස සැතපුම් 17ක මහා වෙනසක් වුණා.
තවත් පුදුම හිතෙන කතාවක් තියෙනවා. නැව වැලි කන්දේ හැප්පෙන්න පැය කිහිපයකට කලින්, නිලධාරීන් වටපිට බැලීමේදී මුහුදේ පාවෙන සමහර සලකුණු (Buoys) සහ ඈතින් තිබ්බ ප්‍රදීපාගාරයක (Light house) එළිය දැක්කා. ඔවුන්ගේ අත්දැකීම් අනුව ඒ ලයිට් තියෙන්න ඕනේ පාරේ නෙවෙයි. හැබැයි ඔවුන් "අපේ අති නවීන කොම්පියුටර් සිස්ටම් එක බොරු කියන්නේ නෑනේ" කියලා තමන්ගේ ඇස් දෙක සහ අත්දැකීම් විශ්වාස කරන්නේ නැතුව, අර වයර් එකක් ගැලවුණු පරිගණකය 100% ක් විශ්වාස කළා!

නැව හැප්පුණාට පස්සේ මගීන්ටයි නැවටයි මොකද වුණේ? 🚢💔

නැව එකපාරටම වැලි කන්දේ ගැටිලා හිරවුණාට පස්සේ කැප්ටන් වහාම ඇන්ජින් කාමරයට කතා කරලා කිව්වා නැවේ යට තට්ටුව (Double bottom hull) සහ ඉන්ධන ටැංකි ඉක්මනටම චෙක් කරන්න කියලා. වාසනාවකට වගේ නැවේ යට යකඩ තහඩු තලාගෙන ගිහින් තිබ්බත්, සිදුරු වීමක් හෝ මුහුදට තෙල් කාන්දු වීමක් වෙලා තිබ්බේ නැහැ.

(මෙතනදී තවත් සිද්ධියක් වෙනවා, කැප්ටන් මේ ගැන වහාම Coast Guard එකට කියන්න හදද්දීම, නැවේ හිටපු එක මගියෙක් තමන්ගේ පෞද්ගලික Cellular Phone (ජංගම දුරකථනය) එකකින් කෙලින්ම Coast Guard එකට කෝල් එකක් දීලා නැව හැප්පුණු වග කියලා තිබ්බා! මේක මේ accident report එකේ තිබ්බෙ හොඳේ…)

නැව හිරවුණු ගමන් නැවේ ප්‍රධාන ඇන්ජින් පාවිච්චි කරලා ඒක තනියම ගලවගන්න නිලධාරීන් පැය කිහිපයක්ම ට්‍රයි කළත් වැඩේ හරිගියේ නැහැ. ඊටපස්සේ මගීන් සහ ඔවුන්ගේ බඩු බාහිරාදිය වෙනත් කුඩා ප්‍රවාහන බෝට්ටු (Ferries) වලට මාරු කරලා බේරගන්න හැදුවත්, ඒ වෙලාවේ මුහුදේ කාලගුණය මාරම දරුණු විදිහට සවුත්තු වුණු නිසා ඒකත් කරන්න බැරි වුණා.

අන්තිමට ජූනි 11 වෙනිදා රෑ, ඒ කියන්නේ නැව හැප්පිලා දවසකට විතර පස්සේ, සමාගම විසින් සල්ලි වලට කුලියට ගත්ත දැවැන්ත ටග් බෝට්ටු (Tugboats) 5ක් එකතු වෙලා ලොකු මහන්සියකින් මේ මගීන් 1500ක් ඉන්න දැවැන්ත නැව වැලි කන්දෙන් ඇදලා මුදාගත්තා!

නැව නිදහස් කරගත්තට පස්සේ Coast Guard එකෙන් මේකට තනියම Boston වරායට යන්න අවසර දුන්නා. ජූනි 12 වෙනිදා නැව Boston වලට ලඟා වෙලා මගීන් සියල්ලම කිසිම කරදරයක් නැතුව ගොඩබිමට බස්සන්න සමත් වුණා. මුළු අනතුරෙන්ම එකම මනුස්සයෙක්ටවත් කිසිම තුවාලයක් හෝ මරණයක් සිද්දවුණේ නැහැ!

නැවේ අන්තිම ඉරණම

මගීන් බස්සලා ඉවර වුණු සැනින් නැව කෙලින්ම Baltimore වල තියෙන විශාල නැව් තටාකයකට (Drydock) අරන් ගියා රෙපෙයාර් කරන්න. නැවේ යට තිබ්බ අඩි 51ක් දිග වගේම අඩි 41ක් පළල ලොකු යකඩ තහඩු පද්ධතියක් සම්පූර්ණයෙන්ම කපලා අයින් කරලා අලුතින් දාන්න සිද්දවුණා.
නැව හදන්න විතරක් ඩොලර් මිලියන 2ක් ගිය අතර, නැව දුවන්න බැරි වුණු දවස් ටිකේ සිද්දවෙච්ච පාඩුවත් එක්ක සමස්ත අලාභය ඩොලර් මිලියන 7ක් වුණා. හැබැයි ඉංජිනේරුවෝ කොහොමහරි වැඩේ කරලා, අනතුර වෙලා දින 14ක් ඇතුළත (ජූනි 24 වෙනිදා) නැව සම්පූර්ණයෙන්ම හදලා ඉවර කරලා ආයෙත් සාමාන්‍ය විදිහටම මගී ප්‍රවාහන සේවයට එකතු කළා!
දැන් තේරුණා නේද අපි මේ කරන ඉංජිනේරු වැඩ වලදී, එක සෙන්සර් එකක් ෆේල් වුණොත් ඒක සිස්ටම් එක විසින් හැන්ඩ්ල් කරන්න ඕනේ කොහොමද සහ එකම සෙන්සර් එකක් මත විතරක් සම්පූර්ණයෙන්ම විශ්වාසය තැබීමේ තියෙන අනතුර කොච්චරද කියලා. රොබෝ කෙනෙක් හැදුවත් GPS විතරක් නෙවෙයි, IMU, Wheel Encoders වගේ Redundant සෙන්සර් ගොඩක් දාන්නේ අන්න ඒකයි.

බලන්න ඔයාලා මීට කලින් මේ Dead Reckoning කියන Navigation සංකල්පය ගැන අහලා තිබ්බද කියලා. ඇත්තටම මේ සිද්ධිය එච්චර හිතන්න දෙයක් නොවුනට ඔයාලට dead reckoning ගැන පොඩි අයිඩියා එකක් දෙන්න තමයි මේ කතාව ලිව්වේ.

එහෙනම් ඊළඟ පෝස්ට් එකෙන් තවත් මේ වගේ කතාවක් අරගෙන එන්නම්.!

⚡

අපි අද කතාකරන්න යන්නේ හැමදාම කතාකරන Circuit කෑලි ගැන නෙවෙයි. කෝඩින් හරි සොෆ්ට්වෙයා වල හරි සිද්දවෙන එකම එක පුංචි වැරදීමකින්, අහස මැදදී මිනිස්සු 315 දෙනෙක්ගේ ජීවිත තත්පර ගණනකින් නැතිවෙලා යන්න ගිය, හැබැයි නූලෙන් බේරුණු සත්‍ය කතාවක් ගැන.

දින වකවානුත් එක්කම කියනවා නම්, මේක සිද්දවුණේ 2008 ඔක්තෝබර් 7 වෙනිදා. සිංගප්පූරුවේ ඉඳන් ඕස්ට්‍රේලියාවට පියාසර කරමින් තිබ්බ Qantas Flight 72 කියන Airbus A330 අති නවීන මගී ගුවන් යානයට. යානය තිබ්බේ අඩි 37,000ක් ඉහළ අහසේ, මාරම සාමකාමී පරිසරයක. මගීන් සමහර අය නිදි, සමහර අය කෑම කනවා. කවුරුත් දන්නේ නෑ තව තත්පර කිහිපයකින් මුළු යානයම අපායක් වෙන්න යනවා කියලා.
එකපාරටම කිසිම හේතුවක් නැතුව කොක්පිට් එකේ තිබ්බ Master Warning Alarms ඔක්කොම කෑගහන්න ගත්තා. යානයේ වේගය මනින සෙන්සර්, උස මනින සෙන්සර් එකිනෙකට වෙනස් අගයන් පෙන්වන්න ගත්තා.(ප්ලේන් එකක අපි මේවට සාමාන්‍යෙන් කියන්නෙ Flight instruments කියලා) පයිලට්ලා කලබල වුණා. හැබැයි ඒ කලබලය ඉවර වෙන්නත් කලින්, යානයේ පරිගණකය (Flight Control Computer) එකපාරටම තීරණය කළා යානය අනතුරක තියෙන්නේ කියලා. මේක මෙහෙම වෙන්න හේතුව, යානයක් ඉහල අහසෙ යද්දි ඒක Auto pilot දානවා. ඒ කියන්නෙ යානය යන්න අවශ්‍ය navigation සහ location data පාවිච්චි කරලා තනියම යන්න කියල දෙනවා. මේක අනිවාර්‍යෙන් කරන දෙයක් මොකද පයිලට්ල සම්පූර්ණයෙන්ම handle කරන්නෙ takeoff and landing කියන දෙක සහ emergency අවස්ථා තමා.

හරි අපි ආපහු කතාවට යමු.

ඊළඟ තත්පරයේදී පයිලට්ලා කිසිම දෙයක් නොකර, යානය ස්වයංක්‍රීයවම තමන්ගේ ඉදිරිපස (Nose එක) පල්ලෙහාට හරවලා අංශක 8.4ක කෝණයකින් වේගයෙන් පොළොව දෙසට කඩාගෙන වැටෙන්න ගත්තා! තේරුණේ නෑ නේද එකපාරටම මොකද වුණේ කියලා? හරි අපි බලමු මෙතන වෙච්ච අවුල.
යානය ඇතුළේ තිබ්බා LTN-101 ADIRU (Air Data Inertial Reference Unit) කියලා ඉතාම වැදගත් සෙන්සර් පද්ධතියක්. මේකෙන් කරන්නේ යානයේ කෝණය, වේගය වගේ දේවල් මැනලා පරිගණකයට දෙන එක. හැබැයි මේ පද්ධතිය ඇතුළේ තිබ්බ මෘදුකාංගයේ (Software) එක පුංචි Coding වැරදීමක් (Data corruption bug එකක්) තිබ්බා. මේක මේ විදිහට සරලව කිව්වෙ ඔයාලට තේරෙන්න. Coding කිව්වම හිතන්න එපා නිකන් අපි අර python වල ගහනව වගේ කෝඩ් කියලා.. මේව සෙන්සර් ගොඩක් එක්ක ලොකු ඩේට ප්‍රමාණයක් හැන්ඩ්ල් කරන්න හදල තියන සිස්ටම් නෙ.

සිද්ධිය වෙච්ච වෙලාවේ මේ සෙන්සර් එකෙන් පරිගණකයට වැරදි ඩේටා එකක් (Angle of Attack එක අසීමිත ලෙස ඉහළයි කියලා, ඒ කිව්වෙ ප්ලේන් එක හරි කෙලින් තිරස්ව යද්දිත්, මේකෙ ඉස්සරහ උඩ ගිහින් කියල වැරදි ඩේට එකක් තමා control unit එකට ගියේ) යැවුණා. සාමාන්‍යයෙන් මෙහෙම වුණාම වෙන්න ඕනෙ පරිගණකය විසින් "මේක වැරදි දත්තයක්" කියලා ඒක අතහැරලා දාන එකයි. හැබැයි අර ප්‍රෝග්‍රෑම් එකේ අවුල නිසා යානයේ ප්‍රධාන පරිගණකය රැවටුණා යානය උඩට කැරකිලා අනතුරක් වෙන්න යනවා කියලා. අන්න ඒ නිසා යානය බේරගන්න කියලා හිතාගෙන පරිගණකය විසින්ම ස්වයංක්‍රීයව යානය පල්ලෙහාට හැරෙව්වා!

ඔයාලට හිතාගන්න පුළුවන්ද යානය ඇතුළේ මොකද වුණේ කියලා? යානය එකපාරටම පල්ලෙහාට හැරෙද්දී ඇතිවුණු සෘණ ගුරුත්වාකර්ෂණය (-G force) නිසා සීට් බෙල්ට් දාලා නොහිටපු මගීන් ( යානයක් ඉහළ අහසෙ යද්දි සාමාන්‍යෙන් seat belt ගලවගෙන ඉන්න පුලුවන් අපිට), කෑම ට්‍රොලි, බඩු බාහිරාදිය ඔක්කොම විසිවෙලා ගිහින් යානයේ වහලයේ වැදුණා! මිනිස්සු කෑගහනවා, හැමතැනම ලේ, හැමතැනම කෑම..

පයිලට්ලා උපරිම ශක්තිය දාලා යානයේ Control Stick එක පස්සට ඇද්දත් වැඩක් වුණේ නැහැ, මොකද පරිගණකය පයිලට්ගේ අණ නොසලකා හැරලා ඒක ක්‍රියාත්මක වුණේ. තත්පර 2ක් ඇතුළත යානය අඩි 650ක් පල්ලෙහාට කඩාගෙන වැටුණා. ඊටපස්සේ යානය ආයෙත් සාමාන්‍ය තත්වයට ආවා. පයිලට්ලා හුස්මක් ගන්න හදද්දීම, අර වැරදි දත්තය ආයෙත් ආපු නිසා යානය දෙවැනි පාරටත් එකපාරටම පල්ලෙහාට කඩාගෙන වැටෙන්න ගත්තා!

කොහොමහරි පයිලට්ලාගේ තිබ්බ අති දක්ෂකම නිසා, ඔවුන් Auto-pilot සහ අනෙකුත් පද්ධතීන් ක්‍රියාවිරහිත කරලා, යානය අතින් පාලනය (Manual Control) කරගෙන, ඉතාම අමාරුවෙන් ඕස්ට්‍රේලියාවේ ලියර්මන්ත් (Learmonth) කියන පාළු ගුවන් තොටුපළකට යානය හදිසියේ ගොඩබස්වන්න සමත් වුණා. මගීන් සහ කාර්ය මණ්ඩලයේ 100කට වඩා තුවාල ලැබුවත්, වාසනාවකට එකම මිනිස් ජීවිතයක්වත් නැතිවුණේ නැහැ.
පස්සේ කාලෙක මේ ගැන කරපු ලොකු පරීක්ෂණයකින් තමයි හෙළිවුණේ, මේ මුළු විනාශයටම හේතුව අර සෙන්සර් එකෙන් ආපු වැරදි දත්ත 8-bit ද 16-bit ද කියලා වෙන් කරගන්න බැරුව පරිගණක මෘදුකාංගය ඇතිකරපු "Data Corruption" එකක් කියලා.

දැන් තේරුණා නේද අපි මේ කරන කෝඩින් (Coding) වල, සෙන්සර් දත්ත (Sensor Data) හැන්ඩ්ල් කරන එකේ තියෙන වටිනාකම සහ වගකීම කොච්චරද කියලා. රොබෝ කෙනෙක්ගේ කෝඩින් වැරදුණොත් රොබෝ හැප්පෙයි එක්කො වැඩ නැතුව යයි, හැබැයි ගුවන්යානයක කෝඩින් වැරදුණොත් සිය ගණනකගේ ජීවිත ඉවරයි.

මම මේ අනතුර සිද්දවෙච්ච වෙලාවේ යානය ඇතුළේ වහලයට මිනිස්සු විසිවෙලා වහලය කැඩිලා තිබ්බ ඇත්තම ෆොටෝ එකක් කමෙන්ට් සෙක්ෂන් එකේ දාලා තියන්නම්. බලන්න ඔයාලා මීට කලින් මේ Qantas 72 අනතුර ගැන අහලා තිබ්බද කියලා.
ඔයාලටත් කෝඩින් කරද්දී මේ වගේ "Logical Bugs" අහුවෙලා තියෙනවා නම්, ඒ අත්දැකීම් පහළින් කමෙන්ට් කරන්න. එහෙනම් ඊළඟ පෝස්ට් එකෙන් තවත් මේ වගේ කතාවක් කතාකරමු. ගිහින් එන්නම්!

⚡

අපි අද කතාකරන්න යන්නේ Pixel LED (නැත්නම් Addressable LED) ගැන. දැන් වෙසක් කාලේ ලඟ නිසා හැමෝම තමන්ගේ ගෙවල්, වෙසක් කූඩු ලස්සන කරන්න මේ Pixel LED වැල් ගන්න බලනවා ඇති. සාමාන්‍ය LED වැල් වගේ නෙවෙයි, මේවයින් එක එක බල්බ් එක වෙන වෙනම පාට කරලා ලස්සන රටා හදන්න පුළුවන් නිසා දැන් මේක මාරම Trend එකක්.
අපි අද කතාකරමු, මොකක්ද මේ Pixel LED එකක් ඇතුළේ වෙන සෙල්ලම, සහ අපි වැඩක් කරද්දී හැමෝටම වැරදෙන ලොකුම ප්‍රශ්නයක් ගැන.
සරලවම කිව්වොත් Pixel LED වැලක තියෙන්නේ වයර් 3යි නෙ. පවර් දෙන වයර් දෙකයි (5V සහ GND), සිග්නල් එක යන Data වයර් එකයි. හැබැයි මේකේ සිය ගණනක් තියෙන බල්බ් වලට වෙන වෙනම වයර් නැතුව එකම වයර් එකකින් දත්ත යවන්නේ කොහොමද? තේරුනේ නෑ නේද කියපු එක? හරි, අපි පැහැදිළි කරගමු මේක.
මේ හැම බල්බ් එකක් ඇතුළේම පුංචි Microchip එකක් (IC එකක්) තියෙනවා (ඔයාලා අහලා ඇති WS2812B හෝ WS2811 කියලා). අපේ Controller එකෙන් (උදාහරණයක් විදිහට Arduino හෝ ESP32 එකකින්) දෙන සිග්නල් එක මුලින්ම යන්නේ පළවෙනි බල්බයට. ඒ බල්බය තමන්ට ඕන පාට තියාගෙන, ඉතිරි සිග්නල් ටික ඊළඟ බල්බයට Pass කරනවා. ඒක හරියට පන්තියක ළමයි පෝලිමට ඉඳගෙන අතින් අත බඩු පාස් කරනවා වගේ වැඩක්. මේක මාරම වේගයෙන් සිද්දවෙන නිසා තමයි අපිට ලස්සන Animation පේන්න ගන්නේ.
එතකොට මොකක්ද මේකෙදි හැමෝටම වැරදෙන ලොකුම ප්‍රශ්නේ? අන්න ඒක තමයි අපි දැන් කතාකරන්න යන්නේ.
අපි උදාහරණයක් විදිහට Pixel වැල් 3ක් 4ක් දිගටම එකට ගැටගහලා එක කොණකින් විතරක් පවර් (5V) දෙනවා කියලා හිතමු. මෙන්න මේ වෙලාවෙදි ඔයාලට දකින්න ලැබෙයි වැලේ අන්තිම හරියට යද්දී බල්බ් වල පාට නිල් හෝ කොළ වෙන්නේ නැතුව, ලා තැඹිලි හෝ රතු පාට වෙනවා. නැත්නම් බල්බ් ගැස්සෙන්න (Flicker වෙන්න) ගන්නවා.
ඇයි මෙහෙම වෙන්නේ? අපිට තේරුනේ නැතුවට, වයර් එක දිගටම යද්දී ඒකේ තියෙන ප්‍රතිරෝධය නිසා Voltage එක ටික ටික අඩු වෙන්න ගන්නවා. මේකට කියන්නේ Voltage Drop එකක් කියලා. මුලින් දීපු 5V එක අන්තිම බල්බයට යද්දී 3.5V විතර වෙනකම් බහින්න පුළුවන්. අන්න ඒ නිසයි අන්තිම බල්බ් ටික හරියට වැඩ කරන්නේ නැත්තේ.
ඉතින් මේකෙන් බේරෙන්න අපිට කරන්න පුළුවන් උපක්‍රමයක් තියෙනවා. ඒකට කියන්නේ Power Injection කියලා. කරන්න තියෙන්නේ මෙච්චරයි, දිග වැලක් පාවිච්චි කරද්දී එක කොණකින් විතරක් පවර් දෙන්නේ නැතුව, හැම බල්බ් 50කට හෝ 100කට වරක් පවර් සප්ලයි එකේ ඉඳන් වෙනමම ඇදපු 5V සහ GND වයර් කෙලින්ම වැලේ මැදට සහ අගටත් සම්බන්ධ කරන්න. එතකොට වැලේ හැම තැනටම එක වගේ පවර් එක ලැබිලා, මුළු වැලම එක වගේ ලස්සනට පත්තු වෙනවා!. ඔයාලා මීට කලින් pixel LED වලින් බුදුරැස්මාලා හදල තියනවනම් ඔයාලට මේ ගැන අත්දැකීම් ඇති…
දැන් තේරුනා නේද මේ Power Injection කතාව අපිට වෙසක් ලයිට් දාද්දී කොච්චර වටිනවද කියලා. බලන්න ඔයාලා මීට කලින් මේ ක්‍රමය පාවිච්චි කරලා තියෙනවද කියලා.
මේ වගේ Pixel LED එක්ක වැඩ කරලා ඔයාලට අත්දැකීම් තියනවනම්, නැත්නම් මොනවා හරි ප්‍රශ්න තියනවනම් පහළින් කමෙන්ට් කරන්න. වෙසක් ළඟ ළඟම එන නිසා ඔයාලට දැනගන්න දේවල් තියනවනම් අපි කතාකරමු ඒ ගැනත්. එහෙනම් මේ වගේ ඉලෙක්ට්‍රොනිකස්, රොබෝටික්ස් වල වැදගත් තවත් දෙයක් එක්ක ඊලඟ පෝස්ට් එකෙන් හමුවෙමු. ගිහින් එන්නම්!

ඔයාගෙ ලැප් එකේ battery health එක කිසිම software එකක් නැතුව බලාගන්න විදිහ දන්නවද? අපි අද කතාකරමු ඒ ගැන.

මේක හරිම සරල දෙයක්… ඒ වගේම ගොඩක් දුරට accurate data ගන්න පුලුවන්. ඔයාට කරන්න තියෙන්නේ, ඔයාගෙ ලැප් එකේ command prompt එක run as administrator දීල ඕපන් කරලා (cmd කියල windows search bar එකේ search කරාම මේක ඔයාට හොයාගන්න පුලුවන්.ඒක උඩ Right-click කරලා "Run as Administrator" දෙන්න. ) මෙන්න මේ command එක ගහන්න. දැන් මේ command එක ටයිප් කරලා Enter කරන්න: powercfg /batteryreport
දැන් ඔයාගේ C: drive එකේ (නැත්නම් screen එකේ පෙන්වන path එකේ) battery-report.html කියලා file එකක් හැදෙනවා. ඒක double-click කරලා open කරගන්න.
රිපෝට් එකේ බලන්න ඕනේ වැදගත්ම දේවල් දෙක තමයි,
Design Capacity vs Full Charge Capacity: * Design Capacity කියන්නේ ලැප් එක ෆැක්ටරියෙන් හදලා එවනකොට බැටරියේ තිබ්බ උපරිම ධාරිතාවය (mWh වලින්).
Full Charge Capacity කියන්නේ මේ වෙලාවේ ඒ බැටරියට උපරිම charge වෙන්න පුළුවන් ප්‍රමාණය. මේ අගයන් දෙකෙන් අපිට හොයාගන්න පුලුවන් දැන් බැට්‍රියට කොච්චර චාජ් එකක් දරාගන්න පුලුවන්ද කියලා. උදාහරණයට, 50000 mWh design capacity එකක් තිබිල, දැන් full charge capacity එක 25000 mWh උනොත් බැට්‍රි හෙල්ත් එක 50% යි. තේරුනා නේද?
Cycle Count:
බැටරියක් 0% ඉඳන් 100% වෙනකම් එක පාරක් full charge වීමට එක "Cycle" එකක් කියනවා. සාමාන්‍ය ලැප් එකක බැටරියක් සවුත්තු වෙන්න කලින් Cycles 300 - 500 ක් විතර දුවන්න පුළුවන්. Cycle count එක 400 පැනලා නම් ඒ බැටරිය ළඟදීම මාරු කරන්න වෙන්න ඉඩක් තියනවා.
Lanka ⚡

අපි අද කතාකරන්න යන්නේ Optocouplers ගැන. ඔප්ටොකප්ලර් එකක් කියන්නෙත් ඉලෙක්ට්‍රොනික් ලෝකයෙදි අපිට නැතුවම බැරි වටින component එකක්. අපි අද කතාකරමු, මොකක්ද මේ ඔප්ටොකප්ලර් එකක් කියන්නෙ, කොහොමද ඒක වැඩකරන්නෙ, අපේ වැඩවලට ඒක පාවිච්චි කරන්නෙ කොහොමද කියලා.

සරලවම කිව්වොත් ඔප්ටොකප්ලර් එකක් කියන්නෙ switching device එකක් කියල කියන්න පුලුවන්. ඒ කියන්නේ, අපිට පුලුවන් එක පැත්තකින් සිග්නල් එකක් දීල ඒක අනිත් පැත්තෙන් ගන්න. තේරුනේ නෑ නේද කියපු එක. හරි අපි පැහැදිළි කරගමු මේක. ඔප්ටොකප්ලර් එකක පැති 2 ක් තියනව ප්‍රධානවම, අපි සිග්නල් එක දෙන පැත්ත, ඒ කියන්නෙ input side එක සහ අපි සිග්නල් එක එලියට ගන්න පැත්ත. දැන් ඇයි මෙහෙම සිග්නල් එකක් දීල ඒකම ආපහු ගන්නෙ, නේද. මෙහෙමයි, මේකෙ අපි සිග්නල් එක දුන්නම වෙන්නෙ IR LED එකක් පත්තු වෙනව ඒ සිග්නල් එකට අදාලව, ඒ LED එක පත්තු උනාම, ඒකෙ ඒ ආලෝකය වැටිල අනිත් පැත්තෙ තියන කොටස (එතන තියෙන්නෙ phototransistor එකක්) සම්බන්ධ වෙනව, ඒ කියන්නෙ ස්විච් එකක් වගේ, Input සිග්නල් එකක් නැති වෙලාවට ඒක කැඩුන කම්බියක් වගේ, සිග්නල් එකක් දුන්නම ඒක සන්නායකයක් වගේ. දැන් ඔයාලට තේරුනා නේද මේක කොහොමද වැඩකරන්නෙ කියල.

එතකොට ඇයි මෙහෙම එකක් ඕන වෙන්නෙ. බලන්න මේකෙදි, අපි ඒ සිග්නල් එක එක පැත්තක ඉඳල අනිත් පැත්තට යවන්නේ ආලෝකය හරහා, එතකොට මොකක්ද මේකෙ වැදගත්කම. අන්න ඒක තමයි අපි දැන් කතාකරන්න යන්නේ. අපි උදාහරණයකර relay එකක් ගමු. දැන් හිතන්න අපි මේකෙන් AC current එකක් switch කරනව කියල. දැන් අපි සාමාන්‍ය විදිහට රිලේ එකේ කොයිල් එකට සප්ලයි එක දීල AC current එක switch කරනව කියල හිතමු, මෙන්න මේ වෙලාවෙදි අපිට තේරුනේ නැතුවට, voltage spike එන්න පුලුවන් ගොඩක් වෙලාවට, මොකද මෙතන වෙන්නෙ AC voltage switching නෙ. අන්න ඒ වෙලාවෙ, හිතන්න අපි මේ relay එක control කරන්නේ Arduino Board එකක් හරහා කියලා. අන්න එතකොට මේ ආඩියුනෝ බෝඩ් එකට මේක එච්චර හොඳ දෙයක් නෙවෙයි, අපි දාල තියන program එක අවුල් යන්න පුලුවන්, Arduino එක reset වෙන්න පුලුවන්. සමහර වෙලාවට arduino එක පිච්චෙන්න උනත් බැරි නැ. ඉතින් අන්න ඒ වගේ දේකින් වැලකෙන්න අපිට පාවිච්චි කරන්න පුලුවන්, මෙන්න මේ optocoupler තාක්ෂණය. මේකෙදි AC side එකයි, අපේ signal එක දෙන පැත්තයි අතර කිසිම වයර් හරහා සම්බන්ධයක් නෑනෙ, ආලෝකය හරහා තමයි සිග්නල් එක යන්නේ.. ඉතින් ආලෝකය හරහා මෙහාට ඒ වගේ voltage spikes එන්න බැනෙ. අන්න ඒ නිසා මේකෙදි අපේ controlling side එකේ තියන components ආරක්ෂා වෙනවා.දැන් තේරුනා නේද මේක අපිට ගොඩක් වටිනව කියලා. මම ඔයාලට මේ ගත්ත උදාහරණෙ ඇත්ත ලෝකෙ දකින්න තියනවා… මම කමෙන්ට් සෙක්ෂන් එකේ දාල තියන්නම් normal relay module එකක් සහ optocoupler isolated relay module එකක්. බලන්න ඔයාල relay module තෝරගද්දි මේක දැනගෙන හිටියද කියලා.

මේව එක්ක ඔයාලට අත්දැකීම් තියනවනම් පහළින් කමෙන්ට් කරන්න. ඒ වගේම මේ ගැන ඔයාලට මොනවහරි ප්‍රශ්න තියනවනම් ඒවත් පහළින් අපි කතාකරමු. එහෙනම් මේ වගේ ඉලෙක්ට්‍රොනික්ස් රොබෝටික්ස් වල වැදගත් දෙයක් කතාකරනකන් ඊලඟ පෝස්ට් එකෙන්, ගිහින් එන්නම්.

ඔයාලට ජය!!!

අපි කලින් post දෙකකින් කතාකලා අපි කොහොමද ඩයෝඩ් එකක් අපේ circuit එකක් ආරක්ෂා කරගන්න, ඒ කියන්නෙ පිච්චෙන එකෙන් වළක්වගන්න පාවිච්චි කරන්නෙ කියලා.

අපි නිතරම දකින සහ අහන්න ලැබෙන ඩයෝඩ් එකක් තමයි 1N4007 කියන්නෙ. හැබැයි ඕක විතරද තියන එකම ඩයෝඩ් එක සහ ඩයෝඩ් වර්ගය. ඇත්තටම නෑ, ඩයෝඩ් තව වර්ග ගොඩක් තියනවා. ඒ ගැන කියන්න කලින් මම මේ basic diodes වල තියන ප්‍රශ්නෙ සහ ඒක විසඳගන්න අපි මොනවද කරන්නෙ කියල කියල ඉන්නම්.

ඔයාල දන්නව ඇතිනෙ, අපි පොඩි කාලෙත් ඉගනගත්තා, මේ ඩයෝඩ් වල කරන්ට් එක යන්නෙ එක පැත්තකට කියල, නේද? එතකොට මේ ඩයෝඩ් එකක, එයාට කරන්ට් එක යන්න බැරි පැත්තට අපි කරන්ට් එක දෙන්න හැදුවොත් එයා හැදිල තියන semiconductors වල හැසිරීම නිසා, මේ ඩයෝඩ් එක කරන්ට් එකට යන්න දෙන්නෙ නැති වෙනව. ඒ කියන්නෙ අපි දන්න විදිහට මේ ඩයෝඩ් පාවිච්චි කරන්න පුලුවන් අපිට කරන්ට් එක එක පැත්තකට විතරක් යවන්න ඕනෙ උනාම. අපි ඒක දන්න දෙයක්නෙ. ඒ වගේම AC current එක DC කරගන්නත් අපි මේ ඩයෝඩ් පාවිච්චි කරනවනෙ. Rectifier කියල කියන්නේ. හැබැයි මේ වගේ AC current එකක frequency එක, ලොකු ගානක් වෙද්දි මේ සාමාන්‍ය ඩයෝඩ් වල ප්‍රශ්නයක් එනවා. අපි දන්නව සාමාන්‍යෙන් අපි ගෙවල්වල පාවිච්චි කරන AC supply එකේ frequency එක 50Hz-60Hz වගේනෙ. සාපේක්ෂව මේක පොඩි අගයක්. හිතන්න මේ වගේ එකක, frequency එක කිලෝ හර්ට්ස් ගනන් වලට ගියොත්, අන්න එහෙම බලද්දි ඒක ගොඩක් ලොකු අගයක්. අන්න ඒ වගේ වෙලාවල් වලට මේ ඩයෝඩ්, මේ ඩයෝඩ් කියල මම කියන්නෙ අපි කතාකරන සාමාන්‍ය 1N4007 වගේ general purpose ඩයෝඩ් ගැන. එතනදි වෙන දේ බැලුවොත්, ඇත්තටම ඩයෝඩ් එකක කරන්ට් එක යන්න බැරි පැත්තට කරන්ට් එක යවන්න හැදුවොත් එයා reverse bias (පසු නැඹුරු) වෙනව කියල අපි කියනවනෙ. මේ ක්‍රියාවලිය වෙද්දි වෙන්නෙ, කරන්ට් එක යන්න බැරි වෙන්න, voltage barrier එකක් ඩයෝඩ් එක ඇතුලෙ හැදෙන එක. මේක ගැන ඉලෙක්ට්‍රෝන මට්ටමට ගිහින්ම කතාකරන්න පුලුවන් මාතෘකාවක්, ඒත් අපි අද ඩයෝඩ් ගැන කතාකරන නිසා මම මේ voltage barrier එක ගැන ඔය විදිහට සරලව කියන්නම්. මෙන්න මේ voltage barrier එක හැදෙන්න යම් වෙලාවක් යනවා. ඒක එච්චර ගැටලුවක් නෑ, අපි අර කලින් කිව්ව වගේ frequency එක අඩු තැනකදි, ඒත් හිතන්න, ලොකූ frequency එකකින් AC current එකක් ආවොත් මොකද වෙන්නෙ කියලා. අර voltage barrier එක හැදෙන්නත් කලින් මෙයා කරන්ට් එකේ පැත්ත මාරු කරනවා, එහෙම බැලුවම ඒ වගේ high frequency වලදි මේක නිකන් කම්බි කෑල්ලක් වගේ කිසිම වැඩක් නැති දෙයක් වෙලා.

ඔන්න ඔය ප්‍රශ්නෙට විසඳුමක් විදිහට හොයාගෙන තියනව fast recovery / Ultra fast diodes. උදාහරණයක් විදිහට UF4007, FR107 වගේ කියන්න පුලුවන්. මේවයෙ reverse recovery time (t_rr) එක ගොඩක් අඩුයි, නැනෝ තත්පර ගානක් වෙන්නෙ. අන්න එතකොට ලොකු frequency එකක් තිබ්බත් මෙයාලට පුලුවන් පටස් ගාල අර අනිත් පැත්තට යන්න හදන කරන්ට් එක නවත්තන්න. මේ වගේ ඒව පාවිච්චි වෙන්නෙ මොන වගේ වෙලාවල් වලටද කියල හිතන්න පුලුවන්ද… ප්‍රායෝගික උදාහරණයක් කියන්නම්. අපි සාමාන්‍යෙන් මෝටරයක් control කරද්දි, ඒකෙන් එන High-frequency back EMF එක මේ වගේ UF diode එකක් දාල අපිට නවත්තගන්න පුලුවන්. ඒකෙන් අපේ driver එකේ IC එක ආරක්ෂා කරගන්න පුලුවන්. දැන් අලුතෙන් එන හොඳ motor drivers වල මේ protection methods පාවිච්චි කරල එයාල මේ වගේ ඩයෝඩ් දාලම එවන තැන් තියනවා. ඉතින් දැන් ඔයාලට තේරෙන්න ඇති, සාමාන්‍ය ඩයෝඩ් එකකයි, High speed switching diode එකකයි, තියන වෙනස. මීට අමතරව තව schottky diode කියල ජාතියකුත් තියනවා. අපි ඒක ගැන වෙනම දවසක කතාකරමු. මේව එක්ක ඔයාලට අත්දැකීම් තියනවනම් පහළින් කමෙන්ට් කරන්න. ඒ වගේම මේ ගැන ඔයාලට මොනවහරි ප්‍රශ්න තියනවනම් ඒවත් පහළින් අපි කතාකරමු. එහෙනම් මේ වගේ ඉලෙක්ට්‍රොනික්ස් රොබෝටික්ස් වල වැදගත් දෙයක් කතාකරනකන් ඊලඟ පෝස්ට් එකෙන්, ගිහින් එන්නම්.

ඔයාලට ජය!!!