ListenMode settings to support ULP

[ulli]

I checked your ListenMode extension in your library and I do not understand why you
* have a delay in your burst "delayMicroseconds( 5000 );"....not really a burst. It just sends one message every 5 ms.
    Does the 5ms delay does not cause transmission problems? I always try to send a burst with a minimum of transmission delays, to create a continues burst.
* turn of the encryption. Do you see any disadvantages in the ListenMode by using encryption?

[joelucid]

Hey Ulli, I think that part of the code originates from me so here are my comments:

It really is a continuous burst because the radio never leaves TX. What happens is the radio sends preamble while nothing else is sent. A problem with that setup is that packagesent gets triggered immediately for every packet after the first. Therefore you need to hand tune a delay (that's the delayMicroseconds). Finally encryption does not work when TX is kept on.

On the upside you get a burst that really does not include s gap - so great for listen more.

[WhiteHare]

It really is a continuous burst because the radio never leaves TX. What happens is the radio sends preamble while nothing else is sent. A problem with that setup is that packagesent gets triggered immediately for every packet after the first. Therefore you need to hand tune a delay (that's the delayMicroseconds). Finally encryption does not work when TX is kept on.

On the upside you get a burst that really does not include s gap - so great for listen more.

FWIW, I appear to be hitting a 1ms Rx window 100% of the time while in Listen Mode by having the transmitter simply call sendFrame in a tight loop.  That results in a Tx cycle that's ~1.2ms long, with the Tx active for ~750uSec of each cycle.

[joelucid]

FWIW, I appear to be hitting a 1ms Rx window 100% of the time while in Listen Mode by having the transmitter simply call sendFrame in a tight loop.  That results in a Tx cycle that's ~1.2ms long, with the Tx active for ~750uSec of each cycle.

Sure - but I like to use RX windows 1/4 to 1/3rd of a ms. You are guilty of energy waste

[WhiteHare]

No doubt yours is a better way.  As a lesser milestone, though, I'm happy it works at all, especially because the underlying default RFM69 library code does appear to be using the sync word....I think.  I'll need to review it again to double check.  When you encountered the "bug", was it an intermittent thing, or did it happen every time?  i.e. Do you remember if there was there any pattern to it?

[joelucid]

When you encountered the "bug", was it an intermittent thing, or did it happen every time?

It happened every time a radio in listen mode with address filtering on would receive a burst addressed to another node. In that case the radio got stuck in receive until the burst was over - regardless of timeout2.

[WhiteHare]

When you encountered the "bug", was it an intermittent thing, or did it happen every time?

It happened every time a radio in listen mode with address filtering on would receive a burst addressed to another node. In that case the radio got stuck in receive until the burst was over - regardless of timeout2.

How long after the end of the burst was it that the radio got unstuck and returned to listen-mode?

[joelucid]

How long after the end of the burst was it that the radio got unstuck and returned to listen-mode?

I didn't have a scope then, so I can only offer a roundabout estimate: the radio got unstuck immediately when the burst ended. That's why I think there's a chance that your non-burst method might not trigger the bug. However the bug is not a big issue since you can just disable packet filtering at the radio and reject the packet at the 328p.

[WhiteHare]

That's why I think there's a chance that your non-burst method might not trigger the bug.

That's what I'm hoping.  If it does trigger it, then it sounds like I can dial-in a bigger gap between Tx's until it doesn't.  Adding gap is easy.  Getting smaller and smaller gaps, as you have already managed to do, is more challenging.

In any case, it would be interesting to know what the minimum gap size would have to be.  It sounds as though there is at least some gap already, though very small.  Have you or Tom measured what it currently is?

[TomWS]

That's why I think there's a chance that your non-burst method might not trigger the bug.

That's what I'm hoping.  If it does trigger it, then it sounds like I can dial-in a bigger gap between Tx's until it doesn't.  Adding gap is easy.  Getting smaller and smaller gaps, as you have already managed to do, is more challenging.

In any case, it would be interesting to know what the minimum gap size would have to be.  It sounds as though there is at least some gap already, though very small.  Have you or Tom measured what it currently is?

I haven't but, unfortunately, I've put away my scope for a couple of weeks.  I probably wouldn't get around to measuring this until the middle of October. Sorry,
Tom

[ulli]

Hey Ulli, I think that part of the code originates from me so here are my comments:

It really is a continuous burst because the radio never leaves TX. What happens is the radio sends preamble while nothing else is sent. A problem with that setup is that packagesent gets triggered immediately for every packet after the first. Therefore you need to hand tune a delay (that's the delayMicroseconds). Finally encryption does not work when TX is kept on.

On the upside you get a burst that really does not include s gap - so great for listen more.

Some very good points

I use the the "Unlimited Length Packet Format" to create a continues burst. Therefore you are right and a encryption would not work with that TX mode. But this also applies with the CRC and data whitening/manchester function, don't it?

Additionally, I think that it is not necessary to hand tune the delay, if you use the following function to check the transmission/FIFO status during your burst?

Code Select Expand

while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFOLEVEL) != 0x00); // Wait till Threshold is not exceeded / Does not work in Sleep_Mode!

Regarding the so called "bug" in ListenMode. I guess the Module keeps receiving during your burst because it is comparing the incoming data with the sync and address filtering pattern till it hopefully matches. After the timeout it maybe gets immediately triggered again due to the high RSSI value and goes into RX Mode?
What do you think?

[joelucid]

Ulli,

Whitening and CrC work if the package size is under 255 bytes. But encryption generally only works if the radio is in mode standard when you fill the fifo and switch into tx afterwards. The datasheet can be read to support these experimental facts.

I like the fifolevel idea. I have to try that. If it works it would really help because hand tuned delays are obviously ugly.

Rg the timeout: yeah whitehare and I had already discussed that. But an interesting fact is that noise does not trigger this behavior. so there seems to be something special about seeing a real packet that doesn't match the address. Maybe in that case the radio stays in receive until RSSI drops at least once. In any case the workaround I described works well.

According to the spec the receiver is automatically switched off when timeout2 hits, so I think we can use bug without the quotes.

[joelucid]

In any case, it would be interesting to know what the minimum gap size would have to be.  It sounds as though there is at least some gap already, though very small.  Have you or Tom measured what it currently is?

Nope. My code does not produce a gap at all. Why don't you just use the workaround?

[ulli]

Whitening and CrC work if the package size is under 255 bytes. But encryption generally only works if the radio is in mode standard when you fill the fifo and switch into tx afterwards. The datasheet can be read to support these experimental facts.

If you are right that the CRC works for "unlimited package length" (I could not find it in the doc) it can not be received right by our ListenMode Node, because the CRC is calculated over the complete burst message?
If we send a burst with a length of RX/Idle Time we should always have payloads >255bytes, don't we?

Just to be sure we talk about the same thing, in the following my TX code for "unlimited package length"

Code Select Expand

for(uint16_t e=0; e<=lDataStruct->XDATA_Repeats; e++) {

		mySpi.xferBegin(RF69_Config.spi_id);
		mySpi.xfer_byte(REG_FIFO | 0x80); //set FIFO to TX Modus

		//Data to RFM FIFO
		for (byte i = 0; i < bufferSize; i++)  {
		  mySpi.xfer_byte(lDataStruct->DATA[i]);
		}
		mySpi.xferEnd(RF69_Config.spi_id); 	

		//TX control		
		if(!e) setMode(RF69_MODE_TX); //first push data while rfm69 is in standby
		while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFOLEVEL) != 0x00); // Wait till Threshold is not exceeded / Does not work in Sleep_Mode!
	}

[ulli]

In any case, it would be interesting to know what the minimum gap size would have to be.  It sounds as though there is at least some gap already, though very small.  Have you or Tom measured what it currently is?

Nope. My code does not produce a gap at all. Why don't you just use the workaround?

To have no gap is very important for the canSend() function of the ListenMode Node. Because if there is a gap in the burst I loose some ACK messages of the ListenMode Node, because the canSend() function detects that the burst is over and sends the ACK message to early.