Сега са около 400, но до 2г. се планира да достигнат 4000 и то за разплод само от тази порода (а там има и още 2-3 други породи и коне), т.е. ще растат още и на всяко животно да има сензори. Кравите се местят на ново пасище, след като изгризат старото. Малкото се отбиват от майката също чрез преместване на друго пасище. Тези местения не мога да ги контролирам и затова трябва да няма колизии дори при хиляди мрежи, работещи едновременно. Та с предаване отместено през секунда и около 80 честотни канала, за 1 час ще могат да предадат без колизиии доста над планирания брой добичета. Явно ще е така... Това ми се вижда най-просто и надеждно.

4000 говада са нищо. Дори да са на 1 канал. Не си усложнявай живота с излишни глупости. Помисли за проблемите около тока и дали не може да зареждаш батерията на устройството безжично. Ако държиш да правиш усложнения.
Помисли и за менажирането на тази мрежа. Какво ще стане ако говедо на канал 3 отиде в стадо с канал 4? Кой ще сменя канали? Кой ще обучава кой контролер на кое стадо кои крави има?
Опрости го максимално. Щом данните не са ти критични в реално време - методи има много. Мастърите броадкастват постоянно на техния си канал. Кравата знае на кой канал е последния мастър и се опитва да му говори 2-3-4-5 пъти на ден. Ако не успее - заспива и се пробва пак след рандом секунди - 1000-10000. Ако не успее няколко пъти да си предаде съобщението пуска сканиране на каналите и търси друг мастър на който да си предаде данните. Така не те интересува кое говедо къде е и т.н. Ще си опростиш живота и ти гарантирам, че не 4000 а 400 000 ще обслужва без проблем. Той нагошиейшъна ще ти е повече време и данни от полезната информация.
По-големия проблем ми се вижда брояча на брой крачки и опашка. Там ще трябва да залегнеш с по-сериозен хардуер ако искаш да си малкоконсумиращ.

Опитвах се да правя нещо подобно за автомобили / датчици в гумите
Задължително е да се сменя времето на излъчване от датчика/говедото
базовата станция слухти - всички други се включват произволно
за пестене на енергия могат да предават само при промяна на някакв параметър
и много по-рядко "жив съм" - на няколко секунди
с една батерийка "панасоник" работеше 5 години / може още да работи - не съм пробвал.../

Не те разбрах, Пифе (може и заради края на работния ден да е ).
Това, което към момента ми се вижда добро е, за всяка мрежа на 2,4GHz, т.е. за всяка крава да се настрои определен канал и определен офсет (да речем секунда или дори по-малко. това ще се уточни по-късно)след кръглия час на предаване:
1 - канал 1, предава в 8:00:00
2 - канал 1, предава в 8:00:01
...
3600 - канал 1, предава в 8:59:59
3601 - канал 2, предава в 8:00:00
и т.н.
Координатора на мрежата за дадена крава и нейните сензори се включват на съответния канал и в зададеното време, обменат натрупаното инфо, сензорите заспиват, а координатора предава данните нататък. Всяка такава мрежа работи независимо от останалите и без взаимно да си пречат - това е целта. Не може сензор от една мрежа да търси някакъв координатор намиращ се наблизо, защото не се знае дали има такъв. Кравите се отглеждат на открито пасище и биха могли да са наблизо една до друга само, ако са се скрили под обща сянка.

Сензорите ще се хранят с литий-тионилхлоридни елементи, а координатора с литиев акумулатор, зареждан от 3 секции монокристални соларни панела.

Крачкомера е лесен - акселерометъра има такава вградена функция при консумация няколко десетки микроампера, а вдигането на опашката е пак от акселерометър, който буди проца, когато ъгъла на дивайса прескочи прага на задействане. Има и жироскоп.

Те това се прави с LORA(Semtech)...
хем покриваш голям участък в звезда(радиус 1 км ти е без проблем за пасбище),
хем координатора ти слуша "целия" диапазон едновременно(SDR), а децата автоматично си сменят каналите(LoraWan)

Лео, по няколко начина се опитваме да ти кажем, че синхронизирането с цел избягване на конфликти е безсмислено. Освен това е и леко забранено от спефикации от рода на FCC.
В случая обаче имаш друга причина за синхронизация, това е че и применик и предавател са ти на батерия. Така че явно ще имаш синхронизация, за да може и двете да спат максимално време.
Да кажем, че координаторът ще си включва приемника за определено време на всеки N милисекунди. В идеалния случай датчиците ще се събуждат в тоя прозорец и ще си изпяват песента. Не помня дали 24L01 можеше да мериш ниво, но RFM-четата могат грубо така че е добре да имплементираш listen before talk. Така, датчикът се събужда, проверява дали ефирът е чист и ако е предава, ако не изчаква. Координаторът също може да следи ефира и да си удължава прозореца.
Конфликтите между твоите мрежи ще са пренебрежимо малко, по-скоро ще имаш изчаквния за чист ефир, които също не би трябвало да са проблем.
Сега, преди детайлите според мен трябва да помислиш за други два ключови въпроса:
1) Как ще си управляваш каналите
2) Как ще се женят датчиците с координатор.
По първия въпрос решението може да го вземаш централизирано, т.е. координаторите като се вържат с кораба майка той да води статистистика и да казва "ти ще слухтиш на еди кой си канал с еди какъв си прозорец".
След подобно препрограмиране или след друг проблем ще се налага нова женитба. По принцип женитбата е трудна работа. Едната страна трябва да се анонсира през определен интервал, а другата да чуе анонса. Не мога да преценя коя страна да предва трябва да се сметнат консумациите, така че сумата им да е минимална. По-сложно е изборът на канал и интервал. Повечето препоръчват случаен принцип пред сходящ алгоритъм, аз нямам опит... Но очевидно е, че да се засекат на една и съща честота по едно и също време не е лесно. Затова може да се опрости задачата. Единият вариант е да има отделен канал само за женитби. Така вместо да се търсите на 80 канала, ще е само един и ще се търси само съвпъдък по време. Друг вариант за ускорение е шерната женитба като примерно всеки координатор да приема и обслужва всякакви анонси. Не знам колко може да си позволиш да ги държиш в режим приемане, но колкото - толкова. Просто от сървъра разпределяш координаторите така че да не се застъпват на анонс канала и да го покриват максимално време. Пък всеки датчик с мерак за женитба, събужда се, проверява ефира и предава с надеждата че все някой ще го чуе. Може и обратното - координаторите да се анонсират, датчика само се събужда, ослушва се малко и ако чуе нещо чуе, ако не пак спинка.

Според мен по-скоро сихронизацията може да определя времето в което няколко приемника слушат - примерно от 8:00 до 8:05 слушат първите 50 крави. В това време мастъра праща заявки за четене, всяка със адрес на съответната крава. След като една крава е прочетена и се изпраща обратно сигнал че е готова, и тя спира да слуша, оглушава до 9:00... Така няма да стои цял час на приемане и да хаби ток. А пък няма да има нужда от супер-точно заделяне на тайм-слотове. Пък и при тази скорост на данните мисля, че за една минута мастъра ще оправи всички крави

Целта е милисекунди включено радио. Няма смисъл от секунди или минути работещо радио.
Слушайте Миро. Човека приказва верни приказки.

40 000 крави. 1 измерване на час. Измерването е температура - 1 байт, номер на устройство 2 байта, крачки, 4 байта, опашка 2 байта. ЦРЦ 2 байта. Начало, край на пакет 3 байта. 14 байта. При скорост 2 мегабита 63 микросекунди полезно предаване на данните. С нагошиейшъна стигнахме до 10 милисекунди. При колизия - още 10. Да кажем 20 милисекунди на крава - 50 крави в секунда ще предават данните си. Ако всяка крава има по 2 колизии прави 180 000 крави на час. От един приемник на една честота. И това е без смяна на канали и други глупости.

Та сметката е проста и не трябва да се усложнява радиото. Сложното ще дойде от крачкомера и опашкомера. Там е проблема според мен. Аз бих сложил и допълнителна екстра за преброяване на кравите при влизането им в обора или на мястото за хранене и доене. Там има смисъл от автоматизация.
Началото на 80-те години по ТКЗСтата сложиха такива компютърни системи за автоматично хранене на кравите и всяка си имаше РФИД ама на мястото и а не на кравата.

Тия радиа харчат около 20mA, а се предполага и малък размер, така че батерията вероятно ще е нещо между 20 и 200mAh. През целия си живот устройството може да си позволи между един и няколко часа общо ефирно време.
Демек ако се включва по 5мин на всеки час устройството ще издържа ден-два... Не е особено практично

Предполагам ще се гони поне 1000 пъти повече. Поне за датчиците това е постижимо. Дрифта им е около 1mS/min. Времето за включване, предване и получаване на квитанция е средно около 5mS, така че изглежда разумно всяка минута да се обаждат. Това прави 5mS/минута или 300mS/час или 7.2 секунди/ден или един час работа ще натрупат за около 500 дена.

@Pif Повечето от кравите са порода Абърдийн Ангъс, за месо и не се доят. Отглеждат се на открити пасища, като само през зимата се хранят допълнително и не се прибират в обори. Издържат на студ и сняг дори новородените телета. Животните от тази порода са направо казано диви - гледка "дядо води крава" е невъзможна. И са скъпи, а като устойчивост на болести май са по-кекави от нашите породи.
Та това налага този проект, който като, че е за "безумни идеи".
Сензора на опашката е най-проблемен като закрепване и може и да отпадне, ако не намеря решение.
Сензора за движение/положение на крака е възможно да изпадне и тук Миро е прав, че трябва да има "женене" на нов сензор при неговото поставяне. Сензора за телесна температура изглежда най-лесен, но да видим...
Предаването от сензорите към техния координатор и после нататък, ще е в 0:00, 8:00, 12:00 и 16:00, съгласувано с краваря и неговия ветеринар, така, че до 8 измервания ще се вместват в едно предаване.

Миро, "Така, датчикът се събужда, проверява дали ефирът е чист и ако е предава, ако не изчаква. Координаторът също може да следи ефира и да си удължава прозореца." Ако няколко сензора са наблизо и на една честота и видят, че ефира е чист и тръгнат да предават едновременно? Същото важи и за координаторите.
Затова искам да ги отместа по честота и време.
nRF24L01 няма RSSI, а само carrier detect.

Да, могат да тръгнат да предават едновременно. Конфликти винаги може да се получат с твои и с чужди устройства. За това е хубаво да пуснеш потвържденията. Хем ще знаеш дали са те чули или не. Щото може и без конфликт пак да не те чуят ако сте се разминали във времето. Когато не те чуят, всяко устройство може да опита пак, но желателно е след случаен интервал, за да не опитат отново по едно и също време. Ако са само твои устройства все трябва да се разбират до няколко опита, ще си напишеш домашното сигурен съм Но хубаво е да следиш и в приемащата страна, демек като видиш че има нещо по ефира, а не се получават читави пакети може да оставиш координатора малко повече време включен от обикновено.

За RSSI виж RFM73... иначе е същия като nRF-a...

Е при тия работих, и са написали 5000+ дивайса, 1000метра
Правят го индистриално за климатизация в сгради, имат си патент как да не си газят трансивърите
Базирано е на Чипкон, сега TI, или така мисля. Но не е проблем да тръгне и на Nordic.

Но няма много детайли...освен ако си купиш развоен кит за 1500Е или решиш да им станеш индустриален клиент

https://www.lumenradio.com/mira/

Координаторът си мисля че няма логика/шанс/нужда да заспива - трябва да слуша през цялото време. Може да се появят нови устройства (за регистрация), а и спането на централата поставя изисквания към нодовете кога да предават - още едно усложнение зорлем.
Ефирът там се очаква да не е мнофо за*ран - все пак е пасище сигурно някъде из планината, така че освен някой ентусиаст дето е пуснал 30Км линк да има, друго си мисля че няма какво.
Това по никакъв начин не изключва необходимостта от потвърждение!
Ако трябва да има "в 8ч, в 12ч..." значи както каза в началото, има си RTC и то се сверява по централата ти? Сверяването може да идва от ack-то като таймстампа на централата "сега е 8ч. 01м и 10сек ... биип" - нода като го получи сравнява че по неговия часовник е било "8ч 01м и 20сек" и си връща часовника. Това е базата на IEEE1588, само че там има още и PLL който цели да премести осцилатора на нодското РТЦ така че на следващия ден такава разлика от 10с да няма. Т.е. ако се сверяват през 4ч и се види разлика 20с значи твоя осцилатор има еди колко си ппм спрямо този на централата и можеш софтуерно да го коригираш. Разбира се температура, захранване и т.н. ще влияят но все пак имаш шанс да намалиш от принципно 100-тина ппм възможен начален офсет до 20-30 примерно. Не че е критично, но е екстра. При IEEE1588 грешката от следването минава през регулатор (PI тип) който си има определени настройки според типа на мрежата и гонените параметри - бързо следване или по-добро филтриране. При теб ако имаш информация за времето на всеки 4ч няма много смисъл от филтриране с регулатор...
От практиката мога да кажа че с такъв подход (PI и корекция), с подходящ хардуер (прецизно може да си мести осцилатора) лесно се стига на под 20ппм джитър, и то включая 10-тина внесени от странични фактори. Но там (индустриален етернет) пак си искат прецизни кварцове.
Ако и при теб има 20ппм значи на 4часа ще имаш 0.3с грешка. Ако остане на примерно 200ппм (100+100 worst case) ще имаш 3с.
Сега, има и опции за по-прецизно - вчера гледах на cnx-software че са пуснали някакво модулче с atmel и lora - там дискутираха че лората искала за високата чувствителност TCXO. Та ако можеш да стъпиш на такова чудо ще получиш даром (е, откъм софтуер де) прецизност. Там мисля че 10ппм не са проблем да се постигнат.
Та ако можеш да разчиташ на 0.3с грешка/прецизност може да се мисли за времеделене на 1с примерно, т.е. активното време би трябвало да може спокойно да падне на нещо като няколко стотин мс. Ти предаваш с точност +/-0.3с и очакваш че до 50-100мс ще дойде ack (дето връща в себе си и "централното" време). Номерът е прецизността да пасне на избрания прозорец за отместване на нодовете.
Да, периодите са големи (4ч примерно) само че колкото по-дълги са периодите, толкова по-широки стават прозорците които можеш да алокираш за всеки нод - това като абсолютно време. Иначе са си все един и същи - като ppm.
Което ни връща на оригиналната ти идея за времеделене и проблема, които спомена Миро - прецизността. Та ако тръгнеш в тази посока моя съвет, или по-скоро извод, е да се застраховаш с добър осцилатор - най-добре TCXO, ако не софтуерно гъделичкане.
За запълването - в този хипотетичен времеви сценарий казахме че говорим за прозорци от 1с за всеки нод. Т.е. за всяка една секунда от времето ще имаш по два пакета - по един във всяка посока. Не знам колко са дълги - да кажем по 1мс? , значи имаш активно време 2мс на 1000мс - имаш 0.2% запълване. Не помня колко е по стандарт - но звучи ок. И по-важното е че е разпределено равномерно във времето. Ако имаш carrier detect ще има едни яки бърстове около времето за предаване - където всички нодове засипват към централата на всеки 4ч. Може и да се източат по-бързо, но точно тогава ще нарушим изискването да не за*ираме ефира?

Edit: то това с TCXO е малко шантаво - има прецизни и евтини на 16МХз / 0.5ppm:
http://eu.mouser.com/ProductDetail/TXC-Corporation/7Q-16000MBG-T/?qs=sGAEpiMZZMt8oz%2fHeiymAH1hIqVoiZCgItlzMRYaTMc%3d
Ама на теб ти трябва за RTC-то, което сигурно е на 32768Хз? Има разни на 5ppm:
http://www.mouser.com/ds/2/371/SiT1566-datasheet-1003143.pdf
Но са скъпи - над 3 евро, и дърпат 4.5мкА. Но 5ппм са си 5ппм - на 4ч са 144мс (10ппм - по 5 за двете страни, т.е. worst case). Това говори за нещо като 200мс джам на нод, т.е. 18000 нода на час.

Edit: абе щях да преложа да смениш чипа - примерно nrf52 - че търся съмишленик да бори тиквите, ама сигурно си здраво завързан за nrf24 и е излишно да те агитирам? Ако си отворен за идеята да пишем за екстрите (BLE, NFC - "удобства за говедовъда"), иначе няма смисъл да си хабим времето и пръстите.
Една зарибявка:
http://www.fanstel.com/bt840e/

Ако се иска по-голяма точност на RTC-то - може да погледнеш DS3231. С вътрешен осцилатор е, температурна корекция и по спецификация му дават максимално отклонение 63 сек на година. Има го на достъпна цена и като модулче с цокълче за батерията, плюс допълнителна памет 24C32 мисля, че беше. Интерфейса му е I2C, и е доста сносно за работа.

То не е толкова проблем абсолютната точност - по-скоро идеята е да има строг синхрон между нодовете и централата. Няма лошо в централата да има точен и сверен по гпс или нтп главен часовник, но по-важното е подчинените в нодовете да вървят достатъчно точно с него.
ДС3231 по тези данни които си дал е 2ppm (ако не бъркам сметките). СиТайм-а дето е на 32КХз има варианти 3ппм или 5ппм, докато на по-високи честоти има модели с по 0.5ппм и надолу.