Archived Forum

Just one short addition here - just after writing the text above I did a short search for Raspberry UART count and found someone's idea of using USB-to-UART(TTL) converters which would give additional serial inputs.

Would it be possible for emonHub to receive data from multiple serial interfacers ?

Could emonHub add additional infos to the serial stream - like a node id ?

you can indeed use usb<->serial adapters, I frequently hook up nodes via a FTDI programmer. In emonhub you would need to define the additional interfacers in emonhub.conf probably using /dev/ttyUSB0 and /dev/ttyUSB1 in place of the /dev/ttyAMA0,

​I would recommend setting them up identically in emonhub.conf and define the node id's in the emontx sketches as the way Raspbian allocates the device ref's (ttyUSB0 and ttyUSB1) is not absolutely guaranteed to be the same at each reboot, they are allocated in order as the devices are discovered but if they are configured to be identical and the node id is part of the incoming payload it doesn't matter.

If you search the forum for "serial-direct" you will see it's quite common and quite easy to implement a single emonTx, just edit the sketch to output a node id and payload in the "nodeid var1 var2 var3..." format and edit emonhub.conf.

Paul .

That sounds great - thanks for the help.
I will have a look at the serial-direct discussions.

I saw a Arduino script for "serial-direct" - is it possible to use the discrete sample sketch with RF and export the data to the serial port as well ?
And is it possible to decrease the interval between measurements and serial send ?

I would of thought this setup would work with any of the OEM sketches, most of them already have some foem of serial output for debugging. The existing serial prints just need to be replaced with the "OEM formatted payload" in the form nodeid val1 val2 val3....etc" so yes you should be able to pas the same dat over serial and by rf from the same sketch.

Shortening the interval between serial prints is very do'able depending on what other stuff is happening you could probably do 1 sec, however if you are sending rf packets in tandem that could cause traffic issues on the rf network so you need to only go as fast as the rf will let you or add some code to increase the frequency of the serial outputs only which will involve some totalling and/or averaging so not so straight forward.

Paul

The idea behind was to screw off the RF Antennae from 3 TxV3 and give them an interval of 1/s or below.
I'd realy like to do some "profiling" on the current lines to decide between "devices" beeing switched on and of.

The idea was to change the Interval maybe by the dip switches (instead of US, ...) and to omit things like one wire Temp sensors or pulse counting (since I don't need it - maybe pulse....).

I guess even RF sending could be turned on or of by dip switches.

Which interval will be the smallest possible (with serial transmit only) ?

and a little off topic - regarding calibration....

Do I need to calibrate the readings for the TxV3 when ordered with a standard AC/AC Adapter ?
And when YES, what do I need to calibrate ?

Especially - Do I need to calibrate the internal reference voltage or not ?

Do I need to calibrate the readings for the TxV3 when ordered with a standard AC/AC Adapter ?

Most likely yes, to compensate for component variations.

And when YES, what do I need to calibrate ?

Voltage, Current and Phase Angle.

Especially - Do I need to calibrate the internal reference voltage or not ?

No.   It doesn't matter what the Vref is so long as it's stable  (actually, I think most OEM sketches use Vcc as the Vref).   Any component variations in Vref will get sorted out when you calibrate the above items.  

The only exception to that is when you're running off batteries.  ReadVcc() effectively uses one of the internal bandgap voltages to measure the battery voltage.  If you want that battery measurement to be accurate then you need to know your actual bandap voltage.  Since you're running of mains, you can ignore it.

I would disable the rf in code rather than unscrew the antenna to reduce the workload (and possible seepage) I do not know what speeds you could manage as there are too many variables (for me anyways) things to bear in mind is the prints can slow down the code so may impact readings. If the print loop is independent of the calculations you may end up sending the same results multiple times in between calc cycles.

A RPi 2 B would be better suited to this than a B or B+ and it will probally be best to throttle the uploads to emoncms. If you set a send interval of 10secs for instance emonhub will collate all the data and send it in one go every 10 seconds rather than bombard the server. This is an absolute must if sending to emoncms.org, you can of course send as frequently as you like to a local server but it won't improve anything except responsiveness of the widgets as the same number of data points are passed just in batches rather than singly.

It may also be a good idea to use a localhost url to keep the traffic off the LAN or going via a DNS etc.

It will be interesting to hear back what speeds you obtain, I know on occasions when I have omited a delay data frames can successfully accumulate much faster than I could count but I have never actually checked the accuracy or validity of them. maybe someone could theorize an estimate??

Paul

Maybe I misunderstood the whole process of measurement within the script.

As far as I understood, the sketch does a discrete sampling of same values (Voltage from AC/AC, Power from CT1..4). After having recorded these samples (how long is the sample period ?) the RMS values are transmitted to a receiver (emonHub via RF or Serial).

What happens now ?
From the sketch code I would guess, emonTxV3 goes to sleep for 10 seconds and start again with sampling and sending.

So from my point of view, all values (power, current) in between these 10s are lost and not recorded. High loads within this period will not be recorded.

What I am actually trying to do is - put 3x emonTxV3 into the mains/fuse box in the building. Connect each of them via serial to one Pi B+ or Pi2 (doesn't matter for me) and configure the Pi's emonHub to send it to a local 2nd "Pi 2" which has a SSD attached and records the data inside its emonCMS with a MariaDB,

The emonCMS / MariaDB is already working now for RF measurements each 10s from my existing emonTxV3.
From my stomache feeling a few Bytes of data each second shouldn't be a problem - neighther for a Pi B+ nor for the LAN. But I might be wrong on this.
I am not using emonCMS.org online at all - just local recording with a fixed IP.

What I didn't understand was this

"If you set a send interval of 10secs for instance emonhub will collate all the data and send it in one go every 10 seconds rather than bombard the server"

I only found the setting for altering the send interval inside the sketch file for the TxV3. I did not see any such setting for emonhub at all.
Does emonHub collate the data and sends 10packets at once after 10s ?

Thanks for all the replies ! It was realy realy helpful so for for me as a novice.

I have been a bit hazy on what your end goal was so answering direct questions and giving generalized info. When you mention "discreet sampling sketches" and also "sending serial data every second" I didn't imagine you meant both together I thought you where exploring avenues.

There would be very little point in using the discreet sketch, you mention "profiling" and data at 1s intervals, the discreet sketch's sample period is tiny compared to the update interval and even bringing the interval down to 1s you are only getting part of the picture. You should use a continuous sampling sketch for there to be any point in a 1s interval.

The update interval defined in the sketch will set how often the data is forwarded to emonHub (by serial or rfm) when emonhub receives each packet it places it in a buffer and then independently the buffer is flushed regularly to forward the data to emoncms. With a 10s update interval the buffer operation is transparent unless there is a network issue and the data backs up and gets forwarded when the network comes up.

When sending >packets per second it would be easier going on all involved if there was 1 update of 30+ frames to emoncms(s) rather than 30+ attempted connections. It isn't usually needed but in emonhub.conf in the emoncms interfacers [[[runtimesettings]]] you can define interval = 10 which will limit the update frequency and buffer all the packets for bulk upload, each with it's own timestamp so emoncms still gets the same granularity of data but in manageable chunks every 10s.

The comment about localhost was aimed at not extending the data's journey unnecessarily thus increase speed and prevent outside influence preventing delivery as 3+ packets per second will shorten the time it takes for the buffers to fill up. There just seemed little point in sending data to www.mydomain.com -> mydns.com -> local router -> back to the same device if speed was the goal, you will just use the LAN ip for your 2nd Pi in your case and no I wouldn't expect the amount of data to be an issue unless the network stalls. With the default buffer size of 1000 it would only take around 5 mins to overflow that at 3+ frames per sec, 

Paul

Is there an example of a continuous sampling sketch available ?
As I pointed out - I am really new to all of this - I'm not sure if I can create a suitable sketch from scratch.

As for the discrete sketch - I can easily choose 1s intervall - since the sampling time is much short - did I get that right ? How would I enlarge the sampling time (to let's say 3/4 of a second) ?

Just for the first tests without caring about continuous measurement.

What is the backdrop (regarding power consumption) with continuous measurement vs. discrete sampling ?

Thanks for the help again !

https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxV3/RFM/emonTxV3.4/emonTxV3_4_continuous_kwhtotals/emonTxV3_4_continuous_kwhtotals.ino

I don't no for sure but I would expect any "serial direct" examples you have found to be continuous sampling as even if you don't have an AC adapter, the Pi would be used to power a directly connected emonTx so Battery life is not a concern. The discreet sampling's power consumption is only good to prolong battery life, since when using the AC adapter to power the Pi running a continuous monitoring sketch, imposes a 20mA current limit, I think we can assume the current drawn is of negligible consequence compared to running the 2 Pi's. In fact not sending the data by rf will possibly offset any increase due to not sleeping

I see no benefit of rewriting a sketch designed for a scenario you are not using, to almost fit the gap that is already catered for. I'm still not entirely sure of your goal. but if you just want 3 emonTx's reporting every 1s then 3 x continuous sampling sketches with a 1s interval is by far your best bet.

Paul

Thanks a lot - that helped me out.
Next step is to order the missing 2 TxV3s and get running :-)

I will update this  thread next week when I've got some results.

Paul wrote "I would disable the rf in code rather than unscrew the antenna to reduce the workload (and possible seepage)"

You should definitely do that, otherwise you risk damage to the RFM69CW radio module if it operates at full power without an antenna. (The data sheet specifies "Maximum VSWR at antenna port at +13dBm - 3:1")