Frequency input timeout

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Frequency input timeout

Postby ECOELEC » Tue Jul 09, 2019 12:05 pm

Hello,
In my opinion, the DL1 and DL2 suffer both from a frequency measurement bad design.
Normally, when measuring frequency with a time delay between pulses, if the time between two pulses is greater than a timeout (user defined), the frequency should be assumed equal zero.
Actually, there seems theses counters doesn't have this timeout (or I couldn't find it) and their measured frequency never return to zero.
It's quite annoying.
Regards

racetec
Site Admin
Posts: 326
Joined: Thu Oct 27, 2005 12:02 pm

Re: Frequency input timeout

Postby racetec » Wed Jul 10, 2019 12:19 pm

Where are you looking at the data from the data loggers? This timeout is more a function of the display than the data logger, as the data logger is designed to record and count the pulses. There is no method for it to log not having a pulse. As such, any timeout would need to be incorporated in to the relevant viewing software or display.

Martin

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Re: Frequency input timeout

Postby ECOELEC » Sun Jul 14, 2019 11:04 pm

Hello Martin,
I don't agree with you.
As the DL1 log the frequency, the frequency must be the frequency. Using a timeout for frequency measurement is always mandatory in its computation. If the DL1 doesn't receive any pulse after the user defined timeout, the frequency must be considered as null. All frequency meter work as this.

If this problem can be avoided (but no solved) in the Dash4 with the general variable timeout, it let the logged frequency unusable in analysis (there is no way to correct it in analysis) especially when you have fast change of the measured frequency (wich remain always far from its real zero).
JM

racetec
Site Admin
Posts: 326
Joined: Thu Oct 27, 2005 12:02 pm

Re: Frequency input timeout

Postby racetec » Mon Jul 15, 2019 9:05 am

The DL1 doesn't log the frequency. It logs a counter value each time that a pulse arrives. Whatever is looking at the data from the DL1 then looks at the time interval between the pulses and calculates the frequency. If there is no pulse, at what point should the DL1 say that there is a non-existant pulse?
If it did log and store frequency then it would be possible to log it as a zero frequency, but it doesn't. That is why it is left up to whatever is processing the data to do the timeout function if required.

Martin

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Re: Frequency input timeout

Postby ECOELEC » Mon Jul 15, 2019 11:53 am

Hello Martin,

I still disagree, the DL1 log and transmit 4 variables named "frequency" (channel 14-17) and also pulse (channel 86-89) and they are completely different because it's impossible to compute frequency from pulses outside the DL.
Measuring the time between two pulse is a way to compute a frequency (if pulse frequency is relatively low) and it can only be done in the DL.
To prevent bad low frequency computations, if no pulse is received after a pre-defined time out, the DL1 algorithm must consider, broadcast and log the frequency as zero. This "time out" is usually a user variable.
It's impossible to correct these bad frequencies using the logged data. The only RT allow is to considering any remaining constant incoming data in the Dash as not valid (but not zero) but it's a bad way because we can't use this option when we have stationary measures (as many of them) and let the logged frequency wrong.

Regarding this forum, many RT users suffer a lot from this real problem and it's quite easy to correct in the DL firmware. Frequencies are usually used to measure speed and rpm (with suited sensors) and they are always wrong at real 0 RPM and 0 MPH (or km/h).
In my case, my electrical motor (with hall sensor) stop in less than 0.1s. My logged RPM remain constantly at more than 2kRPM!
I can't do nothing with DL logged frequencies and as I really need them for analysing, I had to measure them correctly with an external micro-controller and send them to the DL with RS232 and RT coding for log.

Regards

JM

racetec
Site Admin
Posts: 326
Joined: Thu Oct 27, 2005 12:02 pm

Re: Frequency input timeout

Postby racetec » Mon Jul 15, 2019 12:11 pm

I am not sure what you are disagreeing about. The spec for the frequency input messages is here:

https://www.race-technology.com/wiki/in ... encyInputs

As you will see, it is stored as a time period between successive pulses in multiples of 1/6 us. 3 byte counter, maximum pulse period of 2.8s

The DL1 can not log the frequency as zero because it does not log frequency. It logs time between pulses. It could log a time between pulses after a certain timeout, but that would not be correct as there had not been any pulses. It has no way to log not having a pulse.

Martin

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Re: Frequency input timeout

Postby ECOELEC » Mon Jul 15, 2019 4:39 pm

The problem is that the DL1-2 wait till the next pulse to log and transmit whenever it's overflowed.

You you solve easily the frequency (and RPM) problem as I so it in my microcontroller:
- On the DL1-2, when the 24 bit counter is overflowed, FF FF FF should be log and transmitted on message 14..17 (without waiting the next pulse).
- On the decoder (Dash and Analysis), you only have to interpret FF FF FF as null frequency (actually, I have to do it manually in a user variable).

This ensure a natural timeout of 2,7962s which correspond to a frequency lower than 0.3576Hz (the lowest that can measure the DL).
A better way is to define a user limit of the counter (lower than FF FF FF) which cause FF FF FF as result (but the lowest measurable frequency will raise).

These modifications will not affect those who don't have the corrected firmware and decoding algorithm.
They will only see 0.3576Hz after 2,7962s instead of hazardous values.

JM

racetec
Site Admin
Posts: 326
Joined: Thu Oct 27, 2005 12:02 pm

Re: Frequency input timeout

Postby racetec » Tue Jul 16, 2019 6:35 am

I agree that if it was being handled in the data logger then that would be a reasonable way to do it.

Martin

ECOELEC
Posts: 49
Joined: Sat Nov 29, 2008 10:33 pm
Location: Brussel
Contact:

Re: Frequency input timeout

Postby ECOELEC » Tue Jul 16, 2019 10:38 am

Another way is simply to send and log the frequency (with a time out) and not the time between successive pulses.
As the time between successive pulses has no use except for decoding frequency, it should not be a problem.
JM

racetec
Site Admin
Posts: 326
Joined: Thu Oct 27, 2005 12:02 pm

Re: Frequency input timeout

Postby racetec » Tue Jul 16, 2019 1:13 pm

Except when you are using a low power processor and have four frequency inputs coming in at up to 2khz, it is much quicker and easier to log the time between pulses then to convert to a frequency. Do the processing on the PC end where it has more time and power available to do it.

Martin


Return to “General software support”

Who is online

Users browsing this forum: Google [Bot] and 10 guests