Электроник, мэдээллийн технологийн чиглэлээр суралцаж байгаа, доорхи шаардлагуудыг хангасан, идэвхтэй, найдвартай оюутныг системийн загварчлал, симуляцийн чиглэлийн ажилд хамтран ажиллуулна. Уг ажлын талаархи товч мэдээллийг "Mapping of application model to architecture model" бичлэгт өгсөн байгаа. Энэ ажлыг сурахын хажуугаар хийх боломжтой, заавар зөвлөмж, харилцаа онлайн хэлбэрээр хийгдэх бөгөөд 2 долоо хоног тутамд ажлын тайланг авч байна. Эхлээд тодорхой асуудлыг шийдэх даалгавар өгч, гүйцэтгэлээс нь хамааруулан сонгон авна. Ажлын үргэлжлэх хугацаа доод тал нь 6 сар, сарын суурь хөлс 50 евро + шагнал.
Тавигдах үндсэн шаардлага:
- электроник, мэдээллийн технологийн чиглэлээр суралцаж байгаа
- англи хэл дээрх мэргэжлийн материалыг төвөггүй уншиж ойлгодог байх (ажлаа тайлагнаж, дүгнэж бичих чадвартай байвал бүр сайн)
- жава хэл дээр програм бичих дадлага, туршлагатай байх
- линукс үйлдлийн систем дээр ажиллаж байсан (гэхдээ шээл болон пэрл скрипт бичдэг бол бүр сайн)
Мөн дараахь дадлага, туршлагатай байвал бүр сайн:
- матлаб/симулинк дээр загварчилж байсан
- ЮМЛ диаграм ашиглан дээр загварчилж байсан
- микропроцессор бүхий жижиг электрон схем зохион бүтээж, туршиж байсан
Хэрэв эдгээр шаардлагыг хангаж байгаа гэж үзвэл, өөрийнхөө товч танилцуулгыг (CV ч юм уу) yahuumeel эт yahoo цэг com хаягаар илгээж, блогт давхар коммент үлдээнэ үү. Ямар ч тохиолдолд хариуг буцаан илгээх болно.
АНХААР! Зөвхөн коммент үлдээсэн тохиолдолд л имэйлээ шалгах болно.
Monday, July 27, 2009
Mapping of application model to architecture model (wireless sensor system)
The proposed work will cover the definition and implementation of a mapping mechanism that constructs an executable system model for an application-specific sensor network simulation. The desired system model, which will be based on a wireless sensor network, shall be built by using appropriate submodels that separately represent system behavior (function model), its physical implementation (architecture model) and application-specific model (i.e., mobility).
Function model: it describes target system behavior by using logical sensor entities, which provide typical sensor network functionalities, like sensor processing, radio communication, and data management. A behavior of such a logical entity would be given in certain separate state diagrams (compatible with UML statecharts). The sensor processing diagram represents basic operations for accessing sensors and processing sensor data, i.e., data averaging or compression. The communication diagram represents basic communication protocol and is the main part of the function model. The data management diagram specifies local data storage handling (data is removed after successful transmission or due to memory overflow). The function models can be defined for the source and destination entities differently.
Architecture model: it contains potential physical parameters for physical sensor nodes, that can be obtained from technical descriptions of available hardware platforms or some prototype models: sensor type/delay, memory size, processor type, radio transmission range/rate.
Two types of hardware architecture models are chosen: COTS (Berkeley Mica series) and SoC (VHDL/FPGA) models and both support the TinyOS operating system.
Application-specific model: radio channel models, group/individual mobility model.
Mapper: According to a given application scenario, it constructs a system model that comprises of aforementioned three separate models: function, architecture and application-specific models.
It takes certain parameters from application requirements: a number of the target objects (i.e., animal under biological study), additional properties/restrictions of the target objets and base stations (i.e., mobile or stationary, possible communications), study area, intended positions for obtaining data from the targets (if destinations are stationary), candidate sensor node hardware architecture (one or more) etc.
The mapper creates the same number of the instances (a simple PTII actor that can contain required parameters for the function and mobility models) for the source nodes; the amount is equal to a number of target objects. The maximum possible number of the instances for destination nodes (or base stations) will be derived from the number of the base stations (or their positions). By default, all source nodes will be mobile and all destination nodes will be stationary and only existing communication is between the sources and destinations (restriction: no communication between sources).
The system is verified by simulation and evaluated with certain metrics, such as connectivity/delay (a function of the numbers of sensors, destination nodes, and positions, communication protocol, memory), and power consumption/network lifetime (a function of architecture, communication protocol, and the numbers of sensors). Because of complexity in estimating power consumption, only connectivity/delay will be considered at first.
When any of source nodes is in communication distance of any of destination nodes and the destination node is active they will exchange data until the communication terminates due to distance. During communication, physical delays will be introduced by a channel model and the architecture model.
Possible application scenarios:
- mobile sources and stationary destinations
- both sources and destinations are mobile
- communication is only between sources and destinations, but not between sources
- communication is possible between sources, and sources and destinations.
- above scenarios in case of 2-3 different communication protocols (protocol descriptions will be taken from the Zebra project)
A diagram below shows structure of components that will be defined and implemented within the work.
Comment:
- Implementation (in blue, PTII actors)
- Definition (in pink, UML compatible)
- Definition (in green, actor-oriented/PTII compatible, classes)
Function model: it describes target system behavior by using logical sensor entities, which provide typical sensor network functionalities, like sensor processing, radio communication, and data management. A behavior of such a logical entity would be given in certain separate state diagrams (compatible with UML statecharts). The sensor processing diagram represents basic operations for accessing sensors and processing sensor data, i.e., data averaging or compression. The communication diagram represents basic communication protocol and is the main part of the function model. The data management diagram specifies local data storage handling (data is removed after successful transmission or due to memory overflow). The function models can be defined for the source and destination entities differently.
Architecture model: it contains potential physical parameters for physical sensor nodes, that can be obtained from technical descriptions of available hardware platforms or some prototype models: sensor type/delay, memory size, processor type, radio transmission range/rate.
Two types of hardware architecture models are chosen: COTS (Berkeley Mica series) and SoC (VHDL/FPGA) models and both support the TinyOS operating system.
Application-specific model: radio channel models, group/individual mobility model.
Mapper: According to a given application scenario, it constructs a system model that comprises of aforementioned three separate models: function, architecture and application-specific models.
It takes certain parameters from application requirements: a number of the target objects (i.e., animal under biological study), additional properties/restrictions of the target objets and base stations (i.e., mobile or stationary, possible communications), study area, intended positions for obtaining data from the targets (if destinations are stationary), candidate sensor node hardware architecture (one or more) etc.
The mapper creates the same number of the instances (a simple PTII actor that can contain required parameters for the function and mobility models) for the source nodes; the amount is equal to a number of target objects. The maximum possible number of the instances for destination nodes (or base stations) will be derived from the number of the base stations (or their positions). By default, all source nodes will be mobile and all destination nodes will be stationary and only existing communication is between the sources and destinations (restriction: no communication between sources).
The system is verified by simulation and evaluated with certain metrics, such as connectivity/delay (a function of the numbers of sensors, destination nodes, and positions, communication protocol, memory), and power consumption/network lifetime (a function of architecture, communication protocol, and the numbers of sensors). Because of complexity in estimating power consumption, only connectivity/delay will be considered at first.
When any of source nodes is in communication distance of any of destination nodes and the destination node is active they will exchange data until the communication terminates due to distance. During communication, physical delays will be introduced by a channel model and the architecture model.
Possible application scenarios:
- mobile sources and stationary destinations
- both sources and destinations are mobile
- communication is only between sources and destinations, but not between sources
- communication is possible between sources, and sources and destinations.
- above scenarios in case of 2-3 different communication protocols (protocol descriptions will be taken from the Zebra project)
A diagram below shows structure of components that will be defined and implemented within the work.
Comment:
- Implementation (in blue, PTII actors)
- Definition (in pink, UML compatible)
- Definition (in green, actor-oriented/PTII compatible, classes)
Design space exploration of a domain-specific wireless sensor networks
My research interest is in both hardware and software design challenges of wireless communication systems. In alignment with the research work that is being done at the Institute of Microelectronic Systems (MES) of TU Darmstadt, I integrated to a team of researchers who work on wireless sensor networks and reconfigurable hardware design.
Design space exploration is one of the major tasks in electronic system-level design. Same applies to the whole design process of application specific wireless sensor network design. Due to the complexity of such a system, automated development involves various levels of system abstraction. Consequently, a variety of different development tools including several different simulators are required. It was estimated that the work is best divided into four phases depending on the level of abstraction.
In the first phase, the objective is to create a sensor node library that includes a set of common components of a single sensor node. Here the lowest level of abstraction shall be dealt with, including the hardware and software platforms for a sensor node. A typical sensor node consists of smaller hardware modules such as a microcontroller (in certain case with an integrated special-purpose hardware unit), sensing and actuating modules, and a (medium/short range) radio transceiver as well as software modules such as a real-time operating system, (multihop) routing protocol, and other task-specific algorithm implementations.
The second phase involves domain-specific system modeling, the goal being the modeling of a target application environment. It is thus effectively the highest level of abstraction. Here the primary modeling methodology shall be based on an actor-oriented approach. By use of an existing actor-driven, distributed embedded system design framework a chosen specific application shall be modeled into a system model. Consequently, this system model describes the target system behaviour as a set of functions. A wildlife tracking and monitoring, which is considered as a one of the most complex wireless sensor network applications, is chosen as the target application.
The proposed domain-specific, model-based simulation approach to the design space exploration shall be prototyped in the third phase. Here, previously predefined system functions (from the second phase) shall be mapped to the sensor node platforms (from the first phase) and these mapping techniques will be evaluated. While this phase ends with the development of the prototype on the basis of homogeneous sensor nodes, the fourth phase will extend the prototype by supporting heterogeneity and reconfigurability of sensor nodes.
Design space exploration is one of the major tasks in electronic system-level design. Same applies to the whole design process of application specific wireless sensor network design. Due to the complexity of such a system, automated development involves various levels of system abstraction. Consequently, a variety of different development tools including several different simulators are required. It was estimated that the work is best divided into four phases depending on the level of abstraction.
In the first phase, the objective is to create a sensor node library that includes a set of common components of a single sensor node. Here the lowest level of abstraction shall be dealt with, including the hardware and software platforms for a sensor node. A typical sensor node consists of smaller hardware modules such as a microcontroller (in certain case with an integrated special-purpose hardware unit), sensing and actuating modules, and a (medium/short range) radio transceiver as well as software modules such as a real-time operating system, (multihop) routing protocol, and other task-specific algorithm implementations.
The second phase involves domain-specific system modeling, the goal being the modeling of a target application environment. It is thus effectively the highest level of abstraction. Here the primary modeling methodology shall be based on an actor-oriented approach. By use of an existing actor-driven, distributed embedded system design framework a chosen specific application shall be modeled into a system model. Consequently, this system model describes the target system behaviour as a set of functions. A wildlife tracking and monitoring, which is considered as a one of the most complex wireless sensor network applications, is chosen as the target application.
The proposed domain-specific, model-based simulation approach to the design space exploration shall be prototyped in the third phase. Here, previously predefined system functions (from the second phase) shall be mapped to the sensor node platforms (from the first phase) and these mapping techniques will be evaluated. While this phase ends with the development of the prototype on the basis of homogeneous sensor nodes, the fourth phase will extend the prototype by supporting heterogeneity and reconfigurability of sensor nodes.
Monday, July 13, 2009
Электрон хэлхээг (прототип) ажилд оруулах
Микроконтроллерийн удирдлага бүхий дэд хэсэг, дууны аналог дэд хэсэг, гадны бусад төхөөрөмжтэй холбогдох интерфейсийн дэд хэсэг бүхий цахилгаан хэлхээтэй хавтанг хэрхэн ажилд бэлтгэх буюу утааны тест (smoke test) хийх талаар SZ-н хавтан дээр хийсэн ажилдаа тулгуурлан тайлбарлав.
SZ хавтан нь ойролцоогоор 40 гаран том жижиг ИС (микропроцессор, тоон сигналын процессор, санах ой, програмчлагдах логик, кодек, цуурай дарагч, аналог мултиплексор, хаяг/өгөгдлийн буфер, шугамын драйвер, хүчдэл тохируулагч), 20 гаран транзистор, 10 гаран шулуутгах болон тогтворжуулах диод, 260-д эсэргүүцэл, 200-д конденсатор, цөөн тооны ороомгоос тогтох дуудлага, холбооны гэрлэн системийн удирдлагын төхөөрөмж юм.
Энэхүү төхөөрөмжийн хавтанг ажилд бэлтгэхдээ хэлхээний хэвийн байдалд үндсэн 2 шалгалтыг хийв.
1. Механикийн шалгалт (үүнийг голчлон гагнуурын төлөвлөгөөний зураглал буюу beschtueckungsplan-ны тусламжтайгаар хийнэ)
- ИС, элементүүд хавтан дээр бүгд бүрэн гагнагдсан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (зарим эсэргүүцэл, конденсатор гагнагдаагүй орхигдсон байв)
- ИС, элементүүд зөв байрласан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (санах ойн ИС буруу байрласан байв)
- ИС, элементүүд бүрэн гагнагдсан эсэхийг нүдээр шалгана. (кодекийн зарим хөл гагнагдаагүй байв)
2. Цахилгааны шалгалт (үүнийг бүх схем зураглал, техникийн тодорхойлолт дээр тулгуурлан програм хэрэгсэл, хэмжүүрийн болон бусад багаж хэрэгслийн тусламжтайгаар гүйцэтгэнэ, механик шалгалт ч мөн давхар хийгдэж болно)
- ИС-н оролт гаралт, свитч түлхүүрийн байрлал зөв тохируулагдсан эсэхийг шалгана.
- Тэжээлийн шугамууд бүгд зөв холбогдсон эсэхийг програм хэрэгсэл ашиглан зарчмын схемийг байрлал холболтын схемтэй тулгах замаар шалгана. (+24, +5, +3, +2, -5, +22-н бүх шугамуудыг PCB файл дээр нь мөрдөж шалгасан)
- Хэрэв хэлхээ дотроо тэжээлийн дэд хэсэгтэй бол түүний ерөнхий хүчдэлтэй ойролцоо хүчдэл бүхий үүсгүүрийг тэжээлийн дэд хэсэгт гаднаас холбож, хэлхээний гүйдлийн хэмжээг шалгана. Шаардлагатай тохиолдолд тэжээлийн дэд хэсгийн элементийг бүхлээр нь болон хэсэгчлэн хэлхээнээс салгаж, тусгаарлаж байгаад шалгана. (тэжээлийн дэд хэсэг дэх гаралтын хэлхээний ороомгийг салгах замаар тэжээлийн дэд хэсгийг хэлхээнээс тусгаарлаж, +5-н шугамд гаднаас тэжээл өгсөн. +5 өгөхөд гүйдэл 3А-с дээш байсан нь хэлхээ алдаатай, эсвэл согогтой гэдгийг харуулж байв)
- Хэлхээний тэжээлийн шугам бүрийг нэг бүрчлэн тусад нь шалгана. (+5, +3, +2, -5, +22-н шугамыг шалгасан. +5, +3-н шугамнаас тэжээл авдаг элемент, хэсгүүдэд алдаа байсныг олсон)
- Гадны тэжээлд холбоход хэлхээнийн гүйдэл хэт өндөр байх (+3A-с дээш байв), эсвэл өөр ямар нэгэн сэжиг илэрсэн үед эхлээд зарчмын схем зураглал дээрх ИС-н тэмдэг тэмдэглэгээ техникийн өгөгдөл, тодорхойлолттойгоо (datasheet) таарч байгаа эсэхийг шалгана. (кодекийн 3 хөлний тэмдэглэгээ тодорхойлолтоос зөрж байсныг илрүүлсэн)
- Мөн сэжигтэй тохиолдолд заавал хийх шалгалт нь зарчмын схем зураглал нь байрлал холболтын схем зураглалтай (layout) таарч байгааг програм, багаж хэрэгсэл ашиглан шалгах юм. (шугамын драйверийн ИС-н холболт буруу байсныг мултиметрийн хэмжилтээр олсон. Үүний дараа PCB файл дээр бусад бүх холболтуудыг мөрдөж шалгасан)
Жишээ нь SZ хавтан дээр илэрсэн алдаанууд:
- эхлээд +24-н хэлхээнд +5-г гаднаас өгөхөд тэжээлийн блокийн гүйдэл 3А-с дээш зааж байв. Энэ нь хэлхээнд алдаа, согог байгаа гэдгийг харуулж байна. Уг нь 260mA-с хэтрэх ёсгүй.
- Тиймээс тэжээлийн ороомгийг салгаж байгаад +5-н шугамд гаднаас +5-г өгөв. Гүйдлийн хэмжээ өндөр хэвээр.
- Тэгэхээр нь +3-н хэлхээнд гаднаас +3-г өгөв. Учир нь +3, +2, -5 нь +5-р үүсгэгдэж байгаа. Гүйдэл мөн өндөр хэвээр.
- +3 ямар ИС, элементэд холбогдсоныг зарчмын схемийн дагуу мөрдөж, тэдгээр холбоотой ИС, элементүүд хавтан дээр зарчмын схемийн дагуу холбогдсоныг мултиметрээр шалгах явцад шугамын драйверийн хэлхээнд буруу холболт хийгдсэнийг олов.
- Алдааг засаад дахин +3-г гаднаас өгөхөд гүйдэл өндөр хэвээр байв. Өөрөөр хэлбэл өөр алдаа байна гэсэн үг.
- Бүх холболтыг PCB файл дээр шалгаж, зөв гэдгийг тогтоосны дараа ИС-н тэмдэглэгээг datasheet-тэй нь тулгаж шалгав. Энэ шалгалтаар кодекийн 3 хөл зарчмын схем дээр буруу тэмдэглэгдсэн болохыг олов. Өөрөөр хэлбэл зарчмын схем дэх симбол буруу тодорхойлогдсоноос алдаа гарч, ИС-н хөлнүүд буруу сигналд холбогдсон байв. Энэ буруу холбогдсон хөлнүүдийг хавтангаас хөндийрүүлсний дараа +3-г холбоход гүйдэл багасч ойролцоогоор 400mA болсон байв. Үүнийг +3-н хэлхээ алдаагүй болсон гэж үзэв.
- +5-н шугамд гаднаас +5-г өгөхөд гүйдэл дахин өндөр хэвээр байв. Гэхдээ 2,5А орчим байв.
- +5-н шугамд PCB файл дээр шалгалт хийх явцад санах ойн ИС буруу байрласныг олов.
- Уг ИС-г хэлхээнээс салгаж байгаад дахин +5-г өгөхөд гүйдэл багасаад 400mA орчим зааж байв. Ингээд +5 шугамд гүйдэл бага байгаа тул +3, +2 шугамууд хэвийн гэж үзэв.
- Нэгэнт дотоод тэжээлийн гаралтын хэлхээ хэвийн болсон тул тэжээлийн оролтонд +5-с +24 хүртэл хүчдлийг аажмаар өгөв. Гүйдэл бүр багасч 200mA-с багыг зааж байв.
- Үлдсэн -5, +22 шугамын хүчдэлийг шалгахад -5 хэвийн, харин +22-н оронд +16 зааж байв. +16-н хэлхээний ҮӨ-н гаралт 0В орчимд байсан тул үүнийг хэвийн гэж үзэв.
- Шалгалтын явцад бусад жижиг алдаануудыг мөн илрүүлэв: зарим эсэргүүцэл, конденсатор холбогдоогүй, зарчмын схемийн хэд хэдэн алдаа г.м.
SZ хавтан нь ойролцоогоор 40 гаран том жижиг ИС (микропроцессор, тоон сигналын процессор, санах ой, програмчлагдах логик, кодек, цуурай дарагч, аналог мултиплексор, хаяг/өгөгдлийн буфер, шугамын драйвер, хүчдэл тохируулагч), 20 гаран транзистор, 10 гаран шулуутгах болон тогтворжуулах диод, 260-д эсэргүүцэл, 200-д конденсатор, цөөн тооны ороомгоос тогтох дуудлага, холбооны гэрлэн системийн удирдлагын төхөөрөмж юм.
Энэхүү төхөөрөмжийн хавтанг ажилд бэлтгэхдээ хэлхээний хэвийн байдалд үндсэн 2 шалгалтыг хийв.
1. Механикийн шалгалт (үүнийг голчлон гагнуурын төлөвлөгөөний зураглал буюу beschtueckungsplan-ны тусламжтайгаар хийнэ)
- ИС, элементүүд хавтан дээр бүгд бүрэн гагнагдсан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (зарим эсэргүүцэл, конденсатор гагнагдаагүй орхигдсон байв)
- ИС, элементүүд зөв байрласан эсэхийг гагнуурын төлөвлөгөөтэй тулгаж, нүдээр шалгана. (санах ойн ИС буруу байрласан байв)
- ИС, элементүүд бүрэн гагнагдсан эсэхийг нүдээр шалгана. (кодекийн зарим хөл гагнагдаагүй байв)
2. Цахилгааны шалгалт (үүнийг бүх схем зураглал, техникийн тодорхойлолт дээр тулгуурлан програм хэрэгсэл, хэмжүүрийн болон бусад багаж хэрэгслийн тусламжтайгаар гүйцэтгэнэ, механик шалгалт ч мөн давхар хийгдэж болно)
- ИС-н оролт гаралт, свитч түлхүүрийн байрлал зөв тохируулагдсан эсэхийг шалгана.
- Тэжээлийн шугамууд бүгд зөв холбогдсон эсэхийг програм хэрэгсэл ашиглан зарчмын схемийг байрлал холболтын схемтэй тулгах замаар шалгана. (+24, +5, +3, +2, -5, +22-н бүх шугамуудыг PCB файл дээр нь мөрдөж шалгасан)
- Хэрэв хэлхээ дотроо тэжээлийн дэд хэсэгтэй бол түүний ерөнхий хүчдэлтэй ойролцоо хүчдэл бүхий үүсгүүрийг тэжээлийн дэд хэсэгт гаднаас холбож, хэлхээний гүйдлийн хэмжээг шалгана. Шаардлагатай тохиолдолд тэжээлийн дэд хэсгийн элементийг бүхлээр нь болон хэсэгчлэн хэлхээнээс салгаж, тусгаарлаж байгаад шалгана. (тэжээлийн дэд хэсэг дэх гаралтын хэлхээний ороомгийг салгах замаар тэжээлийн дэд хэсгийг хэлхээнээс тусгаарлаж, +5-н шугамд гаднаас тэжээл өгсөн. +5 өгөхөд гүйдэл 3А-с дээш байсан нь хэлхээ алдаатай, эсвэл согогтой гэдгийг харуулж байв)
- Хэлхээний тэжээлийн шугам бүрийг нэг бүрчлэн тусад нь шалгана. (+5, +3, +2, -5, +22-н шугамыг шалгасан. +5, +3-н шугамнаас тэжээл авдаг элемент, хэсгүүдэд алдаа байсныг олсон)
- Гадны тэжээлд холбоход хэлхээнийн гүйдэл хэт өндөр байх (+3A-с дээш байв), эсвэл өөр ямар нэгэн сэжиг илэрсэн үед эхлээд зарчмын схем зураглал дээрх ИС-н тэмдэг тэмдэглэгээ техникийн өгөгдөл, тодорхойлолттойгоо (datasheet) таарч байгаа эсэхийг шалгана. (кодекийн 3 хөлний тэмдэглэгээ тодорхойлолтоос зөрж байсныг илрүүлсэн)
- Мөн сэжигтэй тохиолдолд заавал хийх шалгалт нь зарчмын схем зураглал нь байрлал холболтын схем зураглалтай (layout) таарч байгааг програм, багаж хэрэгсэл ашиглан шалгах юм. (шугамын драйверийн ИС-н холболт буруу байсныг мултиметрийн хэмжилтээр олсон. Үүний дараа PCB файл дээр бусад бүх холболтуудыг мөрдөж шалгасан)
Жишээ нь SZ хавтан дээр илэрсэн алдаанууд:
- эхлээд +24-н хэлхээнд +5-г гаднаас өгөхөд тэжээлийн блокийн гүйдэл 3А-с дээш зааж байв. Энэ нь хэлхээнд алдаа, согог байгаа гэдгийг харуулж байна. Уг нь 260mA-с хэтрэх ёсгүй.
- Тиймээс тэжээлийн ороомгийг салгаж байгаад +5-н шугамд гаднаас +5-г өгөв. Гүйдлийн хэмжээ өндөр хэвээр.
- Тэгэхээр нь +3-н хэлхээнд гаднаас +3-г өгөв. Учир нь +3, +2, -5 нь +5-р үүсгэгдэж байгаа. Гүйдэл мөн өндөр хэвээр.
- +3 ямар ИС, элементэд холбогдсоныг зарчмын схемийн дагуу мөрдөж, тэдгээр холбоотой ИС, элементүүд хавтан дээр зарчмын схемийн дагуу холбогдсоныг мултиметрээр шалгах явцад шугамын драйверийн хэлхээнд буруу холболт хийгдсэнийг олов.
- Алдааг засаад дахин +3-г гаднаас өгөхөд гүйдэл өндөр хэвээр байв. Өөрөөр хэлбэл өөр алдаа байна гэсэн үг.
- Бүх холболтыг PCB файл дээр шалгаж, зөв гэдгийг тогтоосны дараа ИС-н тэмдэглэгээг datasheet-тэй нь тулгаж шалгав. Энэ шалгалтаар кодекийн 3 хөл зарчмын схем дээр буруу тэмдэглэгдсэн болохыг олов. Өөрөөр хэлбэл зарчмын схем дэх симбол буруу тодорхойлогдсоноос алдаа гарч, ИС-н хөлнүүд буруу сигналд холбогдсон байв. Энэ буруу холбогдсон хөлнүүдийг хавтангаас хөндийрүүлсний дараа +3-г холбоход гүйдэл багасч ойролцоогоор 400mA болсон байв. Үүнийг +3-н хэлхээ алдаагүй болсон гэж үзэв.
- +5-н шугамд гаднаас +5-г өгөхөд гүйдэл дахин өндөр хэвээр байв. Гэхдээ 2,5А орчим байв.
- +5-н шугамд PCB файл дээр шалгалт хийх явцад санах ойн ИС буруу байрласныг олов.
- Уг ИС-г хэлхээнээс салгаж байгаад дахин +5-г өгөхөд гүйдэл багасаад 400mA орчим зааж байв. Ингээд +5 шугамд гүйдэл бага байгаа тул +3, +2 шугамууд хэвийн гэж үзэв.
- Нэгэнт дотоод тэжээлийн гаралтын хэлхээ хэвийн болсон тул тэжээлийн оролтонд +5-с +24 хүртэл хүчдлийг аажмаар өгөв. Гүйдэл бүр багасч 200mA-с багыг зааж байв.
- Үлдсэн -5, +22 шугамын хүчдэлийг шалгахад -5 хэвийн, харин +22-н оронд +16 зааж байв. +16-н хэлхээний ҮӨ-н гаралт 0В орчимд байсан тул үүнийг хэвийн гэж үзэв.
- Шалгалтын явцад бусад жижиг алдаануудыг мөн илрүүлэв: зарим эсэргүүцэл, конденсатор холбогдоогүй, зарчмын схемийн хэд хэдэн алдаа г.м.
Subscribe to:
Posts (Atom)