nRF24L01+ : побеждаем модуль.

Еще раз прошу помощи, как конкретно по пинам подключить
nRF24L01 к Due ? пробовал по описанию от Меги, не выходит...((

 

с Due никогда не работал. Посмотрите по спецификациям сделать сравнение меги и due... не думаю, что там есть какая-то принципиальная разница

 

Синим цветом питание, зеленым данные

 

здравствуйте, подскажите плз запустил скетч из первых постов темы для проверки каналов, вывод в терминал не такой как у автора темы, подскажите где тут номер каналов итп, может кто знает почему вывод не такой (ардуино иде 1.6.5-рс и 1.6.6) плата ардуино мини

А блин понял каналы это первые 2 строчки горизонтальные, а на показания нужно смотреть по вертикали сверху вниз, сори затупил

 

Спасибо, буду пробовать !

 

удалось завести модули вот с этим кодом
https://github.com/TMRh20/RF24/tree/master/examples/GettingStarted_HandlingData
ура но назрела куча вопросов
- удается стабильно получать\принимать данные только при RF24_PA_LOW и RF24_250KBPS если ставлю больше всегда таймаут это может быть из-за чего? питания не хватает? подключены модули к vcc пину ардуино мини про через lm1117 по идее порт по докам должен выдавать достаточно или я не прав? конденсатор стоит 2.2uF 50v такой пойдет же?
- параметры в функции как правильно передавать, они в библиотеке описаны как unit8_tчтоб установить 128 канал правильно писать так radio.setChannel(128); или так radio.setChannel(0x7f); в документации unit8_t задается числом от 0 до 255, но в сканере каналов почему-то хекс значения

 

ух более менее разобрался и заработало, у кого есть опыт правок библиотеки помогите плз
При правке файла либы посторонним редактором а потом в ардуино нажатия выгрузить библиотека перекомпилируется или старая берется? Не выходит внести изменения в библиотеку блин она все время одинаковая на ардуине.
Подскажите как заставить эту либу печатать отладочную информацию,там есть флаг FAILURE_HANDLING который описывается в rf24.h и задается в rf24_config.h но у меня не включилась отладка

По моему там есть баг в функции write тк у меня отправка проходит вполне успешно возвращается ответ от приемника но эта функция возвращает ложь в коде либы нашел паузу в 85 милисекунд ожидания ответа в которые приемник укладывается только если скорость передачи 1мб, а в 250кб по-моему эта цифра должна быть раза в два больше

+ нашел в коде переменную txRxDelay она какраз выставляется в зависимости от частоты процессора и скорости передачи и там те же 85 миллисекунд фигурируют, значит в функциях write нужно просто 85 поменять на эту переменную

Логика ее работы такая
если ардуина 16мгц ставиться 85
иначе 250
дальше если скорость RF24_250KBPS и ардуина 16мгц 85 меняется на 155
если скорость RF24_250KBPS и ардуина не 16мгц скорость меняется с 250 на 450
ну и еще условие для 2мбит скорости

Она так круто высчитывается и потом используется только в одном месте

Помогите в общем кто может поковырять и докопаться до истины

 

Коллеги! Исследование показывает, что есть в модуле такая интересная установка, как:

Код (C++):

radio.setCRCLength(RF24_CRC_16);
// или
radio.setCRCLength(RF24_CRC_8);
// или
radio.setCRCLength(RF24_CRC_DISABLED);

При инициализации о ней забывают (я вообще забыл о ней напрочь!). А она, похоже, у всех модулей разная по умолчанию.
Библиотека:
http://tmrh20.github.io/RF24/annotated.html
Конфигурация при инициализации:

Код (C++):

const uint64_t readingPipe = 0xE8E8F0F0EBLL;
const uint64_t readingPipe = 0xE8E8F0F0EBLL;

  // Setup and configure rf radio
  radio.begin();
  radio.setChannel(0);
  radio.setRetries(15,15);
  radio.setDataRate(RF24_250KBPS);
  radio.setPALevel(RF24_PA_MAX);
  radio.setAutoAck(1);
  radio.setCRCLength(RF24_CRC_16);
  //radio.setCRCLength(RF24_CRC_8);
  // radio.setCRCLength(RF24_CRC_DISABLED);
  radio.openWritingPipe(writingPipe);
  radio.openReadingPipe(1,readingPipe);
  radio.startListening();

ЗАРАБОТАЛАААААААА!!!!! АААААААА!!!!! И заработала, после указания в модулях setCRCLength

Проверьте. Отпишитесь, пожалуйста!

 

Скажите, а есть вариант, вешать устройство на другие пины: ну например у меня на уно свободны 0,1,6,7,12,13. Это вообще реально?

 

Нет. Шина SPI как минимум в значениях MISO, MOSI, SCK - завязана жестко на три пина. Остальные два модно вешать на другие ноги.

 

Так и думал... Но... у меня на 10 и 11 дисплей с которым идет работа через LiquidCristal... Перенести не получается, вероятно, по той же причине... И как их заставить существовать вместе?
Или отдельную нану покупать?

 

Дисплей можно попробовать "потаскать" - должен работать.

 

Если используется версия LiquidCristal для подключения к куче пинов (параллельный интерфейс), то там все легко переносится. Все пины указываются при объявлении экземпляра класса.

Если используется версия LiquidCristal для подключения через SPI (например, через выходной сдвиговый регистр), то он подключается параллельно другим устройствам на шине SPI к двум из трех контактов (если не путаю, MOSI, SCK, ибо на дисплей данные только передаются). главное, чтобы чипселекторы (оно же CS, оно же CSN, оно же SS) были разнесены по разным пинам (когда-то таким баловался, пока не "переехал" на мегу, работало).

 

в библиотеке rf24 от maniacbug прописана
setCRCLength( RF24_CRC_16 ) ;

 

Здравствуйте.
Сразу хочу поблагодарить Игоря К и всех участников за нелегкий труд и отличные результаты.

Про SPI и несколько устройств
Некоторые устройства вытягивают MISO вверх жестко. Настолько, что не получается просадить ее.
Например, этим грешат SD-карточки. Получается ситуация, что SD-карта отработала, CSN||SS отключили ее. Но SD-карта продолжает тянуть MISO вверх. Включаю другое устройство, оно ждет MISO=0, чтобы начать обмен, а фиг там.
Думаю, это связано с крутой подтяжкой шин к VCC в SD-картах и подобных вредителях. Видать, сопротивление впаяли 102 вместо 103 или 104, например.
Как лечить? Поставить подтяжку к GND и перетянуть MISO вниз на холостом ходу (возможно). Диод также поможет, желательно, с малым падением напряжения.

Про 250KBPS и Scanner от tmrh20
Модули китайские "+".
Прием-передача нормально: 250KBPS 1MBPS 2MBPS.
Сканер от tmrh20: только 1MBPS 2MBPS.

250KBPS - сканер не работает, по всем частотам 0.
1MBPS или 2MBPS - сканирует нормально, ловит мышку, пульт от вертолета, вай-фай и прочее.
Код инициализации полный, из последних сообщений. Игрался параметрами (мощность, CRC и т.д.) - не помогает. Вот так!

 

Прослушка 6 труб
Интересная заметка "Avoiding RX Pipe 0 For Enhanced Reliability"
http://maniacalbits.blogspot.ru/2013/04/rf24-avoiding-rx-pipe-0-for-enhanced.html
Автор советует не использовать pipe0 для чтения, т.е. не делать radio.openReadingPipe(0, pipeAddr);
(насколько я понял).

Я написал код для 5 труб. База слушает трубы 1..5. Датчиков 5 штук, каждый отправляет данные в свою трубу.
База нормально принимает, но ACK(acknowledge подтверждение) возвращается в датчик в странном виде: "1893882" вместо "201", "2888732" вместо "202". Примерно так. Буду разбираться.

 

Нулевая труба - она по умолчанию открываются для передачи. Слушать можно и ее, но только в том случае, если "слушатель" ничего никогда не будет передавать. Иначе все запутается.
Собственно, это и указано в последнем абзаце заметки.

 

В данный момент у меня подозрения, что подтверждение передачи (ACK from RX to TX) === передача от слушателя. Поэтому нулевую область нельзя слушать. Вызов openReadingPipe(0, addr) сломает отправку подтверждений о получении.

 

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

 

И еще про writeAckPayload
http://tmrh20.github.io/RF24/classRF24.html#a65619238c25036c3de72dc2c1a1c6e52

Если слушаем много труб, то заранее записать подтверждения в буферы можно только для 3х труб. Поскольку буферов всего 3 штуки.
Получается:

Код (C++):

radio.writeAckPayload(1
radio.writeAckPayload(2
radio.writeAckPayload(3 //уже нельзя, 3 буфера заняты
radio.writeAckPayload(4
radio.writeAckPayload(5 //уже нельзя, 3 буфера заняты
 
if (radio.available(&currPipeNum)) {
    radio.read
}

И еще должен быть включен enableDynamicPayloads(), чтобы работал метод writeAckPayload
То есть, setPayloadSize(32) нельзя использовать(?)