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 пакеты не приходят. В чем может быть проблема?
Полная версия этой страницы: Помогите разобраться с CC1101
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Rf & Microwave Design
Цитата(Igor_O @ Feb 25 2009, 14:37) 
Если ставлю в настройках PKTLEN 0хFF и PKTCTRL0 0х05 пакеты не приходят. В чем может быть проблема?
А что предполагается сделать ? При PKTCTRL0 = 05 первый байт пакета должен содержать длину (пакет переменной длины). Так и делается ? А то уйдет передатчик в underflow, и не придет ничего, естественно...
Получилось! По даташиту думалось, что длину пакета СС1101 вычисляет сама.
Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать?
При приеме с подтверждением сталкиваюсь с тем, что по CRC CC1101 (LQI 7) данные ОК, а данные битые и моя (посчитанная отдельной п.п) CRC, переданная внутри пакета выдает ошибку. Причем сбойные данный явно не мусор, т.к. часто повторяются. Например: в цикле передаю 0х21 0х03 CRC, а на входе 0х05 0х7F XX
Куда копать?
Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать?
При приеме с подтверждением сталкиваюсь с тем, что по CRC CC1101 (LQI 7) данные ОК, а данные битые и моя (посчитанная отдельной п.п) CRC, переданная внутри пакета выдает ошибку. Причем сбойные данный явно не мусор, т.к. часто повторяются. Например: в цикле передаю 0х21 0х03 CRC, а на входе 0х05 0х7F XX
Куда копать?
Цитата(Igor_O @ Feb 25 2009, 16:48)
Получилось! По даташиту думалось, что длину пакета СС1101 вычисляет сама.
Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать?
Теперь еще вопрос: Если нужно после приема передать подтверждение, то достаточно ли просто обнулить SFTX, записать данные, включить STX и подождать окончания передачи на GDO0 или нужно после приема очистить SFRX и перейти в IDLE, уже затем передавать?
После приема надо перейти в idle (автоматически либо вручную, если используется непрерывный прием), затем передавать.
Цитата
При приеме с подтверждением сталкиваюсь с тем, что по CRC CC1101 (LQI 7) данные ОК, а данные битые и моя (посчитанная отдельной п.п) CRC, переданная внутри пакета выдает ошибку. Причем сбойные данный явно не мусор, т.к. часто повторяются. Например: в цикле передаю 0х21 0х03 CRC, а на входе 0х05 0х7F XX
Куда копать?
Куда копать?
А вот тут не подскажу - с таким не сталкивался...
Никак не получается запустить устойчивый прием/передачу. Пробую разные скорости и разные настройки. Несколько пакетов ловятся нормально, затем ловит мусор, причем постоянно один и тот же код неправильно принятых байт.
Начал смотреть регистр 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
Начал смотреть регистр 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
Цитата(Igor_O @ Mar 7 2009, 15:56)
Никак не получается запустить устойчивый прием/передачу.
Кварц - сколько ppm?
Код
//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);
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);
}
{
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
}
__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
}
У Вас в коде кол-во принятых байт не анализируется. Просто проверяется, что не 0. Неустойчивый прием оказался из-за аппаратной части. Заменил Сс1101 и контроллер - стало принимать стабильно, но вопрос остался. Количество принятых байт стабильно показывает 0F вместо 3 -х. Перед приемом делаю SIDLE затем SFRX, потом SRX. Пробовал после передачи подтверждения делать SPWD ( CC1101 SLEEP ) все равно - кол-во принятых байт 0F. Что может быть? Я так понимаю, должно быть 5 (3 байта данных, LQI и RSSI).
Убрал передачу подтверждения - кол-во принятых байт стало =5. После приема перед передачей вставил еще одно SIDLE, SFRX (SFTX было) - все арвно 0F.
Убрал передачу подтверждения - кол-во принятых байт стало =5. После приема перед передачей вставил еще одно SIDLE, SFRX (SFTX было) - все арвно 0F.
Я бы предложил для начала поиграться с фиксированной длиной пакета, в этом режиме я лично никаких проблем не наблюдал (а с переменной длиной, когда передается байт длины - не пробовал). И еще - там в эрратах есть предупреждения на предмет тонкостей опроса счетчика принятых-отправленных, да и в контроле состояния не все так просто, плюха была в 1100, и, насколько мне помнится, все это осталось и в 1101.
Разобрался с длиной пакета. Как оказалось все просто: - запрос RXBYTES делал не как для статус регистра (6 бит не был =1), отсюда и получал данные с другого регистра с тем же адресом до 6 бита.
Теперь все работает, принимает, передает подтверждение. Четко вижу уровень сигнала по RSSI (70 dB от одного передатчика и 80 dB от другого). Уровень стабилен. Максимально прыгает на 1-3 dB. Обмен идет каждые 20 сек. Информация от каждого передатчика независимая, т.е. возможно наложение пакетов. В защиту от этого при ошибке CRC ошибка подтверждения и, как следствие повтор передачи. При повторе по временной разбежке сдваивание повторного пакета уже не возможно. Все работает, но через некоторое время (1 - 2 часа) с GDO0 перестает поступать импульс принятого пакета. До зависания мощность принятых пакетов нормальная. На GDO1 генерация f/128 есть. Мерял частоту кварцев - отличаются на 20-100 Гц. Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема?
Теперь все работает, принимает, передает подтверждение. Четко вижу уровень сигнала по RSSI (70 dB от одного передатчика и 80 dB от другого). Уровень стабилен. Максимально прыгает на 1-3 dB. Обмен идет каждые 20 сек. Информация от каждого передатчика независимая, т.е. возможно наложение пакетов. В защиту от этого при ошибке CRC ошибка подтверждения и, как следствие повтор передачи. При повторе по временной разбежке сдваивание повторного пакета уже не возможно. Все работает, но через некоторое время (1 - 2 часа) с GDO0 перестает поступать импульс принятого пакета. До зависания мощность принятых пакетов нормальная. На GDO1 генерация f/128 есть. Мерял частоту кварцев - отличаются на 20-100 Гц. Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема?
Цитата(Igor_O @ Mar 24 2009, 15:40)
Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема?
Я как-то получил нечто похожее - из-за невозможности непосредственного контроля готовности после подачи выборки на трансивер, сделал просто задержку от выборки до подачи команды. Задержка оказалась слишком малой, на грани. И вот если реально готовности не поступило, то прием не работал (хотя вроде бы в статусе был код состояния приема, не помню теперь уже). И вроде бы все регистры посмотрел - все как надо, а прием - не работал. Пока с готовностью не разобрался, так и выползало, раз в час...
Цитата(Igor_O @ Mar 24 2009, 15:40)
...через некоторое время (1 - 2 часа) с GDO0 перестает поступать импульс принятого пакета. До зависания мощность принятых пакетов нормальная. На GDO1 генерация f/128 есть. Мерял частоту кварцев - отличаются на 20-100 Гц. Прием прекращается одновременно от обоих передатчиков. Алгоритм работы см. выше. В чем может быть проблема?
Тайм-ауты при всех ожиданииях предусмотрены, обработчики ошибок таймаутов есть?
Я как старый параноик периодически сбрасываю трансивер и полностью инициализирую его заново, в части изделий - с передергиванием питания, для чего ставлю ключ на питание трансивера.
To rx3apf: Не совсем понял. Задержка после подачи CS (выбор СС) и передачей команды SRX? или что имеется ввиду?
To 3m: Приемник постоянно крутится в приеме GDO0 (IOCFG0 0x06). Какой таймаут нужен? Неужели СС зависает раз в час? Чего то круто, ладно конфиг ему переписывать, но питание передергивать как то круто
To 3m: Приемник постоянно крутится в приеме GDO0 (IOCFG0 0x06). Какой таймаут нужен? Неужели СС зависает раз в час? Чего то круто, ладно конфиг ему переписывать, но питание передергивать как то круто
Цитата(Igor_O @ Mar 24 2009, 16:24)
To rx3apf: Не совсем понял. Задержка после подачи CS (выбор СС) и передачей команды SRX? или что имеется ввиду?
Да. Согласно даташиту, после подачи -CS надо дождаться "0" на SDO. Я этого сделать не мог (требовалась особая экономичность), и попробовал тупой задержкой. И - нарвался...
У меня есть ожидание 0 на SDO. Но поставил несколько микросекунд задержку. Посмотрим, поможет или нет.
Цитата(Igor_O @ Mar 24 2009, 16:24)
To rx3apf: Не совсем понял. Задержка после подачи CS (выбор СС) и передачей команды SRX? или что имеется ввиду?
Да. Согласно даташиту, после подачи -CS надо дождаться "0" на SDO. Я этого сделать не мог (требовалась особая экономичность), и попробовал тупой задержкой. И - нарвался...
Что не делаю - все равно через несколько часов зависает в опросе GDO0. Все время работы нормальный прием-передача, затем нет ответа GDO0 либо при опросе GDO0 после передачи ответа, либо при опросе GDO0 при ожидании приема данных. На GDO2 при этом продолжается запраграммированная f/128
Привожу протокол обмена:
Прием:
После ожидания импульса с GDO0 (GDO0->1, затем GDO0->0)
1. Чтение кол-ва принятых байт RXBYTES(0х7B) прием 5
2. Чтение 3-х байт данных RXFIFO (0x3F)
3. Чтение LQI (0x73)
Передача:
Перед передачей переход в SIDLE и очистка SFTX. После SFTX пауза 2 мс затем
1. Загрузка 3-х байт в TXFIFO (0x3F)
2. Включение передачи STX (0x35)
Далее по программе ожидание импульса на GDO0 (GDO0->1, затем GDO0->0) окончания передачи
СС1101 менял - толку нет.
Что не так?
Привожу протокол обмена:
Прием:
После ожидания импульса с GDO0 (GDO0->1, затем GDO0->0)
1. Чтение кол-ва принятых байт RXBYTES(0х7B) прием 5
2. Чтение 3-х байт данных RXFIFO (0x3F)
3. Чтение LQI (0x73)
Передача:
Перед передачей переход в SIDLE и очистка SFTX. После SFTX пауза 2 мс затем
1. Загрузка 3-х байт в TXFIFO (0x3F)
2. Включение передачи STX (0x35)
Далее по программе ожидание импульса на GDO0 (GDO0->1, затем GDO0->0) окончания передачи
СС1101 менял - толку нет.
Что не так?
Пробую читать регистры СС после "отключения" GDO - все ОК. В IOCFG0 0x06. Пробую после зависания переинициализировать СС - все равно продолжает не видеть вх. пачек. Кварц не "гуляет", температура тоже не влияет, т.к. пересбросив питание опять несколько часов все ОК. Замаялся уже - не пойму в чем может быть дело? При этом передатчики, работающие наоборот: каждые 20 сек. передают 3 байта и принимают подтверждение работают постоянно и все ОК.
Доброй ночи! У меня проблема таже. Есть две платы с CC1100, которые обмениваются сообщениями. Алгоритм работы следующий: один трансивер передает пакет(~100байт) раз в 3сек, другой приняв пакет, посылает ответ(~20байт). IOCFG0=0x06, на контроллере(Atmega) прерывание по нарастающему фронту(INT0). Работает неплохо, но переодически(через произвольные промежутки времени), у трансивера ожидающего ответ, прерывание срабатывает(т.е. ловит синхрослово), а в RX FIFO пусто(чтение регистра RXBYTES всегда ноль). Конфигурация трансиверов следующая: MSK, 250kbps, 4байта преамбулы и 4байта синхрослова, PQT=4, переменная длина пакета, CRC включен, адреса выключены, autoflush выключен. Кварц с 6-ю знаками после запятой, разница в частоте несущей ~4KHz. Калибровка после перехода из RX TX в IDLE. Errata читал, косяки трансиверов обходил согласно рекомендациям из них. Расстояние между трансиверами 50см, выходная мощность -10dbm, антенны-куски гибкого провода в четверть длины волны.В чем может быть причина приема синхрослова с достаточно хорошей преамбулой и не приема payload???
Всем доброго времени суток. Я тоже столкнулся с такой же проблемой. СС1101 выставляет на GDO0 высокий уровень во время приема и так и остается в этом положении. Прием может быть стабилен сутки, а может и через 10 мин после подачи питания прекратится. Igor_O или anaconda вы решили как то аналогичную проблему?
Проблема решена. В датахе сказано, что GDO0 устанавливается в 1 при обнаружении слова синхронизации и сбрасывается в 0 после приема требуемого количества байт. Если же в условиях плохого приема СС1101 примет только слово синхронизации и больше ничего, то GDO0 так и останется в 1. Для сброса его в 0 я поступил так: перешел в IDLE , очистил приемный буфер и вернулся в режим RX. Может кому то будет полезна эта информация.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.