Just for the hell of it, I knocked up a 2917-a-like simulation since I couldn't find a Spice model. This is based purely on the functional description in the data-sheet, but it seems to work. I was interested to see what the 'ripple' response was like. Obviously C2 filters the output to reduce ripple, but at the side effect of increasing lag in the readings....

So here is the output for C2 = 0.1u. Takes about 70mS to get near the final value at faster speeds, but a shed load of ripple at low speed (speeds are 50 100 200 500 750 1000 1250 1500 1750 2000 2250)


Increasing C2 to 0.5u gives a settling time of 200mS, but better ripple at low speeds



Finally, try C2 = 1u as per data-sheet... again, less ripple but response time is 400mS or so

 

You are really enjoying yourself there I see *IC*. This is a nice visual representation of the ripple and settling times. I would still go up to 200 ms response time over the ripple honestly, in order to better align my commands with response in the overall system of the data logging.

Funny enough, I am actually starting to understand now, but it is all magic. I am awake and still working on it myself. Might as well ask:

That 5 V regulator, how well does it handle the 15V input in terms of heat?

 

Figure 27 in the datasheet makes the output into a 2nd order filter, which would reduce the ripple by a greater degree without the slow response.

 

Morning all, so I followed the circuit and tested its parameters. Below are the modifications as @Irving has modified. But I am not getting a Vout of more than 6-6.9V @2kHz. Vout starts to saturate at about 6V and @+1kHz.


Maybe someone can spot something I did on my schematic?

 

The LM2917 has a built-in 7.5V regulator, the LM2907 doesn't. If you have the 2917 the output doesn't go much above 6V.

 

The LM2917 has a built-in 7.5V regulator, the LM2907 doesn't. If you have the 2917 the output doesn't go much above 6V.

If you hadn't dropped this piece of knowledge, I could have cranked up the voltage Thank you.


You keep telling me to read the Datasheet over and over to get info, some info is starting to click in.

So I used the Vout=Vcc*f*C1*R1 formula, and set Vout=6V? Then Set an f of 2000Hz, C1=4.7nF, then calculated R1 to be 43K.

Results on LM2917 (14-pin) with a Vcc = 15V, C1=4.7nF, R1=(10K + 33K Trim), C2=1uF, C3=1uF,

@0Hz, Vout = 0V
@500Hz, Vout = 1.499V
@1000Hz, Vout = 3.004V
@1500Hz, Vout = 4.49V
@2000Hz, Vout = 5.94V

So as I approach the 2000 Hz mark, I do lose some linearity, but I can compensate for that in LabVIEW by setting a scale table.

The time constant is given by τ =R1*C1, I can adjust these values knowing well that C1 should be large than 500 pF for the charge pump.
------------------------------------

------------------------------------
And that the max frequency I can read is given by
------------------------------------

----------------------------------

I will keep experimenting with a few more values.

 

If you hadn't dropped this piece of knowledge, I could have cranked up the voltage Thank you.

It's probably 30 years since I last used it, so the tiny point about the zener had slipped my mind.

 

In post #17 you say that you will be using 2 pulses per revolution and in post #26 you say your maximum frequency will be 2Khz. So this means the shaft will be rotating 1000 times per second. This is 60000 RPM. From the picture of your mechanical arrangement in post #1 I don't think this will survive rotating at such a high speed. It would help if you gave more information on what you are trying to achieve. Also what is the minimum frequency you are trying to measure and how many reading do you need per second. This information will help to work out the filtering or averaging of reading at lower speeds.

Les.

 

The LM2917 has a built-in 7.5V regulator, the LM2907 doesn't. If you have the 2917 the output doesn't go much above 6V.

@Ian0 is right, although the output stage can do more, the charge pump output across R1 and the following opamp are limited to around 7v.

Either change to the LM2907, or recalibrate for 6v and change R1 /C1 to suit. With a 16bit DAC you won't lose significant resolution as you only need 11 or 12 bits for 0 - 2000Hz.

 

although the output stage can do more

The output stage seems to be nothing more that an emitter follower. All it seems to achieve is to avoid loading the output current on the zener - it wouldn't appear to be able to exceed the zener voltage.
The output still seems to be limited to Vzener-2Vbe.

 

In post #17 you say that you will be using 2 pulses per revolution and in post #26 you say your maximum frequency will be 2Khz. So this means the shaft will be rotating 1000 times per second. This is 60000 RPM. From the picture of your mechanical arrangement in post #1 I don't think this will survive rotating at such a high speed. It would help if you gave more information on what you are trying to achieve. Also what is the minimum frequency you are trying to measure and how many reading do you need per second. This information will help to work out the filtering or averaging of reading at lower speeds.

Les.

You are correct @LesJones, I have been swaying all over the place with my values. let me try to clarify them now.

I can vary the pulse per revolution of my shaft by changing the number of teeth coupled to it. My Teeth can be set to 24 or 2. Let's say they are at 24, which will generate 24 pulses per revolution. At 2000 Hz speed sensor reading, that will be 2000/24=83.33 Revolutions per Second, which will be 83.33*60=5000 RPM. 5000 RPM is over and above my applications of about 3000 RPM, but I would like to be able to capture runaways, over speeds, etc.

I am accounting for higher teeth which directly translates to higher sensor frequency reading - more resolution at lower speeds.

As far as the minimum speed I would like to read, I would say about 120 Hz at the low end, which is about 300 RPM

 

@Ian0 is right, although the output stage can do more, the charge pump output across R1 and the following opamp are limited to around 7v.

Either change to the LM2907, or recalibrate for 6v and change R1 /C1 to suit. With a 16bit DAC you won't lose significant resolution as you only need 11 or 12 bits for 0 - 2000Hz.

I have opted to stick with the LM2917-14pin for now, and just recalibrated my C1 and R1 in order to give 6V at 2kHz - I don't mind a Vout of 6V instead of 10V.

 

hi,
@Irving
This is a copy of the LM2907/2917, it may help.
E

 

View attachment 271126

Any ideas on how I can arrange all of these components into a perf-board? I thought it would be a walk in the park but I can see that there are a lot of things I need to be mindful of.

 

Data from a Hall sensor is already digital. Personally, I would choose to measure the frequency directly and then send it LabVIEW digitally via whatever means is most appropriate.

 

I might have found something already built and ready A frequency to Voltage converter (F/V) with good range.

But that gives an analog voltage out which you would then need to read with an A/D converter to determine the speed.
Converting from digital to analog and then back to digital is complex and not as accurate as directly reading the pulses.

Better to use a microprocessor or other circuit to determine the time interval digitally between pulses and calculate the RPM from that.
Here's a discussion of a basic interval counter circuit.

 

But that gives an analog voltage out which you would then need to read with an A/D converter to determine the speed.
Converting from digital to analog and then back to digital is complex and not as accurate as directly reading the pulses.

Better to use a microprocessor or other circuit to determine the time interval digitally between pulses and calculate the RPM from that.
Here's a discussion of a basic interval counter circuit.

I have played around with the digital I/O pins on the USB 6002 device. LabVIEW does support a lot of the functions I need such as pulse measurements, frequency, counters, pulse width measurement and many more. The issue is that my device only has one counter and no internal clock on the digital Inputs pin - meaning the digital I/O are not programmable, unfortunately (except for the one counter which can only count really) and it can quickly be seen on the device test when I connect it. The DIO stop picking up pulses at about 400 or so, tested this is so much desperation but it doesn't sample fast enough and cannot be set.

The Analog AI in LabVIEW is a lot more capable, with read rates and sampling settings of up to 50ks/s. I had a code and read the incoming pulse wave and performed the period calculations in order to get the RPM. it worked but the issue was that I would have to read at more than double the speed and about 100 samples (less at high speeds) just to keep up with the incoming signals (this rate would be fixed to all 8 Analog channels) - which meant that I lost a lot of functionality in my device (could not use the other ports for different readings, I only need 3 speed sensor readings, then pressure and others for the other ports) - I still had to display and write to a TDMS file (Labview's Binary file format, more space-efficient than excel) and a 1000 Hz rate.

This solution of leaving all the timing and translation of frequency to voltage, to an IC, means that I can reduce my read rate to 1000 Hz and 1 number of samples: which plots easily on a graph than the 100 number of samples and requires no further coding because LabVIEW allows for custom scales/gains and can calibrate the incoming voltage directly do an RPM externally, even set units and tittle headings for an Excel type tabular display - all before the device even runs. The incoming data are in a waveform data type, with a dt setting of 1 ms in my case - making it 1000 data points per second.

The only process I do in my while loop is just the continuous reading of the incoming data, indexing through the array of channels to display the readings, and writing them directly to a TDMS file.

This cheap solution of the IC results in a lot of savings because LabVIEW devices cost thousands and are a bit overkill. For a project of multiple sensor readings, this kind of creative innovation to achieve the same goal but with fewer resources is what really where people really earn their name and I am really great for everyone's input.

 

Whether you go analog or digital to read the RPM really depends upon the accuracy you need for the value.
Even with calibration, analog will likely be lower accuracy than digital.

 

Whether you go analog or digital to read the RPM really depends upon the accuracy you need for the value.
Even with calibration, analog will likely be lower accuracy than digital.

Indeed, Digital is just a lot more cleaner. I remember blinking a pin with an Ardunio to see how high a frequency the DAQ 6002 digital pin could pick up, it could not read higher than 400 Hz consistently and started flickering. I was really disappointed because an Arduino can produce a pulse within a few microseconds period, which I had to confirm with a multimeter.

 

I couldn't find models for the PCB 2 Terminal connectors onEasyEDA (I don't want to end up having them facing the wrong way)

I am a complete noob is schematics.