I want to measure RPM of a metal wheel using an inductive proximity sensor (npn) and a LM2917N which is supose to convert frequency into voltage which I intend to read using an ESP32 since has 12bits ADC.
The wheel has 2 holes which will be "see" by the sensor and a diameter of 50mm. Basically for a complete RPM sensor needs to "see" 2 wholes. Considering the max speed of the wheel which I intend to measure is 5 km/h I made following calculations:
Max rpm of the wheel will be around 530 rpm.
For that rpm sensor will get max 1060 pulses per minute which means about 17.67 Hz
Min rpm which I would like to measure is 100 rpm which means about 3.2 Hz.
Now the concerns:
I see in LM2917N datasheet that the input voltage can be 0 and 28 V, in my setup will be powered at 12V and supply voltage I assume will be same 12V since proximity sensor is powered also on same power supply as LM2917N.
I am not able to do calculations of the C1, C2 and R1 based on my setup and also have to find a way to put the output voltage in range of 0-3.3V (esp32 limits)
Second help is needed to understand how to match the read voltage to frequency (eg - 1V means 10Hz or rpm...)
Any help will be highly appreciated
Thanks in advance!
after reading datasheet : formula is Vo = R1 × C1 × VCC × f
with Vcc=12V, C1=0.1 mF and R1=100K >> V0=0.12V/Hz
for 18Hz, output will be 2.16V
so you can connect directly output to analog input and convert value as
int getRPM() {
float V0 = 3.3 * analogRead(A0)/1024;
float F = V0 / 0.12;
int rpm = F * 60;
return(rpm);
}
How I can calculate accurate energy if I have Power, Current , Voltage values
This is the code of energy calculation, the result's it's wrong so how I can fix that
I want to measure apparent energy, I don't have a problem in V , I, P values
if(millis() >= energyLastSample + 1)
{
energySampleCount = energySampleCount + 1;
energyLastSample = millis();
}
if(energySampleCount >= 1000)
{
apparent_energy_l1 = apparent_power_l1/3600.0;
finalEnergyValue_l1 = finalEnergyValue_l1 + apparent_energy_l1;
apparent_energy_l2 = apparent_power_l2/3600.0;
finalEnergyValue_l2 = finalEnergyValue_l2 + apparent_energy_l2;
apparent_energy_l3 = apparent_power_l3/3600.0;
finalEnergyValue_l3 = finalEnergyValue_l3 + apparent_energy_l3;
// Serial.print(finalEnergyValue,2);
// Serial.println("test");
energySampleCount = 0 ;
}
energy_total= finalEnergyValue_l1+finalEnergyValue_l2+finalEnergyValue_l3;
}
Some tips about power calculation using Arduino or any microcontroller,
open-source code or project,
guidelines to solve my problem
Note that energy (W x t) is a measurement of power over time, while power is a measurement of work, meaning that you cannot simply divide power by 3600 (which would be the factor to convert from seconds to hours) to get an energy value. Power (W) is a measurement of how much work for example a device is currently doing. If you want to calculate the Energy consumed by a device, you will have to continuously measure the Power, for example in 1s intervals, and add it to a counter. Then you have a value which represents Ws - Watt seconds. You can then calculate the Wh consumed from that value.
Example:
You have a device which consumes 300W of power. You keep that device running for exactly 3 hours. If you measure the power consumption every second as described, you will have measured 3240000 Ws. 3240000 Ws / 3600 = 900Wh / 1000 = 0,9 kWh. You can of course change your measurement interval to fit your needs in regard to accuracy.
Pseudocode:
if ( millis() >= lastmillis + 1000 )
{
lastmillis = millis();
wattseconds = wattseconds + power; #increment energy counter by current power
kilowatthours = wattseconds / 3600000;
print(kilowatthours)
}
You could of course use a one second interrupt with an external RTC to get a more accurate timing.
I have been studying the digital audio processing by using the book <Designing Audio Effect Plugins in C++>.
For analog Sinusoid:
Complex Sinusoid = e^(jωt)
Delayed Sinusoid = e^(jω(t−n)) = e^(jwt) * e^(-jwn), a delay of n seconds
For digital sampled version:
sampled complex sinusoid = e^(jωnT), T is interval for each sample, n is the index of sample
I understand all above, but I got confused about the delayed sampled sinusoid which described as: e^(jω ( nT −M )), M = samples of delay
But I think it should be described as e^(jωT( n − M )), since the T is a constant for a fixed sample rate, n and M has the same unit.
Anyone can explain it for me?
You are right about e^(jωT( n − M )), when M represents delay as sample count
Formula e^(jω ( nT −M )) is valid for M as time
Where can I find the information about error ranges for trigonometric function instructions on x86 processors, like fsincos?
What you ask is rarely an interesting question, and most likely you really want to know something different. So let me answer different questions first:
How to calculate trigonometric function to a certain accuracy?
Just use a longer datatype. With x86, if you need the result with double accuracy, do an 80-bit extended double calculation and you are on the safe side.
How to get platform-independent accuracy?
You need a specialized software solution for this, like MPFR
That said, let me come back to your original question. Short answer: for small operands it should be typically within 1 ulp. For larger operands it's getting worse. The only way to find out for sure is to test this for yourself, like this guy did. There is no reliable information from the processor vendors.
For Intel CPUs the accuracy of the built-in transcendental instructions is documented in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, section 8.3.10 Transcendental Instruction Accuracy:
With the Pentium processor and later IA-32 processors, the worst case error on transcendental functions is less than 1 ulp when rounding to the nearest (even) and less than 1.5 ulps when rounding in other modes.
It should be noted that the error bound of 1 ulp applies to the 80-bit extended-precision format, as all transcendental function instructions deliver extended-precision results. The issue noted by Stephen Cannon in an earlier comment regarding a loss of accuracy, relative to a mathematical reference, for the trigonometric function instructions FSIN, FCOS, FSCINCOS, FPTAN, due to argument reduction with a 66-bit machine PI, is acknowledged by Intel. Guidance is provided as follows:
Regardless of the target precision (single, double, or double-extended), it is safe to reduce the argument to a value smaller in absolute value than about 3π/4 for FSIN, and smaller than about 3π /8 for FCOS, FSINCOS, and FPTAN. [...] For example, accuracy measurements show that the double-extended precision result of FSIN will not have errors larger than 0.72 ulp for |x| < 2.82 [...]
Likewise, the double-extended precision result of FCOS will not have errors larger than 0.82 ulp for |x| < 1.31 [...]
It is further acknowledged that the error bound of 1 ulp for the logarithmic function instructions FYL2X and FYL2XP1 only holds when y = 1 (this was not clear in some of Intel's older documentation):
The instructions FYL2X and FYL2XP1 are two operand instructions and are guaranteed to be within 1 ulp only when y equals 1. When y is not equal to 1, the maximum ulp error is always within 1.35
Using a multi-precision library, it is straightforward to put Intel's claims to a test. To collect the following data, I used Richard Brent's MP library as a reference, and ran 231 random test cases in the intervals indicated:
Intel Xeon CPU E3-1270 v2 "IvyBridge", Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
2xm1 [-1,1] max. ulp = 0.898306 at x = -1.8920e-001 (BFFC C1BED062 C071D472)
sin [-2.82,+2.82] max. ulp = 0.706783 at x = 5.1323e-001 (3FFE 8362D6B1 FC93DFA0)
cos [-1.41,+1.41] max. ulp = 0.821634 at x = -1.3201e+000 (BFFF A8F8486E 591A59D7)
tan [-1.41,+1.41] max. ulp = 0.990388 at x = 1.3179e+000 (3FFF A8B0CAB9 0039C790)
atan [-1,1] max. ulp = 0.747328 at x = 1.2252e-002 (3FF8 C8BB9E06 B9EB4DF8), y = 3.9204e-001 (3FFD C8B8DC94 AA6655B4)
y2lx [0.5,2.0] max. ulp = 0.994396 at x = 1.0218e+000 (3FFF 82C95B56 8A70EB2D), y = 1.0000e+000 (3FFF 80000000 00000000)
yl2x [1.0,1.2] max. ulp = 1.202769 at x = 1.0915e+000 (3FFF 8BB70F1B C5F7E103), y = -9.8934e-001 (BFFE FD453A23 AC926478)
yl2xp1 [-0.7,1.44] max. ulp = 0.990469 at x = 2.1709e-002 (3FF9 B1D61A98 BF349080), y = 1.0000e+000 (3FFF 80000000 00000000)
yl2xp1 [-1, 1] max. ulp = 1.206979 at x = 9.1169e-002 (3FFB BAB69127 C1D5C158), y = -9.9281e-001 (BFFE FE28A91F 132F0C35)
While such non-exhaustive testing cannot prove error bounds, the maximum errors found appear to confirm Intel's documentation.
I do not have any modern AMD processors to test, but do have test data for an old 32-bit Athlon CPU. Full disclosure: I designed the algorithms for the transcendental functions instructions used in 32-bit Athlon processors. My accuracy target was less than 1 ulp for all the instructions; however the same caveat about argument reduction by 66-bit machine PI for trigonometric functions already mentioned above applies.
Athlon XP-2100 "Palomino", x86 Family 6 Model 6 Stepping 2, AuthenticAMD
2xm1 [-1,1] max. ulp = 0.720006 at x = 5.6271e-001 (3FFE 900D9E90 A533535D)
sin [-2.82, +2.82] max. ulp = 0.663069 at x = -2.8200e+000 (C000 B47A7BB2 305631FE)
cos [-1.41, +1.41] max. ulp = 0.671089 at x = -1.3189e+000 (BFFF A8D0CF9E DC0BCA43)
tan [-1.41, +1.41] max. ulp = 0.783821 at x = -1.3225e+000 (BFFF A947067E E3F4C39C)
atan [-1,1] max. ulp = 0.665893 at x = 5.5333e-001 (3FFE 8DA6B606 C58B206A) y = 5.5169e-001 (3FFE 8D3B9DC8 5EA87546)
yl2x [0.4,2.5] max. ulp = 0.716276 at x = 6.9826e-001 (3FFE B2C128C3 0EF1EC00) y = -1.2062e-001 (BFFB F7064049 BC362838)
yl2xp1 [-1,4] max. ulp = 0.691403 at x = 1.9090e-001 (3FFC C37C0397 F8184934) y = -2.4796e-001 (BFFC FDE93CA9 980BF78C)
The AMD64 Architecture Programmer’s Manual, Vol. 1, in section 6.4.5.1 Accuracy of Transcendental Results, documents the error bounds as follows:
x87 computations are carried out in double-extended-precision format, so that the transcendental functions provide results accurate to within one unit in the last place (ulp) for each of the floating-point data types.
You can read the Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 1 section 8.3.10 on Transcendental Instruction Accuracy. There is a precise formula, but also the more accessible statement
With the Pentium processor and later IA-32 processors, the worst case error on transcendental functions is less than 1 ulp when rounding to the nearest (even) and less than 1.5 ulps when rounding in other modes.
I am using an Arduino Due with a TMP36 (for reading temperature). Here is my formula that converts the readings to °F:
tempReading = analogRead(tempPin);
voltage = tempReading * 5.0; // Saves the voltage
voltage /= 1024.0;
tempC = (voltage - 0.5) * 100 ; //Converts to Celsius
tempF = (tempC * 9.0 / 5.0) + 32; //Converts to Fahrenheit
In the serial, my Arduino is printing out temperatures from 90-100 °F, and my house is set to about 70 °F. What the problem here be?
From http://arduino.cc/en/Main/ArduinoBoardDue:
"Unlike other Arduino boards, the Arduino Due board runs at 3.3V. The maximum voltage that the I/O pins can tolerate is 3.3V. Providing higher voltages, like 5V to an I/O pin could damage the board."
So likely you should multiply tempreading not by 5, but by 3.3.