I am going to go way out on a limb here and guess that the "Transmitter for RPM Measurement" actually produces pulses in the range of 0.0005 Hz to 50 kHz.
With a 250 Ω resistor in the 4 mA to 20 mA current loop, a 4 mA state would produce 1 V and a 20 mA state would produce 5 V. Thus the signal is a series of pulses with low levels of 1 V and high levels of 5 V. The question then becomes: how will the OP process this (basically) digital signal and do something useful with it?
The usual method (because of the extremely wide frequency range) is to simply measure the period between successive pulses, typically by gating a counter, driven by a precision clock oscillator time-base, with the edges of the pulse train. It is important to capture the period of the pulse train, not just the period of the high states or the low states. That means the counter gate would be triggered ON with a rising (or falling) edge of the pulse train and then triggered OFF with the next rising (or falling) edge of the pulse train. The count in the counter would then represent the period between successive rising (or falling) edges of the pulse train. The reciprocal of the period measurement would then be proportional to the RPM.
If a continuous read-out is required, then two counters could be used in alternation. However, if the counter is implemented with a microcontroller, it is possible to start and stop the counter with pulses from the RPM transmitter, read the counter, and then reset the counter between "oscillator clock" pulses. This would allow a "continuous" read-out of the RPM, but limited in update speed by how long the interval is between the pulses from the RPM transmitter... 2000 seconds or about 33 minutes for 0.0005 Hz pulses. Also, the counter "clock oscillator" would have to operate at a significantly higher frequency than the fastest RPM transmitter frequency of 50 kHz to avoid losing resolution at the fastest RPMs.
A clock oscillator frequency of 1 MHz would probably be feasible with a fast microprocessor and efficient coding. If not, then two discrete IC counters can be used, with some latency in obtaining "real time" RPM data while each counter is gated on and off, its count read into memory, and the counter reset. Note that the "length" of the counter must be long enough to accommodate the number of counts accumulated during the period of the slowest RPM or else the counter will overflow and provide an inaccurate measurement of the period.