Thanks again Felix. I think several things may need to line up to see this happen, but it's easy enough to trigger intentionally and was happening enough to cause major headaches for me. If the battery is small enough, maybe it just won't provide enough current when discharged this far to actually tx, so it doesn't happen. AA batteries seem work just fine to cause it. The other details are using stock 300kbps radio settings at power 20, 915MHz HCW radio, sending(not with retry) packets of 60 bytes payload, 12ms delay between packets.
For the major headache, there are hundreds of these guys potted in urethane sitting in a field that takes a passport to get to, so its not exactly a quick trip down to the sewer sump pump to change the battery if one happens to die. I do have remote monitoring of battery but not someone who could always catch it in time, and no big deal anyway i thought, they just go dead and you lose one damaged unit, right? The AA pack is good for a year or more in this ap if everything works as it should, I only need a couple months, but that only happens in theory. This type of thing is very predictable a wise man once told me with the help of charts and graphs. A rodent or field worker will damage something, rain gets in, pack drains faster than expected, 200 units in the dark, plane ticket purchased, its Murphy's law.
For anything I do in the future, I will either have control of the power to the radio (best?), or at a minimum a pullup resistor on the radio reset so that the MCU has to assert a pin for radio to be operational. My understanding is that if a brownout reset happens the pin goes high impedance, pull-up should hold radio quiet, but the pullup will always be consuming power, so a switch on radio power may be best.
I assumed Motino would die quietly, not always so. If in TX when MCU browns out, it can stink up many MHz of the band with plenty of power. If you transmit infrequently or short packets it may be impossible to trigger, dont know, but when it happens it happens hard. The lesson for me is having the radio (that can break the law) fully operational when its controller can go out to lunch in the middle of the transaction is probably a poor choice. Checking for the lack of regulated voltage before transmitting seems to solve the issue for me, but an auto-reset or RFM power down in hardware would be way more solid, I just don't have the option anymore without replacing a bunch of stuff. Its slightly cumbersome to check your shoes to make sure you have enough leather each time you plan to cross the street, but it fixes the problem. Maybe there is a better way in code, this is what I call before TX:
void antiDeathRattle(){
ADMUX = B01011110; // Measure 1.1V internal source
delay(3); //delay for 3 milliseconds
ADCSRA |= _BV(ADSC); // Start ADC conversion
while (bit_is_set(ADCSRA, ADSC)); //wait til complete
uint16_t batLevel = ADCL; //get first half
batLevel |= ADCH << 8; //get rest (always read low first)
while(batLevel > CUTOFF_BATLEVEL); // hang here, DO NOT TX
}
CUTOFF_BATLEVEL of 370 is what I'm using, anything decently over brownout to cover the TX drop should do. Hopefully this helps somebody. The hard part, at least for me, is realizing this is what was happening. If it happened at lot, it would have been discovered in 2 years of development. When the numbers went up, it happened plenty enough. If it can happen at all and the result is accidentally putting power continuously on someone else's commercial band, probably a pseudo problem best avoided. I could be comparing notes about how radio authorities in 2 countries ring you up, explaining how its not actually hosing the band for hours, it just seems like it is. Would be nice to know if there are other things that might trigger this condition. Sounds like Tom and Dan have some idea what I'm describing here. Maybe anything that locks the Atmel (call it MCU if you like) during TX could cause this? Arduinos I2C libraries are good for hangs, so that maybe checks out, but the regular watchdog will catch that as far as I have seen, possibly hanging the RFM. If that happens RFM is likely unrecoverable without reset/cycle and wailing the whole time. In brownout you have no control, so it's see it coming or hardware failsafe the radio. Don't think you can talk to the radio without a reset/power cycle after it starts wailing, so on something permanently powered if it can be triggered, then you might just need to cycle the power to the whole building every few days to a month, that's normal. You know how the 'fruit folks breakout and use the RFM reset? A waste of a pin and precious time I thought, well no more. Oddly that board won't init if you don't tickle the reset, dunno. I think most or all is solved if RFM is hard reset when MCU resets either from brownout or watchdog. Not having full authority over the radio may work OK if you send a byte if the mail comes today, still not good, but if every I2C hang requires power cycle to restore the network, ugh. As long as you don't let your battery get too low, or never watchdog reset, maybe never see it. If you live in the real world it happens at least to some of us, can't be recovered without a cludge wire to reset or power cycle, and I don't think what I see on the radio spectrum could be anything close to legal. Can't miss it, its impressive and will swamp at least 2MHz of the band either side, drowning traffic until something intervenes. For me anticipating brownouts in code works, maybe for somebody else an I2C library with timeouts would prevent resets during TX, but relying on software for this is a bandage. With all the grey hairs this has given me, I would happily lose a pin to gain a radio enable that must be asserted by a happy MCU, but my hardware is locked in at least for a while. If yours isn't, my advice is to have hardware that will keep the radio quiet if the MCU is sad. Otherwise, it will probably work, probably be legal if you tell it to be, and probably not wreck the whole network from time to time. Since I will definitely need work in the future to keep living indoors, I'm definitely never counting on this particular probably again if I can help it.
