Sorry, only saw your message now. If still needed, I do have a few boards left.

Power consumption should be comparable to the blue pill with leds and regulator removed. Never got around measuring it myself but here are some results for the bluepill: https://www.stm32duino.com/viewtopic.php?f=3&t=658&start=40 , stating 13µA in STOP mode.
Also note that last time I checked, low power was not supported in MySensors for these MCU's so you would need to add it in yourself.

@ian1scott: sorry for the late reply. The part references can be found in the Fab layer in the kicad file.

@timo said in openHAB 2.2 binding:

I continue to hope for an integration in the main repository. ;-)

Hi @TimO,
What is preventing this? I'm willing to help if needed.

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?

@diogoc
Hi,
I'm having a similar problem and found your post.

From looking at the code I understand the CSMA entries mean that the transceiver is waiting for the channel to clear up before transmitting. So I suspect there must be some interference or a bad antenna.

@freynder said in Is the 32-bit ATSAML10 the ATMEGA328P killer that we've been waiting for?:

@yveaux I stand corrected. I just tried compiling an example sketch and indeed no errors. Last time I tried I had compilation errors, but that may have been due to other factors then.

I'm revisiting this as I tried to compile a sketch today using the official STM32 core (https://github.com/stm32duino/Arduino_Core_STM32 v1.3)

I realize now I tested with the wrong core as it is a bit confusing in Arduino IDE. Please see the screenshot below which boards menu should be selected (highlighted the selected board).

image url)

When I select this core, the sketch will not compile because the ARDUINO_ARCH_STM32F1 flag is not set.

@Yveaux and @nagelc : can you confirm you actually used this core? The core named "STM32 Boards (stm32duino.com)" is Roger Clarks core, not the official STM32 core one. Easily confused as the github user name for the official STM32 core is stm32duino.

@neverdie said in Is the 32-bit ATSAML10 the ATMEGA328P killer that we've been waiting for?:

You can even put a USB bootloader onto them.

plus debug using Black Magic Probe or stlink + OpenOCD

@yveaux I stand corrected. I just tried compiling an example sketch and indeed no errors. Last time I tried I had compilation errors, but that may have been due to other factors then.

@nagelc said in Is the 32-bit ATSAML10 the ATMEGA328P killer that we've been waiting for?:

I see that the L1 is supported now. Gonna have to dig those back out.

Are you referring to the official STM32 core provided by STM (github)?

AFAIK, MySensors currently only works with the unofficial one from Roger Clark (github) which is much more limited as far as supported mcu families go (good F1 support and limited F4).

A nice overview of cores can be found here.

@nagelc That would be interesting. Remember also that MySensors currently only supports STM32F1 without sleep mode. I'm running a modified version with sleep support, but since I could not make it generic enough, I never submitted it as an enhancement (can be found here: github, 2.2.0 only)

I still have a few prototype boards available but don't have enough time to progress much in the near future. If you would like a few boards (PCB only, not fully assembled) for experimenting and testing I can send you a few provided shipping costs permit it. I would love to see them better supported. Drop me a PM if interested.