Archived Forum

The real problem is millis() is an unsigned long and it should go to 2^32 - 1, and then roll over to zero. So my first suspicion is your sketch is restarting before 5 s have elapsed. If your serial monitor prints

emonTX CT123 Voltage example
OpenEnergyMonitor.org

every time it transmits the data, then this is certainly what is happening, and that is wrong.

If you recompile with the latest emonLib, which uses a different (low pass) filter that is initialised to very near to its quiescent state, the requirement to wait for the filters to settle before transmitting the first results vanishes, and you can remove the variable "settled" and the conditional around the code that transmits the data.

e.g.

  // because millis() returns to zero after 50 days ! 
	  if (!settled && millis() > FILTERSETTLETIME) settled = true; 
	
	  if (settled)                      // send data only after filters have settled
	  { 
	    send_rf_data();                 // *SEND RF DATA* - see emontx_lib
	    digitalWrite(LEDpin, HIGH); delay(2); digitalWrite(LEDpin, LOW);      // flash LED
	    emontx_sleep(5);      // sleep or delay in seconds - see emontx_lib
	  }          

I'll give it a try

Well, it's not working. I've put the library .h file in the arduino folder and made the changes. Do i need to change the file emontx_lib.ino as well?

Why is it restarting? it's inside a loop..

The output is this

emonTX CT123 Voltage example
OpenEnergyMonitor.org
Node: 10 Freq: 433Mhz Network: 210
 ap1: 5 rp1: 0 pf1:

I'm writing a series of Serial.print but it only prints the first 3....

Has this been running ok and then just stopped or is it a fresh/revised install?

Which sketch are you using, is it "stock" or had you made changes?

What power supply are you using? if battery are they ok? could the power be dipping on an attempted send causing a reset hence millis() is always <5000?

Which IDE and Libs are you using, there have been significant changes to the arduino IDE and a lot of bugfixes implemented in later versions so early (in frequently used and tested) sketches may need tinkering with to keep them current.

Is it using a rfm12 or rfm68?

Paul

It just stopped working. It was working fine.

I've made changes based on the emonTx_CT123 sketch.

The IDE is 1.0.5 r2. I've only changed the emonLib library and that was today.

I'm using a rfm12.

The strange thing is that i haven't changed anything but it looks like it's always resetting.

It's operating continuously for the past weeks. So i shouldn't be the software or the IDE. Or even the base. So it must be hardware?? maybe the ac-ac went puff??

I've attached the sketch i'm using.

The led on the board stays on and then blinks after about 10 seconds...

Thanks

I forgot to mention that i'm using a 5v transformer to power it.

And now, i've disconnected the ac-ac and the 5v transformer. It's powered by the laptop and the result is the same

Maybe some problem with the memory on board, if it has any...

Any reset switch on the board?

I see there is a watchdog in the setup but I cannot see a "wdt_reset();" in the loop so it will only run for 8secs max before being reset by the watchdog.

Paul

In the original sketch there isn't one either although there is a wdt_enable.

So should i put the wdt_reset or should i remove wdt_enable? and where should i put it?

In the emontx_lix sketch there is this code:

void emontx_sleep(int seconds) {
  // if (emontx.battery > 3300) {
    for (int i=0; i<seconds; i++) {
      delay(1000);
      if (UNO) wdt_reset();
    }
  // } else Sleepy::loseSomeTime(seconds*1000);
}

and the sleep function is called inside the if at the end of the code

The watchdog reset is hidden inside emontx_sleep()

void emontx_sleep(int seconds) {
  // if (emontx.battery > 3300) { 
    for (int i=0; i<seconds; i++) { 
      delay(1000); 
      if (UNO) wdt_reset();
    } 
  // } else Sleepy::loseSomeTime(seconds*1000);
}

Is the sketch definitely restarting every 8 s? Your answer was not clear. You said it prints 3 values, but you did not say what happens after that.

It is restarting after 8 seconds.

I've put some println around the code and now it doesn't print everything. It should print

  Serial.begin(9600);
  Serial.println("emonTX CT123 Voltage example");
  Serial.println("OpenEnergyMonitor.org");
  Serial.print("Node: ");
  Serial.print(nodeID);
  Serial.print(" Freq: ");

But now it only prints what is on the attach. It seems i can't do a copy from the serial monitor...

I can't see a major problem with your sketch. It runs for me without restarting, with or without an ac voltage input.

What I have done to tidy up the print statements - because the characters were corrupted - is add a delay after each pair, e.g:
Serial.print(" ap1: ");Serial.print(emontx.ap1);delay(10);

This is the result:

emonTX CT123 Voltage example
OpenEnergyMonitor.org
Node: 10 Freq: 433Mhz Network: 210
ap1: 2759 rp1: -2772 pf1: -100 ap2: -8092 rp2: -8092 pf2: -104 ap3: 2869 rp3: -2868 pf3: -99 Vrms: 22629
ap1: 2758 rp1: -2771 pf1: -100 ap2: -8104 rp2: -8104 pf2: -105 ap3: 2859 rp3: -2865 pf3: -100 Vrms: 22622
ap1: 2769 rp1: -2782 pf1: -100 ap2: -8126 rp2: -8126 pf2: -105 ap3: 2863 rp3: -2872 pf3: -100 Vrms: 22662
ap1: 2753 rp1: -2766 pf1: -100 ap2: -8084 rp2: -8084 pf2: -105 ap3: 2858 rp3: -2867 pf3: -100 Vrms: 22614
ap1: 2760 rp1: -2774 pf1: -100 ap2: -8103 rp2: -8103 pf2: -105 ap3: 2860 rp3: -2869 pf3: -100 Vrms: 22639
ap1: 2767 rp1: -2781 pf1: -100 ap2: -8118 rp2: -8118 pf2: -105 ap3: 2868 rp3: -2877 pf3: -100 Vrms: 22662
ap1: 2778 rp1: -2791 pf1: -100 ap2: -8125 rp2: -8125 pf2: -105 ap3: 2872 rp3: -2882 pf3: -100 Vrms: 22713
ap1: 2752 rp1: -2766 pf1: -100 ap2: -8088 rp2: -8088 pf2: -105 ap3: 2853 rp3: -2863 pf3: -100 Vrms: 22600
ap1: 2757 rp1: -2770 pf1: -100 ap2: -8087 rp2: -8087 pf2: -105 ap3: 2862 rp3: -2872 pf3: -100 Vrms: 22624
ap1: 2761 rp1: -2775 pf1: -100 ap2: -8109 rp2: -8109 pf2: -105 ap3: 2865 rp3: -2875 pf3: -100 Vrms: 22645
ap1: 2765 rp1: -2779 pf1: -100 ap2: -8117 rp2: -8117 pf2: -105 ap3: 2866 rp3: -2876 pf3: -100 Vrms: 22663

So I think there is something wrong with your hardware.

The 5v supply and the ac-ac should be ok, since i'm running from my laptop.

I'm going to check all the connections and see if something got loose.

Are there any specific  checks i can make with a multimeter? Besides what's in the setup and build guide?

The first suspect is the power supply. Check the 5 V and 3.3 V supplies. Your V2 is nearing the age where a dry joint might have corroded enough to become intermittent, so (using a hand lens if needs be) carefully look at all the soldered connections. It could also be the electrolytic capacitor, but I think that's less likely. Also take a careful look at the processor's reset line, because the purpose of that is to cause a reset.

After some days working ok, i got the same problem. I've reconnected it to my pc and did some more tweaking. One thing i've put is a condition to check if the the variable CT1 is 1 or zero before defining the values for the calibration, etc.

Now it works ok, but i'm betting that in a few days it will revert to it's ill state.

I've changed the 5v usb transformer but it's the same thing.

Maybe the sensors  get static electricity, or something else and it does a feedback to the board? It has happened that i remove the 5v power and put it back again and it goes ok.

What does work better, is to resend the code, sometimes with some changes.

Actually i have the board on my side and it has been ok. All of a sudden the led lights up and then starts blinking normal again. Looks like something did a reset on the board.

The 5v power is from a charger of a smartphone. Can it be the problem? Or maybe the board is heating up?

The first suspect is indeed the 5 V charger. Read this and you'll see why I suggest that as the first thing to check. You'll find very, very many posts if you search for "noise". 

This "What does work better, is to resend the code, sometimes with some changes." doesn't make sense if it's worked for some time before you saw the fault. How long had your V2 worked before the problem appeared?

It could be static, what sensors do you have connected?

I assembled the V2 this year.

I have 3 sensors connected. One is the "normal" blue one. The other 2 are mini versions of that sensor.

"I assembled the V2 this year."
For how many weeks/months did it work correctly? 

What are the sensors, current transformers, temperature, ac adapter for voltage? Can you list everything you have connected? Where are they all located in your house?

I can list, yes. It will take a little time though.

The board is fisicaly near the Panel along with the sensors.

Does that Java program/arduino sketch to analyse the 5v works with the emontx V2?

"Does that Java program/arduino sketch to analyse the 5v works with the emontx V2?"
Sorry, I don't know that. I have never needed to use it.
 

I've comented the line rf12_sendWait in emontx_lib and the problem seems to go away. If i enable it, it restarts after a few seconds.

This means the transmitter is at fault?

Thanks

That's weird. The purpose of that is to allow time for the transmitter to finish sending, putting the processor into low-power mode while it does so. It would need a very careful trawl through the JeeLib code to see exactly what is happening there. Is the message being transmitted - you seem to imply that it is.

something is sent but the base can't read them. It gives unreadable content

If it just stopped working, the sketch hangs waiting for the transmission to complete, and the base can't read the content (presumably because the transmission didn't complete) but it used to, and it's not bad soldering, then it is looking like your RFM12B has died.

What you can do about that is a whole new problem. Do you have access to, or know anyone who has a professional rework station? Because unsoldering and lifting that module without damaging the main PCB is almost impossible. If you search the web, I have seen a suggestion to make a soldering iron bit out of thick copper wire, bent so that you can melt all 16 joints at the same time. I can't say that I think it would be easy to do.

I wonder if this could be the same as meso's problem (http://openenergymonitor.org/emon/node/11977) only this time with the wdog enabled?

rjsc2000, does yours come good after a power-cycle (which seems to be the only way currently available to reset the RF module) or is it permanently stuck in the 8 second wdog reset even after you're power-cycled it?

Well, There were times when powering the board off and then on again would make everything normal, but after a few days or hours, it would return to the same problem. And there were times when it would stay the same.

This all started when i noticed nothing was being sent because the of the millis function (see first post). After that i've removed the if statement.

dBC:
This is a V2, but meso and today's http://openenergymonitor.org/emon/node/12089 are both V3 (and presumably RFM69s).

Hi again

I've checked the voltage in the RFM12B board while working and blinking as it should, and they looked fine. After a day or so running, it locked again. Every 8 seconds or so, the board would reset and start over. I think watchdog detected the lock up and reseted as it should be.

I tested the voltages on the rfm12b again and the voltage was lower than 3.3 and sometimes zero.

But the board itself was on top of a table without moving and without being touched.

Anyway i've desoldered it and will try to connect it in another board....

I guess i'll have to buy another one and see if it works....

In the shop there's the 868 version. Isn't there the 433 version?

By special request in the notes on the order...

I just saw that RFM69CW they sell in the store is compatible with RFM12B.

If i want to switch will there be any major problems/modifications ?

Thanks

You'll need to remove the RFM12B module, which could be tricky. Are you talking about your emonTx V2? It's surface-mounted and if you don't have the proper equipment to remove it, you could very easily destroy your main pcb. Then it's a matter of setting the appropriate compiler directive ("#define RF69_COMPAT 1") so that JeeLib includes the correct code, recompile and reload the sketch.

So the major problem is likely to be physically getting the RFM12B off the pcb.