So far betatests for two modules soldered manually two weeks ago are good. I was using two analog inputs and 5 digital outputs. Radio is rock stable also.

Found strange behavior of RFM69 OTA burning firmware after some research
OTA + RFM 69 (possible) glitches.
Used MYScontroller – works super flawless
Tried both MySensors Library 2.0 and MySensors Library v2.1.0
Various boards made by Koresh 8 Mghz Atmega with RFM69 radios

The issue: On larger sketches (like more than 20kbytes), OTA always gives CRC error. Smaller ones (4k or less) could be burned 1 out of 3 tries.

In the picture below the blues screen is comparing two files (right column is HEX and two lines actually is single 16 bit OTA payload)
Bin.txt file is parsed Arduino hex output to the way it is identical to JDEC flash content. TXT2 file is JDEC flash content.
Log indicates NACK error for the block B=0065 and LEN !=29 (assume it is 0 length payload). After that, somehow instead of re-requesting that corrupted or 0 sized payload, it duplicates previously received (marked in yellow) into new address. This can happen sometimes 2-3 or 10 times during OTA process

I spend many hours playing with MyOTAFirmwareUpdate , transport and RFM driver trying “fixing” logic there but failed. Solution found Koresh by increasing from 40ms to 100ms retryWaitTime in RFM69.h

virtual bool sendWithRetry(uint8_t toAddress, const void* buffer, uint8_t bufferSize,  uint8_t retries=2, uint8_t retryWaitTime=100); //!< sendWithRetry (40ms roundtrip req for 61byte packets) 

So may be something strange happens when rfm ack is received outside the circle in sendWithRetry function.

My and Koresh concern it is not “real” solution. Since this kind of re-requesting of 0 sized payloads should be dealt very well in protocol layer. Otherwise if there is lots of traffic going on
In the network, there will be lots of this kind of 0 payload situations.
The fix actually gives good results (10 out of 10 without CRC errors). It works now but… I think would be great to look into deeply.

@tekka

The break down cost of the board and components is less than USD $5 ( aliexpress component prices mostly) . Can someone share some PCBA service which can also do components sourcing ? with reasonable pricing of course. I would order some 20 - 30 units and may be others could join to make price cheaper.

@tekka

with your new PR updated all works good now. I could not replicate @ 40 ms in retryWaitTime the mentioned above. so I put 10 ms like a stress test. It has survived! with lots of WRONG FWB but with CRC OK!

the logs

serial
https://drive.google.com/open?id=0B11zpaGZaUo5c3NMT1VuSGoxU3c

last OTA is correspoding to serial log
https://drive.google.com/open?id=0B11zpaGZaUo5MVh2cUg2cWMxWER0aHEwWHhoY1VidEpuOURn

Once a week I was having NACK blackout. All nodes could not send nor receive anything. Initially I was resetting everything and after some 20 minutes I was “able to fix” things. However, it was reappearing. Looked very strange. I bought very very very useful device called RTL-SDR (R820T) software digital receiver. Just in case you do not have, it is worth to buy. Yes, it is around $7 dollars from aliexpress include delivery. The device is not good for NRF since range is 24 - 1766 MgHz but for RFM it is super good. Back to my problem though, I found the noise at 429 -437 Mghz and it lasts around 20 minutes, the time “I was fixing things” previously. Huh!
Video
https://youtu.be/BH_hDyWGr5I
You can see from the video, blackout was at the frequencies from 429 -437 Mghz
After that, I switched RFM 69 to 440 Mghz and see results. 5 transmissions!!!
https://youtu.be/jlE2p07-jOY
The device is super useful toy!!! You can listen FM radio and other air traffic control towers.
Found later is not legal to use 440 Mghz though…
The RTL-SDR (R820T):
With this tutorial you can turn RTL-SDR (R820T) into 24 - 1766 MgHz receiver and see what happens in the air.
http://www.rtl-sdr.com/rtl-sdr-quick-start-guide/

Hope it is helpful.

Alfa testing:

Checking radios as various nodes. Currently working as 2 relay nodes, DHT 22 temperature node and gateway.
All is good . Range 1-2 meters less than NRF24 with big antenna in apartment surrounding.
Digital pins cheeked like in the video: https://youtu.be/00fy9amZnt4
Analog pins tested with generic arduino light sensor. So radios and pins are OK.

The bootloader and OTA update script + RFM69 work super nice with MYScontroller. I use it few times a week. Big Big Big ups to Tekka. Especially I like the sensebender micro bootloader boots instantly ))). Enjoy everybody!

@mariusl said in Gateway sends NACK to node:

Any ideas from someone on this?

#define MY_TRANSPORT_STATE_TIMEOUT_MS (5*1000ul)

//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF1288
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096

These lines can affect. the TRANSPORT_STATE_TIMEOUT may be less than a actual message sending time. you will get constant NACK's.

@TurboMaster66 said in MySensors Error received:

item type not found

Seems like some sensor types you created in those nodes not supported\accepted by the controller. try different types. That is my best guess. I've seen something like that in homeassistant and domoticz

Hi @fisher yes this is Koresh board. Hope to upload others soon... We did production and testing with him together.

@TurboMaster66 said in MySensors Error received:

item type not found

Seems like some sensor types you created in those nodes not supported\accepted by the controller. try different types. That is my best guess. I've seen something like that in homeassistant and domoticz

@TurboMaster66

Do you have nodes with addresses ## 17 60 100 on your network?

@mariusl said in Gateway sends NACK to node:

what it does

SF number is chips (chirps) needed to code each bit. SF4096 is maximum range especially in urban area, but very long delay . I tried different combinations and found below MY_RFM95_MODEM_CONFIGRUATION is pretty much good. 20 - 30% less in terms of distance and delay #define RFM95_RETRY_TIMEOUT_MS (300ul) is enoght. Much faster.

#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW_500KHZ | RFM95_CODING_RATE_4_5, RFM95_SPREADING_FACTOR_2048CPS | RFM95_RX_PAYLOAD_CRC_ON, RFM95_AGC_AUTO_ON

@mariusl said in Gateway sends NACK to node:

good value for the timeout?

here are the delay examples in the docs
https://www.mysensors.org/apidocs/group__RFM95grp.html#ga23a30185cbd40984e65d5269983bf840

for yours #define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096

I would use #define RFM95_RETRY_TIMEOUT_MS (2000ul)

any reason for the Spread factor SF4096 ?

pinout looks ok.

btw This line from the Node log

1269 !TSF:MSG:SEND,100-100-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1

Means node cannot send OR gateway cannot receive. may be node radio is HCW somehow?
mysensors lib not broken\timeouts not tweaked?

@ctodor said in Gateway doesn't receive any message from node:

broken only on the "send side"

As @mfalkvidd said, it is possible to burn with no antenna attached but I never actually did that. RFM is quite reliable. Is Schematics available? I see you have reset pad soldered. reset should be disconnected after reset is completed.

@ctodor said in Gateway doesn't receive any message from node:

I bought from you, "easySensor"

Yes.

may be detailed photo of the device can help...

@mariusl said in Gateway sends NACK to node:

Any ideas from someone on this?

#define MY_TRANSPORT_STATE_TIMEOUT_MS (5*1000ul)

//#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR45SF1288
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096

These lines can affect. the TRANSPORT_STATE_TIMEOUT may be less than a actual message sending time. you will get constant NACK's.

@ctodor said in Gateway doesn't receive any message from node:

GW ia not totally mute

Better to have 3-rd device to play with. Preferably 3.3 V one. RFM is 3.3 volts radio. not sure if you used logic level shifters for Nano digital pins connected to radio. Also, SDR radio is handy to detect any radio emission.

which radio version do you use HCW or CW?

#define MY_IS_RFM69HW // this is for HCW or commnet out for CW