When I set out on my epic PV Router voyage, I had no intention of routinely sending any data anywhere. My Mk2 router just needed to divert surplus power to a dump-load as efficiently as possible. One way of enhancing its capabality has been to send RF commands to a remote dumpload. Rev5 of my Mk2i code does this, but it does not transmit any other data (apart from a message ID so that the receiver can detect when a message has been lost).
Several other constructors have already got systems to work in which surplus PVpower is diverted and useful data is also sent out to anything that may be listing, such as an emonGLCD or a Nanode/ Raspberry PI. My Mk2i code has plenty of spare time on its hands, and I could no doubt arrange for it to transmit relevant data too, if that would be helpful.
The standard calcVI() routine returns detailed results for a short measurement window. This includes parameters of a fairly specialised nature, such as Apparent Power and Power Factor. I'm doubtful whether there would be much benefit in routinely transmitting such values to a data collection facility. But general data, such as power (generated/consumed/diverted) and voltage etc. may be appropriate. Commands for a remote dump-load would also be needed. It may also be helpful to retransmit LED pulses as detected from the meter, so that a remote load would be able to flag up if were ever in the 'on' state when a pulse occurred.
So, if anyone has any ideas about a generic format for such data, or can post some details here about what they're already using, that would be much appreciated.
Thanks, Robin
Re: RF Data Structure for PV Router Systems
The structure that I am using is this:
typedef struct { int power1, power2, power3, Vrms, temp, frequency1, ext_divert; } PayloadTx;
power1 = House power
power2 = Solar power
power3 = Diverted power
Vrms = Mains Voltage
temp = temperature of the local triac
frequency1 = Mains frequency
ext_divert = command data for external diverter
No particular thought was applied to this on my part so it could no doubt be improved upon. I like the idea of adopting some sort of standard.
Maybe the best starting point is to discover what everyone else is doing.
Re: RF Data Structure for PV Router Systems
Thanks, Brian.
Are you processing any of this data using emonCMS, or similar? Or just it just go to your display unit(s), in which case a purpose-built structure may be ideal.
It occurs to me that the base-station could usefully transmit some accumulated data rather than leaving all of the processing for the receiving end to do. By that means, a emonGLCD unit unit could always start up showing some meaningful totals, rather than just what's happening now.
A simple protocol should allow any amount of data to be sent, albeit not in every message. Each RF message could include the current status of key parameters, plus some background data too, rather like the teletext protocol.
Re: RF Data Structure for PV Router Systems
Where I used to work we used to make a number of special purpose short range data links involving a master and remote end the latter was usually battery powered.
Although the data format varied from job to job we evolved a standard regime of always transmitting back the received signal strength and the battery voltage in every data package. in that way the master station knew not only the signal strength it was receiving but also the the strength of signal as perceived by the remote end.
This proved incredibly useful for debugging, positioning aerials etc. so much so that we left in in the protocol even after delivery so that if our customer complained of poor performance, we would request some data files to be emailed to us and often we could tell what the problem was.
If you have room for a few extra bytes in the packet, I would really recommend doing something similar.
Taking things to another level of sophistication, it might be possible to drop the data rate in situations of poor signal strength. I don't know if the wireless module will support this?
hth
Bob
Re: RF Data Structure for PV Router Systems
it might be possible to drop the data rate in situations of poor signal strength. I don't know if the wireless module will support this?
Yes it is, and it's been done, and I've seen the code. A search of the forums is in order - IIRC it was either MartinR or Martin Harizanov.
Re: RF Data Structure for PV Router Systems
The data rate command register for the RFM12B is described in the attached extract from the main data sheet. Martin Roberts uses 0xC606 to achieve the standard 49.2 kbps and he recommends 0xC657 for 3.8918 kbps.
The C6 is a fixed requirement. It is only the the state of cs and r6 -- r0 that vary.
Re: RF Data Structure for PV Router Systems
Are you processing any of this data using emonCMS, or similar? Or just it just go to your display unit(s), in which case a purpose-built structure may be ideal.
I don't yet have any kind of master although in the longer term I hope to include something. Currently I have a modified example of Martin's eMC controller with a remote diverter of my own design and two modified emonGLCD.
It occurs to me that the base-station could usefully transmit some accumulated data rather than leaving all of the processing for the receiving end to do. By that means, a emonGLCD unit unit could always start up showing some meaningful totals, rather than just what's happening now.
I agree that it makes more sense for accumulated data to be held in the diverter.
A simple protocol should allow any amount of data to be sent, albeit not in every message. Each RF message could include the current status of key parameters, plus some background data too, rather like the teletext protocol.
My remote diverter operates on a real time change of state signal which may not be how anyone else is doing this.
Re: RF Data Structure for PV Router Systems
My remote diverter operates on a real time change of state signal which may not be how anyone else is doing this.
Mine does too, so that aspect is certainly not going to disappear on my watch!
With these chilly temperatures, but plenty on sun, having an additional place to dump surplus power after the DHW is at max temp makes a lot of sense. I think I've got all the bits now for my remote diverter, I just haven't put them together yet!
Just a reminder that the purpose of this thread is to ascertain whether anyone who has built a PV Router is sending data out to emonCMS (or anywhere else) in any kind of standard format.