u/RoleMain7059

I made a very fast sculk wireless transmitter. The basic idea is to abuse comparator update detection. The comparator can detect the moment the signal starts traveling toward a calibrated sculk sensor, before the vibration actually reaches it.When the comparator detects that update, it immediately disables the inverted signal and allows the bell to activate. The bell then sends a vibration to the next calibrated sculk sensor. At the next sensor, we detect the signal starting to travel again and immediately trigger the next bell, repeating the process.

So instead of waiting for the vibration to fully reach the sculk sensor before transmitting again, each stage detects the signal as it starts traveling and prepares the next transmission almost instantly.This is still a very early version, and I think it can be made significantly faster with better timing and optimization.Right now, I can transmit across about 64 blocks in roughly a second or less.

The reason the sculk vibrations aren't that far behind the redstone signal is that each next sculk sensor is triggered earlier than it normally would be. The comparator update detector detects the signal as soon as it starts traveling toward the calibrated sculk sensor and immediately sends the next signal. However, this doesn't interfere with or stop the original signal that is already traveling toward the sculk sensor. So the original sculk signal continues traveling normally, while the next transmitter has already been activated. That's why the sculk vibrations stay relatively close to the redstone signal instead of falling further and further behind with each stage.

I spent the whole day reading Minecraft documentation about tile tick priorities and scheduled ticks, and watching tutorials on technical redstone, just to finally understand how all of this works and build this.

It took me way longer than I expected, but I finally started understanding how scheduled ticks, priorities, and update order interact.

I’m honestly pretty happy with the result.

I made a wireless binary 2-bit half-adder using calibrated sculk sensors and split the whole system into four separate modules, a transmitter, a receiver, a protocol/interpreter, and the half-adder

The transmitter only sends the signals and the receiver only receives them, neither of them needs to understand what the information means, the protocol is what interprets the received frequencies and converts them into two binary outputs that can be connected to anything, not just the half-adder

I use calibrated sculk frequency 10 as binary 1 because it corresponds to an activation, and frequency 9 as binary 0 because it corresponds to a deactivation

The protocol has two slots, the first slot can store either 1 or 0 and the second slot can also store either 1 or 0, when the first signal arrives the protocol checks whether it is frequency 10 or 9, interprets it as 1 or 0, locks the first slot and waits for the second signal, when the second signal arrives it does the same thing and locks the second slot

Once both slots contain their values, the two outputs are sent to the half-adder, meaning the protocol itself doesn't perform the calculation, it just turns the wireless transmission into two usable binary signals.There are also four reset buttons that let me independently unlock and clear the stored values of both slots, including resetting either frequency 9 or frequency 10 from either slot, so I can manually reset the protocol and send another pair of bits. The main reason I built it this way is that the wireless communication system is completely separate from the actual computation, so the two binary outputs from the protocol can be connected to basically anything else, meaning the same transmitter, receiver and protocol could later be used for other redstone logic instead of only this half-adder.

If both slots are filled, the protocol simply ignores additional signals because both slots are locked, so I can keep sending frequency 9 or 10 without changing the stored values until I press reset, this also means the same two stored bits can remain connected to whatever redstone system is using them..This is basically my first attempt at making an actual wireless binary communication system in Minecraf.

I’m a beginner at Redstone, and I’ve been experimenting with using sculk as a kind of wireless Redstone communication system.

The first version of my transmitter/receiver uses two channels:

Channel 10: detects block activation. This one was relatively easy to calibrate. A note block can activate the calibrated sculk sensor, which then lets me transmit the signal.

Channel 9: detects block deactivation. This one was much trickier.

For the deactivation channel, I made a setup where pressing another button activates a trapdoor first. Then a piston pulls away the wool that was covering the trapdoor. At that exact point, the trapdoor closes, producing the deactivation sound. The calibrated sculk sensor listening on channel 9 can then detect that sound and transmit the signal.

So, with these two channels, I can independently transmit two different signal states. That means I can essentially encode arbitrary binary information by deciding which channel to emit.

This is only a very early prototype. My next goal is to build an actual communication protocol for it, where the transmitted bits have meaning and determine what the receiver should do.

Basically, I’m trying to make wireless Redstone using sculk.

I’m still pretty new to Redstone, so any advice, optimization ideas, or suggestions for where I could take this would be appreciated.