Time-domain debounce multiple inputs?

elliottcable · Post by **elliottcable** » Tue Mar 24, 2026 6:31 pm

I spent a little time trying to come up with this myself, but everything I ended up with was just horribly complicated. I'm somehow convinced this should be easy with 2.0 combinators, but I can't quite piece it together.

Goals:

All signals in the input treated equally (ideally subject to some base condition like "<8", but can always throw an additional decider in front)
Any signal that appears/rises is subject to a N second delay before being passed to the output (as a boolean, value can be lost);
and any signal that passes that delay without flickering off stays on the output until it's disappeared from the input for N seconds (again, without flickering on), at which point it disappears from the output as well.

The actual goal would be to pass signals from all the "input" belts to this, for those inputs which are supposed to be fully-saturated belts; then if any input belt is having throughput drop, once throughput has been continuously spotty (continuously <8 items on the belt) for a while, throw on an alarm.

Tertius · Post by **Tertius** » Tue Mar 24, 2026 6:36 pm

So you want to check if a belt is fully compressed and throw an alarm if it isn't?
Is this belt carrying a single item (for example just iron plates) or does it contain a mix of items as found on a sushi belt?

If it is carrying a single item, you can do something like this:
- build a clock. This is a decider combinator counting from 0 to infinity. Use counter variable T.
- wire a belt piece to an input of the combinator. Set the belt piece to read items (hold mode).
- as reset condition in the counter, set :anything: >= 8
- place a programmable speaker and connect it to the output of the combinator. Set the activation condition of the speaker to T > timeout where timeout is the number of ticks you allow the belt being uncompressed and not yet throw an alarm.

mmmPI · Post by **mmmPI** » Wed Mar 25, 2026 4:36 am

Tertius wrote: Tue Mar 24, 2026 6:36 pm If it is carrying a single item, you can do something like this:
- build a clock. This is a decider combinator counting from 0 to infinity. Use counter variable T.
- wire a belt piece to an input of the combinator. Set the belt piece to read items (hold mode).
- as reset condition in the counter, set :anything: >= 8
- place a programmable speaker and connect it to the output of the combinator. Set the activation condition of the speaker to T > timeout where timeout is the number of ticks you allow the belt being uncompressed and not yet throw an alarm.

I got stuck in the instructions, don't you need a constant too to set-up a clock ? and doesn't that risk resetting when T reaches 8 ?

elliottcable wrote: Tue Mar 24, 2026 6:31 pm The actual goal would be to pass signals from all the "input" belts to this, for those inputs which are supposed to be fully-saturated belts; then if any input belt is having throughput drop, once throughput has been continuously spotty (continuously <8 items on the belt) for a while, throw on an alarm.

I have something that may serve the purpose but it's based on a modified train counter so the logic doesn't come with tick precise timer. Instead it works calculating a moving average throughput from a belt ( or a train lane ) and you can ring an alarm when it drops under a threshold. The attached blueprint is setup to show the throughput with 1 decimal place, so for a yellow compressed belt with stone, it should flickers between 149 and 150 on the right most combinator output, but if the belt is half compressed, it will converge toward 75 overtime. The red belt shows 299 or 300 and the blue one 449 or 450. You can set the alarm to ring when the average drops under any arbitrary threshold, the closer to the max throughput the more reactive the alarm.

: average thruput.jpg (78.89 KiB) Viewed 944 times

It's an old one and a difficult one so i'm not too sure about the math, Ai told me it is called linear recurence, if you add 6000 every tick to a counter x , and you also divide this counter x by 6000 every tick, it will converge toward 36 000 000, that's the max negative number that can be shown in the counter composed of the 2 combinators one above the other. And that would correspond to detecting something every tick so the throughput would be 60 per second , but the number displayed with 1 decimal would be 600 ( that's the division by 60 000 in the right most arithmetic 36 000 000/60 000= 600) .
Conveniently, if you only add 6000 to the counter only 1 every 10 ticks, 10%, the convergence will be toward 3 600 000, it's linear ! which correspond to detecting something 10% of the time, so only 6 out of the 60 ticks in a second, or having a throughput of 6 per second.

Such addtions are done by the left most arithmetic combinator, it multiply the pulse received from the belt by 6000, or really -6000, this is done to optimize combinators, the counter is stored as a negative sign, and divided by /-6000 every tick, the result is positive and fed back into the counter with a wire.

I understood the general use case as less detecting gaps in belts and more detecting shortages of materials, so maybe this approach works ? It need a bit of time to show the proper value, but then it's a "quite reactive" moving average of all the item passing through the belts, possibly "can" wok on sushi, if you sum up all the signals i suppose you could detect if that represent full belts or any bits missings but i haven't tested it for that.

Tertius · Post by **Tertius** » Wed Mar 25, 2026 10:01 am

elliottcable wrote: Tue Mar 24, 2026 6:31 pm The actual goal would be to pass signals from all the "input" belts to this, for those inputs which are supposed to be fully-saturated belts; then if any input belt is having throughput drop, once throughput has been continuously spotty (continuously <8 items on the belt) for a while, throw on an alarm.

Having read this part again, I wonder how one would use the information "belt throughput is spotty". Information is nice, but what would you do with it, if you find out one belt isn't fully compressed? Is the information useful if you learn there is a gap just once in a while but not more often?

In the past, I built a super simple compressed belt detector for the design process. It was to determine if the design is able to output a fully compressed belt. Later, in production, this information wasn't needed any more.
The compressed belt detector for this purpose was a quite simple one, and it was totally sufficient.

I built a lamp that activated if :anything: <> 8. This lamp will flash if the belt is not fully compressed. This is very visible and exactly the information I needed during design.

I also built a row of 8 lamps, where lamp #n with n=0..7 activates if :everything: > n. For an fully compressed belt, all 8 lamps are lit up. For an almost compressed belt, the last lamps in the row will flash, and according to how many items are missing, more lamps will flash as well so you immediately see how bad the gaps in the belt are.

The :everything: wildcard will make the lamps also light up if there are no items, however this way you're able to merge the signals of multiple belts and merge their signalling. You know some belt isn't compressed but not which one.

out4.mp4: (9.74 MiB) Downloaded 16 times

mmmPI · Post by **mmmPI** » Wed Mar 25, 2026 2:30 pm

Tertius wrote: Wed Mar 25, 2026 10:01 am Having read this part again, I wonder how one would use the information "belt throughput is spotty". Information is nice, but what would you do with it, if you find out one belt isn't fully compressed? Is the information useful if you learn there is a gap just once in a while but not more often?

It depend on the belts , if you have something like this in your bus , it tells you if / which ressource isn't supplied in enough quantity anymore when you are in another planet. It spares the regular check-up to know if you need to add outposts.

You can also use the rolling average thing to check wether or not the coal demand risk exceeding current belt. If the average reaches the max capacity of the belt, it means all the coal is consumed, you can put an alarm to let you know you need to upgrade or add another belt.

mmmPI · Post by **mmmPI** » Thu Mar 26, 2026 6:51 pm

Apparently it was useful x) since you can find the parameterised version there : viewtopic.php?p=690657 but really it comes from here : viewtopic.php?t=29679 ^^

Here is the version that serve for train counter : viewtopic.php?p=598581

Nidan · Post by **Nidan** » Mon Mar 30, 2026 9:32 pm

I happened to need a timer based on signals not changing for my own save; only the single signal version though. A vectorized version of it turned out to be much less annoying than I initially expected (only one extra combinator). From there, all that's left to fulfill the goals as stated in the OP is to tack on a latch and take care of propagation delay differences.

Factorio Forums

Time-domain debounce multiple inputs?

Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?

Re: Time-domain debounce multiple inputs?