Hi Robert, thanks for the speedy reply:
I was just going to edit my post as I had realised I had got the name wrong! Sorry Robin. However when I tried it just said Abandon or Keep…
So the CM software is loosely based on Robin’s… so if the diversion code was added, I would probably strip out the part of the sketch that displays diverted kWh locally, which would free up most of the I/O, and as I said previously use a ESP8266 to log the data to CMS, this I guess keeps most of the code as is apart from the diversion code. I did look at robins published sketches 6 months ago when I built the router. Just had a look again and it seems that there are a lot more sketches added, including data logging via RFM… and possibly in OEM format. Does this mean that if I use the correct sketch I could possibly log my data into a emonBase?
Ok so now i’m even more confused as to the direction I should take. Basically I really don’t want to replicate what I’m doing already if I don’t have to - there is a finite amount of CT’s I can get into my CU! and 2 CT’s on the same live conductor or adjacent to each other might not be a good idea.
I guess I need to dive into the code of both and see what I need to do… any pointers here would be greatly appreciated. I did much coding when I was younger, but mostly machine code on x86 systems at college, but that was in excess of 20 years ago probably more like 30! I’ve got some self teach packages based on Arduino and other’s but it will be a deep learning curve…
And, yes the emonGLCD, couldn’t remember the name of it! Can this still be used to display the data collected by emonTX via the RFM? I believe I will have to change the RFM I have already.
When you say ‘(See the various STM 32 threads - but we’re a long way from a fully working version of that, both hardware and software-wise.)’ do you mean there is still plenty of available overhead available with the 'Atmel ‘328P’ i.e not necessary, or that the change to other processors hasn’t been completed yet?