[AndreyS 0]

Вопрос в скорости передачи байта. Верне времени отставания переданного байта в эфир и реально полученного в другом устройстве. Каково оно???

 

А пока вводная.

Имею

пакет из 5 байт в одну сторону и пакет из 2-х байт в подтверждение.

Пакет на передачу (5 байт) состоит из:

0 - 1 байт заголовок

1,2 - 2 байта данных

3 - 1 байт временной метки

4 - 1 байт CRC

Пакет подтверждения

0 - 1 байт заголовок

1 - 1 байт CRC

 

Иными словами, меньше чем 5 байт пакет сделать нельзя.

 

Теперь о скорости передачи. Реально данные (поток байтов в одну сторону) передаются (я говорю про максимальную частоту) с скорость 62500 бит в сек (сам проверял, перед тем как начать писать протокол MAC для своей задачи). Теперь если взять идеал, то для пакетной передачи (в 5 байт на передачу и 5 на ответ) максимальная скорость 781 пакет в секунду. На практике это не достижимо. Мало того у меня получилось что с 5 на передачу и 2 на ответ максимальная скорость формирования пакетов не более 300!! (ну в первую очередь это связано с реповторами, а во вторую из-за того, что время от момента, когда сработало прерывание, что мол передающий буфер передатчика пуст и до момента, когда сработало прерывание в приемнике, что есть байт инфы составляет 490 uS. Это очень много!! Это почти 4 байта полезной информации!!

 

 

Вот и вопрос.

Кто работал с этой микрухой, какую максималку в пакетной передачи достигал????

У меня получилось что максимальная скорость (с учетом выше сказанного. А речь идет именно о пакетах!!!) 12000 к бит в сек. Для моей задачи этого мало, да и по расчетам должно было быть болшьше. Но вот время отставания меня просто убило!!! :( Как бы его сокраить???? Не хочется делать асинхронную передачу пакетов. Это будет геморой еще тот!!!

 

Подскажите. Какое время отставания данных!!!???????

[Dr.NoA 0]

Не совсем понятно, что вы имеете в виду. Из сказанного вами получается, что задержка распространения составляет 490 мкс. Грубо говоря, для такой задержки расстояние между устройствами должно быть порядка 147 км! Скорее всего, вы как-то некорректно измеряете.

Как же вы тогда проверяли максимальную скорость в 62500 бит/с?

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

Попробуйте не использовать прерывания, а выполнять поллинг.

[AndreyS 0]

Решил попробывать (как вы рекомендовали) опрос флажка, а не прерывание. Цифры получилиь такими же.

Теперь попробую объяснить что именно я имел в виду.

Вот кусок кода:

bit transmit_radio(byte buffer_length, byte *tx_buffer)
{
   byte i;
   unsigned int counter;
   // Включаем режим передачи
   radio_transmit_on();
   counter=Get_Radio_byte(REG_TX_INT_STAT);
   clr_int_radio;
   // включаем прерывание TX буфер пуст
   Write_Radio(REG_TX_INT_EN, TX_EMPTY);
   // передаем пакет
   LED=!LED;
   for(i = 0; i < buffer_length; ++i, tx_buffer++) 
   {
     for (counter = 0; (counter < DEADMAN_MAX_COUNT) && (!Irq_radio); counter++); // ждем полной передачи
     if (Irq_radio)
     {
       LED=1;
       Write_Radio(REG_DATA_TX, *tx_buffer);
       counter=Get_Radio_byte(REG_TX_INT_STAT);
       clr_int_radio;
       LED=0;
     }
     else
     {
       radio_off();
       LED=!LED;
       return(0x00);
     }
   }
   // включаем прерывание EOF
   Write_Radio(REG_TX_INT_EN, TX_EOF);
   for (counter = 0; (counter < DEADMAN_MAX_COUNT) && (!Irq_radio); counter++); // ждем выполненея EOF
   // выключаем передатчик
   radio_off();
   LED=!LED;
   return(0x01);
}

 

LED в данном случае показывает, когда сработал обработчик записи в CYWUSB байта. По нему и смотрю. Вот и получается что (при передачи 2-х байт) между первым входом в обработчик и второым входом растояние = 180uS. Далее смотрим какое расстояние от первого входа в обработчик отправки и выходом из процедуры (ну вернее я поставил второй щуп осца на ножку прерывания и измеряю расстояние до срабатывания прерывания EOF) и оно равно 460uS.

 

После этого я вывел на LED приемника в процедуре приема состояние о приеме данных. Приведу процедурку приема.

byte recive_radio(byte *rx_buffer,int TIME_OUT)
{
   unsigned int i;
   byte j,temp_crc;
   byte irq_source=0;
   byte rx_data_len=0;// указатель на результат выполнения функции
   byte num_erasures=0;// число ошибочных бит в переделах одной позиции. При таком подсчете CRC не может быть больше 1.
   byte bad_row=0;// позиция в буфере данных с битым битом
   byte bad_bit_count = 0;// число битых байт во всем пакете. Не может быть более 3-х.
   byte valid_buffer[MAX_RX_BUF];

   radio_receive_on();
   clr_int_radio;
   // включаем прерывание RX (EOF, OVER, FULL)
   irq_source=Get_Radio_byte(REG_RX_INT_STAT);
   Write_Radio(REG_RX_INT_EN, (RX_OVER_A | RX_EOF_A | RX_FULL_A));
   // цикл приема с учетом таймаута.
   // Т.е. принимаем пока не получим EOF или не выйдет время.
   // Если получм OVER, то пакет прибиваем (потерян байт)
   LED=!LED;
   for (i=0; i<=TIME_OUT; i++)
   {
      if (Irq_radio)
      {
         // пошел прием
         // получаем байт состояни прерывания. (кто вызвал нас?)
         irq_source=Get_Radio_byte(REG_RX_INT_STAT);
         clr_int_radio;
         if(irq_source & RX_FULL_A)
         {
            if (rx_data_len<MAX_RX_BUF)
            {
               // есть байт в приемнике. Нужно забрать.
               // читаем данные
               LED=1;
               *rx_buffer=Get_Radio_byte(REG_DATA_RX_A);    
               LED=0;
               // читаем VALID регистр при условии, что в состоянии возведен флаг. То просто FF
               if (irq_source & RX_VALID_A)
               {
                  valid_buffer[rx_data_len] = 0xFF;
               }
               else
               {
                  valid_buffer[rx_data_len] = Get_Radio_byte(REG_VALID_RX_A);
               }    
               // переводим указатели чтения
               rx_data_len++;
               rx_buffer++;    
               // отсрачиваем таймаут
               i=0;
            }
            else
            {
               Get_Radio_byte(REG_DATA_RX_A); // освобождаем буфер приема
               radio_off();
               LED=!LED;
               return(0); // Если на выходе rx_data_len=0, то значит пакет не принят.
            }
         }
         if(irq_source & RX_EOF_A)
         {               
            if (valid_buffer[rx_data_len-1]>=0xFF)
            {
               break; // необходимо выйти. весь пакет приняли
            }
            // ошибка в байте с CRC. Восстановить не сможем
            Get_Radio_byte(REG_DATA_RX_A);     // освобождаем буфер приема
            radio_off();
            LED=!LED;
            return(0); // Если на выходе rx_data_len=0, то значит пакет не принят.
         }
         if(irq_source & RX_OVER_A)
         {
            Get_Radio_byte(REG_DATA_RX_A); // освобождаем буфер приема
            radio_off();
            LED=!LED;
            return(0); // Если на выходе rx_data_len=0, то значит пакет не принят.
         }
      }
      else
      {
         // выждать 10uS
         time(tick_10us);
      }
   }
   radio_off();
   LED=!LED;
   if (rx_data_len != 0)
   {
      // тут обработчик по проверке целостности и попытке восстановления пакета.
   }
   return(rx_data_len);    // Если на выходе rx_data_len=0, то значит пакет не принят.
}

 

И что же я увидел. Да то что расстояние между первым срабатыванием прерывания в передатчике и первым срабатыванием прерывания в приемнике = 490uS. Сейчас могу сказать что это неправильное измерение. Теперь измеряем расстояние от начала передачи второго байта до начала приема первого байта (вот это истинное отставание) = 240uS. А если посчитать сколько времени понадобится для передачи одного байта при скорости 62500, то оно равно 128uS. Теперь отложим отрезок от первого срабатывания прерывания в передатчике = 128uS и от него измерим расстояние до первого срабатываниря прерывания в приемнике = 292uS. Это равно времени передачи 2.28 байт. Колосальная задержка!!!. Теперь посмотрим расстояние между двумя принятыми байтами в приемнике. Оно равно 128 uS. Т.е. скорость 62500. Иными словами. Все работает на своей скорости, но наблюдается отставание в передаче байт. Такое чувство, что в передатчике есть глубокий буфер и вторым байтом я выпихиваю первый в среду.

В общем если передавать с подтверждением, то эта пауза дает огромную потерю в макимальной частоте формирования пакетов. :(

[Dr.NoA 0]

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

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

 

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

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

[AndreyS 0]

Про поток без подтверждения думал, но определяя максимальное число реповторов на передачу пакета в случае если подтверждение не получено, но при этом приемник функционирует и попросту это есть рассинхронизация во времени, то получил что не менее 8. Иными словами есть вероятность, что пакет не будет воспринят приемником на другой стороне или он попросту не сможет пробиться и отправить ответ передатчику за 8 реповторов. А после 8 реповторов я считаю что связь потеряна и останавливаю всякую передачу и перехожу в режим определения маршрутизатора в сети. По этому боюсь не поможет. Но попробую. Так конечно можно вытянуть максимальную частоту формирования пакетов в 785 Гц. Выше уже точно в моем случае невозможно. Ну хоть 500 точно вытяну.

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

Все равно большое спасибо за помощь.

Сейчас проверил, максималку смог вытянуть 400Гц формирования пакетов. Прийдется на этом остановиться. Зато хоть все устойчиво работает. ;)

[Dr.NoA 0]

Говоря про увеличение длины пакета, я не имел в виду забивать его бесполезной инфой. Сейчас у вас в пакете 1 байт заголовок, 1 байт CRC и 3 байта полезной информации (2 байта данных и 1 байт временной метки). Время передачи такого пакета и пакета подтверждения составляет (5+2)*128=896 мкс, т.е. задержка получается как треть времени полезной передачи.

Если допустим передавать в одном пакете 20 байт данных и 10 временных меток, т.е. длина пакета получился (1+1+20+10)=32 байта, время транзакции получается (32+2)*128=4352 мкс, тогда потери времени из-за задержки будут всего 7%.

[AndreyS 0]

Точно!!! Вы правы!!! :) Только с реповторами худо. Надо будет подобрать длину пакета так чтобы буфер в 100h не перекрутился. Мысль!! ;)

Спасибо!!

[Dr.NoA 0]

Кстати, провел сейчас эксперименты аналогичные вашим и получил тотже результат. Получается, что непонятно на что тратится около 150-160 мкс при любой скорости передачи (т.е. длине расширяющей последовательности). Очень интересно!

Вы Cypress'у не задавали вопрос по этому поводу?

[AndreyS 0]

Нет не задавал. Я на их форуме не был. И не знаю на сколько они серьезно относятся к этому продуту. Может так выйти что им это все до лампочки. Ведь они его позиционируют для низко скоростных устройств. Типа клава и мышь. Хотя странно. Для оптичской мыши с такой задержкой, они явно пролетят. Максимум 400 Dpi вытянуть можно А этого мало нынче для мышей. А вы знакомы с их форумом и групой поддержки???? У них есть хоть какая-то реакция на вопросы????

 

 

Я не внимательно прочел ваш ответ. Погодите. Вы проверяли и на низких скоростях??!!! Получается задержка константа. Хмммм. Действительно странно. Я то думал, что может быть у них буфер глубокий. А выходит нет. Хмм. Такое чувство, что модулятор отстает. Хотя и так понятно что медленный он 64 бита на один бит полезной инфы, но ведь несущая 2.4 ГГц. Странно.

Изменено 7 марта, 2006 пользователем AndreyS

[Dr.NoA 0]

Суммарная задержка, которую вы собственно и измеряли, состоит из двух частей: время на передачу непосредственно байта и 150 мкс задержка непонятно на что. При скорости передачи 62500 бит/c суммарная задержка будет (128+150)=278 мкс, т.е. примерно то что вы получили. При 31250 - (256+150)=406 мкс, при 15625 - 662 мкс. Примерно эти значения я как раз и получил при экспериментах.

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

Сам форум на сайте Cypress ничего интересного из себя не представляет, т.к. общаются на нем обычные пользователи, как мы с вами, так что врядли вы там узнаете что-то новое.

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

[AndreyS 0]

Я им уже задал этот вопрос, если ответят что-то внятное, сообщу.

Отлично. Буду ждать от вас сообщения.

 

CYRF6936. Что вы можете сказать об этом чипе??? Работали ли вы с ним??? Я так понял Cypress не выпускает готовых модулей на базе этого чипа. Для этого чипа существуют какие либо отличия по разводке антены от CYWUSB693x?????

 

Вопрос не теме. А вы не работали с CY7C68013???

Изменено 8 марта, 2006 пользователем AndreyS

[Dr.NoA 0]

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

 

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

 

С CY7C68013 не работал.

[AndreyS 0]

Да нет. Модули применять я не собираюсь. Просто проще было бы начать их изучать. Я начал с CYWUSB6934, заказал пару микрух в SOI корпусе и ждал их прихода 2 недели, потом распаял на макетке (конечно ВЧ тракт постарался сделать как можно лучше, но все равно не ахти получиля. Но дальности в 5 метров мне достаточно!!! Так что почти сразу с заказом CYWUSB6934 напоролся на модули и решил их тоже заказать) получилось очень даже неплохо. Попробовав модуль понял, что для простой проработки материала это удобнее. Хотя собранные мной макеты CYWUSB6934 работаю хорошо. Теперь я имею уже 4 устройства. Два с модулями и два с макетами. Отлажу прошивки на модулях и начну проверять работу в составе 4-х устройств (одно мастер).

 

Не секрет. ;) Хочу применить ее для передачи пульсовой волны (медицина) в мое уже существующее и продаваемое устройство. Иными словами модернизировать. Сейчас используется проводной датчик пульса. Но это крайне неудобно для пользователей и плюс часто происходит перегиб провода и его обрыв. Многие сейчас гонятся за скоростью передачи в безпроводных устройствах. Мне необходима скорость для реализации 1000Гц пакетов. Но в принципе для предварительного анализа хватит и получившихся 400Гц. А вообще интерресуют приемо передатчики на нелецензированных и разрешенных медиками частотах 2.4 ГГц как раз то что нужно. Конечно эта микруха много жрет. Вернее ОЧЕНЬ МНОГО!!!! Но я пока нахожусь на стадии проектирования и проработки материала. Так что для макета и показа думаю этого достаточно. По расчетам аккумулятора 1000 mA/H должно хватить на 5-8 дней рабочего режима этого устройства. При текущем потреблении.

Могли бы что-нибудь (желательно такое же простое, как эти микросхемы. Так как сложные сети на них не собираюсь строить. ЗигБи точно не нужно!!!! Суть предмета достаточно проста, по этому и сети строить нет смысла. Должно работать Пир 2 пир. Но при этом Хост должен видеть все устройства в сети. Но организовывать только один канал передачи данных, потому как должен работать только с одним устройством при прокачке информации) подсказать. Так сказать дать пару ссылок. Вот приглядываюсь к Chipcon CC2420. Но пока хочу поработать с Cypress. Надо же его всеже довести до конца и посмотреть как оно будет выглядеть в окончательном варианте ;). В дальнейшем предполагаю реализовать стек сопряжения своего устройства по каналу Wi Fi с PC. Вот тут я пока вообще ничего не знаю. Скорости в 10Мбит бля меня за глаза (минималка необходима 1.2 Мбит). Но хочу именно WiFi, а не ZigBee. Хотя ZigBee с 250Кбит не подойдет. Быть может вы работали с WiFi на стороне микроконтроллеров??? Смоглибы дать пару полезных ссылок??? На стороне PC подразумеваю использовать покупную карту. В общем хочу ввести свое устройство в локальную сеть. ;)

Изменено 8 марта, 2006 пользователем AndreyS

[Dr.NoA 0]

Не совсем понятно как вы прокачаете 1000 пакетов в секунду, да еще и от 4 устройств. Может быть имеет смысл вычислять пульс непосредственно у датчика и передавать уже результат. Все равно ведь у вас стоит микроконтроллер какой-то. А так потребуется, скорее всего, выделять каждому устройству свою частоту.

По поводу других приемопередатчиков. Как вы, наверное, заметили выбор-то не особенно большой. Можно попробовать приемопередатчики Zigbee, только не использовать сетевой стек для создания сети, а пользоваться только физическим и MAC уровнем, причем часть функциональности MAC уровня у них реализовано уже аппаратно. Для вас лучше подойдут CC2420 (ну и его клоны) от Chipcon и приемопередатчики от Freescale. Лично мне они не нравятся в силу того, что слишком уж заточены под ZigBee.

Еще достаточно интересные приемопередатчики делает Nordic (например, nRF2401, кажется), у них просто частотная модуляция, зато скорость до 2 Мбит/с.

Меня тоже в Cypress все устраивает, но вот потребление ужасное. Поэтому-то я и жду появления новой микрухи, она должна потреблять что-то среднее между Chipcon и Freescale.

 

По поводу Wi-Fi ничего рекомендовать не могу. У меня тоже давно есть желание использовать Wi-Fi в девайсах, но проблема заключается в том, что все производители (которых я знаю) чипсетов ориентируются на крупных заказчиков. Просто так вы даже документацию не получите. Хотя если у вас речь идет о массовом производстве, то это другое дело.

[AndreyS 0]

Да данные передавать нужно только от одно устройства. Т.е. 4 или более в сети, но связь устанавливается по передаче данных только с одним. Остальные в этот момент могут быть вообще выключены. Политика такова, да и устройство достаточно мало (чтобы применять полное ZigBee), что связь в момент прокачки данных это тупое P2P соединение. А когда данные не передаются, то пользователь видит все доступные устройства в сети и может выбрать работу с одним из них. А про 1000 это достаточная максимальная скорость. Конечно можно сразу данные обрабатывать, вот только выводить информацию будет некуда. Устройство достаточно мало, чтобы на него установить ЖК дисплей. Устройство крепится на палец человека. А информация выводится для врача. По этому все равно транслировать данные необходимо. Пока я остановился на 400 пакетах в сек. Попробую упаковать больше отсчетов в один пакет, посмотрим на сколько смогу поднять частоту дискретизации.

А из ZigBee чип кон мне нравится своими размерами.

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

Вы читали документацию (вероятно да) на CYRF6936??? Я не совсем понял. Для работы на 1000 кбит в сек не используются PN??

PMU каков его КПД???

Ток потребления я так понял соответствует VCC питанию??

Вкусная вещь. ;) Всю пакетную передачу можно запихать в чип. А контроллер может заняться алгоритмами вычисления.