Много от описаното е направено по времето, когато хората нямаха и по ред причини нямаше как да имат домашни компютри на които да работят. Паралелно с това някой студенти участвахме в работата на Научно - Изследователският Сектор (НИС) в института. Работехме в различни направления като избирахме задачите по необходимост или по лични възможности и предпочитания. Проектирахме различни реални устройства и най-често и пишехме софтуера за управлението им ако имаше такъв. Компютрите, макар и разпределени по лаборатории бяха малко и ги ползвахме едва ли не по график съвместно с преподавателите. Не оставаха без някой да работи на тях. За това, което правехме ни се заплащаше по- скоро символично, но целта ни не бяха парите от там, а възможността да правим реални неща и да научим нещо повече от това, което учехме в редовният курс на обучение. Впрочем много от наученото не ни беше и по специалността. А ако искахме да работим по лични проекти, нерядко пишехме и обмисляхме софтуера вкъщи на хартия а в института по най-бързият начин го въвеждахме, раазпечатвахме и тествахме когато можем, дори и през 15 минутните (тогава) междучасия, или висяхме в залите за свободен достъп който предоставяха някой катедри, записвахме се за радиолюбители, за да имаме достъп до компютъра в радиоклуба, оставен просто "ей така" за ползване от членовете, оставахме нелегално нощем в института да работим в лабораториите, от които иначе легално имахме ключове работейки денем по теми по НИС (тогава още не се крадеше). Вярно е, че понякога преоткривахме топлата вода и велосипеда, а и още тогава имаше подмятания от типа "Те това хората (разбирай на запад) вече са го направили!"
Направили са го, ама... Ако гледате с насмешка на направеното - можете ли да го направите с техниката и знанията с които разполагате след толкова години?
Първо че ние го правехме реализируемо с достъпната тогава за соц-индустрията компонентна база, понякога заобикаляхме и патентни защити, които не биха позволили на индустрията ни да произвежда за износ копирани изделия, и второ - не по-малко важно, че като продукт на тази развойна дейност излизаха и обучени във всяко едно отношение хора (техническо, организационно, административно), които да могат да я вършат - и преподаватели и студенти. Все пак това е смисълът на един технически ВУЗ, нали?
Сега някой от проблемите, които решавахме изглеждат тривиални и ги има решени като даденост в смартфона на всяко хлапе, но тогава Стив Джобс беше млад човек, който още не беше сънувал смартфон, по нашите земи нямаше интернет, откъдето да сваляме каквото си искаме (1991 някой хора започнаха да използват BBS), а Microsoft беше слабоизвестна фирма...
В по-долното описание са включени само разработки по които съм работил извън учебният материал, включен в учебният план.
Далеч съм от мисълта че това, което съм участвал е нещо върхово - в още много катедри и лаборатории се правеше какво ли не и вероятно е имало и доста по- сериозни разработки от страна на студенти, но ако след толкова години някой неща днес изглеждат тривиални, или у някого нивото на техниката от тогава или софтуерните ресурси будят насмешка, нека за проверка на собствените си възможности да опита да направи нещо подобно със съвременна техника, с която разполага...
Упоменатите преподаватели с които сме работили са с тогавашните си научни титли и длъжности, като с някой през годините не съм имал повече контакти и не знам как са се развили.


    Разработки по НИС и частни проекти, по които съм работил:
• Термоконтролер за управление пещи в завода за стъкло в Белослав, базиран на процесор и периферия от фамилията 68xx на Motorola - извършвах помощни работи по изготвяне на кабелни форми и механична работа по крепежни и охлаждащи компоненти и заедно с това запознаване с микропроцесорната система и работата в екип (в I курс) 1987 г. (ръков. доц. Атанасов, гл.ас. Д.Славов, ст.ас.Г. Сотиров) кат. СТ
• Комуникационна система за Управление на градския транспорт – (това което сега прави по европрограмата за „Интегриран градски транспорт”)(Assembler 6800, 6502, Apple II Basic ръков. доц. Атанасов, гл.ас. Д.Славов, ст.ас.Г.Сотиров) кат. СТ 1987-88г
Сега GPS-и искаха да слагат даже по контейнерите за боклук в София, но тогава нямаше достъпна GPS технология за проследяване на автобусите, но от друга страна не ни и трябваше - градските автобуси се движат по фиксиран маршрут извън който нямат работа. Системата предвиждаше изнесени по спирките или сградите до тях комуникацонни модули, които автоматично да обменят дискретни съобщения с автобусите по радиоканал с обхват 30-50м общо-взето районите около спирките), и с възможност за изпращане на персонализирани или циркулярни пейджинг съобщения до автобусите, автоматично да ги опознава по ID и да докладва на диспечерският компютър, а с диспечерският пункт модула да комуникира по некомутируема телефонна линия. Устройствата в автобусите бяха със модули от 7-сегментни индикатори и се наложи да се направи подпрограма на BASIC за диспечерската програма, който да транслитерира буквите в знаци на кирилица или латиница, даже донякъде да интерпретират съобщенията за да има минимална смес между кирилица и латиница, които да могат да се изобразяват в скролиращи надписи на индикацията и да се четат смислено. Аз писах част от софтуера - протокол за управление на серийна комуникация през ASIA (бълг. аналог СМ603), управляващо TTL интерфейс от фамилията 75XX (токов интерфейс)за обмен по некомутируемата телефонна линия. Тогава нямаше нито интернет, нито модеми (поне у нас), а скорости на обмен 14.4 Kbit/s освен между две машини на една маса бяха нечувано високи и отдалечената връзката между две устройства граничеше с фантастиката. Впоследствие работих и над диспечерска програма за автоматизирано приемане и изпращане на съобщения от изнесените по автоб. спирки модули (там беше необходим същият протокол за обмен, но за процесор 6502) и програма за Бейсик за визуализация и печат, която да приема съобщенията от модулът на асемблер. Подобен софтуерен протокол по- късно срещнах в българските фонокартни телефони, където работих но не през токов интерфейс, а там вече беше изграден модем, макар и с 300 bit/s
• Програмен модул за интерфейсен обмен м-у едноплатков компютър и PC (отделно вграждаем програмен модул в EPROM-a на едноплатков. компютър) за обмен между между PC, работещо с кросс асемблер и едноплатков компютър за развойна дейност и обучение - рък. гл.ас. Д.Славов, кат СТ 1988г
Едноплатковите компютри с процесор 6800 на Motorola (бълг. аналог СМ601) бяха широко разпространени във ВМЕИ и се използваха както за обучение, постановки за лабораторни упражнения, така и за развойни дейности. Бяха известни като "китчета", и на тях се работеше само чрез въвеждане на програмите и данните в 16-тичен код. Интерфейсът им беше клавиатура от 32 клавиша, 16 от които за 16-тични числа и 16 служебни, 8 бр седем сегментни индикатора, сегментите на които се управляваха по програмен път и 1-2бр PIA MC6821 (бълг. аналог СМ602) и 1-2бр ASIA (СМ603) освен тия, които обслужваха клавиатурата и индикацията. Голяма екстра беше че все пак имаха батерийка, която да удържа CMOS паметта с въведеният код. Модулът който написах беше нужен, за да не се въвежда всяка програма на ръка както до момента, както и за улеснено тестване на програми при развойна дейност или препрограмиране на действащи индустриални устройства базирани на същата фамилия, която беше индустриално разпространена, понеже се произвеждаше в България. Работеше се, като от страна на PC програмният код в S формат, изготвен от кроссасемблер се прехвърляше чрез стандартна DOS-овска команда COPY ( copy име_на_файл > [com1] [com2] ) към едноплаковият компютър, включеният към COM порта на PC. Моята програмка получаваше поблоково, прекодираше кода от ASCII формат в HEX код, формираше контролна сума и я сравняваше с изпратената и при коректна транслация зареждаше изпратеният код в RAM-a на указаните в блоковете адреси. След приключването на трансфера и зареждането обявяваше и оставаше в готовност за стартиране на заредената програма. В голяма степен трудността идваше от това, че EPROM-a беше пълен с програмни модули от системен характер, писани разностилно - явно в различно време и навярно от различни хора, с фиксирани начални адреси, които се ползваха от различни потребителски програми и за да се запази съвместимостта с тях аз трябваше да разположа моето "творение" в оскъдно място в "дупките" между модулите. рък. гл.ас. Д.Славов, кат СТ 1988г
• Хардуерно проектиране на разширителен модул - системен часовник за компютър ХТ и написване на BIOS за него.
Сега това устройство може да се види във всеки WINDOWS в Device Manager/ System Devices/ System Timer и надали някой му обръща внимание като на всяка даденост, но IBM XT/ Правец 16 нямаха хардуерно устройство системен часовник и при включване винаги започваха да броят от 1.1.1980г и вмъкваме редове в AUTOEXEC.BAT файла на DOS за задаване на дата и час. Впрочем тогава у нас не бяха познати и ранните версии на WINDOWS. Аз проектирах ISA платка с PIT от фамилията 68xxx (защото такъв намерихме), наситих я и я оживих и вкарах предварително написаното BIOS-че за него в EPROM-a му (Orcad 3.x, Protel PCB, Assembler 8086/8088) 1988г
• Програма за реологичен анализ на скални материали (документирана - наградена 3-то републиканско място в областта „Математическо моделиране” на републиканският кръг на студентска научна сесия – форум за приложни студентски разработки ( Apple II Basic, Assembler 6502 – Правец82 ) рък. гл. ас. Румен Цанев (сега доцент) кат. "Математика" за нуждите на Геолого - Проучвателно предприятие - Варна 1987-88г Съществуват геоложки методи за изследване на скални материали, които са евтини и служат за потвърждение или категорично отричане на възможността за съществуване на някой видове залежи. За целта се взема скална проба, шлифова се до определени размери ( цилиндър с височина 70 мм и диаметър 36 мм), Монтират се на нея тензодатчици и се натоварва на натиск с хидравлична преса. Макар и камъкът да е пословично твърд, в действителност далеч не е така и в резултат на натиска той като всяко реално тяло има еластичност и се подчинява на закона на Хук, има си еластичен модул на Юнг, а заедно с това в зависимост от предисторията на скалата се проявяват и закъсняваща еластичност и вискозни процеси.
Моята програма изследваше снетите ръчно данни за деформацията на скалният материал, снети от тензодатчиците и през обемисти и трудоемки изчисления (в които имаше и доста от математическият апарат на статистиката) изчисляваше 14 реологични коефициента, които геолозите анализираха. Когато започнахме разработката, само екип от италиански геолози бе започнал работа по темата, което ние следихме през бюлетините и експресжурналите на патентното ведомство и доста скоро изпреварихме италианскяит екип. На форумът за студентски приложни разработки бяха наградени 3 такива, моята на трето място. Първо и второ място бяха "Математически модел на изграждане на невронна мрежа и създаване на асоциативна памет" и "Матем. модел на ембрионално развитие" което илюстрира какви теми и подготовка за тях са имали макар и единици от студентите. Предвижаше се като следващ етап автоматизирано снемане на даниите от тензодатчиците, които трябваше да се свалят през времеви интервали минути в експоненциална функция и последните няколко измервания се падаха в странни времена от денонощието, но "Геолого проучвателно предприятие" не осигури финансиране. После дойде така наречената "демокрация" и проекта увисна. Интереса към него се върна когато американска геолого-проучвателна фирма, търсеща петрол и газ в наши териториални води в началото на 1991г предложи аналогичен продукт за 90 000 USD (тогава тристаен апартамент в центъра на Варна струваше 3-5 хиляди $), но по ред причини не можахме да продължим проекта.
• Текстов редактор за рутинна офис дейност Недовършен, макар и доста напреднал заради работа по други задачи.Личен проект 1988-89г През годините така и не видях текстов редактор за Apple II/ Правец 82 функционален аналог на MS WORD, а тогава имаше нужда от него. Идеята беше за функционален аналог на някогашният DOSC за Правец 16, който пък беше аналог на ранна версия на MS WORD за DOS и насочен към писане и автоматизирано оформление на протоколи от лабораторни упражнения. В него беше предвидено да изготвя сам рамки и антетки на страниците, да оставя полета за графики и като далечна цел - да импортва графика. В него вид би служил и за създаване на фирмени бланки, но... у нас още нямаше фирми. Интересно за мен беше изготвянето на цялостен концептуално завършен продукт за масова употреба. Въпреки че и шрифта на Apple/ПРАВЕЦ и шрифтовете на тогавашните принтери бяха monospace (с еднаква широчина на символите), беше предизвикателство и създаването на алгоритъм, който да следи динамично дължината на реда в брой символи, обособен от размера на полето за писане (с рамка или не), да се съобразява с фонетиката на сричките и възможностите за граматически правилно буквопренасяне в края на реда, а в случай на корекция на вече написан текст да коригира динамично въведените буквопренасяния след мястото на корекция. Поради липса на достъпна речникова база данни не беше предвиждана правописна проверка на текста...
Програма за символно интегриране и диференциране и символна обработка на математически аналитични изрази зададени през клавиатурата от потребителя в процеса на изпълнение на програмата (BASIC Правец 82 Частен проект в съавторство с К.Секов) 1988-89г Замисълът беше да се използва за обработка на аналитични изрази при изчисляване на електромагнитни процеси и минимизиране на електромагнитният шум в силови инвертори при преобразуването на стъпаловидната псевдосинусоида през трансформатора, а като ширпотреба - в помощ на учебният процес. За да започне анализът програмата даваше на потребителят да въвведе в диалогов режим аналитичният израз, който трябваше да бъде обработен, (все пак написан на синтаксис на BASIC), след което скрито му добавяше номер на ред и през междинен запис на дискета добавяше реда в тялото си като изпълним. Впоследствие по същият начин ракурсивно добавяше изразите които се получаваха от предната операция ( опростяване на израз, интегриране, или диференциране). Най-вълнуващото беше, че програмата можеше да вмъква изпълними редове в тялото си и впоследствие да ги изпълнява, което даваше възможност да се самомодифицира ако се разработи алгоритъм за това. А ранна версия на MatLab (под DOS, естествено - Windows тогава все още беше просто екзотична DOS-овска надстройка), видяхме едва година по- късно...
• Проектиране на цифров волтметър с СМ751 (изцяло хардуерен), работещ по метода на двойното интегриране. (Protel) Сега подобни, но компактни и с доста повече опции се продват на цена 7-20 лв с батерията (която дава процентно доста от цената), но тогава просто нямаше. Целта ни беше да се създаде възможност за производство поне на малки серии за нуждите на лабораториите от катедрата
Проектиране и изработка на механична конструкция, възли и механизми на ВЕИ 1988-89г - ПНИЛ по ВЕИ - кат. АП, под ръков. на доц Пазвантов Това включваше конструиране и якостно оразмеряване на възлите, анализ на натоварвания и вибрации породени от работата на ВЕИ, изготвяне на конструкторска и технологична документация.
• Система за управление на ветрено-енергийно съоръжение - част от нея самосиндикална разработка в ПНИЛ по ВЕИ 1989г в Съавторство с К. Секов - Apple BASIC, Асемблер 6502 за Правец82 Сега ВЕИ има буквално под път и над път, но някой задава ли си въпроса как работят те и какво има да им се управлява? Основното предназначение на ВЕИ не е да произвежда изцяло електричеството примерно за даден район ( това може да е мрежата на един трафопост), защото не можем да разчитаме на постоянен вятър, а поддръжката на акумулатори и инвертори от които да консумираме изцяло енергията е скъпо и заедно с първоначалната цена на основното съоръжение обезсмисля безплатната енергия. Замисълът е ВЕИ да работи паралелно с електроснабдителната система и да я подпомага. Когато има подходящ вятър, ВЕИ поема част от товара и с това снижава консумацията от енергийната система. Простичко казано перката върти генератор, като конструкциите и на перките и на генераторите са различни, но да започнем с генераторите... Обикновено те са променливотокови. И обикновено напрежението което генерират не е индустриално съвместимо. В нашият случай то беше около ~100V. По принцип ампитудата на напреженеито е зависима от оборотите. Но те се регулират през витлото (вятър, ъгъл на атаката на лопатките и динамичен товар от ел. консумацията). За да е използваемо, произведеното електричество трябва да се инвертира в ~220V. Ако мислим упростенчески, то такъв генератор директно свързан към трафопоста при липса на вятър би заработил като вентилатор в полето. Освен това електроснабдяването и у нас, както и по цял свят е трифазно. В идеалният случай би трябвало трите фази да са еднакво дефазирани една спрямо друга и да са с еднаква амплитуда. На практика поради нееднаква натовареност и по активен и по реактивен товар, векторната диаграма на трите фази е леко, а понякога и доста асиметрична, като асиметрията се мени в зависимост от променливата консумация (доилни агрегати рано сутрин, включване на климатици рано сутрин и завишена консумация от фризери в хранителните борси при сутрешното зареждане със стока, когато фризерите се отварят и затварят често или се вкарва нова незамразена стока, консумация от електродвигатели на машини през деня и пр.) Ако към такава реална система подадем паралелно захранване с идеално трифазно напрежение, то реалните и изработените идеални фази никога няма да съвпадат и ще има уравнителни токове между трансформатора на трафопоста и нашето съоръжение. Такива токове при макар и малки разлики в напреженията се очаква да бъдат големи, защото основното изискване към захранващата мрежа е да бъде нискоомна за снижаване на загубите в нея. И тогава ВЕИ става консуматор на основната мрежа. Затова изискванията към инверторът, който служи за това да е мощен, трифазен и да следи и копира състоянието на реалната мрежа. Сам по себе си той е голяма и съществена част от съоръжението. Затова и темата беше зададена на ПНИЛ към лаборатория "Управление и автоматизация на ел. задвижванията" понеже задачата не е чисто електротехническа, а има сложна електроника за управление, която е свойствена за управлението на мощни ел. задвижвания, с което се занимаваше тази лаборатория от катедра АП. Инверторът беше дело на екипа електрончици под ръководството на доц. Пазвантови и беше патентован. Той изработваше импулси, които се "сглобяваха" в псевдосинусоидален сигнал на "стъпалца" в специално конструиран за целта трансформатор, с 12 секции, които които бяха част от първични намотки и три вторични свързани в "звезда". Стъпаловидните псевдосинусоиди се изглаждаха от филтриращите свойства на трансформатора и висшите хармоници в голяма степен се подтискаха, иначе биха се излъчвали през силовите кабели на енергийната система, които в случая биха играли и ролята на антени за паразитно електромагнитно излъчване. Едно от сериозните изисквания към такива съоръжения е нисък електромагнитен шум. Тъй, като напреженеито на генератора зависи от оборотите му, оборотите трябва да бъдат вкарани в някакви граници. От една страна за да осигурят нормирано входно напрежение на генератора, от друга страна да не се натоварва излишно витлото от центробежните сили. При това и скоростта на вятъра е променлива и генераторът при различен електрически товар оказва различен съпротивителен момент на витлото. Оставено на празен ход и особено при силен вятър то би могло да развие опасни за конструкцията обороти. За да се регулират оборотите механичната конструкция, която е мое дело, променяше синхронизирано ъгълът на атаката на лопатките на витлото. Освен това съоръжението работи най-ефективно, когато остта на въртене на витлото съвпада с моментната посока на вятъра. Поради конструкцията на витлото беше съвършенно недопустимо то да бъде обдухвано изотзад. Тогава лопатките щяха да се пречупят. На пръв поглед би било просто да се направи "опашка" на генератора като на ветропоказател. Но витлото за 125 KW беше с диаметър 20м със скорост на въртене до 120 об/мин и тежеше малко повече от половин тон, а генераторът който въртеше то тежеше над 1300 кг, като се въртеше с 1500 оборота в минута. При такива скорости и маси изчисляемият жироскопичен ефект би бил такъв, че за да се ориентира по ватъра съоръжението, трябваше опашка с голяма площ и дължина поне 40м, което осезателно би оскъпило построяването на бетонният фундамент и би ограничило възможната гъстота на разполагане на съоръженията. Нашето съоръжение беше 125 KW, а съвременните ВЕИ са 3 мегавата а и по-големи мощности и подобна "опашка" е немислима.
...
В рамките на работата си като стругар и шлосер изработих цялостно датчиците за скорост и посока на вятъра (механична изработка и проектиране)като обаче проектирах и наситих и платките в него, проектирах и изработих контролер за отчитане на показанията им и в извънработно време написах софтуера (Измерване през 20 секунди скорост и посока на вятъра, предсказване чрез екстраполация данните за след 20 сек. Управлението тръгва да отработва авансово насочеността на кулата и ъгълът на атаката на лопатките на перката, но това става, докато и вятърът също променя скоростта и посоката си - той не може да ги измени мигновенно със скок и така положението на перката и ъгълът на атака по време на преместването си в голяма степен корелират на условията, определени от вятъра. А при една и съща скорост на вятъра ъгълът на атака на лопатките зависи и от електрическият товар на генератора, тъй като механически той работи като товар на въртящият момент на витлото. Аз написах свалянето и обработката на данните за вятъра и екстраполацията, а Камен проектира контролера за управление на двигателите и написа на асемблер за 6502 модулите, които бейсиковата програма за екстраполация викаше, а те управляваха двигателите които коригират азимута на остта и ъгъла на атаката на лопатките на витлото през контролера понеже това беше точно по неговата изучавана специалност). Добавихме и датчици за контрол на положението на кулата и лопатките на витлата. Допълнително бяха взети мерки против зацикляне на програмата (сигнал Програма ОК (ПОК) към хардуерен таймер от фамилията 555 за запускане преди да е изтекло времето, при липса на ПОК - рестарт на програмата), понеже по механични причини би било фатално вятърът да духа витлото изотзад и изпадането на системата в неустановено положение създава предпоставки за това. Захранването на компютъра беше предвидено да е през инвертор от акумулаторите на съоръжението предвидени за сервизни цели, което беше предвидено като даденост в съоръжението, по принцип трябваше да е по- надеждно поддържано от съвременните UPS-и, но докато имахме касателство това не беше изпълнено. Затова при неустановено положение след вероятно спиране на тока, програмата подаваше команда по най-бързият начин съоръжението да се ориентира срещу моментната посока на вятъра лопатките да заемат добре обтекаемо положение ( да посрещат вятъра с ръба си и едва след засичането на 3 показания за скорост и посока системата да влезе отново в цикъл. Идеята за ПОК беше взаимствана от тот-ман системата на влаковете, при която машинистът е длъжен през интервал не повече от минута да натиска педал, иначе влака спира. По- късно я видях реализирана и в българските фонокартни телефони, с които работих. При Правец 82 можеше да се рестартира и само приложението, което да върне управлението на DOS-a а след това програмата (при променени векторни адреси на прекъсването) да се самозапусне, като провери дали е начално пускане на програмата.Ако не е - да вземе последните 2 измерени точки за вятъра (за които, обаче няма критерий от колко време са), да извърши ново измерване и по три точки да продължи по алгоритъма. Състоянието ня вяъра зависи от неговата предистория - маса на въздуха, скорост, посока. Такъв вид процеси се наричат ергодични. По подобен начин се държи и борсовият пазар, понеже там търсенето влияе на цените. Само че за разлика от вятъра процесите в борсата са вероятностно предопределени от историята на пазара и действията и на другите участници и са стохастични. Там теорията на предсказанията за бъдещи стойности е доста по- сложна, но дори и да подходим както с вятъра, методът би могъл да се използва за предсказване на търсенето и едно автоматизирано предсказване на дребните флуктоации може да "изстиска" печалба при незначителни дрейфове на спокоен пазар (без екстремни събития - войни, природни катаклизми, преврати) цените и интензивни покупко-продажби. Дори и при 1% на ден печалба от това, но с реинвестиране на пeчлбата за около 70 дни ресурсът ни би се удвоил. Поради липса на източник на информация в реално време и липса на пазарни възможности не сме работили по темата. В наше време борсовите роботи вече са банално ежедневие на финансовият пазар...
• Разработване на стотици чужди курсови работи и проекти (предимно срещу заплащане) по ОЦМПТ, Мат. анализ - числени методи, предмети свързани с процесорни системи на спец. АП, Микроелектроника Най-често пишех на ръка асемблерските програми и ги асемблирах ръчно (то и в час работехме така), като от много работа бях научил и доста от шестнадесеттичните кодове на инструкциите на 6800 и 6502 и изчислявах отместванията наум. Убеждавах клиентите, че програмите са проигравани на компютър, и с изключение на един-единствен случай те тръгваха от пръв опит за въвеждане, стига опитът да е правилен. Освен комерсиалната страна на въпроса, тази "ширпотреба" ми беше ценна че отигравах куп детайли - запознаване с купища числени методи, алгоритми за намиране къде е разположена полезната част от графика и изолирането й с цел по- ефектно визуализиране, самомащабиране на графики (сега това го виждам по графиките на валутните курсове в някой сайтове), смяна на базиса при изчертаване на екрана и принтиране (понеже координатите на точките на монитора се падат в 4-ти квадрант, но с обърната абсциса), всевъзможни прекодирания, сортирания, действия с масиви, "умни светофари", асемблерски програми, които вписват в тялото си кодове на инструкции и си ги изпълняват (но пък няма да работят, ако са записани в EPROM), или самоцелни задачи (за моя тренировка с цел "полиране на техниката") - в рамките на едно решение да напиша асемблерската програма с най-малко байтове, или да я минимизирам в най-малко машинни тактове ако работи в цикъл, или най-малко редове на сорса, рeкурсивни подпрограми и пр. Паралелно с това проектирах и хардуерни задания, като обаче се придържах предимно към цифровите, но каквото и да правех не поемах ангажимента да изготвям "белова" оформена с рамки и "чисти" чертежи за представяне. Иначе човечето-поръчител съвсем нямаше да се запознае със съдържанието на курсовата си работа или проекта и щяха да го върнат, а да изкара виновен мен и да идва да иска обяснения.
Пък е и нерентабилно като съотношение вложено време/заплащане.
( Assembler 6800,Fortran 77, Basic, Pascal и още доста) 1988-1992
• Проучване на фабричните разпечатки на BIOS-а на IBM-PC и "монитор" на Apple ][ с цел "крадене на хватки" от системното програмиране и познания за организация на системата адреси, процедури и пр., проучване на работещ софтуер с цел "адаптирането" му. Впрочем и в момента като видя в някой сайт интересен трик, свалям кода и разглеждам как е направен с цел бъдещо използване. • Сваляне на схемите на множество работещи устройства с цел копиране на изделията за различни цели
• Работа по написването на системният софтуер на едноплатков компютър за развойна дейност с процесор Intel 8085 за нуждите на "Електроснабдяване" Задачата поех аз заради натрупаният опит и знания за системният софтуер на аналогичният едноплатков компютър на Motorola и знанията за организацията на BIOS-a на XT и неговият аналог в Apple - "монитор" - Недовършена в напреднала фаза поради отпадане на необходимостта - рък. Д. Славов, кат СТ 1989-90г
• Система за снемане на индикаторна диаграма на дизелов двигател (налягането в нагнетаталната помпа на дизеловият двигател на всеки градус от завъртането на коляновия вал на двигателя - до 2000 оборота в минута, до 570 атмосфери налягане при впръскване - в реално време на Правец 82 с 1 MHz процесор и 64К РАМ от които около 47К програмно достъпни). Целта беше да се изследват характеристиките на гориво нагнетателната помпа на дизеловият двигател при пригаждане за работа с пропан-бутан към дисертацията на рък. гл.ас. Славчо Жечев кат. ДВГ, лаб. "Гориворазпръсквателна апаратура" До момента това се правеше, като системата получаваше синхронизация за градусите и за оборот от оптични двойки следящи перфориран диск монтиран на коляновият вал и запускаше осцилоскоп, а от екрана на осцилоскопа се правеха снимки с лентов фотоапарат + цялата романтика по проявяването на снимките. В новата система използвахме перфорираният диск, оптичните двойки и наличните датчици като даденост (а то други варианти и нямахме), напрежението което даваше пиезодатчика, се съгласуване сигнала през предусилвател и усилвател които г-н Жечев конструира, имайки опит от дотогавашният си начин на работа с високоомният пиезодатчик, изискващ и особено високоомен вход на интерфейса, който снемаше сигнала от него, а аз констриурах контролера с АЦП СМ757 и специално разработената за целта аналогова памет, управлявана по софтуерен път и написах софтуера за управление на измерванията и записване на резултата ( Асемблер за 6502 - ПРАВЕЦ 82) А впоследствие и модул на Apple BASIC, който да визуализира графично резултата, да дава възможност за мащабировка и курсор-линия за посочване на интересни точки, визуализация на стойности и поставяне на маркери. 1990-91г Елементарните сметки показват, че при 2000 об/мин, един градус от оборота на двигателят се превърта за около 83 микросекунди. Бавният от днешно гледище Правчо с неговият 1 MHz тактова честота ( всъщност 1.017 за получаване чрез делене на честота за видеоизхода) и алгоритъма на измерващата програма и хардуера на контролера можеше да измерва при минимално време на цикъла сканиране - запис - ново запускане на аналоговата памет 47 микросекунди, а за избягване на грешки - 53 микросекунди, с време между две сканирания за синхронизация 6 машинни такта. Времето на цикъла сканиране-запис би позволило да се сваля същата диаграма при повече от 3500 оборота в минута. "Правчо" се превърна в история, непозната за новото поколение IT специалисти, но дизелов двигател, работещ на 3500 оборота все още не е създаден...
• Програма - Покер, който играе хитро без да лъже потребителя, но следи картите които биват обявявани и играни (от средата на 90-те години в САЩ "следенето" е забранено със закон), анализира поведението на опонента, изчислява кои карти са в неизвестност (а те са в опонента или в банката) и изготвя алгоритъм на блъф. В процеса на изпълнение програмата самомодифицираше изпълнимата си част, като генерираше и вмъкваше в тялото си нови редове, които коригираха поведението й и си ги изпълняваше след това. Сега такива възможности откривам в JavaScript, но за съжаление все още съм много далеч от нужното ниво на познаването му. Имаше сериозни проблеми с анализа за премахване или игнориране на вече ненужни редове, поради което трябваше всеки път да се стартира от едно и също начално съдържание, което беше проблем и цел на бъдещо алгоритмично надграждане. Това правеше невъзможен и опит за втори блъф в една игра - наследяваха се стари модели базирани на предишни ситуации.
Програмата нямаше графичен интерфейс и визуализация на картите, а играеше с буквено - цифрени означения за тях картите, като по ред причини не ми остана възможност да работя над графичен интерфейс и довеждането и до продаваема компютърна игра. (1990г - политически вълнения, стачки, купонна система за хран. продукти, режим на тока, принудителна работа по строежи за изхранване). По принцип и особено на него етап това не ми беше и цел. Целта ми беше формирането и доразвиването на поведенчески алгоритмичен модел, както и алгоритъм на "мислеща" програма но по ред причини това не беше донаправено. Междувременно сорсът на програмата беше нелепо унищожен - (намокрена от дъжд кутия с дискети).
(личен проект 1989-90г)
• Разработка на датчици и централи за СОТ с цел започване на малък бизнес. Използвахме разработки от курсовите си работи по "Осигурителна техника" от предният семестър, които доведохме до реални изпълнения с достъпна за момента елементна база. Бяхме импонирани от нашумялата тогава поредица от филми за Индиана Джоунс, където Инди се натъкваше на разни хитроумни капани, а стандартни датчици за СОТпросто все още не се продаваха. Поне не в бившият соцлагер. Идеята се обезсмисли търговски, но не и технически заради невъзможност да осигурим реакция по защита (посещение от патрулка) на обекта със задействан СОТ и финансова и законова възможност за поемане на застрахователни ангажименти, което и обезсмисли по- нататъшната работа по разработките и изграждане на СОТ.
Все пак разработихме капацитивен датчик за присъствие със самокомпенсация на измененията от влагата във въздуха, сензорна цифрова ключалка със time-out защита при сгрешен код в добавка при сгрешен код сензорната част се отцепваше и през нея при докосване се разреждаше кондензатор, зареден от мрежата през диод, инфрачервени датчици за пресичане на охранявана зона, осигурени срещу "заслепяване" с лампа, система за дистанционна незаглушима автомобилна аларма с опция "тих" режим, която при активиране да не притеснява крадеца, а да задейства приемника на собственика, който да вземе изненадващи мерки или да звънне на полицията и със заложена възможност за проследяване чрез пеленговане. (Незаглушимостта идваше от това, че централката излъчваше радиосигнал на 8 честоти, като ги обхождаше циклично една по една. Приемникът беше предвиден с кодировка за следене на същите честоти, повтарящи се в същият цикъл и сработваше при детектиране на 6 честоти от порядъка в цикъла. В случай на заглушаване на сигнал чрез излъчване на някоя от честотите, то системата на мястото на редовният сигнал би прихванала заглушаващият, и пак би сработила. Проблемите за приложението на системата бяха два: От една страна наличната елементната база, която не позволяваше миниатюризация и минимизация на захранването (критичен беше приемникът за собственика - централката имаше къде да се скрие в автомобила и да "краде" ток от габаритните светлини, с който да подзарежда локално акумолаторче монтирано заедно с нея на недостъпно място, така че даже да се откачи пусковият акумолатор, нейният собствен да продължи да захранва), от друга страна липсата на възможности за проектиране и изработване на аналогови филтри с добри характеристики. (съавторство с А. Собаджиев) 1990-91г
• Опит за създаване на система за гласово разпознаване на команди чрез автокорелационна функция и самообучаване чрез съпоставяне на предишни изговори на командата. - Личен проект 1990-91г
(всъщност преработка на софтуера на системата за снемане на индикаторната диаграма от дизелов двигател и добавяне на софтуерни модули за корелационен анализ, понеже направеното по хардуера до момента искаше само малки добавки, за да може да се ползва за целта. Трябваше да се добави към контролера малък модул с таймер 555 (като в контролера за управление на ВЕИ), който да задава тактовата поредица, която да запуска сканирането през интервали от време наместо импулсите от оптодвойките на диска, закрепен на коляновият вал. За да бъде разпозната гласова команда, според теоремата на Котелников трябва да фиксираме минимум 3 точки от най-високочестотният хармоник в разложението на сигнала в ред на фурие. При изговаряне сканираните точки от звука се запазваха в масив. При неколкократен изговор на една и съща команда по леко различен начин (желателно от различни хора) отделните изговори след нормиране по продължителност да се сравняват и така да се оформи звуков "профил" на командата, но с отчитане на изместването на честотният спектър на записа след разтягането или свиването на продължителността му във времето. Позвуков анализ със сравняване в правописна речникова база данни тогава по ред причини беше "висока топка" - имаше трудности с позвуковият анализ, (макар че вече имаше "говореща програма от Борислав Захариев" - тя беше насочена към синтезирането и извеждането на звуци, а не на разпознаването им), нямаше достъпна речникова база данни, а обемът памет и скоростта на дисковите операции при липса и на търсачки правеха задачата принципно нерешима и без да говорим за реално време. За да се решат всички тия въпроси трябваше многократно повече работа от самата задача. И сега гласовото разпознаване на смартфоните работи, само когато има връзка с интернета, по причина, че в самият апарат няма сериозен правописен речник база данни (е има за Т9, но е доста постен), а алгоритъмът на разпознаване на думи вероятно е сходен с тоя на OCR програмите.
Имаше обаче много сериозен проблем за разрешаване:
Ако за гласовите команди приемем за честотна лента стандартната телефонна лента (300 Hz-3.4 KHz, която е най-тясната от дефинираните и сега като стандартни и с най-ниска горна гранична честота), то излиза, че за да свалим 3.4KHz с по 3 опитни точки в рамките на периода на най-високата честота от сигнала,то за секунда запис трябва да извършим над 10 000 измервания. При 8 битово сканиране (което не е толкова точно и създава възможност за грешки в разпознаването) това са малко над 10 килобайта за секунда и обработката на една простичка команда като HOME (изчисти екрана) би било таванът на възможностите на Правец 82 (Apple][ ), който имаше малко под 48К програмно достъпна памет - и за програма и за данни и нямаше да се съберат програмата, записаните данни от текущото сканиране и съпоставими данни от предни гласови сканирания. По конюнктурни причини нямах достатъчен достъп до компютър XT на който да работя когато си искам, а и доста от достъпните XT-та в института не бяха наситени с 640КB или 1 MB памет, а с едва 256 КB памет. Нямах и компоненти и време за създаване на втори контролер - за XT, като се има впредвид че и целта ми беше друга, а контролерът - инструмент. Явно паметта беше крайно недостатъчна. Само файла, който четете в момента е доста по-голям без да има картинки в него. Това наложи създаването на модул с допълнителна памет и контролер за управлението й. Проектирах модула памет с контролера за управление, даже поръчах платката, но до реализация не се стигна по финансови причини - нямах пари за паметите. Всъщност по тях времена беше трудно да се намерят и памети. Междувременно докато чаках да ми изработят проектираната гола платка и да набавя памет, бях написал софтуера за свалянето на гласовите команди и разпознаването им чрез автокорелационната функция. Години по- късно научавам, че по същото време Creativ Labs е създавал прототипът на неговият легендарен саундбластер, а екип от специалисти на Lotus-Intel-Microsoft е създавал модул памет и протокол за управлението й станал известен като LIM стандарт и ползван макар и за кратко. Аз се опитах да направя и двете неща сам и с джобните си пари, което се оказа критично твърде близко до успеха. Сега гласовото разпознаване работи във всеки смартфон с Android от 2.2 нагоре, а за повечето други ОС работи, но все още не и на Български език...
Обичам гласовото разпознаване!!!
• Система за измерване на постъпващото количество въздух в цилиндъра на ДВГ (цилиндърът не беше действащ, а монтиран на стенд, за изпитания по промяна на геометрията на въздуховода на цилиндровата глава - проектирани хардуерните модули и написан софтуера) ръков. доц. Пилев 1990г
• Макет на Бордови компютър за мотокар (развойно на Assembler 6502 за Правец 82 за прототип, кат. ДВГ, лаб. "Гориворазпръсквателна апаратура", рък. гл. ас. С. Жечев, съавторство с Б. Алексиев) 1990-91г
Използвахме Правец 82, защото го имахме наличен, вече имахме опит в създаването на контролери и компоненти за тях. Процесорът на Правец 16/XT работеше на 8 или 10 MHz (8086, 8088), ISA шината му на 4.77 MHz и намирането на някой компоненти за таква честота (АЦП/ЦАП, буфери и др) през Лукановата зима беше проблем. Правчо беше несъизмеримо по- удобен за развойна дейност, а и не си позволявахме да изпозваме по-бърз процесор от тоя, с който се предвиждаше да се прави изделието, за да не се окаже на следващ етап, че със задачата се справя само стендовият макет. В добавка все пак имаше флопидисково устройство заради което да не се налага непрекъснато да изтриваме и записваме EPROM памети. Иначе за индустриална реализация на следващ етап беше предвидено след пренаписване на целият софтуер да се използва едночипов микрокомпютър на тропинизирана платка. Пренаписването на изцяло друга платформа не ни притесняваше заради опита придобит от по- раншни подобни задачи, а Боян Алексиев беше спец. ИТ и далеч не се ограничаваше само с редовният курс на обучение. Двигателят се управляваше чрез софтуерен ПИД регулатор, който оптимизираше работата му и заедно с оптимизацията трябваше да даде теоретично до 18% икономия на гориво + осезателно по-добри характеристики на двигателя. Педалът за газта беше заменен с "електронен педал" (колкото при изпълнение на реален мотокар да не се променят двигателните навици на мотокаристите впредвид текучеството им), а корекцията на количеството гориво - чрез хидравлична система, задвижвана от дизелово гориво под ниско налягане, идващо от горивоподкачващата помпа през магнитвентил (който аз изработих), управляван от процесорната система и движещо рейката на горивонагнетателната помпа. Отчитането на реалните обороти на двигателя след задаването им през газ-педала ставаше чрез магнитен датчик, понеже нямаше нужда от детайлност каквато даваше оптичният датчик, но имаше проблеми с мястото за монтажа му и замърсявания при реална експлоатация. Ресурсът на процесорната система на Правец 82 с неговият 1 MHz тактова честота беше предостатъчен да обслужва в реално време всичко това + антиблокираща система на колелата, както и система за следене начина на ползване на мотокара в реално време и водене на статистика за това (моточасове, процентно време работа на празен ход, дори вероятен превозен товар). А предвиденият Intel-ски едночипов микрокомпютър работеше на 2 MHz и със сигурност би покрил ресурсно задачите и имаше повече от достатъчно вградени интерфейси, но с неголямо количество памет. В края на разработката вече имаше едночипови компютри на Intel от 4 MHz серия но по законови причини отпадна фонд РТО за предприятията, а с него и финансирането и прекратихме работата.
• Метод за анализ и конструктивно оразмеряване на аналогови RC филтри - по същество симулатор на електронни аналогови схеми с възможност за виртуална настройка на схемата от симулатора по задание на конструктора в диалогов режим ( АЧХ, АФХ, ГВЗ, коеф. на усилване). (Turbo Basic v. 1.0) документирано – моята дипломна работа, ръководител ас. Атанас Стоянов Такъв софтуерен продукт беше нужен на ПНИЛ по телекомуникации под ръководството на Ивайло Чернев за проектирането на реплики на комуникационни модули за изграждане на телексна връзка по радиоканал с честотна модулация за нуждите на БМФ. Затова бяха нужни филтри с особено точно моделирани характеристики. Впоследствие проектът се провали по финансови причини (БМФ се отказаха темата ), но аз продължих със започнатата разработка и я издигнахме като предложена тема за дипломна работа. До момента много често такива филтри изчислявахме по разни неясно как изведени формули, взети от книжки с приложни схеми, но при реализация често те нямаха нищо общо с изчислените характеристики. Най-лошото е, че липсваше единна и надеждна методика. За удобното въвеждане на формалното описание на схемата (топология и стойности) реших да използвам таблицата на връзките за опроводяване, създадени някоя от индустриално съвместимите CAD системи за проектиране (OrCAD, CadStar или друга), което е и без това е необходим етап при проектирането на електронно изделие с CAD система. Тя дава еднозначна и удобна за обработка информация за възлите на схемата и стойностите на компонентите. Изхождайки от опита и идеите ми придобити от работата над правената 2 год. по-рано системата за символна обработка на аналитични изрази, първоначалният ми замисъл беше да разработя алгоритъм, който по топографията на схемата да съставя предавателна функция, която аналитично да подлагам на параметрична многомерна минимизация с цел настройка, но подходът се оказа неудачен по ред причини: Едната от сериозните причини беше, че в някой случаи даже ръчно не беше възможно да се синтезира предавателна функция на някой популярни транзисторни схеми и от там и невъзможността за създаване на алгоритъм, който от топология да генерира предавателна функция. Алгоритъмът за синтез се усложняваше непредсказуемо, когато някой компоненти трябваше да се заменят с еквивалентни заместващи схеми. Друг сериозен проблем беше, че предавателната функция не се занимаваше с постояннотоковият режим на схемата, заради което усилвателните елементи спокойно можеха да стоят наситени или запушени и да не работят със сигнал въпреки добре моделираните променливотокови характеристики, а продуктът да не открива това.
--- --- ---
Затова се ориентирах към друг подход - След изчисляването по старите методики да се получат долу-горе желаните характеристики и работни точки, колкото за задаване на коректни (макар и не съвсем точни) начални стойности на компонентите за оптимизиране. А след това да моят продукт да моделира финно характеристиките й. Продуктът беше постпроцесор - обработваше схемата след нейното създаване и не можеше да се намесва в оригиналната й топология. след което моят продукт да поеме таблицата на връзките, да изгради по нея еквивалентна схема чрез включване в модела на екв. заместващи схеми на нелинейните и активните компоненти и да започне анализът й. --- --- ---
Анализът започваше с проверка на електрическата коректност на схемата, постояннотоковият режим, оценяваше възможността за частично запушване или насищане на активен елемент при подаване на променливотоков сигнал и едва тогава пристъпваше към приемане на задание за оптимизация (настройка). Анализите при всяка стъпка винаги бяха първо по постоянен ток за определяне на работните точки и постоянно токовите напрежения на входовете и след това с променливотоков сигнал, като на всяка стъпка се тестваше възможността за самовъзбуждане на схемата и превръщането й в генератор. В процеса на оптимизация програмата "обикаляше" по пасивните компоненти на схемата и местеше с малки стъпки стойностите им като извършваше частна минимизация по всеки компонент. след което при изчерпване на възможностите за оптимизация при даден процент на изменение на стойностите на компонентие намаляше стъпката на сканиране на стойностите и извършваше целият цикъл отново. По същество извършваше многомерна оптимизация, като гонеше най-добрата корелация (както при автокорелационната функция за гласовото разпознаване) между "профила" на филтъра, посочен от точките в техническото задание и зададеният коефициента на усилване, и това което се получава при минимизацията. На него етап нямаше как да се гони идеалното съвпадение между двете, но при корелация на целият профил 90-95% резултатът би бил приемлив. Все пак говорим за проценти съвпадение по абсолютни стойности на сигнал и нива най-често задавани в децибели. (3dB определящи честотите на срязване са 0.7171 от нормалното ниво, което е около 28% разлика спрямо абс. ниво в честотата на срязване, а тук говорим за 5-10% разлика в корелацията сумарно на целият профил) Предвидена беше и възможност за задаване на характеристиките както като честоти на срязване и стръмности (децибели или непери на декада- комуникациите и сега ползват извънсистемната единица непер), така и точка по точка (честота - ниво) с цел да се компенсират дефекти в аудио характеристиките на тонколони или др. специфични цели. Всъщност всеки усилвател за музика може да се разглежда като филтър от 20 Hz до 20 KHz. Идеята за "изкривяване" на характеристиките на усилвателя взаимствах от темата за пригаждане на конвенционален дизел за работа с пропан-бутан, където чрез промяна на на геометрията на гърбичките от гърбичният механизъм на помпата се променяха параметрите на впръскване и от подобно "изкривяване" на гърбици при изчисляване на гърбични механизми за ДВГ по методът Полидийн за което бях помагал в една дипломна работа. По техн. задание продуктът е насочен към проектиране на аналогови RC филтри, но след добавянето само на няколко програмни реда (мисля че 4), включващи индуктивности в схемата, той можеше съвсем пълноценно да обработва всякаква аналогова схема по подобие на PsPice на "OrCAD System Corporation", чийто аналог в крайна сметка е. Работещ симулатор PsPice видях за пръв път две седмици преди датата за защита на дипломната си работа, когато беше твърде късно за каквото и да е взаимстване, като и двата продукта (PsPice и моят) удивително си приличаха по замисъл и работа, затова и "подкарах" PsPice с лекота за сравнително сложни схеми. Разликата е, че PsPice за полупроводниковите елементи използва моделът на Gomel-Poon, а аз използвах изучаваният от нас във ВМЕИ модел на Еберс - Мол, който всъщност е орязана версия на моделът на Гумел-Пун и беше залегнал и в изготвените от производителя на тая база модели на компоненти родно производство, които бяха публикувани в техническата литература. Заради вътрешните разлики в моделите (а те имаха различен брой възли в екв. заместв. схеми) нямаше как да се взаимства алгоритъмът от там, друг е въпроса, че да получиш сорсовият код от компилирана и линквана програма е задача, съизмерима по сложност с получаването обратно на яйца от омлета в изходният им вид. Месеци след получаването на заданието за дипломна работа попаднах на описанието на алгоритми за цифрова филтрация, които биха решили много по- елегантно и евтино проблемът, станал повод за дипломната работа но заданието вече беше спуснато, необходимостта отпаднала, а темата за симулацията на схеми ми беше много интересна. Изборът на Borland Turbo Basic беше по много причини. Той работеше и със синтаксис на APPLE Basic като на ПРАВЕЦ 82 и със синтаксис, почти еднакъв с новопоявилият се, но оценен като переспективен още с появата си Borland C. Tова позволяваше едновременно и да се ползват стари модули, писани за други цели и впоследствие при евентуално развитие продуктът да се прехвърли на C с минимален труд по преработката и тестването на голяма част от тях. От друга страна обемът работа по задачата беше огромен и обхващаше както материята изучавана по няколко основни и обемисти учебни дисциплини, така и моделирането им с голяма част от изучаваният математически апарат и изборът на език на който да бъде изпълнена задачата не натоварваше с допълнително изучаване и на него. Дори потребителският интерфейс беше отработен на базата на стари поръчкови курсови работи - програмата сама избораше за визуализация полезната част от графиката, служебните съобщения по анализа на схемата се извеждаха в рамка като табела и съобразена с размера на изписване на съобщението. (От псевдографика, наистина - Сега в HTML това прави BOX моделът с Border), но при мен и с нарисувани "винтчета" в ъглите й, и се разполагаше върху графиката там, където няма да закрие полезна графична информация.
Опция за софтуерна настройка на аналогови схеми от PSPice излезе едва 6 години по- късно през 1998г.
• Програма за преработка на база данни на служба 144 от БТК - Формат "непрекъснат ред" (без елементи за указване край на поле със записи за абоната, в който единственият критерий е дължината на отделните полета и общата дължина на записа, ако тя е спазена), с многобройни увредени през годините записи с нецели полета и автоматично извличане и разделяне на здравите и увредените полета за ръчна документална проверка за целите на служба 144 (телефонни услуги) в БТК 1993г Borland Turbo Basic 1.0
Прекратена след като беше практически готова и покриваше всички тестове заради обявяване на конкурс до който не бях допуснат като служител на БТК. До цялата база БТК не предоставяше достъп за да не се изнася телефонният указател и други фирми да печелят от него. Умишлено загубих програмното досие и програмистите от фирмата, която спечели конкурса по документи се мотаха с дни да разгадават формата и структурата/семантиката на записите, а аз го бях разгадал за едно кафе време, разглеждайки го с PCTools-a.
• Преработка на софтуера на BG фонокартен телефонен апарат, с цел отстраняване на бъгове и премахване на възможностите да се копират фонокарти директно на работещите апарати (Assembler 6800)1994-95г
• Работа в съавторство по софтуера за телетаксуващо устр-во хотелски тип с таксуващ сигнал от АТЦ 16 KHz и разработка на импулсно захранване, модула индикация и филтрите за 16 KHz на устройството. (Ассемблер за едночипов компютър 68HC11, Orcad-SDT/ PCB, SPSice, )- Частен проект 1996г съавторство с ас. Любомир Атанасов и ас. П. Павлов кат. АП