Development branch serial gateway sends ACK 16 times?
-
16 answers seems a bit much :)
Can't see any obvious reason. Is the automatic NRF24L01 retries visible by the sniffer?
setupRadio()
RF24::setRetries(5,15);@hek said:
Is the automatic NRF24L01 retries visible by the sniffer?
Yes. The acks you probably won't see, but the retransmits should be visible. @tosa Have a close look at the nrf24 header for the 16 messages (expand them in wireshark). The PID field is increased with each message, also when retrying un-acked messages.
The timestamp between the messages seems to be 2.3ms apart between the messages. Does this match with the retry timeout? -
16 answers seems a bit much :)
Can't see any obvious reason. Is the automatic NRF24L01 retries visible by the sniffer?
setupRadio()
RF24::setRetries(5,15);setRetries(5,15) would be a fit in terms of # (1 original + 15 retries) but based on the RF24 library documentation the first parameter of 5 would mean (5+1)*250us -> 1.5ms delay between retries
The PIDs don't increase. For the screenshot above messages 1 and 2 have PID=0 and messages 3-19 have PID=2, message 20 has PID=3.
Message 21 starts with PID=0 again which makes sense because the nRF is re-configured between bootloader execution (messages 1-20) and firmware execution (message 21+).
All messages show
.... .... 0... .... = No ack: ACK (0)@Yveaux do you suppress the ack messages in the sniffer code? as it's sniffing "on air" in theory it should see all messages including the ACKs... Is there a parameter I can set on startup to see the ACKs as well? Maybe I've set the AutoAck incorrectly in the initialization code in the bootloader but then I would be surprised why it works for packet #2 which is just submitted once.
-
-
setRetries(5,15) would be a fit in terms of # (1 original + 15 retries) but based on the RF24 library documentation the first parameter of 5 would mean (5+1)*250us -> 1.5ms delay between retries
The PIDs don't increase. For the screenshot above messages 1 and 2 have PID=0 and messages 3-19 have PID=2, message 20 has PID=3.
Message 21 starts with PID=0 again which makes sense because the nRF is re-configured between bootloader execution (messages 1-20) and firmware execution (message 21+).
All messages show
.... .... 0... .... = No ack: ACK (0)@Yveaux do you suppress the ack messages in the sniffer code? as it's sniffing "on air" in theory it should see all messages including the ACKs... Is there a parameter I can set on startup to see the ACKs as well? Maybe I've set the AutoAck incorrectly in the initialization code in the bootloader but then I would be surprised why it works for packet #2 which is just submitted once.
@ToSa said:
as it's sniffing "on air" in theory it should see all messages including the ACKs...
I take that back - probably the nRF module connected to the sniffer will assume it's an "internal" message and not publish it to the MCU.
@hek it's the full low level packet including the address etc. For the first packet in the screenshot above it looks like this:
-
@ToSa said:
as it's sniffing "on air" in theory it should see all messages including the ACKs...
I take that back - probably the nRF module connected to the sniffer will assume it's an "internal" message and not publish it to the MCU.
@hek it's the full low level packet including the address etc. For the first packet in the screenshot above it looks like this:
-
@Yveaux said:
@ToSa @hek I think that all your questions are answered in my blog. I'll get back to this later.
Got it :)
When fixed payload size of the sniffer is set to a value (much) larger than the actual payload size in the packet, then subsequent packets might be missed. When the nRF24 is still capturing the fixed size payload and a new packet arrives, this will not be detected. A good example for this are the auto-acknowledge packets which can be enabled in Enhanced Shockburst mode. After the target node receives the packet (and it will know the real size of the payload a lot faster than the sniffer will) it switches its radio from receiving to transmitting mode in only 130us. Then it sends out the acknowledge packet. Reception of 32 bytes at 1Mb/s takes 32*8us = 256us, so acknowledge of a short message will definately be missed. For acknowledge packets this isn't much of a problem as the transmitter will retry to send the identical message when no acknowledge was received and we will know it missed the acknowldge. -
@Yveaux said:
@ToSa @hek I think that all your questions are answered in my blog. I'll get back to this later.
Got it :)
When fixed payload size of the sniffer is set to a value (much) larger than the actual payload size in the packet, then subsequent packets might be missed. When the nRF24 is still capturing the fixed size payload and a new packet arrives, this will not be detected. A good example for this are the auto-acknowledge packets which can be enabled in Enhanced Shockburst mode. After the target node receives the packet (and it will know the real size of the payload a lot faster than the sniffer will) it switches its radio from receiving to transmitting mode in only 130us. Then it sends out the acknowledge packet. Reception of 32 bytes at 1Mb/s takes 32*8us = 256us, so acknowledge of a short message will definately be missed. For acknowledge packets this isn't much of a problem as the transmitter will retry to send the identical message when no acknowledge was received and we will know it missed the acknowldge. -
@Yveaux Yeah - I'm not really good at reading manuals :)
I've submitted a pull request in GIT for your MySensors2.dll code - nothing major but just adding the latest additions to the enums and adding the stream types so that they show up as plain text in Wireshark as well... I could not test it because I ran into some issues during compilation - probably not the right toolchain installed. -
@Yveaux Yeah - I'm not really good at reading manuals :)
I've submitted a pull request in GIT for your MySensors2.dll code - nothing major but just adding the latest additions to the enums and adding the stream types so that they show up as plain text in Wireshark as well... I could not test it because I ran into some issues during compilation - probably not the right toolchain installed. -
Just a little curious... What exactly can you read out more than PID?
Is it just the package control fields?
Or the whole package?
Access to the later would be really interesting! Especially the address field would be nice to have.
@hek said:
Just a little curious... What exactly can you read out more than PID?
The sniffer catches everything on air after the generic address part, shared by all nodes. This includes everything starting with the last byte (in case of MySensors) from 'Address 3-5 byte' in that figure upto and including the 2 CRC bytes, and any data coming after that up to the maximum packet size (32 bytes)
-
Topic can be closed - while I still don't understand why this 16x repetition was reproducible consistently between these nodes and always only affected the third packet, it's now no longer reproducible and for now I'll just assume it has been a connectivity issue (even if nodes were sitting with <1m distance and nothing changed)
