Linux gateway don't receive Ack

[rozpruwacz]

I had similar problems. What is happening is the rfm69 drivers is checking the rssi value before sending anything. If rssi is below some treshold the mesage is sent, and if not the driver waits 500ms and then it sends the message regardless of the rssi value. When message is send, the driver waits only 200ms for the ack, so if other end has high rssi value the ack is not received on time. So the problem is high rssi value before sending. In my case it was due to poor power supply so i would recommend powering the rfm module from separate low noise ldo regulator.

[freynder]

@rozpruwacz : Great suggestion about the power supply. I tested with a battery and added a decoupling capacitor but unfortunately that did not help in my case.

I troubleshooted further by replacing boards, transceiver, the antenna. No improvement either.

I'm now checking the code in detail and have a concern with the following function (v2.3.0):

LOCAL bool RFM69_channelFree(void)
{
	// returns true if channel activity under RFM69_CSMA_LIMIT_DBM
	const rfm69_RSSI_t RSSI = RFM69_readRSSI(false);
	RFM69_DEBUG(PSTR("RFM69:CSMA:RSSI=%" PRIi16 "\n"), RFM69_internalToRSSI(RSSI));
	return (RSSI > RFM69_RSSItoInternal(MY_RFM69_CSMA_LIMIT_DBM));
}

The function is supposed to compare RSSI with the threshold set in RFM69_CSMA_LIMIT_DBM.
If RSSI is above the threshold then it should return true.
However, the comparison is made with the internal representation which is defined as - (2*value)

Since both values are negated, wouldn't the comparison operator need to be inversed as well?
e.g.: RSSI = -80 , limit = -95
-80 > -95 so the function should return true
converted to internal presentation this should be:
160 < 190 so it should also return true
however, the function does:
160 > 190 --> false

Am I missing something here?

[mfalkvidd]

@freynder internaltorssi will convert the internal value to rssi. So I don’t think that’s the case.

Edit: Sorry, you might have a point. The rssi is indeed converted to internal. Looks strange.

[freynder]

@mfalkvidd said in Linux gateway don't receive Ack:

@freynder internaltorssi will convert the internal value to rssi. So I don’t think that’s the case.

Yes, that's my point. Both values in the comparison are in internal format so the comparison should be RSSI_internal < LIMIT_internal.

Suppose an excellent RSSI: -30dbI . RSSI_internal = 60
Limit is -95dbi. LIMIT_internal = 190
so 60 < 190
The function will return false although RSSI is excellent.

[mfalkvidd]

@freynder but if RSSI is excellent, it means someone else must be sending and the channel isn't free. So maybe the correct value is returned anyway in your calculation example (but the comparison is still strange)

[mfalkvidd]

If the code was refactored like this I think it would do exactly the same thing, but it would be easier to follow:

LOCAL bool RFM69_channelFree(void)
{
	// returns true if channel activity under RFM69_CSMA_LIMIT_DBM
	const int16_t RSSI = RFM69_internalToRSSI(RFM69_readRSSI());
	RFM69_DEBUG(PSTR("RFM69:CSMA:RSSI=%" PRIi16 "\n"), RSSI);
	return (RSSI <= MY_RFM69_CSMA_LIMIT_DBM);
}

[freynder]

@mfalkvidd said in Linux gateway don't receive Ack:

If the code was refactored like this I think it would do exactly the same thing, but it would be easier to follow:

LOCAL bool RFM69_channelFree(void)
{
	// returns true if channel activity under RFM69_CSMA_LIMIT_DBM
	const int16_t RSSI = RFM69_internalToRSSI(RFM69_readRSSI());
	RFM69_DEBUG(PSTR("RFM69:CSMA:RSSI=%" PRIi16 "\n"), RSSI);
	return (RSSI <= MY_RFM69_CSMA_LIMIT_DBM);
}

I think the comparsion should be > in this case. (e.g. -30 > -95)

[rozpruwacz]

@freynder no, the function is correct. Before sending the rssi value read by this function should be lower than treshold -80dbm is not lower than - 95dbm. You should get rssi reprted around - 100dbm in this function but for some reason you have higher values.

[freynder]

@rozpruwacz

Ok, I must be missing something then. You say that the rssi should be around -100dbm for the channel to be clear? So lower is better for checking channel clearance? I thought higher was better.

[rozpruwacz]

@freynder yes, the lower the better. You may be confused by this because the rssi is "Received Signal Strength Indication" so the higher the better, but in this function this indicator is used to check that nothing is receiving

[freynder]

@rozpruwacz Ok, got it now. Thank you very much.

[freynder]

@mfalkvidd said in Linux gateway don't receive Ack:

@freynder but if RSSI is excellent, it means someone else must be sending and the channel isn't free. So maybe the correct value is returned anyway in your calculation example (but the comparison is still strange)

Indeed you were right. I had a wrong understanding on how RSSI was measured. It appears to be an indication of "the amount of energy available within the receiver channel bandwidth", so if nobody is sending it will be low.

[scalz]

And for newcomers, about rfm69 channel free, it helps to avoid some collisions, but this function+automatic powertransmit tuning helps to be better at FCC compatibility. RFM69 can go up to +20 dBm so it could create some mess in air..
FCC is related to

• hardware. Still, you can buy a fcc module but as soon as you place it on a custom board, so not exact same shape as manufacturer, FCC is not valid anymore. FCC is tested with specific manufacturer design, and when you change shape and layout of pcb, rf is not same as before, so FCC not ok ;)
• and software. You can have a FCC device, but if rf stack in framework don't check channel free etc then it's not FCC too

[diogoc]

Ok, I understand now that the modules are measuring the noise signal strenght before sending someting.
Apparently the noise level is high, but with the other gateway I get low values.
It seems to be the linux gateway that is generating the noise ???
The RFM69 is powered by a separated LDO and capacitors, so I don't think it is a power supply problem.

The RFM69 linux driver is the same that arduino RFM69 driver? Could be some missing register parameterization?