Archived Forum

The same sketch gives sensible voltage readings on an Uno, so must be the 3 phase code not liking the Leonardo...

Tim.

Total Samples: 297 Power Samples: 282 Time: 232 Crossings: 22
254.61 
254.59 
233.65 
181.92 
123.43 
55.20 
-10.75 
-64.49 
-122.00 
-147.65 
-79.33 
-11.29 
42.54 
103.13 
157.49 
211.64 
246.65 
253.64 
Voltage: 237.61
 Current 1: 0.10 Power 1: 1.05 VA 1: 24.88 PF 1: 0.04
 Current 2: 0.00 Power 2: 0.00 VA 2: 0.00 PF 2: nan
 Current 3: 0.00 Power 3: 0.00 VA 3: 0.00 PF 3: nan

I wonder if you might be suffering from the problem discussed in this thread:  http://openenergymonitor.org/emon/node/10089.   If you are, and you're not using the RF stuff, that could well be another useful clue.  Robert's last post there said he was off to investigate if it might be in JeeLib, but if you're not using that,  and your problem is the same, you may save him some effort.

Here's a graph of the above set of samples, plus another couple from the Uno.  Computed voltage is in brackets in the key.  Uno 2 voltage is missing sorry, but I'm pretty sure it was about the same as Uno 3 (233 or so), and was taken a few minutes apart at a higher load time for this area vs. the Uno 1 samples which were from yesterday).

I haven't had time to look at the algorithm to see what it's trying to do, but the graphs basically look pretty funky to me, and I'd hope they're not an accurate representation of my mains voltage waveform (perhaps they're not intended to be tho)! :o)

Tim.

The waveforms don't look obviously wrong! Bear in mind that it's only necessary to record one sample more than 120° 240 ° so you will never have a complete cycle recorded.

[And I'm still trying to find time to track down that problem!]
When you wrote "...must be the 3 phase code not liking the Leonardo..." I stopped looking at your particular problem as I know nothing about the Arduino range, so I'd be most unlikely to be able to help you.

If you suspect it's something related to memory allocation, then the differences between the Uno and Leonardo may be relevant.  The Leonardo uses the Atmel ATmega32u4 with built-in USB functionality.

As a result, when the sketch I'm using is complied for the Uno (which has a separate USB <-> serial chip), the code size is 9134 bytes.  The same sketch compiled for the Leonardo comes in at 11788 bytes.

I'd guess the difference is the USB serial code (or maybe some boot loader code or something) which the Arduino IDE is including.

I just modified the sketch to allocate a static string (like this char *spacewaster = "blahblahblah [...] blah";) to push the Uno code size up to the same Leonardo.  The static string isn't referenced anywhere else in the code.

The Uno version now outputs garbage and sometimes chunks of the static string instead, but no useful output.

So the bug is memory related by the look of it.

Tim.

That's useful to know, thank you. I was fairly certain that was indeed what was happening, But I haven't had time to even check what's happened between the emonTx V2 with the old libraries, which worked fine, and the emonTx V3 with the new libraries, which appears to fall over for some people and not for others. I have only the emonTx here, I can't comment about the Arduino platform. What I'm looking to do is rework the sketch so as to reduce the memory demand, if that's possible.

I've done a bit of that, and shaved about 1k off the one I've got here.  I managed to restore the uno one to operation (whilst still having the big useless string in), but haven't got the Leonardo working yet (resolutely gives rubbish Vrms output).

FWIW, just turning off the LED blink stuff saved a chunk, once the number of digitalWrite() calls fell to zero...

Also worth making all the pin declarations, and calibration values etc. at the top of the sketch consts I think.

Doh, just realised I've been trying to minimise code size, instead of SRAM size (which is what's going to be in short supply).

Oh well, back to the drawing board.  Still the const thing is probably still a good bet I suppose.

Still the const thing is probably still a good bet I suppose.

That should help quite a bit, although obviously not as much as it does on a machine with an MMU.  The compiler treats pre-initialised constant scalar variables much like a #define.  Each time you reference it, the generated code loads up the original literal again, so regardless of what's happened to the RAM location, the original value will be used. 

You can see in the example below, I did manage to corrupt an element in a const array, although I had to work pretty hard to do it.  It was only when I finally randomised the index, that compiler stopped loading up literals, and was forced to use the corrupt RAM location.

const uint32_t test_array[] = {
  0x1000,
  0x1001,
  0x1002,
  0x1003,
  0x1004,
  0x1005,
  0x1006,
  0x1007,
  0x1008,
  0x1009,
  0x100a,
  0x100b,
  0x100c,
  0x100d
};
const uint32_t *cp;
uint32_t *p;
int index;

void setup()
{
  Serial.begin(115200);
  Serial.println("Hello world");
  index = random(0,13);
  Serial.print("index: ");
  Serial.println(index);
  Serial.print("test_array[index]: ");
  Serial.println(test_array[index], HEX);
}

void loop()
{
  cp = &test_array[index];
  p = (uint32_t*)cp;
  *p = 0xcafebabe;
  Serial.print("test_array[index]: ");
  Serial.println(test_array[index], HEX);
  delay(1000);
}

produces:

Hello world
index: 11
test_array[index]: 100B
test_array[index]: CAFEBABE

​

By contrast, on a unix machine with an MMU, the constant variables in the .rodata section are mapped to read only pages of memory, then you get instant notification of who's doing the corruption:

#include <stdio.h>
#include <stdint.h>

const uint32_t test_var = 0xdeadbeef;
const uint32_t *cp;
uint32_t *p;

main () {
  printf("Hello world\n");
  cp = &test_var;
  p = (uint32_t*)cp;
  *p = 0xcafebabe;
  printf("test_var: %x\n", test_var);
}

produces:

(gdb) r
Starting program: test 
Hello world

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400572 in main () at test.c:12
12      *p = 0xcafebabe;
(gdb) 

Looks like the cause of the bug is the readVcc() code, which doesn't work on the ATmega32u4 (and returns incorrect and fluctuating values).

In looking for the bug I made out a few other minor changes to the code to fix some compile warnings and reduce the SRAM footprint too.  I'll publish updated code when I get a chance - probably next week some point...

I'm not surprised, that (readVcc( ) ) has had many tweaks as new variants of the Arduino range have appeared.

The easy work-around, if you're using a mains supply, is to forget readVcc( ) and put the correct constant in its place for your dc supply voltage - given that the 5 V (?) regulator is stable. If it isn't, you'll need Plan A and add a patch to readVcc( ), because while the initial value of the internal reference is unknown to better than 10% (so a lot worse than most regulators), its stability, both long-term and under load and temperature changes, should be very much better than most regulators.