Миландр

Регистр коррекции неортогональности в режиме СКВТ позволяет сдвигать фазу на +-пи/4. А возможно задать +пи/2 или -пи/2 ?

Больше уже не двигает.
На всякий случай - это коррекция фазы огибающего сигнала, не несущей. Меняется именно система координат в которой вычисляется угол.

"Схема восстановления сигнала опорной частоты
использует сигнал Ex_ref для определения квадранта в котором находится СКВТ"

Если мы хотим работать внутри одного квадранта, с параметром Coord_resolution=0, то может ли м/сх работать без этого сигнала?

Да, тогда поставьте Ex_source=1, а вывод EXI нужно посадить через резистор на землю.

Здравствуйте, коллеги!

Нужна помощь. Использую микросхему 1310НМ025 (1847 rev3). Настройки стоят такие:
Coord_resolution[3:0] = 2 (разрядность угла 16 бит)
LBW = 14 (т.е. тоже 16 бит)
Vel_resolution[3:0] = 3.
Прикрепляю pdf, где более подробно описал все настройки и условия работы микросхемы.
Т.е. максимальная скорость должна быть 976 Гц в положительном направлении. И ей должен соответствовать код 32767 ед., и это так для версии rev2 1738, но не для rev3 1847.
В rev3 я разгоняю двигатель до приблизительно 100 Гц (а скорее всего даже до 97,6), имею код около 3270 ед. (предполагаю, что это 3276) и вижу, что регистр C1Vel переполняется. Ниже прикладываю скрин терминала с работы, где виден этот эффект

По вертикальной оси как раз выведен необработанный код скорости с регистра C1Vel, по горизонтальной – время.
Я постарался стабилизироваться на скорости 100 Гц (как раз «дребезг» на скрине) и посмотрел, какой же код скорости показывает SPI. Второй луч поставил на чип селект. Скриншоты непосредственно перед и после переполнения так же прилагаю.
Перед переполнением

И после переполнения

Для сравнения приведу ещё осциллограмму с CS и SCK в том же масштабе, чтобы точно было видно, что разрядов до переполнения ещё хватает.

Из скринов с осциллографа видно, что переполнение является результатом работы самой микросхемы (или её неправильной настройки?). Т.е. SPI-master ни при чём. Разрядов ещё хватает.
Изменение параметров LBW и Vel_resolution не дало абсолютно никаких результатов. Переполнение точно так же происходит при коде около 3270 ед., просто этот код соответствует другой скорости. Предполагаю, что при формировании кода скорости происходит лишний сдвиг влево на единицу десятичного разряда.
При переполнении флаг OVF также устанавливается в единицу.


Кто-нибудь сталкивался? В чём может быть дело? Не нашёл в errata от 26.11.2018 информации об этом.
Заранее спасибо за ответ!

Действительно, в ревизии 3, с целью уменьшения шумности, внутреннее значение скорости отбирается до фильтра, и увеличилось в 10 раз. Однако, это изменение не учтено при обрезании результата под размер 16 бит Внесем ошибку в эррату.
К сожалению, напрямую обойти это не удастся, только увеличивать значение Vel_resolution.

Будет ли это исправлено в последующих ревизиях? И где можно отследить информацию об этом?

Вероятно, будет еще одна полноценная ревизия. Тогда в ней исправим все ошибки 3ей ревизии.
Здесь сообщу, когда/если будет новая ревизия.

Возможно ли использование Vel_resolution < 3, допустим 0? В версии 1.1.0 спецификации не нашел информации о том, что будет при значениях, отличных от приведенных в таблице 7. С формулой 20 всё ясно, и на практике проверял. Интересует вопрос надёжности и отсутствия неоговоренных подводных камней.
Ещё хотелось бы подать сигналы с одного датчика параллельно на два канала одной микросхемы. Собираюсь сдедать это, соединив IOSA1 с IOSA2 и IOCA1 с IOCA2 соответственно. При этом будут задействованы операционники только одного канала, на которые параллельно будут подключаться по два АЦП. Входного сопротивления АЦП я не знаю. Вопрос в том, не перегрузит ли это ОУ при постоянной работе в таком режиме?

Должно работать.



Из общих соображений это может быть рабочий вариант, но никто не проверял. Могут ухудшиться характеристики АЦП, что в свою очередь повлияет на погрешность. На каждом АЦП ОУ заряжает емкость 6,84pF через ~4кОм (сопротивление точно не могу сказать). Время заряда емкости (33 + ADC_cycle - 42)/FINT, т.е. можно его регулировать с помощью ADC_cycle.

Пришло письмо, что вы будете разрабатывать "МК на базе RISC-V с умножающим ЦАПом и преобразователем СКВТ, индукционных, емкостных или оптических датчиков" с описанием основных параметров.
А можно поинтересоваться, что это за "индукционные, емкостные или оптические датчики", и что за аналог?

Если вопрос ко мне, то я пока таких не видел, но вроде бы они существуют. Проводятся маркетинговые исследования, на предмет интереса к подобной микросхеме - более дешевого и массового варианта, сделанного по обычным технологиям (без стойкости), а также ее возможного облика.

Понятно, спасибо.
А категория ВП будет или только ОТК?

Вообще не очень понятно как это будет выглядеть. У емкостных возбуждение обычно большое(+-15В), частота 20/40кГц, токи не большие. У индукционных частота до 2МГц со всеми вытекающими. В оптике самое сложное соединить все отсчеты/дорожки и АЦП обычных контроллеров типа ВЕ92 с головой достаточно.

Из аналогов знаю только для СКВТ(AD2S, PDG411, RD-19230) и еще для индукционных CAM502(302,204) и LX3302A, но у вторых основное - это контроль резонанса. Емкостные netzer делает на рассыпухе. Оптику делают много на чем. Специализированные разве что с кучей фотоприемников и обработкой их сигналов, причем для своих кодовых шкал.

Обычно без ВП мы не делаем.
Пока что все на уровне разговоров, и как это будет в итоге выглядеть трудно сказать.
Сложилось впечатление, что под емкостными/индукционными/оптическими датчиками все понимают разные вещи (и у нас тоже). В данном контексте это скорее какие то разновидности абсолютных датчиков похожих на СКВТ/индуктосины c квадратурными сигналами (sin и cos). Для обычных емкостных датчиков у нас есть АЦП ёмкость-код.

Коллеги, хотел бы обратить внимание на вот такую картинку:

Это телеметрия от рейса PK-LQP, разбившегося недавно в Индонезии (очень похожий случай только что в Эфиопии), из за которой сейчас на приколе все 737MAX. Взято отсюда https://denokan.livejournal.com/204046.html
В контексте этой ветки, хочу обратить внимание ТОЛЬКО на графики левого и правого датчика углов атаки (6 и 7 график "показания углов атаки"). Они стали первопричиной катастрофы, хотя их никто и не обвиняет. Датчики в общем то работают, но показывают значения с разным знаком. [Конечно, там другая микросхема]
-----
Немного инсинуаций:
Датчик UTC 0861, вероятно, основан на RVDT (4х проводная схема) у которого сдвиг фаз между первичной и вторичной обмотки превысил допустимое значение, в результате чего поменялся знак. Вероятно датчик даже полностью исправен (на земле он успешно проходил проверки), но имеет конструктивно малый запас по фазе при высокой температуре (Эфиопия и Индонезия жаркие страны с сильным солнцем). Это, конечно, только версия.
-----
Немного лозунгов:
Всегда настраивайте сдвиг фаз (по методике) и проверяйте, что он далеко от пределов, во всем диапазоне температур.
Вероятно, высокая частота возбуждения, все же, не очень хорошая идея, по крайней мере нужно очень внимательно следить за сдвигом фаз.
5ти проводная схема LVDT (cо средней точкой) не имеет подобной проблемы, а также и ряда других.