I'm working on sending data through a serial analog wire with varying pulse duration, and needs something to convert it back to binary. I came up with this but not sure if there is a more simple way of doing it.
The design needs to be able to keep pulse duration, size doesn't matter too much. It's more speed that i want to improve, at the moment it takes 4 ticks. Also you need a minimum 3 tick signal, not too sure why it doesn't work with a 2 tick pulse :/
The usually-powered repeaters right before the unary/decimal-to-binary encoder don't seem necessary. You could alternate running wire from the tops and sides of the blocks before them.
The last usually-powered repeater looks like its on a different setting than the others?
EDIT: also try removing the 2-tick repeaters controlling the 8 and 12 and 14 lines. Their only purpose is to turn off (or, actually, on) those lines for higher values which isn't necessary, and removing them can help with some of the 0-tick off-pulses caused by switching which torch is powering a line (you might not be able to see them with lamps, but you can see them with pistons or doors/trapdoors). And, obviously, you don't need the 2-tick repeater for the 15 line either because it will never get powered (can't see if you had it or not).
With those changes (and adding piston repeaters to almost offset the rising/falling discrepancy of the lamps), I can run it on a 2-tick analog clock:
The usually-powered repeaters right before the unary/decimal-to-binary encoder don't seem necessary. You could alternate running wire from the tops and sides of the blocks before them.
The last usually-powered repeater looks like its on a different setting than the others?
EDIT: also try removing the 2-tick repeaters controlling the 8 and 12 and 14 lines. Their only purpose is to turn off (or, actually, on) those lines for higher values which isn't necessary, and removing them can help with some of the 0-tick off-pulses caused by switching which torch is powering a line (you might not be able to see them with lamps, but you can see them with pistons or doors/trapdoors). And, obviously, you don't need the 2-tick repeater for the 15 line either because it will never get powered (can't see if you had it or not).
With those changes (and adding piston repeaters to almost offset the rising/falling discrepancy of the lamps), I can run it on a 2-tick analog clock:
Ah that helps easy way to get it down to 3 ticks anyway Wouldn't changing the other repeaters effect the pulse duration of the output.
Also something weird with the one i made, it accepts a 2 tick pulse on the lowest and second lowest signal strength but it has to be 3+ ticks on the others. Any idea what was happening there?
oh yeah that last repeater on 2 ticks was a derp up
… Wouldn't changing the other repeaters effect the pulse duration of the output. …
I don't think so. They're not there for timing, they're there as part of a logic gate -- and for those particular logic gates, one input doesn't matter. For example, the logic gate controlling the a8 line is saying "(NOT signal strength a8+) OR (signal strength a9+)" (where the output of that logic gate being off means it's exactly a8, allowing the torch to turn on the b8 line). But we're happy if the torch it's controlling is allowed on for any a8+, so no logic gate is needed.
Also something weird with the one i made, it accepts a 2 tick pulse on the lowest and second lowest signal strength but it has to be 3+ ticks on the others. Any idea what was happening there? …
Huh. My 2-tick analog clock worked (2 ticks per signal strength), but a simple 2-tick pulse gets the same thing you describe.
Some oscilloscopes show that the dust in the analog decoder is getting the 2-tick pulse, but by the time it gets through the logic gate it's been shortened to 1-tick, which isn't long enough to turn on the torches in the unary encoder.
I'm not sure what's happening there. I suspect the torches in the analog decoder, but I'm not sure why.
It uses a 1-tick analog-to-unary decoder, loosely based on/inspired by :
The even unary lines go straight out, but I had to wrap the odd unary lines over top of the a2u decoder and they just barely made it across the u2b encoder output lines. I've stripped it down in the image above so you can sort of see what's going on. For example, the last torch on the near side is 14 dust from the input, while the last near repeater is 15 from the input -- when the signal strength is 14, the torch will turn off, allowing the u14 line to turn off, but when the signal strength is 15 the repeater will turn on, turning the u14 line back on.
I couldn't quite get his decoder to work with this (which was too bad because all the outputs were on the same side) because the even outputs did their OR in a block so you would have needed torches (like he had) or repeaters to power lines into the u2b encoder.
properinglish also has an he says is 2 ticks, but it could only be considered 2 ticks if you ignore the additional 2 ticks it takes to split the input to the upper and lower sections, which I don't think you can.
Because we're controlling a u2b encoder, we can let the even unary control lines be off for both their value and the next odd value (for example, the u2 control line can be off for both a2 or a3 input, because both should power the b2 output line). This allows us to get everything back on one side, still in 1 tick, and greatly simplifies the u2b encoding (the odd unary lines only need to control the b1 output line):
The light blue lines are the even unary control lines, and the (dark) blue lines (a single block each) are the odd unary control lines.
Looking at the u2 line (far right light blue line), the torch controlling it turns off when the input is 2, but the repeater below the torch doesn't turn on again until the input is 4. So the b2 output line will be powered by the u2 line for both a2 and a3 input, and we let the odd unary lines worry about the b1 output line.
Again we're using the "remove u8/u12/u14 repeater" trick to simplify the u2b encoding (which is why the encoding lines on the left look simpler than they should be).
Here's a close-up of the a2u decoder from the other side:
When i built this i was still having problems with a 2 tick input not working on some of the signal strengths. It was changing the 2 tick to 1 tick... Then when i isolated the single bit that wasn't working it then worked. Pretty sure it is the redstone torch update bug, where if you have 2 redstone torches going off next to each other, 1 of them can create a 1 tick pulse. This may have been fixed in the later versions i'm still only using 1.5 on my laptop. Does 2 ticks work for you?
I think this is the bug that's stopping it working, the back torch has a 2 tick pulse but the other only gives a 1 tick meaning the lamp doesn't go on.
… Pretty sure it is the redstone torch update bug, where if you have 2 redstone torches going off next to each other, 1 of them can create a 1 tick pulse. This may have been fixed in the later versions i'm still only using 1.5 on my laptop. Does 2 ticks work for you?
I'm having the same problems in 1.7.4 and the snapshots.
I had forgotten about that bug (MC-2340) -- that does sound like this problem, so that's probably it.
I press a button to send a 2-tick pulse in, and I'm looking at the torches, and I can actually see them turning off at different times, even though they're all on the same line of redstone dust. But a 3-tick pulse -- completely in sync. Bah.
I checked and it's not the comparator providing the input doing something weird. It still happens with no comparator.
My second build had the torches alternating which side they're on, and that doesn't help unfortunately. Same problem.
I'm having the same problems in 1.7.4 and the snapshots.
I had forgotten about that bug (MC-2340) -- that does sound like this problem, so that's probably it.
Urgh... Thought they fixed that, maybe it was something similar.
I'm pretty sure i've made a big mistake and my whole concept is broken anyway *sigh*. I was going to have differing pulse lengths from 2 ticks to 10 ticks with pulse length detectors, giving 8 x 4 bits. Problem is, this only gives 1 unique unary number out of 128 each second and doesn't multiply the bits. So 8 x 4 would just equal 7 bits per second.
Guess i'll just try for sending 4 bits per 2 or 3 ticks
Rollback Post to RevisionRollBack
Question you have on redstone? Feel free to pm me here, or on my Youtubeaccount.
Analog repeater wire is almost as fast as regular repeater wire (14 blocks per tick instead of 18 for block-repeater-block). As long as you plan ahead for the offsets and turns it needs to take.
Analog repeater wire is almost as fast as regular repeater wire (14 blocks per tick instead of 18 for block-repeater-block). As long as you plan ahead for the offsets and turns it needs to take.
Isn't that 16 blocks per 2 ticks...? You can get it to 17 having a block on one side, (you can't have a block on both sides though). Also it's more of a circuit that a single line of redstone. I think lag is just something we have to deal with when using analog logic sadly.
I'm tempted to try and make some instant wire that works with serial binary for long distance. Probably the bit rate would be horrible though.
Rollback Post to RevisionRollBack
Question you have on redstone? Feel free to pm me here, or on my Youtubeaccount.
If you want to encode all 16 possible signal strengths, it's 17 blocks per 2 ticks (8.5 blocks per tick) if you use a comparator and a block between each segment of analog repeater wire, but if you just overlap the segments by one block (the last output block of one segment is the first input block of the next segment) then it's 14 blocks per tick. When you overlap it that way you can't get it to go in a straight line (each segment will be offset to the side from the previous by 2 blocks) and you can only turn corners in certain directions, so you need to plan for it.
When you're encoding fewer than 16 signal strengths, you have more flexibility, as in Cubehamster's .
Ahh, what i get for not reading all of that section in the wiki. It says 14 ticks per block then the pic is of the comparator design.
I just found out a way to use comparators with 1 tick pulses and have been able to send 40 bits per second through a comparator line. Any ideas on how to convert that to binary? Doesn't really matter how big it is, just a pain working with redstone torches and single ticks.
40 bit per second signal (each tick has a different signal strength)
There are four primary methods of inverting signals -- torches, comparators, pistons, and locked repeaters -- and they all have problems with 1-tick pulses and off-pulses. Hmm.
Ahh, what i get for not reading all of that section in the wiki. It says 14 ticks per block then the pic is of the comparator design. …
The comparators are only there to indicate that the input and output are a signal strength, but maybe that's confusing with only a single segment shown.
EDIT: Aaaand, I just freaking figured out how to turn corners the other way. That's been bugging me for a long time.
And that also allows you to keep your arw inline without comparators, at 14 blocks per tick, at some cost in height:
Sorry, not what you're asking about, but I'm geeking out right now. : )
Oh awesome! Least that dramatically reduces the time lag between point A and point B
This sort of shows 1 tick per unique comparator outcome (the lamps on the last 2 are still on because lamps take a few ticks to turn off even though the redstone is off)
Rollback Post to RevisionRollBack
Question you have on redstone? Feel free to pm me here, or on my Youtubeaccount.
Say you feed your input into 4 segments of analog comparator wire (acw = comparator-block-dust-block-repeat). Off the side, after each comparator, maybe alternating which side for space, you have a 1-tick clocked gate feeding a 3-tick analog pulse extender -- either a segment of arw with the repeaters set to 3 ticks (bigger but faster), or multiple tracks of 1, 2, and 3 comparators* (smaller but slower, since you need extra comparators at the input and output). Every 4 ticks you pulse all the gates at the same time. This gives you a snapshot of 4 ticks worth of data, with each tick of data going into a separate 3-tick analog pulse extender after which it can easily be handled by its own a2b decoder. Now you demux the binary outputs into a single binary bus by first delaying each a different amount then pulse-limiting them to a single tick.
* EDIT: the multiple tracks method can be done without input and output comparators, so it's simply smaller than 3-tick arw.
Yeah that's sort of what i was thinking, either splitting it into 4 or 8 and then each having a separate decoder. Might convert it into either 32 bit parallel binary with a frequency of 800ms or 16 with a 400ms frequency, so that it can be handled more easily.
Analog pulse lengthener is a good idea, if i get it to 4 ticks i can convert straight into 16 bit parallel. Found a good way to make a 1 tick AND gate to retrieve all the signals. This might actually work
Rollback Post to RevisionRollBack
Question you have on redstone? Feel free to pm me here, or on my Youtubeaccount.
urgh... i can't seem to get this to work. Munin/anyone else any chance you could check it out, not sure if i'm doing something stupid or there is an update bug messing it up. Maybe i need to space out some of the components differently.
My first test works fine (using "1.5 tick" redstone torch AND gates), but when i connect it up to a clock with 1.5 tick comparator AND gates it only captures 3 of of the 4 signals.
Initial test, all signals show up
Using a 4 tick clock
Red = leading pulse to activate rsnor & activate 4 tick clock AND gate
Green = 1 to 4 tick analog pulse extender
White = 1st signal
Blue = 2nd
Yellow = 3rd
Black = 4th
Dark green = 2nd set
It seems to be the 1st signal that isn't getting registered.
The design needs to be able to keep pulse duration, size doesn't matter too much. It's more speed that i want to improve, at the moment it takes 4 ticks. Also you need a minimum 3 tick signal, not too sure why it doesn't work with a 2 tick pulse :/
Any ideas?
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
The last usually-powered repeater looks like its on a different setting than the others?
EDIT: also try removing the 2-tick repeaters controlling the 8 and 12 and 14 lines. Their only purpose is to turn off (or, actually, on) those lines for higher values which isn't necessary, and removing them can help with some of the 0-tick off-pulses caused by switching which torch is powering a line (you might not be able to see them with lamps, but you can see them with pistons or doors/trapdoors). And, obviously, you don't need the 2-tick repeater for the 15 line either because it will never get powered (can't see if you had it or not).
With those changes (and adding piston repeaters to almost offset the rising/falling discrepancy of the lamps), I can run it on a 2-tick analog clock:
Ah that helps easy way to get it down to 3 ticks anyway Wouldn't changing the other repeaters effect the pulse duration of the output.
Also something weird with the one i made, it accepts a 2 tick pulse on the lowest and second lowest signal strength but it has to be 3+ ticks on the others. Any idea what was happening there?
oh yeah that last repeater on 2 ticks was a derp up
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
I don't think so. They're not there for timing, they're there as part of a logic gate -- and for those particular logic gates, one input doesn't matter. For example, the logic gate controlling the a8 line is saying "(NOT signal strength a8+) OR (signal strength a9+)" (where the output of that logic gate being off means it's exactly a8, allowing the torch to turn on the b8 line). But we're happy if the torch it's controlling is allowed on for any a8+, so no logic gate is needed.
Huh. My 2-tick analog clock worked (2 ticks per signal strength), but a simple 2-tick pulse gets the same thing you describe.
Some oscilloscopes show that the dust in the analog decoder is getting the 2-tick pulse, but by the time it gets through the logic gate it's been shortened to 1-tick, which isn't long enough to turn on the torches in the unary encoder.
I'm not sure what's happening there. I suspect the torches in the analog decoder, but I'm not sure why.
It uses a 1-tick analog-to-unary decoder, loosely based on/inspired by :
The even unary lines go straight out, but I had to wrap the odd unary lines over top of the a2u decoder and they just barely made it across the u2b encoder output lines. I've stripped it down in the image above so you can sort of see what's going on. For example, the last torch on the near side is 14 dust from the input, while the last near repeater is 15 from the input -- when the signal strength is 14, the torch will turn off, allowing the u14 line to turn off, but when the signal strength is 15 the repeater will turn on, turning the u14 line back on.
I couldn't quite get his decoder to work with this (which was too bad because all the outputs were on the same side) because the even outputs did their OR in a block so you would have needed torches (like he had) or repeaters to power lines into the u2b encoder.
properinglish also has an he says is 2 ticks, but it could only be considered 2 ticks if you ignore the additional 2 ticks it takes to split the input to the upper and lower sections, which I don't think you can.
Because we're controlling a u2b encoder, we can let the even unary control lines be off for both their value and the next odd value (for example, the u2 control line can be off for both a2 or a3 input, because both should power the b2 output line). This allows us to get everything back on one side, still in 1 tick, and greatly simplifies the u2b encoding (the odd unary lines only need to control the b1 output line):
The light blue lines are the even unary control lines, and the (dark) blue lines (a single block each) are the odd unary control lines.
Looking at the u2 line (far right light blue line), the torch controlling it turns off when the input is 2, but the repeater below the torch doesn't turn on again until the input is 4. So the b2 output line will be powered by the u2 line for both a2 and a3 input, and we let the odd unary lines worry about the b1 output line.
Again we're using the "remove u8/u12/u14 repeater" trick to simplify the u2b encoding (which is why the encoding lines on the left look simpler than they should be).
Here's a close-up of the a2u decoder from the other side:
When i built this i was still having problems with a 2 tick input not working on some of the signal strengths. It was changing the 2 tick to 1 tick... Then when i isolated the single bit that wasn't working it then worked. Pretty sure it is the redstone torch update bug, where if you have 2 redstone torches going off next to each other, 1 of them can create a 1 tick pulse. This may have been fixed in the later versions i'm still only using 1.5 on my laptop. Does 2 ticks work for you?
I think this is the bug that's stopping it working, the back torch has a 2 tick pulse but the other only gives a 1 tick meaning the lamp doesn't go on.
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
I had forgotten about that bug (MC-2340) -- that does sound like this problem, so that's probably it.
I press a button to send a 2-tick pulse in, and I'm looking at the torches, and I can actually see them turning off at different times, even though they're all on the same line of redstone dust. But a 3-tick pulse -- completely in sync. Bah.
I checked and it's not the comparator providing the input doing something weird. It still happens with no comparator.
My second build had the torches alternating which side they're on, and that doesn't help unfortunately. Same problem.
Urgh... Thought they fixed that, maybe it was something similar.
I'm pretty sure i've made a big mistake and my whole concept is broken anyway *sigh*. I was going to have differing pulse lengths from 2 ticks to 10 ticks with pulse length detectors, giving 8 x 4 bits. Problem is, this only gives 1 unique unary number out of 128 each second and doesn't multiply the bits. So 8 x 4 would just equal 7 bits per second.
Guess i'll just try for sending 4 bits per 2 or 3 ticks
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
Isn't that 16 blocks per 2 ticks...? You can get it to 17 having a block on one side, (you can't have a block on both sides though). Also it's more of a circuit that a single line of redstone. I think lag is just something we have to deal with when using analog logic sadly.
I'm tempted to try and make some instant wire that works with serial binary for long distance. Probably the bit rate would be horrible though.
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
When you're encoding fewer than 16 signal strengths, you have more flexibility, as in Cubehamster's .
I just found out a way to use comparators with 1 tick pulses and have been able to send 40 bits per second through a comparator line. Any ideas on how to convert that to binary? Doesn't really matter how big it is, just a pain working with redstone torches and single ticks.
40 bit per second signal (each tick has a different signal strength)
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
The comparators are only there to indicate that the input and output are a signal strength, but maybe that's confusing with only a single segment shown.
EDIT: Aaaand, I just freaking figured out how to turn corners the other way. That's been bugging me for a long time.
And that also allows you to keep your arw inline without comparators, at 14 blocks per tick, at some cost in height:
Sorry, not what you're asking about, but I'm geeking out right now. : )
This sort of shows 1 tick per unique comparator outcome (the lamps on the last 2 are still on because lamps take a few ticks to turn off even though the redstone is off)
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
either a segment of arw with the repeaters set to 3 ticks (bigger but faster), ormultiple tracks of 1, 2, and 3 comparators*(smaller but slower, since you need extra comparators at the input and output). Every 4 ticks you pulse all the gates at the same time. This gives you a snapshot of 4 ticks worth of data, with each tick of data going into a separate 3-tick analog pulse extender after which it can easily be handled by its own a2b decoder. Now you demux the binary outputs into a single binary bus by first delaying each a different amount then pulse-limiting them to a single tick.* EDIT: the multiple tracks method can be done without input and output comparators, so it's simply smaller than 3-tick arw.
Analog pulse lengthener is a good idea, if i get it to 4 ticks i can convert straight into 16 bit parallel. Found a good way to make a 1 tick AND gate to retrieve all the signals. This might actually work
Question you have on redstone? Feel free to pm me here, or on my Youtube account.
My first test works fine (using "1.5 tick" redstone torch AND gates), but when i connect it up to a clock with 1.5 tick comparator AND gates it only captures 3 of of the 4 signals.
Initial test, all signals show up
Using a 4 tick clock
Red = leading pulse to activate rsnor & activate 4 tick clock AND gate
Green = 1 to 4 tick analog pulse extender
White = 1st signal
Blue = 2nd
Yellow = 3rd
Black = 4th
Dark green = 2nd set
It seems to be the 1st signal that isn't getting registered.
world download https://www.mediafire.com/?nwnn38b4v8n89fn
Question you have on redstone? Feel free to pm me here, or on my Youtube account.