RX to TX first transmission issue

[ziplockk]

Hi,

Been using moteinos/RFM69's for a while as remote, low power, data capture nodes with great success (probably moving to lora soon too).

However, have been prototyping a solution which uses the same moteino/rfm69 platform with the LowPowerLab RFM69 library to do some command/response pattern messaging and may have discovered a problem.

I don't use (cannot use) transmission retry or ack, I can only use simple broadcasts only (this is defined by the problem space and can't be changed). What I have discovered may be masked by the use of retry mechanisms.

What I observe is that occasionally (not too infrequently) a response transmission, which are sent as soon as possible after receiving a command, doesn't get sent (i.e. never makes it onto the air). The more delay I add between reception and transmission the less likely the issue is to occur. By the time that delay is a few hundred ms the problem is not apparent.

Anybody else seen anything similar ? - From what I can see the library seems to implement the transmission sequence defined in the data sheet, but I'd need to go through it with a lawyer (as usual) to be 100% sure . . . thought it worth asking folks on here before pulling the library apart (which I have no desire to do).

Any pointers appreciated.

Fd

[Felix]

What I observe is that occasionally (not too infrequently) a response transmission, which are sent as soon as possible after receiving a command, doesn't get sent (i.e. never makes it onto the air). The more delay I add between reception and transmission the less likely the issue is to occur.

Hi,
Is this with stock examples or with your own code?
Is the "response transmission" an ACK or what exactly?
Note an ACK is just a regular packet that also has a special bit set in the packet header (to indicate to the recipient to treat it as an ACK).
The statement I'm most interested in is "never makes it onto the air", what makes you say that? How do you test the packet never gets sent?
FWIW it's one thing to not get sent, a totally different thing to not receive. The observation might be the same, but what actually happens is very different. If your recipient is not ready and listening by the time the ACK is sent, no packet will be received.

[ziplockk]

Hi,

Latest library, straight our of git.

Response is just a regular packet (i.e. radio.send(RF69_BROADCAST_ADDR,buffer,length)), all messages are 32 bytes fixed length.

I'm using a 3rd node to snoop the OTA traffic and the response is not seen by either the sniffer or the intended recipient. The sniffer is in permanant RX mode - different code and has proven to be completely relaible in its observations (it timestamps the RX packets and logs them to serial as it's a timing critical thang).

I'm surprised as this is a very heavily used library, but you never know . . . lots of people love their retransmission patterns . . .

Fd

[ziplockk]

Code Select Expand

//grossly simplified pseudo code
loop
{
  if(radio.receiveDone())
  {
     if(received data == wombleCommand)
     {
        create wombleResponse buffer
        radio.send(RF69_BROADCAST_ADDR, wombleResponse, wombleResponseLength)
        // happy days
     }
  }
}
//grossly simplified pseudo code

I may grossly simplify the code to just this later and see if the problem persists

wombleCommands arrive at a relatively low rate, say one every 1000+ms.

RF bitrate is per the library config so it's not overlapping transmissions.

[perky]

Right, every 1000ms is the clue. I think it is the send() routine which reads RSSI, and there's a 1000ms timeout which means it will send either if the current RSSI is below a threshold, or the timeout occurs. Reading RSSI has been problematical for people (and it *may* be related to bit rate).

Try setting RF69_CSMA_LIMIT_MS to 0 to see if things improve.

Mark.

[RoSchmi]

Hi, I think you cannot send from the place in the code, from where you do (except an ACK). After a receive you must first do a second call of receiveDone(). In this second call the receiveBegin() function will be called, which sets PAYLOADLEN to 0. If PAYLOADLEN is not 0, the canSend() function will not return true.

Edit: Not sure if this is right, just saw that receiveDone() is called in the send routine.

[ziplockk]

Right, every 1000ms is the clue. I think it is the send() routine which reads RSSI, and there's a 1000ms timeout which means it will send either if the current RSSI is below a threshold, or the timeout occurs. Reading RSSI has been problematical for people (and it *may* be related to bit rate).

Try setting RF69_CSMA_LIMIT_MS to 0 to see if things improve.

Mark.

Seems to have improved things, some more testing tomorrow to verify . . . after reading the library code I wondered if something in this area was causing the issue . . . this may confirm it . . . In my application the message transmission times are precisely controlled so when I call send I need the radio to send unconditionally . . . off into the code, chainsaw in hand . . .

[ziplockk]

In retrospect that change doesn't stop transmission, merely defers it I think, which is not what is happening.

More testing required

Fd

[perky]

OK, are you saying that transmissions just don't happen at all? Does the code get stuck?
Mark.

[perky]

OK, are you saying that transmissions just don't happen at all unless you wait for a few hundred ms after receiving the command? Does the code get stuck when this happens? And did changing the timeout value make it work? Are you also absolutely sure it's not transmitting and it's not the receiver not receiving? The reason I ask is because I've seen problems when transitioning from STANDBY to RX mode on the receiver, that doesn't appear to reset the receover logic properly although the specs say it should. The result is the receiver simply misses that packet, but will then start receiving normally. My fix for that is to put the receiver to SLEEP just prior to enabling RX.
Mark.

[ziplockk]

Well, when the packet is not received it's not received by two independent radios, both running different software, so either they are both failing to receive at precisely the same time (I guess that's possible - but one of them is always in RX mode). I'd say it's most likely that the packet is not being transmitted. The transmitter does not lock up - it thinks everything is fine. My gut tells me that the radio is not in tx mode despite being told to and it's a timing issue . . . but that's a pure guess . . .

Haven't had the time to do any more testing yet, next stage must be to simplify and test more aggressively.

[perky]

Ah, OK. I'd say it's not transmitting then ;-)

Your pseudo code shows the transmission of the reply happens when you receive a command, so I guess you've simulated that command packet being received locally to rule out not actually receiving the command (my SLEEP v STANDBY argument also holds for that too).

Mark.

[ziplockk]

So . . . could be RF interference . . . spectral analysis shows wideband transmission over the band, sporadic but not infrequent. Could be the huge 20ft tall antenna 50 meters away (never noticed it before) . . . testing in an RF quiet area doesn't show the issue . . . more testing required . . .