I've been testing nRF's months ago but I forgot almost everything because I didn't
really used them for a project back then, so right now I want to use them in my project
I got the basics how to set up pins, simple testing code and changing channels.
I want to create a circuit which I'll be able to change the channels with some programmed
jumper pins and a 2 way data communication. In theory I got everything perfectly done but
in code it's a bit time consuming to read everything about nRF24 library.
My 1st testing came from that 2 online threads/topic:
It's not really hard to understand a simple code but I've seen more advantage coding which I'd like to
study and use if needed, I've seen people can set data speed MB,KB, weight of a package ..etc
but the most important that I'd like to know is how to make the nRF as transceiver, I got simple examples how to just transmit but how do I transceive? and another important thing is I'm sure I'm able to do that but how do I set a array of bits in the beginning of each package so I would be able to
simple encrypt and receive only packages from a exact module. Actually that's not really necessary I can think a way to do that in code.
The pair of attached programs are a simplified version of a model railway control system. It uses writeAckPayload() to allow the slave to send data back to the master as part of the acknowledgement process. This means there is no need for the master and slave to switch roles.
TrackControl is the master and HandControl is the slave.
Note the comments in the code about a small change to the RF24 library.
So you set the Master as transmitter and slave as receiver
as we know the setup runs only once so you set the data rate, open pipe and enableAckPayload which
i unserstand makes it as transmitter so you make for the receiver the same but to receive data, the trick
to transcive is in the loop, you create a if to work with millis and you make the transmiter as receiver for
few second.
I'm I right ?
As i saw you set to transmit only few characters, in my project I got to transmit more than
10 chars per array is that possible and what will be the max package array i can send?
Domino60:
and you make the transmiter as receiver for few second.
Not really. As part of the normal transmission the sender expects an acknowledgement and the listener sends that accknowledgement automatically without any code that I need to write. If I create an ackPayload that will automatically be sent as part of the acknowledgement process.
As i saw you set to transmit only few characters, in my project I got to transmit more than
10 chars per array is that possible and what will be the max package array i can send?
10 chars would be no problem - just make the array big enough. I think the max in a single packet is 32 bytes - but you should check the nRF24 datasheet.
The datasheet is not the easiest of documents to assimilate but after you read it 10 or 15 times it begins to make sense. It is a very clever system with a lot of work going on in the background to make life easy for the user.
I got a project that would be nice to receive data from the receiver to see the actual status/data of the
device but I need to transmit a lot of data as well so I'm not sure if will be possible to make a real time
transceiver communication without big delays and errors.
For example I want to transmit the status of 8 switches, 4 buttons and 4 pots that will be about ~25bytes
which need to be stored in separated array by id. On the other side[receiver] I got many sensors and I got
about ~100bytes of data which i need to store in a array of 10 separated id's
(id of array I mean the actual number a array get's behind the stored data ex. 1.hello 2.world 3.etc)
While I'll transmit the data from the receiver to transmitter I want to print them on a oled.
to be honest I'm not sure if it's possible to transmit all that data without big delays.
Now I'd like a answer, should I make my life complicated with the above example or should i keep it simple
and just store the sensor data on a sd card? because sending all that data from the sensor will be just for the user to see the live status of the device and nothing more.
If you just want to display the status of the device, you do not need any acknowledges,
as the device does not need to know whether the display received the data.
Just send the data as often as you like via W_TX_PAYLOAD_NOACK to a predefined pipe address
(it would be a good idea to send the data quite infrequently and add extra sends on changes...).
That is the fastest way to send data (no receive mode involved) and I doubt that collisions will be a problem.
Domino60:
For example I want to transmit the status of 8 switches, 4 buttons and 4 pots that will be about ~25bytes
which need to be stored in separated array by id. On the other side[receiver] I got many sensors and I got
about ~100bytes of data which i need to store in a array of 10 separated id's
I find this confusing.
Do you mean you want to send 25 bytes in one direction and send 100 bytes in the other direction?
Or do you just mean that, after sending 25 bytes the receiver has work to do which might interfere with a quick acknowledgment.
Or something else?
Either situation is easy to deal with.
If it was my project I would break the data transfer into chunks so that I could control what is happening. For example a transmitted message might include a code that identifies what should be sent next. Or the "reply" could include a code that identifies the contents.
To use ackPayload the payload should be in place BEFORE the message is received - so it could be the data requested in the previous message.
And, of course, what @Whandall said if it is just one-way communication.
Transmitter:
I have many switches, buttons, pots and I need to control something in the other end
real time no delays and no mistakes should be made a few seconds delay that will be a
huge problem.
Receiver:
Receiver will receive from the transmitter the data from the switches, buttons, pots in the
way to control what It should control, the receiver will have several sensors which I'd like
to transmit to the transmitter and user will be able to see the live status of the device
(what is going on ..etc).
Personally I think it would be great to make it just one way communication because
I want to have a real time no delay communication, I don't know how many affect the communication
if i send a lot of data, 2nd reason is that I need a big range communication so I'll set my nRF at 250Kb,
at this point if i lose communication or get a big delay of the transmitted data will be a huge problem
for me.
Domino60:
Transmitter:
I have many switches, .....
Receiver:
.... the receiver will have several sensors which I'd like to transmit to the transmitter
Going back to the questions in Reply #7, does that mean you want to send 25 bytes one way and 100 bytes the other way ?
Specific answers make it much easier to help you.
And some more pertinent questions
Would it be sufficient to send the switch/button/pot data 10 times per second?
Tell us more about the type and quantity of data that needs to be sent back.
If it is just to update a user display an update rate of once per second may be sufficient. That would allow plenty of time to send part of the 100 bytes in the acknowledgement of each of the switch messages.
Going back to the questions in Reply #7, does that mean you want to send 25 bytes one way and 100 bytes the other way ?
Well that depends on how many things I'd like to transmit so let's say yes (maybe i'll add more I don't know yet but will be something like that).
Would it be sufficient to send the switch/button/pot data 10 times per second?
The pots of curse at least 5 times per second without missing packages because I'll control something
real time, about the switches and button send them only if status have been changed of send them as
well once per second.
Tell us more about the type and quantity of data that needs to be sent back.
The data I'll send it more like, gps(lat,lon), compas, temp, humidity and few other sensors a total side
of approx. 100bytes of less. I want to store them in the way to know which one is which and send individual
packages for each one, knowing that it's not important a real time read of them so I can send them once per second or more.
The important part of the project is the transmitter I need to send data without losing packages.
Robin2:
If it is just to update a user display an update rate of once per second may be sufficient. That would allow plenty of time to send part of the 100 bytes in the acknowledgement of each of the switch messages.
I see a message rate of around 1000 packets per second with my unoptimized testcode.
(I'm in the process of finishing an interrupt driven/nonblocking NRF24 library
(interface overhaul, check for missing/superfluous functionality, examples, ...))
Domino60:
The important part of the project is the transmitter I need to send data without losing packages.
The transmitter does not loose packets.
Packets can be lost due to many reasons (collission, channel overload, slow receivers...).
What should the transmitter do, if it detects a failure?
Probably it should send the information again, shouldn't it?
Just keep on transmitting (mostly the same stuff) over and over,
the receiver updates its lokal data by incomming packets.
When some are lost, the update will be delayed a little.
With the fact, that your data has parts of different age, you have to live anyway.
Domino60:
The important part of the project is the transmitter I need to send data without losing packages.
The code I gave you in Reply #1 will do that. Try it. Extend it to meet your needs.
But, and this is important, don't close your mind to quirky ways to meet your needs that help to make the programming easier - such as breaking up the long data into smaller packages that can fit into an ackPayload.
It can often be easier to send data in a standard format even though the value has not changed. That can reduce the confusion for the device receiving the data.
I want to store them in the way to know which one is which
Just include an identifying character with each item - for example C:xxx could be a compass reading.
I think I will skip the part of transmitting sensor data, I should not make my life complicated, It's a nice idea,
I don't give up, maybe I'll try it in the future but right now I got many things to combine so I'll just store
the data on a sd card and read the data after i get the device.
I'll make just a one way communication.
At the receiver side i got many sensors which are on different atmegas so I need to work with I2C
and use the sensor data as well for the device..etc It's a lot of work.
I'll use the code you gave me as an example of communication if I'll have time I'll run some tests on 2 way com. If I'll get some questions I'll be back for sure.
