Почему пакеты данных отсутствуют в настройке Zigbee arduino?

Я сделал настройку, состоящую из 3 Zigbee, 2 маршрутизаторов (Zigbee S2C) и 1 координатора (Zigbee S2). Каждый маршрутизатор подключен к arduino nano, который собирает данные с 2 FSR и IMU (тип кадра: запрос на передачу zigbee и размер пакета 46 байт) и отправляет их координатору, подключенному к arduino UNO. Все Xbee находятся в режиме API 2 и работают со скоростью 115200 бод. Я использую библиотеку под названием «Простая библиотека Zigbee» для отправки всех собранных данных координатору. Сбор и отправка данных работает нормально, за исключением того, что в пути теряются пакеты. Выборочные данные nano на частоте около 25 Гц независимо друг от друга. Координатор пытается прочитать данные, отправленные с zigbees (конечно, используя библиотеку) в каждом цикле, но, к сожалению, он получает только около 40-45 выборок (должно было быть 25 * 2 = 50 всего выборок из 2). хби). Кто-нибудь может подсказать, почему это происходит. Мне нужно как можно меньше потерь данных, чтобы моя установка достигла своей цели. Любая помощь приветствуется.

P.S: Может быть важно отметить, что координатор считывает данные только с одного xbee в каждом цикле.

Как видно из заголовка "Источник" этого изображения данных, полученных координатором, «19» и «106» — это адреса маршрутизаторов, и пакеты данных периодически отбрасываются

Спасибо.

void setup()
{
    // Start the serial ports ...
    Serial.begin( 115200 );
    while( !Serial ){;}  // Wait for serial port (for Leonardo only).
    xbeeSerial.begin( 115200 );
    // ... and set the serial port for the XBee radio.
    xbee.setSerial( xbeeSerial );
    // Set a non-zero frame id to receive Status packets.
    xbee.setAcknowledgement(true);
}
void loop()
{
    // While data is waiting in the XBee serial port ...
    while( xbee.available() )
    {
        // ... read the data.
        xbee.read();
        // If a complete message is available, display the contents
        if( xbee.isComplete() ){
            Serial.print("\nIncoming Message: ");
            printPacket( xbee.getIncomingPacketObject() );
        }
    }
    delay(10); // Small delay for stability
    // That's it! The coordinator is ready to go.
}
// Function for printing the complete contents of a packet //
void printPacket(SimpleZigBeePacket & p)
{
    //Serial.print( START, HEX );
    //Serial.print(' ');
    //Serial.print( p.getLengthMSB(), HEX );
    //Serial.print(' ');
    //Serial.print( p.getLengthLSB(), HEX );
    //Serial.print(' ');
    // Frame Type and Frame ID are stored in Frame Data
    uint8_t checksum = 0;
    for( int i=10; i<p.getFrameLength(); i++){
        Serial.print( p.getFrameData(i), HEX );
        Serial.print(' ');
        checksum += p.getFrameData(i);
    }
    // Calculate checksum based on summation of frame bytes
    checksum = 0xff - checksum;
    Serial.print(checksum, HEX );
    Serial.println();
}

person Aniket    schedule 19.02.2017    source источник
comment
учитывали ли вы коллизию пакетов и повреждение данных? Достаточно ли развит протокол связи, чтобы справиться с такими ситуациями?   -  person Patrick Trentin    schedule 19.02.2017
comment
Эта ссылка говорит, что: радио, используемое этими модулями (уровень MAC и PHY), определяется стандартом IEEE 802.15.4, который определяет использование множественного доступа с контролем несущей с предотвращением коллизий или сокращенно CSMA/CA.electronics.stackexchange.com/questions/36932 /   -  person Aniket    schedule 19.02.2017
comment
Отлично, но я имел в виду что-то более высокого уровня, чем это. CSMA/CA может и определенно не сможет предотвратить коллизии при правильных обстоятельствах, хотя определенно лучше иметь его, чем не иметь. Протокол более высокого уровня должен требовать, чтобы каждый пакет был подтвержден, и принудительно отправлять пакет повторно, если ACK не получен в течение заданного < я>время ожидания. В прошлый раз, когда я работал с ZigBee, хотя я признаю, что не использовал Arduino, мне пришлось реализовать это самому.   -  person Patrick Trentin    schedule 19.02.2017
comment
Спасибо за быстрый ответ @PatrickTrentin. Я использую Xbees в режиме API, и пакеты данных подтверждаются, как вы описали. Библиотека, которую я использую (простая библиотека Zigbee), делает всю тяжелую работу за меня. Кроме того, мой фактический код работает со скоростью 115200 бод, а не 9600 бод, как показано в примере.   -  person Aniket    schedule 20.02.2017
comment
Это приятно знать, спасибо   -  person Patrick Trentin    schedule 20.02.2017
comment
Сказав это, есть ли что-то, что мне нужно изменить, чтобы получить данные более надежно?   -  person Aniket    schedule 20.02.2017


Ответы (2)


Хотя вы утверждаете, что используете скорость 115 200 бит/с, опубликованный код показывает, что вы открываете последовательные порты на скорости 9600 бод, что определенно недостаточно для скорости 2500 байт/сек (50 пакетов/сек * 45 байт/пакет * 110% накладных расходов), полученных от XBee и сбросил printPacket()). Помните, что скорость передачи данных 802.15.4 всегда составляет 250 кбит/с, а конфигурация последовательного порта модуля XBee предназначена только для локальной связи с хостом.

Убедитесь, что ваши маршрутизаторы отправляют одноадресные (а не широковещательные) пакеты, чтобы уменьшить радиотрафик.

Вы должны убедиться, что отправка работает, прежде чем устранять неполадки кода на координаторе. Обновите код на своих маршрутизаторах, чтобы увидеть, получаете ли вы успешный пакет состояния передачи для каждого отправленного пакета. Стремление к 50 Гц кажется слишком большим — вы пытаетесь отправить 45 байт (это полный размер кадра API?) каждые 20 мс.

Используете ли вы аппаратный последовательный порт на Arduino как для модуля XBee, так и для Serial.print()? Сколько времени занимает каждый вызов printPacket()? Если вы уменьшите код в printPacket() до минимума (последний байт адреса отправителя и 1-байтовый идентификатор кадра), вы увидите, что все пакеты проходят (признак того, что вы тратите слишком много времени на сброс пакетов).

person tomlogic    schedule 20.02.2017
comment
спасибо за ответ @tomlogic. Я использую скорость передачи данных 115200 для всех трех Arduino. Ошибка в примере кода была исправлена. Отправка работает, так как я получаю сообщения подтверждения для обоих маршрутизаторов. Но некоторые пакеты не подтверждаются. Происходит примерно в 2 из 10 пакетов (в обоих xbees). 50 Гц не обязательно, но чем выше, тем лучше для меня. Я использую серийный номер программного обеспечения на всех трех xbees. Даже когда я сокращаю код в printPacket до минимума, все пакеты не проходят. - person Aniket; 20.02.2017
comment
Вы по-прежнему печатаете много информации о каждом полученном пакете (100 символов * 50 сообщений = 50 кбит/с из макс. 115,2 кбит/с) — уменьшите ее до нескольких байтов для тестирования. Возможно, вы тратите так много времени на печать пакетов, что отстаете. Насколько велики последовательные буферы на Arduino? Можно ли использовать аппаратное квитирование (CTS/RTS) для предотвращения переполнения буфера? - person tomlogic; 21.02.2017
comment
Я сократил код до минимума данных (8 байт), которые необходимы. Размер последовательного буфера составляет 64 байта для Arduino. Я попытался увеличить размер буфера UNO, используя метод, показанный на hobbytronics.co. uk/arduino-serial-buffer-size, но все равно теряет байты данных. Есть идеи, что еще можно попробовать? - person Aniket; 21.02.2017

Меня беспокоит код, который вы используете в цикле. Я не знаю, как работает Arduino, но блокирует ли эта задержка в 10 мс другой код от обработки данных? А если упростить:

void loop()
{
    xbee.read();
    // Process any complete frames.
    while (xbee.isComplete()){
        Serial.print("\nIncoming Message: ");
        printPacket( xbee.getIncomingPacketObject() );
    }
}

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

person tomlogic    schedule 21.02.2017
comment
Я убрал задержку в коде для Координатора, урезал размер пакета до 8 байт полезной нагрузки (ранее было 45, общий размер пакета около 15 байт), даже тогда он просто упорно сбрасывал точки данных. Результат, показанный в ссылке в исходном посте, был получен с помощью эмулятора терминала на ПК, подключенном к Uno с Xbee Shield. Когда я напрямую подключаю координатор к ПК с помощью Xbee Explorer, я получаю тарабарщину. Это может быть потому, что я нахожусь в режиме API. Но я просто не могу понять, почему он не работает. Мне это нужно для моей диссертации. Любая помощь приветствуется. - person Aniket; 21.02.2017
comment
Вам нужно будет просмотреть данные в шестнадцатеричном виде, чтобы понять их. Следите за 0x7E в качестве начального символа кадра, за которым следует двухбайтовая длина и тип кадра. Как я уже сказал, вам нужно сначала убедиться, что вы действительно отправляете данные с маршрутизаторов, прежде чем тратить больше времени на устранение неполадок координатора. Самым простым решением для этого может быть снижение частоты обновления до тех пор, пока вы не получите надежную связь. - person tomlogic; 22.02.2017
comment
В одном проекте мониторинга, над которым я работал, конечные устройства собирали данные в течение 5 минут, а затем отправляли один пакет с минимальным, максимальным и средним значением за это 5-минутное окно. Возможно, что-то подобное сработает для вашего проекта. - person tomlogic; 22.02.2017
comment
Вы также можете попробовать работать с одним маршрутизатором, предоставляющим данные, чтобы убедиться, что вы получаете надежную связь. Это был бы быстрый способ подтвердить правильную работу на обоих концах. В этот момент это либо проблема перегрузки сети в сети ZigBee, либо слишком большая обработка на координаторе, чтобы не отставать. Если один работает, попробуйте два с половиной частоты дискретизации. - person tomlogic; 22.02.2017