Development branch - RF24Network::write() incorrectly returns false

[nrf24]

Development branch - RF24Network::write() incorrectly returns false

[spaniakos]

I am using and trying to support intel galileo.
Can u tell me, does the helloworld_rx and _tx world properly ? I think is
the best sketch to check it. Also do you have communication in both ways ?
On Dec 2, 2014 8:24 AM, "prophet-roshak" [email protected] wrote:

Hi!
I'm using RF24Network (Dev branch, to check out fragmenting) on top of
RF24 master branch. My devices are Arduino compatible DevDuino sensor node
and Intel Galileo (on top of MRAA). I do not use Arduino IDE, so all libs
is compiled and linked along with main code.

While sending a data structure of 12 bytes length, from child node to
master, RF24Network::write() always gives me false, however master recieves
and parses actual data.

When I switch to master branch of RF24Network for both nodes - everything
seems to be working fine.

Can you confirm that there is a use case when RF24Network::write() returns
true, while sending short 1 frame unfragmented packets? e.g. should I go
deeper in serial/console debugging, or this is a known bug and there is a
workaround? :)

—
Reply to this email directly or view it on GitHub
#32.

[prophet-roshak]

Well, I've started with plain rx - tx examples, and it works fine.

I do have data transfers both ways when using RF24Network version from master branch. I also have actual data on my reciever node when I use RF24Network Development branch. But transmitter exits network.write() always returning false, while actual data is transmitted and correctly recieved. Maybe there is some ACK mechanic (away from nRF24 Enhanced ShockBurst) that reciever should do on program logic level to give transmitter acknolwedgement?

here is code sample which gives me wrong result on dev branch:

if (!jobExecuted)
{
    ledBlink(9, 1, 1000); // Long blink 1 time

    SensorData data;
    data.temp = dht.readTemperature();
    data.humidity = dht.readHumidity();
    data.vcc = readVcc();

    RF24NetworkHeader header(/*to node*/ 00, /*type*/ 'D' /*Data*/);

    if (network.write(header,&data,sizeof(SensorData)))
    {
        ledBlink(9, 1, 200); // Short blink 1 time
        sendErrors = 0;
    }
    else
    {
        ledBlink(9, 3, 200); // Short blink 3 times
        sendErrors++;
    }
    jobExecuted = true;
}

SensorData is struct of 2 floats and 1 long. This code always increases sendErrors, no matter that actual data was recieved by master node.

[spaniakos]

I use mine with no problem at all.
I have tested the library with the simple rx tx, and with many variables in
the structure, 2 char arrays, 2 unsigned long, and a large char array for
md5 digest i am developing.

I have tested it with galileo using IDE, and rasberry pi, and it workes
fine. When i have a similar problem like yours it was caused from wrong pin
selection, thus the rasberry could not send the ack packet.
On Dec 2, 2014 12:19 PM, "prophet-roshak" [email protected] wrote:

Reopened #32 #32.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[TMRh20]

Hmm, I'm not able to recreate the issue myself.
What is the RF24Network address of the sending node?
If you modify the data structure in helloworld_tx and helloworld_rx sketches to send two floats and a long, can you recreate the issue?
If you can't recreate it using the helloworld examples, it would have to be something specific to your code, and we would need to see all of it to tell you waht that is.

[prophet-roshak]

So you use code from Development branch, and ::write() calls returns you correct transfer status?
I will try ping from Galileo to my Arduino node this evening, but I'm pretty sure that I'm missing some acknolwedgement sequence, which should be done on network layer...

There is code if RF24Network.cpp at line 659, which seems to wait for an ack after successful outbound transfer for packets with type > 64 and < 192 (I use packet type 'D' which is 68), but I cant find code which generates NETWORK_ACK packets in RF24Network::Update() function.

if( ok && conversion.send_node != to_node && (directTo==0 || directTo==3) && frame_buffer[6] > 64 && frame_buffer[6] < 192){
        uint32_t reply_time = millis(); 
        while( update() != NETWORK_ACK){
            if(millis() - reply_time > routeTimeout){  
                IF_SERIAL_DEBUG_ROUTING( printf_P(PSTR("%lu: MAC Network ACK fail from 0%o via 0%o on pipe %x\n\r"),millis(),to_node,conversion.send_node,conversion.send_pipe); );             
                ok=0;
                break;                  
            }
        }       
    }

I will try sending data with unacknolwedgable paket type when I come home to check if this is my problem.

[TMRh20]

The code you are looking at only engages if the payload is being routed over 1 or more nodes, part of why I asked for the RF24Network address of the sending node.
If yes, the delivering node (intermediary) manually sends back a network-ack.
If no, the radios use built-in auto-ack (ESB) for acknowledgement.
The network-ack is sent from the same code block, line 646 if required.

[prophet-roshak]

Thanks for clarification, I was too fast to post a comment, just before
reading your answer, sorry.

I'm sending directly from address 02 to address 00, so, basically, no ack
other than radio's hardware ack should be required.

To check that hardware part is working, i switched back to ack'less code
from master, which starts to work just as required.

I'll check all the suggestions as soon ad i'll get to my hardware :-)

[prophet-roshak]

I've got a follow up
I've made a simple pinging (out of Network_ping) example, that uses Galileo as ping sender, and Arduino to return back ping. I've found out, that i have around 300ms roundtrip time, and Galileo always gets "false" from RF24Network::write function.

Digging code in debugger, I've found that "RF24Network::write_to_pipe" function always returns false, as radio.txStandBy(txTimeout) actually times out.

Here's output of radio.printDetails after network.begin(radio):

cpufrequency is 399.076 mhz
nanoseconds per clock 2.50579
STATUS           = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xccccccccc3 0xcccccccc3c
RX_ADDR_P2-5     = 0x33 0xce 0x3e 0xe3
TX_ADDR          = 0xcccccc33e3
RX_PW_P0-6       = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA            = 0x3f
EN_RXADDR        = 0x3f
RF_CH            = 0x64
RF_SETUP         = 0x07
CONFIG           = 0x0f
DYNPD/FEATURE    = 0x3f 0x05
Data Rate        = 1MBPS
Model            = nRF24L01+
CRC Length       = 16 bits
PA Power         = PA_MAX

I've tried to debug RF24::txStandBy, and found out that in my environment TX_EMPTY in FIFO_STATUS register never gets to 1, until tx_flush() is executed. I'll browse the datasheet to check what makes my nRF24 part to handle this way.

[spaniakos]

I use galileo as ping sender as well , but i have no problem .... Will
check it as well
On Dec 2, 2014 9:16 PM, "Anton" [email protected] wrote:

I've got a follow up
I've made a simple pinging (out of Network_ping) example, that uses
Galileo as ping sender, and Arduino to return back ping. I've found out,
that i have around 300ms roundtrip time, and Galileo always gets "false"
from RF24Network::write function.

Digging code in debugger, I've found that "RF24Network::write_to_pipe"
function always returns false, as radio.txStandBy(txTimeout) actually times
out.

Here's output of radio.printDetails after network.begin(radio):

cpufrequency is 399.076 mhz
nanoseconds per clock 2.50579
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xccccccccc3 0xcccccccc3c
RX_ADDR_P2-5 = 0x33 0xce 0x3e 0xe3
TX_ADDR = 0xcccccc33e3
RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA = 0x3f
EN_RXADDR = 0x3f
RF_CH = 0x64
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x05
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX

I've tried to debug RF24::txStandBy, and found out that in my environment
TX_EMPTY in FIFO_STATUS register never gets to 1, until tx_flush() is
executed. I'll browse the datasheet to check what makes my nRF24 part to
handle this way.

—
Reply to this email directly or view it on GitHub.

[TMRh20]

Almost sounds like your CE pin isn't connected properly, or not working, as a HIGH state on the CE pin is what tells the radio to begin transmitting (and empty the tx FIFO).

[prophet-roshak]

Well, if that was the case, no transmission should occur, isn't it? But I'm clearly seeing that my reciever gets data, decodes it, and sends it back to requesting node.

Should the radio clear tx FIFO only after recieving auto ACK, or just after sending packet? Maybe there is some problem with sending/recieving hw ACK packet? It looks like enabled from start... Could it be switched off somewhere later?

There is a statement in datasheet
It is important never to keep the nRF24L01+ in TX mode for more than 4ms at a time. If the Enhanced ShockBurst™ features are enabled, nRF24L01+ is never in TX mode longer than 4ms.

I currently use slow GPIO pin on my Galileo, it gives On-Off time around 4ms, could it be that nRF24 on this part never gets into RX mode to recive autoack? Or it is engaged regardless of CE pin state?

[spaniakos]

I could check the time to add some .ore delay to galileo, but i use the
code for many days now with out any single problem with the current
settings ....
On Dec 3, 2014 9:02 AM, "Anton Sabadash" [email protected] wrote:

Well, if that was the case, no transmission should occur, isn't it? But
I'm clearly seeing that my reciever gets data, decodes it, and sends it
back to requesting node.

Should the radio clear tx FIFO only after recieving auto ACK, or just
after sending packet? Maybe there is some problem with sending/recieving hw
ACK packet? It looks like enabled from start... Could it be switched off
somewhere later?

There is a statement in datasheet
It is important never to keep the nRF24L01+ in TX mode for more than 4ms
at a time. If the Enhanced ShockBurst™ features are enabled, nRF24L01+ is
never in TX mode longer than 4ms.

I currently use slow GPIO pin on my Galileo, it gives On-Off time around
4ms, could it be that nRF24 on this part never gets into RX mode to recive
autoack? Or it is engaged regardless of CE pin state?

—
Reply to this email directly or view it on GitHub
#32 (comment).

[TMRh20]

Yeah, the radio should only clear tx FIFO after success (ack received, or when complete if autoack=0)

I'm kind of stumped, since it seems to work fine for spaniakos, but 4ms times on the GPIO might be part of the problem.

The main difference between the master branch and dev in this case seems to be that in master, stopListening() is called slightly sooner. Could you maybe try with fast GPIO, or adding a delay(200); or so after stopListening() is called and again after radio.txStandBy() to test this.

Other than that, dev does do things a bit differently, using dynamic payloads, multicast etc. so is a bit more demanding on the radios. Are you familiar with the information here? and have you tried some of these options on the Arduino and/or Galileo?

[prophet-roshak]

to Spaniakos: Which Galileo board you are using? I have Galileo Gen 1 - Rev D. Also, if it's Rev D, what pins do you configure as CE and CSN?

to TMRh20: I'll try fast GPIO today to check if 4ms is the problem. Also, I'll try falling back to basic RF24 GettingStarted example to check if there is same problem. I've done the tests with it before I upgraded to RF24Network, and all seemed to be just fine (eg pings were sent, detected as sent OK, and answered in required manner).

I've read that info on my first tryes with RF24 lib, but finally found that I missconnected CE and CSN on Gallileo part. After fixing wires - tests gone smoothly as they should. My radio module is factory connected on Arduino-compatible side, but on Galileo side it is breadboard alike, so if the simple example won't work I'll check into power supply issues... /* thinking of getting oscilloscope 3rd time this week */

[spaniakos]

I dont know about revision . I will check in a couple of hours.
I think all revisions have the same pins and are compatible with arduino.
I a using pins 9,10.
On Dec 3, 2014 10:21 AM, "Anton Sabadash" [email protected] wrote:

to Spaniakos: Which Galileo board are you using? I have Galileo Gen 1 -
Rev D. Also, if it's Rev D, what pins do you configure as CE and CSN?

to TMRh20: I'll try fast GPIO today to check if 4ms is the problem. Also,
I'll try falling back to basic RF24 GettingStarted example to check if
there is same problem. I've done the tests with it before I upgraded to
RF24Network, and all seemed to be just fine (eg pings were sent, detected
as sent OK, and answered in required manner).

I've read that info on my first tryes with RF24 lib, but finally found
that I missconnected CE and CSN on Gallileo part. After fixing wires -
tests gone smoothly as they should. My radio module is factory connected on
Arduino-compatible side, but on Galileo side it is breadboard alike, so if
the simple example won't work I'll check into power supply issues... /*
thinking of getting oscilloscope 3rd time this week */

—
Reply to this email directly or view it on GitHub
#32 (comment).

[spaniakos]

Also, try both boards as tx and rx to see if the signals are being send
correctly
On Dec 3, 2014 10:38 AM, "spaniakos" [email protected] wrote:

I dont know about revision . I will check in a couple of hours.
I think all revisions have the same pins and are compatible with arduino.
I a using pins 9,10.
On Dec 3, 2014 10:21 AM, "Anton Sabadash" [email protected]
wrote:

to Spaniakos: Which Galileo board are you using? I have Galileo Gen 1 -
Rev D. Also, if it's Rev D, what pins do you configure as CE and CSN?

to TMRh20: I'll try fast GPIO today to check if 4ms is the problem. Also,
I'll try falling back to basic RF24 GettingStarted example to check if
there is same problem. I've done the tests with it before I upgraded to
RF24Network, and all seemed to be just fine (eg pings were sent, detected
as sent OK, and answered in required manner).

I've read that info on my first tryes with RF24 lib, but finally found
that I missconnected CE and CSN on Gallileo part. After fixing wires -
tests gone smoothly as they should. My radio module is factory connected on
Arduino-compatible side, but on Galileo side it is breadboard alike, so if
the simple example won't work I'll check into power supply issues... /*
thinking of getting oscilloscope 3rd time this week */

—
Reply to this email directly or view it on GitHub
#32 (comment).

[prophet-roshak]

Hi!
Gen 2 - Rev H, has a full sized usb port on board, that's the main easy to
see difference from Gen 1. They also connected 12 GPIOs directly to SOC,
which was via Cypress I2C chip on 1st gen device.

In my current app, Galileo sends pings and gets answers from Arduino (this
is ok). Arduino sends sensor data to Galileo (this also ok). What is not ok

• is that I can not reliably determine if transmission was success on
  senders side.

If you use gen 2 galileo - that means that you have IO speed up to 477 kHz
or 2 us, that is why everything was perfect...

2014-12-03 12:39 GMT+03:00 Georgios Spanos [email protected]:

Also, try both boards as tx and rx to see if the signals are being send
correctly
On Dec 3, 2014 10:38 AM, "spaniakos" [email protected] wrote:

I dont know about revision . I will check in a couple of hours.
I think all revisions have the same pins and are compatible with
arduino.
I a using pins 9,10.
On Dec 3, 2014 10:21 AM, "Anton Sabadash" [email protected]
wrote:

to Spaniakos: Which Galileo board are you using? I have Galileo Gen 1 -
Rev D. Also, if it's Rev D, what pins do you configure as CE and CSN?

to TMRh20: I'll try fast GPIO today to check if 4ms is the problem.
Also,
I'll try falling back to basic RF24 GettingStarted example to check if
there is same problem. I've done the tests with it before I upgraded to
RF24Network, and all seemed to be just fine (eg pings were sent,
detected
as sent OK, and answered in required manner).

I've read that info on my first tryes with RF24 lib, but finally found
that I missconnected CE and CSN on Gallileo part. After fixing wires -
tests gone smoothly as they should. My radio module is factory
connected on
Arduino-compatible side, but on Galileo side it is breadboard alike, so
if
the simple example won't work I'll check into power supply issues... /*
thinking of getting oscilloscope 3rd time this week */

—
Reply to this email directly or view it on GitHub
#32 (comment).

—
Reply to this email directly or view it on GitHub
#32 (comment).

С уважением,
Антон Сабадаш.

[spaniakos]

Nop i have gen1 , just dont know about revision.
Cab u post a sketch that is producing the problem ?
On Dec 3, 2014 11:03 AM, "Anton Sabadash" [email protected] wrote:

Hi!
Gen 2 - Rev H, has a full sized usb port on board, that's the main easy to
see difference from Gen 1. They also connected 12 GPIOs directly to SOC,
which was via Cypress I2C chip on 1st gen device.

In my current app, Galileo sends pings and gets answers from Arduino (this
is ok). Arduino sends sensor data to Galileo (this also ok). What is not
ok

• is that I can not reliably determine if transmission was success on
  senders side.

If you use gen 2 galileo - that means that you have IO speed up to 477 kHz
or 2 us, that is why everything was perfect...

2014-12-03 12:39 GMT+03:00 Georgios Spanos [email protected]:

Also, try both boards as tx and rx to see if the signals are being send
correctly
On Dec 3, 2014 10:38 AM, "spaniakos" [email protected] wrote:

I dont know about revision . I will check in a couple of hours.
I think all revisions have the same pins and are compatible with
arduino.
I a using pins 9,10.
On Dec 3, 2014 10:21 AM, "Anton Sabadash" [email protected]
wrote:

to Spaniakos: Which Galileo board are you using? I have Galileo Gen 1

Rev D. Also, if it's Rev D, what pins do you configure as CE and CSN?

to TMRh20: I'll try fast GPIO today to check if 4ms is the problem.
Also,
I'll try falling back to basic RF24 GettingStarted example to check
if
there is same problem. I've done the tests with it before I upgraded
to
RF24Network, and all seemed to be just fine (eg pings were sent,
detected
as sent OK, and answered in required manner).

I've read that info on my first tryes with RF24 lib, but finally
found

that I missconnected CE and CSN on Gallileo part. After fixing wires

tests gone smoothly as they should. My radio module is factory
connected on
Arduino-compatible side, but on Galileo side it is breadboard alike,
so
if
the simple example won't work I'll check into power supply issues...
/*
thinking of getting oscilloscope 3rd time this week */

—
Reply to this email directly or view it on GitHub
<
https://github.com/TMRh20/RF24Network/issues/32#issuecomment-65377076>.

—
Reply to this email directly or view it on GitHub
#32 (comment).

С уважением,
Антон Сабадаш.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[prophet-roshak]

I've updated my repos with
https://github.com/prophet-roshak/DevDuinoNodeRF24
https://github.com/prophet-roshak/IOTHarvester

1st one is arduino part, look src/core.cxx for main logic
2nd one is galileo part, also src/core.cxx has main logic

these are working sets, so I feel sorry for them not being tidy...

[spaniakos]

Np wipl try to check them today. But i will with galileo and rasberry pi
On Dec 3, 2014 11:33 AM, "Anton Sabadash" [email protected] wrote:

I've updated my repos with
https://github.com/prophet-roshak/DevDuinoNodeRF24
https://github.com/prophet-roshak/IOTHarvester

1st one is arduino part, look core.cxx for main logic
2nd one is galileo part, also core.cxx has main logic

these are working sets, so I feel sorry for them not being tidy...

—
Reply to this email directly or view it on GitHub
#32 (comment).

[spaniakos]

I couldn't test it with RPi. Much code to convert i suppose. But i checked
it with mine.
As my initial checks, 1/4 packets will get lost with iterval < 700ms ( test
was with 650 ) actuall max is 666.66666666 interval. But that was because
the fifo was full.

By storming my code with messages i lost some because i had some md5 and
3DES calculations from my development libraries that needed optimizations
and measurements. ( more complex code will decrease the bandwidth u can use
with linear code execution )

All of my messages was acknowledged.

There was a case that the NRF antenna was not outputting any messages. Dont
know the cause, but i will check more into it.

Finally with out using the fifo queue ( outputting the messages directly,
with out any interval , i lost 0 messages, all was acknowledged, again the
interval of send was 700 ms ( no MD5 or 3DES)

There was no case of message transmission that was handled to the server
and the write returned false.

[prophet-roshak]

Thanks for your time!

I've downgraded to plain RF24 messaging, and correctly ACKing all packets at the moment, regardless of gpio or fast gpio pin used on Galileo.

I also emulated RF24Network::write (with short packets) and it also worked good.

I'will do some code restructuring and clean up, and will get back to this issue after that.

[prophet-roshak]

I've finally managed to reproduce the issue on pingpong example! It looks
like enabling dynamic ACK feature (calling RF24::enableDynamicAck()) on my
nRF24L01+ chips somehow disables autoack sequence. If I comment out this
call in RF24Network::begin() - TX_FIFO gets cleared, and RF24Network::write
reports correct transmission status.

I've updated my repos with simplifyed code on this issue. Can you confirm such behavior of your nRF24L01+ chips, or that's just some chip 'update' with parts I use?

[TMRh20]

So you are able to recreate the issue using the standard Network_Ping examples just by removing the line `radio.enableDyanamicAck();`` ? Is it the same using a simpler example like, helloworld_rx and helloworld_tx? Seems kind of odd, doesn't happen with any of my modules/chips.

[spaniakos]

I will give it a shot at tuesday using rx tx and galilro and raspberry
On Dec 6, 2014 12:27 PM, "TMRh20" [email protected] wrote:

So you are able to recreate the issue using the standard Network_Ping
examples just by removing the line radio.enableDyanamicAck();` ? Is it the
same using a simpler example like, helloworld_rx and helloworld_tx? Seems
kind of odd, doesn't happen with any of my modules/chips.

—
Reply to this email directly or view it on GitHub.

[prophet-roshak]

Yes, it's the same with helloworld_rx and helloworld_tx.

I've made some tests and here are results I got (DAE stands for dynamicAckEnabled, 1 if line is executed, 0 if commented). Every test shown correct data transmission.

(A) Reciever Arduino, Transmitter Galileo

Arduino DAE0 Galileo DAE0, Arduino DAE1 Galileo DAE0, Arduino DAE0 Galileo DAE1 -
write returns correct state.

Only if Arduino DAE1 and Galileo DAE1 - Error, write returns incorrect state.

(B) Reciever Galileo, Transmitter Arduino

Arduino DAE0 Galileo DAE0 and Arduino DAE1 Galileo DAE0 - write returns correct state.

Arduino DAE0 Galileo DAE1 and Arduino DAE1 Galileo DAE1 - Error, write returns incorrect state.

Looks like there is some problem on Galileo side. What API do you use for Galileo side, Spaniakos? Is it Arduino sketches, or all fancy Intel IOT Devkit with MRAA and UPM?

[spaniakos]

I am using arduino sketches
With Galileo IDE
On Dec 6, 2014 10:29 PM, "Anton Sabadash" [email protected] wrote:

Yes, it's the same with helloworld_rx and helloworld_tx.

I've made some test and here are results I got (DAE stands for
dynamicAckEnabled, 1 if line is executed, 0 if commented). Every test shown
correct data transmission.

(A) Reciever Arduino, Transmitter Galileo

Arduino DAE0 Galileo DAE0, Arduino DAE1 Galileo DAE0, Arduino DAE0 Galileo
DAE1 -
write returns correct state.

Only if Arduino DAE1 and Galileo DAE1 - Error, write returns
incorrect state.

(B) Reciever Galileo, Transmitter Arduino

Arduino DAE0 Galileo DAE0 and Arduino DAE1 Galileo DAE0 - write returns
correct state.

Arduino DAE0 Galileo DAE1 and Arduino DAE1 Galileo DAE1 - Error,
write returns incorrect state.

Looks like there is some problem on Galileo side. What API do you use for
Galileo side, Spaniakos? Is it Arduino sketches, or all fancy Intel IOT
Devkit with MRAA and UPM?

—
Reply to this email directly or view it on GitHub
#32 (comment).

[prophet-roshak]

Hello, I've found the root of the problem I encountered, and it's something frustrating :) It appears, I have a different RF24L01+ modules on my devices. One connected to Galileo actually is "nRF24L01 Module Enhanced Edition" featuring some kind of additional RF synth, and one I have on Arduino is standard "nRF24L01+ Module". I've got a new standard module to replace Enchanced one, and code works perfect now...

I think this Issue can be closed now. I'll try to debug that enchanced module after I get my scope :)

[TMRh20]

Just a note from taking a quick look at the 'enhanced modules', the only difference I've spotted so far is they are basically LNA+PA modules, so will require a solid 120ma supply if running at full power. You might also have better luck setting radio.setPALevel(RF24_PA_MIN); to minimize power consumption.

[prophet-roshak]

Thanks for advice, I'll try if this helps. I have only one such module, and planned to use it as hub one, with a stabilized 3.3v power source from galileo board.
For me, it looks like enabling dynamic ack on this module somehow stops module to send back normal ack sequence... Like pa not switching into transmit mode... Lacking schematics, it's hard to tell, how PA is controlled...