Hi,
First of all let me thank you for this superb lib :), im really loving this rfm69 modules :) .
After i got my two rfm modules to work , one acting as a trasmitter (just sends messages) and other acting as the reciever (just recieves messeges) i left both modules working for hours but some times they stop communicating, it seams like for some strange reason it is blocking on the method "sendWithRetry" on the transmitter side, but strange enough if i restart the reciever the transmitter continues like nothing bad happened.
Is it suposed on any ocasion for the method "sendWithRetry" not to return?
Does anyone had a similar problem before?
Im scratching my head on this, and i would really love to get this to work 24/7.
Thanks in advance.
Best regards,
João Ladeira.
Thanks, Joao.
I haven't seen such behavior. It's hard to say why without adding some debugging code or better - using a logic analyzer.
So are you using a Moteino? What kind of modules do you have RFM69W or HW? Did you get them from me?
Hi Felix,
No unfortunately i only found your site after i got my rfm69hw modules (if this doesnt work out im thinking on buying two moteino's from you) but for now i just have two rfm69hw and two atmega328.
Yesterday i jumped right into action coding all my needs for my little project (simple transmitter hooked on two bateries that sleeps for 8 seconds and transmits sensor data when wakes up) and the reciever is always on and communicates with a netduino trough i2c.
But since after a couple of hours (more than 3) the transmittion was being stoped for some reason im now reverting back and right now i just uploaded again the gateway and node code to both atmega's, hoping its some bug in my code.
If this doesnt work maybe its a bad connection on the circuit but i dont have a clue on what may be wrong, i atached pictures of the transmitter and reciever(sorry for the bad quality but i had to resize and compress so that the filesize dont exceeds 192 forum limit).
Best regards, and keep up with the good work :)
Hi,
So i think i found the problem, one of the RFM modules was faulty.
I figured that out on an atempt of implementing the rcCalibration method when there were temperature changes of more than x degrees, when i was testing if the temperature changed just a little (or for some strange reason i just put my hand on top of the module without touching it) the reciever stoped responding and was always breaking on the "sendACK" method, most probably on that while loop inside of it.
Fortunattly i had another new rfm69 module laying around and after replacing with that new one at least now i cannot replicate the above, so i will leave this runing over night and see if that solved the issue, i will give and update tomorrow on this if everithing is ok.
Thank you for your help Felix, and once again, keep up with the exelent work with the lib and moteino ;)
Thanks for the update. It's actually not very surprising to me that it can happen because the RC oscillators can shift in frequency response with temperature variation, just enough that they will not talk on the same channel any more.
But it can also be because of a faulty chip like you said. It's really hard to track down these kinds of bugs really identify the root cause. Most times if I have something like this it's not worth the time to spend one or two hours trying different debugging techniquer or a logic analyzer only to realize it's a bad chip, but rather throw it away and use another one.
I did notice that on the HW chips they have a higher rate of weirdness/faultiness. I don't yet know for sure if it's the hardware (but I suspect it is because the difference in behavior when keeping all other variables the same) or it's some slight firmware setting that could be tweaked to improve things. But most chips work just fine. I do my best to test out all Moteino+RF chips before shipping out, but not much I can do on individual chips.
Hi,
Just to close this thread i can confirm that now it has been running for almost 18h now without any problem, so that was really the problem :).
Yes also another thing i noticed was tat the temperature reported by that faulty chip was higher that the good one, for example the good one was reporting 22 C and the faulty was reporting 31. It could have been also because that the faulty one was the first i soldered in several years :p so it could also be my fault when soldering it.
I cannot thank you enough for this lib, im really having a blast with this modules and they have really long range :) i'v got 300m without any problem with the receiver inside my house and me outside walking.
Great to hear, thank you for the feedback, much appreciated!