Archived Forum

First question: do you have any genuine 3-phase loads (i.e. motors), or are they all single-phase loads connected to one of three phases?
Second question - what is your system voltage (phase-neutral)?
Third - Do you have 3 ac adapters?
Fourth - How are the loads that you want to individually measure split across the three phases?

Depending on the answers to those, I suspect the most simple and accurate way for you is to use one emonTx per phase, running the "continuous" sketch. The three TX's won't report their results synchronously, so you'll get 3 sets of 4 readings going to both your RPi and to your GLCD. (No, the GLCD gets its data direct from the emonTx's by default). You'll need to modify your GLCD sketch to listen to all 3 emonTx's, and maybe combine some of the values. You cannot get too ambitious in the GLCD, memory is extremely limited.

First alternative: It should be possible to send the data back from your RPi to the GLCD - Paul (PB66) might be able to confirm that, and what processing can be done in the RPi

Second alternative: If you don't have two infeeds + 2 separate loads per phase, then you've got to do some fiddles to shift the voltage waveform to be synchronous with the load on the 'other' phase. That will need a new sketch (a merge of the 'continuous' and 'three-phase').

I don't want to go any further until you've thought about that.

Thanks Robert,

1. I have no 3 phase loads.

2. 240v (new Zealand)

3. yes have three ac adaptors

4.

phase 1 - hot water

Phase 2 - Oven & Pool

Phase 3 - everything else.

In that case, my main proposal will give you the 3 nett grid connection powers/energies, the 3 PV infeed powers/energies, then separately Oven, Pool and the option of splitting everything else into two groups. Note that you can uprate the 4th input on your emonTx V3 by adding a parallel resistor to the existing burden, should you need to, and if "everything else" is on separate feeds, then provided it's physically possible you can put several wires through the CT and get the total current that way. (They must be the same phase of course, else you get the vector sum, which isn't what you want.) You will have a spare input on the Phase 1 emonTx, it sounds as if you're happy with that.
Alternative 2 looks to be dead. We'll prod Paul if you're keen to look at Alternative 1. The GLCD gets the time by that route anyway, and its sketch will almost certainly need some work done, depending on how much detail you want to display on it.

Sending data out over RFM from emonHub is possible. The current version only sends the time update for glcd (there is also a "hack" to add PacketGen) but this is a big part of current developments and will hopefully be widely implemented in the not too distant future.

We could in the mean time add a very simple "PacketGen like hack" to "fetch" the data you need from emonCMS and broadcast it, this may add a couple of seconds to the responsiveness but it will also allow the data from 3 phases to be sent to glcd via 1 payload rather than 3 so should help with the limited resources at the glcd end.

Aligning the data of the 3 phases maybe something you want to consider, not just for the glcd display but for the whole project, Maybe you also could use the glcd transmission from emonHub to trigger or align the 3 emonTx's.

​Happy to chip in where I can if needed

Paul  

I haven't looked at Robin's 'continuous' sketch with a view to synchronising the totals, presumably the 3 emonTx's are close together and I'd have favoured extending MartinR's "full-fat" serial comms solution - where the master synchronises and requests data from the others and only itself transmits, in preference to receiving synchronising commands by radio. But that'll need developing, Martin did 'discretesampling', not continuous.

Unfortunately I²C isn't an (easy) option with the emonTx v3 as A4 and A5 are already used.

Shame really as I already have a working I²C set-up where the Pi is the master and a number of emonTx v2 based boards are "polled". The method I use is possibly the closest we will achieve to absolute identical timing as the Pi broadcasts a calculations trigger and then collects the payloads one after the other during the interval.

It reminds me of school and written exams, the Pi screams "times up, pens down" and then goes about collecting "the exam papers" at it's own pace. Do they still use pen and paper in exams these days?

Paul

Hi Guys,

This is all new to me so please be patient.

Thanks for your responses. I'm thinking that i get the correct data out of the system before I start playing around with getting the GLCD running.

Photo attached of the three emonTx's installed, ignore the labels on them as they are now incorrect.

As you can see from those labels in the photo, that was how i have planed to monitor the power and have them set up.

What we are saying now is I can only monitor circuits on the emonTx that are on the same phase?

Node10: CT1=Grid1, CT2=PV2, CT3=Hotwater

Node11: CT1=Grid2, CT2=PV2, CT3=Lights, CT4=Garage

Node12: CT1=Grid3, CT2=PV3, CT3=Oven, CT4=Pool

Do the AC adapters need to be powered from there own phase also?

They do indeed need to be on the same phase as the current clamps, effectively each emonTx is specific to one phase only.

Thanks,

So i have some work to do, I'll add three power points to allow the AC adaptors to be connected to each of there own phases.

and to ensure i can use all the inputs from the emonTx's, I'll shift something from Phase 2, lighting perhaps,(everything else) to Phase 1 which currently has only the hot water.

I'll upload MartinR's "full-fat" sketch and see what results i get.

Good to see another Kiwi on here pushing the boundaries ;). Welcome from ChCh.

Thanks for the welcome from Waikanae, Wellington.

I'm locked out again.

Hi there,

best regards from Germany to all Kiwis out there... I love NZ... ;-)

@pb66: I am also heavily interested in sending data from emoncms to an emonGLCD. Could you point me in the right direction what to do to transmit a feed value via emonHub? How to implement this "PacketGen like hack"?

Thank you very much

Matthias

"I'll upload MartinR's "full-fat" sketch and see what results i get."

I don't advise that! It is for the emonTx V2, therefore all the I/O pin numbers will be different, the radio is probably different and might need a different JeeLib, and there are problems with the serial data connection as Paul points out.

The reason for suggesting that each emonTx deals with one phase only was accuracy. The AC adapter is both a power supply AND a voltage measurement. The emonTx 3-phase sketch makes an educated guess at the voltage of the 2nd & 3rd phases - see the comments in the sketch for the details and the side effects. Keeping one emonTx per phase removes all those errors/guesses.

@Matthias, Sure, if you want to start a thread with some details we can see if we can throw something together, it will be just a hard-coded "hack" though, a better solution is in the pipework.

​Paul

Hi All,

So I have now installed the three power points one on each phase.

I have left the default emonTx sketch on each of the emonTx's.

I have not yet replaced the labels on each of the emonTx's, so they are incorrect still.

So i have been watching the PV outputs, they do not appear to be correct, the inverter is saying its producing 213Wand the emonTx's are saying 154W.

[Hopefully, normal service is resumed, and I can answer now!]

Something's not right there. Is it just the PV inputs, or is everything wrong by the same factor?

First, are you on the right phase? And have you checked the calibration? The numbers don't appear to have the right relationship for just one problem (like phase, where I'd expect a factor of cos(120°), and it's far too far out to be a straightforward calibration discrepancy, so I don't have an immediate solution, and some detective work is required.

What ac adapters are you using (what is the output voltage at what mains input voltage?), which CTs are you using?

Is the 3.3 V d.c. on your emonTx's roughly right?

Not sure about anything of the other inputs, as I'm not sure how to messure them.

What I'm doing is adding the 3 PV outputs that are being measured by the three emonTx from the input display of emoncms and comparing there total to what the inverter is telling me. see attached.

Is this the correct way of checking it?

How can i check what is on each Phase and compare it to the inputs on emoncms?

I'll double check to ensure i have each clip on the correct wire,the board is a mess so its hard to locate the correct one.

I'm using the CT's purchased from open energy store.

The adaptor is one someone suggested on the forums http://www.jaycar.co.nz/productView.asp?ID=MP3027&form=CAT2&SUBCATID=100... the output voltage from the AC adpator later today,the mains input is 240ish volts.I'll get teh specifications from the packaging tonight.

"What I'm doing is adding the 3 PV outputs that are being measured by the three emonTx from the input display of emoncms and comparing there total to what the inverter is telling me. see attached."
That should be the correct way, what we need to know is whether all are wrong by the same proportion, or whether one or more is wrong by different amounts. Can your inverter tell you the output per phase? That there is a big spread of values makes me a little suspicious.
If you are not using the "shop" adapter, you certainly need to check and most probably adjust the calibration. (That link does not tell me any details of the adapter sufficient for me to calculate a coefficient. If you can measure the actual mains voltage and the actual output voltage of the adapter, then it's possible to get the exact value. Alternatively, you could simply tweak the coefficients until all 3 emonTx's read the same mains voltage as your meter/the inverter. And yes, I would expect them to be fractionally different.)
We can worry about the power when we have the voltage correct.

Not sure if the inverter is able to tell me per phase will try and find out.

Yeah, not able to use the shop adaptor as there is no version for a NZ outlet. I'll get the specifications from the packaging and measure the  input and output voltages.

Here are the calculations I use to scale/calibrate my EmonTX sketch (using the same adaptor from Jaycar). Even with the measured output voltage I still have to scale my readings by a factor of about 2.6 to get something accurate. But it has been running fine like this for quite a few months and seems to be very stable/consistent.

Calibrating after a full months data will hopefully improve things more - I just calibrated a few days ago after getting my monthly bill and comparing to what I measured. Will check again in a months time...

// Voltage calibration constant:

// AC-AC Voltage adapter is designed to step down the voltage from 230V to 9V
// but the AC Voltage adapter is running open circuit and so output voltage is
// likely to be 20% higher than 9V (9 x 1.2) = 10.8V. 
// Open circuit step down = 230 / 10.8 = 21.3

// The output voltage is then steped down further with the voltage divider which has 
// values Rb = 10k, Rt = 120k (which will reduce the voltage by 13 times.

// The combined step down is therefore 21.3 x 13 = 276.9 which is the 
// theoretical calibration constant entered below.

// NZ voltage = 240
// Output voltage of AC-AC adapter = 11.23
// EmonTx shield voltage divider = 11
// --> ( 240 / 11.23 ) * 11 = 235.1

// Current calibration constant:

// CT ratio / burden resistance for EmonTX shield
// --> (100A / 0.05A) / 33 Ohms = 60.606

// Measured load using the powerCal below with no scale factor
// - first HWC (3kW)  = 3000 / 1126.9 = 2.66217
// - then Enasolar    = 1.71 / 1.78   = 0.96967 = 2.55748 (instantaneous)
// - then Enasolar    = 1.78 / 1.76   = 1.01136 = 2.58654 (instantaneous)
// - then Enasolar    = 6.47 / 6.70   = 0.96567 = 2.49774 (daily total)
// - then spreadsheet =               = 0.97    = 2.42281 (2014-08-27)
// - then spreadsheet =               = 1.00683 = 2.43936 (2014-09-03)
// - then manual      =               = 1.135   = 2.76867 (2015-01-21 - full month report from openHAB vs Meridian)

// default/startup values
float scaleFactor_CT1 = 2.76867;  // Grid
float scaleFactor_CT2 = 2.76867;  // Solar (Enasolar output)
float scaleFactor_CT3 = 2.76867;  // HWC (3kW)
float scaleFactor_CT4 = 2.76867;  // UFHP

It's helpful of you, Ben, but it isn't definitive because ordinary component tolerances come into play, in the voltage regulator and resistors tolerances as well as the adapter tolerance and regulation. It's all spelled out in Building Blocks. So Grant, apart from having an emonTx rather than the Shield, will need to tweak his calibration constants in any case.

Yep - agree - was more just showing the steps I went thru and how much of a scale factor I had to apply in order to get accurate results. Hope I haven't confused the issue... :S

Hey sumnerboy, i was confused before you posted anything.

Ok, I have had a look at the building blocks calibration page and are confused now.

Phase 1 - Mains = 243.2 - AC output = 11.49

Phase 2 - Mains = 245.3 - AC output = 11.65

Phase 3 Mains = 244.6 - AC output = 11.59

OK, we can use those values to calculate your voltage calibration constants. First, the ratios aren't the same (manufacturing tolerances, as I said!). Second, the numbers I'm going to give you do not take into account the resistor tolerances in your emonTx, nor the tolerance of the voltage regulator which is used as the reference.

The voltage calibration constants are:

Phase 1: 243.2 × 13 ÷ 11.49 = 275.161
Phase 2: 245.3 × 13 ÷ 11.65 = 273.725
Phase 3: 244.6 × 13 ÷ 11.59 = 274.357

(13 is the voltage divider ratio = (120k + 10k) ÷ 10k)

Those aren't vastly different to the default values, so don't expect to see a massive change in the numbers.

I have the new sketch's in place on the emonTx's, so at least the readings are close enough for now.

Are there any good instructions on emoncms and setting up inputs & feeds etc, I have some working however they probably need some tweaking.

GLCD is the next thing i have loaded up the SolarPV sketch and this appears to be working however of course its only for one phase.

Is it possible to pull the readings for the GLCD from the feeds in emoncms?

"Is it possible to pull the readings for the GLCD from the feeds in emoncms?"

It should be possible - Paul's answered that in outline above.

Failing that, and bearing in mind memory in the GLCD is limited, you could try modifying that. Here's what you need to do in outline:

Add two extra instances of PayloadTX (one for each emonTx - let's call them emontx1, emontx2, emontx3).
Replicate the code that checks and stores the emonTx data: "if (node_id == emonTx_nodeID)..." once for each emonTx (3 node ID's required).
Finally, you'll need change "power_calculations()" to add up the three phases. Doing it this way will update the power and the display each time a set of data comes in - this may not be your choice and you might want to look at treating one phase as "master" and updating only when that sends the data.
You'll need to have lines like "consuming = emontx1.power1 + emontx2.power1 + emontx3.power1;", etc.

"Is it possible to pull the readings for the GLCD from the feeds in emoncms?"

As Robert, points out there is more than one way to do it, with pro's and con's to both. If the glcd's limited memory is able to cope with the extra code it maybe a more permanent solution as a "emonHub hack" to retrieve data from emoncms could get "broken" by future emonhub updates.

However following the earlier suggestions Matthias(McFly) started this thread How to send feed data from emoncms to emonGLCD?, He has implemented and shared a working solution that could work for you too.

Paul

Thanks for the replies I'll have a play around and post the results.

So hopefully I have got something together I'll try it tonight.

Is there anyway to include an external temperature reading from either underground weather or PVoutput both sites  have the temp from my weather station?

I guess the best way of doing this would be to get the temperature on to the emoncms server, which for me is local, and grab it from there that way any network issues that are outside me control will not be effected.

I'm not using the temperature senor on the emonTx, I have a prefect temperature sitting on my roof, just a matter on how to get it back to the GLCD.

I see no reason why you shouldn't be able to get another value, depending on what you have already you could possibly get the external temp and append it to the same payload as the feed values, 

The only concern is holding up emonhub if the network is slow or a website is down etc, more elaborate code could be used to run the requests in a separate thread.

Paul

ok, so i have made some progress, I thought...

this is the edited sketch i'm now using and mostly it is working.with the exception of a  couple of cases which i'll explain after the sketch. I have highlighted the lines I have either added or edited to include all 3 phases.

//------------------------------------------------------------------------------------------------------------------------------------------------

#define RF69_COMPAT 0 // set to 1 to use RFM69CW
#include <JeeLib.h>   // make sure V12 (latest) is used if using RFM69CW

#include <JeeLib.h>
#include <GLCD_ST7565.h>
#include <avr/pgmspace.h>
GLCD_ST7565 glcd;

#include <OneWire.h>      // http://www.pjrc.com/teensy/td_libs_OneWire.html
#include <DallasTemperature.h>      // http://download.milesburton.com/Arduino/MaximTemperature/ (3.7.2 Beta needed for Arduino 1.0)
#include <RTClib.h>                 // Real time clock (RTC) - used for software RTC to reset kWh counters at midnight
#include <Wire.h>                   // Part of Arduino libraries - needed for RTClib
RTC_Millis RTC;

//--------------------------------------------------------------------------------------------
// RFM12B Settings
//--------------------------------------------------------------------------------------------
#define MYNODE 20            // Should be unique on network, node ID 30 reserved for base station
#define RF_freq RF12_433MHZ     // frequency - match to same frequency as RFM12B module (change to 868Mhz or 915Mhz if appropriate)
#define group 210            // network group, must be same as emonTx and emonBase

//---------------------------------------------------
// Data structures for transfering data between units
//---------------------------------------------------
typedef struct { int power1, power2, power3, Vrms; } PayloadTX;         // neat way of packaging data for RF comms
PayloadTX emontx1;
PayloadTX emontx2;
PayloadTX emontx3;

typedef struct { int temperature; } PayloadGLCD;
PayloadGLCD emonglcd;

//---------------------------------------------------
// emonGLCD SETUP
//---------------------------------------------------
//#define emonGLCDV1.3               // un-comment if using older V1.3 emonGLCD PCB - enables required internal pull up resistors. Not needed for V1.4 onwards
const int SolarPV_type=1;            // Select solar PV wiring type - Type 1 is when use and gen can be monitored seperatly. Type 2 is when gen and use can only be monitored together, see solar PV application documentation for more info
const int maxgen=7000;              // peak output of soalr PV system in W - used to calculate when to change cloud icon to a sun
const int PV_gen_offset=50;         // When generation drops below this level generation will be set to zero - used to force generation level to zero at night

const int greenLED=6;               // Green tri-color LED
const int redLED=9;                 // Red tri-color LED
const int LDRpin=4;          // analog pin of onboard lightsensor
const int switch1=15;               // Push switch digital pins (active low for V1.3, active high for V1.4)
const int switch2=16;
const int switch3=19;

//---------------------------------------------------
// emonGLCD variables
//---------------------------------------------------
int hour = 12, minute = 0;
double usekwh = 0, genkwh = 0;
double use_history[7], gen_history[7];
int cval_use, cval_gen;
byte page = 1;

//---------------------------------------------------
// Temperature Sensor Setup
//---------------------------------------------------
#define ONE_WIRE_BUS 5              // temperature sensor connection - hard wired
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
double temp, maxtemp,mintemp;

//--------------------------------------------------------------------------------------------
// Flow control
//--------------------------------------------------------------------------------------------
unsigned long last_emontx;                   // Used to count time from last emontx update
unsigned long last_emonbase;                   // Used to count time from last emontx update
boolean last_switch_state, switch_state;
unsigned long fast_update, slow_update;

//--------------------------------------------------------------------------------------------
// Setup
//--------------------------------------------------------------------------------------------
void setup()
{
  delay(500);        //wait for power to settle before firing up the RF
  rf12_initialize(MYNODE, RF_freq,group);
  delay(100);       //wait for RF to settle befor turning on display
  glcd.begin(0x19);
  glcd.backLight(200);
   
  sensors.begin();                         // start up the DS18B20 temp sensor onboard 
  sensors.requestTemperatures();
  temp = (sensors.getTempCByIndex(0));     // get inital temperture reading
  mintemp = temp; maxtemp = temp;          // reset min and max

  pinMode(greenLED, OUTPUT);
  pinMode(redLED, OUTPUT);
 
  #ifdef emonGLCDV1.3                      //enable internal pull up resistors for push switches on emonGLCD V1.3 (old)
  pinMode(switch1, INPUT); pinMode(switch2, INPUT); pinMode(switch2, INPUT);
  digitalWrite(switch1, HIGH); digitalWrite(switch2, HIGH); digitalWrite(switch3, HIGH);
  #endif
}

//--------------------------------------------------------------------------------------------
// Loop
//--------------------------------------------------------------------------------------------
void loop()
{
 
  if (rf12_recvDone())
  {
    if (rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)  // and no rf errors
    {
      int node_id = (rf12_hdr & 0x1F);
      if (node_id == 10) {emontx1 = *(PayloadTX*) rf12_data; last_emontx = millis();}
      if (node_id == 11) {emontx2 = *(PayloadTX*) rf12_data; last_emontx = millis();}
      if (node_id == 12) {emontx3 = *(PayloadTX*) rf12_data; last_emontx = millis();}
      if (node_id == 15)
      {
        RTC.adjust(DateTime(2013, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));
        last_emonbase = millis();
      } 
    }
  }

  //--------------------------------------------------------------------------------------------
  // Display update every 200ms
  //--------------------------------------------------------------------------------------------
  if ((millis()-fast_update)>200)
  {
    fast_update = millis();
   
    DateTime now = RTC.now();
    int last_hour = hour;
    hour = now.hour();
    minute = now.minute();
   
    if (SolarPV_type==1){

    usekwh += (emontx1.power1 + emontx2.power1 + emontx3.power1 * 0.2) / 3600000;
    genkwh += (emontx1.power2 + emontx2.power2 + emontx3.power2 * 0.2) / 3600000;
    }
   
    if (SolarPV_type==2){
    usekwh += ((emontx1.power1 + emontx1.power2) * 0.2) / 3600000;
    genkwh += (emontx1.power2 * 0.2) / 3600000;
    }
   
    if (last_hour == 23 && hour == 00)
    {
      int i; for (i=6; i>0; i--) gen_history[i] = gen_history[i-1];
      genkwh = 0;
      for(i=6; i>0; i--) use_history[i] = use_history[i-1];
      usekwh = 0;
     
    }
    gen_history[0] = genkwh;
    use_history[0] = usekwh;
   
    if (SolarPV_type==1){

    cval_use = cval_use + (emontx1.power1 + emontx2.power1 + emontx3.power1 - cval_use)*0.50;
    cval_gen = cval_gen + (emontx1.power2 + emontx2.power2 + emontx3.power2 - cval_gen)*0.50;

    }
   
    if (SolarPV_type==2){
    cval_use = cval_use + ((emontx1.power1 + emontx1.power2) - cval_use)*0.50;
    cval_gen = cval_gen + ((emontx1.power2 + emontx2.power2 + emontx3.power2) - cval_gen)*0.50;
   
    }
     
    if (cval_gen<PV_gen_offset) cval_gen=0;                  //set generation to zero when generation level drops below a certian level (at night) eg. 20W
   
    last_switch_state = switch_state;
    switch_state = digitalRead(switch1); 
    if (!last_switch_state && switch_state) { page += 1; if (page>4) page = 1; }

    if (page==1)
    {
     
     draw_solar_page(cval_use, usekwh, cval_gen, maxgen, genkwh, temp, mintemp, maxtemp, hour,minute, last_emontx, last_emonbase);
      glcd.refresh();
    }
    /*else if (page==2)
    {
      draw_power_page( "POWER" ,cval_use, "USE", usekwh);
      draw_temperature_time_footer(temp, mintemp, maxtemp, hour,minute);
      glcd.refresh();
    }
    else if (page==3)
    {
      draw_power_page( "SOLAR" ,cval_gen, "GEN", genkwh);
      draw_temperature_time_footer(temp, mintemp, maxtemp, hour,minute);
      glcd.refresh();
    }*/
    else if (page==2)
    {
      draw_history_page(gen_history, use_history);
    }

    int LDR = analogRead(LDRpin);                     // Read the LDR Value so we can work out the light level in the room.
    int LDRbacklight = map(LDR, 0, 1023, 50, 250);    // Map the data from the LDR from 0-1023 (Max seen 1000) to var GLCDbrightness min/max
    LDRbacklight = constrain(LDRbacklight, 0, 255);   // Constrain the value to make sure its a PWM value 0-255
    if ((hour > 22) ||  (hour < 5)) glcd.backLight(0); else glcd.backLight(LDRbacklight); 

    int PWRleds= map(cval_use-cval_gen, 0, maxgen, 0, 255);     // Map importing value from (LED brightness - cval3 is the smoothed grid value - see display above
    if (PWRleds<0) PWRleds = PWRleds*-1;                        // keep it positive
    PWRleds = constrain(PWRleds, 0, 255);                       // Constrain the value to make sure its a PWM value 0-255
  
    if (cval_gen>PV_gen_offset) {
      if (cval_gen > cval_use) {            //show green LED when gen>consumption cval are the smooth curve values 
 analogWrite(redLED, 0);        
 analogWrite(greenLED, PWRleds);   
       
      } else {                              //red if consumption>gen
        analogWrite(greenLED, 0);
 analogWrite(redLED, PWRleds);  
      }
    } else {                                //Led's off at night and when solar PV is not generating
      analogWrite(redLED, 0);
      analogWrite(greenLED, 0);
    }
  }
 
  if ((millis()-slow_update)>10000)
  {
    slow_update = millis();

    sensors.requestTemperatures();
    double rawtemp = (sensors.getTempCByIndex(0));
    if ((rawtemp>-20) && (rawtemp<50)) temp=rawtemp;                  //is temperature withing reasonable limits?
    if (temp > maxtemp) maxtemp = temp;
    if (temp < mintemp) mintemp = temp;
  
    emonglcd.temperature = (int) (temp * 100);                          // set emonglcd payload
    rf12_sendNow(0, &emonglcd, sizeof emonglcd);                     //send temperature data via RFM12B using new rf12_sendNow wrapper -glynhudson
    rf12_sendWait(2);   
  }
}

So this mostly works as per the images labeled correct, what i cant explain is the images labeled FAILED

You've actually got a "Type 2" installation, according to what you wrote earlier, but the maths you're doing is for a Type 1. So you're doing the wrong sums.

That was stupid, thanks, have been using the wrong modified sketch.

Yeah, been there, done that. My favourite is to edit one sketch, load a different copy and wonder why the change hasn't done anything.

Thanks all for your help, the system is up and running fairly well at the moment, just a few tweaks to make so it's producing what i want it to.