Comments 3
Конечно, TCP/IP на BASIC не напишешь— никто не хочет «Challenge Accepted»? :)
Прототип был собран только для проверки качества связи при изменении параметров радиоканала, поэтому на нём нет никаких интерфейсных разъёмов для подключения каких-либо датчиков или других внешних устройств.
Очень жаль, что нет интерфейсов. Сейчас нужны девайсы, на базе которых можно организовать mesh-сеть: соединить соседей на лестничной площадке, или замутить локальную сеть в частных домах. Поверх такой сети смогла бы например работать моя Пандора.
TCP не обязательно, хотя бы сделать примитивный API для отправки и приёма небольших пакетов (<10Kb). Идентификация узла пусть будет случайная, или жёстко прописана на железке (что-то типа MAC-адреса). Пакеты пусть расходятся мультикастом от одного всем его соседям, кто в зоне видимости (а они дальше передают).
Чтоб пакеты по кругу не гоняли, запоминать маркер пакета (содержит ID отправителя, время создания и хэш пакета), хранить где-то в буфере список этих маркеров 1 минуту. Отбрасывать, если маркер пакета есть в буфере, или если пакет старше 1 минуты. Другой способ: прикреплять в конце пакета ID узла, так будет копиться список ID, чтобы этим узлам пакет снова не отправляли. При получении пакета первым делом заглядывать в этот список: если есть свой ID, то отбросить пакет, если ID соседа, то ему не отправлять. Но так пакеты могут сильно раздуваться. Чтобы пакеты не раздувались, хранить номер передачи, увеличивать его на +1 при каждой передаче. Если число передач больше 30, то отбрасывать пакет.
Ну и понятно, пакеты брать с интерфейса и класть туда же.
Разумеется, интерфейсы в реальности нужны. Идея сделать полновесный модуль (-и) есть. Однако нужно бы и финансирование где-то найти. Уж больно дорогостоящие приборы нужны для отладки радиотракта. Уже проходил и знаю, что без приборов лучше не соваться.
Одной из целей публикации было пощупать, а есть ли интерес.
Соображения по маркировке очень интересны. Только как бы не заняться изобретением велосипеда в 100-й раз…
В том неудачном проекте как раз элементы TCP хотели применить, т.е. в пакет включается байт счётчика. Если число узлов превышает заданное N, то пакет уничтожается. В этом случае не нужен никакой буфер, где хранится информация о переданных пакетах. Даже если пакет заблудился и гуляет по кругу, то также ничего страшного не произойдёт. А навешивать ID в конце пакета — это путь к пакету переменной длины. Тогда можно забыть о FEC.
Одной из целей публикации было пощупать, а есть ли интерес.
Соображения по маркировке очень интересны. Только как бы не заняться изобретением велосипеда в 100-й раз…
В том неудачном проекте как раз элементы TCP хотели применить, т.е. в пакет включается байт счётчика. Если число узлов превышает заданное N, то пакет уничтожается. В этом случае не нужен никакой буфер, где хранится информация о переданных пакетах. Даже если пакет заблудился и гуляет по кругу, то также ничего страшного не произойдёт. А навешивать ID в конце пакета — это путь к пакету переменной длины. Тогда можно забыть о FEC.
Sign up to leave a comment.
СС1101 под управлением PIC-контроллера или построение одноранговой сети для радиоинженера