This didn't actually happen, but i built a "wireless" communication system in a fort. It sends messages between two partial forts which have no walking connection and thus also no shared mechanism links.
Information is sent via minecart, obviously. The exact information is transmitted by the minecarts' weights and decoded via pressure plates tuned to respond to the specific carts. As mentioned elsewhere, there are eleven distinguishable minecart weights. One cart is required for the "done" signal, so that leaves us with ten bits of space per message sent. Each individual bit in the message is represented by the presence or absence of the minecart in question, so sending the finisher cart alone actually sends 0000 0000 00. Sending carts one, two, five, seven and nine (and the finisher) sends 1100 1010 10.
Of course, to make the operation reasonable, a fair bit of auxiliary machinery was required. I wanted the message entered in one go and sent as a "package" instead of issuing each bit individually and wait for it to be sent before sending the next. This required a "dispatcher" to turn the lever-pulls at the main controls into a properly spaced sequence of launch signals.
Not very transparent, i'm afraid. Visibility doesn't exactly profit from it being built in the middle of a kimberlite vein and halfway over an older dysfunctional (too tightly spaced) design. Each lever opens one hatch cover (or not, if it is "off"). The dispatcher cart checks each ramp/hatch combination and if the hatch is closed, it bounces back out and is sent to the next without sending a launch signal. If the hatch is open, the cart passes through, activates the pressure plate sending the launch, bounces against a wall, back into the ramp-pit and out and to the next pit. This provides enough distance between the actual signalling carts so that they can eventually file back into their proper positions.
The signal carts sit each on their own individual hatch, which gets opened by the launch signal from the dispatcher. There's a bit of spacing provided because the carts that get started first in the sequence have the shortest distance to the main launch rail:
Quite simple, just a bunch of (SE) impulse ramps. The cart enters on the westernmost ramp, which is EW to guarantee a uniform starting speed. The ² things at the eastern end, where a proper ramp launches carts into the air, are the remains of a cat that got curious at the wrong time. Poor thing completely disintegrated.
The carts are sent off at somewhere in excess of two tiles per step, travel along a ballistic arch with an apex at z+17 (i have a picture of a cart in flight, but well, it's just a screenfull of empty space with a lone minecart) and lands about 90 tiles east of the ramp, here:
If you squint really hard, you can see the moat surrounding this sub-fort. Dwarfs cannot cross.
All pressure plates on the southern "incoming" path are weight-sensitive, ranging from 1-800kg for the first to 50-100 for the last. Each plate activates the door two tiles east of it, letting the cart pass, but if the cart is not the right weight, the cart follows the corner, touches the plate on the northward path, takes the next corner sending it west and eventually gets launched back out at the western end, two tiles northeast of the start of the incoming rail. This arrengement is why carts are sent from heaviest to lightest, with the bloodthorn cart as finisher - they can come in less than 100 steps apart, since each lighter cart is supposed to pass all doors passable by heavier carts anyway and thus, no false bits can be set.
In the picture, one cart is in the loop (the nickel one, judging by the plate it just went over) and the plate activated by an earlier cart (presumably lead) is still active - those carts were sent significantly less than 100 steps apart, and the launch for one cart between them was checked but wasn't required by the main controls.
After jumping back, the carts are pulled up two z-levels and sorted through this array of even more hatch-pits governed by weight-sensitive pressure plates:
Once again, the weight-ordering is used to ease the sorting process. Carts enter from the right and the heaviest carts leave on the left, so the plates/hatches are ordered by ascending weight. This was the part that needed the re-build of the dispatcher. I had an earlier design with closer-spaced launches, but that led to carts colliding here.
The plate activations at the reading end of the minecart jumps are first fed into a bunch of set/reset latches
and when the finisher (bloodthorn) cart touches its pressure plate, the main decoder/processor is activated:
Bottom left: a simple delayer - hatch cover/ramp loop holding a cart as long as the hatches are open, sending it over a pressure plate and back to the starting location after 100 steps are up. _This_ signal sends an open to all four floor grates to the middle-north, each holding back a minecart in a ramp-pit. These carts leave their pits after the grates open 100 steps later and pass over the track/bridges directly south of the grates. Two latches govern the positions of these bridges and which of the four carts gets to enter the main processing loop depends on the bridges' positions: there's a currently-retracted bridge immediately south of the grates. Currently, the second cart from the left gets to leave.
The operation cart then goes through eight latch-governed gates, sending signals to the main memory depending on cart weight and hatch positions. After finishing the cycle, the cart goes up to the above level, goes over another pair of bridges working like those below, sending the cart back to its origin pit and in the process sends an open signal to the bridge in the latch array, re-setting the latches.
One of eight cells of the main memory can be seen in the northeast. They're comically large, but can add, subtract, toggle or get set to a specific value.
The four minecarts in the operation loop are of four different weights (of course) and each hatch-gate has three pressure plates. Two are in the branch travelled when the hatch is open -
first plate responds to weights from 200-500, sends an "add" to its memory cell
second plate responds to weights from 400-max, sends a "subtract" to its memory cell
the other is in the branch travelled when the hatch is closed
responds to weights from 1-200, sends a "set to zero" to its memory cell.
Each of those main gates has an added hatch-pit cycle behind it. The hatch in it is triggered by the first and second pressure plates and if open, holds the cart back for 100 steps before it travels to the next gate. That's because carries can be generated in the main memory when adding or subtracting, the delay is supposed to prevent carries from failing to register.
The carts used are from wood (<50), copper (~350), silver (just over 400) and gold (770ish). So the operations are
copper - add
gold - subtract
silver - toggle status of every cell which has been selected, add without carry.
The wooden cart is first sent over a pressure plate which both sends a "set to one" to all memory cells _and_ holds the cart back for a hundred steps before it goes into the operation loop. Thus,
wood - set memory to transmitted bit chain. Sending the blood thorn cart alone sets the memory to zero.
Communication with this machine is one-way, to allow responses, a similarly large contraption would be required going the other way. One byte of information and a two-bit "opcode" take about 300 steps to get through the "dispatcher", each cart takes another ~200 steps to deliver its message, main operation starts another 200 steps after the bloodthorn minecart has come through and takes from 500 to 1500 steps depending on how many bits are set. About two dwarf-days to transmit and rudimentarily process one byte of information, ~3 to 5 mBit/s. It's gonna take a while before dwarfs start sending ballistic weight-encoded porn.
Author
Topic: Urist McMarconi cancels send wireless message: blown apart by *silver minecart* (Read 4403 times)