278 posts
Posted 01 January 2014 - 02:16 AM
I've run a search on "corruption" and "static" and found no topic titles that directly spoke about this, so here goes…
I think that adding destructive effects to wireless rednet transmissions would provide an interesting challenge for those writing communications programs and such. (I'm thinking of file transfer programs)
The effects could vary based on the amount of interference, the distance between the sender and receivers, environmental effects, and so on.
This could also provide some kind of alternative for the "hard" limit for rednet transmission distance; instead of messages simply not being received past the range limit, messages could grow more and more corrupted as the distance grows before reaching the point where the orignal message cannot be recovered.
For example, with a rednet distance limit of 128 blocks on a clear day, rednet messages could be effected along these lines (barring noise effects):
In my mind, interference effects would manifest the same way, but the amount of corruption would depend on the total "activity" on the channel and "nearby" channels in the past few seconds or so.
For example, programs that transmit huge "bursts" of data all around the same time (like my routing protocol) would get heavily corrupted even if they were relatively close together. The effects of channel noise shouldn't be limited to one channel, as well: Transmissions on one channel should effect "adjacent" channels too. (e.g transmissions on channel 5 increase the "background noise" level of channel 1).
Interference effects could work as follows:
Each channel could have a counter indicating how much interference is present, as a probability of any one character in each message being corrupted, similar to how distance effects.
This counter should range from 0 to 1.
When a message is transmitted, the counter could be incremented like so:
Interference should also "seep" into adjacent channels; when a message is transmitted on channel n:
However, the counter could be decreased by one-half every tick, finally resetting to zero once it gets below 1%.
As an example: let's examine the interference caused by 4 computers using the GPS program, with one computer (or Turtle) attempting to triangulate its position and the other three providing fixes.
For simplicity's sake, let's assume that the hosts have three-digit X, Y, and Z coordinates.
The position fixes would be transmitted as such: "{[1]=XXX, [2]=YYY, [3]=ZZZ}", with a message length of 26.
This would increase the "interference counter" by 3% for each host / fix.
Taking the initial ping message into account as well as the other two messages into account, each position request would increase the interference counter by 10%, which would fade after 4 ticks, or 0.2 seconds.
This would only increase as more hosts are added.
Five turtles attempting to determine their position at once would increase the corruption rate to 50%, before distance effects.
This type of corruption could be avoided by spreading out GPS requests, like so:
The interference definitely needs some fine-tuning, but the basic idea should remain.
This would give us a use for error-correcting and error-detecting codes, at least. As I said above, it also gives us an interesting challenge to work around.
And for those who just want a sandbox to play with, this could easily be turned into a configuration option.
I think that adding destructive effects to wireless rednet transmissions would provide an interesting challenge for those writing communications programs and such. (I'm thinking of file transfer programs)
The effects could vary based on the amount of interference, the distance between the sender and receivers, environmental effects, and so on.
This could also provide some kind of alternative for the "hard" limit for rednet transmission distance; instead of messages simply not being received past the range limit, messages could grow more and more corrupted as the distance grows before reaching the point where the orignal message cannot be recovered.
For example, with a rednet distance limit of 128 blocks on a clear day, rednet messages could be effected along these lines (barring noise effects):
- 0 - 64 blocks: No effects. Messages are always received clearly in the absence of channel noise.
- 65 - 96 blocks: Minor effects. Messages receive a minor amount of distance-related corruption. (1 character out of ten, which should be configurable)
- 97 - 128 blocks: Moderate effects. Messages receive more corruption due to distance. (3 or 4 characters out of ten, or to taste)
- 129 - 161 blocks: Severe effects. Messages receive even more corruption due to distance. (6 to 8 characters out of ten, or to taste)
- 162 - 226 blocks: Messages are simply received as pure garbage.
- 227+ blocks: Messages are not received.
In my mind, interference effects would manifest the same way, but the amount of corruption would depend on the total "activity" on the channel and "nearby" channels in the past few seconds or so.
For example, programs that transmit huge "bursts" of data all around the same time (like my routing protocol) would get heavily corrupted even if they were relatively close together. The effects of channel noise shouldn't be limited to one channel, as well: Transmissions on one channel should effect "adjacent" channels too. (e.g transmissions on channel 5 increase the "background noise" level of channel 1).
Interference effects could work as follows:
Each channel could have a counter indicating how much interference is present, as a probability of any one character in each message being corrupted, similar to how distance effects.
This counter should range from 0 to 1.
When a message is transmitted, the counter could be incremented like so:
(.01 + ( floor(#message / 10) / 100 ) )
Interference should also "seep" into adjacent channels; when a message is transmitted on channel n:
- 50% of its "interference level" should be added to the two channels directly adjacent to it. (i.e channels n+1 and n-1)
- 40% should then be added to channels n+2 and n-2.
- And so on, with appropriately decreasing levels of interference being added, with 10% being added to channels n+5 and n-5, and none being added for any channels past that.
However, the counter could be decreased by one-half every tick, finally resetting to zero once it gets below 1%.
As an example: let's examine the interference caused by 4 computers using the GPS program, with one computer (or Turtle) attempting to triangulate its position and the other three providing fixes.
For simplicity's sake, let's assume that the hosts have three-digit X, Y, and Z coordinates.
The position fixes would be transmitted as such: "{[1]=XXX, [2]=YYY, [3]=ZZZ}", with a message length of 26.
This would increase the "interference counter" by 3% for each host / fix.
Taking the initial ping message into account as well as the other two messages into account, each position request would increase the interference counter by 10%, which would fade after 4 ticks, or 0.2 seconds.
This would only increase as more hosts are added.
Five turtles attempting to determine their position at once would increase the corruption rate to 50%, before distance effects.
This type of corruption could be avoided by spreading out GPS requests, like so:
local gps_delay = 4
local delay_timer = -1
local GPS_CHANNEL = 65534
local modem = peripheral.wrap(MODEM_SIDE)
function GPS_Delay_Coroutine()
delay_timer = os.startTimer(0.05)
while true do
local event, side, sCh, rCh, msg, dist = os.pullEvent()
if ((event == "modem_message") and (sCh == GPS_CHANNEL)) then
gps_delay = gps_delay+4
elseif ((event == "timer") and (side == delay_timer)) and (gps_delay > 0) then
gps_delay = gps_delay -1
end
end
end
function get_gps_position(timeout, debug)
while true do
os.sleep(0.05)
if gps_delay <= 0 then
return gps.locate( timeout, debug )
end
end
end
function main_loop()
-- ...stuff...
local pos = get_gps_position()
-- ... more stuff ..
end
parallel.waitForAll(GPS_Delay_Coroutine, main_loop)
The interference definitely needs some fine-tuning, but the basic idea should remain.
This would give us a use for error-correcting and error-detecting codes, at least. As I said above, it also gives us an interesting challenge to work around.
And for those who just want a sandbox to play with, this could easily be turned into a configuration option.
Edited on 02 January 2014 - 02:16 PM
