RFM95W MODEM_CONFIGRUATION
-
Hello ,
define MY_RFM95_MODEM_CONFIGRUATION is ok?
Beacause i test with #define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096
and RFM95_BW31_25CR48SF512.
I do this in Gateway and node but does'nt work.
I precise communication work verry well with RFM95_BW125CR45SF128.0 MCO:BGN:INIT NODE,CP=RLNNA--,VER=2.1.0 4 TSM:INIT 4 TSF:WUR:MS=0 6 RFM95:INIT 18 RFM95:PTX:LEVEL=13 20 TSM:INIT:TSP OK 22 TSM:INIT:STATID=12 24 TSF:SID:OK,ID=12 26 TSM:FPAR 28 RFM95:SWR:SEND TO=255,RETRY=0 3055 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 5064 !TSM:FPAR:NO REPLY 5066 TSM:FPAR 5068 RFM95:SWR:SEND TO=255,RETRY=0 5193 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 7202 !TSM:FPAR:NO REPLY 7204 TSM:FPAR 7206 RFM95:SWR:SEND TO=255,RETRY=0 10233 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 12244 !TSM:FPAR:NO REPLY 12247 TSM:FPAR 12249 RFM95:SWR:SEND TO=255,RETRY=0 15278 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 17287 !TSM:FPAR:FAIL 17289 TSM:FAIL:CNT=1 17291 TSM:FAIL:PDT``` -
I know it's a bit late but I just set up my RFM95 nodes and started playing. I did noticed something interesting when using RFM95_BW31_25CR48SF512 and RFM95_BW125CR48SF4096. The TX times are very long, about 6000ms long. Yet I think it's got something to do with packet retries.
The node reports an NACK status for each packet, however the gateway receives them just fine. -
Thanks i found a temporaly solution.
Change in RFM95.h this ligne#define RFM95_RETRY_TIMEOUT_MS (500ul) //!< Timeout for ACK, adjustments needed if modem configuration changed (air time different)by
#define RFM95_RETRY_TIMEOUT_MS (5000ul) //!< Timeout for ACK, adjustments needed if modem configuration changed (air time different)and change in Mytransport.h
#define MY_TRANSPORT_STATE_TIMEOUT_MS (2*1000ul) //!< general state timeout (in ms)by
#define MY_TRANSPORT_STATE_TIMEOUT_MS (30*1000ul) //!< 2 changed to RFM95W Ultra long Range enable general state timeout (in ms)and it work fine.
-
I just found this out yesterday but I can't recall exactly what value I changed. The only thing I do remember is that I change only one value, not two and then everything was fine.
-
@Al85 For me it worked only by changing:
#define RFM95_RETRY_TIMEOUT_MS (500ul)to
#define RFM95_RETRY_TIMEOUT_MS (2000ul)in drivers/RFM95/RFM95.h. And then both RFM95_BW31_25CR48SF512 and RFM95_BW125CR48SF4096 worked just fine, although RFM95_BW125CR48SF4096 has a whooping ~3000ms TX time per packet so not very feasible for battery powered sensors, unless the poll cycle is set to a an absolute minimum or even better is based on interrupts, like a door sensor.
-
@Al85 For me it worked only by changing:
#define RFM95_RETRY_TIMEOUT_MS (500ul)to
#define RFM95_RETRY_TIMEOUT_MS (2000ul)in drivers/RFM95/RFM95.h. And then both RFM95_BW31_25CR48SF512 and RFM95_BW125CR48SF4096 worked just fine, although RFM95_BW125CR48SF4096 has a whooping ~3000ms TX time per packet so not very feasible for battery powered sensors, unless the poll cycle is set to a an absolute minimum or even better is based on interrupts, like a door sensor.
-
I don't think the library is FCC compliant :smile:
Now seriously, there's no reason for MySensors to enforce such limit as the user has full control over the duty cycles of his sensors and RFM network, it's up to the user to abide to these regulations. In fact, for the battery sensors nodes it's actually recommended to stick to that rule. With ** RFM95_BW31_25CR48SF512** taking about 1000ms for a TX and ** RFM95_BW125CR48SF4096** taking about 3000ms, you'll kill the battery pretty fast if you'll use short duty cycles. All my sensors nodes at home send their readings minutely, but the RFM95 node sends a beacon every 300s and whenever an interrupt fires it. -
I don't think the library is FCC compliant :smile:
Now seriously, there's no reason for MySensors to enforce such limit as the user has full control over the duty cycles of his sensors and RFM network, it's up to the user to abide to these regulations. In fact, for the battery sensors nodes it's actually recommended to stick to that rule. With ** RFM95_BW31_25CR48SF512** taking about 1000ms for a TX and ** RFM95_BW125CR48SF4096** taking about 3000ms, you'll kill the battery pretty fast if you'll use short duty cycles. All my sensors nodes at home send their readings minutely, but the RFM95 node sends a beacon every 300s and whenever an interrupt fires it.@mihai.aldea I am not sure if MySensors should enforce the legal limit, but I think it is really important that the library makes it easy to stay within legal limits. If the library does nothing, I think it is likely that people will abuse the frequency band without even knowing. That's ugly.
With BW125CR48SF4096, 300s between each beacon you are already right at the limit of the duty cycle. Every message triggered with interrupt will make device non-compliant/illegal.
Almost all MySensors example sketches send data more often than will be ok, which I think will lead to most users inadvertently abusing the band.
-
I am ham radio licensed operator so I'm very much aware of the regulations. However we should not forget that this is an open band and as such no mission critical devices will run on these frequencies. FCC drafted these regulations to prevent some donkey to keep the channel closed by using 80-90% duty cycle and prevent all others from using it. However juding strictly from the MyS perspective, this is used by hobbyists and while many would put a dumb grim on their faces when using RFM95_BW125CR48SF4096 we should not forget that most of them work indoors, behind rebared walls and use poor antennas, so in real life there's really no impact on the band as their signal will not take off pretty far. And we can all agree that a when a Yagi is involved, those are most likely responsible experienced engineers who will know better than to block the band with their temperature sensors :laughing:
I'm not condoning in any way the abuse on these bands, but all I'm saying that I see no reason for MyS to enforce these limits. -
I am ham radio licensed operator so I'm very much aware of the regulations. However we should not forget that this is an open band and as such no mission critical devices will run on these frequencies. FCC drafted these regulations to prevent some donkey to keep the channel closed by using 80-90% duty cycle and prevent all others from using it. However juding strictly from the MyS perspective, this is used by hobbyists and while many would put a dumb grim on their faces when using RFM95_BW125CR48SF4096 we should not forget that most of them work indoors, behind rebared walls and use poor antennas, so in real life there's really no impact on the band as their signal will not take off pretty far. And we can all agree that a when a Yagi is involved, those are most likely responsible experienced engineers who will know better than to block the band with their temperature sensors :laughing:
I'm not condoning in any way the abuse on these bands, but all I'm saying that I see no reason for MyS to enforce these limits.@mihai.aldea good point that the signals probably won't disturb the band that much.
I am not at all worried for people like you who know what they are doing and have the knowledge to be responsible. What I am worried about is the"noobs", which very much is the target user group for MySensors. They will use the example sketches with no or very small modifications, and they won't know that they might be messing up the band.
I would prefer that MySensors is user friendy to noobs, which imo includes making it easier to do the right thing than to do the wrong thing.
-
Well, this makes sense. And after all, if you're smart enough to tweak the lib and bypass the restrictions, chances are you know what you're doing both with the coding and with the radio spectrum.
