Jump to content

    

_pv

Свой
  • Content Count

    2999
  • Joined

  • Last visited

Everything posted by _pv


  1. а они там ещё и с четвертым циклоном на второй плате, куда BBB втыкается?
  2. нашелся его китайский родственник под именем ebaz4205, к нему хотя бы схему/плату можно попытаться найти. правда за 40$ как и большинство остальных лотов "antminer control board". а за 20$ всё-таки как-то подозрительно. а ещё beaglebone black на алиэкспрессе если брать как запчасть к майнерам - тоже всего 20$ :)
  3. STM32F4 запись и отправка видео

    jpeg в межкадровое сжатие не умеет. и для него надо около 100-200 тактов (в зависимости от архитектуры МК) на пиксель. то есть на пару кадров в секунду с одной камеры stm32F4 возможно ещё хватило бы для VGA разрешения. и то если сильно постараться, но думаю не больше. а если МК более могучий, и ему хватает дури зажать в жпег со скоростью прилетающих с камеры 30кадров в секунду, то памяти под буфер достаточно только на 8 строк изображения. Но это баловство имхо, берите камеры с езернетом/вайфаем и рулите ими напрямую. ну или любой одноплатный ПК с линуксом для управелния/складирования картинок на SD карту, хотя вроде бы и готовых ip камер которые сами на sd карту пишут слишком дофига есть, чтобы самому такое разрабатывать.
  4. если все прямоугольники могут быть во весь экран то искать надо в первую очередь gpu способный сделать 1920*1080*40*60 = 5 Гига текселей / секунду, что для всяких raspberry и всяких allwinnerов с mail-400 пожалуй многовато будет.
  5. ну в 3Д игрушках миллионы треугольников на каждый кадр рисуются, но кадров в секунду как было 60 так и остаётся.
  6. специально для вас чем же отличаются два соседних числа, неужели сдвигом на один бит и добавлением нового бита из следующего числа? и ведь никто не мешает ходить по этой последовательности с шагом равным разрядности (4 в данном случае), что собственно и происходит при табличнном вычислении через xor, никто там по одному биту не двигает, и получать тем самым псевдослучайные числа.
  7. откройте хотя бы википедию и прочитайте наконец что такое сдвиговый регистр. и как следующее значение получается из предыдущего.
  8. а вы берите из него каждый 16й отсчёт, тогда будет 4096 неповторимых чисел, а те что между ними получаются как раз простым битовым сдвигом (тоже неповторимым) на то он и сдвиговый геристр.
  9. 6мм период отверстий 2мм отверстие 4мм зазор, 3 оптопары по 60 градусов (1мм) сдвинуты как раз и дают илиметровое разрешение.
  10. а у сдвигового регистра по вашему есть выбор как из какого-то своего состояния сгенерить больше одного следующего состояния сдвинутого на один бит? неуникальность "сдвиговой последовательности" означает что он прошел через все возможные значения и вернулся на начало. соответственно если какой-то полином генерирует максимальную последовательность, все они будут уникальные, иначе это не было бы максимальной последовательностью.
  11. судя по фото выходы оу приходят на PA8-12 PC6-9 у stm32f103rct6 нет АЦП на этих ногах. ну и с цифрой как-то понадежнее как мне кажется будет.
  12. я к тому что нельзя сделать отверстие которое ВСЕГДА будет перекрывать ровно 3 оптопары, это либо будет или 2 или 3 в зависиомости от положения, если отверстие чуть меньше, либо 3 или 4 если отверстие чуть больше. не получится так что при определённом положении синхронизация потеряется среди данных?
  13. при сдвиге ровно на пол бита, когда все обычные отверстия будут перекрывать по две оптопары сколько оптопар перекроет S? тоже две?
  14. а полиномы максимальной длины каким-то другим образом находятся? при переборе же значений, следующий подходящий код берется минимальным из возможных, что и даёт для первой четверти последовательности просто нечетные коды 1,3,5,7,9,... при этом по-вашему получается что для любой разрядности полином с двумя старшими единицами (для последовательности из нечетных чисел в начале) должен быть "максимальным", что выглядит как-то сомнительно. у него ещё последовательность с 0, а не с 1 как у оригинала начинается. тогда ещё столько же "разрядов" придётся потратить на "синхронизацию". а так только 4 из 16.
  15. Если она единственная, у меня для вас плохие новости, потому что тогда у энкодера который вы скопировать пытаетесь она тогда тоже неправильная, хотя и с моей последовательностью совпадает получше :)
  16. а просто сплиттер вместо циркулятора не подойдёт? если половину принимаемой мощности не жалко. полупрозрачным зеркалом поделить, поделённое при "передаче" можно даже пожалуй попробовать обратно собрать вместе, если половину передаваемой мощности жалко, ну а половина принятого улетит обратно в лазер.
  17. Не, не нужен там никакой дополнительный сдвиг на 0.5 бита. Есть только 16ти разрядные числа закодированные 16ю отверстиями. 32 оптопары там только для того, чтобы нормально получать 16ти разрядное число когда линейка ровно на полбита сдвинута. Каждый код вместе с соседним при побитовом сдвиге выдаст 16 различных комбинаций, пока следующий код не встанет в целиком в энкодер. Это минус 4 бита, для кодирования сдвинутых кодов, остаётся как раз 12 значащих бит. для 8ми бит, имеем -3 бита на кодирование 8ми "сдвинутых" комбинаций для каждого кода и остаётся 5 бит для кодирования позиции. осталось только найти такую последовательность соседей у которой и побитовом сдвиге не повторяются комбинации. тупо перебором для 8ми бит получается последовательность из 32 кодов 1, 3, 5, 7, 9, 11, 13, 15, 17, 49, 81, 113, 145, 177, 209, 242, 82, 114, 178, 210, 243, 53, 55, 59, 61, 63, 85, 214, 215, 219, 221, 254, при её побитовом сдвиге через 8ми битное "окно" из оптопар, на них будет последовательность из 255 неповторяющихся значений: 1, 2, 4, 8, 16, 32, 64, 129, 3, 6, 12, 24, 48, 96, 193, 130, 5, 10, 20, 40, 80, 160, 65, 131, 7, 14, 28, 56, 112, 225, 194, 132, 9, 18, 36, 72, 144, 33, 66, 133, 11, 22, 44, 88, 176, 97, 195, 134, 13, 26, 52, 104, 208, 161, 67, 135, 15, 30, 60, 120, 241, 226, 196, 136, 17, 34, 68, 137, 19, 38, 76, 152, 49, 98, 197, 138, 21, 42, 84, 168, 81, 162, 69, 139, 23, 46, 92, 184, 113, 227, 198, 140, 25, 50, 100, 200, 145, 35, 70, 141, 27, 54, 108, 216, 177, 99, 199, 142, 29, 58, 116, 232, 209, 163, 71, 143, 31, 62, 124, 249, 242, 228, 201, 146, 37, 74, 148, 41, 82, 164, 73, 147, 39, 78, 156, 57, 114, 229, 202, 149, 43, 86, 172, 89, 178, 101, 203, 150, 45, 90, 180, 105, 210, 165, 75, 151, 47, 94, 188, 121, 243, 230, 204, 153, 51, 102, 205, 154, 53, 106, 212, 169, 83, 166, 77, 155, 55, 110, 220, 185, 115, 231, 206, 157, 59, 118, 236, 217, 179, 103, 207, 158, 61, 122, 244, 233, 211, 167, 79, 159, 63, 126, 253, 250, 245, 234, 213, 170, 85, 171, 87, 174, 93, 186, 117, 235, 214, 173, 91, 182, 109, 218, 181, 107, 215, 175, 95, 190, 125, 251, 246, 237, 219, 183, 111, 222, 189, 123, 247, 238, 221, 187, 119, 239, 223, 191, 127, 255, 254, 252, 248, 240, 224, 192, 128 то есть 16ти отверстий действительно достаточно для кодирования 6mm * 65536 = 96mm * 4096 = 392m
  18. ну в аудио карту за 2$ можно влезть с паяльником и ёмкости на выходе позакорачивать, так что какое-то DC будет, но для аудио цапов его стабильность может быть довольно печальной, да и иногда в аудио ЦАПах/АЦП встречаются не особо отключаемые цифровые фвч фильтры.
  19. ну написано что поддерживает. теоретически в УСБ пролазить должно. для просто запихивания фрембуфера целиком в USB проц особо не нужен. а требуемые ТСом прямоугольники можно и на gpu закрашивать. у остальных hdmi + dispalyport.
  20. да вроде есть одноплатных пк и с двумя HDMI: RasPI4, EM3399, DragonBoard, UP squared. либо на USB3 вешать usbVGA, есть вообще безмозглые переходники, даже без буфера под кадр, FL2000 по 5$. они тупо непрерывно гонят поток из USB3 напрямую в VGA ЦАП вместе с синхронизацией.
  21. ну если микрофонный вход религия использовать не позволяет, то есть и с линейным: https://www.aliexpress.com/item/32960799667.html 2$ https://www.aliexpress.com/item/4000113207256.html 6$
  22. судя по фотографиям шаг 32 оптопар 3мм, в два раза меньше чем шаг отверстий , скорее всего чтобы без ошибок считывать 16 отверстий когда они как раз на пол шага сдвинуты.
  23. всё равно не хватит. например последовательность кодов 0x888, 0x889 1000 1000 1000 1000, 1000 1000 1000 1001, 1000 ... начинайте сдвигать влево побитно и через четыре бита опять получите повторяющийся код на оптопарах. то есть надо по 8 бит "синхронизации", и как при этом оставшихся 8 хватает на 392 метра - не понятно. Возможно используется то, что оптопар всё-таки 32 и где-то дальше по ленте есть круглые отверстия на пол шага (3мм) смещённые. Александр, есть фото другого конца ленты, где отверстий побольше?