APRS в Киеве ...

[UT5UKA]

еще раз вопрос про WIDEn-n подскажите на пальцах

Правильно ли понимаю:
"Первое число в пути типа WIDEn-n является общее количество Digi скачков желаемых . Второе - количество потенциальных скачков остальных как пакет передается из заданного диджипитер ."

исходя из этого получается если я посылаю пакет с WIDE2-2 - это значит, что я расчитываю что его еще диджипитнут 2 репитера 2 раза, т.е. ты поймал мой пакет и вписал в свой ретранслируемый WIDE2-1* , и отослал его дальше, если кто-то в зоне еще примет, то соответственно он отошлет его дальше с WIDE2* - это значит что мой пакет дальше этого второго диджика не пойдет...

и еще а можно вместо WIDE вставить в унпрото адрес TRACE ? и как правильно?

"Иногда вы можете знать, что фактические digis сигнал проходит через . Родовые позывные скрыть личность отдельных диджипитеров . Чтобы увидеть фактические позывных , вы заменить Позывной «TRACE» для «WIDE» . Теперь каждый Digi вставит свой собственный ( реальный) позывной на пути перед направлением . НА Пример теперь выглядит следующим образом :
RELAY,TRACE3-3 начальный пакет
RELAY*,TRACE3-3 после первого RELAY digipeat
RELAY*,UT4UKA*,TRACE3-2 после первого WIDE digpeat
RELAY*,UT4UKA*,UT5UKA-12*,TRACE3-1 после второй WIDE digipeat
RELAY*,UT4UKA*,UT5UKA-12*,UR3CNO-1*,TRACE3*после третьего WIDE digipeat - полностью использована , неt более digipeats"

[UZ7HO]

исходя из этого получается если я посылаю пакет с WIDE2-2 - это значит, что я расчитываю что его еще диджипитнут 2 репитера 2 раза, т.е. ты поймал мой пакет и вписал в свой ретранслируемый WIDE2-1* , и отослал его дальше, если кто-то в зоне еще примет, то соответственно он отошлет его дальше с WIDE2* - это значит что мой пакет дальше этого второго диджика не пойдет...

Верно, только лучше еще в путь добавлять позывной свой, так виднее будет через какие узлы проходит пакет. Например:

UZ7HO-14>APRS,WIDE2-2 Port=1 <UI C Len=35>:=\54XGVlLT- BAndy, Lubny {UIV32N}
UZ7HO-14>APRS,UT5UKA,WIDE2-1* Port=1 <UI C Len=35>:=\54XGVlLT- BAndy, Lubny {UIV32N}
UZ7HO-14>APRS,UT5UKA,UT5UAK,WIDE2* Port=1 <UI C Len=35>:=\54XGVlLT- BAndy, Lubny {UIV32N}

В UI-View INI заменить строки:

UIFLOOD=TRACE
UITRACE=WIDE

---------- Добавлено в 17:43 ---------- Предыдущее сообщение было размещено в 17:29 ----------

"Иногда вы можете знать, что фактические digis сигнал проходит через . Родовые позывные скрыть личность отдельных диджипитеров . Чтобы увидеть фактические позывных , вы заменить Позывной «TRACE» для «WIDE» . Теперь каждый Digi вставит свой собственный ( реальный) позывной на пути перед направлением . НА Пример теперь выглядит следующим образом :
RELAY,TRACE3-3 начальный пакет
RELAY*,TRACE3-3 после первого RELAY digipeat
RELAY*,UT4UKA*,TRACE3-2 после первого WIDE digpeat
RELAY*,UT4UKA*,UT5UKA-12*,TRACE3-1 после второй WIDE digipeat
RELAY*,UT4UKA*,UT5UKA-12*,UR3CNO-1*,TRACE3*после третьего WIDE digipeat - полностью использована , неt более digipeats"

Ну вот это то, о чем писал, только сам TRACE заменили на WIDE, с той же функцией.

[UT5UKA]

В UI-View INI заменить строки:

UIFLOOD=TRACE
UITRACE=WIDE

Ага, понятно, СПАСИБО! Т.е. ручками поправить файлик ини, а если из пользовательского интерфейса типа через окошки - где это делается? Для общей эрудиции...

ЗЫ: вариант заполнения унпрото адрес APRS,WIDE1-1,WIDE2-2 можно считать правильным, а если вариант APRS,WIDE1-1,WIDE2-1 - как в таком плане пошагово будет отрабатывать "домашняя станция" с дигипитером?
Настройки диги в алиасах например UT5UKA,WIDE2-1 и поле диги роутерс 1=1 ... (диги сетап в уивиев)

А то в голове пока еще каша получилась до сих пор ...

[UZ7HO]

Ага, понятно, СПАСИБО! Т.е. ручками поправить файлик ини, а если из пользовательского интерфейса типа через окошки - где это делается? Для общей эрудиции...

ЗЫ: вариант заполнения унпрото адрес APRS,WIDE1-1,WIDE2-2 можно считать правильным, а если вариант APRS,WIDE1-1,WIDE2-1 - как в таком плане пошагово будет отрабатывать "домашняя станция" с дигипитером?
Настройки диги в алиасах например UT5UKA,WIDE2-1 и поле диги роутерс 1=1 ... (диги сетап в уивиев)

А то в голове пока еще каша получилась до сих пор ...

В меню пытался найти, но не нашел. Правил по старинке, через INI. :)

В случае WIDE1-1,WIDE2-2 сначала отработает первый WIDE, потом приступит ко второму WIDE, в итоге будет 3 хопа.

Да, еще, как мне помнится UI-View подставляет для ACK путь через который пришел пакет. Т.е. в случае если пакет пришел через серию WIDE без подстановки позывных, и был принят на последнем скачке, то ACK-ответ уйдет не на WIDE2-2, к примеру, а просто на WIDE2. Правда, я точно не уверен, надо перепроверить. В случае, если же была задействована подстановка позывных, то в ответе будет фигурировать прямой путь, через который прошел пакет, и уйдет он обратно по этому же пути.

ЗЫ Вообще, как я понял, изначально WIDE задумывался как широкополосная передача своего объекта. Для сообщений более предпочтительно было пользоваться TRACE. Ну это до реформы, как написал Игорь выше.

[UT5UKA]

UIFLOOD=TRACE
UITRACE=WIDE

До замены:

1:Fm UT4UOF To APMI01 Via WIDE2-1 <UI F/R Pid=F0 Len=72> [22:27:54R]
}UT7UV-5>APDR12,TCPIP,UT4UOF*:=5027.29N/03029.00E$ http://aprsdroid.org/
1:Fm UT4UOF To APMI01 Via WIDE2* <UI F/R Pid=F0 Len=72> [22:27:58T]
}UT7UV-5>APDR12,TCPIP,UT4UOF*:=5027.29N/03029.00E$ http://aprsdroid.org/

После замены

1:Fm UT4UOF To APMI01 Via WIDE2-1 <UI F/R Pid=F0 Len=72> [22:32:14R]
}UT7UV-5>APDR12,TCPIP,UT4UOF*:=5027.29N/03029.00E$ http://aprsdroid.org/
1:Fm UT4UOF To APMI01 Via UT5UKA*,WIDE2* <UI F/R Pid=F0 Len=72> [22:32:21T]
}UT7UV-5>APDR12,TCPIP,UT4UOF*:=5027.29N/03029.00E$ http://aprsdroid.org/

Соответственно УОФ пуляет в эфир с WIDE2-1, я принимаю(буквочка R после времени) и ретранслирую(буквочка Т) с WIDE2* + теперь добавляется мой позывной и видно через кого прошел пакет, т.е. моя последняя ретрансляция или по другому получается всего один скачек/хоп ...

Т.е. пакеты слышно ушами, но зачастую уже второй скачек не декодируется.

Вопрос - почему? Мы с Димой когда экспериментировали на 144825 тоже такое наблюдали, хотя никого больше нет в эфире, некоторые пакеты просто не декодятся, хотя ухом их слышно... Я без подключения к нету и Дима тоже, просто пробовали по эфиру сконектиться...

ЗЫ: не густо в феврале с эфирными станциями ...

 Stations heard directly by UR3CNO-1 :
позывной 		pkts 	впервые услышал - EET 	последний слышал 	длинная 	(rx => tx) 	длинной в - EET
UT5UKA 		64 	2014-02-01 17:47:18 	2014-02-06 00:50:40 	KO50FK > KO50EK 	4.3 km 110° 	2014-02-06 00:50:40
UT4UKA 		72 	2014-02-03 20:28:12 	2014-02-06 16:34:25 	KO50DK > KO50EK 	10.1 km 261° 	2014-02-06 16:34:25
UT3UX 		9 	2014-02-02 23:20:18 	2014-02-03 00:39:45 	KO50HJ > KO50EK 	17.2 km 105° 	2014-02-03 00:39:45
UT7UV 		5 	2014-02-01 08:39:47 	2014-02-03 07:27:51 	KO50FK > KO50EK 	6.5 km 75° 	2014-02-03 07:27:51
UT5UAK-12	751 	2014-02-01 02:04:51 	2014-02-06 22:51:09 	KO50DG > KO50EK 	21.4 km 199° 	2014-02-06 22:51:09
UR3CNO-9	298 	2014-02-04 14:24:21 	2014-02-06 11:58:56 	KO50GK > KO50EK 	11.1 km 100° 	2014-02-05 15:37:24
UT2UW-14	11 	2014-02-03 08:00:35 	2014-02-04 13:46:42 	KO50MN > KO50EK 	45.6 km 71° 	2014-02-04 13:46:42

[UT5UAK]

Да, интересно, теперь пакеты traceable! Особенности UI-View... Почему некоторые хорошо слышимые пакеты не декодируются - я сам не знаю. В примере Андрея просто шумы на большом удалении мешают, когда ЧМ не пробивается. Но иногда бывают просто вопиющие случаи: одна станция за 50 км декодируется, а другая за 500 м - нет. Возможно, есть какие-то временнЫе параметры, в AGWPE при настройке модема можно вводить поправки. Но я с ними никогда не игрался.

ЗЫ: 45 км - это неплохо! Ничего, будет теплее - активности прибавится.