Version 4.2 was just published. The board now also contains breakout headers for I2C devices (temperature sensors such as Si7021, HTU21D, SHTT71 and BME280) and a headers for a RXB6 RF 433Mhz receiver. Not tested yet.

After testing the board for a few weeks I implemented a major redesign, marked as V4. Not tested yet.

Changes:

• Changed headers to XH2.54 connectors for leds and buttons
• Added secondary regulator to power RF modules
• Changed RFM69 footprints to remove unused pads
• Changed CHG340G chip to CHG340C, eliminating the crystal
• Relayed all traces for cleaner design
• Added capacitors at USB input power
• Added second capacitor for decoupling at RFM69 modules

@diogoc said in Recommendation for PCB fab?:

JLCPCB made good and cheap pcbs

I second that. Especially if you can combine a few PCBs in one order it is very interesting.

@yveaux and @scalz

Thanks for confirming. So only Clark's core is supported at the moment.

It would be interesting to support the official STM32 core as they provide low power functions. I will do some experiments.

@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.

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

@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.

@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)

@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.

@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?