Archived Forum

The voltage calibration (in most sketches, but not that one) affects only the voltage reading.
The current calibration (in most sketches, but not that one) affects only the current reading.
Again, in most sketches but not that one, both affect the power calculation.

In the 'continuous' sketch, because voltage and current are not reported separately, only a combined power calibration is needed. It is however, derived from the separate voltage and current calibration constants.

The value of the voltage calibration constant in that sketch is most likely a carry-over from previous adapters and/or voltage divider component values (that's without checking back). The whole purpose of calibration is to remove the uncertainty introduced by component tolerances, therefore it should be the norm if you want accurate measurements. There's more about that, and the derivation of the calibration constants, elsewhere in Building Blocks.

Thanks Robert. I'm aware of the purpose of calibration hence my link and question since the value in this sketch is so wildly different to what I expected.

Upon further investigation I think the value (276.9) was selected based on assumptions for emonTxV3 and is therefore wrong:

From http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor... the EmonTx PCB, the voltage is further reduced by the potential divider formed by R13 and R14, the ratio being 1/11 in the emonTx V2 but 1/13 in the emonTx V3. This voltage is then measured by the analog input of the processor relative to the processor supply voltage (in this case 3.3 V), which is used as the reference, and scaled so that the reference voltage would give the maximum count of 210 ( = 1024)."

From the comments in the sketch muliplying 21.3 x 11 instead of 13 gives 234.3 which is roughly what I expected and would give a fairly accurate reading "out-of-the-box".

Matthew

I have now also added temperature reading and changed the Wh totals so they give import/export totals allowing me to calculate house consumption, total export, total import, total generated etc.

See https://github.com/mattwire/emonTxFirmware/tree/master/emonTxV2/emonTx_continuous_importexport_watthours_V_temp

Thanks to Robin Emley's mk2pvrouter (Mk2_RFdatalog_4) for the temperature/Vrms code.

Thanks to Dave Dixon for the import/export totals (http://openenergymonitor.org/emon/node/5309)

The way that temperature is being measured in this code will unfortunately cause some data from the ADC to be lost (for roughly 10 ms on each occasion).  This happens because the OneWire protocol for the Dallas temperature sensor is much slower that the ADC's sampling scheme.  This loss of data may not be much in percentage terms, but is not ideal.

In the Mk2_RFdatalog_4 sketch on my website, this problem has been overcome by a complete restructuring of the code.  In that sketch, all of the logic for calculating and controlling the flow of energy is contained within the ISR, not just the ADC's operation.

Hi, I have a simple question.

What are the differences between emonTxV3_continuous_kwhtotals_noeeprom and emonTxV3_RFM12B_DiscreteSampling.

​Obviously, I know the different output. Which is the best? The most accurate?

Now, I'm using the last one and then I compute the Kwh in emoncms' feed.

Thanks.

Discrete sampling is the practice of only sampling for a fraction of each period and assuming the rest of the period is the same, it's done to reduce power requirements for battery use. So any continuous sampling sketch should be an improvement in accuracy.

As for the ...kwhtotals part, it can also be more accurate to do the calcs "continuously" on board the emonTx, There can also be a marked improvement in accuracy if the rfm network is subject to interference or poor signal etc that can result in dropped packets before they can be included in the emoncms derived totaling. However the on-board totals get reset at each restart of the device so it requires a whaccumulator "ratchet mechanism" at emoncms. It could be prone to a greater inaccuracy if the emonTx gets reset ( ie power supply issues etc) whilst holding totals that haven't reached emoncms yet ie one big loss rather than a occasional inaccuracy.

So "kwhtotals" can be better depending on your set up, but  "continuous" is definitely better than  "discrete" if you are running on a power supply (not batts).

Paul

Thaks Paul,

So I'm going to modify the firmware in order to use emonTx via serial (there are a lots of info on the serial). How can I add the voltage? In the standard there is no voltage. Moreover, I'll use emonTx with AC/AC adapter.

Sorry, I've forgot to say that I use emonTx V3

My recently posted Mk2 Router code for use with the emonTx V3.2 should do exactly what you want.  It monitors "real power" continuously on all four CT channels and also measures the RMS voltage and temperature.  Data is routinely transmitted by RF and is also presented to the serial interface.  Equivalent code for the emonTx V3.4 is here.

If you have PV on-site, this code can also identify and divert any surplus power for some useful purpose.  But it can function just as well as a monitor only.

As posted, cumulated energy is calculated for just one of the channels, this being CT3 which is intended for  "diverted power".  This logic could be easily extended to cover the other three channels if "kwhtotals" were required for all of them.

"As posted, cumulated energy is calculated for just one of the channels, this being CT3 which is intended for  "diverted power".  This logic could be easily extended to cover the other three channels if "kwhtotals" were required for all of them."

Hi Robin, just curious, I don't currently have a need but for future reference. Is there enough processor time and memory to do all 4? and how easy would it be to also implement "directional subtotals" ie total exported and total imported rather than (or as well as) a nett total?

My arduino coding isn't strong so I would need to study the code for some time to get to grips with it, but I would also assume there isn't likely to be an issue using longs rather than ints for the totals, correct? 

Paul

Hi Paul, there should be no problem with memory.  My sketches generally display how much free RAM is available; less that half of the RAM is being used for this sketch.

Floating-point maths is relatively slow, but most of the Mk2's code uses integers and longs.  If you carefully replicate the logic which accumulates energy for CT3, I sure you won't have any difficulty to get similar results for the other channels.  I think the accumulaors are all 'long', with the transmitted datafields being 'int'.

Take it carefully, one stage at a time, and keep checking and saving.  While developing any new code, I keep frequent copies in an adjacent folder called archive.  The various copies are simply dev_1, dev_2 etc.  I also keep a log file into which results and ramblings can be copied.  This record can be really useful for later reference, and is much easier than writing notes on paper.

I'm not sure about "directional subtotals".  The whole point about the Mk2's design is that the flow of energy changes direction so quickly that it is ignored by the meter.  To record such minor flows would not seem useful if they are not seen by the meter.  But if this requirement can be adequately specified, I see no reason why it could not be implemented by additional Mk2's logic. 

Within each datalog period, the minimum number of sample sets per mains cycle is recorded.  This number provides a good indication that the processor is not being overloaded.  With my latest code, as released for the emonTx V3.2 and V3.4, measurements of temperature do not affect the underlying sampling process, as confirmed by this number.  If temperature measurements were to be performed in older versions, the sampling process would be disrupted but there is no easy way to detect this (albeit small) loss of data.

"The whole point about the Mk2's design is that the flow of energy changes direction so quickly that it is ignored by the meter.  To record such minor flows would not seem useful if they are not seen by the meter.  "

Indeed, it's a bit of a no mans land as the net total's usefulness can also be questioned when the main reason for monitoring (for most users) is to know how much energy they are buying and how much PV is exporting (or escaping) and since we don't have net metering in the uk, import and export ideally need to be sub-totaled but without the sweetzone modulation included.. 

Is there a way that the diverter code can indicate when it's operating in the "sweet zone" ? to prevent the movement being added to the running total. I recall reading about a related solution using the meters led to confirm operation in the "sweet zone".

My current system does count the to'ing and fro'ing but since most of the year there is no actual export, the recorded export can actually be used to correct the import value (assumming any to'ing has corresponding fro'ing) however that goes out the window at the height of summer if I fail to use all PV.

Would having a virtual 1w "sweetzone" in the code be a solution? I understand a fixed point may not align with the meters "sweetzone" but is it feasible to recognize when modulating rapidly within a small range and only count values straying outside of a 1w zone centered on rolling short term mean average instead? 

As I said just curiosity at this point, I'm not suggesting I would attempt to tackle something like this myself,

Paul

Would having a virtual 1w "sweetzone" in the code be a solution? I understand a fixed point may not align with the meters "sweetzone" but is it feasible to recognize when modulating rapidly within a small range and only count values straying outside of a 1w zone centered on rolling short term mean average instead? 

Yes, this kind of arrangement should be entirely possible.  Not all meters have the same penalty-free range, so that would complicate matters.  Getting the spec nailed down is likely to be the difficult part.  The coding itself should be relatively straightforward.

Unless a positive export rate has been deliberately included, the Mk2's design will not allow any energy to "escape".  Unless the amount of surplus power exceeds the ability of the loads to consume it, the Mk2's processor will always believe that a correct balance is being maintained.  If a small amount of "escaped"energy is recorded by the meter, that will be because the two systems are measuring the flow of energy differently.  This effect can be minimised by ensuring that the Router has been properly set up, in particular so that the current and voltage sensors are using most of the available range of the ADC.  When operating in AF mode, the energy thresholds and calibration become important too.

In some parts of the world, the rate for exported power is tiered.  For the first X hours per month, it is relatively beneficial to export, but then the rate drops.  Without a real-time clock on board, it does not seem practical to include this level of complexity in the Router itself.  Maybe it could be implemented in some associated controller and then communicated to the Router via one or more of the IO pins.  Polling IO pins is a very simple and effective way of communicating with the processor, so a "diversion enabled/disabled" flag protocol could be easy implemented.

Once the tank is up to temperature and surplus power is being exported, the average power at the supply point will go from approximately zero to negative.  EmonCMS should be able to spot this and increment its export register rather than decrementing its import register.  Having an extra field in the RF payload so that the Router can convey something useful to emonCMS may be a useful addition.

These days, I tend to be driven by what my potential customers are asking for.  Since starting my own business, all new developments of mine have been customer-led. But if there are spin-offs, I'm generally happy to post them here on the forum for others to use, and to peer-review.

I agree a "1w" sweetzone probably wouldn't be the best way to go, using the existing  sweetzone settings used by the diverter would make far more sense.

My use of the term "escaping" was referring to energy escaping the grasp of the user and exporting back to grid unused rather than suggesting a "leakage" due to error or accuracy. There is no disputing the accuracy and it's only because of that accuracy that it would be worth considering such a level of fine-tuning through further development .

Indeed there are tiered export rates in parts of the globe that may reduce the "out of the box" usefulness of the added accuracy, but those same users and many many more besides are already currently unable to get an acceptably accurate export total, Plus that same philosophy would also apply to the usefulness of any form of watt hour totaling for many users, if they buy their energy at a multi-tariff rates, including UK's own off-peak economy7.

These tariffed and tiered calculations could be done quite accurately outside the sketch IF there was an accurate import/export value to work from, or indeed as the control side of OEM gets a footing the sketches totals could be reset as each new tier/tariff commences. but my own opinion is that these calculations involving time, money and tiers etc should be done in emoncms as tariff rates and T&Cs can change quite frequently. 

The use of the flag is interesting and would work well for on-board inclusion/exclusion logic for totaling, the reason I say "on-board" is the emonTx to emonCMS reporting interval would introduce heavy inaccuracies if the flag's state is only updated once per reporting interval. 

Surely he best place to reduce the additional import and export reported due to modulating in the sweetzone has to be at source, the diversion codes "flag" would just indicate if the movement should be included in an import/export total. Almost all the inaccuracy could be eliminated, if the Router is using for example 90% of the sweetzone to avoid straying into "chargeable territory" then 90% of the sub-totaling inaccuracy would be eliminated.

Maybe even that can be improved if the router is working to a defined safe area. ie if your best guess or the meters tech spec says the sweetzone is X and you run the router at 90% of X maybe it's possible to use X in the sub-totaling calcs.

As a side note, the way I can currently "see" the unmetered amount accumulating is an excellent indicator of how well (hard) the diverter is working as opposed to how effective it is. The amount diverted and the absence of any export tells me the diverter is effective, but on a high PV day the inaccuracy is far less than a cloudy day, effectively because the diverter can just switch to divert and remain there. Whilst on the cloudy day it has to work harder and the amount that is reported as export but not metered is actually a direct indication of how much energy was saved by modulating the diverter rather than just "diverting".

None of this is considered or intended to be criticism, I am already totally sold on the diversion concept, however the act of diverting introduces an inaccuracy (which I consider to be a small price to pay) that wouldn't previously of been noticeable if present. It would be a valuable addition to the diverters code to be able to remove as much of that as it can, especially as it is the most efficient method. In fact it has occurred to me whilst writing this that the diverter effectively imposes it's own sweetzone within the meters sweetzone and since that defines the boundaries of the diverting my previous 90% example isn't totally true as the diverter is capable of removing 100% of the inaccuracy derived from utilizing 90% of the sweetzone for diversion. wouldn't it??

Nor was it intended to be a feature request, more as an interesting discussion about future development in the area of energy monitoring, Although "These days, I tend to be driven by what my potential customers are asking for. " I would expect accurate monitoring and reporting of separate export and import in non-net-metering countries to be high on the users wish list, especially here on an energy monitoring forum. Advances in this area would also negate the need for any explanation of "why is my system exporting?" when it's not, when the subtotaling is done off-board.

Either way it's fantastic kit, :-)

Paul