PicoScope 7 Software
Available on Windows, Mac and Linux
Flow measurement (pulse)
Flow measurement (pulse)
I have a Flow-Rate Sensor which generates pulses (max 400Hz).
I want to se and log a graph of the frequency over time. How do I do that?
Can I use PicoLog 1216?
Is it possible to count pulses?
I want to se and log a graph of the frequency over time. How do I do that?
Can I use PicoLog 1216?
Is it possible to count pulses?
Re: Flow measurement (pulse)
Hi DBJ,
It's not possible to count pulses in PicoLog 6, but in PicoScope 6 you can actually create a Math Channel that will plot frequency.
However, it would be better to do this using a PicoScope 2204A rather than a PicoLog 1216 (unless you need a lot of channels), because the PicoLog can only stream data to the Computer at a rate of 1Ks/s per channel, which means that the Math Channel struggles resolving frequencies above 500Hz. So, instead of getting a precise plot as the frequency increases, you get ever increasing jumps to a value that covers an ever increasing range of frequencies, i.e. the plot resolution drops and the image becomes more blocky looking (see the image below, where the Blue waveform is a squarewave being stepped up and down in frequency, and the red waveform plots that frequency).
In contrast, you can stream at 2kS/s in the PicoScope 2204A (or even faster) to give you a much more precise plot (as shown below).
Also, with the PicoLog 1016 you can only stream for a maximum time of 16mins 40secs in one complete capture, while with the PicoScope 2204A you can stream for much longer (in fact it's only at a 2hours 46mins 40 secs Collection Time that the display has the blocky resolution of the PicoLog 1216). (Note that you can set an alarm to automatically save the capture to a file, and then restart the capture, for both devices, but then you will have missed the data in the time taken to do that.) You can use the psdata file below for your Flow Meter measurement, which is the one used to create the PicoScope 2204A plot in the image above, and increase the Collection Time up to the limit mentioned, however just remember that the image becomes increasingly lower resolution as you do that and starts to look blocky above 3mins 20 secs.
Regards,
Gerry
It's not possible to count pulses in PicoLog 6, but in PicoScope 6 you can actually create a Math Channel that will plot frequency.
However, it would be better to do this using a PicoScope 2204A rather than a PicoLog 1216 (unless you need a lot of channels), because the PicoLog can only stream data to the Computer at a rate of 1Ks/s per channel, which means that the Math Channel struggles resolving frequencies above 500Hz. So, instead of getting a precise plot as the frequency increases, you get ever increasing jumps to a value that covers an ever increasing range of frequencies, i.e. the plot resolution drops and the image becomes more blocky looking (see the image below, where the Blue waveform is a squarewave being stepped up and down in frequency, and the red waveform plots that frequency).
In contrast, you can stream at 2kS/s in the PicoScope 2204A (or even faster) to give you a much more precise plot (as shown below).
Also, with the PicoLog 1016 you can only stream for a maximum time of 16mins 40secs in one complete capture, while with the PicoScope 2204A you can stream for much longer (in fact it's only at a 2hours 46mins 40 secs Collection Time that the display has the blocky resolution of the PicoLog 1216). (Note that you can set an alarm to automatically save the capture to a file, and then restart the capture, for both devices, but then you will have missed the data in the time taken to do that.) You can use the psdata file below for your Flow Meter measurement, which is the one used to create the PicoScope 2204A plot in the image above, and increase the Collection Time up to the limit mentioned, however just remember that the image becomes increasingly lower resolution as you do that and starts to look blocky above 3mins 20 secs.
Regards,
Gerry
Gerry
Technical Specialist
Technical Specialist
Re: Flow measurement (pulse)
Yes a pico scope can show high frequencies too, but I need max 400Hz.
You cannot even with a math channel, neither show frequecy or count pulses with PicoLog 1000. It requires an integral function and a such is not
You cannot even with a math channel, neither show frequecy or count pulses with PicoLog 1000. It requires an integral function and a such is not
Re: Flow measurement (pulse)
Hi DJB,
Sorry I have been off work for a week and then catching up last week.
The short answer to your statement:-
"You cannot even with a math channel, neither show frequency or count pulses with PicoLog 1000. It requires an integral function and a such is not"
is that you can show cycle or pulse count as a waveform which should be reasonably accurate for a capture time of 16 minutes and 40 seconds in a PicoScope 2204A with a maximum flow rate of 400Hz at a 50% duty cycle (which you can see in the second to last data file posts when you scroll to the bottom of this reply). However, this depends upon whether 5ms glitches can be excluded from typically expected flow rate waveforms.
The Long answer is as follows:
Actually what you need to count pulses is a representation of time or a reference to the trigger point that you can use in calculation (I have a Math channel in the example below that counts pulses or cycles without an integral), unfortunately, neither of which you will find in PicoLog 6 software, which is why I was focussing on using PicoScope 6 software, in my last reply.
In your first post you mentioned that you want to see and log the graph of frequency over time, but you didn't mention for how long you want to do this. As you are looking at a data logger I have assumed that you want to do this for a reasonable length of time. As your maximum frequency will be 400Hz, then if all you want is the count of the number of pulses you can do this, but only for a very small time period, if using a data logger in PicoScope 6.
In the following examples, I have used a PicoScope to Generate the pulses (as squarewaves) at 400 Hz for a PicoLog 1012 (as I'm working from home, I only have a PicoLog 1012), as shown below, with a Math Channel counting the pulses from the Trigger point:
You will notice that this is an oversimplification because I'm not considering duty cycle variation, but the principle of validating the method and using it still applies.
To start with, I captured 1/2 a second of data at 15.63MS/s in Fast Sampling Mode and calculated the number of pulses, using a Math Channel, and a rising Edge Count Measurement (to confirm the Math Channel Calculation, as shown below):
As you can see (more clearly in the image of the zoomed in view of the data) there is a mixture of slightly different frequency cycle lengths that are used in the waveform recreated in the display, in order to get an average of 400Hz. This variation represents a small uncertainty, and the error in the signal becomes much more of a problem when you try to capture data for longer capture times in slow sampling Mode.
So, when you increase the capture time to 1 second, by default, PicoScope 6 will switch to Slow Sampling Mode, and in this Mode the sample rate is fixed at the Streaming rate that we quote in the Specifications when using PicoScope 6 with our PicoScopes. Note that, for the PicoLog 1000 series Data Logger Specifications, this will be the same value that we quote for 'when Streaming and using our PicoLog software', i.e. 1kS/s. So, in PicoScope 6, when you go to a Total Capture Time of 1 second, the sample rate changes to 1kS/s for the PicoLog 1012 and the captured data looks as shown below:
As you can see in the zoomed in image, the cycle lengths are switching between 2 values to give a correct average value in the recreated waveform for the display. As you can see in the normal sized (zoomed out) image, the Math Channel error is proportional in size to the count value, so it increases as the count increases. In this case, the error is much larger, because the sampling rate is much lower, meaning that the frequencies have to be switched over a longer distance. This reduction in frequency resolution corresponds to the blocky looking resolution that I was referring to in my previous post (containing the sweeping frequency images) and clearly makes the math Channel unusable.
So to overcome this large error it is better to use Fast Sampling Mode giving you higher frequencies for the same Capture times. So, this is what I did for the next capture, to get a relatively error free Math Channel calculation for a capture time of 5 seconds (i.e. 5 times the last one) at a sample rate of 1.6kS/s (if you are following with the data file, you have to change the 'Collection Time' in the 'Sampling Tab' of the 'Tools->Preferences' Menu in order to keep Fast Sampling for longer capture periods) and I then calculated the number of pulses, using the same Math Channel (you also need to adjust, by a corresponding amount, the maximum value for the range over which the Math Channel can display values in order to maximise the displayed vertical range of the Math Channel). This better Fast Sampling Mode capture is shown in the following data:
As you can see, at this sample rate, for this particular capture the Math Channel has a glitch (which could be considered a short enough time event to not cause a problem, as discussed in the next section). The rest of it is a straight line, but that is because the sample rate is a multiple of the pulse rate (the glitch may appear anywhere, or not at all, because it is caused by the slightly different clocks of the PicoScope Signal Generator and the PicoLog 1012 as they are drifting out of phase). This is the longest amount of time that you can capture the data for, and still get a potentially useful Math Channel, but in the PicoLog 1216 the maximum potentially usable time would be 10 seconds (as the memory buffer in the hardware data logger is twice the size). So, clearly, to capture data for a longer time you would need more Buffer memory in the capture device, or better still a faster Streaming rate in the Slow Sampling Mode of PicoScope 6.
This was the point that I was making when I suggested using a PicoScope instead of the PicoLog 1000 series data logger. For instance a PicoScope 2204A (which wouldn't be a significant drain on your finances, because it is priced similarly to the PicoLog 1012) would give you a much higher sample rate, in Slow Sampling Mode. This means that the error in the Math Channel would be tiny in comparison to the error in the data logger, and potentially removable from true results, giving you much higher accuracy, and is shown below, when using a PicoScope 2204A to perform a Slow Sampling Mode, 16 minute 40 second capture, at a sample rate of 10kS/s:
In the Zoomed in views, you can see that there are regular small glitches in the Math Channel waveform. These glitches have a width of 5ms, and therefore represent extremely quick changes, which are unlikely to represent the rate of change of a natural process such as the rate of flow. They also return to exactly the same value, so they are easy to eliminate from consideration.
If you want maximum accuracy only then, 16m40s will be the limit of how long you can sample without errors (apart from the potentially discountable glitches), because when you increase the capture time to 33 minutes 20 seconds, you can see the frequency switching error starting to occur in the Maths Channel again (although as a small proportional error), as shown in the capture below:
Note that you can't discount the errors here because instead of a brief excursion to an error value before returning to a correct value, they are switching between 2 values, neither of which are the average value which indicates the true value of the count. So they add a constant proportional value of uncertainty (error) to the count values.
So, in general, as you can see, you can create a pulse count waveform, with potentially usable Math Channel waveforms, but whether this will be suitable depends upon (a) the maximum pulse rate, (b) how long you need to log the pulse count waveform for, (c) to what accuracy you need the flow rate displayed as (you could log data for longer, with increasingly less accuracy as you extend the capture time) and (d) whether or not 5ms glitches can be ignored in terms of natural flow rates (note that if they can't be ignored then they will add an uncertainty/error to the Math Channel waveform equal to the height of the glitch). Typically you will need to investigate the errors that will occur in the Math Channel waveform, to see what errors you can tolerate in your flow rate waveform. You can do this by testing pulses generated at the maximum rate of flow and minimum pulse width, if needed, by generating different pulse widths in the Arbitrary Waveform Generator (AWG), which you can do with a PicoScope, as all models apart, from the 4224, 4424 and 4444 models have Signal Generators with AWG's (which is another reason for using a PicoScope over a PicoLog 1000 series).
Hopefully this clarifies how you can do cost-effective, short duration flow rate measurement using a Pico Technology product.
Regards,
Gerry
Sorry I have been off work for a week and then catching up last week.
The short answer to your statement:-
"You cannot even with a math channel, neither show frequency or count pulses with PicoLog 1000. It requires an integral function and a such is not"
is that you can show cycle or pulse count as a waveform which should be reasonably accurate for a capture time of 16 minutes and 40 seconds in a PicoScope 2204A with a maximum flow rate of 400Hz at a 50% duty cycle (which you can see in the second to last data file posts when you scroll to the bottom of this reply). However, this depends upon whether 5ms glitches can be excluded from typically expected flow rate waveforms.
The Long answer is as follows:
Actually what you need to count pulses is a representation of time or a reference to the trigger point that you can use in calculation (I have a Math channel in the example below that counts pulses or cycles without an integral), unfortunately, neither of which you will find in PicoLog 6 software, which is why I was focussing on using PicoScope 6 software, in my last reply.
In your first post you mentioned that you want to see and log the graph of frequency over time, but you didn't mention for how long you want to do this. As you are looking at a data logger I have assumed that you want to do this for a reasonable length of time. As your maximum frequency will be 400Hz, then if all you want is the count of the number of pulses you can do this, but only for a very small time period, if using a data logger in PicoScope 6.
In the following examples, I have used a PicoScope to Generate the pulses (as squarewaves) at 400 Hz for a PicoLog 1012 (as I'm working from home, I only have a PicoLog 1012), as shown below, with a Math Channel counting the pulses from the Trigger point:
You will notice that this is an oversimplification because I'm not considering duty cycle variation, but the principle of validating the method and using it still applies.
To start with, I captured 1/2 a second of data at 15.63MS/s in Fast Sampling Mode and calculated the number of pulses, using a Math Channel, and a rising Edge Count Measurement (to confirm the Math Channel Calculation, as shown below):
As you can see (more clearly in the image of the zoomed in view of the data) there is a mixture of slightly different frequency cycle lengths that are used in the waveform recreated in the display, in order to get an average of 400Hz. This variation represents a small uncertainty, and the error in the signal becomes much more of a problem when you try to capture data for longer capture times in slow sampling Mode.
So, when you increase the capture time to 1 second, by default, PicoScope 6 will switch to Slow Sampling Mode, and in this Mode the sample rate is fixed at the Streaming rate that we quote in the Specifications when using PicoScope 6 with our PicoScopes. Note that, for the PicoLog 1000 series Data Logger Specifications, this will be the same value that we quote for 'when Streaming and using our PicoLog software', i.e. 1kS/s. So, in PicoScope 6, when you go to a Total Capture Time of 1 second, the sample rate changes to 1kS/s for the PicoLog 1012 and the captured data looks as shown below:
As you can see in the zoomed in image, the cycle lengths are switching between 2 values to give a correct average value in the recreated waveform for the display. As you can see in the normal sized (zoomed out) image, the Math Channel error is proportional in size to the count value, so it increases as the count increases. In this case, the error is much larger, because the sampling rate is much lower, meaning that the frequencies have to be switched over a longer distance. This reduction in frequency resolution corresponds to the blocky looking resolution that I was referring to in my previous post (containing the sweeping frequency images) and clearly makes the math Channel unusable.
So to overcome this large error it is better to use Fast Sampling Mode giving you higher frequencies for the same Capture times. So, this is what I did for the next capture, to get a relatively error free Math Channel calculation for a capture time of 5 seconds (i.e. 5 times the last one) at a sample rate of 1.6kS/s (if you are following with the data file, you have to change the 'Collection Time' in the 'Sampling Tab' of the 'Tools->Preferences' Menu in order to keep Fast Sampling for longer capture periods) and I then calculated the number of pulses, using the same Math Channel (you also need to adjust, by a corresponding amount, the maximum value for the range over which the Math Channel can display values in order to maximise the displayed vertical range of the Math Channel). This better Fast Sampling Mode capture is shown in the following data:
As you can see, at this sample rate, for this particular capture the Math Channel has a glitch (which could be considered a short enough time event to not cause a problem, as discussed in the next section). The rest of it is a straight line, but that is because the sample rate is a multiple of the pulse rate (the glitch may appear anywhere, or not at all, because it is caused by the slightly different clocks of the PicoScope Signal Generator and the PicoLog 1012 as they are drifting out of phase). This is the longest amount of time that you can capture the data for, and still get a potentially useful Math Channel, but in the PicoLog 1216 the maximum potentially usable time would be 10 seconds (as the memory buffer in the hardware data logger is twice the size). So, clearly, to capture data for a longer time you would need more Buffer memory in the capture device, or better still a faster Streaming rate in the Slow Sampling Mode of PicoScope 6.
This was the point that I was making when I suggested using a PicoScope instead of the PicoLog 1000 series data logger. For instance a PicoScope 2204A (which wouldn't be a significant drain on your finances, because it is priced similarly to the PicoLog 1012) would give you a much higher sample rate, in Slow Sampling Mode. This means that the error in the Math Channel would be tiny in comparison to the error in the data logger, and potentially removable from true results, giving you much higher accuracy, and is shown below, when using a PicoScope 2204A to perform a Slow Sampling Mode, 16 minute 40 second capture, at a sample rate of 10kS/s:
In the Zoomed in views, you can see that there are regular small glitches in the Math Channel waveform. These glitches have a width of 5ms, and therefore represent extremely quick changes, which are unlikely to represent the rate of change of a natural process such as the rate of flow. They also return to exactly the same value, so they are easy to eliminate from consideration.
If you want maximum accuracy only then, 16m40s will be the limit of how long you can sample without errors (apart from the potentially discountable glitches), because when you increase the capture time to 33 minutes 20 seconds, you can see the frequency switching error starting to occur in the Maths Channel again (although as a small proportional error), as shown in the capture below:
Note that you can't discount the errors here because instead of a brief excursion to an error value before returning to a correct value, they are switching between 2 values, neither of which are the average value which indicates the true value of the count. So they add a constant proportional value of uncertainty (error) to the count values.
So, in general, as you can see, you can create a pulse count waveform, with potentially usable Math Channel waveforms, but whether this will be suitable depends upon (a) the maximum pulse rate, (b) how long you need to log the pulse count waveform for, (c) to what accuracy you need the flow rate displayed as (you could log data for longer, with increasingly less accuracy as you extend the capture time) and (d) whether or not 5ms glitches can be ignored in terms of natural flow rates (note that if they can't be ignored then they will add an uncertainty/error to the Math Channel waveform equal to the height of the glitch). Typically you will need to investigate the errors that will occur in the Math Channel waveform, to see what errors you can tolerate in your flow rate waveform. You can do this by testing pulses generated at the maximum rate of flow and minimum pulse width, if needed, by generating different pulse widths in the Arbitrary Waveform Generator (AWG), which you can do with a PicoScope, as all models apart, from the 4224, 4424 and 4444 models have Signal Generators with AWG's (which is another reason for using a PicoScope over a PicoLog 1000 series).
Hopefully this clarifies how you can do cost-effective, short duration flow rate measurement using a Pico Technology product.
Regards,
Gerry
Gerry
Technical Specialist
Technical Specialist
-
adrianpugsley
- Newbie
- Posts: 0
- Joined: Fri Dec 11, 2020 6:03 pm
Re: Flow measurement (pulse)
Hi,
I am also interested in pulse counting.
We regularly measure performance of renewable energy technologies such as solar collectors, heat pumps, etc. We currently use Delta-T DL2e data loggers to measure temperature, voltage, current, flow rates, and cumulative energy usage. The Delta-T loggers are very easy to use and have 60 channels but they are very old and are getting a bit cranky. I am struggling to find a good replacement which has enough voltage / current / thermocouple / resistance channels and also has easy-to-use pulse-count functionality (eg for flow meters and energy meters).
I bought a Picoscope 3403D last year and have found it excellent for current and voltage measurements using both Picoscope 6 and Picolog 6 software, depending on exactly what I am doing. Sometimes our measurements are short-term / instantaneous (eg using Picoscope software) but more commonly we need to log for several hours, days or weeks, recording sample-average readings every 1-minute or every 5-minutes (eg using Picolog software).
Based on the success I've had with the Picoscope, I have just convinced colleagues to let me buy 5x Picolog TC08 thermocouple loggers. I am then planning to expand by adding one or more Picolog PT104s and maybe a few Picolog 1216 or ADC24 units so we can build a modular measurement system which allows us to measure voltages, currents and temperatures.
The missing element in this new measurement system is the ability to easily count pulses from flow meters and energy meters. For example, I often use Nixon OG flow meters which give between 0.2 and 80 pulse/sec and sometimes turbine flow meters which give between 20 to 600 pulse/sec. I also sometimes use electricity meters which might only pulse a few times per hour. The counter therefore effectively needs to be able to deal with very low frequencies but can probably ignore >1kHz in most cases. There are sometimes also issues with noise from mains hum interference to deal with!
It would be great if Pico could expand the logger range or add new functionality to the Picolog software to support these pulse-count applications. Is this something that you would consider?
Regards,
Adrian
I am also interested in pulse counting.
We regularly measure performance of renewable energy technologies such as solar collectors, heat pumps, etc. We currently use Delta-T DL2e data loggers to measure temperature, voltage, current, flow rates, and cumulative energy usage. The Delta-T loggers are very easy to use and have 60 channels but they are very old and are getting a bit cranky. I am struggling to find a good replacement which has enough voltage / current / thermocouple / resistance channels and also has easy-to-use pulse-count functionality (eg for flow meters and energy meters).
I bought a Picoscope 3403D last year and have found it excellent for current and voltage measurements using both Picoscope 6 and Picolog 6 software, depending on exactly what I am doing. Sometimes our measurements are short-term / instantaneous (eg using Picoscope software) but more commonly we need to log for several hours, days or weeks, recording sample-average readings every 1-minute or every 5-minutes (eg using Picolog software).
Based on the success I've had with the Picoscope, I have just convinced colleagues to let me buy 5x Picolog TC08 thermocouple loggers. I am then planning to expand by adding one or more Picolog PT104s and maybe a few Picolog 1216 or ADC24 units so we can build a modular measurement system which allows us to measure voltages, currents and temperatures.
The missing element in this new measurement system is the ability to easily count pulses from flow meters and energy meters. For example, I often use Nixon OG flow meters which give between 0.2 and 80 pulse/sec and sometimes turbine flow meters which give between 20 to 600 pulse/sec. I also sometimes use electricity meters which might only pulse a few times per hour. The counter therefore effectively needs to be able to deal with very low frequencies but can probably ignore >1kHz in most cases. There are sometimes also issues with noise from mains hum interference to deal with!
It would be great if Pico could expand the logger range or add new functionality to the Picolog software to support these pulse-count applications. Is this something that you would consider?
Regards,
Adrian
Re: Flow measurement (pulse)
Hi Adrian,
Your requirements would be beyond what I was suggesting for DBJ, so I will put in a feature request, to our development team, to implement a long term pulse or edge counting function in PicoLog 6.
Regards,
Gerry
Your requirements would be beyond what I was suggesting for DBJ, so I will put in a feature request, to our development team, to implement a long term pulse or edge counting function in PicoLog 6.
Regards,
Gerry
Gerry
Technical Specialist
Technical Specialist