Is faster sampling firmware practicable?

Greetings all. 

I'm interested in higher resolution sampling so wondering how small I could set the time between samples in the firmware for it to be reliable?

Would it make sense (e.g.) to ramp up the frequency of firmware publication (for purposes like mine) and move the 5 second sampling delay downstream from the firmware to the interface (for emoncmshttp eg) ?

Suggestions welcomed.

Robert Wall's picture

Re: Is faster sampling firmware practicable?

Your suggestion may prove problematical if you are using a radio link, because there are licensing constraints on the proportion of time that a single transmitter can occupy the band. If you're using a wired serial link, the only limit will be the rate at which you can send the data. I've not tried this (and I don't have time at present to do so), but I suspect that sub-1 second would be possible, provided that you restricted the amount of data sent each time. But you won't be able to send to emoncms.org at that rate.

fubar's picture

Re: Is faster sampling firmware practicable?

Right - thanks.

I'd already figured out emoncms.org would probably not cope well with fast data streams but hadn't thought about radio spectrum because I'm not using any radio links.

My emonpi is sitting in our fuse box and connects to the home wifi network. I was more concerned about internal "serial" (did I read in the hardware docs that it's actually a gpio?) bandwidth but you're right - any solution I come up with will not be generalisable to radio linked setups. Thanks again for pointing that out.

glyn.hudson's picture

Re: Is faster sampling firmware practicable?

Emoncms.org is restricted to 10s data. If you run emoncms on your own server you will be able to post faster 

fubar's picture

Re: Is faster sampling firmware practicable?

Yes, thanks - as I said, I'd figured that out.

My goal is to build a much more lightweight statistical and display system based on http://bokeh.pydata.org in an effort to bypass emoncms completely on a single user system. 

 

kaulquappe's picture

Re: Is faster sampling firmware practicable?

I found several threads claiming that it is possible to change the sampling rate if you have installed it on a private server, but i couldn't find any that actually explains how to do that!?

Maybe it's just me not being able to type the right searchphrases. However I need some help on this!

greatings

kaulquappe

 

Bbaass_TMH's picture

Re: Is faster sampling firmware practicable?

In the emonTxV3.4 firmware, look for

const byte TIME_BETWEEN_READINGS = 10;

That sets the sampling rate.

kaulquappe's picture

Re: Is faster sampling firmware practicable?

This is actually only changing the time the emonTX is sending its sample, I think emoncms has it's own limmitation of how often it is updating, because glyn said the emoncms.org is limited to 10s.

Is there just no limit at all on a private emoncms and it is just applying to the sample rate of the emontx?

fubar's picture

Re: Is faster sampling firmware practicable?

Is there just no limit at all on a private emoncms and it is just applying to the sample rate of the emontx

As far as I can tell from reading the code, it looks like the interfacer will send an update to emoncms via http every 30 seconds and each update will contain all node records accumulated during that 30 second time interval.

So I am guessing that if the firmware is changed to update (eg) every second rather than the default 5 seconds, payloads arriving at emoncms every 30 secs will have 30 data rows from that node rather than 6 rows with 5 second interval sampling in the firmware. Note the comment above about radio spectrum problems with faster updates if you do change the firmware and use radio transmission.

Did I get that right?

I'm testing a modified version of emonhub/src/EmonHubEmoncmsHTTPInterfacer.py ("EmonHubRateLimitedEmoncmsHTTPInterfacer.py") - the emoncms interface. No matter what the firmware sampling interval, the data sent to emoncms will be down-sampled to (eg) every 5 seconds to minimise any disruption from faster firmware sampling. Is this of interest to anyone? Happy to make a pull request when it's done.

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.