433 Group
Радиоэфир => APRS => Тема розпочата: koval від Грудень 08, 2016, 00:34:28
-
Підняв Direwolf на Raspberry PI з RTL-SDR.
Програма ніби працює коректно. Тільки не можу зрозуміти одну річ.
Згідно з статистики сайту www.aprsdirect.com мій i-Gate стабільно приймає маяк з ефіру UR5KSH
https://www.aprsdirect.com/details/statistics/sid/456583
http://prntscr.com/dgnq9s
Але якщо подивитися на raw data то там не буде жодної згадки про UR5KSH
http://prntscr.com/dgnqlv
Тобто на сайті в розділі raw data відображає тільки самий маяк. І не показує інфо про декодований пакет з ефіру.
Те ж саме на шлюзі UR8US-8
сирі пакети http://prntscr.com/dgnrpg
і реальні пакети з ефіру
http://prntscr.com/dgns0r
Хтось може пояснити чому так відбувається?
-
Потрібно дивитись ці сирі пакети на самому модемі, тому що те що йде на сервер, може бути не все. Можливо помиляюсь. Ще треба глянути налаштування Gate RF to IS. Він його часом не по інтернету бачить і кидає про це інфу?
-
"Він його часом не по інтернету бачить і кидає про це інфу?"
Ні, не через Інтернет. Бо коли відключаю апрс по радіо каналу то воно вже не показує прийняті пакети. Це точно.
Сирий пакет постараюся сьогодні дістати і приклад покажу.
-
Щось заплутався зовсім цим "вовком".
Може хтось поділиться працюючим конфігом для "Гейта+Діджипітера"?
І без використання сторонніх програм.
-
Як успіхи? Робочий конфіг з документації коректно працює. Перевіряв в себе на сетапі.
-
Як успіхи?
Нічого не розумію.. (с) Колобки
В лозі 98% ПРЕ Одеса. І багато кого ще чути..
А на APRS.fi значиться прийом, тільки позиційних пакетів Полтави..
Direwolf не дружить з microsat?
Чи воно так і повинно працювати.
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
Так і має бути. Тому що пакети з Одеси та інших проходять в Інтернет швидше ніж долітають до вас, декодуються і залітають в Інтернет.
Хто перший почув, той перший пульнув в Інтернет. Тому ваш Direwolf все приймає, декодує, пуляє в Інтернет. Але оскільки такий пакет вже раніше був переданий, то сервер просто ігнорує його як дублікат. Тому все працює коректно. Для тесту можете зробити APRS маяк який би приймала тільки ваша станція, а інші i-Gate не чули. Тоді вона буде проходити через вас. В мене таке само було. Це така особливість опрацювання APRS.
-
[quote="koval" post=26556]Так і має бути.[/quote]
Дякую! Трохи заспокоїли..
Позиційних пакети, начебто однакові зовні з одного джерела. Чи в них є "мітка часу відправлення", всередині?
Як тоді сервер дізнається, що це різні, по часу відправки пакети, а не один і той самий який прийнятий різними станціями.
Також виходить, що "монітор тропо через APRS" чи APRS рекорди ваших вузлів (https://433.com.ua/forum/index.php?topic=15761.0)
Це гра "хто перший прийме "новий пакет""..
А те що зараз "дальне тропо в мене", не дізнаються.. Бо хтось про це на 100км, раніше повідомив?
Тож для справжнього "моніторингу тропо" Кожен Діджик повинен надсилати інфу на спеціальній окремий сервер для цього?
А не брати данні з мережі APRS. Виходить що так?
-
Чи в них є "мітка часу відправлення"
Мітки відправлення в них немає. Але якщо на сервер приходять два однакових пакети з інтервалом до 2 хв. (2 хв. це час приблизний, вибрано для наочності, точний час треба дивитися в документації) тоді пропускається перший, а інші ігноруються.
Також виходить, що "монітор тропо через APRS" чи APRS рекорди ваших вузлів
Це гра "хто перший прийме "новий пакет""..
А те що зараз "дальне тропо в мене", не дізнаються.. Бо хтось про це на 100км, раніше повідомив?
Все вірно. Моніторити проходження ефіру через АПРС теоретично можна, але результати будуть дуже приблизні. Для прикладу буває таке що ближнійi-Gate пакет не прийняв (бо там була заввада, або два пакети прийшли одночасно і декодувався тільки один з них), а дальній гейт пакет прийняв. Тобто при вдалому збігові обставин далекий і цікавий пакет прийняти можливо. Прийнявши його тобі просто пощастить і це аж ніяк не буде говорити про реальний стан тропо продження.
На мою думку сервіси типу APRS tropo forecast (http://aprs.mennolink.org/) це все "костилі" тому що основна задача АПРСу це доносити інформацію від станції та її координати в радіоефір та Інтернет. Але оскільки на сьогодні це мало кому цікаво, аматори почали допилювати протокол "сайд ефектами".
Тож для справжнього "моніторингу тропо" Кожен Діджик повинен надсилати інфу на спеціальній окремий сервер для цього?
А не брати данні з мережі APRS. Виходить що так?
Десь рік тому я для цікавості написав простий парсер логу pymultimonoaprs (https://github.com/asdil12/pymultimonaprs) який всю декодовану інформацію записував в MySQL і потім через PHP виводив на HTML сторінку. І тільки після цього можна було дивитися реальний стан APRS ефіру. І тоді ми побачили багато різних станцій і пакетів, які на "нормальних" серверах не відображаються. Тому для реального ефіру треба запускати свій декодер і вручну все парсити. Якщо тут є люди яким би було цікаво написати фронтенд для такого парсера то можна було б скооперуватися і зробити щось таке цікаве і більш корисне.
Теж додам що для справжнього моніторингу ефіру створений протокол WSPR (http://wsprnet.org/drupal/wsprnet/activity). Але тут теж не все так просто, тому що для 2 метрів треба стабільний TCXO (https://www.electronics-notes.com/articles/electronic_components/quartz-crystal-xtal/tcxo-temperature-compensated-crystal-xtal-oscillator.php), а для 70 см. треба дуже стабільний TCXO що коштує трохи грошей.
-
На мою думку сервіси типу APRS tropo forecast це все "костилі" тому що основна задача АПРСу це доносити інформацію від станції та її координати в радіоефір та Інтернет. Але оскільки на сьогодні це мало кому цікаво, аматори почали допилювати протокол "сайд ефектами".
да да дадада дададада дада!
Ребят, если гейт ловит (или его ловят) по тропо -- это очень плохо. Это замечательно для дальних УКВ связей, но АПРС совсем не об этом, здесь чем хуже, тем лучше ;)
Если такое часто происходит, то надо крутить антенну: гнуть лепестки к земле, исключать направленность в одну сторону итп.
Вообще в большинстве случаев хорошим показателем будет процент декодированных пакетов (ясен пень, исходим из того, что АФУ и уровни у нас настроены правильно!), он не должен быть обычно меньше 60% и никогда в жизни не меньше 50%. Это говорит о том, что все, что слышим можем декодировать. А если видите, что с какого-то направления приходит много битых пакетов (консоль telnet в фоновом режиме вам в помощь, в случае Microsat), так туда не антенну крутить надо, а в том ареале тупейший диги на однокристалке, баофенге и резиновой антенне ставить.
-
Питання від Ів.- Франківських аматорів
------------------------------------------------------
Маємо Direwolf на діджі, маємо декілька термодатчиків.
Температуру з них отримуємо такою командою:
cat /sys/bus/w1/devices/28-030079a29357/w1_slave | sed -n 's/^.*\\(t=[^ ]*\\).*/\\1/p' | sed 's/t=//' | awk '{x=$1}END{print "T#MIC" int(x/1000)}'
(де 28-030079a29357 - номер датчика)
Всього датчиків п'ять, що як раз корелює із п'ятьма можливими значеннями в одній передачі телеметрії.
Якщо наведену команду виконати в командній строці, вона повертає температуру з датчика із бажаним округленням.
Як зробити так, щоб п'ять (бо в нас п'ять датчиків) команд виконувались послідовно, а поверненні значенні температури відсилались як телеметрія?
Я так розумію, що то має бути окремий скріпт, що опитує датчики та формує пакет так, щоб віддавати Direwolf'ові вже готову строку.
Або складніше: послідновно спочатку передавати нйменування параметрів, потім одиниці виміру, а потім, власне, значення - як це дозволяє стандарт APRS.
https://t.me/APRS_UA
-
Я б не заморочувався з Direwolf, а формував пакет bash скриптом і потім посилав через curl кожні n-хвилин через Cron.
-
Перепрошую, а можна, будь ласка, попросити приклад, якого я б зміг скопіпастити?
-
В Лінуксі кладемо в папку:
/usr/local/bin/
Файли з назвою:
sensor1.sh
sensor2.sh
sensor3.sh
sensor4.sh
sensor5.sh
Кожний файл це команда для запиту температури з кодом:
#!/bin/bash
cat /sys/bus/w1/devices/28-030079a29357/w1_slave | sed -n 's/^.*\\(t=[^ ]*\\).*/\\1/p' | sed 's/t=//' | awk '{x=$1}END{print "T#MIC" int(x/1000)}'
Відповідно в кожному файлі змінюємо назви датчиків на потрібний
28-030079a29357
Робимо файл executive:
chmod +x /usr/local/bin/sensor1.sh
chmod +x /usr/local/bin/sensor2.sh
chmod +x /usr/local/bin/sensor3.sh
chmod +x /usr/local/bin/sensor4.sh
chmod +x /usr/local/bin/sensor5.sh
Переходимо в конфіг Direwolf і додаємо наступний код до вже існуючого конфігу:
CBEACON sendto=IG delay=0:12 every=1:00 infocmd="telem-parm.pl UR3PHP-8 TempDTX,TempDRX,TempETX,TempERX,TempDIGI,None,None,None,None,None,None,None,None"
CBEACON sendto=IG delay=0:13 every=1:00 infocmd="telem-unit.pl UR3PHP-8 Deg.C,Deg.C,Deg.C,Deg.C,Deg.C"
CBEACON sendto=IG delay=0:14 every=1:00 infocmd="telem-data.pl `telem-seq.sh` `sensor1.sh` `sensor2.sh` `sensor3.sh` `sensor4.sh` `sensor5.sh` `echo '00000000' `"
sendto=IG => маяк в Інтернет
delay=0:13 => на 13 секунді після запуску системи
every=1:00 => виконувати кожну звилину
CBEACON sendto=IG delay=0:12 every=1:00 infocmd="telem-parm.pl UR3PHP-8 TempDTX,TempDRX,TempETX,TempERX,TempDIGI,None,None,None,None,None,None,None,None" => генерація назв датчиків
CBEACON sendto=IG delay=0:13 every=1:00 infocmd="telem-unit.pl UR3PHP-8 Deg.C,Deg.C,Deg.C,Deg.C,Deg.C" => генерація значень одиниць
infocmd="telem-data.pl `telem-seq.sh` `sensor1.sh` `sensor2.sh` `sensor3.sh` `sensor4.sh` `sensor5.sh` `echo '00000000' `" => генерація телеметрії
Перезапускаємо софт і все має запрацювати.
-
Дякую! *THUMBS UP* *DRINK*
-
Всем привет есть более подробная инструкция и на какой пин вешать датчик
-
Ось інструкція
https://www.circuitbasics.com/raspberry-pi-ds18b20-temperature-sensor-tutorial/ (https://www.circuitbasics.com/raspberry-pi-ds18b20-temperature-sensor-tutorial/ )
Розділ про підключення WIRING FOR SSH TERMINAL OUTPUT
Розділ про активацію інтерфейсу 1-Wire інтерфейс
ENABLE THE ONE-WIRE INTERFACE
Повинно працювати.
-
ну скажу так
темп не удалось прикрутить
делал все по инструкции выше
-
Давайте допоможу.
На якому етапі у вас "затик" ?