Собственно стартовый вопрос в заголовке. По причине ЯВНОЙ декларации производителем наличия у чипа JN516x аппаратной поддержки измерения времени задержки распространения сигнала, заинтересовался именно им. Убивает, коенечно, полное отсутствие документации на железо - вот вам API, на непонятных условиях еще может дадим дополнительные либы, так и живите. Но у конкурентов не лучше особо . В общем буду с ним копаться по любому. Сейчас заказал Evolution Kit.
Интересует прежде всего его минимально доступный уровень API, то есть IEEE 802.15.4. Всякие прочие Jennet примочки и ZigBee, это уже для меня дело далеко не первое. Но может тоже когда пригодятся.

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

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

Ну вот, получил в понедельник кит. Кит с моргалками-перделкам, конечно, убивает . Дается ясно понять, что основная напраленость JN5168 на на некие поделки типа закосов под "умный дом". Как следствие, для работы с чипом только API, а все остальное только полулегально (кое-что в хидерах недокоументрованно встречается) и нелегально-хакерски .
Поддержки от производителя - РОВНО НОЛЬ. На письма не отвечают категорически, на официальном!!! форуме так-же НАЧИСТО отсутствуют ответы представителей NXP.
Я думал что хоть с китом, как бывает, придет волшебный код регистрации для дополнительной информации, но фиг.
Куда, блин, все катится???
Я, конечно, уже печенкой почти все и без всякой "поддержки", чую что и как, и лабораторно проверить могу, посему и так уже без одной, но ключевой фичи запустил то, что нужно.
Сейчас уже гоняются тесты на живость и вшивость.

А ключевая для меня фича это Time-of-Flight. По ней для JN516x НИЧЕГО не получить вообще. Я уже в пятницу со штатовского корпоративного адреса письмо послал, но пока, как и ранее, только ответ робота.

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

А с поддержкой только у TI все более или менее хорошо.

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

Да я и на NXP до сих пор совсем не жаловался. Тут дело видимо больше в том, что это все-же Jennic, а не нативный NXP.

Я пошёл немного другим, дешевым путём и заказал на Али китайские модули ZM5168P0. Оформил запрос, прислали ПО и либы. Буду разбираться. Надеюсь на сотрудничество и помощь, т.к. в программировании ARM, да и вцелом в программировании начинаю переходить от азов...

Ну по дешевизне не особо понятно, в чем особая дешевизна, ибо "родные" модули стоят только порядка на евро дешевле, да и то не всегда.
Но тем неменее ОЧЕНЬ интересно. Интересна как совместмость, ибо есть свои китайцы в Китае и соответственно по ценам внутреннего рынка получать можно.

Списочек присланного? Интересует и ОЧЕНЬ интересует одна единственая либа:
Time-of-Flight API Software Libraries V2.0

ПОСМОТРИТЕ ПОЖАЛУЙСТА!!!


В этом направлении всегда пожалуйста.

Да в этом случае там вообще ARM и не пахнет - он глубоко зарыт и доступно только API . Так-что имеем вполне абстрактное программирование на 'C'. Уровень IEEE802.15.4 на даный момент насиловал, как только мог. Явных ляпов и глюков не обнаружил.
Что несколько смирило с закрытостью чипа. Осталось раздобыть помянутую выше либу. Переписка c NXP идет в темпе одно письмо в месяц . У китайцев она ТОЧНО есть, но пока удалсь только фуфло ввиде старой версии не поддерживающей 5168 у них раздобыть.

P.S.
Посмотрел на китайский модуль. Полной заявленной совместимости с оригинальным нет , но вроде частично совпадения есть и футпринт достаточно совпадает.

На сайте, вроде как производителя, http://www.zlg.cn/Wireless/zigbee_en.php никакого софта для разработки не нашел. Посему большай просьба к Paul6923 отписаться, что дали ему.

Тем, что прислано я вас врядли удевлю.

Thank you for your request, if you wish to use the new BeyondStudio for NXP Toolchain please click on the following link to download the toolchain JN-SW-4141 and one of the following links to download your preferred Networking stack compatible with BeyondStudio:

· JN-SW-4163 JN516x IEEE802.15.4 SDK

· JN-SW-4165 JenNet-IP SDK

· JN-SW-4168 JN516x ZigBee Home Automation and Light-Link SDK (coming soon)

Detailed SDK Installation instructions can be found in the JN-UG-3098 BeyondStudio for NXP Installation and User Guide

If you wish to use the original toolchain please click on the following link to download the toolchain JN-SW-4041 and one of the following links to download your preferred Networking stack:

· JN-SW-4060 JN516x ZigBee RF4CE SDK

· JN-SW-4062 JN516x ZigBee Light-Link SDK

· JN-SW-4063 JN516x IEEE802.15.4 SDK

· JN-SW-4064 JN516x ZigBee Smart Energy SDK

· JN-SW-4065 JenNet-IP SDK

· JN-SW-4067 ZigBee Home Automation SDK


А по поводу вашего поиска Time-of-Flight API Software Libraries V2.0 :

http://en.pudn.com/downloads632/doc/detail2564970_en.html#

Согласно JN-RN-0026-Time-of-Flight-API: V2.0 подходит и к 5148 и 516x (Time-of-Flight API Software Libraries (JN-SW-4043) v2.0
Important Notes Before installing this release, the latest versions of the JN51xx SDK Toolchain (JN-SW-4041) and JN5148 or JN516x SDK Libraries (JN-SW-4040 or JN-SW-4065) must already be installed. )

Вот:

Это точно

Вы ОЧЕНЬ мне помогли! Я забрал архив с таким названием на другом программерском китайском сайте, но он был обманкой - вутри верcия 1.1
Я на pudn уже и не полез, тем более моя старая регистрация там то-ли накрылась, то-ли я проль забыл. Често говоря решил упереться и добить NXP официально.
Тем более, что эта либа официально под их старый компилятор, хотя под новый тоже можно попробовать подтянуть.
Спасибо! Завтра на свежую голову буду пробовать прикрутить.

Получится-отпишитесь.

Я планирую использовать zigbee для разработки сенсорной сети специального назначения. Займусь этим через месяц-полтора. Так что контакт специалиста мне бы не помешал. Спасибо.

Обязательно!

Я, увы, не собираюсь использовать именно прилагаемый zigbee стек. Основная задача была обойти по максимуму даже приблуды даже нижнего ( IEEE802.15.4 ) уровня. Что удалось и надстроен свой стек. Но вообще совместимость с минимальнейшими ограничениями сохранена, так-что можно при возникновении необходимости поднимать параллельно и zigbee для чужих и WPAN в перспективе для себя

Чем смогу - помогу!

Смеяться или плакать даже не знаю. Начал прикручивать полученные библиотеки, а они уже были в последнем комплекте "4041" взятом c сайта. Хотя по всем документам быть их там не должно. Вот дурь, и главное ни одна зараза из "техподдержки" нифига не могла сказать, что я дурак и они там есть. Надо будет глянуть, может они и под свежий компилятор так-же молча лежат.
В общем закинул в тестовый проект несколько базовых вызовов - отрабатывают как-то. Продолжаю.

Всякое бывает Обидно, что производитель не контактирует с разработчиком.

Подскажите, пожалуйста, мне как чайнику. Учитывая что имеются только API. Я могу корректировать порядок маршрутизации, например сделать MESH-сеть из одних только маршрутизаторов, периодически засыпающих, например по аналогии как сделано в Xbee с их Digi-MESH? На сколько глубоко можно управлять МК, если он как Вы говорите на столько "закрыт" (имеются только API)? Спасибо.

Не знаю, не разбирался. Меня данная реализация ZigBee не интересует и не скоро будет, если будет.

Да, имеется только API. Оно более-менее описано. Причем максимально нижний уровень API это IEE802.15.4 Остальные уровни можно не использовать и строить свое. Я, например, и не собираюсь, поскольку ZigBee, как таковой, не пригоден мне, как класс. К ZigBee вообще-то термин Mesh притянут за уши. Это что-то в чем-то похожее на mesh и не более . Переодически засыпающие очевидно можно сделать, также очевидно, что скорость упадет катастрофически, или спать они почти не будут.
API надо вычитывать и думать, пробовать, как использовать альтернативно.

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

Измерение чисто по RSSI или дополнено еще чем?

Разумеется интересен не RSSI, который тоже есть. Основное это результат измерения задержки в пикосекундах.

За счет измерения сдвига фазы модулирующего сигнала в каком то пакете?

Типа да. Пакеты специальные.

В OQPSK это проще сделать чем на разных FSK. Разброс показаний до двух метров на каком расстоянии?

Не проще, а только на на подобных и возможно.

На рассточниях начиная с пары десятков метров на открытом пространстве.
Но это именно разброс(дребезг) а не точность. И два метра это уже после некоторой обработки пачки измерений.

Я к тому, что в OQPSK есть возможность двигать фазу в широком пределе без ущерба при передач данных, то чего нет у разных FSK. К тому же переход фазы через ноль (где скорость точки максимальная) не даст значительной джитторной ошибки в OQPSK, в отличие от других видов модуляций.
На разброс влияет много факторов, начиная с джиттера генератора, фапча, ... + конечно антенна, ее поляризация, земля, переотражения, зоны френеля и еще кучка разной физики таких как дифракция, интерференция и тд. Некая обработка должна быть это понятно, хотябы тот же калман двумерный или что-нить аналогичное. Интересно конечно посмотреть, что они там за паткеты шлют и понять принцип их измерений. Но разброс два метра на двадцати с обработкой кажется много. Думаю, что мат обработка сигналов RSSI, LQI может такое давать тоже для этого диапазона.

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

А это фиг . Тот-же RSSI, конечно стоит практически на удивление мертво, но сие работает ТОЛЬКО в открытом пространстве и прямой видимости. Изменять по RSSI дистанцию до устройства лежащего в кармане или вообще где попало, движущегося человка это ни в какие ворота.





Начал просматривать информацию по этим модулям. Документация в лучших китайских традициях .
Совместмость с NXP модулями как-бы декларируется. Физически - совпадает достаточно точно. Но дальше начинается...
1) Пины в большинстве своем названы по своему и как-бы перенумерованы.
2) Часть пинов не выведена
3) И самое страшное - есть несколько документов по которым количесво неподключенных пинов отличается (речь не о пинах управления усилителем и антеннами )
Схем модуля не нашлось. Схемы демоборды - тоже.

В комплекте с купленными Вами модулями не было документации, кроме той (футпринты и мануал ни о чем ), что на сайте?
Мне требуется достаточно большое количество интерфейсов, посему проблема нарваться на неподключенный пин и НЕ обеспечить реалную совместммость в конкретном изделии, для меня острая .

Ну эти банальности для студентов про открытое пространство. Есть же реальные пере-отражения в этом диапазоне, как в солнечную погоду, зайчики от проезжающих машин, окон домов. А за поляризацией вы никак не следите. Так что не есть фиг. И ворота у того же RSSI там нормальные. В отличие от измерения временных интервалов от тысяч трасс, и затем их усреднение - это ни в какие ворота. Просто с этим работал, и опыт имеется. Все измерения времени, усреднения без учета, той же 3D диаграммы направленности антенны - не дадут вам понятного результата. Атмел со соим модулем TOM в чипе at86rf233 так и застрял.

Что не поняли? То, что любые изменения в ближней зоне антенны, а устройство, повторяю, носимое, гробят все попытки извлечь информацию из RSSI. Ну и дискретность RSSI в 1dB уже не дает никакой точности после десяков метров, даже если про уровень шумов забыть А мне нужны дистанции и под 300 метров. RSSI уже пройденный этап.

Про "усереднение" не надо - я ведь не пионер пишущий "демку" .

P.S.
Глянул крайний копмилятор, для которго TOF либа и не обещалась. Оказалось, что ТОЖЕ есть в комплекте. Так-что я сразу перешел на свежачек. Мой стартовый учебный проектик похудел с 55 до 47 килобайт на новом компиляторе.

На борту полноценный JN5168. Лично под лупой просмотрел - все выведено! (там, где в доках написано NC - это только для их, китайских, приложений). Для меня главное, чтобы ВЧ-часть была разведена, ну и еще раз повторюсь, что все функциональные контакты выведены (питание и радио уже разведено).
Так то модули абсолютно идентичны.

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

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

Поведайте, какие такие зменения в ближней зоне антенны гробят все попытки извлечь информацию из RSSI. Если это человек, животрое, то почти ничего не меняется. Теряется процент мощности или меньше. Другое дело поворот атненны, её поляризация. Измеряемый уровень RSSI более 100dB, масштабировать 1dB не проблема, и тем более на 10 метрах потерять 1dB это надо очень умудриться. Причем тут уровень шумов, этот диапазон чист. Это вам не короткие или длинные долны. Возможно вы просто не разобрались, что RSSI это только часть инфы для обработки при измерении для ваших дистанций.

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

P.S. Да, было бы интересно посмотреть на ваше железо.

Завтра сделаю фото. Доберетсь до дома - сравните.

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

Ок. Да я сомневаюсь, что они принципиально отличаются. Разве что позиционированием элементов.

Вопрос наверное глупый... Как вы прошивку заливаете? Через bootloader + usb-uart свисток получится? И необходимо ли для начала докупить jtag-отладчик?

И какой Toolchain лучше использовать: BeyondStudio for NXP или Original?

Да, через встроеный загрузчик. Через просто USB-RS232 не получится, ибо нужны уровни 3,3V, а не уровни RS232. Так-что нужен кабелек типа http://www.tme.eu/en/Document/d35506873b14...232R_CABLES.pdf - ТЕХВОЛЬТОВЫЙ!!! вариант

Для заливки - нет. Для "отладки"??? Я лично пользуюсь в исключительнейших случаях (уже лет 8 не пользовался ), хотя практически для всех контроллеров покупаю, именно для исключительных случаев, что-бы было.

Что такое "оригинал"? Старый, очевидно? Тогда использовать ТОЛЬКО новый, который BeyondStudio - он собственно текущий от производителя ядра контрллера BA22 с прибамбасами для RF интерфейса. Там в комплекте, не знаю зачем, два гнусных компилятора - 4.7.3 и 4.7.4
Я, естественно, начал использовать 4.7.4
Какой в оболочке используется я не знаю, по причине нахренненужности мне всяких IDE слепленных производителем. Брал только компилятор.

Спасибо.

Однако,

Свисток http://ru.aliexpress.com/item/1pc-lot-USB-...627657.html?s=p
Поддерживает 3,3V.

Я бы не искал приключений. Там, судя по цене, очень реален какой-нибудь экстремальный китайский чип типа ark-а в комплекте с дикими дравверами под win98 да и то не рабочими. Разборки "кто виноват" будут дороже

CH340. Уже испробован. Положительно. Аналог FT232.

Впрочем это не тема обсуждения.

Тестил JN5168 TOF API. от результата в помещении не в восторге.
Файлы года два назад получил через техподдержку (ито через т.п. Arrow).
Архив прикрепляю.

P.S. поддержки ноль. документация хоть и объемная, но и от нее не в восторге. В итоге использую TI для подобных прменений.

А что собственно ожидалось в условиях гарантированных можественых отражений?
В полевых условиях, над поверзностью заросшей высокой травой результаты измерения расстояния БЕЗ всякой обработки вполне достойные. Для условий отражений - надо обрабатывать измереия, причем измерять с обоих строн. Результат меня пока устраивает.

Спасибо! Но как оказалось (уже писал) они сейчас все эти волшебные либы просто МОЛЧА кидают в комплект поставки компилятора но продолают посылать к дилерам. Дилеры в свою очередь шизеют. Так-что самые свежие либы просто в комплекте лежат.

А вот с этого места поподробнее, пожалуйста! Какой именно из TI?
У меня нет никаких преференций к Jennic. Скорее наоборот. Просто при поиске ничего вменяемого у TI не нашел. Прошляпил?
И каким образом тому-же TI или Вам? удается обмануть физику, если говорить о работе в помещении.

По крупному все, что хотел сделал.
Начал озадачиваться загрузчиками и иже с ними. Как вариант собрался было посмотреть, что там Jennic наворотил из инструментария. Есть такой Jennic Encryption Tool (JET) JN-SW-4052-JET.zip
Но этот уже точно по запросу. Что-то мне после передыдущй переписки энтузиазма совсем нет. Может у кого-то есть этот архивчик?

zltigo, а каких результатов удалось добиться?

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



А все много проще. Вместо того чтобы измерять время распространения сигнала + RSSI стали мерять RSSI+ускорение. А раз рекурентная фильтрация все равно предполагалась, то потеря не велика. Аппаратно я тоже не видел у TI реализованными функций измерения времени распространения. чип поставили CC2530.

А вообще 0.3...0.5 метра точность более чем достижима на расстоянии до 20 метров. Что устроило.

А они оказываются коррелируемы и очень даже сильно. До 20 метров это без преград ввиде ж/б стенок на трассе, ... мало кому нужно. Всем нужно в ж/б здании с кучей комнат и до 500 метров. Думаю не понимаете, что излучение от антенн и тот же RSSI, TOF зависят от обоих антенных диаграмм, поляризации и еще кучки физ. процессов распространения эм волны выбранной длины.

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


Понятно. А то я уж подумал, что прошляпил .

Это для меня совершенно НЕ то. И растояния больше и антенны не на открытом пространстве и не в фиксированном окружении. Так-что RSSI идет лесом сразу. Хотя, уже писал, в тепличных условиях на расстояниях метров до 50 Jennic работает на удивление стабильно.

Ну что-то новенькое у Вас есть по этим модулям? Я запустил первую установочную серию изделия на "родном" модуле. Так-что теперь можно пробовать и на альтернативных для сравнения. Буквально сегодня закажу, тем более, что китайский коллега вчера в гости приехал.

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

Извините за офтоп, но вы судя по всему неплохо разобрались в их SDK, вам удалось с их компилтором использовать функкции lib.c,
чтобы при компиляции не возникали подобные ошибки
/ba_toolchain/r36379/source/gcc-4.7.4-ba-r36379-build/ba-elf/mcpu_jn51xx_sizeopt/newlib/libc/sys/basim/../../../../../../../gcc-4.7.4-ba-r36379/newlib/libc/sys/basim/glue.c:75: undefined reference to `end'
/ba_toolchain/r36379/source/gcc-4.7.4-ba-r36379-build/ba-elf/mcpu_jn51xx_sizeopt/newlib/libc/sys/basim/../../../../../../../gcc-4.7.4-ba-r36379/newlib/libc/sys/basim/glue.c:75: undefined reference to `_stack'
/ba_toolchain/r36379/source/gcc-4.7.4-ba-r36379-build/ba-elf/mcpu_jn51xx_sizeopt/newlib/libc/sys/basim/../../../../../../../gcc-4.7.4-ba-r36379/newlib/libc/sys/basim/glue.c:75: undefined reference to `_stack'
/ba_toolchain/r36379/source/gcc-4.7.4-ba-r36379-build/ba-elf/mcpu_jn51xx_sizeopt/newlib/libc/sys/basim/../../../../../../../gcc-4.7.4-ba-r36379/newlib/libc/sys/basim/glue.c:75:(.text+0x197): relocation truncated to fit: R_BA_8 against undefined symbol `_stack'

Ну написали-бы, какую функцию хотели использовать. Предположил, что что-то типа printf() и прочие malloc(), ибо, как правило, хипы в микроконтроллерных либах не поддерживают. И таки да. Значит в либе так доступ к heap хотят получить. Посмотрел, что там наоротили в "фирменных" гнусных скриптах линкера. Heap в принципе заложен. Надо в App_Stack_Size.ld добавить строчку
_minimum_heap_size=Желаемый_размер;
Для обеспечения гарантированного минимума. Дальше веселее.
Библиотеки не пользуются скриптовыми _heap_start и _heap_end - банальная халтура неудосужившихся.
Посему надо в скрипт AppBuildEnd_JN5168 добавить две строчки:
end = . ; (типа конец BSS) перед .heap


и _stack = . ; после .stack (начало STACK)


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


А что Вы делаете на этом чипе?

Спасибо большое за совет. Да вы угадали, нужен был malloc чтобы не перепрошивать gateway всякий раз когда хочешь поменять размер буффера комманд. Можно было, наверное, и свою кучу написать, но раз была анонсирована производителем поддержка libc то решил, что лучше этого не делать.

Делаю систему управления освещением.