Archived Forum

Nyquist gives twice the frequency of the highest frequency component in the signal, which for UK mains is taken to be about 20 times the fundamental, I believe.  This gives reasonably good resolution when the waveform is distorted.  The result is a highest frequency component of 1kHz and a minimum acceptable sampling rate of 2kHz to satisfy the Nyquist criterion.

250 Hz seems far too low to me, and will almost certainly generate sampling artefacts if the waveform is a bit distorted, as it often seems to be.

There needs to be an adequate low pass filter in front of the A/D in order to prevent any high frequency signals (coming from mains-borne signalling or data transmission) from getting in and causing sampling errors, too.

The standard emonLib does as you say call the ADC repeatedly and as fast as it will go with those particular read commands. It works out, when you have the rest of the code in place, to around 50 sample pairs per cycle, or 2500 sample pairs per second. (A sample pair is voltage and current.) The normal use of the library is to sample over a period of around 20 cycles and then repeat this for a second and third c.t., then report by radio and sleep for 5 s.

However, if the ADC in the Atmel is allowed to free run independently and report into the main program using interrupts as in Calypso_rae's Mk2i sketches, much better performance is seen. Or as MartinR's sketch http://openenergymonitor.org/emon/node/1535 demonstrates, voltage and two c.t's can be sampled at exactly 50 sets of samples per cycle with plenty of time to read a temperature and send the results by radio. In both cases, the readings are taken continuously without pausing.

The sample rate is of course determined by Nyquist and the highest frequency you are interested in (or vice versa).

The filter is there to remove the d.c. offset, which is required because the ADC input needs to be biassed midway between 0 and Vcc. Its corner frequency needs to be low enough to not introduce a significant phase shift at the lowest frequency of interest - 50 Hz in our case. You wrote: "The Digital filters for offset removal article talks about 250 sample periods. When I tried this number of sample periods per waveform in a spreadsheet some of the filter results were 10% out."  I think you misread that paragraph.

Unfortunately, you will need to correct for phase difference because the input transducers, voltage and current transformers, each introduce phase shifts that are not equal, and worse, they vary with the measured quantity.

JSHarris:

"Nyquist gives twice the frequency of the highest frequency component in the signal, which for UK mains is taken to be about 20 times the fundamental, I believe. "

I think you're trying to say that the tariff meter is accurate up to the 20th harmonic, which I believe is the case.

Here are some actual numbers for 1 call to emonLib. Time is in microseconds

Num Samples = 518 Time = 202128
Num Samples = 517 Time = 201856
Num Samples = 518 Time = 202888
Num Samples = 518 Time = 202312
Num Samples = 518 Time = 201192
Num Samples = 518 Time = 209912
Num Samples = 518 Time = 210536

As you can see, the number of samples in a nominal 10 cycles can vary slightly, as there is no attempt to synchonise exactly.
 

Yes, the spec for tariff meters is for them to be accurate when the waveform is distorted to the point where the 20th harmonic is just detectable, as this is considered to be the upper bound for waveform distortion due to things like phase angle controllers or switch mode power supplies.  A look at the mains on a spectrum analyser shows that there is often a fair bit of energy up to around the 5th harmonic or so, with not much really beyond that as a rule. 

If the lower accuracy is acceptable, then sampling at around 500Hz (twice the 5th harmonic) should be reasonably accurate.  Sampling any lower than this will introduce sampling artefacts, with their magnitude being non-linearly proportional to the amplitude of the harmonic causing the artefact.

I've just had a look at the mains here on the spectrum analyser and the 4th harmonic is fairly prominent (maybe 2 to 3% of the fundamental amplitude) but the 6th harmonic is barely detectable, which makes a reasonable case for only needing to sample at around 500 Hz to get reasonably OK data.

It works out, when you have the rest of the code in place, to around 50 sample pairs per cycle, or 250 sample pairs per second

I think you lost a 0 there Robert! 50 x 50 =2,500 so we're sampling at about 2.5kHz.

Robert,
Thank you for the responses. I will start with about 50 sample pairs per cycle. I'm planning to interrupt after every 8 ADC conversions and I don't expect to have enough to do to keep the PIC busy.

Robert and JSHarris - very off topic
Since I noticed on another thread you both confessed to having used a PDP-11, I will also hold up my hand here - I was a developer of one of the RSX PDP-11 operating systems. I too used an acoustic coupler to run programs, and worked with someone who was taking her program in person for its daily run on the CDC 6600 in London, and managed to drop the program (hundreds of punched cards) in the middle of Waterloo station in the rush hour. Those were the days!

50 x 50 != 250   

For the record, I've corrected it.

2.5 KHz is fine, good enough to meet the tariff meter basic spec, i think.   The A/D will need a low pass anti-alias filter in front of it though, set to remove everything above the sampling rate / 2, with negligible phase shift in the pass band.  Without an anti alias filter there's a risk of getting sampling-created artefacts.

Many years ago, when we switched from using FM instrumentation tape recorders to digital data loggers we ran into hosts of problems with aliasing errors, as we were pushing things by only sampling at the Nyquist rate (because the technology  of the day didn't allow really fast 16 bit sampling and conversion) and we'd neglected  to fit good LPFs on the front end.

Another tip is to make sure that the sampling frequency is NOT a multiple of the fundamental.  Offset or randomise the sampling rate a bit, so there's less chance of an alias creeping in and mucking up the measured data.

There's a small but worthwhile improvement in sampling rate to be obtained with a small change to EmonLib.  In the inside loop, there are two conversions from integer to float where one would suffice:

    //-----------------------------------------------------------------------------
    // B) Apply digital high pass filters to remove 2.5V DC offset (centered on 0V).
    //-----------------------------------------------------------------------------
    filteredV = 0.996*(lastFilteredV+(sampleV-lastSampleV));
    filteredI = 0.996*(lastFilteredI+(sampleI-lastSampleI));

Inserting a 2 pairs of brackets (bold)  forces sample and lastSample to be subtracted as integers before the result is converted to float.

It was Robin Emley who was the first to point this out, it increases the sample rate to about 56 sample pairs per cycle. I thought it had been included in the library some while ago, but apparently not.
 

Robert,

I had sent the following to Trystan in a PM in August 2012, but I think he decided not to 'change a winning team' :-) ,which I fully understand:

" .....

I have now made some experiments with your original sketch 'emonTx_CT123_Voltage'. I found that the period for measuring one voltage sensor and one CT is around 394us. This is jittering by +/-10us due to different calculation times from one loop to the other. 

Then I tried to speed this up. One small change brings the periode down to 364us, an improvement of ~8%. This is by just changing the line:

 filteredV = 0.996*(lastFilteredV+sampleV-lastSampleV);

to:

  filteredV = 0.996*(lastFilteredV+(sampleV-lastSampleV));

(same for the current calculation). The calculation (sampleX-lasSampleX) is done in integer now and this is much faster than in float. The result is exactly the same.

Then I wanted to use the time when the processor is waiting for an adc conversion to complete. For this I have to cancel the call to analogRead() and just inline the same code. The time while the controller is waiting for the end of conversion can now be used for calculating the desired measurment variables.

I put the code snippet here because I do not know how to attach something:

//*************************************************************************

  while ((crossCount < crossings) && ((millis()-start)<timeout))
  {
 digitalWrite(TESTpin, HIGH);
//    sampleV = analogRead(inPinV);                 //Read in raw voltage signal
    ADMUX = 0x40+inPinV;
    ADCSRA |= (1<<ADSC);
    {
      numberOfSamples++;                            //Count number of times looped.
      lastSampleV=sampleV;                          //Used for digital high pass filter
      lastSampleI=sampleI;                          //Used for digital high pass filter
      lastFilteredV = filteredV;                    //Used for offset removal
      lastFilteredI = filteredI;                    //Used for offset removal
    }
    while (bit_is_set(ADCSRA,ADSC));
    sampleV = ADC;

//    sampleI = analogRead(inPinI);                 //Read in raw current signal
    ADMUX = 0x40+inPinI;
    ADCSRA |= (1<<ADSC);
    {
      filteredV = 0.996*(lastFilteredV+(sampleV-lastSampleV));
      sqV= filteredV * filteredV;                 //1) square voltage values
      sumV += sqV;                                //2) sum
      phaseShiftedV = lastFilteredV + PHASECAL * (filteredV - lastFilteredV);
    }
    while (bit_is_set(ADCSRA,ADSC));
    sampleI = ADC;
 digitalWrite(TESTpin, LOW);

    filteredI = 0.996*(lastFilteredI+(sampleI-lastSampleI));
    sqI = filteredI * filteredI;                //1) square current values
    sumI += sqI;                                //2) sum

    instP = phaseShiftedV * filteredI;          //Instantaneous Power
    sumP +=instP;                               //Sum

    lastVCross = checkVCross;
    if (sampleV > startV) checkVCross = true;
                     else checkVCross = false;
    if (numberOfSamples==1) lastVCross = checkVCross;

    if (lastVCross != checkVCross) crossCount++;
  } //*************************************************************************

I think you will see from where I cut this. This code does now run in 296us. This gives a ~25% higher sampling rate. As it is 'buried' in a library, it can possibly be looked upon as having a 'high enough' abstraction level although it does not use analogRead().

Just an idea. Regards, Jörg.

...."

The second change is 'unrolling' and 'inlining' the anaologRead() function to be able to use the conversion time for calculations. Improves sampling rate by another ~25%.

But I also think that an interrupt version of the lib should be the final goal.

BR, Jörg.

Digital filters for offset removal was very helpful to someone like me with no prior knowledge of filters, but I couldn't understand one line in the code.

The basic algorithm is
  filtered_value = 0.996 * (filtered_value + sample - last_sample);

This is then converted to integer arithmetic to remove the floating point multiplication. To improve accuracy, before dividing a quantity by 256, 128 is added to give the correct rounding. Also, to improve resolution, the intermediate calculations are done in quantities 256 times the final result needed. These quantities are called 'shifted' units.

The code which replaces the above line is then

  long shiftedFCL = shifted_filter + (long)((sample-last_sample)<<8);
  shifted_filter = shiftedFCL - (shiftedFCL>>8);
  long filtered_value = (shifted_filter+128)>>8;

The first two lines work in 'shifted' quantities, i.e. multiplied by 256. The third line then divides by 256 to get the required filtered value. This third line includes 128 for rounding, but I don't understand why. It would be correct to round if the intermediate calculation had been done in the final units, but not in shifted units. If you then add 128 to shifted filter then divide by 256, you are just adding a constant offset of about 0.5 to the final filtered value. I think the third line should be:

  long filtered_value = shifted_filter>>8;

Am I misunderstanding something?

Also, the code in EmonLib appears to use the floating point calculation, not the integer calculation suggested in the digital filters article. Does integer calculation not actually make a lot of difference to the execution time of the code in the Arduino?

If you then add 128 to shifted filter then divide by 256, you are just adding a constant offset of about 0.5 to the final filtered value.

If you want rounding then adding the 0.5 temporarily (!) before the division is necessary as the result is integer again. It just gives the 'best fitting' result for the operation. But maybe I misunderstand you.

Does integer calculation not actually make a lot of difference to the execution time of the code in the Arduino?

It makes a big difference! FP calculations add a lot of overhead (not only) because they always have to handle 4 byte values.

If you look at the example given earlier in this thread, changing the simple calculation (sample-last_sample) from fp to integer saved ~30us run time! 

Sorry, Jörg, I thought it was you who originally proposed the change, but I couldn't find it. Robin's post was December so yours predates his by a long way.

To add to the "0.5" explanation, conversion from float to integer is normally by truncation. Therefore on average the resulting values will be 0.5 less than they should be. So adding 0.5 to the float before truncation means that the resulting integer will always be in error by a maximum of 0.5, rather than 1 as it might otherwise have been.

To answer Arnold's implied question, my explanation for why integer maths isn't used in emonLib is because the concept and operation of a digital filter is hard enough to explain to someone who hasn't met one before, and one where parallel quantities are scaled differently, with bit shifts and the like, well... !

The digital filters article was added only recently, emonLib predates it by a long way. The original integer maths is I think in Atmels App note AVR465.

If you want rounding then adding the 0.5 temporarily (!) before the division is necessary as the result is integer again. It just gives the 'best fitting' result for the operation. But maybe I misunderstand you.

If you're working of units of 256, then shifted_filter=n*256 say.

So (shifted_filter+128)>>8 = (n*256+128)/256 = n+0.5

The filtered_value should be n but is 0.5 too high.

The attached spreadsheet shows the three steps of the above calculation for a constant DC level of 100. The filtered value without 128 settles to 0, filtered value with 128 settles to 0.5.

To answer Arnold's implied question, my explanation for why integer maths isn't used in emonLib is because the concept and operation of a digital filter is hard enough to explain to someone who hasn't met one before, and one where parallel quantities are scaled differently, with bit shifts and the like, well...

I agree with Roberts comment. It took me some time to understand the integer code above.

Arnold

The attached spreadsheet didn't get attached. I'll try again

To attach the spreadsheet, I clicked File Attachments, selected the file, clicked Attach, then Save to post the reply. The attachment doesn't appear to be there. What am I doing wrong?

[Edited by RW:  You need to tick 'List' - I've done it for you]

So (shifted_filter+128)>>8 = (n*256+128)/256 = n+0.5

The filtered_value should be n but is 0.5 too high.

No, because n+0.5 = n as the result is an integer value (long in the example above). As Robert tried to explain, the error is +/- 0.5 after rounding instead of -1..0 without rounding.

Sorry, Jörg, I thought it was you who originally proposed the change,...

This was not the reason why I made the comment :-) I just wanted to give the additional hints to further improve the sampling rate for which I originally was to shy to do it publicly (only PMed to Trystan).

No, because n+0.5 = n as the result is an integer value (long in the example above).

You're correct. The spreadsheet I couldn't attach calculated the final result as floating point. Both results would have been 0 if they were integer.

As the filtered value stays in long integer, adding the 128 has no effect. So I was wrong - the code in the article works OK. On the other hand if adding 128 has no effect it's unnecessary and possibly confusing to have it in the code.

I wish I could figure out how to attach a file. After your comment, there's no need to attach this spreadsheet, but I may need some help when I start building this Energy Monitor, and I may want to attach a file in the future.

Arnold

Arnold - see your post above that I've edited.

Arnold - see your post above that I've edited.

Thanks

On the other hand if adding 128 has no effect it's unnecessary and possibly confusing to have it in the code.

You still don’t get it do you Arnold?

Let me have a go at explaining....

255/256 = 0.996

If you just do integer division without adding 128 first you will get 0, clearly not the closest integer value to 0.996.

Now if you add 128 first (255+128)/256 = 383/256 which for integer division = 1, the closest integer to 0.996

If you are having so much trouble with this simple concept are you sure you want to design your own system using a PIC chip? I’m sure it would be a lot easier to learn the Arduino environment.

Arnold,

I have modified your spreadsheet with two columns showing the integer values of the results. I think you can clearly see that it makes a difference to add 128.

Arnold, you'll have to believe us. It is probably as old as computers - and I don't mean electronic ones! I have a very vague recollection that I read somewhere that Charles Babbage (who else?) had incorporated this mechanically in his Difference Engine, by offsetting by half a cog.

Jörg,

Thanks for the updated spreadsheet and for your patience. I was getting confused because originally I'd been thinking the filter values would be used as floating point numbers, which is why I wasn't rounding them. Obviously it makes more sense to keep them as long integers and do the subsequent V*V sums etc in integer arithmetic.

If you are having so much trouble with this simple concept are you sure you want to design your own system using a PIC chip? I’m sure it would be a lot easier to learn the Arduino environment.

Martin

In spite of appearances to the contrary I am well aware of the simple concept of rounding integers. As a new user of this site, I didn't find your response particularly helpful.

Well it was good advice. The Arduino tools are incredibly easy to use, there's lots of help and useful libraries available, all the ground work has been done and there are very cheap circuit boards available. I'm sure it would be a faster path for you than trying to convert everything to PIC.

In your first post you implied that the main reason you wanted to use a PIC chip was so that you wouldn't have to do phase correction but as Robert explained, that isn't the case.

Anyway, good luck, I'll be interested to see how you get on but I won't try and help again.

Personally, I think the Arduino stuff is incredibly hard to pick up, and I've got around 40 years experience with writing code from CORAL, through FORTRAN to assembler for the early 8 bit micros and thence to various control languages, and the odd bit of PASCAL.  I know that the Arduino has an ardent fan base, and that it's partially supported via some indecipherable open source geek sites, but it is far from being well documented and easy to get to grips with.  Whatever documentation there is seems fragmented, poorly supported, full of errors and inconsistencies and any reliable information is buried in places that only those in the know can find and written in a form of English that I personally can't decipher.

I do like the idea of a reasonably fast microcontroller like the ATmega range running compiled code with floating point math, but the key for me has to be rock-solid and reliable manufacturer support and documentation, including the critical stuff about the hardware interface specs and performance. 

The PIC range are very well supported in this regard, with excellent documentation and a wealth of easy to use compilers, very cheap programming (including in-circuit options) or even integrated interpreters in the case of the Picaxe range.  PICs are inherently a bit easier to use for some hardware interface jobs, it seems, if less easy to use, in some cases, for complex mathematics and things like interfacing to Ethernet.  For example, I have a dsPIC running a vector controlled 3 phase brushless motor.  It's far faster (and also a lot cheaper) than an Arduino, in fact an Arduino just couldn't manage the hardware interface, or do the vector calculations, anywhere near fast enough to allow the motor to run at more than a few tens of rpm.

To some extent it's horses for courses.  If it were better documented and easier to get to grips with then I might well look at using an Arduino for a complex automation hub application, where the good support for things like Ethernet connectivity and interfacing with graphics displays easily etc would be an advantage.  For a sensor interface then a PIC beats it hands down, though, at a fraction of the cost, too.

I just wish that the Arduino crowd would get their act together and produce some easy to understand and accurate documentation, all in one place, with a well-written and easy to follow beginners guide, as that seems to me to be the Achilles heel of the thing at the moment  (together with the relatively high price).

Sorry for drifting off-topic..................

Well it was good advice. The Arduino tools are incredibly easy to use, there's lots of help and useful libraries available, all the ground work has been done and there are very cheap circuit boards available.

Martin

I'm sure you're right. I suspect PICs have a higher learning curve than Arduinos. As I said in my first post though, I'm familiar with PICs and that's the main reason I'm using them for this. It's a pity I'll still have to do some phase correction, but that's not a big deal.

I may be wrong, but I don't think it will be too different to convert everything to a PIC. The majority of the code should be the same (C, but that converts easily from C++), the ADC will be a bit different on a PIC but I've used that before, I'll use a different RF solution to communicate with my PC application, but again I've done that before. The main stuff I'm not familiar with is current and voltage sensing and filtering, but neither of these are Arduino specific and there's a great deal of helpful information about these on this web site, and hopefully I can get further help from this forum if I need it.

I ought to check out Arduino some time. It's just a bit of an effort when you're familar with another platform.

P.S. Just read the previous post as I was about to post this. One thing I do like about Microchip is that the documentation is reasonably central. Also I just use the individual MCUs not development boards, so it only costs me £1 to £3 for a processor that will do what I want. The wide variety of sensors and interfaces is a plus, but this can be a double edged sword, because it's easy to get overwhelmed with the number of processors to choose from. Anyway, this is a bit off topic, and I'm sure I'll be back when I get the energy monitor underway.

I think we may be comparing apples and oranges here.

As you know, PICs are a range of microprocessors from Microchip which I agree are cheap, easy to use, well documented and well supported. There is also a range of microprocessors from Atmel which are equally easy to use, well documented and well supported. Just like Microchip, Atmel provide a range of free development tools which are excellent. Their chips may be slightly more expensive than PICs but the ATmega328 used in the OpenEnergyMonitor project is also only £2-3.

Arduino on the other hand is something completely different. It is an open-source development environment specifically designed to introduce beginners to microprocessor development. It has no direct connection with any manufacturer, they happen to have chosen Atmel for their first boards but it could equally well have been Microchip and there is no reason why the environment couldn’t be ported to use PICs in the future.

I’m really surprised you found the Arduino concept hard to pick up Jeremy as it’s really aimed at beginners, with your experience it should be a doddle. I assume you’ve looked at the Arduino and Atmel home pages?

I did look at the Arduino when it first sort of started evolving, but it was clear right from the off that it was aimed at geeks who didn't want to get to grips with the nitty-gritty details of real-world hardware interfacing, but wanted to to be able to do geeky stuff from a PC.  

I'm a fan of the concept of open source, in fact I've freely shared everything I've ever developed, but it has a major flaw, a flaw so vast as to make it seriously difficult to use for anything that needs reliability and long term supportability.  That flaw is testing and reliability.  No one is responsible for anything in an open source system, so no one needs to do thorough testing or take responsibility for any flaws.  The result is anarchy, with the proliferation of dodgy and untested code libraries that then get relied upon by those developing new applications.  IMHO, this is breeding complacency with some programmers who aren't bothering to check whether they are incorporating SOUP into their code via untested and verified libraries. 

I have to say my other main problem is with c++ in this case.  I've never been comfortable with the bizarre lack of structure and odd syntax.  As a language it doesn't seem best suited to control and instrumentation (which is my background).  Given its heritage this isn't surprising, but it's an odd choice for a control-based open source development system.

Cost is the other problem.  I can buy a PIC for £1 or so that can be incorporated directly in a project as is.  Even some of the pre-progammed (but far less capable) PIC variants, like the very cheap little Picaxe 08M2 that I've used in my PV power diverter only costs £1.50, and needs no programmer, no purchased compiler and has comprehensive and free documentation with a very high degree of reliability and accurately known performance.  Not a bad price for a 32MHz microcontroller that does all the stuff needed to run a PV diverter, and better value by far than an Arduino for applications like this that are primarily control based.

Just for the record, even those fully wedded to the Arduino environment can quite easily and cheaply go the "stick a cpu on your pcb" route too.  For about $5:

http://hwstartup.wordpress.com/2013/03/06/how-to-build-a-5-arduino-clone/

You still need a programmer to get the bootloader in, but they can be built out of an Arduino (even a $5 Arduino).  You'd need to borrow an Arduino or ISP to solve the very first chicken-n-egg problem.

I think it's really a case of picking the right solution for any particular application, rather than one being better than another.  For example, I have a monitoring system in this house where I measure temperature, humidity and CO2 at various locations (including the roof space, outside and the deep ground temperature).  It made sense to make the combined temperature and humidity sensors semi-intelligent and do the basic processing to get real numbers, then have them transmit data back to a central display and data logger.

Using something like an Arduino on every remote sensor, just to do some simple conversion and output a data stream to a 433MHz TX or send serial data down a cable, would have been an expensive overkill.  On the other hand, adding a £1.50 Picaxe (which has a built in bootloader and interpreter, so is in circuit programmable directly from a PC) to each sensor was a better solution, as it was small, cheap and plenty powerful enough for such a limited task.

However, for the central hub, where the data is received, displayed and stored, it would have made sense to use something like an Arduino, just because it would have been better able to handle multiple tasks, drive complex displays, talk to the LAN, store to SD card etc.

There is a fair bit of merit in looking at a distributed processing topology for home monitoring, as when you split off the measurement and data acquisition parts to sensors with their own own initial processing the task of the central unit becomes a lot simpler to implement.  It also makes testing and calibration simpler, especially if sensors can be individually calibrated by just reloading some new constants to their own on-board controller.

However, for the central hub, where the data is received, displayed and stored, it would have made sense to use something like an Arduino, just because it would have been better able to handle multiple tasks, drive complex displays, talk to the LAN, store to SD card etc.

Geeze.... grab a Raspberry Pi for that!  ;-)

I'll admit to having been tempted by the various small computers, like the Pi and the host of others that are broadly similar.  for our new house I may well use one as the central hub for information display and recording, but not for control.

One thing I've learned during development and planning of our new passive house and the controls it needs to perform properly, is that there is a big problem with many of the commercial offerings.  Houses last a long time, so any control system needs to be not only reliable but also supportable for at least 20 years, preferably longer.  There are hosts of home automation systems out there running on things like tablets, using apps as the core means of control for things like lighting, heating, entertainment systems or even door locks and alarms.  What on earth happens when, in two or three years time new tablets have lost the ability to run legacy apps and the original supplier has gone the way of the DoDo?

I made a firm decision to use a distributed measurement and control topology based largely on the need to be able to either keep things repairable through life, or allow any node to be replaced in the future with something that can be made compatible.  The weak point in my solution is the reliance on medium speed serial protocols being retained for the next 20 years or so, but other than that I think it should be fairly future-proof.

This thread is now offtopic and will leave to no good.

Comparing atmel, microchip and compilers is not ever a good thing to do. All are good for what they are designed to do.

As a note, Arduino GUI is a nice package that hides many complex work from working with the hardware itself.

But behind the curtain it uses gcc, the industry standard  open source C/C++ compiler that is also used by AVR Studio and all linux world anyway. Meaning, if you can learn from the basic needs from arduino ide that simplifies the usage of C/C++ language on atmel itself, you have the knowledge to program for any platform in the world from x86 to PICs.

You need to start with simple things in C or else you will dismotivate yourself looking at pointers and C++ structures that will not made any sense if dont know the bases of C.

PICaxe is a commercial product with Basic language syntax, started as a didactic learning tool for 15 years old students.  May be simple but if you don't know anything else you are locked to it an will have difficulties to understand anything else like you seem to have. If you start to learn C then will see how much limited you are with that basic proprietary solution you have now.

Well, I guess that's me told then.  I must be a real beginner to deserve such a dressing down.  Pity I've been designing, building and testing measurement and control systems for only 40 odd years, so probably have more experience with a larger number of programming languages than you've had hot dinners.

Still, I get the message, and shall not return.

This forum seems to be  misnamed -  I thought it had the word "open", as in having an open mind, as the first word in it's title, how silly of me to have misunderstood.

JSHarris are you marketing picaxe and got mad by being turn down with a logical explanation of why arduino opensource platform is better?

Open your eyes and read how many times I've mentioned each brand of microcontroller. 

It might stop you putting your foot in your mouth and being so offensively rude when you realise that I've used the word "picaxe" ONCE on here, yet have referred to the Arduino, PIC and others many times.

Anyway, this my last post here, I shall carry on with my project without sharing it here, as it's clear that this forum seems to find discussion on an open and freely shared basis something to be critical of.  You might consider renaming the forum "ClosedEnergyMonitor" if one mention of one other possible solution gives rise to such offensive rudeness.

chaveiro

Please do not make personal attacks aimed at other forum members. Mr Harris is entitled to his opinions, as you are to yours. You may disagree with one another, but if you must disagree in a public forum, be prepared to produce evidence, not opinions, to support your claims and don't make comments like your last one.

Huh?

A don't meant to be rude nor ofensive to anybody. I made a technical post about two concurrent but similar technologies and got a strange emotional comment about not comming here again by disagreeing.  I must say i had seen similar behaviour on marketing campaigns on other foruns that was discovered by ip tracking by the administrator. So i politely asked if that was the case.

JSHarris said:  "Personally, I think the Arduino stuff is incredibly hard to pick up, and I've got around 40 years experience"

I responded to that with a simple advise: "If you start to learn C then will see how much limited you are with that basic proprietary solution you have now."

I don't care for bad humor, neither mean to be rude and  wont comment more on this thread that at similar foruns should already have been locked when went offtopic.

I realise English might not be your first language, but I read your posts leading up to this as being opinionated - as were Jeremy Harris's, and I read your post of 14:41 as a personal attack. To a native English speaker, the way you wrote it was confrontational. If you really wanted to question whether Jeremy Harris was marketing the PIC. then maybe you should have chosen gentler words. My opinion is, if you believed he was marketing the PIC, you should not have commented at all, but raised the matter with the administrators. I don't see any evidence to suggest that might be true, I think it is very simply the case that he is happy with what he is familiar with, in exactly the same way that you are.

Perhaps you can both agree on something I've known for a long time: "Most likely, the best system to solve any problem is the one you are familiar with."

I agree the post has gone off-topic, if you wish to continue this discussion, please PM me.