Igor_O 0 25 февраля, 2009 Опубликовано 25 февраля, 2009 · Жалоба RF_SETTINGS code rfSettings = { 0x06, // FSCTRL1 Frequency synthesizer control. 0x00, // FSCTRL0 Frequency synthesizer control. 0x10, // FREQ2 Frequency control word, high byte. 0x09, // FREQ1 Frequency control word, middle byte. 0x7B, // FREQ0 Frequency control word, low byte. 0xF5, // MDMCFG4 Modem configuration. 0x75, // MDMCFG3 Modem configuration. 0x13, // MDMCFG2 Modem configuration. 0x22, // MDMCFG1 Modem configuration. 0xE5, // MDMCFG0 Modem configuration. 0x00, // CHANNR Channel number. 0x14, // DEVIATN Modem deviation setting (when FSK modulation is enabled). 0x56, // FREND1 Front end RX configuration. 0x10, // FREND0 Front end TX configuration. 0x18, // MCSM0 Main Radio Control State Machine configuration. 0x16, // FOCCFG Frequency Offset Compensation Configuration. 0x6C, // BSCFG Bit synchronization Configuration. 0x03, // AGCCTRL2 AGC control. 0x40, // AGCCTRL1 AGC control. 0x91, // AGCCTRL0 AGC control. 0xE9, // FSCAL3 Frequency synthesizer calibration. 0x2A, // FSCAL2 Frequency synthesizer calibration. 0x00, // FSCAL1 Frequency synthesizer calibration. 0x1F, // FSCAL0 Frequency synthesizer calibration. 0x59, // FSTEST Frequency synthesizer calibration. 0x81, // TEST2 Various test settings. 0x35, // TEST1 Various test settings. 0x09, // TEST0 Various test settings. 0x07, // FIFOTHR RXFIFO and TXFIFO thresholds. 0x3F, // IOCFG2 GDO2 output pin configuration. 0x06, // IOCFG0D GDO0 output pin configuration. Refer to SmartRFR Studio User Manual for detailed pseudo register explanation. 0x0C, // PKTCTRL1 Packet automation control. 0x05, // PKTCTRL0 Packet automation control. 0x00, // ADDR Device address. 0xFF // PKTLEN Packet length. Передаю 3 байта. Если ставлю PKTLEN 0х03 и PKTCTRL0 0х04 пакеты приходят . В приемнике: 0. Инициализация и установка мощности 1. SFRX 2. Пауза 1 мс 3. Вкл. SRX 4. Читаю GDO0 пока не 1 5. Читаю GDO0 пока не 0 6. Проверяю, что RXBYTES не равен 0 7. 3 раза читаю RXFIFO 8. Вывод результата на RS232 9. SIDLE переход на п.1 В передатчике: 0. Инициализация и установка мощности 1. SFTX 2. 3 раза данные в TXFIFO 3. STX 4. Читаю GDO0 пока не 1 5. Читаю GDO0 пока не 0 - Окончание передачи 6. Пауза 1 сек (для вывода в приемнике данных на RS232 ) переход на п.1 Если ставлю в настройках PKTLEN 0хFF и PKTCTRL0 0х05 пакеты не приходят. В чем может быть проблема? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 25 февраля, 2009 Опубликовано 25 февраля, 2009 · Жалоба Если ставлю в настройках PKTLEN 0хFF и PKTCTRL0 0х05 пакеты не приходят. В чем может быть проблема? А что предполагается сделать ? При PKTCTRL0 = 05 первый байт пакета должен содержать длину (пакет переменной длины). Так и делается ? А то уйдет передатчик в underflow, и не придет ничего, естественно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 25 февраля, 2009 Опубликовано 25 февраля, 2009 · Жалоба Получилось! По даташиту думалось, что длину пакета СС1101 вычисляет сама. Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать? При приеме с подтверждением сталкиваюсь с тем, что по CRC CC1101 (LQI 7) данные ОК, а данные битые и моя (посчитанная отдельной п.п) CRC, переданная внутри пакета выдает ошибку. Причем сбойные данный явно не мусор, т.к. часто повторяются. Например: в цикле передаю 0х21 0х03 CRC, а на входе 0х05 0х7F XX Куда копать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 25 февраля, 2009 Опубликовано 25 февраля, 2009 · Жалоба Получилось! По даташиту думалось, что длину пакета СС1101 вычисляет сама. Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать? После приема надо перейти в idle (автоматически либо вручную, если используется непрерывный прием), затем передавать. При приеме с подтверждением сталкиваюсь с тем, что по CRC CC1101 (LQI 7) данные ОК, а данные битые и моя (посчитанная отдельной п.п) CRC, переданная внутри пакета выдает ошибку. Причем сбойные данный явно не мусор, т.к. часто повторяются. Например: в цикле передаю 0х21 0х03 CRC, а на входе 0х05 0х7F XX Куда копать? А вот тут не подскажу - с таким не сталкивался... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 7 марта, 2009 Опубликовано 7 марта, 2009 · Жалоба Никак не получается запустить устойчивый прием/передачу. Пробую разные скорости и разные настройки. Несколько пакетов ловятся нормально, затем ловит мусор, причем постоянно один и тот же код неправильно принятых байт. Начал смотреть регистр RXBYTES, а там число принятых байт все время разное и неправильное. Я передаю всегда 3 байта, а ловится чаще всего в RXBYTES 22, затем, когда в RXFIFO мусор RXBYTES=81, т.е переполнен. Перед чтением строб SFRX посылаю (см. мой порядок действий в первом посте). Пробовал и с фиксированными пакетами и с произвольными - везде так. Что я делаю не так? 0. Инициализация и установка мощности 1. SFRX 2. Пауза 1 мс 3. Вкл. SRX 4. Читаю GDO0 пока не 1 5. Читаю GDO0 пока не 0 6. Проверяю, что RXBYTES не равен 0 7. 3 раза читаю RXFIFO 8. Чтение LQI и контроль CRC (LQI (7)) 9. Чтение RSSI 10. Строб SIDLE 11. Строб SFTX 12. Пауза 1 мс 13. 3 байта в TXFIFO (не burst) 14. Строб STX 15. Читаю GDO0 пока не 1 16. Читаю GDO0 пока не 0 17. Пауза 1 мс (вставил уже от нечего делать) 18. SIDLE 19. Вывод результата на RS232 go на п. 1 переход на п.1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 7 марта, 2009 Опубликовано 7 марта, 2009 · Жалоба Никак не получается запустить устойчивый прием/передачу. Кварц - сколько ppm? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bloodden 0 7 марта, 2009 Опубликовано 7 марта, 2009 · Жалоба //38.4kbps nastroyki dlya 26.000 halSpiWriteReg(CCxxx0_FSCTRL1, 0x06); halSpiWriteReg(CCxxx0_FSCTRL0, 0x00); halSpiWriteReg(CCxxx0_FREQ2, 0x10); halSpiWriteReg(CCxxx0_FREQ1, 0xB0); halSpiWriteReg(CCxxx0_FREQ0, 0x71); halSpiWriteReg(CCxxx0_MDMCFG4, 0xCA); halSpiWriteReg(CCxxx0_MDMCFG3, 0x83); halSpiWriteReg(CCxxx0_MDMCFG2, 0x13); halSpiWriteReg(CCxxx0_MDMCFG1, 0xA2); halSpiWriteReg(CCxxx0_MDMCFG0, 0xF0); halSpiWriteReg(CCxxx0_CHANNR, 0x00); halSpiWriteReg(CCxxx0_DEVIATN, 0x34); halSpiWriteReg(CCxxx0_FREND1, 0x56); halSpiWriteReg(CCxxx0_FREND0, 0x10); halSpiWriteReg(CCxxx0_MCSM0 , 0x18); halSpiWriteReg(CCxxx0_FOCCFG, 0x16); halSpiWriteReg(CCxxx0_BSCFG, 0x6C); halSpiWriteReg(CCxxx0_AGCCTRL2, 0x43); halSpiWriteReg(CCxxx0_AGCCTRL1, 0x40); halSpiWriteReg(CCxxx0_AGCCTRL0, 0x91); halSpiWriteReg(CCxxx0_FSCAL3, 0xE9); halSpiWriteReg(CCxxx0_FSCAL2, 0x2A); halSpiWriteReg(CCxxx0_FSCAL1, 0x00); halSpiWriteReg(CCxxx0_FSCAL0, 0x1F); halSpiWriteReg(CCxxx0_FSTEST, 0x59); halSpiWriteReg(CCxxx0_TEST2, 0x81); halSpiWriteReg(CCxxx0_TEST1, 0x35); halSpiWriteReg(CCxxx0_TEST0, 0x09); halSpiWriteReg(CCxxx0_IOCFG2, 0x40); halSpiWriteReg(CCxxx0_IOCFG0, 0x06); halSpiWriteReg(CCxxx0_PKTCTRL1, 0x0C); halSpiWriteReg(CCxxx0_PKTCTRL0, 0x04); halSpiWriteReg(CCxxx0_ADDR, 0x00); halSpiWriteReg(CCxxx0_PKTLEN, 0x08); Под 26.0000МГц и скорость 38,4. У меня работает. Попробуйте, может Вам поможет. Это передача: void Send_packet(unsigned char* data, unsigned char len) { P2IE &= ~BIT7;//GDO0 ~IE halSpiStrobe(CCxxx0_SIDLE); halSpiStrobe(CCxxx0_SFTX); halSpiWriteBurstReg(CCxxx0_TXFIFO, data, len); halSpiStrobe(CCxxx0_STX); //while (~GDO0_PIN); // Wait for GDO0 to be set -> sync transmitted //while (GDO0_PIN); // Wait for GDO0 to be cleared -> end of packet while((P2IN&BIT7) == 0); while((P2IN&BIT7) != 0); halSpiStrobe(CCxxx0_SFTX); Receive_packet_int(rx_buff); } А на приём прерывание (мсп430): #pragma vector = PORT2_VECTOR __interrupt void PORT2_VECTOR_code() { rx_len=halSpiReadStatus(CCxxx0_RXBYTES); if(rx_len == 0) { halSpiStrobe(CCxxx0_SIDLE); halSpiStrobe(CCxxx0_SFRX); halSpiStrobe(CCxxx0_SRX); rx_rdy=0; } else { halSpiReadBurstReg(CCxxx0_RXFIFO, pointer_receive_buffer, rx_len); halSpiStrobe(CCxxx0_SIDLE); halSpiStrobe(CCxxx0_SFRX); halSpiStrobe(CCxxx0_SRX); if((pointer_receive_buffer[rx_len-1] >= 0x80))//CRC ok { ///////////////////////наши данные правильны и приняты } } P2IFG &= ~BIT7;//IF clear } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 8 марта, 2009 Опубликовано 8 марта, 2009 (изменено) · Жалоба У Вас в коде кол-во принятых байт не анализируется. Просто проверяется, что не 0. Неустойчивый прием оказался из-за аппаратной части. Заменил Сс1101 и контроллер - стало принимать стабильно, но вопрос остался. Количество принятых байт стабильно показывает 0F вместо 3 -х. Перед приемом делаю SIDLE затем SFRX, потом SRX. Пробовал после передачи подтверждения делать SPWD ( CC1101 SLEEP ) все равно - кол-во принятых байт 0F. Что может быть? Я так понимаю, должно быть 5 (3 байта данных, LQI и RSSI). Убрал передачу подтверждения - кол-во принятых байт стало =5. После приема перед передачей вставил еще одно SIDLE, SFRX (SFTX было) - все арвно 0F. Изменено 8 марта, 2009 пользователем Igor_O Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 8 марта, 2009 Опубликовано 8 марта, 2009 · Жалоба Я бы предложил для начала поиграться с фиксированной длиной пакета, в этом режиме я лично никаких проблем не наблюдал (а с переменной длиной, когда передается байт длины - не пробовал). И еще - там в эрратах есть предупреждения на предмет тонкостей опроса счетчика принятых-отправленных, да и в контроле состояния не все так просто, плюха была в 1100, и, насколько мне помнится, все это осталось и в 1101. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба Разобрался с длиной пакета. Как оказалось все просто: - запрос RXBYTES делал не как для статус регистра (6 бит не был =1), отсюда и получал данные с другого регистра с тем же адресом до 6 бита. Теперь все работает, принимает, передает подтверждение. Четко вижу уровень сигнала по RSSI (70 dB от одного передатчика и 80 dB от другого). Уровень стабилен. Максимально прыгает на 1-3 dB. Обмен идет каждые 20 сек. Информация от каждого передатчика независимая, т.е. возможно наложение пакетов. В защиту от этого при ошибке CRC ошибка подтверждения и, как следствие повтор передачи. При повторе по временной разбежке сдваивание повторного пакета уже не возможно. Все работает, но через некоторое время (1 - 2 часа) с GDO0 перестает поступать импульс принятого пакета. До зависания мощность принятых пакетов нормальная. На GDO1 генерация f/128 есть. Мерял частоту кварцев - отличаются на 20-100 Гц. Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема? Я как-то получил нечто похожее - из-за невозможности непосредственного контроля готовности после подачи выборки на трансивер, сделал просто задержку от выборки до подачи команды. Задержка оказалась слишком малой, на грани. И вот если реально готовности не поступило, то прием не работал (хотя вроде бы в статусе был код состояния приема, не помню теперь уже). И вроде бы все регистры посмотрел - все как надо, а прием - не работал. Пока с готовностью не разобрался, так и выползало, раз в час... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба ...через некоторое время (1 - 2 часа) с GDO0 перестает поступать импульс принятого пакета. До зависания мощность принятых пакетов нормальная. На GDO1 генерация f/128 есть. Мерял частоту кварцев - отличаются на 20-100 Гц. Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема? Тайм-ауты при всех ожиданииях предусмотрены, обработчики ошибок таймаутов есть? Я как старый параноик периодически сбрасываю трансивер и полностью инициализирую его заново, в части изделий - с передергиванием питания, для чего ставлю ключ на питание трансивера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба To rx3apf: Не совсем понял. Задержка после подачи CS (выбор СС) и передачей команды SRX? или что имеется ввиду? To 3m: Приемник постоянно крутится в приеме GDO0 (IOCFG0 0x06). Какой таймаут нужен? Неужели СС зависает раз в час? Чего то круто, ладно конфиг ему переписывать, но питание передергивать как то круто Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба To rx3apf: Не совсем понял. Задержка после подачи CS (выбор СС) и передачей команды SRX? или что имеется ввиду? Да. Согласно даташиту, после подачи -CS надо дождаться "0" на SDO. Я этого сделать не мог (требовалась особая экономичность), и попробовал тупой задержкой. И - нарвался... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Igor_O 0 24 марта, 2009 Опубликовано 24 марта, 2009 · Жалоба У меня есть ожидание 0 на SDO. Но поставил несколько микросекунд задержку. Посмотрим, поможет или нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
