Spikes on S0 line

[majowi5]

I have a lot of spikes on an S0 line. It is difficult to get rid of them. They would be easily detectable, as they are much shorter than a regular signal.
Vzlogger offers a debounce_delay but no option to define a minimum signal high time, to recognize a regular signal and
to dissmiss spikes easily.

I think this would be a very useful enhancement. Is there a chance to get this implemented?

[Tomcat42]

Why working in software around buggy hardware (the hardware between S0 and vzlogger)? Problem solving by Software has most of the time drawbacks. Shielding and termination may imrpove against spikes. This may only be seen as a recommendation. Have seen it a lot of times when people plan to „rescue“ the product by pushing functions on the software side. In german: „Fasse nichts in Software an, wenn es die Hardware kann“ Habe a Nice day! Von meinem iPhone gesendet

…

Am 08.11.2021 um 21:27 schrieb majowi5 ***@***.***>:  I have a lot of spikes on an S0 line. It is difficult to get rid of them. They would be easily detectable, as they are much shorter than a regular signal. Vzlogger offers a debounce_delay but no option to define a minimum signal high time, to recognize a regular signal and to dissmiss spikes easily. I think this would be a very useful enhancement. Is there a chance to get this implemented? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[majowi5]

@Tomcat42 : sorry, but this does not answer my question
I know your recomendation, but sometimes it is the other way round.
Have a nice evening.

[mbehr1]

Which frequency do you have? (how many signals per sec/min?) And what’s your intended „minimum signal high time“ you’d like to ignore? Matthias

…

Am 08.11.2021 um 21:27 schrieb majowi5 ***@***.***>: I have a lot of spikes on an S0 line. It is difficult to get rid of them. They would be easily detectable, as they are much shorter than a regular signal. Vzlogger offers a debounce_delay but no option to define a minimum signal high time, to recognize a regular signal and to dissmiss spikes easily. I think this would be a very useful enhancement. Is there a chance to get this implemented? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#503>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY3UC2RCTU75TRC3DMTBFDULAXDHANCNFSM5HTS2H5A>.

[majowi5]

signal must be at least for the minimum time defined high (or low) to change the state in vzlogger.
Example:
signal is active high, if the signal is high for a time shorter than the minimum time defined, the high signal is ignored. Same is valid for low; if the signal is low for a period shorter than the minimum time defined, the low signal is ignored.
Time range should be about 10 ms to 2000ms (I suppose I will need a value at about 200ms)

My frequency is far less than 1 Hz, about 1 signal per minute.

[brlnr23]

I had to deal recently with the same issue. A few signals were simply wrong, cause by interferences with whatsoever. My technical skills to fix the hardware are limited that much, that I tried to understand what exactly is going wrong by logging the signals with a small Python script. It turned out, that the issue @majowi5 described was exactly what I was suffering from. Signals < 10ms while regular signals are >100ms.

In general I would agree that "fixing the root cause" is way more preferred than putting a strip on it somewhere else, but in my case that would be simply inefficient.
In the end I fixed my issue by using a custom Python script instead of vzlogger which posts data to the middleware via curl.

A configuration option for the min and the max length of a "valid" signal would help me a lot.

[wrichter]

This is implemented in #525