Stops sending after 4 hours

Started by ShadowGrass, March 09, 2014, 10:03:52 AM

john k2ox

If it hears signals from 'foreign' radios, it will not transmit. 

As I mentioned before, use the WDT.

I have a Moteino 1200 ft behind my house in the field in a plastic bucket that has not had a hick up since being deployed in mid December.

I would read the signal strength, rssi, to make sure they can hear each other.  I also posted the spectrum showing hundreds of signals from others radios in the 'ether'.

Felix's lib will keep a radio from transmitting if it hears other signals on the frequency.  I disabled this in my code, because I use one Mote as a 'Master'  and all others are 'slaves'.  The 'Slaves' only transmit when replying to the 'Master', thus no collisions.  My current project will be event driven by the nodes though.

If you have a lot of signal strength from the well shack,  you can set the TX threshold higher  to ignore the weaker ambient signals.

The other thing I try to do is have the remote node is dumb as possible and put as much decision/smart code in the radio that is in my house.  It's a lot easier changing things inside and not having to travel back and forth.

If you only have two radios, can you swap the indoor and outdoor radios and see if the issue follows the radio.

Just a bunch of ideas.

john

ShadowGrass

QuoteFelix's lib will keep a radio from transmitting if it hears other signals on the frequency.  I disabled this in my code, because I use one Mote as a 'Master'  and all others are 'slaves'.

Interesting point, I didn't know this.  How would I go about that? In my scenario, I don't think my slave should listen at all, only send.  The master should be the only one listening. 

I have an excellent signal from the well house, it's only about 100' away, going through 3 stick/drywall walls.

The WDT function is also interesting.  I would like to try disabling the listening on the slave and possibly increasing my TX threshold (not sure where to do this either).  If this doesn't resolve it I will go the next step and try the WDT route.

Much thanks on the help.

Felix

Hm, the fact that it randomly stops leads me to believe it's not the radio that's the issue. But not saying that's impossible. It's a bit hard though to pinpoint the issue because even looking at hardware there are other "unseen" factors like noise which John mentioned.
How do you power the Moteino?
As John suggested, would it be possible to swap the units or use another one on the outside to try and narrow down if the issue is hardware related?

ShadowGrass

This is what I have:

Power is a 5v 500mA wall wart to Vin and Gnd.
Two relays in typical resistor, transistor, diode configuration, output.
One controls 120v ac heat lamp.
One controls 12v bilge pump (not currently connected)
One DS18B20 using OneWire in non-parasitic.
One photocell with 10k pull down resistor, input, analogRead.
Float switch with 10k pulldown resistor, input, digitalRead.

I thought maybe the AC could be bothering it or the relays.  But there is no switching when it fails, and I'm pretty sure that point would have been raised already.  I mean, the lines aren't touching the antennae but it is within a couple inches. 

I don't have another board to replace the one that is out there.  I could switch the two, but that would be very involved.  I will leave that as last resort.

Felix

Ok, one last thing, can you please try this RFM69 library variant that I posted in this message: http://lowpowerlab.com/forum/index.php/topic,380.msg2108.html#msg2108
I am suspecting some issues with some changes I made that makes the radios less stable. The user that raised that topic reported that this older version makes them loose far fewer packets.

There's still a potential for RAM issues, or other things. We could try another Moteino on there and that should yield some more clues. But please try the older version of the lib and see if that makes a difference. Thanks

ShadowGrass

The library change did not correct the problem. I guess I will try to figure out John's suggestion on increasing the TX and possibly implementing WDT.  I feel this is more of a patch than a fix however.  Regardless I need it to run, and run reliably, so at this point whatever it takes for that to happen.  It ran about 2 hours after the library change.

ShadowGrass

#21
Quote from: ShadowGrass on March 11, 2014, 03:04:23 PM
QuoteFelix's lib will keep a radio from transmitting if it hears other signals on the frequency.  I disabled this in my code, because I use one Mote as a 'Master'  and all others are 'slaves'.

I found another post where John provided code on how to do this.  So I made the change to my library and loaded it.  It has been running since about 8:40pm last night, so going on 13 hours.  This is one of the longest runs so far, so hopefully it continues.  Just to reiterate what happens, the radio on the sender in the well house goes off, as in no led showing that it is sending, as it could be in a sleep or shutdown state.  If this doesn't work I'll get down there with my laptop this weekend and add some debugging lines to see what exactly is going on.  I was not able to increase my TX as I do not know how, I looked through the library and it looks to me as if it already at the max.  I didn't change any of that, so whatever the default in the library is is what I am running.

Thanks.

john k2ox


ShadowGrass

Yeah, me too...you can watch it live, that is the only way I know it is working.  If Exosite stops getting updates, then you'll know.  I have it send me an e-mail so I may know a little before you.

https://portals.exosite.com/views/1557739845/3656177209

ShadowGrass

Still going.....18 hours  and still tickin.  The best showing yet. 

john k2ox

Cool.  I was just looking at it on Exosite. 

I don't know if you have seen this http://lowpowerlab.com/forum/index.php/topic,255.msg1205/topicseen.html#msg1205 ,but I think it might be what is causing problems.

If you just let a Moteino print out RSSI values every time it goes above a threshold you can get an idea of how much activity is on that frequency.

Moteino's have a lot of neighbors sharing the spectrum.

Good luck!
john

ShadowGrass

It died at 5:16pm. 
I have the 433MHz variant.  I don't have really any knowledge of how radios work, frequency, antennas etc.  Your solution was to move to 933.05, so are you suggesting I try 433.05?  I don't know where to set that.  I was going to see how to boost the power as well. 

In my program I have:
#define FREQUENCY RF69_433MHZ


In RFM69.cpp I see this code, would I change something here?:
/* 0x07 */ { REG_FRFMSB, (freqBand==RF69_315MHZ ? RF_FRFMSB_315 : (freqBand==RF69_433MHZ ? RF_FRFMSB_433 : (freqBand==RF69_868MHZ ? RF_FRFMSB_868 : RF_FRFMSB_915))) },

In RFM69.h I see:
[code]#define RF69_433MHZ     43

    /* 0x08 */ { REG_FRFMID, (freqBand==RF69_315MHZ ? RF_FRFMID_315 : (freqBand==RF69_433MHZ ? RF_FRFMID_433 : (freqBand==RF69_868MHZ ? RF_FRFMID_868 : RF_FRFMID_915))) },
    /* 0x09 */ { REG_FRFLSB, (freqBand==RF69_315MHZ ? RF_FRFLSB_315 : (freqBand==RF69_433MHZ ? RF_FRFLSB_433 : (freqBand==RF69_868MHZ ? RF_FRFLSB_868 : RF_FRFLSB_915))) },
[/code]

john k2ox

I moved mine to 915.05. 

Bummer.

One easy question.  Do you have CRC check enabled?

ShadowGrass

Right, 915.05, mistyped.  Should I move mine?

What appears to be an easy question for you is Greek to me.  I have no idea, I don't have anything in my sketch that says CRC..

kobuki

Well, to sum it up a bit. Your transmitter is still stopping after an indefinite amount of time. You have disabled the "band is jammed" check in the code so your code is transmitting unconditionally. Yet it still stops. I think that shifting the frequency would not help here since it's the transmitter that stops evey time. Resorting to the watchdog is not a solution, but a workaround, but you're already aware of that.

If you could swap the receiver/transmitter Moteinos, that would help in identifying a hardware problem. And I still think that the highest chance you're dealing with is a hardware problem. Either just a faulty/slightly out of spec RFM69XX module, the slightly overclocked Moteino, or the sum of both. Maybe a sudden, unfiltered spike from the mains supply. Do you have any powerful power consumer in the same socket as the TX Moteino, by any chance? Could you try powering the TX side from a battery?

Sorry that it's just a bunch of ideas, but the random nature of this error you described very much resembles a PC problem casused by faulty HW I have dealt with over the many years I was working with them. I can't help but draw the parallels.