Konchog Posted April 26, 2020 Share Posted April 26, 2020 The delay gate seems to be acting differently than I imagined. Maybe it changed in the last update? So, in the enclosed drone (see picture), the three circuits all have an impulse pause of 3 seconds, and the gate has a delay of 1 second. From the top down, the impulses last for 0.9s, 1.0s, and 1.1s respectively. Before you run the drone, ask yourself which LEDs are going to be lit, and at what time offset from zero are they going to be lit, and for how long? I would have thought, bearing in mind it's a delay gate - that we would see all 3 LEDs lit, all at the 4th second, with the each LED being lit for 0.9s, 1.0s, and 1.1s respectively. Seems reasonable, for a delay gate. But that is not what happens. In fact, only the bottommost LED is lit, and it is lit for 0.1 second. So - it appears that an 'off' value sent to the delay gate while it is processing the delay just clears the gate's internal delay buffer. filter component.drn It seems that any change to the input cancels the buffer, which means it's some sort of short frequency filter. Maybe that is your intent - but I think that calling it a delay gate is a bit weird.. There's a real thing called the "gate delay" (or propagation delay) - which is the length of time which starts when the input to a logic gate becomes stable and valid to change, and ends at the time that the output of that logic gate is stable and valid to change. The only way I can see to get the the behaviour I expected efficiently is by adding a driver - a buffer gate, which has the timing set to be equal to the delay gate. (see the following drone for the blinkenlights). While this works, it does mean that the forward timing (of the delay gate) must be repeated in the buffer gate, which doesn't seem to be correct. I am quite willing to be told that I am ignorant and out of my depth here! delay driven with buffer gate.drn Link to comment Share on other sites More sharing options...
ababaBABABABABBA Posted April 26, 2020 Share Posted April 26, 2020 (edited) 7 hours ago, Konchog said: The delay gate seems to be acting differently than I imagined. Maybe it changed in the last update? So, in the enclosed drone (see picture), the three circuits all have an impulse pause of 3 seconds, and the gate has a delay of 1 second. From the top down, the impulses last for 0.9s, 1.0s, and 1.1s respectively. Before you run the drone, ask yourself which LEDs are going to be lit, and at what time offset from zero are they going to be lit, and for how long? I would have thought, bearing in mind it's a delay gate - that we would see all 3 LEDs lit, all at the 4th second, with the each LED being lit for 0.9s, 1.0s, and 1.1s respectively. Seems reasonable, for a delay gate. But that is not what happens. In fact, only the bottommost LED is lit, and it is lit for 0.1 second. So - it appears that an 'off' value sent to the delay gate while it is processing the delay just clears the gate's internal delay buffer. filter component.drn 23.54 kB · 0 downloads It seems that any change to the input cancels the buffer, which means it's some sort of short frequency filter. Maybe that is your intent - but I think that calling it a delay gate is a bit weird.. There's a real thing called the "gate delay" (or propagation delay) - which is the length of time which starts when the input to a logic gate becomes stable and valid to change, and ends at the time that the output of that logic gate is stable and valid to change. The only way I can see to get the the behaviour I expected efficiently is by adding a driver - a buffer gate, which has the timing set to be equal to the delay gate. (see the following drone for the blinkenlights). While this works, it does mean that the forward timing (of the delay gate) must be repeated in the buffer gate, which doesn't seem to be correct. I am quite willing to be told that I am ignorant and out of my depth here! delay driven with buffer gate.drn 53.02 kB · 0 downloads i thought about this too before the impulse is activating the output for .9s but what i don't know is if the delay gate takes that as a single tick input regardless of the duration it's held --- or if it takes it as a bunch of inputs, basically infinite since its being held, and then just registers the last tick when the input active held duration ends for the delay gate to activate all the leds, the impulse giver activation time has to be greater than the delay gate time [ 1s ] since the top two were .9 and 1.00 they didn't register and only the bottom 1.1 did for the delay gate holding the led on the delay gate doesn't have a held output so it should be one tick but the input isn't one tick its technically infinite ticks but if it worked by registering the held tick inputs as infinite and then doing the output for each tick of the input which would make it register as infinite then maybe the delay gate would output each tick, or have infinite ticks for the duration of the input that went into it instead of infinity the game could just immediately activate another tick if it's 'held' so there isn't a gap, its not technically infinite seamless but it would simulate no gaps and then the delay gate would output each tick that went into it idk if the game can recognize infinity, if the smallest possible time it can do is in fact one tick this would mean that if impulse held output --> .9 | delay gate --> activates the first tick after the set delay time and then continues activating the rest of the ticks comprised in the .9 input for .9 seconds so in the example there was a 1 second delay time that would mean that the led will light 1s after the very first tick from the impulse held output and it should light up for .9s first tick == ' first and ending ticks == | [3s]---------------->['] <no gap> [starts delay gate 1s]--------->|------------------------------------->[.9s]---------------------------------------------->| (impulse wait) ^ ^ ^ (activation stops when delay gate uses all ticks) ^> |-------------->[.9s]--------------->| ^ > > > > > > > > ^ ^ (impulse held time output ^ (delay gate keeps getting ticks) ^ immediately? fills with ticks) ^ ^ ^ ^ > > > > > > ^ (delay gate takes 1st tick) i think the way it works now is that it if the input is still not being pressed after the delay finishes it won't activate so a more accurate name would be a trap gate (may or maynot exist in real life) probably needs a description like Waits for the input key to be activated for a set time, then activates output key. tell me if there is something wrong also check this out the battery full output is not going to the delay gate input but it is lighting the battery full led it's not starting below full so should at least put out one tick of battery full but it must be doing that because the led is lighting but then why isn't it going to the delay gate input battery full output.drn Edited April 26, 2020 by ababaBABABABABBA Link to comment Share on other sites More sharing options...
Konchog Posted April 26, 2020 Author Share Posted April 26, 2020 Well, with the battery full output, the delay gate time is less than than the battery expiry time. If you change the battery delay gate to 10 seconds, then the turquoise LED never lights - it's just the same as the other stuff. I do not think you need to be concerned about infinity, either.. Well - so my expectation was that the "Delay Gate" is what is called a "digital delay line" (There are analog delay lines too - which is normally fixed to a specific offset). So, we know the the game uses ticks, (which are normally called 'samples' in digital electronics), and the maximum number of seconds the "Delay Gate" is set to is 10, so you only need 10 * the number of ticks / second for storage; not infinity. The normal programming structure for a digital delay line is some form of FIFO queue. Normally you only update the pointer to an array, which acts both as the value to output, and then the place to put the next input. An empty three tick DDL, with inputs (at each tick) of 10100 will output 000101 000=>100 // Tick 1: output 0, input 1. ^ // Ptr at 0 100=>100 // Tick 2: output 0, input 0. ^ // Ptr at 1 100=>101 // Tick 3: output 0, input 1. (the pointer loops back to zero) ^ // Ptr at 2 101=>001 // Tick 4: output 1, input 0. (the input 1 has been delayed 3 ticks!) ^ // Ptr at 0 001=>001 // Tick 5: output 0, input 0. (the input 0 has been delayed 3 ticks!) ^ // Ptr at 1 001=>000 // Tick 6: output 1, input 0. (the input 1 has been delayed 3 ticks!) ^ // Ptr at 2 Now, because the Devs at stray fawn did NOT implement the delay gate this way, I'm trying to work out just why they did it the way they did. So, it's clear from experimentation that the Delay Gate will only activate if the input happens to coincide with it's own timing loop. Therefore, by tying an Impulse Giver with a active/pause of 0.1/1.2 (1.3 seconds total), to a Delay Gate with a delay of 0.7 seconds, the delay gate may never fire, even though. It also turns out that my earlier solution fails, because the buffer just blanks out any input changes, which isn't so hot. So, I then thought to actually build a proper delay line using If Gates for the FIFO queue elements. (see attached). lossy.drn I added a space key sampler (once the buffer is filled, press the space key to see if there are any 0 being propagated), and it's clear that the logic gates are very lossy indeed, which really sucks and is completely unnecessary: It looks like the rise times or fall times are not correctly coded, so the zeros are washed out of the signal. Damn. So I may be wrong, but it seems there is no feasible way of writing a simple digital delay line that is not lossy. Oh - is this a deliberate thing to stop storing variables? I don't think so - because it's reasonably straightforward to construct addressed memory out of the existing logic gates. It's a pain - but it's made much easier with the on-off switches... So.. what is going on?! Link to comment Share on other sites More sharing options...
Konchog Posted April 27, 2020 Author Share Posted April 27, 2020 3 hours ago, ababaBABABABABBA said: i think the way it works now is that it if the input is still not being pressed after the delay finishes it won't activate so a more accurate name would be a trap gate (may or maynot exist in real life) probably needs a description like Waits for the input key to be activated for a set time, then activates output key. Yeah - sort of... This is what I have now - Delay Gate has just the Time variable, which is on a loop. At the last tick of each loop, it checks the input. If there is a value there, it sends an output. Otherwise it does nothing. That means you can have lots of stuff being sent to delay gate, and you only need a single tick of nothing for the delay never to send anything, if it's synchronised. Quote ............* (check the last tick on the timer) 1111111111110 (inputs on every tick but the last) ==> Never lights up. So, why is that useful? I have no idea! Link to comment Share on other sites More sharing options...
Konchog Posted April 27, 2020 Author Share Posted April 27, 2020 Attached is a pretty close model of the existing delay gate using a tuned trigger impulse with an and gate. dg-woes.drn Link to comment Share on other sites More sharing options...
Konchog Posted April 27, 2020 Author Share Posted April 27, 2020 So, thanks to Micha, and more analysis, I worked out the delay gate! Yay! The following shows a set of timings with various inputs. The driver drone is also here! Delay Gate Examples.drn Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now