Jump to content

Automation compression and decompression system


Recommended Posts

1 minute ago, pether said:

I believe if you used separate sensors for each of the big gates the output would be one big mess if they fell out of sync, right?

If the timings were the exact same then they could, in theory, be separated. Doing this is easier said than done though.

Link to comment
Share on other sites

So in fact you need to run 3 wires - one with compressed data and two other to make 100% it will be decompressed correctly. So you could send 8 bits using single ribbon (2 bits for the clocks and two other for compressed 8-bit data).

I like the idea, thought about the same but didn't have time to play with it :)

Link to comment
Share on other sites

So the thing on the left rotates through the four inputs spending one tick sending the value of each input over the single wire, and the thing on the right rotates through latching the value on the wire into each of one of the four outputs until it cycles around again?

Link to comment
Share on other sites

  • Developer
10 hours ago, Gurgel said:

I don't really know what the folks at Klei were thinking here, but there is not enough functionality available to do reliable time division multiplexing.  

What are the scenarios/features that you're picturing, and what functionality would enable them?

Link to comment
Share on other sites

54 minutes ago, Ipsquiggle said:

What are the scenarios/features that you're picturing, and what functionality would enable them?

I'm thinking the problem is that you need a synchronous clock between the multiplexer and demultiplexer so effectively you now need two normal wires to carry 4 signals.  Plus the cost of the (de)mux and the injectors to turn the 4 separate signals back into a combined one, the loss of response time and jitter to response time that it creates, and the space required for all of that stuff is going to make this pretty useless.

Link to comment
Share on other sites

I believe the (de)multiplexers were not introduced to compress signals - for this one can use 4-bit ribbons that are more compact and easier to use. Sure, you can play with it like this, but I don't think its a main purpose of them

Link to comment
Share on other sites

3 hours ago, Ipsquiggle said:

What are the scenarios/features that you're picturing, and what functionality would enable them?

I don't think ONI actually needs TDM. The 4-lane automation wires should be enough to get several signals over longer distances. Putting TDM on top of that is probably overkill as it basically serves the same function. I also do not really see a use-case for the muxer/demixer besides implementing small lookup-tables, although the graphics makes clear what is going on beautifully.

Anyways, actually doing TDM that works reliably requires some sort of in-band synchronization and precise timing and that is really several orders too complex for what ONI automation can do. You would have to pack it into a sender/receiver endpoint component, but that is basically what the 4-lane logic wires already offer.

I do think you are now pretty close to the upper end of what gate-level logic can do. The next step would probably be some MCU component, were you had, say, several 4 lane logic I/Os and could put in some, say, LUA code that was executed in a loop each tick. That is a whole different level of complexity though, both in implementation and in use.  

Now, don't let me get you down! I think the new content is pretty nice overall. I especially like the counter and the "pulse generator" is a very useful addition too, making things a lot easier.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...