В поисках эффективного датчика тонких излучений

[laryc]

Андрей! Что-то никак не пойму зачем тебе понадобились max736x-max735x да ещё с такой разнузданной архитектурой .. к простой мульке нужно обращаться по адресу! ... так и к тараканам начнём по отчеству.. достаточно просто полевого транзистора - ему что туда проводить что обратно.. ну мажно просто пачку транзисторов в одном корпусе... и ещё мож чего не доезжаю,так ты меня одёрни - зачем мультиплексировать SCL???! Вот нашёл хорошие датчики влажности и температуры в одном флаконе на двухпроводном интерфейсе SHT10 SHT11 вроде как по даташитам одно и тоже разница в цене на элитане меньше чем 500рэ

Изменено 2 ноября, 2013 пользователем laryc

[Andy1744]

Андрей! Что-то никак не пойму зачем тебе понадобились max736x-max735x да ещё с такой разнузданной архитектурой .. к простой мульке нужно обращаться по адресу! ... так и к тараканам начнём по отчеству.. достаточно просто полевого транзистора - ему что туда проводить что обратно.. ну мажно просто пачку транзисторов в одном корпусе... и ещё мож чего не доезжаю,так ты меня одёрни - зачем мультиплексировать SCL???! Вот нашёл хорошие датчики влажности и температуры в одном флаконе на двухпроводном интерфейсе SHT10 SHT11 вроде как по даташитам одно и тоже разница в цене на элитане меньше чем 500рэ

 

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

 

по поводу SCL , по хорошему его тоже нужно коммутировать ,связано это с тем что спецификация I2C предоставляет ведомому посредством этого сигнала управлять скоростью обмена (снижать если он посчитает что не успел). Если SCL поставить просто в параллель , то не поймав на шине SDA ни старта ни стопа , при поступающем тактировании SCL , ведомый может решить что он не успевает и начать резать скорость,типа - парни у вас тут что то интересное происходит , давайте как по медленнее. Т.е. в момент низкого уровня на SCL ведомый тоже поставит туда нулевой уровень на время сколько считает нужным ,а ведущий он ведь не просто ногой SCL дрыгает , он убрав свой "0" прежде всего проверяет вернулась ли шина в "1" , и если она не вернулась значит нужно ждать ведомого. В общем мы получим работу шины на крайне низкой частоте.

[Xenia]

Андрей! Что-то никак не пойму зачем тебе понадобились max736x-max735x да ещё с такой разнузданной архитектурой .. к простой мульке нужно обращаться по адресу!

 

А мне MAX7356 показался предельно простым - на типичный мультиплексор "8 в 1" похож: A0/A1/A2 - выбираемый номер входа, сами входы, и питание с землей. От типичного мультиплексора отличается только тем, что "входы" парные и двунаправленные. Проще управление даже сложно придумать.

 

Прочитав про "разнузданность", вновь полезла в даташит, нашла там описание регистров "enhanced mode" и тоже по-началу перепугалась. Но потом обнаружила, что у младшего MAX7356 (в отличие от старших MAX7357 и MAX7358) этого мода совсем нет. После чего успокоилась.

 

Полагаю, что выбор MAX7356 даже на руку мне с Ларусом, как закоренелым АВРщикам , т.к. я сначала предположила, что Анди обойдется без I2C-мультиплектора тем множеством I2C-интерфейсов, которые имеются у STM32F, но они оказались занятыми. Опять же, MAX7356 хорошо работает, как на 3.3-вольтовом питании, так и на 5-вольтовом.

[laryc]

Всем спасибо,но я так и не доехал до Киева - всё Конотоп да Конотоп... знач Энди Вы отправляете команду на включение преобразование на АДэшки по очереди на каждый преобразователь за t = 1ms?

[Andy1744]

Всем спасибо,но я так и не доехал до Киева - всё Конотоп да Конотоп... знач Энди Вы отправляете команду на включение преобразование на АДэшки по очереди на каждый преобразователь за t = 1ms?

 

да , точнее сказать что суммарное время потраченное на последовательный запуск N AD-шек t=0.1ms*N

[laryc]

Ну понял.. я всётаки ,наверно пожертвую скоростью обмена и постараюсь запускать все оси одновременно чтобы потом исключить сомнения ,но ещё не решил как это сделаю аппаратно ... есть мысль запарить это на логике с тремя состояниями чтобы ловить в логику "acknowledge from slave" тогда и скорость должно быть не потеряю ... но пока время есть пока приобрету прибамбасы для датчика и закончу прогу на LabView ...думал по быстрому напишу а тут открылись новые возможности кроме просто отображения но и управление с компа всякие команды засылать преобразователю да и перейти хочется с СОМ на USB тогда и на планшет виндузный можно перейти да и питаться с порта - в общем увяз в подробностях

[Andy1744]

чтобы ловить в логику "acknowledge from slave"

это самое храброе решение из возможных , без всякого сарказма скажу что мне слабо. но , объясни теперь мне , что тебе даст именно одновременное единичное измерение? такое впечатление что ты даже мало мальски фильтровать не собираешься ,как померил ,скажем раз в секунду , так и на экран бросил? если все же будешь как то фильтровать (ну хоть среднее взять) , тогда одновременность взятия сэмплов ,мне кажется, ни какой роли не играет. Расскажи что дальше будешь делать , после того как получил , три циферки померянные в раз.

[laryc]

это самое храброе решение из возможных , без всякого сарказма скажу что мне слабо. но , объясни теперь мне , что тебе даст именно одновременное единичное измерение? такое впечатление что ты даже мало мальски фильтровать не собираешься ,как померил ,скажем раз в секунду , так и на экран бросил? если все же будешь как то фильтровать (ну хоть среднее взять) , тогда одновременность взятия сэмплов ,мне кажется, ни какой роли не играет. Расскажи что дальше будешь делать , после того как получил , три циферки померянные в раз.

1) храброе решение говоришь? да не....! наиболее плодотворный период (с 30 до 40) я прошёл на логике поэтому остался опыт.. я на процы смотрел как на занятие для недоумков ,но пришлось "задрав штаны бежать за комсомолом" .. ну буду ли делать ловушку или нет я ещё не решил тем более преобразование С лежит в пределах 11 - 109,6 ms а ты говоришь что можно уложиться в 0,1 ms тогда действительно этот огород ни к чему ... можно конечно использовать вместо интерфейсного дешифратора шинный формирователь чтобы отстегнуть суммирование подтягивающих резисторов и отлавливать "acknowledge from slave" по первому состоявшемуся (если АДшки одинаковые то и отклик должен быть примерно равный) мож и скорость не потеряю,но это надо пробовать в железе ,а я взял с собой (я на вахте) только один датчик.. досада...но наверно пойду твоим путём ... нашёл аналдевайсы PCA9546AD 4 -> 1 I2C в приятном корпусе и дешёвые (Maxim я стараюсь обходить бо оригинальных разработок у них кот наплакал а реплики они продают по страшным ценам)

2). Фильры говоришь..мдя-я... оставим на потом.. я малость не докуриваю.. в АДэшках на блок схеме есть квадратик "digital filter" пока обойдусь им ... усреднения измерений есть и по 3 и 5 значениям прям на самописце .. щаз тут всяки тумблера на экране тусую в эту пользу.. да и зачем мне фильтры? если я мечтаю блок отлова логнормальных распределений приладить (готовый прибамбас на LabView есть но нужно покупать (стыреного нет) а для этого нужно купить лицензионную версию Labview ... в общем 1500$.. жаба давит)

P.S. если не куришь "логнормальное распределение" можешь спросить - сделаю попытку объянить на пальцах практическую пользу

Изменено 4 ноября, 2013 пользователем laryc

[Andy1744]

преобразование С лежит в пределах 11 - 109,6 ms а ты говоришь что можно уложиться в 0,1 ms тогда действительно этот огород ни к чему

преобразование это другой вопрос сколько уж там попросишь , те цифры что ты привел и есть , мы говорили только про сам запуск на него достаточно

0.1ms на лицо.

 

"логнормальное распределение"

это я не знаю что ты такое сказал , изысканная ругань ?

 

в любом случае , хорошо если похожую задачу мы порешаем разными техническими способами.

[laryc]

это я не знаю что ты такое сказал , изысканная ругань ?

 

в любом случае , хорошо если похожую задачу мы порешаем разными техническими способами.

да уж какая ругань это когда градиенты отлавливаешь через матстатистику

[Andy1744]

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

[Xenia]

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

 

Заслушать выступление начальника транспортного цеха хотите? Вот она я!

 

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

 

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

 

Если бы у нас были датчики типа турбинок, находящихся внутри трубок, то из таких трех таких трубок следовало бы соорудить конструкцию, в которой все три трубки были бы расположены перпендикулярно друг дружке, наподобие декартовых осей XYZ в 3-мерном пространстве. Тогда бы при любом расположении этой конструкции можно было бы вычислить точку/звезду, откуда дует "эфирный" ветер. Методика определения следовала бы из предположения, что максимальная скорость вращения турбинки достигается в положении, когда она своим торцом направлена на источник дутия. Тогда как в перпендикулярном положении к источнику турбинка не крутится совсем. В этом случае скорости всех трех турбинок можно было рассматривать, как проекции вектора потока, а стало быть, его положение относительно системы трубок/датчиков определялось тривиально.

 

Более того, в такой простой модели можно было бы использовать чисто астрономический подход из 3-х шагов:

1) Ориентировать оси трубок X и Y в горизонтальной плоскости земли, а трубку Z направить в зенит.

2) Медленно поворачивая конструкцию вокруг вертикальной оси (0-Z), найти такое ее положение, чтобы турбина X остановилась, а вращение турбины Y достигло максимальной величины. Это означало бы, что в этом положении источник потока находится в плоскости Y-Z. При этом направление трубки Y соответствовало его азимуту.

3) А величину склонения легко можно было найти на основании соотношения величин скорости между трубками Y и Z. При Y > Z источник находится ближе как горизонту, а при Z > Y ближе к зениту. Точный угол по отношению к горизонту определяется по арктангенсу двух этих величин, аки катетам.

 

В методическом плане двигать такую конструкцию было бы нежелательно, т.к. азимут и склонение источника потока может быть рассчитаны из любого ее положения. Но в плане удобства, ориентацию X и Y в горизонтальной плоскости земли, а Z в направлении зенита, было бы разумнее сохранить. Стационарно расположенная конструкция обладала бы еще и таким полезным свойством, что усреднять сырые отсчеты можно было бы неограниченно долго, не будучи стесненными тем обстоятельством, что измеряемые значения меняются в процессе движения/вращения. Т.е. здесь можно было бы отказаться от полиномиальной фильтрации, сохраняющей тренд, а использовать медианную фильтрацию или простое усреднение данных за какой-то достаточно продолжительный промежуток времени (экспозицию).

 

Теперь вернемся к нашим баранам - дифференциальным датчикам, с рогами под 90°. Такой датчик не даст нам величины падающего на него потока, а даст лишь разность между двумя взаимно перпендикулярными направлениями. Такой датчик приходится вращать (как в астрономическом подходе) до положения с максимальным сигналом. Это положение теоретически должно отвечать положению, когда Cin+ ориентирован по азимуту источника потока, а Cin- перпендикулярен ему.

 

В целом это более сложный случай для расчета направления к источнику потока, т.к. измеряем не проекцию потока на ось, а разность между проекциями на пару осей. Это не слишком приятное для расчетов обстоятельство, которое озадачивало меня и прежде. Я даже вопрос к собравшимся задавала (мечтая избавиться от прямого угла):

В этой связи меня очень интересуют результаты измерений, когда рога расположены не под 90° друг к другу, а под 180°, т.к. направлены ровно в противоположные стороны.

но мне так никто на него не ответил, видимо, полагая, что вопрос праздный.

 

Что можно сделать для 3D-задачи с прямоугольными датчиками, не меняя их конструкцию? По-видимому, в этом случае вращения никак не избежать, т.к. точки мин/макс приходится искать в процессе кругового сканирования. Хуже того, "отращивание третьего пальца" вверх в этой ситуации малополезно. Короче говоря, с применением сканирования направление источника потока может быть определено всего одним единственным датчиком! Тем паче, что от сканирования избавиться не удается. Процедура получается следующая:

1) Рогообразный датчик XY располагаем в горизонтальной плоскости земли и вращаем его в этой плоскости до нахождения максимальной разности Y-X. Это означает, что в точке максимума рог Y направлен по азимуту источника. Практически для этого надо совершить полный оборот (или несколько полных оборотов) датчика вокруг вертикальной оси для выбора искомого азимута.

2) Располагаем рогообразный датчик на этот раз уже в вертикальной (!) плоскости, образованной направлением найденного в п.1. азимута и точкой зенита. Теперь датчику придется совершить полный оборот, неудобный для осуществления в техническом плане. Но если пока закрыть глаза на механические трудности, то оборот в вертикальной плоскости должен помочь нам определить склонение источника потока над горизонтом. При этом мы остаемся с надеждой, что за это время в азимутальном отношении источник относительно датчика не переместился.

 

Конечно же очень хочется избавиться от вращений в пользу первой простейшей модели, где датчики измеряют проекции потока, а не разность в перпендикулярных направлениях. Но тут я пока ничего конкретного предложить не могу. Вижу, что для решения такой задачи, по меньшей мере, необходима "общая база", т.к. общая обкладка конденсатора, относительно которой измерялись бы все три (или больше) разностей, ибо только тогда можно было бы в процессе расчета перейти от разностей к абсолютным величинам. Т.е. тогда бы появилась возможность связать все измерения вместе через "общую базу". Тогда как при ее отсутствии мы фактически имеем неизвестные подставки под измеряемыми величинами на каждом из датчиков, что делает задачу определения направления источника невозможным без вращения конструкции. Т.к. именно вращение выполняет здесь функцию вычета этих поставок.

Изменено 4 ноября, 2013 пользователем Xenia

[Andy1744]

Вижу, что для решения такой задачи, по меньшей мере, необходима "общая база", т.к. общая обкладка конденсатора, относительно которой измерялись бы все три (или больше) разностей, ибо только тогда можно было бы в процессе расчета перейти от разностей к абсолютным величинам. Т.е. тогда бы появилась возможность связать все измерения вместе через "общую базу". Тогда как при ее отсутствии мы фактически имеем неизвестные подставки под измеряемыми величинами на каждом из датчиков, что делает задачу определения направления источника невозможным без вращения конструкции. Т.к. именно вращение выполняет здесь функцию вычета этих поставок.

 

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

[Andy1744]

По-видимому, в этом случае вращения никак не избежать, т.к. точки мин/макс приходится искать в процессе кругового сканирования. Хуже того, "отращивание третьего пальца" вверх в этой ситуации малополезно. Короче говоря, с применением сканирования направление источника потока может быть определено всего одним единственным датчиком! Тем паче, что от сканирования избавиться не удается.

 

согласен. но при наличии "третьего пальца" должно быть еще решение которого пока не видим.

[Xenia]

согласен. но при наличии "третьего пальца" должно быть еще решение которого пока не видим.

 

Логика тут такая. 3D-задача, будучи рассматриваемой в полярных координатах, отличается от 2D-задачи только добавлением еще одного угла (был, положим, только угол тета в горизонтальной плоскости, а тут появится еще и угол пси в вертикальной). Тем самым, 3D-задача как бы распадается на две задачи по поиску каждого из углов. Если наличие "третьего пальца вверх" решало бы задачу поиска вертикального угла без сканирования по вертикали, то ровно тем же способом можно было бы избавиться от сканирования и по горизонтали, т.к. обе задачи подобны друг другу. Но в 2D-задаче вы обойтись без кругового горизонтального сканирования не смогли, откуда следует, что не сможете обойтись и без вертикального, когда задача станет 3-мерной.

 

Сканирование сразу по двум углам - слишком затратная по времени операция, тем более, когда на каждую точку тратится не менее секунды, т.к. в 3D-задаче число точек возрастет в квадрате (всевозможные комбинации шагов обоих углов). А в этом случае гораздо проще искать углы последовательно - сначала найти один угол (тета), а затем, зафиксировав его, найти второй угол (пси). Такая процедура поиска была бы лишь вдвое продолжительнее, чем в 2D-задаче.

 

Однако как только задача распалась на два ПОСЛЕДОВАТЕЛЬНЫХ поиска отдельных углов, то мы сразу же обнаруживаем, что три пальца СРАЗУ нам никогда не нужны (!), т.е. на первом этапе используется только одна пара пальцев, а на втором этапе другая. А раз так, то третий палец всегда можно оторвать , а при переходе ко второму этапу развернуть конструкцию так, чтобы палец, нужда в котором отпала, принял положение пальца, в котором нужда появилась. Именно этот способ я и описала в своем прошлом сообщении.

Изменено 4 ноября, 2013 пользователем Xenia

[laryc]

Рассуждения достойны похвалы хотя и очевидны ибо аудитория мыслит в пространстве координат и времени, но как раз они и являются плохими союзниками. Временное интервалы преобразования велики и отстоят друг от друга на значительные промежутки. Пространственные ограничения вводятся геометрией датчика (хотя и на порядок лучше чем в классическом опыте). Нечто дующее с альфа Дракона приходит на уровень моря далёким отголоском размазанного процесса. Что остаётся ? Нечто среднее по психиатрической больнице в чём и заблудили человечество два пространственно мыслящих хлопца (Майкельсон & Морли) с подачи Гельмгольца. .. О чём это я?..

[laryc]

Сканирование сразу по двум углам - слишком затратная по времени операция, тем более, когда на каждую точку тратится не менее секунды, т.к. в 3D-задаче число точек возрастет в квадрате (всевозможные комбинации шагов обоих углов). А в этом случае гораздо проще искать углы последовательно - сначала найти один угол (тета), а затем, зафиксировав его, найти второй угол (пси). Такая процедура поиска была бы лишь вдвое продолжительнее, чем в 2D-задаче.

Ага.. так вот я о чём... результирующий вектор в 3D задаче решаем как двойные пифагоровы штаны в ДПСК либо как-то ещё если кому-то ближе другая система включая полярную. Имея три ортогональных датчика нет нужды сканировать по улам - каждый датчик пролучает свою проекцию - дальше нет проблем востановить вектор по проекциям. Даже если направление потока трепыхается в ортогональных датчиках а скорость не меняется то корень квадратный из суммы квадратов не меняется,двугое дело откуда он дует? Ведь проекции по барабану в каком направлении дует в прямом или обратном .Вчера сносил свой прибор под землю - 400метров скалы поделии показания в 2,5 - 3 раза, как я и предполагал. Очень приятно что-то полагать а потом убеждаться что ты прав Андрей насколько я понимаю занят поисками глобального эфирного ветра. Для этого ему хорошо бы оказаться на высоте не менее 5000 метров над уровнем моря там опыт с поворачиванием датчика будет более нагляден Мне более интересна эфирная суета вокруг моего носа.А потому требуется более тонкий аппарат интерпретации данных. Попытки вовлечь Вас в более продвинутые кусты упираются в решения прямоугольных треугольников.Но есть ещё информативный канал не удостоеный вниманием...я его подбрасываю - подбрасываю а никто не клюёт на наживку Ксения ! попробую Вас напрячь тоже. Вот вопрос .. можно ли отследить направление (пространственное.. вектор тяги так скажем для наглядности) процесса по статистическим данным (вот их то мы и имеет в чистом виде и ничего более).

Ответ : ДА!!! но как?

P.S. Наверно нужно дать подсказку ибо когда-то сам у добрых геохимиков узнал. Они в отличии геологов ,кои ищут, - предсказывают . Походили недалеко от кассы пособирали нужные им признаки ,определили их количество, определили куда они растут и убывают ,а потом на карте нарисовали прямые линии и в места пересечения отправили геологов кои подтвердили их предсказания

Изменено 5 ноября, 2013 пользователем laryc

[Andy1744]

Ага.. так вот я о чём... результирующий вектор в 3D задаче решаем как двойные пифагоровы штаны в ДПСК либо как-то ещё если кому-то ближе другая система включая полярную. Имея три ортогональных датчика нет нужды сканировать по улам - каждый датчик пролучает свою проекцию - дальше нет проблем востановить вектор по проекциям. Даже если направление потока трепыхается в ортогональных датчиках а скорость не меняется то корень квадратный из суммы квадратов не меняется,двугое дело откуда он дует? Ведь проекции по барабану в каком направлении дует в прямом или обратном .

не , laryc этот вариант ни кто и не оспаривает ,он как бы железно есть . но он не имеет "базы" в отличии от двух сенсоров включенных дифференциально , и этим предположительно не очень хорош. интерес представляет поиск решения (конструкции) отличной от варианта в лоб.

либо применить иную обработку отличную от пифагоровых штанов.

[Andy1744]

расскажи чего в шахте поделал.

[laryc]

либо применить иную обработку отличную от пифагоровых штанов.

так и я про то.. ладно чуть позже выложу если получится - нельзя мне просто так без проверки. нужно приладить ещё один графический блочок и отправлять в него статистику а она должна ложиться в распределение Гаусса в нормальное если ничего не дует и в логнормальное если дует .. а если это по трём координатам а потом в 3D графику (в LabView всё это есть надо пробовать) то должны отрисовываться наглядные "пупыри".... прибор насил в штольню (это горизонтальная шахта) температура там постоянная ветра нет (электричества тоже) на входе в штольню значения мотались в привычных пределах .. унёс в конец выработки - болтанка уменьшилась в 3 раза (отслеживал 100 значений долго там не поторчишь - газы без вентиляции душат) .. вернулся ко входу болтанка пришла в прежнее значение.

[Гость]

насчет штольни можно полюбопытствовать . в каких породах проходит ? че добывают ? есть инфа что нашими мероприятиями идеально в соляных шахтах заниматься.

[laryc]

осодочные в основном алевролиты..золото,серебро,сера

[Гость]

от Кондрашева инфа . он вроде бы СЕ установки на самозапите продает . у них в компании есть пару человек проводящих поиск "хлебных мест" для этих установок . Пробовали устанавливать в штольне в гранитном массиве , в ракушечнике (известняк) и в соляных шахтах . У них получилось что в шахтах можно снять меньшую полезную мощность относительно поверхности . Шкала видимо условная . нащет перещета на толщину пласта тоже не уверен . но то что есть . штольня в граните глубина 40 м уменьшает выход полезной мощности в 6 раз . в известняке в 4 , в соляном пласте в 2 раза. в соляном пласте вроде как выход на рабочий режим занимает меньше времени .

[Гость]

идея о датчиках . идея подсмотрена в методатчике скорости ветра . вцентре грибка там зона нагрева а по радиусу термопары растыканы в несколько рядов . по тому какая из термопар греется понимают направление ветра а по разнице температур -скорость ветра . в нашем варианте предлагаеться 3 ячейки (ячейка ето либо двурогая с замером разницы емкостей либо просто один коаксиальный конденсатор ) расположить в линию на расстоянии 1 метр одна от другой . ячеи все равно каламутят Эфир . есть предположение что если есть ветер в ефире то при ореинтации поперек потока ячеи будут не чуствовать друг друга и емкость во всех трех одинаковых будит одинаковая . при ореинтации поперек потока разница в ячеях будит максимальная и их взаимное влияние будит максимальным

[laryc]

идея о датчиках .

Кондуктометрический принцип...а что переносить он будет? ёмкость?...