Archived Forum

Did your emonTx V3 work "out of the box"? It should have had the standard "discreteSampling" sketch loaded.

As you've obviously overwritten that, it's not a lot of help now. The easy way to force the serial output on is to insert a line immediately after "if (Serial) debug = 1; else debug=0;"

debug = 1;

Robert

Thank you for the quick reply.

I was just getting the solid LED out of the box, hence the update of the firmware.

I have added in the "debug=1;" but still nothing came up in the serial monitor.  I have tried a couple of resets just in case that kicks it in to action. Again, still just the solid red led.

Is there a simple sketch kicking round just to trigger the radio?

Many thanks

Gary

Not that I know of. The V3 has only just been released, so you're in the vanguard. It's time to learn some programming!

Start by making a copy of the sketch you're using which I think is "emonTxV3_RFM12B_DiscreteSampling.ino", then let's first prove that it is the radio that's holding everything up. You need to take out these lines / sections (doing it this way because I know that the radio can fail to complete its set up and there it hangs):

rf12_initialize(nodeID, freq, networkGroup);                          // initialize RFM12B
   for (int i=0; i<10; i++)                                              //Send RFM12B test sequence (for factory testing)
   {
     emontx.power1=i;
     rf12_sendNow(0, &emontx, sizeof emontx);
     delay(100);
   }
  rf12_sendWait(2);
  emontx.power1=0;
  rf12_sleep(RF12_SLEEP);

and down near the bottom:

send_rf_data();                                                       // *SEND RF DATA* - see emontx_lib

If it now puts the LED on for 10 s then flashes it 10 times, we know it stuck somewhere inside that first piece of code you took out, and it should now print to the serial port that the RF is 433 MHz etc - it's lying! And then it should carry on working normally except of course nothing will come over the radio link.

If that's the case (and it's a brand new V3 from the shop) then email the shop and let them know. (Is your RFµ on headers or soldered in?) It might be worth checking the soldering on the RFM12 module first - with a powerful magnifying lens look for bad joints and whiskers of solder. N.B. There's one connection not soldered - you can just see it on the picture on this page: http://openenergymonitor.org/emon/modules/emonTxV3.

Why I'm pretty sure it's in there: Look for lines like "digitalWrite(LEDpin,HIGH);"  That puts the LED on, "LOW" puts it off. The Led is turned on immediately before that block of code, and if it sticks in there, the LED never goes off. If that code isn't there it delays for 10 s here: "Sleepy::loseSomeTime(10000)" (that's 10,000 mS) then it turns the LED off. Then a bit further down it does a loop 10 times and the LED is on for 200 ms and off for 300 ms.

I will send you a replacement RFu328 + RFM12B to see if this fixes the issue. Please post result on the thread.

Cheers,  

Glynn

Thank you, you don't get customer service like this many places - will let you know as soon as I can.  Did you want the current want sent back so you can have a look at it?

By the way, the emonTH standard sketch was a great help in cobbling together a moteino based  temperature monitor using a DHT11 for the moment.  The comments were a great help in working out the bits I needed to tweak to use the standard Jeelib library.  I have added a copy in case anyone else might find this useful.  I also knocked together a quick barebones sketch for the Tx to check the temp sensor when I was troubleshooting.

Have a great Christmas

Gary

Glynn

Brilliant customer service - the replacement Rfu module arrived yesterday and have just managed to give it a go and it is working flawlessly - now to get some feeds sorted out.

I had a go at touching up the soldering on the original RFM12B connections but no luck - I suspect the RFM12B is defective.

Once again, some great customer service.

Gary