Single tick circuits

[ColonelSandersLite]

So I'm pretty I know the answer to this and I'm pretty sure the answer is "no" but I thought I would ask anyways.

Let's say you want to turn a signal from a data source into a single tick pulse. Let's say it's for a counter. Easy enough.

Now what if you want to do the same, where multiple sources can send inputs of the same signal?

The typical arrangement works fine except in the edge case where one data source sends data on exactly the tick after the other data source. Then it breaks.

Is it possible to avoid this without splitting the data into different signals or using a different pulse generator for each data input?


I guess I *can* think of a way to do some kind of rotating polling system but that would risk dropping inputs without careful handling and would certainly take a lot more combinators than just using two pulse generators.

[Nosferatu]

In general: If you do something like that you need to convert the signal to pulse as close to the source as possible otherwise you lose information.

Maybe there are tricks that can be used, but that very much depends on what is the source and what is the data used for.

[mmmPI]

I think there are different fun ways to explore to manage different signals from different sources and prevent their contamination.

You named 3, splitting the data accross different signals and using multiples wires so that they do not sum up are 2 non-desirable solutions for you.

The 3rd one i think is what is refered to as multiplexor from people who learned it in electronic fields ( the rotating polling system ). You time the inputs so that they never occur at the same time and receiver only listen during specific synchronized time interval.

Another way of doing depending on the size of the data, is to use the whole 32 bits of information available in 1 number. A simpler descriptive example that wouldn't involve binary form would be if you have to send numbers only from 0 to 10, and potentially 3 source at the same time, you can make it so that the first source send data from 0 to 10, the second source from 100 to 1000, the third from 10 000 to 100 0000 . If the result is 50 409, this means the numbers sent from the 3 different sources are 5, 4 and 9. You get access to wider range and easier operation for the same application when using the binary form of the number and bitwise operation on combinators but it requires some time investment to understand ( at least i did x) ).

A combinaison of all those or some of those is possible to create a system to handle datas.

The last 2 involve multiples combinators ,but the "rotating polling system" (multiplexor) if you make it barebone is not requiring that many combinators, a simple clock counting to 1000 and a decider combinator allowing everything in case ( C= x ) can be paired with other decider as receiver, that only allows value when ( C= x+1) . The first decider will need 1 tick to ouput everything, and when C=x+1 the content need to be read by the other decider combinator.

It quickly get more complex if you need to store those data, i understood Nosferatu's comment as x+1 is easier than if you had 12 or 15 combinators in between the emiter and receiver as it would require listening at x+13 or x+16 and it gets tricky to keep in mind the delay in signal propagation that would occur and keep things synchronized. ( distance is not in meter )

[robot256]

Maybe this is covered by mmmPi's suggestions. When you have three pulse generators outputting to the same wire, you don't actually lose information when pulses coincide: you get a single tick of value 2 or 3 because the pulse add together. If you use more than a simple ">=1" decider to read it, you can get the total number of pulses.

You accumulate pulsed count in a memory cell, so you get a running integration of pulse heights. To convert this to a spaced-out train of value=1 pulses, add a free-running timer that triggers an output pulse and sends a pulse of -1 to the integrator on a certain tick, if the integrator is greater than zero.

[ColonelSandersLite]

When you have three pulse generators outputting to the same wire, you don't actually lose information when pulses coincide

You misunderstand the problem. The issue here isn't the output side losing data but the input side losing data.

splitting the data accross different signals and using multiples wires so that they do not sum up

This is a fine point but it's actually the crux of the issue. It's not sums that are the problem. Those work fine, at least as long as we're talking about all positive or all negative inputs. The problem is that, without differentiating the inputs somehow, the pulse generator can't tell when input A decrements and input B increments simultaneously (or vise versa). It just thinks it's a single continuous input. Splitting the data on red/green wires doesn't actually solve that. You would end up just having two pulse generators, one for red and one for green. Also doesn't help if there's more than two input sources.


Yeah, multiplex is the word there. It doesn't take much to do it for a basic system to do certain things, sure. If you need to be 100% certain that you don't drop any inputs between polling though, things can get more bulky. It's going to require memory at the input end and logic for managing that memory. In the end, a pulse generator is just either 2 or 3 combinators and doesn't really require any configuration.


I'm not wholly against the idea of doing some data manipulation like that in a lot of cases, but it happens to be inappropriate here for a few reasons. As you might have guessed, this general line of thinking has to do with my Following Trains on Single Track Lines project. In this application, a rail line may have any number of entrances and any number of exits. Such data manipulation requires logic to handle it at both ends. Now, for my own exclusive purposes, I could just manually handle that without any real trouble. However, I want to tool this up to be something the average joe can put together with just a few blueprints. I think that expecting Mr. A. Joe to be able to correctly wire up and configure those combinators would unreasonable. I also just can't account for every possible thing that Mr. A. Joe would want to do.


Ideally, I didn't want to have any combinators outside of the central control computer at all. I reckon though that if I have to have them, they need to be as simple and clean as I can possibly manage. Something that can be stamped down with, ideally, no configuration required whatsoever. And where configuration is required, it should be nothing more than a single constant combinator to control the system as a whole.

[robot256]

If the question is how do you tell the difference between a single source outputting a constant 1, versus if one source on the same wire switches to 0 at the same tick that another source switches to 1, your original hypothesis is correct, they are completely indistinguishable. If you need more information than the number of sources that are ON at the moment, regardless of which ones they are, you do need a separate pair of edge detectors on each source to separate positive and negative edges.

[ColonelSandersLite]

Yeah, mostly was just hoping that someone had some interesting black magic up their sleeve.

Probably for the best though. I try and avoid the dark arts where I can.


Edit - Err... No disrespect to the sorcerers out there.

[Tertius]

Vanishing of signal pulses due to the signal not changing often enough is a classic problem of the signal theory. My computer science study is long ago, but as far as I remember, the classic solution to this is a scrambler. The scrambler is used to add entropy, so for classic wire transmission there are enough low->high and high->low transitions to keep the clock in sync.

However, our issue is slightly different. May be you can develop a circuit that if it receives a 1, it looks ahead 1 tick, and if the next tick contains a 1 as well, it transmits a 2 and a 0 instead of 1 and 1. You cannot actually look ahead of course, so you can delay one signal by 1. So for every group of 2 ticks, save the 1st tick (has 0 or 1) and send a 0, then send the next tick (0 or 1) plus the saved tick (it's then 0+0=0 or 0+1=1 or 1+0=1 or 1+1=2). So you always send 0, then the sum of the previous and the current tick.

This also works if multiple senders send simultaneously, so you might first get a 2, then a 1. This becomes 0, then 3.

This is only feasible of course if you can live with a delay of 1 for every other pulse and you're fine with values > 1.

Or you might need to keep the amount of single pulses, i. e. you may really want 4 distinct pulses, even if 4 senders send their 1 simultaneously and you get a single 4. In this case, you need to stretch the signal to distinct pulses. Create a device that in the first step sums all input into an internal accumulator, then send pairs of (1,0) in 2 ticks and decrease the accumulator by 1 as long as accumulator>0 (otherwise send pairs of (0,0) in these 2 ticks). This of course only works if in the long run there are not more 1 than 0. Otherwise the accumulator increases and increases.

I don't want to spoil the fun, so I leave such circuits as exercise for the audience

[ColonelSandersLite]

That's very interesting thinking. I think maybe I see a way to make it work too, but I'm not so sure because it's late and I'm tired.

Gotta chew on that one a bit.

[mmmPI]

I don't want to spoil the fun, so I leave such circuits as exercise for the audience

Thank you mister sorcerer x) It would not be less fun to try and understand a design, you don't have to restrain your magic !

However, our issue is slightly different. May be you can develop a circuit that if it receives a 1, it looks ahead 1 tick, and if the next tick contains a 1 as well, it transmits a 2 and a 0 instead of 1 and 1. You cannot actually look ahead of course, so you can delay one signal by 1. So for every group of 2 ticks, save the 1st tick (has 0 or 1) and send a 0, then send the next tick (0 or 1) plus the saved tick (it's then 0+0=0 or 0+1=1 or 1+0=1 or 1+1=2). So you always send 0, then the sum of the previous and the current tick.

This sounds similar in principle to error-correction-code, sending information and extra bits describing the information itself to allow the receiver to make sure it's properly transmitted as a form of redundancy. That sound difficult to implement as it requires a "smart" emiter, rather than a centralized brain with all the logic. Still the concept with signal is interesting and new for me and i may not realize all implication/possibilities

Or you might need to keep the amount of single pulses, i. e. you may really want 4 distinct pulses, even if 4 senders send their 1 simultaneously and you get a single 4. In this case, you need to stretch the signal to distinct pulses. Create a device that in the first step sums all input into an internal accumulator, then send pairs of (1,0) in 2 ticks and decrease the accumulator by 1 as long as accumulator>0 (otherwise send pairs of (0,0) in these 2 ticks). This of course only works if in the long run there are not more 1 than 0. Otherwise the accumulator increases and increases.

You accumulate pulsed count in a memory cell, so you get a running integration of pulse heights. To convert this to a spaced-out train of value=1 pulses, add a free-running timer that triggers an output pulse and sends a pulse of -1 to the integrator on a certain tick, if the integrator is greater than zero.

To me those two suggestions are describing the same logic, similar to a buffer zone for pulse to be released later on with correct interval.

As i understand it, potentially, during 10 minutes of heavy traffic it would accumulate delay between the input and ouput. The amount of pulse "stored" in the "internal accumulator"/"memory cell" should not be allowed to increase indefinitly if i understood the use case correctly as it could cascade off to a noticeable time delay for the memory to empty itself.

The system requested from my understanding is designed to handle pulse representing trains present on a rail track

I'm not wholly against the idea of doing some data manipulation like that in a lot of cases, but it happens to be inappropriate here for a few reasons. As you might have guessed, this general line of thinking has to do with my Following Trains on Single Track Lines project. In this application, a rail line may have any number of entrances and any number of exits. Such data manipulation requires logic to handle it at both ends

But i'm not sure i understood the purpose of the circuit as it could either be used only to deal with the extremly unfrequent cases of 2 train entering a place the same tick, which would not occur repeatdly every tick and accumulate a lot. Or be used to generate pulse everytime any train crosses any signal to monitor their number in a certain branch ( using the system to store pulse whenever a train crosses a specific signal and the risk of mis-identification of which particular signal vs whenever 2 or more trains crosses a different signal simultaneously and risk of losing the information that it was 2 pulse and not just 1 ) ( or both )

This seem however easier (in relative term) to implement, as it would not require "smart" emiter, and would allow for a centralized brain with that memoy in the receiver location.