• Проучване на фабричните разпечатки на BIOS-а на IBM-PC и "монитор" на Apple ][ с цел "крадене на хватки" (сега това е популярно като "усвояване на лайф хакове") 1990-91г от системното програмиране и познания за организация на системата, специфични адреси, процедури и пр., проучване на работещ софтуер с цел "адаптирането" му. И сега като видя в някой сайт интересен трик, надничам в кода как е направен или какви разширения са използвани с цел бъдещо използване от мен.

• Сваляне на схемите на работещи устройства с цел копиране на изделията за различни цели

• Работа по написването на системният софтуер на едноплатков компютър за развойна дейност с процесор Intel 8085 за нуждите на развойно звено в "Електроснабдяване" Задачата поех аз заради натрупаният опит и знания за системният софтуер на аналогичният едноплатков компютър на Motorola и знанията за организацията на BIOS-a на XT и в Apple - "монитор" - Недовършен в напреднала фаза поради отпадане на необходимосттаи прекратяване на финансирането от "Електроснабдяване" - рък. гл. ас. инж. Д. Славов, кат. СТ 1989-90г

• Система за снемане на индикаторна диаграма на дизелов двигател за изследване характеристиките на работа на гориво нагнетателната помпа на дизеловият двигател в опитната част към дисертация за "Конвертиране на конвенционален дизелов двигател за работа с пропан-бутан" - дисертацията на рък. инж, гл.ас. Славчо Жечев кат. ДВГ, лаб. "Гориворазпръсквателна апаратура" (1990г, р-л инж, гл.ас. Славчо Жечев, Apple BASIC, Асемблер 6502 за Правец82)
Индикаторната диаграма представлява графика от налягането в цилиндър на нагнетаталната помпа на дизеловият двигател на всеки градус от завъртането на коляновия вал на двигателя. За конвенционален дизелов двигател това са до 2000 оборота в минута, до 570 атмосфери налягане при впръскване. При високи налягания, обаче пропанфутанът се свива, което променя количеството впръскано гориво. Освен това той е по- ниско калоричен, но по- лесно запалим от дизеловото гориво и всичко това налагаше промени по нагнетателната помпа, които бяха обект на дисертацията.
До момента това се правеше на стенд, като системата получаваше синхронизация за градусите от завъртането и за начало на оборот от оптични двойки, следящи перфориран диск монтиран на коляновият вал и запускаше осцилоскоп, а от екрана на осцилоскопа се правеха снимки с лентов фотоапарат + цялата романтика по проявяването на снимките. В новата система използвахме перфорираният диск, оптичните двойки и наличните датчици като даденост (а то други варианти и нямахме), напрежението което даваше пиезодатчика монтиран в цилиндър на нагнетателната помпа като сигнал, се съгласуваше през предусилвател и усилвател които инж. Жечев конструира, имайки опит от дотогавашният си начин на работа с високоомният пиезодатчик, изискващ и особено високоомен вход на интерфейса, който снемаше сигнала от него. Аз констриурах контролера с 12 битово АЦП СМ757 и специално разработената за целта аналогова памет (Sample and hold) от дискретни елементи (ОУ, CMOS ключ, R-C група), управлявана по софтуерен път от PIA (както контролера с таймерите в системата за управление на ВЕИ) и написах софтуера за управление на измерванията и записване на резултата ( Асемблер за 6502 - ПРАВЕЦ 82), Впоследствие и модул на Apple BASIC, който да визуализира графично резултата, да дава възможност за мащабировка и курсор-линия за посочване на интересни точки, визуализация на стойности и поставяне на маркери. 1990-91г. По старият (фотографски) метод нямаше принципната възможност да се получат точни стойности от графиката на диаграмата и по тях да се правят по- обстойни анализи. Пресмятаха ги по деленията на екрана на осцилоскопа след оценка на мащабирането. Със системата, която направихме налягането се получаваше в цифров вид като конкретна величина за всяка точка с оценка на грешката от квантуване по време и даваше много повече информация.
Елементарните сметки показват, че при 2000 об/мин, един градус от оборота на двигателят се превърта за около 83 микросекунди. Бавният от днешно гледище Правчо с неговият 1 MHz тактова честота ( всъщност 1.017 за получаване чрез делене на честота за видеоизхода) и алгоритъма на измерващата програма и хардуера на контролера можеше да измерва при минимално време на цикъла сканиране - запис - ново запускане на аналоговата памет 47 микросекунди, а за избягване на грешки - 53 микросекунди, с време между две сканирания за синхронизация 6 машинни такта. Времето на цикъла сканиране-запис би позволило да се сваля същата диаграма при повече от 3500 оборота в минута. "Правчо" се превърна в история, непозната за новото поколение IT специалисти, но дизелов двигател, работещ на 3500 оборота все още не е създаден...

• Програма - игра на покер с елементи на блъфиране (личен проект 1988-90г)
Програмата играеше хитро, но без да лъже потребителя, като обаче следи картите които са били обявявани и играни (От 1996г в САЩ "следенето на картите" е забранено със закон).
Програмата анализира поведението на опонента, изчислява кои карти са в неизвестност (а те са в опонента или в банката) и според преценката си изготвя математически модел модел на блъф.
В програмата се използваше вече доразвитата идея за вмъкване на програмни редове в програмата, като обаче тя сама динамично си ги генерираше в процеса на изпълнение по своя логика и самомодифицираше алгоритъма си. Сега такива възможности откривам в JavaScript, но за съжаление все още нямам голяма практика в писането на JS и не съм опитвал дори и за свой тест да направя самомодифицираща се програма. Имаше сериозни проблеми с анализа за премахване или игнориране на вече ненужни редове, поради което трябваше всеки път да се стартира от едно и също начално съдържание, което беше проблем и цел на бъдещо алгоритмично надграждане. Това правеше невъзможен и опит за втори блъф в една игра - наследяваха се стари модели базирани на предишни ситуации а не бях доработил критерий за разпознаване на авто генерираните редове.
Програмата нямаше графичен интерфейс и визуализация на картите, а играеше с буквено - цифрени означения за тях, като по ред причини не ми остана възможност да работя над графичен интерфейс и довеждането и до продаваема компютърна игра. (1990г - букет от политически вълнения, стачки, купонна система за хран. продукти, режим на тока, принудителна работа по строежи за изхранване). По принцип и особено на него етап това не ми беше и цел. Целта ми беше формирането и доразвиването на поведенчески алгоритмичен модел, както и алгоритъм на "мислеща" програма но по ред причини това не беше донаправено. Междувременно сорсът на програмата беше нелепо унищожен - (намокрена от дъжд кутия с дискети с всички дотогавашни проекти).

• Разработка на датчици и централи за СОТ с цел започване на малък бизнес. Използвахме разработки от курсовите си работи по "Осигурителна техника" от предният семестър, които доведохме до реални изпълнения с достъпна за момента елементна база. Бяхме импонирани от нашумялата тогава поредица от филми за Индиана Джоунс, където Инди се натъкваше на разни хитроумни капани, а стандартни датчици за СОТ просто все още не се продаваха. Поне не в бившият соцлагер. Идеята се обезсмисли търговски, но не и технически заради невъзможност да осигурим реакция по защита (посещение от патрулка или друга физическа охрана) на обекта със задействан СОТ и финансова и законова възможност за поемане на застрахователни ангажименти, което и обезсмисли по- нататъшната работа по разработките и изграждане на СОТ.
Все пак разработихме капацитивен датчик за присъствие със самокомпенсация на измененията от влагата във въздуха, сензорна цифрова ключалка със time-out защита при сгрешен код в добавка при сгрешена цифра,сензорната част се отцепваше и през нея при докосване се разреждаше кондензатор с малък капацитет, зареден от мрежата през диод (310V по върхова стойност) - безопасно, но неприятно - колкото да възпрепятства посегателствата , инфрачервени датчици за пресичане на охранявана зона, защитени срещу "заслепяване" с лампа, Централка за СОТ с възможност за оповестяване по телефонна комутируема линия с номеронабиране. (съавторство с Атaнac. Собаджиев) 1990-91г

• Опит за създаване на система за гласово разпознаване на команди чрез автокорелационна функция и самообучаване чрез съпоставяне на предишни изговори на командата. - Личен проект 1990-91г

За да бъде разпозната гласова команда, според теоремата на Котелников трябва да разполагаме с минимум 3 точки от най-високочестотният хармоник в разложението на сигнала в ред на фурие. При изговаряне сканираните точки от звука се запазваха в масив. При неколкократен изговор на една и съща команда по леко различен начин (желателно от различни хора) отделните изговори след нормиране по продължителност да се сравняват и така да се оформи звуков "профил" на командата, но с отчитане на изместването на честотният спектър на записа след разтягането или свиването на продължителността му във времето. Позвуков анализ със сравняване в правописна речникова база данни тогава по ред причини беше практически невъзможно - трудности с позвуковият анализ, (макар че вече имаше "говореща програма от Борислав Захариев" - тя беше насочена към синтезирането и извеждането на фонетични звуци, а не на разпознаването им), нямаше достъпна речникова база данни, а обемът памет и скоростта на дисковите операции при липса и на търсачки (всъщност нямаше интернет) правеха задачата принципно нерешима и без да говорим за разпознаване на говор в реално време. И сега гласовото разпознаване на смартфоните, след като се сканира и дигитализира аудиосигнала,работи само когато има връзка с интернет, по причина, че в самият апарат няма сериозен правописен речник база данни (е има заради Т9, но е доста беден), а алгоритъмът на разпознаване на думи със сигурност ползва през интернет роботи, работещи по алгоритмите на OCR програмите за разпознаване на сканиран текст.

(Всъщност това беше доработка на софтуера и контролера на системата за снемане на индикаторната диаграма от дизелов двигател и добавяне на софтуерни модули за корелационен анализ, понеже направеното по хардуера до момента се нуждаеше само малки добавки, за да може да се ползва за целта. Трябваше да се добави към контролера малък модул с таймер 555 (като в контролера за управление на ВЕИ), който след като бъде запуснат, чрез генерирана тактова поредица да синхрониозира сканиранията на точки, наместо импулсите от оптодвойките на диска, закрепен на коляновият вал. от системата за индикаторната диаграма на дизеловата помпа. А с таймерите вече имах практика.

По задачата, обаче имаше много сериозен технически проблем за разрешаване - липса на памет.
Ако за гласовите команди приемем за честотна лента стандартната телефонна лента (300 Hz-3.4 KHz, която е най-тясната, с най-ниска горна гранична честота и най- нискокачествена от дефинираните и сега като стандартни), то излиза че според теоремата на Котелников, за да свалим 3.4KHz с по 3 опитни точки в рамките на периода на най-високата честота от сигнала, то за секунда запис трябва да извършим над 10 000 измервания. При 8 битово сканиране (което не е толкова точно и създава възможност за грешки в разпознаването) това са малко над 10 килобайта за секунда, За 12 или 16 битово - двойно повече. И обработката на еднократно изговорена простичка команда с ниско качество на звука като HOME (изчисти екрана) би било таванът на възможностите на Правец 82 (Apple][ ), който имаше малко под 48К програмно достъпна памет, която се ползваше и за програма и за данни и съвсем пък нямаше да се съберат в нея и записани и съпоставими данни от предни гласови сканирания. Явно паметта беше крайно недостатъчна. Само файла, който четете в момента е поне двойно по-голям без картинките в него. Нямаше и алгоритми за аудио компресия, но и да имаше - те биха натоварили процесора и биха били неприложими в реално време. Това наложи създаването на модул с допълнителна памет и контролер за управлението й.
По конюнктурни причини нямах достатъчен достъп до компютър XT на който да работя. Под DOS можеше да се управляват едва до 640 KB памет, а доста от достъпните XT-та в института не бяха наситени с 640КB или 1 MB памет, а с едва 256 КB памет и това слабо променаше нещата. Нямах и компоненти и време и пари за създаване на втори контролер - за XT, като се има впредвид че и целта ми беше друга, а контролерът - инструмент за постигането и.

Проектирах модула памет с контролера за управление за ПРАВЕЦ 82, даже поръчах и ми изработиха печатната платка. Междувременно докато чаках да ми изработят проектираната гола платка и да набавя памет, бях написал софтуера за свалянето на гласовите команди и разпознаването им чрез автокорелационната функция, но до реализация не се стигна по финансови причини - нямах пари за паметите, макар че имаше от къде да ги купя.

Години по- късно научих, че по същото време Creativ Labs е създавал прототипът на неговият легендарен Саундбластер просто за да извлича звук или да получава звуков сигнал от микрофон, а екип от специалисти на Lotus-Intel-Microsoft е създавал модул памет и протокол за управлението й станал известен като LIM стандарт за разширителен модул за памет за IBM съвместими машини, който по същество прави същото, и ползван макар и за кратко.

Аз се опитах да направя две неща, конкуриращи световното ниво (звуков вход и модул за управление на разширителна памет), за да ми послужат като инструменти за решаването на трети проблем каквото решение тогава нямаше публикуван аналог (разпознаване на гласови команди) - сам и само с джобните си пари, което се оказа критично твърде близко до успеха.
Сега гласовото разпознаване работи във всеки смартфон с Android от 2.2 нагоре, а за повечето други ОС работи, но все още не и на Български език...

Обичам гласовото разпознаване!!!

• Система за измерване на постъпващото количество въздух в цилиндъра на ДВГ 1990г - р-л доц. инж. Пилев - кат. ДВГ, инж. ас. Трифон Узунев (Тонев)
(цилиндърът не беше действащ, а монтиран на стенд, за измерване промяната на потока въздух всмукван от стенда след промяна на геометрията на въздуховода на цилиндровата глава. Цел - получаване повече въздух за по- голямо количество въздух за горивна смес, а горивото лесно можехме да регулираме и така с повече горивна смес да повишим мощността на двигателя без да се увеличава работният му обем и без да се променя цялата конструкция на двигателя, освен простата и евтина за изработка глава. Това би позволило и модернизирането на стари двигатели.
- Проектирах и изработих аналогова измервателна система за измерване на дебит на въздушен поток.

• Макет на Бордови компютър за мотокар (развойно на Assembler 6502 за Правец 82 за прототип, кат. ДВГ, лаб. "Гориворазпръсквателна апаратура", съавторство с Б. Алексиев кат. ИТ, рък. доц. Пилев и гл. ас. инж. С. Жечев,) 1990-91г
Тогава изнасяхме за СССР един мотокар с едноцилиндров дизелов двигател, който заради единственият си цилиндър даваше такива вибрации, че за 3-4 месеца пломбите от зъбите на мотокаристите изпадаха, а за 6-7 месеца непрекъсната работа на такъв мотокар от вибрациите ставаха импотентни заради което и често ги сменяха. В края на 80-те години СССР се отвори към света, руснаците станаха придирчиви и вече не искаха да купуват такива мотокари. И тогава някой се договорил българският производител да електронизира с процесорна система мотокарите докато се организира производството на подходящ за целта дизелов двигател, а новият модел да бъде по условие електронизиран. Двигателят се управляваше чрез софтуерен ПИД регулатор (пропорционален - интегрален - диференциален), който написа Б. Алeксиeв на асемблер и който регулатор освен оптимизираше работните характеристики на двигателя, заедно с оптимизацията трябваше да даде теоретично до 18% икономия на гориво.
Педалът за газта беше заменен с "електронен педал" (колкото при изпълнение на реален мотокар да не се променят двигателните навици на мотокаристите впредвид текучеството им), Системата снемаше данни от прдала за газта и от оборотите на двигателя, като се разчиташе на адекватно превключване на скоростите от мотокариста. След преизчисляване и сравняване можду "заданието" от педала и оборотите на натовареният двигател, се коригираше количеството подавано гориво.
Натоварването беше различно, защото освен относително постоянната маса на мотокара, теглото на товара силно варираше, а това променяше и режима на двигателя, и характеристиките, които оптимизирахме.
Корекцията ставаше - чрез хидравлична система, задвижвана от дизелово гориво под ниско (до 70 атм) налягане, идващо от гориво подкачващата помпа през магнитвентил, който проектирах и изработих аз. (нали преди бях стругар и шлосер).
Рейката на дизеловата помпа беше закачена на пружина, а в обратна посока я притискаше хидравлика, командвана от процесорната система през магнитвентила. В процеса на регулиране, в някой ситуации магнитвентила се задействаше за корекции десетки пъти в секунда и така през впръсканото гориво се контролираше режима на двигателя.
Отчитането на реалните обороти на двигателя след задаването им през газ-педала ставаше чрез магнитен датчик, понеже нямаше нужда от детайлност каквато даваше оптичният датчик, но имаше проблеми с мястото за монтажа му и замърсявания на оптиката при реална експлоатация.

За прототип на бордовият компютър използвахме Правец 82, защото го имахме наличен, вече имахме опит в създаването на контролери и компоненти за контролерите. Процесорът на Правец 16/XT работеше на 8 или 10 MHz (8086, 8088), ISA шината му на 4.77 MHz и намирането на някой компоненти за таква честота (АЦП/ЦАП, буфери и др) през Лукановата зима беше проблем.
Правец 82 беше несъизмеримо по- удобен за развойна дейност, а и не си позволявахме да изпозваме по-бърз процесор от тоя, с който се предвиждаше да се прави изделието, за да не се окаже на следващ етап, че заради многотo математика в реално време, със задачата се справя само стендовият макет. В добавка все пак имаше флопидисково устройство заради което да не се налага непрекъснато да изтриваме и записваме EPROM памети или да перпрограмираме (пак като EPROM-и) едночипови компютри. И едните и другите имаха ресурс на циклите програмиране / изтриване, а ни еползвахме самоделни "изтривалки" направени от счупени живачни лампи с неустановени дължина на вълната и интензитет на UV лъчите. Иначе за индустриална реализация на следващ етап беше предвидено след пренаписване на целият софтуер на асемблер за едночипов микрокомпютър и да се проектира тропинизирана платка за защита от масла, нафта и влага. Пренаписването на изцяло друга платформа не ни притесняваше заради опита придобит от по- раншни подобни задачи, макар че се очертаваха трудности с математическяит апарат на ПИД регулатора. а Бoян Алekcиев беше спец. ИТ и също работеше интензивно по НИС и лични проекти. Ресурсът на процесорната система на Правец 82 с неговият 1 MHz тактова честота беше предостатъчен да обслужва в реално време всичко това + ресурс за добавяне на антиблокираща система на колелата, както и система за следене начина на ползване на мотокара в реално време и водене на статистика за това (моточасове, процентно време работа на празен ход, дори изчисляване по преходните характеристики на вероятна маса на превозваният товар).
А предвиденият Intel-ски едночипов микрокомпютър работеше на 2 MHz, със сигурност би покрил ресурсно задачите и имаше повече от достатъчно вградени интерфейси, но с неголямо количество памет. В края на разработката вече имаше едночипови компютри на Intel от 4 MHz серия.
3 дни преди да дойде приемната комисия и да отчетем етапа на темата, едно уплътнение на магнитният вентил който аз направих протече. Ръководителите на темата забраниха да го разглобя и поправя, за да не спре съвсем макета и да ни откажат плащане по етапа на темата, понеже законът за РТО вече беше отменен и довършвахме и се плащаха само стари започнати задачи. Затова този път аз написах втори ПИД регулатор (пак на асемблер), който да компенсира отклоненията породени от теча на дизелово гориво за магнит вентила.
На тестовите изпитания въпреки очевидният теч и грешките които би трябвало да породи, системата се самокоригираше и работеше коректно, което беше отчетено като сериозен плюс извън техническото задание. Малко по- късно окончателно спря дейността по НИС и фонд РТО, а с него и финансирането и прекратихме работата. През 1999-2000г попаднах на система за мониторинг на корабни двигатели от една специализирана испанска фирма, проектирана по същото време, базирана на същият процесор 6502, но тя не управляваше двигателя, а само следеше неговата работа.

• Метод за анализ и конструктивно оразмеряване на аналогови RC филтри - по същество симулатор на електронни аналогови схеми с възможност за виртуална настройка на схемата от симулатора по задание на конструктора в диалогов режим ( АЧХ, АФХ, ГВЗ, коеф. на усилване). ръководител ас. инж. Атанас Стоянов - Документирано - моята дипломна работа.

(По същество това беше математическо моделиране на работата на електронни схеми и автоматизираната им оптимизация. - Turbo Basic v. 1.0 - Научна обосновка - материалът и методите изучавани по "Теоретични основи на електротехниката", Линейна Алгебра и Аналитична Геометрия, Теория на графите, Теория на електронните схеми. Теория на устойчивостта)
Такъв софтуерен продукт беше нужен на ПНИЛ по телекомуникации под ръководството на инж. н.с. Ивайло Чернев за проектирането на заместващи оригиналните (и скъпи) комуникационни модули за изграждане на телексна връзка по радиоканал с честотна модулация за нуждите на БМФ.
Електрониката за морски цели тогава се ползваше някакъв норматив от часове за които производителят гарантираше безотказна работа, след което модулите на устройствата (както и при военните) се подменяха независимо от доброто им състояние. Доставяха се от английски производител на доста висока цена във валута.
По него време БМФ беше петият по големина търговски флот в света, броят плавателни съдове беше голям и с това нуждата от подобни разработки беше остра. Затова бяха нужни филтри с особено точно моделирани характеристики. Впоследствие проектът се провали по финансови причини (БМФ се отказаха темата), но аз продължих със започнатата разработка и я издигнахме като предложена тема за дипломна работа. До момента много често такива филтри изчислявахме по разни неясно как изведени формули, взети от книжки с приложни схеми, но при реализация често те нямаха нищо общо с предварително изчислените характеристики. Най-лошото е, че липсваше единна и надеждна методика за изчисляването им. За удобното въвеждане на формалното описание на схемата (топология и стойности) реших да използвам таблицата на връзките за опроводяване, създадени някоя от индустриално съвместимите CAD системи за проектиране (OrCAD, CadStar и др), което е и без това е необходим етап при проектирането на електронно изделие с CAD система. Тя дава еднозначна и удобна за обработка информация за възлите на схемата и стойностите на компонентите. Изхождайки от опита и идеите ми придобити от работата над правената 2 год. по-рано системата за символна обработка на аналитични изрази, първоначалният ми замисъл беше да разработя алгоритъм, който по топографията на схемата да съставя предавателна функция, която аналитично да подлагам на параметрична многомерна минимизация с цел настройка. Но подходът се оказа неудачен по ред причини:
Едната беше, че в някой случаи даже ръчно и чрез разни евристични подходи не беше възможно да се синтезира предавателна функция на някой популярни активни схеми (съдържащи усилвателни елементи) от разпространените тогава книжки по електроника които се използваха и всъщност работеха добре, а от там и невъзможността за създаване на алгоритъм, който от топология да генерира предавателна функция.
Алгоритъмът за синтез на предавателна функция се усложняваше непредсказуемо, когато активните компоненти трябваше да се заменят с еквивалентни заместващи схеми, където в моделите на компонентите се вмъкваха нови възли и клонове, което променяше динамично цялата топология на схемата и от там затрудняваше създаването на алгоритъм за създаване на предавателна функция.
Друг сериозен проблем беше, че предавателната функция не се занимаваше с постояннотоковият режим на схемата, заради което би могло усилвателните елементи да са близо до напрежението на насищане или запушване или направо да са наситени или запушени и да не работят със сигнал въпреки добре моделираните променливотокови характеристики, а продуктът да не открива това. Затова се ориентирах към друг подход:
След изчисляването по старите методики да се получат долу-горе желаните характеристики и работни точки, колкото за задаване на коректни начални стойности на компонентите (макар и не съвсем точни) от които да тръгне оптимизацията на схемата. А продукта да моделира финно характеристиките й като коригира стойностите на пасивните компоненти без да променя топологията на схемата.
За да прочете топологията на схемата, моят продукт трябваше да прочете таблицата на връзките, която се изготвяше автоматично от схемият редактор с който е проектирана принципната схема. Тази таблица е съществено необходима за редактора за проектиране на опроводяването на печатни платки и се изготвя автоматично.
Таблицата на връзките може да бъде представена в различни формати, но по същество описва възлите на електрическата или електронната схема.
След това програмата отваряше малка база данни оформена като таблица за разпечатване, в която бяха постоянно токовите и променливо токовите параметри на активните компоненти, зададени от производителите им и зареждаше необходимите, ако са представени в базата. Иначе спираше и искаше допустими заменки на компонентите.
След това по тази таблица на връзките, чрез включването на компонентите с техните параметри и стойности да изгради еквивалентна схема, като замени активните компоненти с техните еквивалентни заместващи схеми с включени виртуалните възли от екв. зам. схема.
При постоянно токовият анализ се отчитат характеристиките на нелинейните и активните компоненти за определяне на постоянно токовият им режим и работните им точки.
Анализът започваше с проверка на електрическата коректност на схемата, Изчисляваше напреженията и токовете за да няма недопустими стойности, оценяваше възможността за частично запушване или насищане на активен елемент при подаване на променливотоков сигнал и едва тогава пристъпваше към приемане на задание за оптимизация (настройка) на схемата.
Поради липсата на предавателна функция нямаше възможност за проверка дали схемата може да работи по желаният от нас начин - примерно нискочестотен фултър да заработи като лентов или високочестотен), коeто беше минус на метода. Но да не забравяме, че продуктът беше "интелигентен калкулатор за констуктори", нямаше действащ световен аналог, а го правех сам.
В процеса на оптимизация програмата "обикаляше" по пасивните компоненти на схемата и местеше с малки стъпки стойностите им, като извършваше частна минимизация по всеки компонент.
Анализите при всяка стъпка винаги бяха първо по постоянен ток за определяне на работните точки и постояннотоковите напрежения на входовете заради променяните стойности на пасивните елементи и след това с променливотоков сигнал, като след всяка промяна на стойност (ако схемата е активна) се тестваше възможността за самовъзбуждане на схемата и превръщането й в генератор и ако да - не възприемаше промяната. Нямах време да разработя по- икономичен критерий са устойчивост, който да пести итерации.
След изчерпване на възможностите за оптимизация при даден процент на изменение на стойностите на компонентите, се намаляваше стъпката на промяна на стойностите като се съобразяваше със стандартният ред на компонентите от съотв. клас на точност и се извършваше целият цикъл отново.
По същество извършваше многомерна оптимизация, като гонеше най-добрата корелация между "профила" на филтъра, посочен от точките в техническото задание и зададеният коефициента на усилване, и това което се получава при минимизацията. (както профила за сравнение при автокорелационната функция за гласовото разпознаване)
Проблемът опира до методите от математическата статистика изучавани по физика за оценка на грешката, по принцип нямаше как да се гони идеалното съвпадение между задание и изчислена схема. Но ако успеем да постигнем корелация на целият профил 90-95% резултатът би бил отличен. Все пак говорим за проценти съвпадение по абсолютни стойности на комплекс от сигнал и нива най-често задавани в децибели. (3dB определящи честотите на срязване са 0.7171 от нормалното ниво, което е около 28% разлика спрямо абс. ниво в честотата на срязване, а тук говорим за 5-10% разлика в корелацията сумарно на целият профил сумарно и в абсолютни стойности, а не децибели - вкл. и наусилването)
Предвидени бяха възможност за задаване на желаните характеристики по различни приети в електрониката начини - като честоти на срязване и стръмности (децибели или непери на декада- комуникациите и сега ползват извънсистемната единица непер), така и точка по точка (честота - ниво) с цел да се компенсират дефекти в аудио характеристиките на тонколони или др. специфични цели. Всъщност всеки усилвател за музика може да се разглежда като филтър от 20 Hz до 20 KHz. Идеята за "изкривяване" на характеристиките на усилвателя взаимствах от темата за пригаждане на конвенционален дизел за работа с пропанбутан, където чрез промяна на на геометрията на гърбичките от гърбичният механизъм на нагнетателната помпата се променяха параметрите на впръскване и от подобно "изкривяване" на гърбици при изчисляване на гърбични повдигателни механизми за ДВГ по методът Полидийн за което бях помагал в една дипломна работа.(отново математическо моделиране) По техн. задание продуктът е насочен към проектиране на аналогови RC филтри, но след добавянето само на няколко програмни реда (мисля че 4), включващи индуктивности в схемата на базата на дуалността, той можеше съвсем пълноценно да обработва всякаква аналогова схема (RLC - активни и пасивни) по подобие на PsPice на "OrCAD System Corporation", чийто аналог в крайна сметка се оказа, че е.
Работещ симулатор PsPice видях за пръв път две седмици преди датата за защита на дипломната си работа, когато беше твърде късно за каквото и да е взаимстване, като и двата продукта (PsPice и моят) удивително си приличаха по замисъл и работа, затова и по-късно с лекота усвоих PsPice за сравнително сложни схеми. Разликата е, че PsPice за полупроводниковите елементи използва моделът на Gomel-Poon, а аз използвах изучаваният от нас във ВМЕИ модел на Еберс - Мол, Всъщност той всъщност е орязана версия на моделът на Гумел-Пун и беше залегнал и в изготвените от производителя на тая база модели на компоненти родно производство, които бяха публикувани в техническата литература. Заради вътрешните разлики в моделите (а те имаха различен брой възли в екв. заместв. схеми) нямаше как да се взаимства алгоритъмът от там, друг е въпроса, че да получиш сорсовият код от компилирана и линквана програма е задача, съизмерима по сложност с получаването обратно от омлета на яйца в изходният им вид. Месеци след получаването на заданието за дипломна работа попаднах на описанието на алгоритми за цифрова филтрация, които биха решили много по- елегантно и евтино проблемът, станал повод за дипломната работа но необходимостта вече беше отпаднала, заданието вече спуснато, а темата за симулацията на схеми ми беше много интересна.
Изборът на Borland Turbo Basic беше по много причини. Той работеше както със синтаксис на APPLE Basic като на ПРАВЕЦ 82, така и със синтаксис, почти еднакъв с новопоявилият се, но оценен като переспективен още с появата си Borland C. Tова позволяваше едновременно и да се ползват стари модули, писани за други цели и впоследствие при евентуално развитие продуктът да се прехвърли на C с минимален труд по преработката и тестването на голяма част от тях. От друга страна обемът работа по задачата беше огромен и обхващаше както материята изучавана по няколко основни и обемисти учебни дисциплини, така и моделирането им с голяма част от изучаваният математически апарат и изборът на език на който да бъде изпълнена задачата не натоварваше с допълнително изучаване и на него. Възползвах се и от това, че дори част от замисленият потребителският интерфейс беше отработен на базата на стари поръчкови курсови работи - програмата сама избираше за визуализация полезната част от графиката, служебните съобщения по анализа на схемата се извеждаха в рамка като табела и съобразена с размера на изписване на съобщението. (Като Pop Up прозорци с рамки от псевдографични символи. Сега в HTML и CSS това прави в BOX моделът с Border - примерно за създаване на бутони за менюта), но при мен и с нарисувани с псевдографика "винтчета" в ъглите й, и автоматично се разполагаше върху графиката така и там, където по възможност няма да закрие полезна графична информация (Което вече бях правил за друго).
Тъй като двата модула (постоянно токов и променливотоков) бяха големи, имах вече познатият проблем с малкото памет и управлението на паметта под DOS - до 640KB вкл. паметта за стек и др. системни цели. Затова ги оставих като два отделни модула, които се командваха от един BAT файл, през който двата модула се викаха един друг и го пренаписваха динамично. По този начин те нямаха възможност да си предават параметри, затова ги записваха във файл с данни.
Публикация за опция за софтуерна настройка на аналогови схеми от PSPice излезе едва 6 години по- късно през 1998г но тогава още нямах достъп до интернет за да си изтегля демо. След това не съм го следил.

• Програма за преработка на база данни на служба 144 от БТК - 1993г - за целите на служба 144 (телефонни услуги) - Borland Turbo Basic 1.0 - Базата данни беше във формат "непрекъснат ред" (без елементи за указване край на поле със записи за абоната, в който единственият критерий е дължината на отделните полета и общата дължина на записа, ако те са спазени - вероятно по подобие на формата от лентовите запаметяващи устройства от предишните поколения "динозаври" за изчислителни центрове).
Базата беше с многобройни увредени по различни начини записи - вероятно от спирания на тока по време на запис на данни, с множество нецели или полета с разменен ред на полетата в записа и така цели поредици (неустановимо колко) от следващите неувредени записи бяха практически неразпознаваеми от системата, защото не беше спазен форматът на предшестващите записи.
Програмата трябваше да чете, намира и разпознава типа на записите, да отделя "здравите" в един файл, като по възможност разпознава и разменя полетата със сгрешен тип на записите, а увредените (или каквото е останало от тях) в друг файл.
След това да пресортира записите от азбучен ред по имена на абонатите на телефонни номера и така те да могат да бъдат проверени по абонатните книги и как са заведени за плащане, понеже имаше и доста телефони "фантоми" които се плащаха, а не се знаеше чии са. Информацията от увредените записи след сравняване да се издирва и възстановява ръчно, понеже повредите в БД бяха разнообразни и беше невъзможно да се дефинират критерии за ефективна автоматична обработка..
Работата беше прекратена след като програмата беше практически готова и покриваше всички тестове заради обявяване на измислен конкурс до който не бях допуснат като служител на БТК. До цялата база БТК не предоставяше достъп за да не се изнася телефонният указател и други фирми да печелят от него. Спечели го известна фирма, която изобщо не познаваше ситуацията с базата данни. А аз загубих умишлено програмното досие - Като са толкова велики да спечелят конкурс на който дори не познават условията на задачата - да се справят и без него. И естествено не дадох нито софтуера си, нито информация за него.
И програмистите от фирмата, която спечели конкурса по документи се мотаха с дни да разгадават формата, семантиката и състоянието на записите в БД, а аз преди да получа програмното досие го бях разгадал за едно кафе време, разглеждайки го с PCTools-a като знаех адресите и телефоните на няколко човека, които познавах и с няколко позвънявания на тел 144 за адресите и телефоните на случайни хора за сверка на това какво намирам аз в базата данни и какво четат в 144 за тях.

• Преработка на дизасемблираният от мен софтуер на BG фонокартен телефонен апарат, с цел отстраняване на бъгове и премахване на възможностите да се копират фонокарти директно на монтираните за ползване и работещи апарати (Assembler 6800) 1994-95г

• Работа в съавторство по софтуера за телетаксуващо устр-во хотелски тип с таксуващ сигнал от АТЦ 16 KHz и разработка на импулсно захранване, модула индикация и филтрите за 16 KHz на устройството за получаване на таксуващи импулси от АТЦ. (Ассемблер за едночипов компютър 68HC11, Orcad-SDT/ PCB, PsPice, )- Частен проект 1995-1996г съавторство с ас. инж. Любомир Атанасов кат. СТ и ас. инж. П. Павлов кат. АП