Jump to content

    

iiv

Свой
  • Content Count

    2265
  • Joined

  • Last visited

Everything posted by iiv


  1. Спасибо большое, wim и µ₀N²!!! Верно подметили, проще функцию записать, но словами тоже надо :) амплитуда всегда нормируется и про нее можно не думать. Конечно если магнитное поле уползло в разы, то про нее надо тоже думать, но там и сам спектр начинает видоизменяться. ага, верно, Вы правы, спасибо, что поправили. Так правильно, обычно так и делаю. Но вот от измерения к измерению магнитное поле может немного измениться, и спектр сдвигается, и обычно с этим я и борюсь, пока вроде успешно. Но надо как-то формализовать словами как это происходит.
  2. Спасибо за ответ! exp(i p(t)) = cos(p(t) + i sin(p(t)) - у меня иногда есть пара сигналов, которая задана в виде комплексного числа, а иногда - только один сигнал (действительная или мнимая часть экспоненциального сигнала). Мне нужно охватывать оба случая, так как оба случая встречаются в моей аппаратуре. Сам сигнал от одного изотопа суть Re ( exp (i W t + i W q(t))) или в комплексном случае, exp (i W t + i W q(t)) - где q(t) медленно осциллирующая функция, а W - частота несущей, например, для водорода b 1.9Т: W=80MHz, q(t) имеет множество пиков, разнесенных примерно на 1КГц. Очевидно проще рассматреть сразу exp(i p(t)) и говорить именно про нее, а не тянуть за собой W t + i W q(t). Как я говорил, если интенсивность магнитного поля меняется, то и W и q(t) линейно меняются (в первом приближении), поэтому проще оперировать именно с трансформацией exp(i p(t)) в exp(i C p(t)) или, в действительном случае, sin(p(t)) в sin(C p(t)) - выбрать синус или косинус тут не принципиально. так и верно, множество, они все сидят не далеко от W и их число зависит от материала, на котором измеряют ЯМР! Скажите, пожалуйста, в чем проблема и не понимание?
  3. Спасибо большое за интересные обсуждения и полезные советы! Да, в ЯМРе сигнал зависит от величины магнитного поля. Фактически, на 1.9Т, которые я использую, у меня примерно 80МГц - несушая по водороду, причем искомый сигнал - это примерно 1КГц в районе этих 80МГц. Мне же надо описать ситуацию, когда магнитное поле изменяется, то есть вместо 80МГц у меня, например, получилось 81МГц. (да, на 1/80 примерно увеличилось магнитное поле) и от этого не только несущая увеличилась, но и сам спектр тоже на эти 1/80 шире стал. Пока остановился на frequency converter, а также дал описание, что этот частотный конвертер делает, то есть переводит сигнал из exp(i p(t)) в exp(i C p(t)), с коэффициентом, равным коэффициенту изменения интенсивности магнитного поля. По поводу "ширина спектра несущих пренебрежимо мала" - это верно для спектра водорода, но уже не верно для другис спектров, например, у углерода где-то 30МГц несушая, и под 60КГц сам спектр, а есть случаи, когда спектры разных изотопов вообще друг на друга залезают, то есть мне конечно же хотелось бы описать общий случай.
  4. кстати, какой-то из старых Джетсонов продувал одроидовской малишной ГПУшке по вычислениям на одинарной точности, что меня сильно забавляло.
  5. на 2014 этот одроид.ху был самым быстрым из всего, что я тогда успел попробовать и с маленькими габаритами. Если габариты позволяют, советую взять обычный писюг и воткнуть туда нормальную графическую карту, латентность будет существенно меньше (на Нвидии сейчас около двух микросекунд), но тут потребление будет в разы выше. Я когда-то так тоже делал, правда и габариты были около 25х25х8см
  6. пользовал до 2014, сейчас все платы у заказчиков, одна у меня есть, но я ее еще в то время пожег, возможно только съемный блок памяти, но помню, что с пол-года за час не смог запустить, а потом забил. У заказчиков как я понимаю, до сих пор все 6 плат работают, по крайней мере никто не жаловался. Из воспоминаний с 2014 года там примерно 1гбайт в секуду скорость копирования оперативная - видео была, но латентность существенная, чуть не до милисеунды доходила. То есть если Вы большими блоками копировать будете, то 1ГБ/с это почти 100 кадров в секунду на FullHD, а если маленькими блоками, то ой, все накроется медным тазом и надо держать эти блоки в видеопамяти, а ее как я помню, там не сильно то и много, на десяток экранов максимум. А нарисовать сразу на OpenGL не покатит? Борда же это поддерживает, там можно неподецки быстро рендерить - я на ней трехмерный контурплот самопально написанный на 10 миллионов линий крутил, более-менее не тормозило. А еще на той видеокарте считаться можно, я на ней около 100Гфлопсов выжимал на одинарной точности, правда борда в этот момент 20ватт потребляется и адски греется :)
  7. я бы порекомендовал одроид-ху4 там встроенная ГПУшка шустрая и на ней аппаратно можно очень многое, я на предыдущем октоядерном одроиде много игрался, и, ИМХО, как раз Вам хорошо должен подойти. Но в линуксе придется разбираться, особенно когда OpenCL для Ваших рисунков настраивать будете.
  8. А их тоже как и штопанные ячейки контробасом в РФ поставлять будете? Может по первости, как Plain советовал с 8-ми битными микроконтроллерами, или как я когда-то про MCP3913 (60 бакс на 126 каналов и не под санкциями)? я очень сомневаюсь, что рабочий клон этой МС с аналогичными характеристиками вы сможете купить дешевле оптовой цены с сайта Техаса, то есть за 50 бакс.
  9. Спасибо большое за ответы! ЯМР на постоянных магнитах, то есть несущие частоты в диапазоне около 5-300 МГц а ширина спектра 100Гц-10кГц. Простите, пожалуйста, в первоначальной версии моего ответа я это написал, но потом как-то опрометчиво удалил.
  10. Спасибо большое, за советы! Технический репорт пишу с описанием того, что делаю. Так как есть вероятность, что англоязычная версия этого текста потом будет сконвертирована в статью, хотелось бы написать идеально. То, что я делаю, у меня реализовано в цифре, но даже в цифре все сделано на конечных элементах, то есть по сути - аналогово. согласен. Пока написал умножитель частоты сигнала, то есть такой преобразователь сигнала, который трансформирует сигнал вида $a(t) exp (i b(t))$ в $a(t) exp (i c b(t))$, где $с$ - коэффициент умножения.
  11. Спасибо большое за советы! Ага, верно, с передискретизатором - я в терминах запутался, спасибо большое, что поправили! Умножитель частоты (Frequency multiplier) мне нравится, но если открыть википедию хоть по-русски, хоть по-английски, там явно указывается, что исходный сигнал содержит одну частоту. Мне же нужно, чтобы исходный сигнал был какой есть (обычно там множество различных частот), и этот умножитель действует на все частоты с одинаковым коэффициентом... Phase multiplier - как-то мутно, нашел сссылку на патент, где частота остается, а фаза двигается, а это не то, что мне надо.
  12. Спасибо! Да, умножитель или делитель сигнала, или передискретизатор. Мне для одного технического репорта по-английски и доновременно, по-русски хочется назвать это одним общеупотребительным словом, причем с тем важным смысловым значением, что сигнал может быть взять еще до дискретизации, то есть в аналоге. То есть передискретизатор сигнала (sample rate conversion of signal) почти подходит с той только проблемой, что явно говорит о дискретной составляющей сигнала, а мне надо охватить аналоговую. Использовать или в контексте нельзя, так бы сказал аналоговый или цифровой передискретизаатор сигнала (analog or digital sample rate conversion of signal). Signal multiplier - имеет совершенно иную смысловую нагрузку, умножая сам сигнал, а не его фазу. Multiplier of phase of signal - как-то очень громоздко звучит...
  13. Добрый день, пусть у меня есть сигнал, вида f(t) sin( g(t) ), скажите, пожалуйста, как по-научному называются фильтры, которые скалируют на константу С частоту этого сигнала, то есть приводят сигнал в вид f(t) sin( C g(t) ) например, PLL так делает, в цифре можно очень много придумать аналогичного, как то прореживание или аппроксимация, как такой фильтр по-научному называется, скажите, пожалуйста? Спасибо! ИИВ
  14. может это TCу и поможет!
  15. я все-таки надеюсь, что программеры ACDSee не на столько тупые, что побайтно читают файлы, и время зачитывания тут роли не должно играть, если читать по 30кбайт. Те же 30МБайт ведь какой-нибудь ZIP за секунду наверное архивирует? Я не вкурсе, но предполагаю, что так.
  16. я не в курсе, что под виндой, если так, то да, вы правы. Если так, то там в чем-то другом тормоза, и, скорей всего не обходимые простым методом.
  17. в линуксе pnmtojpeg всего-то 18 кбайт, так что думайте сами решайте сами. Яб на месте ТС нашел бы свободный дисковый раздел, постивил линь и решил бы эту задачу за несколько часов, всяко это быстрее 5 дней было бы. Линукс сейчас очень дружелюбный. Рекомендую какую-нибудь бубунту для этого.
  18. там данные маленькие - реально в L1 кеш процессора влезут, а тормоза, ИМХО, из-за того, что старт программы в винде влечет запуск тучи всяких сервисов, и рам тут не поможет. Если взять исходники того, что я упоминал (а они опенсорсные) и воткнуть там вызовы друг за другом, то летать должно реально раз так в 20 быстрее, упираясь во время закачки и выкачки на диск, ибо если данные в первом кеше, то все работает почти на тактовой процессора, деже если было написано криворукими программистами.
  19. а лучше и вам тоже прочитать то сообщение, на которое вы ссылаетесь, и понять, что _pv прав.
  20. ага, и, ИМХО, без толку. Так как чуть будет другая температура ячейки, и все очень сильно соскалируется. Но ведь методы геолокации - это не тензорные аппроксимации, где скалирующий коэффициент обычно вообще никто не учитывает. То есть, ИМХО, совсем на скалировку можно забить, главное, чтоб относительно каждое основание ДНК друг от друга отличалось.
  21. Спасибо большое, за интересные советы!!! Актуально, очень даже, пока хотел на низковольтной серве сделать, но пока еще не созрел корпусину сделать. Из характеристик, что хочу достичь, длина хода поршня около 10см, частота хода 5-10 раз в секунду (20 раз я не потяну, хотя хотелось бы). Вес поршня - чем меньше, тем лучше, воздушное сопротивление поршня почти отсутствует, то есть если поршень весит 100гр, то все его сопротивление - как раз и его инерция во время хода, правда, как я понимаю, до 10-16g там при таких параметрах развиться может, хотя осетра эти параметры сильно урезать не хотелось бы :) EDIT: еще хотелось бы КПД по максимуму, но это уж как получится.
  22. простите, реально не знаю, ибо почти никогда на винде ничего не разрабатывал. В эмуляторе на цугвине поддержка многоядерности очень кривая, то есть этот способ может быть не рабочим. Как я понимаю, это примерно 600Гигабайт. Сильно быстрее, чем за несколько часов - всяко не реально из-за скорости чтения-записи на носитель, то есть если ничего не найдете, то Ваши 22 секунды за тысячу решат Вашу проблему за 5 дней под виндой... Криво конечно, но тоже решение, если вам это разово надо сделать, если не разово - то ой... надо с API CUDAвских библиотек разбираться и на них делать, там и за час конвертации можно уложиться, но разбираться с API можно и неделю. Я точно знаю, что такая функциональность есть, но никогда ее не использовал.
  23. bmptopnm pnmtopng под линуксом и распарралелить на все ядра, но обязательно, чтоб с ssdшника
  24. я полностью согласен, что если есть возможность что-то померить - это очень нужно сделать до того, как впадать во все тяжкие и разрабатывать эту электронику. То есть я не стращаю, но предвижу, что эти измерения конечно помогут понять в каком направлении двигаться, но самое интересное начнется, когда ТС воткнется в свои ячейки и начнет не просто измерять фемтосопротивления, а именно их обрабатывать и смотреть на сколько то, что он видит соответствует тому, что он ожидает. Сколько человеко-лет тут будет закопано - одному ТС будет известно.
  25. семплировать надо раз 10 а то и больше, чтоб учесть нестабильность скорости проползания ДНК. В ДНК - только 4 разных комбинации, но думаю, что есть случаи зажовывания и старта-стопа, это тоже надо охватывать. Однозначно там будет сильное скалирование сопротивления от кучи факторов, типа одно и то же основание в начале и в конце считывания могут на порядок по сопротивлению отличаться. То есть пока не имеешь доступ к данным с массовой эксплуатации, ИМХО, надо под 30 раз на сегмент считывать хотя бы, и чтоб потом было что выбросить. Я бы семплировал в 30-100 раз больше, а потом аппроксимировал чем-то подходящим типа кусочно-полиномиальных конечных элементов на существенно меньшей, возможно даже неравномерной сетке (шум выкинуть, но сигнал не потерять), и только это далее использовал для обработки. То есть, ИМХО, пока у вас не будет доступа к огромной куче данных с очень высокой частотой семплирования, вы реально не сможете отловить всех нюансов этого эксперимента. А так, да, со всех 126 ячеек на выходе не больше 5кбайт/с, можно даже с ардуины по компорту такой трафик отстукивать, но только не потянет эту математику ни ардуина, не, ИМХО, даже M7 кортекс.