ook/ask communication

[Tom1234]

I would like to use an ook or ask protocol to communicate different sensors. Every sensor is needed to send  it ID and a 0 or 1  to main panel.

I think the most easy and cost effective way is to use the ook or ask protocol. Also i would need a reliable ook /ask transmitter and receiver .
 I would need your opinion.   

[Parmin]

Use manchester coding for this kind of communication.
Start with a balanced byte for preamble (eg 01010101 or 10101010)
Use parity checking.

[Tom1234]

Firstly what component to use? have you got any suggestion?

[metal]

vicious way, indeed.

tell us what you want to do first

[Langley]

Advanced transceivers like the NRF24L01+ including packet engine w/ CRC checking, addressing, auto retries, etc for <$1 in a nice module on eBay/AliExpress, or for longer range, the 868/915MHz RFM69 xceiver modules for ~$3, make it hard to justify the poor performance of OOK/ASK in any but the most cost sensitive consumer applications.
Further, the very nice libraries available for Arduino, Mbed, etc make these complex devices very easy to set up and use. I’ve had great success using both these xceivers.

[Tom1234]

I would like to create a project in which in a large building there are sensors which they calculate the temperature. If the temperature exceed a specific value then the sensor it will transmit its ID and value 1 (the value 0 mean than the temperature is not exceed). All these sensors they will transmit its ID and values to a central panel.
I am looking for something low cost and as reliable as possible.

[metal]

You are doing a paper, I presume...
NRF24L01+ will not work, even if it is long range, unless you manage to create an algorithm that allows multiple NRF24L01+ to use the same air slots.. you need to find a platform to start with, google and come back here with the findings so we discuss in more details.

[Parmin]

NRF24 can work with 5 nodes simultaneously.
And each node can be programmed to relay info from previous node to forward to the third tier node.

[metal]

this is what I call PITA :- )

[Gallymimu]

You are doing a paper, I presume...
NRF24L01+ will not work, even if it is long range, unless you manage to create an algorithm that allows multiple NRF24L01+ to use the same air slots.. you need to find a platform to start with, google and come back here with the findings so we discuss in more details.

With how little data he needs to send he could simply rely upon low duty cycle statistically random time slotting to insure high likelihood that transmitters won't step on each other.   If the transmitters require an ACK this becomes even easier.

Example 1000 sensors ping once an hour with a maximum time slot of 10ms.  If they don't get an ACK they retry every 10 minutes with a random time delay of =/- 0 to 100 sec which should equate to 1/10000 time slots IF the sensors happen to start transmitting at the exact same time in the first place.  That is easy to program, still pretty low power, and should be reasonably robust.

That said, using a BLE module is awfully easy!

LORA might be a cool option as well depending on the needed range.  2.4GHz won't go that far in a building.

[metal]

yes, I agree, BLE is the way to go.. look at nordic soltuions

[Tom1234]

What i am thinking is the case that a sensor is far away from the central unit which should communicate. What is the range of the use of BLE?
So the use of BLE in the building it will be a better option that the use of an ook/ask?(i speak in the terms of range and reliability)