Need to send data like {0x01, 0x00, 0x00, 0x00} or 0000000100000000000000000000000 using NRF24L01+ and process it on receiver side. How do I achieve it ? I'm using STM32 G030C6T6 IC. Please help I'm a newbie. Thank you

[GSaw]

I'm using https://github.com/elmot/nrf24l01-lib library for communication. For now I' able to send strings like "helloworld" and process them.

[Harvey White]

I've done packets and mesh networking with the NRF chip.

Since you don't mention if you're in a mesh network or linked 1:1, I'll assume 1:1 (it's easier).

If all you're doing is sending a 32 byte (or less) data stream, and nothing is greater than 32 bytes, and never will be, then the entire 32 bytes of a shockburst packet is available.

It can be sent, then the reply goes back to the originator (since there's only one).

If you can get data from more than one place, or send it to more than one place, or send more than one packet, or want checksums, then your "packet" of information has less space for your data and more routing information.

Short and simplest answer is hardcode destination and source addresses, and use shockburst mode at (IIRC) 1 MBPS.

[GSaw]

For now I'm trying to achieve 1:1 network but wish to implement mesh network in future.

I'm able to successfully transmit and receive data (a response in case of source device and received data in case of destination device) which is uint8_t "helloworld" (I call it string).

What I desire to transmit is uint8_t arr[4] = {0x00, 0x01, 0x00, 0x00}; (hex array) and receive the same on destination device and then process it.

Please guide me in this case.

Thank you

[Harvey White]

You need to look at how the string (helloworld) is actually given to the NRF chip. The NRF chip can transmit binary if it's fed binary.

You have the chips talking to each other, so it's just a matter of following the path the data takes when the transmit buffer is loaded.

[Harvey White]

As an addition, this is the routine you should look for, if not by name, then by function:

// ****************************************************************************************************************************************************
// ************************************************************* START FAST WRITE *********************************************************************
// ****************************************************************************************************************************************************
 
// WRITE PAYLOAD AND THEN SET ce TO TRUE
//Per the documentation, we want to set PTX Mode when not listening. Then all we do is write data and set CE high
//In this mode, if we can keep the FIFO buffers loaded, packets will transmit immediately (no 130us delay)
//Otherwise we enter Standby-II mode, which is still faster than standby mode
//Also, we remove the need to keep writing the config register over and over and delaying for 150 us each time if sending a stream of data
 
void RF24::startFastWrite(void* buf, uint8_t len, bool multicast,
		bool startTx)
{ //TMRh20
 
	//write_payload( buf,len);
	if (debug_level >= 1)printf("RF24::writing payload\n");
	write_payload(buf, len, multicast ? W_TX_PAYLOAD_NO_ACK : W_TX_PAYLOAD);
	if (startTx)
	{
		ce(true);
	}
	hal_timer[_US_TIMER]->Delay_us(_US_TIMER,40);
#ifdef NRF_REG_DEBUG
	nrf_diagnostics.reg_full_dump();
#endif
}
 

Note the following:

1) this is written for my system as I use it, don't expect code to be 1 for 1 since I did a bit of re-engineering on the code.

2) This is now a class in C++ and not a C routine, you still have a C routine

3) there is nothing that says that what gets loaded into a buffer is not binary data, the chip sends what you want.

All you really have to do is change what's loaded into the chip.

[GSaw]

@Harvey White​ thanks for this :smiling_face_with_halo: I'll try it out been stuck on this for a long time