Перейти к публикации
Форум - ComputerCraft
Quant

Передача данных по рэдстоуну

Рекомендованные сообщения

В изолированных силы сигнала нет.

 

А если обычный? Из красного сплава, неизолированный.

Не знаю, чего там Иммибис кушает на обед перед моддингом, но в P:R и в оригинальном RP макс. сила сигнала из любых проводов красных равна 255. Подозреваю, что и в RL та же крипотня.

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Передача информации по редстоуну вряд ли найдет практическое применение. Поэтому поднятую тему считаю интересной только с точки зрения изучения работы реальных последовательных протоколов передачи данных. Ни один из реальных известных мне цифровых протоколов не использует силу сигнала как способ передачи информации. Только наличие/отсутствие. Посему предлагаю автору темы реализовать протокол UART как используемый в известных интерфейсах RS-232 и RS-485. Если это кому то кажется абракадаброй, готов помочь чем смогу.

 

Моё мнение может отличаться от мнения других участников форума.

  • Like 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все упирается в лаги, в реальном мире скорость сигнала приближается к скорости света, поэтому можно использовать размещение битов по времени, даже без коррекции ошибок, на огромных скоростях.

А в майне у одного 200 печек работает, другой летает в гравике с бешеной скоростью, у другого чанки после захода грузятся - сервер лагнул раз, подвис два - провод пропустил пачку сигналов и все пропало.

Где-то видел, как в RedPower делали передачу данных по редстоуну, там долго боролись с двумя проводами (скорость около 1 Мб за 10 минут), потом забили и стали юзать бесцветный кабель.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никто не говорит о высоких скоростях. Лучшее на что я рассчитываю - 1 бит/сек. Но для понимания работы этого достаточно. Можно даже осциллограф сделать, что бы смотреть циклограмму.

  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Передача информации по редстоуну вряд ли найдет практическое применение. Поэтому поднятую тему считаю интересной только с точки зрения изучения работы реальных последовательных протоколов передачи данных. Ни один из реальных известных мне цифровых протоколов не использует силу сигнала как способ передачи информации. Только наличие/отсутствие. Посему предлагаю автору темы реализовать протокол UART как используемый в известных интерфейсах RS-232 и RS-485. Если это кому то кажется абракадаброй, готов помочь чем смогу.

 

Моё мнение может отличаться от мнения других участников форума.

Есть стационарные крафтовые роботы, так почему бы не сэкономить на ресурсах?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никто не говорит о высоких скоростях. Лучшее на что я рассчитываю - 1 бит/сек. Но для понимания работы этого достаточно. Можно даже осциллограф сделать, что бы смотреть циклограмму.

Реализовать UART - отличная задача. Осциллограф, показывающий сигналы на входах - вообще крутотень. А для тактования, думаю, можно взять computer.uptime(). Возможно удастся добиться скорости передачи 1 бит/2 тика.

Нужно прикинуть суммарную погрешность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Alex,не повезёт же тебе...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какая интересная и живая тема, а у меня как раз инета не было. Попробую ответить сразу на все соображения по решению этой задачи.

  • В каких единицах измеряется скорость?

-скорость где-то в 11 раз больше(1000 за 42сек.)

1000 чего?
  • Алгоритм кодирования очень странный: передатчик разделяет число на слагаемые, а приемник суммирует. О какой производительности тут можно говорить? Тут уже предлагали разделить число на пятнадцатеричные разряды, такой подход значительно сократит длину передачи.
  • Скорость можно дополнительно увеличить в два раза, избавившись от бессмысленной передачи нуля. Зачем передавать ноль, когда можно передать полезную информацию?
  • Использовать два и более сигнальных провода — тупиковый путь. При таком подходе проводов всегда будет мало. Использование дополнительных проводов оправдано только в случае полного использования пропускной способности одного.
  • Рассказ про шину на компараторах тут интересен только в контексте двоичного кодирования, но в данном случае более оптимальным будет использование пятнадцатеричного.
  • Код Грея вообще не приносит пользы в решении этой задачи, он полезен только в реальном мире и только для двоичных кодов.
  • Кстати, не следует идеализировать реальный мир. В майнкрафте есть лаги, зато в реальном мире к лагам добавляются шумы и потери сигнала. И без коррекции ошибок там никак не обходится кроме простейших случаев.
  • Предложение реализовать UART мне нравится, но не следует делать утверждений о том, что все способы цифровой передачи сводятся к отсутствию или наличию сигнала. Для понимания этого достаточно ознакомиться со способами кодирования сигнала в модемах. Не погружаясь в детали, скажу, что сигнал имеет несколько состояний, и их количество значительно больше двух. Не принимать их во внимание — значит неэффективно использовать особенности среды передачи данных
Резюмирую. Передача по связке кабелей банальна, UART тоже скучноват, передача данных по одному редстоун-каналу с его 16-ю состояниями выглядит весьма интереной, и в текущем решении потенциал редстоуна совсем не раскрыт. А его раскрытие мне кажется увлекательным. Конечно, для начала и UART сойдет. Но 16 уровней сигнала против двух — это совсем другие возможности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какая интересная и живая тема, а у меня как раз инета не было. Попробую ответить сразу на все соображения по решению этой задачи.

...

Резюмирую. Передача по связке кабелей банальна, UART тоже скучноват, передача данных по одному редстоун-каналу с его 16-ю состояниями выглядит весьма интереной, и в текущем решении потенциал редстоуна совсем не раскрыт. А его раскрытие мне кажется увлекательным. Конечно, для начала и UART сойдет. Но 16 уровней сигнала против двух — это совсем другие возможности.

Несколько замечаний.

 

Насколько мне известно, то редстоун сигнал затухает с расстоянием. Т.е. 16 уровней сигнала, но с каждым блоком количество уровней будет сокращаться. Нужна процедура начального согласования, для определения длины линии и, соответственно, количества возможных уровней сигнала. В этом случае можно кодировать посылку не в двоичной а в N-ричной системе счисления, где N - количество уровней сигнала при данной длине линии. 

 

Реализация подобия UART нужна в любом случае, поскольку это N-ричное число нужно по какому-то протоколу передавать, да и процедура согласования опять же.

 

Если правильно решить тактование, то при таком подходе, информационная емкость канала сильно возрастает достигнув теоретического максимума.

 

Дополнительно можно мультиплексировать канал, тогда по одному проводу мы сможем передавать информацию одновременно туда и обратно. Но тут сложнее. РедСтоун участок - дискретен, и встречные волны скорее всего не пройдут. Нужно более детальное изучение поведения рс-цепи. Скорее всего, возможно только мультиплексирование по времени с падением пропускной способности в 4 раза. В этом случае, введение информационных фреймов внутри протокола, позволит нивелировать этот недостаток и использовать канал по максимуму.

 

По поводу лагов. Неравномерность течения времени в игре наблюдается относительно реального времени. Думаю, что если поставить в майне два компьютера, и одновременно запустить, то не смотря на лаги, расхождения в таймерах данных компьютеров наблюдаться не будут. Т.е. внутри мира майнкрафт лагов нет. Но эта гипотеза требует проверки. 

--=--

Тема действительно интересная и объемная. Передача сигналов по одному (не учитывая землю) проводу - основа основ любой электроники.

Изменено пользователем swg2you

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь прога работает ещё быстрее - числа в 14 цифр из девяток(99999999999999) передаются 14*9*2 тиков - это 13 с половиной секунд!

Мир лагал,но это число передалось за минуту.

Изменено пользователем Quant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь прога работает ещё быстрее - числа в 14 цифр из девяток(99999999999999) передаются 14*9*2 тиков

Хороший результат, ты близок к успеху, но есть возможность передать твое число в 20 раз быстрее. Почему ты не захотел разложить число в пятнадцатеричный ряд и вместо синхронизирующего нуля передать что-нибудь более ценное?

И еще проясни смысл вот этой строки в конце принимающей части

print((l-l%10)/10)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хороший результат, ты близок к успеху, но есть возможность передать твое число в 20 раз быстрее. Почему ты не захотел разложить число в пятнадцатеричный ряд и вместо синхронизирующего нуля передать что-нибудь более ценное?И еще проясни смысл вот этой строки в конце принимающей части

 

print((l-l%10)/10)
Целочисленное деление-

3:2=1 вместо 1,5

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Целочисленное деление

 

Синтаксис Lua не вызывает вопросов. Главный вопрос - зачем. Кстати, в коде присутствует еще один странный момент. Приведу краткую выдержку и добавлю свою комментарии. Предполагаю, что дело здесь в неправильном использовании числового типа, но я хочу понять, как ты пришел к такому решению, т.к. есть в этом коде что-то очень неправильное.

-- в цикле передатчика:
l = l - 10^(n-1)

-- в цикле приемника:
l = l +10^ (r.getInput(s.left)-1)
if r.getInput(s.left)==1 then l=l+1-0.1  -- зачем ты что-то добавляешь к результату?

-- вывод результата приемника
print((l-l%10)/10) -- зачем делишь его на 10?
Upd: Погуглил числовой тип в Lua. Четырнадцать девяток вообще не должны вызывать какого-либо переполнения. Так что, я не понимаю происходящее в коде. Присутствуют как минимум три странности:

1) Какое-то деление результата на 10;

2) Добавление к результату 0.9 в тех циклах, когда уже было добавлено 1.0, т.е. 9 раз;

3) Добавление к результату 0.1 во всех циклах, т.е. в твоем случае 14*9 раз.

 

Quant, ты хотя бы проверял работу своего кода? Что выводил приемник?

Изменено пользователем eu_tomat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А,это осталось после исправления ошибок,eu_tomat,и if r.getInput(s.left)==1 then l=l+1-0.1 никогда не выполняется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве передатчик никогда не выдает единицу?

Хотя, нет. Спрошу иначе. Почему твой передатчик никогда не выдает единицу?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве передатчик никогда не выдает единицу?

Хотя, нет. Спрошу иначе. Почему твой передатчик никогда не выдает единицу?

По той же причине, откуда там дроби в другом варианте кода,хотя там нет делений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По той же причине, откуда там дроби в другом варианте кода,хотя там нет делений.

Ты на каком языке пишешь? По-русски скажи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ты на каком языке пишешь? По-русски скажи.

передаю 93 - получается 94.3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

передаю 93 - получается 94.3

Естественно. Я же тебе говорю, у тебя в каждом цикле добавляется 0.1

А циклов у тебя 9+4 = 13.

Поэтому 93 + 0.1*(9+4) = 94.3

 

И для того, чтобы решить проблему, следует не подгонять результат, добавляя 0.9, и не умножать в передатчике на 10, а потом в приемнике делить, чтобы убрать ошибку, т.к. не понимая природы накопления ошибки, ты не можешь оценить и ее размер.

 

Надо просто найти причину накопления ошибки и устранить ее.

Изменено пользователем eu_tomat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Естественно. Я же тебе говорю, у тебя в каждом цикле добавляется 0.1

А циклов у тебя 9+4 = 13.

Поэтому 93 + 0.1*(9+4) = 94.3

 

И для того, чтобы решить проблему, следует не подгонять результат, добавляя 0.9, и не умножать в передатчике на 10, а потом в приемнике делить, чтобы убрать ошибку, т.к. не понимая природы накопления ошибки, ты не можешь оценить и ее размер.

 

Надо просто найти причину накопления ошибки и устранить ее.

в этой версии кода:

local symtime = 0.05

local maxreqtime = 2 --Максимальное время синхронизации

 

 

local c = require("component")

local s = require("sides")

local r = c.redstone

local l = tonumber(io.read())

 

os.sleep(maxreqtime - (os.time()%maxreqtime)+1)

while l>0 do

--print(l)

if l>99999999999999 then n=15

elseif l>9999999999999 then n=14

elseif l>999999999999 then n=13

elseif l>99999999999 then n=12

elseif l>9999999999 then n=11

elseif l>999999999 then n=10

elseif l>99999999 then n=9

elseif l>9999999 then n=8

elseif l>999999 then n=7

elseif l>99999 then n=6

elseif l>9999 then n=5

elseif l>999 then n=4

elseif l>99 then n=3

elseif l>9 then n=2

else n=1 end;

 

l = l - 10^(n-1)

 

r.setOutput(s.right,n)

os.sleep(symtime)

r.setOutput(s.right,0)

os.sleep(symtime)

end;

 

 

local e = require("event")

local c = require("component")

local s = require("sides")

local r = c.redstone

local l = 0

local t = 15

local b = false

function f()

t=3

print(r.getInput(s.left))

l = l +10^ (r.getInput(s.left)-1)

--if r.getInput(s.left)==1 then b=true end;

end;

e.listen("redstone_changed",f)

while t>0 do os.sleep(1) t = t - 1

end;

if b then l=l-1 end;

print(l)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в этой версии кода:

Да, именно в этой, когда ты еще не понаставил костылей.

Правда, здесь тоже какой-то мусор в виде "if b then l=l-1 end;", но не будем о нем.

В каждом цикле у тебя неявно добавляется 0.1 к результату.

 

Вот, ответь мне, сколько у тебя выполняется циклов передачи при пересылке числа 93?

И сколько раз вызывается событие изменения редстоуна в приемнике?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, именно в этой, когда ты еще не понаставил костылей.

Правда, здесь тоже какой-то мусор в виде "if b then l=l-1 end;", но не будем о нем.

В каждом цикле у тебя неявно добавляется 0.1 к результату.

 

Вот, ответь мне, сколько у тебя выполняется циклов передачи при пересылке числа 93?

И сколько раз вызывается событие изменения редстоуна в приемнике?

12 раз,событие - 24раза

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

12 раз,событие - 24раза

Отлично. Теперь скажи, сколько раз происходит суммирование полученных данных в результирующую переменную?

И что именно суммируется?

Если сложно считать в уме, можешь добавить print в обработчик события.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отлично. Теперь скажи, сколько раз происходит суммирование полученных данных в результирующую переменную?

И что именно суммируется?

Если сложно считать в уме, можешь добавить print в обработчик события.

10+0+10+0+10+0+10+0+10+0+10+0+10+0+10+0+10+0+1+0+1+0+1+0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах


10+0+10+0+10+0+10+0+10+0+10+0+10+0+10+0+10+0+1+0+1+0+1+0

Это ты в уме посчитал, но кое-чего не учел.
Для начала перепиши обработчик события в удобоваримый вид. Например:
local inp = r.getInput(input_side)
local add = 10^(inp-1)
res = res + add
print( inp,add,res )
И посмотри на вывод.

 

Fingercomp, опередил меня. Зря ты сказал. Пусть поучился бы отладке кода.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Fingercomp, опередил меня. Зря ты сказал. Пусть поучился бы отладке кода.

ОК, к счастью, Квант это сообщение не увидел (был в оффлайне), так что успел скрыть)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ОК, к счастью, Квант это сообщение не увидел (был в оффлайне), так что успел скрыть)

Ах тыж подлец:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ах тыж подлец

Quant, для тебя же стараемся, помогаем тебе научиться, а ты только флудишь во всех темах.

Посмотри наконец на то, что выведет обработчик события. И без слов Фигнера уже сколько намеков было. Он-то уже разжевал до невозможности, лишь бы ты побыстрее закончил. Сам немного пожуй, дружище, а то зубы не окрепнут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Quant, для тебя же стараемся, помогаем тебе научиться, а ты только флудишь во всех темах.

Посмотри наконец на то, что выведет обработчик события. И без слов Фигнера уже сколько намеков было. Он-то уже разжевал до невозможности, лишь бы ты побыстрее закончил. Сам немного пожуй, дружище, а то зубы не окрепнут.

Во-во, а то развелось беззубых )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×