Topics created by manutremo

@manutremo Activate a forced mode. I bet your sensor is in standby mode right now

@berkseo yes, until now it has been implemented for rfm radios only, as nrf24 doesn't provide true rssi value. As usual, features appears along interests. So if you want it for nrf5, maybe post/PR your snippet on github On my side no time for testing this, my mysensors HA isn't 2.4ghz based as I need longer range, and keep 2.4ghz bandwidth in case for others protocol (wifi, ble, zigbee) for limiting issues.

Answering to myself... after many tests I decided to start to start working backwards and started to discard assumptions... finally I discarded : I know that Mega pins are 5v and in theory RFM69 are 3.3v, but I have more sensors installed in a similar setup with mini Pro 5v and Nano boards that work perfectly. So I fit a ttl levels shifter between the Mega Pro and the RFM69 and it started to work right away. It looks like AT328 and AT2560 have different levels of sensitivity as of being able to interpret 3.3v correctly as a "1". Interestingly, I checked the datasheets for both chips and the specification is the same, min 0.6Vcc volts, so anything over 3v should be interpreted as a "1"... go see... As a final detail, I was able to use a 4way ttl shifter since the MISO line doesn't need to be shifted, which left me with MOSI, SCK, SS and INT. Credit to this forum page for this: I can also confirm that pin D2 on these boards is connected to INT0 as standard... I don't know why the pinout diagram indicates something different. I hope this helps others.

The people that know me well say I'm one of the "need to see to believe" guys. Therefore I decided to get my SDR device out and install it on my PC. I then looked at the area around the 868MHz frequency. I then launched a fw update on one of my nodes, and waited for some of the zwave nodes to talk to the controller. This capture shows how the rfm69 module is talking at the 868MHz (center red band), while a zwave device send some short bursts of data at 868.4MHz. The two red areas are quite well separated so it doesn't really look like they could interfere. I repeated the test several times and found that some zwave devices seem to be not perfectly tuned to 868.4MHz, and were transmitting at more like 868.35MHz. Even in this case, there are no signs of interference. I also took the opportunity to take a look at the 915MHz freq. In Spain this band is not free and happens to be reserved for the 4g data cell communication. In my area this band seems to be really clear, so I guess the cellular antennas are not using them. However, it's not an option if you want to follow the regulations.

@tekka Tested the new library and both issues seem to be gone now, great job ! I have one more question though During testing I treid to put things difficult for my radios and move them until reception started to be bad. At some point the FOTA process gave up with a FW UPD FAIL message (line 41146 in attached log). So the node gave up and went to sleep. I was expecting it to try again after wake-up, but it didn't (see lines after 43589). 36734 !RFM69:SWR:NACK 36737 RFM69:PTX:NO ADJ 36771 RFM69:SWR:SEND,TO=0,RETRY=5 36966 RFM69:SWR:ACK,FROM=0,SEQ=119,RSSI=-55 36972 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12 36976 RFM69:PTX:LEVEL=12 dBm 36978 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 36988 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 36993 RFM69:SWR:SEND,TO=0,RETRY=0 37203 !RFM69:SWR:NACK 37206 RFM69:PTX:LEVEL=13 dBm 37216 RFM69:SWR:SEND,TO=0,RETRY=1 37423 !RFM69:SWR:NACK 37425 RFM69:PTX:NO ADJ 37459 RFM69:SWR:SEND,TO=0,RETRY=2 37666 !RFM69:SWR:NACK 37668 RFM69:PTX:NO ADJ 37679 RFM69:SWR:SEND,TO=0,RETRY=3 37885 !RFM69:SWR:NACK 37888 RFM69:PTX:NO ADJ 37922 RFM69:SWR:SEND,TO=0,RETRY=4 38129 !RFM69:SWR:NACK 38131 RFM69:PTX:NO ADJ 38174 RFM69:SWR:SEND,TO=0,RETRY=5 38313 RFM69:SWR:ACK,FROM=0,SEQ=120,RSSI=-56 38318 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=12 38322 RFM69:PTX:LEVEL=12 dBm 38326 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 38334 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 38338 RFM69:SWR:SEND,TO=0,RETRY=0 38547 !RFM69:SWR:NACK 38549 RFM69:PTX:LEVEL=13 dBm 38559 RFM69:SWR:SEND,TO=0,RETRY=1 38768 !RFM69:SWR:NACK 38770 RFM69:PTX:NO ADJ 38805 RFM69:SWR:SEND,TO=0,RETRY=2 39012 !RFM69:SWR:NACK 39014 RFM69:PTX:NO ADJ 39024 RFM69:SWR:SEND,TO=0,RETRY=3 39231 !RFM69:SWR:NACK 39233 RFM69:PTX:NO ADJ 39268 RFM69:SWR:SEND,TO=0,RETRY=4 39475 !RFM69:SWR:NACK 39477 RFM69:PTX:NO ADJ 39520 RFM69:SWR:SEND,TO=0,RETRY=5 39702 RFM69:SWR:ACK,FROM=0,SEQ=121,RSSI=-54 39706 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12 39712 RFM69:PTX:LEVEL=12 dBm 39714 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 39723 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 39729 RFM69:SWR:SEND,TO=0,RETRY=0 39938 !RFM69:SWR:NACK 39940 RFM69:PTX:LEVEL=13 dBm 39983 RFM69:SWR:SEND,TO=0,RETRY=1 40192 !RFM69:SWR:NACK 40194 RFM69:PTX:NO ADJ 40228 RFM69:SWR:SEND,TO=0,RETRY=2 40435 !RFM69:SWR:NACK 40437 RFM69:PTX:NO ADJ 40480 RFM69:SWR:SEND,TO=0,RETRY=3 40687 !RFM69:SWR:NACK 40689 RFM69:PTX:NO ADJ 40724 RFM69:SWR:SEND,TO=0,RETRY=4 40931 !RFM69:SWR:NACK 40933 RFM69:PTX:NO ADJ 40943 RFM69:SWR:SEND,TO=0,RETRY=5 41125 RFM69:SWR:ACK,FROM=0,SEQ=122,RSSI=-54 41129 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12 41134 RFM69:PTX:LEVEL=12 dBm 41138 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 41146 !OTA:FRQ:FW UPD FAIL 41299 RFM69:SWR:SEND,TO=0,RETRY=0 41506 !RFM69:SWR:NACK 41508 RFM69:PTX:LEVEL=13 dBm 41519 RFM69:SWR:SEND,TO=0,RETRY=1 41725 !RFM69:SWR:NACK 41728 RFM69:PTX:NO ADJ 41762 RFM69:SWR:SEND,TO=0,RETRY=2 41969 !RFM69:SWR:NACK 41971 RFM69:PTX:NO ADJ 42014 RFM69:SWR:SEND,TO=0,RETRY=3 42221 !RFM69:SWR:NACK 42223 RFM69:PTX:NO ADJ 42258 RFM69:SWR:SEND,TO=0,RETRY=4 42465 !RFM69:SWR:NACK 42467 RFM69:PTX:NO ADJ 42477 RFM69:SWR:SEND,TO=0,RETRY=5 42684 !RFM69:SWR:NACK 42686 RFM69:PTX:NO ADJ 42721 !TSF:MSG:SEND,22-22-0-0,s=1,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=NACK:0 42729 RFM69:SWR:SEND,TO=0,RETRY=0 42950 !RFM69:SWR:NACK 42952 RFM69:PTX:NO ADJ 42995 RFM69:SWR:SEND,TO=0,RETRY=1 43005 RFM69:SWR:ACK,FROM=0,SEQ=124,RSSI=-55 43010 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12 43014 RFM69:PTX:LEVEL=12 dBm 43018 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=1,st=OK:20 No detection 43026 MCO:SLP:MS=30000,SMS=1,I1=1,M1=1,I2=255,M2=255 43030 RFM69:SWR:SEND,TO=0,RETRY=0 43065 RFM69:SWR:ACK,FROM=0,SEQ=125,RSSI=-56 43069 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=11 43075 RFM69:PTX:LEVEL=11 dBm 43077 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=32,pt=5,l=4,sg=0,ft=0,st=OK:500 43585 TSF:TDI:TSL 43587 RFM69:RSL 43589 MCO:SLP:WUP=-1 43591 TSF:TRI:TSB 43593 RFM69:RSB 43595 RFM69:SWR:SEND,TO=0,RETRY=0 43606 RFM69:SWR:ACK,FROM=0,SEQ=126,RSSI=-56 43610 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=10 43616 RFM69:PTX:LEVEL=10 dBm 43618 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=33,pt=5,l=4,sg=0,ft=0,st=OK:30000 43778 RFM69:SWR:SEND,TO=0,RETRY=0 43788 RFM69:SWR:ACK,FROM=0,SEQ=127,RSSI=-59 43792 RFM69:ATC:ADJ TXL,cR=-59,tR=-80,TXL=9 43796 RFM69:PTX:LEVEL=9 dBm So when this occurs the only way I can think of to force another update would be update the sketch, refresh the repo in MysController and assign it to the node again. Therefore I wonder if this is intended behaviour and if so, if there is some other way to force an update after a failed one. Thanks.

@manutremo interesting results, thanks for sharing. This would probably apply to signed messages as well as FOTA, sine both use the full packet length.