|
Аз също съм на дебиан (наскоро ъпдейтван от jessie на stretch - не си падам по cutting edge неща много).
Апропо, ще ви зарадвам. ITPP е ВЕЛИКА библиотека и спестява много работа. В резултат на това само за един ден, вече имам (почти) работещо декодиране на NXDN type-C трънк канала:
Още парсване му трябва, но важното е че работи коректно. Моите зли планове да накарам gqrx да следва разговори от трънка може и да се сбъднат. Само трябва да си поговоря с някой разбиращ от тези неща, защото не ми е изобщо ясно какви са бандплановете и как се връзват каналите с реалните честоти.
P.S сега разбирам защо няма и опънсорс декодери (поне доколкото знам DSD+ не е отворен). Спецификацията е грешна. Добре че имам все пак известно вземане-даване с криптография, хаха. Всичкият трафик по NXDN се криптира с поточен шифър, ползващ прост LFSR с 9 регистъра. Началното състояние (ключът) е публично известен и описан в документацията. Полиномът (т.е как се клоква шифърът - кои регистри се xor-ват с кои) - също е описан при това коректно. Според това което са писали обаче, началното състояние трябва да е 0xE4...ма не е, 0x154 е. Не знам на какво се дължи тази разлика, имах теория че за всеки бит изход генерират и изход от шифъра, без значение дали ще го ползват (LICH байтовете в началото на фрейма по спецификация не се криптират)....обаче не е това, проиграх го това и не излиза. Не знам откъде е разминаването. Според мен просто са си оплескали документа без да искат.
Това беше много хубава задача, която ми потроши няколко нощи. Добре че са дали тест вектори пичовете, че да схвана какво не е наред. Другото което не беше наред беше че бях тафнал някакъв viterbi декодер дето не работеше много добре поради някаква незнайна причина. Този проблем libitpp го реши наготово (там има наготово viterbi с punctured codes, дори deinterleaving-а реших с тяхната библиотека да го правя вместо на ръка, голям кеф и мързел).
PS2 друго, което ме дразни (ама не знам дали е добре да дълбая в тази посока) - NXDN48 филтъра в DSD кода е доста тесен, в смисъл достатъчно тесен че скапания RTL-SDR при пускане, в рамките на минута и нещо докато загрее, да му дрифт-не осцилатора дотолкова, че да не може да се декодира вече нищо. С Airspy (а вероятно и с по-новите RTL-чета от rtl-sdr.com магазина) няма такива проблеми. Ама "разширяването" на bandpass-а на филтъра в dsd кода би било голяма свинщина предвид каква свинщина е текущата му имплементация....така че засега ще го оставя. Ако попречи много на бъдещите планове да карам gqrx да следва разговори вече ще си помисля.
PS3 - нямам още и CRC проверки, т.е разчитам че на по-ранна фаза, някъде някое флагче ще е грешно и тем подобни евристични глупутки, които работят добре ако имаш силен сигнал, но се счупват при слаб. Проблемът е много дразнещ. Лесно е да напишеш CRC функция при даден полином. Ама е дразнещо да го правиш когато не е на гранулярност байтове, а битове деба. А при NXDN много го обичат това - контролните съобщения никога не са кратни на 8 бита. За капак ползват няколко различни CRC алгоритъма - за 6-битова и за 12-битова сума, за да има разнообразие. Ама ще се погрижа за това. Така че в последния commit - всички crc глупости в кода абсолютно не се ползват, а те вероятно и не работят половината, защото разчитат на вход - байтове. Много дразнещо това, ма ще се оправим.Редактирано от gat3way на 23.12.17 03:01.
|
Re: Разни (хамски) питания [re: sysvladi]
