Спасибо большое! А то я голову ломал, не мог понять.

А в режиме широкополосной рассылки есть какие-то ограничения наподобии что первый пакет мы переслали, а другие пакеты с nwkSrc+nwkSeq отбрасываем?
Я смотрю что при приеме пакета void nwkRxTaskHandler(void)->nwkRxHandleReceivedFrame(frame)-> сначала идет функция
nwkRouteFrameReceived(frame) которая делает запись в таблицу маршрутизации в случае большего LQI, либо создает запись если ее нет, а дальше в
nwkRxHandleReceivedFrame(frame)-> идет функция nwkRxRejectDuplicate(header), но...эта функция работает только с nwkSeq, но ведь это значение инкрементируется только в случае когда координатор шлет другой пакет, промежуточные узлы на это значение не влияют.
Если это доступная для разглашения информация, то как работает алгоритм в nwkRxRejectDuplicate(header), в частности фрагмент кода
for (uint8_t i = 0; i < NWK_DUPLICATE_REJECTION_TABLE_SIZE; i++)
{
entry = &nwkRxDuplicateRejectionTable[i];

if (entry->ttl && header->nwkSrcAddr == entry->src)
{
uint8_t diff = (int8_t)entry->seq - header->nwkSeq;

if (diff < 8)
{
if (entry->mask & (1 << diff))
{
#ifdef NWK_ENABLE_ROUTING
if (nwkIb.addr == header->macDstAddr)
nwkRouteRemove(header->nwkDstAddr, header->nwkFcf.multicast);
#endif
return true;
}

entry->mask |= (1 << diff);
return false;
}
else
{
uint8_t shift = -(int8_t)diff;

entry->seq = header->nwkSeq;
entry->mask = (entry->mask << shift) | 1;
entry->ttl = DUPLICATE_REJECTION_TTL;
return false;
}
}

if (0 == entry->ttl)
freeEntry = entry;
}

if (NULL == freeEntry)
return true;

freeEntry->src = header->nwkSrcAddr;
freeEntry->seq = header->nwkSeq;
freeEntry->mask = 1;
freeEntry->ttl = DUPLICATE_REJECTION_TTL;

SYS_TimerStart(&nwkRxDuplicateRejectionTimer);
Я понял что сначала когда первый раз принимается пакет, то записи в таблице nwkRxDuplicateRejectionTable еще нет и мы ее делаем там(src,seq,mask,ttl), плюс запускаем таймер, который раз в 100мс декрементирует значение ttl в записи таблицы. Тоесть запись действительна фактически на протяжении 1000мс.
Когда координатор шлет следующие пакеты то пока их количество меньше 8-и(относительно номера пакета зафиксированного в записи в таблице), то мы в функции не трогаем каждый первый пакет (+1,+2...+7) и зарезаем все остальные их ретрансляции через этот узел.
А зачем мы вычисляем разницу именно между номерами пакетов посланных координатором uint8_t diff = (int8_t)entry->seq - header->nwkSeq; ? Или я неправильно понял как работает этот фрагмент кода?

Да, это тоже делается через Duplicate Rejection Table.

Но им все-равно нужно знать обрабатывали они этот кадр уже или нет. Например для определения циклов в таблицах маршрутизации.

Или импользуйте тег code или не цитируйте большие куски кода, когда нет необходимости.

Разница вычисляется между номером входящего пакета и запомненного как номер первого кадра в маске. Это делается чтобы понять попадает-ли принятый пакет в маску или нужно сдвигаться на много (по сути очищать маску). Такое легко может произойти если узел послал нам кадр, затем 50 кадров кому-то еще и снова нам. Разница будет 50, поэтому маску можно очищать, все что там есть уже не верно.

Прошу прощения! Я как-то не обратил внимания что есть такой тег.



я имел ввиду ситуацию на подобии как на рисунке:

Пакет от узла 2 идет к узлу 4, далее к 3, а затем снова к 2.
Узел 2 отсеивает повторные пакеты приходящие к нему только по такому критерию что у этого пакета будет хуже LQI(длиннее путь)?
Я просто смотрю что rejectionTable работает только с nwkSeq, и если nwkSeq постоянный(по сети гуляет один и тот же исходный запрос, меняются только macSeq,macSrc и LQI), то первый раз маска равна 1, а дальше, т.к. diff=0, маска не меняется

Это то самое обнаружение петель в маршрутах. LQI тут никак не используется. Для обычных кадров он даже не накапливается, так что невозможно сказать насколько длинный маршрут.

"return true;" под приведенным if-ом говорит о том, что кадр нужно игнорировать. Маску при этом как раз менять не нужно, она показывает какие кадры мы уже видели.

Александр, спасибо Вам за пояснения!
Еще не до конца понял как работает маска и почему мы не фильтруем пакеты с текущим nwkSeq(который заносим в таблицу), а только последующие..
Я просто не пойму как число 8(эта разница в номерах пакетов) связано с DUPLICATE_REJECTION_TTL(1000мс), ведь когда разница больше 8-и то тогда мы переписываем маску и перезапускаем ttl, а когда меньше 8-и то не трогаем ttl, ждем пока выйдет таймаут.
Завтра постараюсь разобраться.

8 - это просто удобное число. Мы помечаем в маске номера принятых кадров, до 8 кадров могут прийти не в своем порядке, такое может случиться, например если с приложения в один и тот же момент послать зашифрованный и не зашифрованный кадр. Номер назначается до шифрования, так что даже если обработка зашифрованного кадра началась раньше, послан он будет позже. Или при маршрутизации, номер тому кадру, для которого ищется маршрут уже назначен, но кадры поиска маршрута уйдут раньше. И еще туча вариантов когда такое может случиться.

Маска - это история принятых кадров до 8 кадров назад. Так что если мы приняли кадр с номером меньше, чем текущий запомненный, то это еще не означает, что его нужно игнорировать, нужно проверить маску и если он уже стоит в маске, то игнорировать, иначе - добавить в маску и принять.

Добрый день, Александр!
Я немного запутался - подскажите пожалуйста я правильно понял что nwkSeqNum инкрементируется каждым узлом, который:
- либо шлет пакет routeDiscovery, routeReply или routeError,
- либо принял пакет routeDiscovery, routeReply или routeError и ретранслирует его дальше,
- либо посылает подтверждение (ACK),
- либо посылает Data(не ретранслирует а именно посылает, т.е. является инициатором посылки данных)?

Номер macSeqNum в свою очередь инкрементируется каждый раз когда что-либо передаем-ретранслируем(ищем маршруты, передаем данные, пересылаем данные и т.п.)?

Александр, у меня еще вопрос по поводу функции nwkRxRejectDublicate():
1) Когда происходит первая запись в таблицу nwkRxDuplicateRejectionTable? Тогда когда узел принимает первый пакет и вызывается функция nwkRxRejectDublicate?
2) Например у нас пришел пакет с nwkSrc=1, nwkSeq=1.

Почему одни пакеты пропускаются а другие нет?

Вы придумываете слишком сложные правила. macSeqNum увеличивается при каждой физической отправке кадра. nwkSeqNum увеличивается только узлом источником кадра, транзитные узлы его не трогают.

Все остальное вытекает из этих правил.

Происходит разделение на логические уровни. Поиск маршрута происходит уровнем выше, чем все эти увеличения номеров.

routeDiscovery отправляется как локальный броадкаст - только узлы в прямой видимости могут его принять. Приняв его, они формируют новый кадр и заново его отправляют. Это не маршрутизация, это именно создание нового кадра, который не имеет ничего общего с прошлым.

routeReply отправляется юникастом к узлу, который известно, что находится близко, остальная логика такая же.

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



У вас ошибка в сдвигах.

Если diff=0b00000101, то (1 << diff) = 0b00100000.

При сдвиге 1 на сколько угодно в результате будет только 1 единица.

Прошу прощения, я ошибся. Я почему-то посчитал что не 1 сдвигается на определенное число разрядов, а diff сдвигается на один разряд.

Александр, заранее прошу прощения за глупый вопрос, но можете пожалуйста расписать зачем в выражениях ниже используются сначала знаковый, потом беззнаковый, приведения типов...я запутался в том что получиться на выходе.

если например entry->seq=2 а header->nwkSeq=5. Итого я так понимаю -3=0xFD.
Зачем сначала преобразуется число в знаковое, потом результат приводится к беззнаковому?
и зачем здесь делается операция унарного минуса а потом приводиться к беззнаковому?

Чтобы отрицательные числа превратились в большие положительные. Иначе "diff < 8" будет верно и для -3, а это не то, что нужно в данном случае. Нужны только положительные сдвиги.


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

Александр, спасибо Вам большое за пояснения!!!
Все, кажется теперь я наконец-то понял как работает это все. Я изначально принял неправильные утверждения относительно того что routeDiscovery идет с одним номером от узла источника по всей сети, а не отправляется каждым узлом промежуточным по-новому с учетом извлеченных из него данных записанных в таблицу.
И проблема устранения зацикливаний решается тем что сначала пакет проходит через функцию nwkRxRejectDuplicate, которая устраняет повторные пересылки, а дальше уже обрабатывается routeDiscovery исходя из LQI, т.е. всегда в таблице содержиться один путь назад, но самый лучший с точки зрения показателя качества.
Теперь еще попытаюсь понять как формировать и рассчитывать этот показатель качества пути.

И тут скорее всего придется много экспериментировать. LQI из IEEE 802.15.4 чипов удобен тем, что показывает насколько легко было принимать кадр и не зависит от RSSI. В вашем же случае только на RSSI опираться опасно, так как внешний шум будет приводить к увеличению RSSI, но ухудшению качества приема. Придется играться еще и длинной маршрута, и возможно, историей связи с конкретными узлами.

Нет, внешний шум не приводит к увеличению RSSI. Поскольку измеряют его на сигнале а не на шуме. Зависимость LQI от RSSI есть но она не простая.
Но согласен, что только на RSSI опираться опасно, из за особенностей канала передачи.

Какая магия исключает шум во время приема сигнала?

При измерении RSSI измеряется мощность сигнала, а не спектральная плотность мощности шумов в полосе приёма.

Откуда приемник узнает сигнал это или шум? Если в измеряемой полосе есть шум, то его мощность добавится к мощности сигнала.

PS: Ну и от радио зависит метод измерения.

RSSI (Received Signal Strength Indication), слова шум (Noise) как-то не пишут. Для того и приёмники те деланы, чтобы знать где синал, а где шум.
В параметрах приемника задается предельная чувствительность для указанной полосы (как пример -128dBm, для полосы 1KHz) Приемник, для детектирования должен иметь превышение (по разному от вида модуляции) ~ от 3 до 10dB. Определяется RSSI по синхропосылке или позже. Без приема синхры, как правило нет смысла в измерении RSSI. Поробуйте поэкспериментируйте, подав шум на вход приемника, чтение из регистра RSSI даст минимальные значения.

Signal тут больше для обозначения всего что принято, так как приемник (да и человек тоже) не может отличить в оцифрованном сигнале что шум, а что нет.

RSSI - это не какой-то фиксированный параметр, на просто общий термин. Говорить о том, что именно он означает бессмысленно в отрыве от конкретного радио. К примеру из DS на ATmega256RFR2:

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

Пробовал много раз на IEEE 802.15.4 - RSSI растет, так как это просто мощность принятого сигнала (в широком смысле, включая шум).

Или ошибаетесь, или неверно измеряли. У шума RSSI измерить нельзя для этих приемников. Если измеряете просто мощность в полосе, то это не RSSI.

О каком радио идет речь?



В DS на TRC102 есть хороший график "Input Power vs RSSI Voltage". RSSI зависит только от входной мощности.

Так же для настройки приемника рекомендуют слушать вход и уменьшать КУ LNA пока он не попадет в разумные рамки:


Ну и тот факт, что в помощью аналогового выхода RSSI можно восстанавливать ASK сигнал говорит о том, что они просто детектируют и интегрируют входной сигнал и оцифровывают результат интегрирования.

В TRC102 в зависимости от зашумленности рабочей частоты RSSI меняется. У меня дома и на работе это разные значения. Дома например порядка 0.5В, на работе это где-то 0.6-0.65В. Я эксперементировал с RSSI, я его измеряю именно во время приема данных, т.е. когда я принял первый байт(после приема преамбулы) (а байтов у меня больше 5-и), соответственно я считаю что в данный момент идет передача как раз другим узлом и я могу измерить уровень несущей на входе своего узла.
Проблема возникает в том что шум имеет вид небольших всплесков, а когда передающий узел довольно сильно отдален от приемного узла, то RSSI(судя по осциллограмме) находиться фактически на уровне шумов.
Вообщем тут довольно большой простор еще для экспериментов. Действительно надо будет подумать исходя из каких комбинаций параметров лучше рассчитывать показатель качества канала. Я использовал комбинацию RSSI(между каждым из узлов по пути)+число узлов, в итоге на выходе я мог просмотреть и решить есть ли слабые звенья по пути с плохим уровнем сигнала, какое количество хопов у меня и т.к.
Я вот не знаю как бороться с проблемой когда например при поиске маршрута маршрут вычисляется, вроде между всеми узлами маршрута качество нормальное, однако через некоторое время, когда собственно бегают пакеты, между узлами возникло временное препятствие(прошел человек и т.п.), качество связи временно ухудшилось в результате чего пакеты потерялись. И получается что вроде как и маршрут нормальный и проблемы на его пути периодически возникают. Накапливать статистику по качеству сигналов между узлами что-ли, так памяти надо много.....

А какой вид модуляции используется?

FSK модуляция.

Я хотел предложить попробовать OOK на низкой скорости, но TRC102 ее только принимать умеет и то только как хак, так что не судьба.

А какое бы она дала мне преимущество по сравнению с частотной модуляцией?

Демодуляцию можно на процессоре выполнять, а там от помех уже больше способов избавиться, например за счет расширения спектра и согласованной фильтрации. Скорости получатся вообще маленькие, зато можно настоящий взрослый LQI сделать, прямо как в 802.15.4.

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

На самом деле там все довольно просто. Если есть возможность сменить радио и выбрать более низкую скорость, то я бы так и сделал. При желании я могу рассказать что именно и как делать.

Тут нет однозначности в преимуществе. Более узкая полоса как при Rx/Tx даст большую дальность связи. Но при повышении скорости будет расширяться и полоса и по сути это вид AM, который проигрывает по RF энергетики. Его используют в этих трансиверах из-за трудностей простых решений в этих трансиверах для частотных/фазовых модуляций/манипуляций в узких полосах.


это так, делал тоже такое раньше по началу. Но помехи разные есть, не поможет с относительно небольшой но широкополосной помехой.

Добрый день, Александр!
В принципе я жестко к радио не привязан, но хотелось бы чтобы оно было не очень дорогое.
Я так понимаю для более узкой полосы предпочтительнее использовать что-то типа CC1020?
Если Вас это не сильно затруднит, то мне было бы очень интересно узнать как это делается, понять принципы.


Ну я так понимаю что кроме уменьшения полосы тут еще важный момент это довольно узкие входные полосовые фильтры для устранения помех и применение более точных кварцевых резонаторов-генераторов?

Более точные кварцы конечно нужны, хотя полоса захвата и так широкая. Но не сильно вдоховляйтесь этими чипами 220 стандарта. Поскольку полосовые фильтры как Rx/Tx-а дохленькие, около 30dB всего. Примерно с таким подавлением и зеркалка прёт, так что, не ахти что имеем. Так для баловства какой-нибудь бакалаврской работы средненького университета в штатах теперь. Некоторые умудряются пав фильтрами немного выиграть по шумам.
Все же посмотрите на чипы у силабса, они получше будут чем рфм, тексас.

А что подразумевается под чипами 220 стандарта?
Дело в том что чипы от тексас и рфм более массовые и потому более дешевые и легче доставаемые.
Я не крупная фирма, которая может заказать любые чипы из китая тысячами штук, я покупаю их единицами шт, потому для меня важно чтобы они были в наличии у продавцов в Украине и цена была не сильно кусючая.

Я думал что вы в курсе стандартов, это EN-300220 (Europe). Силабс без проблем доставаем, массовый и такой же дешевый.

И еще работая с OOK, минуя внутренний демодулятор, выигрыш может быть около 5...6dB ( и поболее с кодами), за счет собственного декодера и обработчика. Из-за этого преимущества, видимо, Александр предложил вам этот режим. Но это требует шустрого процессора и проигрывает всёже по потреблению.

Да, я тут посчитал - скорее всего игра не стоит свеч. Или скорость получится очень низкая или процессор нужен будет более мощный.

я действительно не в курсе этих стандартов, обязательно ознакомлюсь. спасибо!


Александр, а насколько низкая скорость будет?
Если можно, расскажите хоть в двух словах как это все реализуется или ткните меня носом где можно про это почитать (желательно бы на русском языке, лучше доходит до меня).

Все-таки мне желательно в данный момент все это запустить на trc102 либо cc1100(на этой микросхеме у меня собрана охранная система, которую я хочу довести до ума).

... собрана охранная система...
Так у вас есть еще усилитель для Tx?

нет, у меня стандартная обвязка у CC1100 из даташита. Дальность мне в принципе сильно большая тут не нужна, однако я ее планирую расширить за счет той самой маршрутизации.
TRC102 меня интересует с точки зрения стоимости, простоты и удобства монтажа.

В данный момент мне все это нужно запустить на TRC102, это первостепенная задача. Просто есть железо, которое нужно запустить.
А все остальные решения это уже развитие дальнейшее этого железа, модернизация.

Основная идея такая (самый простой вариант):
1. заменяем каждый бит на последовательность бит, обладающую АКФ приближающейся к дельта-функции, то-есть АКФ в 0 равна 1 и как можно ближе к нулю во всех остальных точках. Таким свойством обладают коды Баркера и М-последовательности, например. Пример М-последовательности длинны 15: {0, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1}.
2. Заменяем 0 на прямую последовательность, 1 - на инвертированную. Ест вариант использовать две разных последовательности для 0 и 1.
2. На приеме оцифровываем принятый сигнал с частотой дискретизации в несколько раз больше, чем битовая скорость (4-8 раз).
3. Проводим согласованную фильтрацию на оцифрованного сигнала. В качестве коэффициентов фильтра берем исходную М-последовательность развернутую задом на перед.
4. Там где входной сигнал совпадет с последовательностью на выходе фильтра будет пик, знак пика покажет 0 или 1 приняли.
5. Далее из последовательности битов нужно обратно собрать байты.

3 этап вычислительно самый сложный, так как на каждый принятый отсчет для длинны М-последовательности 16 и 4-х отсчетов на бит нужно проделать 4*15=60 операций MAC (умножение + сложение). На самом деле умножать придется на 1 и -1, так что умножать ничего не нужно, но все-равно, даже просто 60 сложений - это уже довольно много для простого МК.

Выигрыш тут происходит из-за увеличения времени передачи бита, игры с М-последовательностями нужны для синхронизации.

Описание довольно корявое, но в целом нужно смотреть в сторону описания М-последовательностей, их АКФ и согласованной фильтрации.

Все это не применимо к TRC102, так как оно не умеет передавать OOK сигнал.

Александр, спасибо за описание!
Тут мне сначала нужно еще довольно неплохо теорию по цифровой обработке и математике подтянуть чтобы понять получше это все. Займусь этим.
Но вообще алгоритм получается довольно непростой. Я правильно понял что использование подобного алгоритма мне даст возможность вычислять LQI а также немного улучшит качественные показатели радиоканала, помогут повысить дальность?
Получается я действительно наверное ничего не выиграю, т.к. придется ставить контроллер явно помощнее, следовательно как минимум цена устройства возрастет.
Но вообще интересно будет разобраться получше с тем алгоритмом что Вы описали, уверен что многое для себя почерпну.



А вообще ведь я изначально делал максимально простой радиоканал , потом решил добавить маршрутизацию-ретрансляцию и пошло-поехало , в итоге я уже и забыл с чего начинал и какая у меня цель была.
Попробую как-то попроще слепить из RSSI+кол-во хопов какое-то подобие LQI, наверное это будет более простое решение для меня.

LQI вычисляется исходя из уровня пиков в отношении к уровню шума, грубо говоря он показывает насколько принятый сигнал отличается от идеального с которым сравнивает фильтр. При желании так можно вычислять средний LQI всех бит, IEEE 802.15.4 радио делают это только для преамбулы, но там и модуляции другие используют.

Да, это скорее всего просто поиграться с математикой, если интересно, на практике проще купить радио немного дороже, но которое все это само сделает в железе.

а сколько градаций у LQI? Я вроде бы помню что Вы где-то писали что 0 и 1. Или это я что-то перепутал....
Просто у меня ж уровень шума средний и так замеряется постоянно когда я в RX, и когда я принимаю пакет, то я ж могу замерить уровень несущей, в итоге вычислить соотношение....а дальше я так понимаю эксперименты и эксперименты чтобы понять насколько минимально уровень несущей должен быть больше уровня шума чтобы получить нормальные условия связи.



я бы с удовольствием поигрался с математикой и поразбирался с этим, но, к сожалению, времени и так катастрофически не хватает...
Попробую все-таки как-то сделать какое-то подобие LQI на этом железе, а потом когда-нибуть, если будет возможность, куплю несколько чипов заточенных под zigbee, тогда уже попробую как на них все будет работать чтобы сравнить.

256 обычно, потом для удобства вычислений они масштабируются в диапазон 0-1.

LQI - это не соотношение уровней, это показатель того сколько отсчетов в принятом сигнале совпали с тем, что мы ожидали, при условии, что совпало достаточно много, чтобы принятый бит был засчитан.

Самый хороший вариант - не измерять уровень шума совсем, а масштабировать входной сигнал (используя АРУ) к уровню -1 -- 1. Тогда абсолютный максимальны уровень пика для прошлого примера будет равен 60 - это произойдет только если все отсчеты совпали идеально, то-есть шума в канале нет вообще, то-есть LQI максимален.

вот теперь я наконец-то наверное понял почему нужна AM модуляция...чтобы мы не уровни несущей меряли а именно информационную наполненность так сказать правильными данными - чтобы мы считали пришедшие импульсы, просчитывали ожидаемое значение и сверяли.
Я правильно понял?


Т.е. получается потом по каким-то критериям считаем устраивает ли нас канал связи или нет и выбираем 0(нет связи) и 1(есть связь).


вот тут сходу не понял алгоритма, надо посидеть обдумать.

Типа того. Любая модуляция подойдет, AM просто проще всего демодулировать.

Фильтр - это шаблон того, что мы ожидаем увидеть, при фильтрации мы двигаем этот шаблон вдоль принятого сигнала и проверяем сколько бит совпало. Если совпало достаточно, то мы считаем бит принятым. Трюк заключается в использовании М-последовательностей, которые дают только один пик, кода совпадение точное и уровень боковых лепестков примерно 1/sqrt(N), где N - длинна последовательности.

Я вот подумал а что если ввести в данные избыточность+увеличить скорость, чтобы даже при условии небольших помех более успешно восстанавливать данные.


Я просто никогда не сталкивался с цифровой фильтрацией, потому не знал как она работает а в итоге получилось что я и не мог понять самый мысли как же посчитать сколько совпало данных а сколько нет. Теперь мне становиться понятно.

Нет, это не обязательно целые числа, это могут быть и дроби. Смысл в том, что бы привести LQI к вероятности передачи кадра без потери. А все вероятности в диапазоне от нуля до единицы.

Хранить естественно как float их не обязательно, можно (и даже нужно) как fixed point.

Тоже вариант. Только скорость увеличивать не нужно, если есть возможность.

понял. Спасибо за доходчивые объяснения!
у меня есть вопрос который меня все мучает и на который я не придумал ответа - как быть в ситуации когда например при поиске маршрута маршрут вычисляется, вроде между всеми узлами маршрута качество нормальное, однако через некоторое время, когда собственно бегают пакеты, между узлами возникло временное препятствие(прошел человек, пролетела помеха и т.п.), качество связи временно ухудшилось в результате чего пакеты потерялись. И получается что вроде как и маршрут нормальный и проблемы на его пути периодически возникают. Накапливать статистику по качеству сигналов между узлами?
Ведь та же вероятность при просчете маршрута не учтет этого никак в случае если помеха не побьет биты пакета routeDiscoveryRequest-routeDiscoveryReply.

Повторять передачу и уменьшать счетчик в таблице маршрутизации. Если счетчик достиг нуля, то убирать запись и заново искать маршрут. Если препятствия частые, то есть шанс, что оно будет там при поиске и найдется более хороший маршрут. Других вариантов нет, если не хочется копить статистику и учитывать ее при поиске.