So I had a problem. I wanted to be able to broadcast a set of circuit signals representing a list of required items for a given outpost. The problem was that the radio only supports green and red channels leading to N>3 outputs intermixing signals.
Solution: Use a repeating clock that sends a signal only if Z
={{my_chosen_channel_num}}. There’s some odd stuff going on combinator wise to keep signal values in memory while the Z
timer is on a different channel. Also requires a single clock radio blueprint in order to keep receivers and transmitters in-sync with one another.
This is my first time fiddling with circuits more advanced than if X > Y inserter_enabled
so if you find a way to make this better LMK
In computing this sort of a problem would generally be solved by tagging via packet metadata - wouldn’t it be simpler to reserve a portion of the signal for a recipient address for signal decoding?
That would be way easier. I’m a dumb.
I am a dev in my professional life - the number of times I’ve used that reply to feedback is innumerable (I literally used it on Wednesday in reply to a proposed solution to mitigating replication lag).
Realizing you did a dumb thing is part of the game of life. Now you’ve finished building one awesome system and can probably refactor it to an even awesomer system!
Woo! Same! I’m working on a bit packing solution ATM. Should be more UPS friendly and more resource friendly :D
I think I was leaning into the clock method as it doesn’t have an upper/lower limit to circuit values or number of distinct circuits. Actually as I’m typing this I realized concurrent signals would have to share a 32 bit address space greatly limiting the min/max values. Two channels already limits me to 2^16-1 assuming I want a signed value.
I mean TDMA is also a perfectly valid solution.
Just needs an easier way to synchronize clocks. Maybe one (master) station could send out a sync word that lets all other stations start their clocks.
The easy solution to clock sync was to only have one clock. There’s some funkiness required to TX a signal during the TX’s clock cycle due to combinator timing but, I used that to my advantage on the RX side as it now only requires a single frame delay combinator to keep the signal alive 100% of the time.
This reminds me of what elderaxe blueprint does. Not on radar but like wires
I have that blueprint book but, never actually looked at the core module. If I woulda been able to reverse engineer what the heck is going on there it mighta saved me some headache. Hindsight is a bear
A quick and dirty kind of way is to take the signal you wanna send, run it into the radar, but also run it into a decider combinator set to a number variable.
Like if I wanted to send 30 copper plates to station 4, I send it to a decider combinator that’s always true, and has 2 outputs, one that outputs any, so the copper plate signal will pass through, and a second output for the number_4 signal, so number_4 and copper plates have the same value.
Then at station 4, I compare every signal to number_4, and if they’re equal, I pass them through.
This has a flaw. Notably, requests with the same value. 30 iron plates to station 3 and 30 copper to station 4 will give each station iron and copper signals.
There’s ways to encode a signal that avoid those problems, but this is a very simple one that’ll still pull the right output all the time if you work around that limitation.
My intent here was to be able to send requests to a set of requester chests supplied stations with a list of items needed for construction, resupply, and maybe personal long distance logistics. Although I found I can’t really arbitrarily send a train to a station via circuit signal without having all receiver stations except one be disabled.