Maxzz

Одна и та же плата. Один и тот же код переключения на внешний кварц в двух разных прошивках. XC16 1.31. MPLAB X 5.50 void ConfigureOscillator(void) { RCONbits.SWDTEN = 0; // Configure PLL prescaler, PLL postscaler, PLL divisor PLLFBD=41; // M = 32 CLKDIVbits.PLLPOST=0; // N1 = 2 CLKDIVbits.PLLPRE=0; // N2 = 2 // Initiate Clock Switch to Primary Oscillator with PLL (NOSC = 0b011) __builtin_write_OSCCONH(0x03); __builtin_write_OSCCONL(0x01); // Wait for Clock switch to occur while (OSCCONbits.COSC != 0b011); // Wait for PLL to lock while(OSCCONbits.LOCK!=1) {}; } В обеих прошивках вызывается первой строчкой в main(). Но первая прошивка работает нормально, а вторая - зависает на строчке ожидания готовности переключения источника клока - "while (OSCCONbits.COSC != 0b011);". Даже в новом пустом проекте, только со скопированной функцией переключения клока - не работает. А в старом проекте, сделанном в старой 4.х версии и XC16 1.24 и импортированной в 5.х - работает. Совсем голову поломал, может, кто сможет подсказать, где может быть причина?

Ну не с 99%, но так как сканирование производится многократно, с большой вероятностью. Луч лидара тоже может попасть в дырку в коробке и быть поглощенным полностью. Или отразиться от зеркальной поверхности в сторону. С большого расстояния он не сможет определить толщину опоры, это да. Но дать не врезаться в нее вполне может. Кроме того, есть вполне стандартные алгоритмы обужения луча, с которыми разрешение можно удвоить. Летучая мышь определяет положение мотылька с расстояния в три десятка метров. А у нее только один излучающий канал и два принимающих, плюс быстродействие DSP ограниченное :)

Сама по себе - нет. Но с учетом механики для лидара... Чисто по компонентам, например - что там, что там будет - FPGAшка, LNA (в сонаре с 8 ППЭ, их правда, 8), VGA. В сонаре добавляем, скажем, ту же STHV800, АЦП для 40 кгц стоит копейки. Плюс 8 пьезоэлементов. Длина волны у нас для 40 кгц в воздухе 8.5 мм. Слегка неудобно, тут или ищем пьезокерамику узкую, но длинную, чтобы шаг решетки сделать 1/2L, или не заморачиваемся, берем китайские, ставим тубусы для нужной нам диаграммы направленности чтобы исключить боковые дифракционные максимумы и ставим 2L решетку... Теряем, конечно, в рабочем угле ФАР, но приобретаем в отсутствии геморроя с излучателями. Но все равно, калибруем после изготовления, т.к. параметры китайских пьезоизлучателей процентов на 20-30 могут отличаться запросто. В лидаре добавляем высокоскоростной компаратор, скажем ADCMP566, лазер, диод, усилитель и механику с качающимся и полупрозрачными зеркалами. Теоретически, конечно, механику можно взять из лазерного штрих-кодового сканера, но там зеркало просто болтается с определенной частотой, конкретный угол не задается и не отслеживается, поэтому применимо ли, вопрос... Кстати, схемотехника что для TDC, что для метода измерения фазового угла будет практически одинаковой...

Это надо смотреть учебник по радиолокации :) Но сделать сонар с шириной луча в 3 градуса и углом сканирования в +/-30 градусов без механики должно быть относительно несложно. А компоненты подойдут, в общем-то, те же, что используются для аппаратов УЗ диагностики - у ST это STHV748, STHV800, например. Искать по словам "ultrasonic pulser", "ultrasonic T/R switch", "ultrasonic beamformer".

Например. Но конкретно в этом корпусе надо смотреть - не очень удобно для разработки, там шаг шаров 0.5 мм, если надо много I/O - плата должна разрабатываться под HDI, для прототипов это дорого. В серии, конечно, значения особого не имеет. Для прототипов удобнее BGA381. И вопрос по ультразвуку - а фазированную решетку не рассматривали? Можно получить довольно неплохие параметры по пространственному разрешению...

Стабильность у этих ЛЗ не айс. DS1135 от -20 до +70 съезжает на наносекунду с лишним. Довольно стабильна NB6L295MNTXG, но она программируемая и цена у нее под $30...

1. Вы не смотрели Acam-овские решения? Там есть TDC, которые в некоторых режимах измеряют от нуля с разрешением порядка 30пс. https://ams.com/time-to-digital-converters 2. Для TDC на FPGA ICE40 не подойдет от слова "совсем". У HX серии задержка распространения на бин порядка 0.7 нс. А для получения разрешений класса 20пс и лучше нужны FPGA c задержками лучше 0.4нс/бин и multiwave-union TDC, это порядка 8000LE на канал. В ICE40 ничего не подходит. Хотите дешевле - делайте на ECP5, оно стоит вдвое меньше Циклона.

Продано.

5.5 разрядный мультиметр Advantest R6452A Два канала измерения. Базовая погрешность 0,018% Откалиброван, см фото. Дисплей не севший. Внешнее состояние на "3" - повреждены клеммы (обычная проблема техники Advantest/ADCMT, на работоспособности не сказывается), трещины и сколы в задней рамке. 8000р. На авито такой же прибор в примерно таком же состоянии можно купить за 12000, без повреждений - за 15000. На ебэе вообще только от $450.

Интересно, зачем создавать тему, а потом не отвечать на заданные вопросы? Наверное, так сильно нуждаются в результате...

Да, это НИР, но аппаратная часть ни при чём. Дело в самом принципе измерения расхода времяимпульсным методом. Несмотря на то, что везде в описании этого метода пишется базовая формула v = dt*C^2/(2*cos a*La), при разработке реального прибора всплывает, что в зависимости от скорости потока, вязкости среды, широховатости стенок трубы, конфигурации труб перед измерительным участком разница между реальным расходом, и полученным по формуле, может составлять до 25%. Потому что вычисленная скорость потока является некоей средней скоростью потока на пути прохождения УЗ импульса, а реальная средняя скорость потока по всей площади поперечного сечения трубы - может быть очень сильно другой. Вот и требуется найти метод нахождения точного профиля потока для текущей скорости потока в трубе и соответствующего ему коэффициента коррекции теоретической скорости потока к реальной средней по всему сечению трубы скорости. Задача непростая, для получения погрешности в 1% на диапазоне расходов 1:25 для однолучевого прибора мне потребовалось суммарно два месяца копания в патентах и статьях, и еще полтора месяца проливок. С чего бы это? Доступ к флэши закрыть, прибор в своей собственности, чтобы заказчик не мог забрать. И всё будет нормально.

Как сдавать - это просто. Пишется программный модуль, который по сырым временам и геометрическим параметрам УПР считает расход, вставляется в упрощенную прошивку соответствуюшего прибора ( или в рабочую, но с подписанием NDA или чего-то похожего), УПР проливается на поверочной установке с нужной точности эталоном - и если соответсвующие ТЗ прогрешности достигнуты - производится оплата и передаётся документация по методике. Без написания прошивки, конечно, не обойтись. А вот деньги и сроки - интересны, да...

Да у топикстартера, я так понимаю, если я правильно нашел его контору по данным в документе, уже есть готовый прибор под задачу УЗС-1. Но погрешности у прибора, достаточные для коммерческого/технологического учета воды, ничем не выделяются на общем фоне десятков таких же приборов. А выделяться - хочется. А у GP30 внутри не ARM, а что-то совсем своеобразное, убогая среда разработки и очень скромные параметры - предназначена она для квартирных счетчиков. Серьезный расходомер чисто на ней не сделаешь, нужен обвес. Ну и куча работы по получению достойной метрологии.

Да понятно для чего это нужно, для того, чтобы проходить по конкурсам, нацеленным на импортные приборы - Endress+Hauser, Siemens, Rosemount, Krohne - там требования к погрешностям от 0,5% до 0,2% на основных диапазонах 1:10 и 1:25. Если посмотреть на то, что производит компания автора темы, то ничего из этого не подходит, а им хотелось бы иметь. Вопрос, сколько они готовы за это заплатить. И тому, кто занимался разработкой TOF УЗ расходомеров, желание заказчика вполне понятное. Но хотелось бы, конечно, конкретики.

Несколько вопросов. 1) Какую допустимую погрешность на воде вы хотите получить для 1- 2- 3- лучевых приборов и в каких диапазонах расходов? (кстати, каналами в российской практике принято называть количество УПР, подключенных к вторичному преобразователю, количество пар ПЭП называют лучами). 2) Какими вычислительными мощностями обладают ваши приборы? Потому что, одно дело использовать, как Siemens или Controlotron полученные сотнями проливок на разных диаметрах и конфигурациях трубопроводов таблицы, на основе которых с использованием же эмпирических коэффициентов для разных конфигураций труб перед УПР вычисляется рабочий коэффициент для потока на момент измерения, что не требует больших мощностей, но требует большого объема работ по наработке этих самых эмпирических данных, и другое совсем дело - расчет профиля потока, скажем, методом конечных элементов на лету с последующим решением обратной задачи расчета расхода по времени прохождения сигнала. Кстати, вы планируете учитывать конфигурацию труб перед УПР? Сами понимаете, что обычные паспортные 10Ду перед УПР после двойного колена ну никак не дадут возможность получить погрешность 0,5% на 1-лучевом приборе, если исходить из предположения, что поток установившийся. Даже в 1% не получится вписаться. Потому как профиль потока всякими непрямолинейными участками искажается значительно. 3) По поводу влияния карманов установки ПЭП - оно не так велико на больших Ду, а на малых Ду даже Panasonic, Fuji и GE используют или специальную конструкцию ПЭП, исключающую возникновение вихрей, или специальную конфигурацию трубы в месте установки ПЭП, уменьшающую их скорость, а также искажения профиля потока в этих местах. 4) Задача расчета температуры жидкости и учет её влияния на вязкость для воды довольно давно решена, а для других жидкостей - требуются соответствующие экспериментальные данные. 5) Если не секрет, какой бюджет на эту разработку вы планируете выделить?