Wider notch time window

[womanderful]

Hi,

Documentation at https://www.savvycan.com/docs/sniffer.html talks about a timespan of 200 ms during which the bits that have flipped are remembered, and become uncoloured by a click on the "Notch" button. It then talks about clicking the button repeatedly to add new bits to the set.

I find myself kind of playing whack-a-mole to notch that one last bit that keeps flipping every few seconds :). I think that making the timespan longer would make sense to establish the baseline of an idling car. When saying "longer" I mean a lot, like, 10 seconds?

OTOH that one last bit doesn't really bother me a lot and I doubt it would bother anyone.

Thoughts anyone? Is it worthwhile to have this implemented?

[collin80]

To tell you the truth, the only reason it's set to 200ms is that I read that the "cansniffer" program in linux uses that interval. And, the sniffer window in SavvyCAN is based upon the way that program works. So, why 200ms? I have no idea. It does seem like a rather short interval. So, I think it would be worthwhile to add support for changing it. However, I'm seeing in code that lots of things are tied to that 200ms interval and I think some of them should still operate that quickly. So, I'll have to do some work to let the notch time expand while still keeping the actual screen updates at the 200ms interval (or, perhaps even allow that interval to change too).

[mitchdetailed]

i personally use cansniffer arguments '-h 5 -l 5', so i feel this will be a personal preference case.

…

On Sun, Sep 19, 2021, 6:52 PM Collin Kidder ***@***.***> wrote: To tell you the truth, the only reason it's set to 200ms is that I read that the "cansniffer" program in linux uses that interval. And, the sniffer window in SavvyCAN is based upon the way that program works. So, why 200ms? I have no idea. It does seem like a rather short interval. So, I think it would be worthwhile to add support for changing it. However, I'm seeing in code that lots of things are tied to that 200ms interval and I think some of them should still operate that quickly. So, I'll have to do some work to let the notch time expand while still keeping the actual screen updates at the 200ms interval (or, perhaps even allow that interval to change too). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#416 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI62NLUHX64IQYLH4HBVOXDUCZZVLANCNFSM5EEJROUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[collin80]

It does seem like I should add support for setting all three times you can set in cansniffer. Apparently the hold time in that program is really 1 second but it got set to 200ms like the loop time when making the sniffer window here. I always did think that was too short of a timespan. I just click the notch button like crazy. But, that seems really silly.

[collin80]

This should be working as of a2366d9. But, notching still works the same where I just chop time into slices. That is, if the notch time is 1000 milliseconds then time is sliced into one second increments and if a signal happens at the end of the slice and you are too slow and it progresses to the next slice you will still miss it. But, it now also flashes a bar under the notch interval. This flash is timed to the notch slices so it can help you to synchronize what you do with the notch slices.

[womanderful]

Good stuff, thank you!

I tried to PR an update for the doc but security stuff got in the way ("password authentication was removed"). I uploaded a base64'd diff to https://pastebin.com/raw/RCjRbJ0x in case anyone wants to apply it.