Photon vs Argon/Xenon for emonlib

Hey all, just wondering about something. I had setup a simple little implementation of emonlib on my Argon and it was working great. I then moved the whole thing to a xenon and it doesn’t work anymore. Just wondering if anyone can think of any reason why something like that wouldn’t work on a xenon vs an argon?

@doubleopinter, the Xenon (a deprecated product which is no longer sold) doesn’t have WiFi like the Argon which is the most likely reason it doesn’t work. To work correctly you would still need an Argon mesh gateway or put the Xenon in a Particle Ethernet Featherwing. I suggest sticking with the Argon.

Hey, thanks for the reply. The xenon is setup to talk to the argon which relays everything out via mqtt. I was wondering if there is some hardware difference between the two which would prevent it from reading properly. I’ll have to connect it all up to the argon again and see if something fried I suspect.
And yes I know they are deprecated I just have a little project that I can use these little devices on so why not.

@doubleopinter, the emonlib code would need to use UDP or mesh publishes to the Gateway Argon to work. The code is probably expecting a direct connection to the internet which it will not get via mesh.

Well, it doesn’t seem like emonlib works on xenon. I loaded the exact same code on a photon and off it went beautifully. I misspoke earlier, I set it up originally on a photon not argon. I wonder if this works on an argon.

@doubleopinter, it should work on the Argon. Give it a shot and see what happens!

Same thing as xenon actually, very odd. Trying to figure out what’s going on.

@doubleopinter, which DeviceOS version are you trying it with? How are you compiling (CLI, Web IDE, Workbench)?

I’ve been using 1.52 and using workbench, mostly doing cloud compiles.

So, assuming it compiles, what exactly does “dosen’t work” mean? Do you have any diagnostic Serial.prints that could help determine the cause?

The readings that is produces are incorrect, it’s just completely unstable and inaccurate. Honestly, it seems like the emonlib is counting on some kind of hardware specific spec to calculate the correct number.
On the Photon the VA reading is almost exactly what my KillAWatt shows. On the xenon and argon the number keeps floating around. I have it printing the reading to CLI every second and where on the photon the number is always around 43VA, which is correct, right now on the argon it goes 43, 48, 53, 67, and then it seems to start coming back down again. It’s actually behaving quite well right now, up until now the readings would be like 12. I’m trying to poke around in the library code to see if I can figure anything out.

@doubleopinter, interrupts are faster on the Photon than the Argon. The latency on the Argon may be the cause of the drift, assuming the code uses interrupts.

1 Like

So in reading through the original post of the guy who ported this it certainly seems that there is a dependence on hardware sample rate. The function which you call to do the measurement takes a “number of samples” parameter and I think that depends on the ADC sample rate. Hmmm…

That sounds a bit fishy. Can you share the code or a link to it?

Good morning. So this is the code from the semonlib (which is a slightly modified version of emonlib, which works on the photon just as well as emonlib). This is the code which actually takes the measurement in the library. The call to it is pretty simple, emon.calcIrms(1480). Same code, same libraries, same calls, same setup, works great on photon but not very well on argon/xenon. I put in the millis calc in this and on photon it takes 501ms to run this block of code where on the argon it takes 425ms. I also found some really interesting docs for IO. I noticed that for Photon/Electron the docs state that the analogRead() function actually samples 5 times and returns some kind of average by default and you can use that set ADC read function to change some params on how ADC reads. There is no mention of this for the Argon/Xenon.
Anyway, I appreciate your input but I would say that this is not important enough to get involved with. Porting this to Argon/Xenon is beyond my abilities and its not important enough right now. It’s just a curious artifact at this point. I will use my proton and look for something else for the second meter I need.

float EnergyMonitor::calcIrms(int NUMBER_OF_SAMPLES)
{
  
  int SUPPLYVOLTAGE = 3300;                        //SPARK delete readVcc();
  int startMils = millis();

  for (int n = 0; n < NUMBER_OF_SAMPLES; n++)
  {
    lastSampleI = sampleI;
    sampleI = analogRead(inPinI);

    delayMicroseconds(250);                //SPARK this delay spaces samples to allow phase correction
    lastFilteredI = filteredI;
    filteredI = 0.996*(lastFilteredI+sampleI-lastSampleI);

    // Root-mean-square method current
    // 1) square current values
    sqI = filteredI * filteredI;
    // 2) sum 
    sumI += sqI;
  }
   Serial.println(millis() - startMils);
  float I_RATIO = ICAL *((SUPPLYVOLTAGE/1000.0) / 4096.0);
  Irms = I_RATIO * sqrt(sumI / NUMBER_OF_SAMPLES); 

  //Reset accumulators
  sumI = 0;
//--------------------------------------------------------------------------------------       
 
  return Irms;
}
1 Like