Да ви разсея малко от политическите драми дето ги нищите :)

Имам няколко питания които са тъпи, но със сигурност можете да ударите едно рамо.

Значи тя историята е дълга, но накратко, много си обичам SDR софтуера за общо ползване - gqrx и от години си го ползвам. Проблемът с това е че пичът дето го списва като цяло е загубил интерес и активността не е каквато беше преди няколко години. Нови неща трудно се merge-ват, човекът няма време да ревюира код, има си 1000 други проекта на главата и като цяло е малко отебана в последно време работата. Pull request-и почти не се merge-ват вече, включително и моите - единият за синхронен AM детектор виси, другият - за по-добро потискане на шума, взаимствано от опънсорс DSP библиотека със съвместим лиценз, използваща разни fancy статистически методи. Отделно поне няколко пъти съм виждал хора, които искат добавянето на декодери за масово използвани неща, но авторът на проекта ги отхвърля, защото не вижда как се вписват във философията на gqrx, което според мен е малко жалко. След известна комуникация с него, а и след като ми подхвърлиха идеята, реших да започна експериментален branch, където да имплементирам неща, които биха били полезни и които поради една или друга причина не намират място засега в официалния master бранч. Идеята ми е да се създаде по-активно community, защото в последно време неща като sdrsharp най-малкото доста дръпнаха напред, а gqrx е в застой за съжаление :(

Та така - за момента там са моите промени за синхронния AM демод, потискането на шума, отделно за момента имам имплементирани и ALE (MIL-STD-181-144a) декодер и относително добре работещ CW "декодер" (не е нещо свръхпрекрасно, но за разни радио-фарове и любителски морзове дето не са слаби да се губят в шума и не страдат от много фадинг си е супер - има си адаптивна промяна на WPM, прилично добър FFT tracking, липсва му добър matched филтър и разните супер-дупер екстри на професионалния софтуер, но не е това целта. За общо ползване си е добре.

Та мислех какви други функции биха били полезни за потребителят и които не са застъпени в масовия софтуер. Нагазването в територията с декодерите за какви ли не цифрови режими е малко тъпа идея, сега може би не чак толкова тъпа, но е до голяма степен самоцел. Може би интересно, може би някой ден, но след като има достатъчно софтуер за целта, няма наистина нужда да бухаме всичко в gqrx. Но все пак голяма част от потребителите на gqrx са радиолюбители и тъй като аз не съм такъв, ми е интересно вашето мнение по отношение на по-различна, но чисто радиолюбителска функционалност.

При все казаното за декодерите, все пак има някои неща, които биха били много полезни и биха спестили много усилия - примерно пълна интеграция с DSD - т.е директно от gqrx да можем да прослушваме неща като D-STAR, DMR, NXDN и прочее без да сетъпваме пайпване на аудио през pulseaudio и фалшиви sink-ове, без да стартираме външни програми, без да се хабим да оправяме филтри, да нагласяме оптималната максимална девиация, да не ползваме deemphasis за да не ни насира стрийма към декодера и прочее неща. Тук е евентуално първото ми питане (питанията ще ги сумаризирам накрая на поста де).

Второто е липсата на всякаква подръжка за CTCSS тонове, а това е малко или много използвана функционалност. Дали обаче тя има смисъл при софтуер за прослушване на ефира? Тук евентуално е второто ми питане.

Третото ми питане е - хрумна ми за друго нещо, което малко или много се използва от радиолюбителите (колко много и колко малко не знам - не съм в течение с тези неща). И то е свързано с DTMF и специално с Echolink в частност.

Та въпросите ми са:

1) Преди 2-3 години когато последно се разхождах по-активно из УКВ ефира, имаше доста честоти, на които DSD вършеше добра работа. Колкото и да е глупаво, срещам този проблем сега - тръгнах да интегрирам DSD с gqrx и не мога да си намеря добри тест кейсове. Имам чувството че активността е спаднала в пъти оттогава. Сканирайки бандовете гледам като по-активни честоти са останали DMR-а май на спешна помощ беше, някъде на 146.9нещо и май един-два любителски рипитри на 70см. И никаква активност, там където го има с часове всичко е idle фреймове. В продължение на няколко нощи не видях някой да се обажда. А, да, май с едно изключение на 70см на единия рипитър и беше за много кратко. На какво се дължи това, аз ли нещо бъркам, вярно УКВ антената ми не е прекрасна, но преди не беше така. Да не би да е изникнало нещо по-модерно междувременно?

2) За CTCSS тоновете...то проблемът е философски. При "нормалното" радио което приема и предава, CTCSS squelch-а е да речем нещо полезно. При SDR приемника, дали има въобще смисъл от такава функционалност? Всъщност да, може да не е само squelch, може и да откривам CTCSS тонове и някак да ги визуализирам, но има ли смисъл от това? Вие ако си играехте с един скенер, бихте ли намерили такава информация за полезна? Защото няма да е като никаква играчка, но се чудя колко полезна би била за радиолюбители (за мен би било любопитно, но не особено интересно например).

3) Не разбирам от echolink, но документацията е налице и е въпрос да се заровя. DTMF "декодер" не е ужасно сложно да се напише, още повече че има изписан толкова много опънсорс софтуер, че не е проблем и да се взаимства и готов код, стига да няма лицензни драми. Въпросът ми е, полезна (от радиолюбителска гледна точка) функционалност ли е "декодирането" на DTMF кодовете в контекста на Echolink? Би ли ви било интересно да виждате такава информация изплюта от скенера?

Всъщност Echolink все още ползва ли се активно или вече му е минала модата? На кои репитри (в София живея) мога да очаквам такъв трафик?

Благодаря предварително :)

EOF

Като цяло на един радиолюбител му трябва да може да чува добре. Добро подтискане на съседните канали, добро подтискане на шума и разни филтри с които да може да си извади полезния сигнал от бълвоча. Това се постигна по принцип с добри филтри. За да го направиш цифрово трябва доста качествен АЦП. Нещо което трудно се постига с 7 битовия СДР.
Радиолюбителите са хора които обичат да си говорят. Твоите въпроси са за хора които обичат да слушат. Аз лично не намирам смисъл да слушам нещо на което не мога да отговоря. Та в случая софтуерното радио е малко в страни от радиолюбителството като такова. За една хубава далечна връзка си трябва доста сериозна антена. В тази антена освен многото полезен сигнал има и в пъти повече шумове. Дори да приемем, че имам отделно предавател и ползвам СДР-а само за слушане - пак трудно ще извадя слабия полезен сигнал на фона на всички силни смущаващи сигнали които ми забиват гейна на тунера.

Глей го и тоя. Тамън единия млъкне другия зафаща с гупостите. Бачкат двамата в противотактна схема.
Абе откога радиолюбителите са само такива дето обичат да си приказват ? Една определена категория да те само това правят на ангро - но тях ги приспадам към радиоточките щото както в случая колкото ще получиш конкретен отговор от радиоточка толкова и gat3way получи от тебе.
А ние дето обичаме да слушаме по честотите и да конструираме техника да не сме радиомразители или какви сме според твоята дефиниция. Кат не викаш CQ не си говориш за чушки и домати по Р1 и не лопаш по ключа от сутрин до мрак начи си някъв недъгав или половин човек ли как ли ?
Накрая какви битове какви шумове и филтри като човека демодулира силни сигнали тип АМ и CW на КВ и ЧМ на УКВ а ти му пееш за дълги жици и сигнали на нивото на шума. Нали ти каза че не цели да декодира CW на нивото на шума кво повече ти му разправяш да си фърли СДР-а и да си купи лен и ламбово радио че да стане истински радиолюбител.
Ей хора призовавам ви моля ви пийте си хапчетата редовно че ще изпооткажете народа от хобито.

По същество @gat3way CTSS и DTMF са полезни за УКВ анализ - в много мрежи се ползват и е хубаво параметрите да са известни щом ги слушаме. За КВ PSK и RTTY / Sitor що не и другите дето ги има във FLDIGI за да не си играем на PULSEAUDIO както казваш.

Редактирано от az de на 10.12.17 02:52.

Ей да му се не види вие само се карате за глупости :)

RTTY декодер със сигурност ще направя рано или късно (вероятно рано, имам голям интерес). PSK не знам...толкова ли се ползва? Навремето много слушах PSK31, но след това мигрирах към JT65 и после и към FT8. Но виждам че PSK31 още си се ползва. Но не знам дали има смисъл, понеже декодерите които се ползват са изчистени и изпилени до максимум, аз няма какво да се боря с тях, а хората, които се занимават с това искат точно това - изпилено до максимум, да хванат далечния слаб сигнал.

За SITOR декодер съм си мислил също (SITOR-B предполагам?)

Иначе вчера ми пуснаха една муха, а това вече започва да излиза извън разумните граници, но след като ще интегрирам DMR, защо викат да не интегрирам направо кода от telive и да го ползваме да слушаме TETRA. Това е безумие разбира се, но се замислих че точно това е малко криво, някои софтуери са криви за използване и пада едно лепене с плюнка, връзване с тел и прочее. Конкретно такъв е rtl_433 който е хубав декодер за доста ISM простотии на 433-мегахерцовия банд. Той е крив, понеже е правен да работи само с RTLSDR, DSP частта му, специално филтрите му са скапани, банда е претъпкан с неща особено в градовете, не знаеш какво слушаш, не знаеш колко е силно, не знаеш на каква честота е и прочее неудобства. Та реших да го "вградя" (и между другото да си го ползвам пак - само че с airspy вече). Честно казано от това има смисъл и е забавно, хехе

Съдържаниет е скрито
Влезте за да го видите

Редактирано от gat3way на 10.12.17 04:05.

Бе и аз не искам да се караме ама като се изшие някъв такъв мастит чичак с инициал като тоя от нищото и вземе да намила за радиолюбителството както той го разбира съгласно понятията на баба му и ЦС на Д/ОСО и ДОСААФ и проччее при това като го питат съвсем друго и той не го разбира ама си пее та ми става персонално зле. Не за друго ама се опитва да криви възгледите на хората и то тенденциозно и това ми е байгън.

SITOR-B естествено, няма ка да се реализира А без предавател. За PSK ползва се много активно и ефективно в 32 и 64 битови варианти.
ACARS за УКВ може - въобще квото ти хрумне само да предизвиква желание да твориш код. Знам дето RTL не е перфектен но е една чудесна база да стъпиш на нея и да се развиваш. После има и други 10 и 16 че и 24 битови СДР ама като схване човек идеята хардуера лесно се сменя.

Температурата в басейна не е никак лоша чак ми иде да се натопя в него.

Редактирано от az de на 10.12.17 13:53.

ACARS даже ще е лесно, защото съм имал вземане-даване отпреди това, усилие за 1-2 дни ако си преизползвам тогавашната мацаница.

SITOR-B трябва да го проуча повече, не че не може директно да взаимствам нещо готово със съвместим лиценз, но предпочитам да разбера относително добре как работи и какво се случва. За момента го познавам само от "потребителска" гледна точка.

Що се отнася до RTL и 8-битовото АЦП, аз RTL-ите ги ползвам все още доста, въпреки че основния ми приемник е Airspy (12-битово АЦП). Надявам се преди коледа да ми пристигне играчката за по-сериозни DX занимавки - airspy hf+. То е с 18-битово АЦП (макар че ефективно се "отрязват" до 16 битови семпли и последните се сервират от USB контролера). За приеми на слаби сигнали това има огромно значение. Докато примерно за да разбера температурата в басейна на училището отсреща или да прослушвам местните репитри, това няма никакво значение - RTL-четата си вършат прекрасна работа, а като се има предвид че не струват нищо....

EOF

Кофтито на УКВ-то е, че в повечето случаи интереса ти е лимитаран от това какво можеш да чуеш около теб. Както сам казваш - като няма трафик и най-добрия софтуер да иммаш, бързо ще загубиш интерес. Искам да кажа, че там нямаш голям естествен избор - или слушаш каквото има или трябва сам да си излъчваш за да си натъманиш нещата.

DTMF и CTCSS да декодираш е много полезно, но от това има полза изключително рядко, особено за слушател. Т.е. веднъж-дваж можеш да попаднеш на DTMF с който някой командва нещо, но информацията или ще бъде публична или скоро след това вече ще са сменени. Т.е. полезна екстра е, но ще се ползва много рядко.

за DSD-то - в София има най-много цифров трафик на D-STAR репитрите. С любителските DMR-и нещо става, но не знам какво - уж се развива мрежата, но в София нещо трафика наистина май запада. Преди година имаше един натоварен репитър, после зачезна. Сега има два, но пък разделиха страната уж на групи и не е ясно какво излиза през тях. В момента мисля, че в София са активни 431.825 и 431.875. Ако ти трябва стабилен любителски DMR трафик - всяка събота от 18 часа наше време (не съм съвсем сигурен защото се мени с лятното и зимното време) има световна мрежа, където мераклиите от цял свят се регистрират и се в общи линии се преброяват. Това отнема грубо около час, през което време мисля, че всички репитри, свързани към brandmeister.network се вкарават в режим да предават група 91 (worldwide), по която се води мрежата. Т.е. по това време можеш да разчиташ на трафик, въпреки че не знам как е, защото събота рядко съм в София, а когато не съм, не ловя софийски DMR репитри и излизам през хотспот.

А коя е тая DSP библиотека, която спомена?

Да, криво е това с липсата на трафик.

Преди малко се чу DMR реч в ефира, почти 10-тина минути двама пича си говореха , обсъждаха нещо някакви настройки на радиата си, дори не помня честотата - някъде 439.4-439.5 беше. Значи не е толкова безнадеждно зле, има понякога. Имаше и някакъв друг подобен режим, пак някъде там, но DSD не знаеше за него. Беше по-теснолентов (около 6khz), но не беше D-STAR, нещо друго е, не знам какво. Мен цифровата говорилня не ми е много позната, та нищо чудно че не знам нищо за това. Това за съботата не го знаех, мерси много - значи идеално време за тестване.

CTCSS и DTMF нещата значи ще ги оставя на втори план засега значи :)

Библиотеката е wdsp,

Съдържаниет е скрито
Влезте за да го видите

Сбъркал съм и съм ти написал входа на репитрите, трябва да прибавиш 7.6MHz за изхода им.

Съдържаниет е скрито
Влезте за да го видите

Така, вградих DSD в gqrx и имаме почти целия спектър режими търкалящи патентования MBE codec (без dPMR и yaesu system fusion - първото е нещо което сигурно няма да видя скоро, второто е нещо което силно подозирам че съществува по софийските честоти и би било интересно ако се окажа прав). След цялото упражнение съм много отвратен от цялата работа. Това е едно тотално грешно направление, не съм хам разбира се, но ако бях, бих бил отвратен. Дори не мога да видя файдата чисто откъм честотна лента, тя е точно нищо особено (ако вземем предвид телефонията, данните почти всичко е proprietary при DMR примерно). Всичко това е някакво доста безумно усилие според мен и не мога да разбера как е успяло да вземе превес. На КВ, някак нещата са далеч по-демократични. Блах.

Няма повече да се занимавам с тази шитня заклевам се.

Както и да е, следващото забавно нещо - някой забелязвал ли е колко много контролни trunk канали има в София по UHF бизнес банда (над 440mhz?). Аз бях доста очарован. Има поне 4-5 MPT1327 честоти (с никаква активност в продължение на часове повечето), има също motorola type II като последните са предимно около 2-та метра. Всички които прослушвах имат изключително ниска активност. Следващото забавно нещо ще е декодер за контролния канал. За MPT-1327 ще е относително лесно. За Motorola type 2 ще е доста по-сложно и ще видим какво може да се взаимства наготово. За p25 историите е тотално извън възможностите ми предвид че няма и с какво да тествам. Да, има такъв проект, ама p25 от всичко което чета за него е нещо от което ме боли главата доста.

Ще е супер забавно gqrx да му добавим и лимитирана възможност да слухти trunk канали и да проследява разговори.

EOF

В цифровите режими на УКВ никога не е имало твърде голям радиолюбителски елемент. На практика там Icom се усетиха да "обезмаслят" пазара, веднага ги последваха от Yaesu, но сякаш късно. Единствено по-любителски, парадоксално, са DRM-ите, които макар и просто адаптирани от радиолюбители, в крайна сметка не е невъзможно да се наложат, главно поради ниската си цена, въпреки че реално са най-далеч като удобство за любители.

На КВ всичко е заради идеята - там се дават маса пари за трансивъра, да, но от там нататък фирмите видяха, че няма смисъл да се бъркат. Icom опитаха с D-STAR за къси вълни в два модела, но това не придоби никаква популярност така или иначе, да не говорим да стимулира по някакъв начин продажбите.

Fusion репитър остана май един в София, 439.400 му е изхода. Но нямам никаква идея дали въобще е настроен да работи C4FM. Преди това 439.000 беше Fusion, но преди месеци или му изключиха C4FM-а или направо смениха репитъра. Въпреки ниската си цена, уж символична, на която "подаряват" репитрите от Yaesu, оказва се че качеството им е далеч надолу от нормалното. И май гърмят като пуканки. Аз имам Fusion радио от много отдавна, за всички тези години съм направил една единствена връзка през репитър, като това беше и единствения път в който съм чул нещо на C4FM. Не съм особен оптимист, че лесно ще попаднеш на трафик, въпреки че сравнително отдавна не съм слушал ефира в София.

В общи линии си се натоварил с много неблагодарна работа. От друга страна "на запад" има места, където ефира е къде-къде по-натоварен, там ще оценят усилията ти, но на самия теб няма да ти е лесно.

Има като гледам в общи линии три DMR честоти на 70см, две от тях нямаха никаква активност (едната периодично излъчва idle фреймове, другата много спорадично). Тази на 439.425 ми се вижда най-активна. От време на време засичам разговори там (сутрин и през уикенда - вечерно време много рядко, а точно тогава работя по това

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от gat3way на 18.12.17 01:57.

Здравей gat3way,
би ли написал линка към твоя експериментален branch на gqrx,
за да го инсталирам.

Колкото до MBE codec-а, точно заради затворения му код, все още има радиолюбители, който са кричични или отхвърлят този тип цифрова технология.

Производителите на оборудване предполагам забравиха, че радиолюбитеския сектор все още представлява общество от хова, желаещи по някакъв начин да се развиват в технически аспект.
А затворения код, развива повече зависимост към потребление на технологията, но не и в посока на развиването и.
В същност донякъде радиолюбитеския сектор се превърна в консуматорско общество.

Друг вашен фактор е цената на цифровото оборудване.
А там се чакаше от китайците, към коя технология ще решат да се насочат за производство.

Развитието на цифровите мрежи и особенно на DMR тръгна усилено след като g4klx разработи MMDVM.
https://github.com/g4klx/MMDVM
Този цифров модем, засили интереса към цифровата технология, тъй като улесни достъпа до нея.
А също, че не всичко идва на готово и се предлага възможност за различни технически решения.

Редактирано от sysvladi на 18.12.17 11:28.

За съжаление относно DMR SMS познанията ми се свеждат до това, че там кашата е пълна. Освен тези, описани в ETSI стандарта, всъщност има и поне още два други вида, които са под формата на UDP пакети, като "нормалния" е характерен за Моторола имплементации, а има и "китайски" вариант. В общи линии в радиолюбителската практика се е утвърдила практиката "проба-грешка" докато нещо успее да излезе между две различни радиа. Самите UDP пакети съответно могат да са с компресиран хедър или не, абе пълна боза, но то това никога не е проектирано да е съвместимо чак толкоз между различните производители.

Аз както я разбирам, идеята на DMR SMS е доста различна от това някой да вземе да си пише съобщения с друг. То и няма смисъл, понеже стандарта никъде не имплементира store and forward, т.е. пращайки съобщението то или отива до целта си веднага или не отива никога и толкоз. Там идеята е тези съобщения да се използват като система за оповестяване, т.е. една фирма като си направи комуникационната система да може да се изпращат някакви бележки до всички или групи юзери. Самите потребители и да пращат някакви съобщения, то това са почти винаги предвариделно записани такива, т.е. фиксирани отговори или пък рапорти. Т.е. освен радиолюбител, не мисля че ще срещнеш някой друг на този свят да въвежда ръчно DMR SMS на радио.

Съдържаниет е скрито
Влезте за да го видите

Редактирано от Alenadrow на 18.12.17 11:49.

За да не пиша два отговора: то си е достъпно и сега - в github на

Съдържаниет е скрито
Влезте за да го видите

Благодаря за линка. Щом се билдва, се надявам да го пробвам по празниците - няма да му търсим кусури я.

Съдържаниет е скрито
Влезте за да го видите

Продължих със сканирането аз, реших да разуча как стои въпроса с NXDN, та има....и долу към VHF бизнес банда.....уффффф. Явно всичко научавам последен, хах.

EOF

Матей 20:16 -- "И последните ще станат първи, а първите ще станат последни."

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Здравей gat3way, днес пробвах експерименталния branch, но при мен възникват грешки при компилацията .
Ето изхода:

Scanning dependencies of target gqrx
[ 11%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o
In file included from /usr/include/boost/predef/other/endian.h:11:0,
from /usr/include/boost/predef/detail/endian_compat.h:11,
from /usr/include/boost/detail/endian.hpp:9,
from /usr/include/boost/math/special_functions/detail/fp_traits.hpp:27,
from /usr/include/boost/math/special_functions/sign.hpp:18,
from /usr/include/boost/lexical_cast.hpp:167,
from /usr/include/boost/program_options/value_semantic.hpp:14,
from /usr/include/boost/program_options/options_description.hpp:13,
from /usr/include/boost/program_options.hpp:15,
from /usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/applications/gqrx/main.cpp:46:
/usr/include/boost/predef/os/bsd.h:85:5: error: missing expression between '(' and ')'
#if BOOST_OS_BSD
^
In file included from /usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/qtgui/ism433win.h:28:0,
from /usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/applications/gqrx/mainwindow.h:46,
from /usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/applications/gqrx/main.cpp:42:
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/cism433.h:123:24: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
int register_all = 1;
^
src/CMakeFiles/gqrx.dir/build.make:186: recipe for target 'src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o' failed
make[2]: *** [src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/gqrx.dir/all' failed
make[1]: *** [src/CMakeFiles/gqrx.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

Иначе master branch -а от същото репо се компилира и инсталира без проблем.
Поздрави!

Това е доста странно...онази глупост с инициализацията в хедъра съм я пропуснал, оправена е, но това с boost-а е изключително странно. main.cpp би трябвало да е абсолютно идентично 1:1 с master бранча, там никога не съм пипал. Нямам обяснение за това. Ако създадеш нова билд поддиректория (примерно build2) и от нея прясно викнеш cmake .. && make дава ли го пак това?

EOF

Здравей,
Обнових си локалното репоситори
Пробвах и в нова директория build2, но изхода е:

Scanning dependencies of target gqrx
[ 11%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o
In file included from /usr/include/boost/predef/other/endian.h:11:0,
from /usr/include/boost/predef/detail/endian_compat.h:11,
from /usr/include/boost/detail/endian.hpp:9,
from /usr/include/boost/math/special_functions/detail/fp_traits.hpp:27,
from /usr/include/boost/math/special_functions/sign.hpp:18,
from /usr/include/boost/lexical_cast.hpp:167,
from /usr/include/boost/program_options/value_semantic.hpp:14,
from /usr/include/boost/program_options/options_description.hpp:13,
from /usr/include/boost/program_options.hpp:15,
from /usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/applications/gqrx/main.cpp:46:
/usr/include/boost/predef/os/bsd.h:85:5: error: missing expression between '(' and ')'
#if BOOST_OS_BSD
^
src/CMakeFiles/gqrx.dir/build.make:186: recipe for target 'src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o' failed
make[2]: *** [src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/gqrx.dir/all' failed
make[1]: *** [src/CMakeFiles/gqrx.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

Дистрибуцията е Debian 8.8

Редактирано от sysvladi на 20.12.17 20:19.

gat3way,
Днес обърнах внимание, че при процеса на cmake се открива липсваща зависимост LibITPP, която не се появява при cmake от master branch-a
Инсталирах libitpp-dev libitpp8, но все още излиза грешка, въпреки че намира бибилиотеката.

/usr/local/include
-- Could NOT find LibITPP (missing: LIBITPP_INCLUDE_DIR)
libitpp found.

Потърсих в кода къде е дефинирано LIBITPP_INCLUDE_DIR
Едно от местата е
gqrx/CMakeLists.txt:139:find_path(LIBITPP_INCLUDE_DIR/itpp itcomm.h
Предполагам, че се търси пътя към този хедър фаил itpp itcomm.h
и самия фаил в /usr/local/include, където намирам други хедъри, но не и търсения.

Би ли проверил при теб дали този хедър файл е наличен.

Редактирано от sysvladi на 21.12.17 10:02.

Хм, при мен itpp/itcomm.h е в /usr/include (идващо с libitpp-dev). Тези да не са направили някоя реформа в libitpp техната верица. Както и да е, това не би трябвало да е фатално, libitpp е опционална зависимост, в случай че искаш да анализираш данните в p25 трафика (какъвто така или иначе тук няма). Все пак нямаш ли някъде itcomm.h? Коя версия ти е libitpp-dev?

Що се отнася до libboost-program-options (как мразя boost не е истина, с кеф ще го разкарам това за сметка на доброто старо getopt в чистото C)....все още не мога да разбера откъде се получава това. Да не би да имаш няколко инсталирани версии на пакета (което не е невъзможно - те са си кошмар и съответно и дебианските им зависимости са оформени кошмарно)? Макар че както казваш, master-а си се билдва. Голяма мистерия.

EOF

П.П в момента всъщност проучвам да ползвам itpp за разни опити да декодирам контролните съобщения по NXDN трънка, та от това което знам засега е странно да го няма този хедър.....това се води в общи линии "основния" хедър на itpp библиотеката, всички типове и голяма част от класовете им са декларирани там, би било странно ако са го преименували, доста неща ще счупят предполагам...ма знам ли...

EOF

Да докладвам, че на Linux mint 18.3 всичко се билдва и резултата се пуска. Но само толкоз време сколасах да отделя днес, не съм го дори разглеждал подробно, нито пускал в реално действие. Просто ъпгрейднах машината, билднах и само да кажа, че поне при мен всичко изглежда ОК от раз. Някой от тия дни се надявам да разцъкам.

П.П. А ти има ли късмета да си получиш HF+? В "моя" магазин пише, че са ги леко прецакали и ще доставят май чак от началото на януари. Аз не съм поръчвал де - чакам някакво първаначално ревю от теб.

Аlenadrow, за съжаление при мен "одисеята" продължава.

gat3way, понеже вчера бързах и не съм огледах добре нещата.

1. Днес просто направих символичен линк от /usr/include/itpp към /usr/local/include/itpp :)

2. По отношение на cmake при Could NOT find LibITPP (missing: LIBITPP_INCLUDE_DIR)
След помощ от приятел :), нещата се решиха.

CMakeLists.txt:139

# mbelib (optional dependency)
find_path(LIBITPP_INCLUDE_DIR/itpp itcomm.h
HINTS ${PC_LIBITPP_INCLUDEDIR} ${PC_LIBITPP_INCLUDE_DIRS}
PATH_SUFFIXES libitpp )


При мен вече изглежда така

# mbelib (optional dependency)
find_path(LIBITPP_INCLUDE_DIR itpp itcomm.h
HINTS ${PC_LIBITPP_INCLUDEDIR} ${PC_LIBITPP_INCLUDE_DIRS}
PATH_SUFFIXES libitpp )

3. Наложи се за билдна и инсталирам gnuradio 3.7.11, т.к. експерименталния branch на gqrx при билдването не "харесва" gnuradio 3.7.6, с който работех, нещо му липсваше в хедърите на
gr-analog/include/gnuradio/analog/pwr_squelch_cc.h

4. Излязоха проблеми на:
[ 13%] Building C object src/CMakeFiles/gqrx.dir/dsp/ism433/baseband.c.o
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/baseband.c: In function ‘baseband_demod_FM’:
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/baseband.c:133:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (unsigned n = 0; n < num_samples; n++) {
^
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/baseband.c:133:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

но ги реших :)

5 .Накрая макар и малък, напредъка е до тук:
[ 11%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/main.cpp.o
[ 11%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/mainwindow.cpp.o
[ 11%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/receiver.cpp.o
[ 12%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/remote_control_settings.cpp.o
[ 12%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/remote_control.cpp.o
[ 13%] Building CXX object src/CMakeFiles/gqrx.dir/applications/gqrx/file_resources.cpp.o
[ 13%] Building C object src/CMakeFiles/gqrx.dir/dsp/ism433/baseband.c.o
[ 14%] Building C object src/CMakeFiles/gqrx.dir/dsp/ism433/bitbuffer.c.o
[ 14%] Building C object src/CMakeFiles/gqrx.dir/dsp/ism433/data.c.o
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:98:62: error: ‘strdup’ undeclared here (not in a function)
.array_elementwise_import = (array_elementwise_import_fn) strdup,

/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c: In function ‘data_make’:
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:217:4: warning: implicit declaration of function ‘strdup’ [-Wimplicit-function-declaration]
format = strdup(va_arg(ap, char*));
^
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:217:11: warning: assignment makes pointer from integer without a cast
format = strdup(va_arg(ap, char*));
^
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:240:10: warning: assignment makes pointer from integer without a cast
value = strdup(va_arg(ap, char*));
^
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:259:16: warning: assignment makes pointer from integer without a cast
current->key = strdup(key);
^
/usr/src/gqrx-sdr/gqrx-experimental/gqrx/src/dsp/ism433/data.c:262:23: warning: assignment makes pointer from integer without a cast
current->pretty_key = strdup(pretty_key ? pretty_key : key);
^
src/CMakeFiles/gqrx.dir/build.make:370: recipe for target 'src/CMakeFiles/gqrx.dir/dsp/ism433/data.c.o' failed
make[2]: *** [src/CMakeFiles/gqrx.dir/dsp/ism433/data.c.o] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/gqrx.dir/all' failed
make[1]: *** [src/CMakeFiles/gqrx.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

Между другото коя версия на gcc ползваш?

Редактирано от sysvladi на 22.12.17 21:42.

Нямах днес Debian под ръка да пробвам, иначе бих опитал дали ще се получи същото.

Моята "радиолюбителска" машина е доста "чиста" всъщност - имаше си отпреди build essential, билдвал съм туй-онуй, но в общи линии нищо не е пипано "надълбоко", само довабих едно-две липсващи зависимости, които cmake ме наплю, но от дистрибуцията - на ръка не съм компилирал нищо, освен самото gqrx на gat3way. Въпреки че тоя mint не знам и аз за коя поредна година го ъпгрейдвам, то по-скоро нещата са близки до чиста инсталация, поне що се отнася до билд системата.

Ще погледам по виртуалките, които търкалям за някой Debian тия дни, ако попадна на някой чист обещавам да пробвам дали на него ще мине, ако това ще бъде от полза.

Опасявам се, че проблемите при мен се дължат на компилатора, който е gcc version 4.9.2

Аз също съм на дебиан (наскоро ъпдейтван от jessie на stretch - не си падам по cutting edge неща много).

Апропо, ще ви зарадвам. ITPP е ВЕЛИКА библиотека и спестява много работа. В резултат на това само за един ден, вече имам (почти) работещо декодиране на NXDN type-C трънк канала:

Съдържаниет е скрито
Влезте за да го видите

Редактирано от gat3way на 23.12.17 03:01.

Не, моят магазин (moonraker) твърди точно същото. Е това е хубаво че ще почакам, щото много свободно време за кодене на глупости, като дойде, няма да ми се коди вече :)

EOF

Хм, като гледам ползвам gcc 6.3.0-18. Което не е добре. Трябва да изчистя всички глупости, които трошат по-стари компилатори, защото досега доста нехайство съм проявявал (специално с интеграцията на rtl_433, там свинщината е пълна). Специално такива изпълнения като деклариране на брояча във for цикъла в чист C код аз лично не бих си позволил (но очевидно те са си го позволявали). Тези неща могат лесно да се оправят, но е хубаво че ги репортваш. Обещавам като свърша с "нововъведенията" да мина през всичкия код и да изчистя всички такива простотии.

EOF

Хм в крайна сметка това с началното състояние се оказа забавно - защо не ми излизаха тестовите вектори от официалната документация на стандарта със стойностите от тяхната картинка - първо наистина броят по едно битче за всяко битче което изпращат, дори да не ги смесват. Второ, оплескал съм си сметките. Както и да е, тази част от стандарта не е добре документирана. Като цяло доста самоцелно занимание от любопитство, похабих толкова време за глупости, но ми се изясниха разминаванията в документацията на стандарта. Отивам да се занимавам с mpt1327, интересно какви забави ще са там.

EOF