Data interface between downhole sensor and SIU

Technical forum on ESP sensors. Discuss workshop bench testing, pressure and temperature calibration, vibration checks, and sensor-to-motor assembly
ALEngineer
Site Admin
User avatar
Posts: 530
Joined: Wed Mar 18, 2026 2:51 pm

Re: Data interface between downhole sensor and SIU

Post by ALEngineer »

Personally I think that right now IRZ downhole monitoring system (TMS) is ahead of the planet, a very convenient unit, absolutely zero glitches, unification, and so on. They walked a long road to that, worked hard, and got what they have. This is about downhole monitoring system (TMS) ONLY. The VSDs are decent, but not entirely convenient (the HMI), reliability is average, personal IMHO, I am not pushing it on anyone.

The bits about flux and imported precision parts made me laugh! :) The flux topic has been studied inside and out! Parts - do not make my horseshoes laugh, China makes anything and could not care less about the USA's opinion.

As for pressure and temperature to thousandths, that is of course madness, but tenths are VERY convenient when you are not sloppy and you understand what the VSD is writing at that moment. In the first few hours of run you can build fairly accurate forecasts and track the "health" and performance of the system as a whole. I remember times (not that long ago) when pressure was polled once every 20 minutes and with no tenths - what is that downhole monitoring system (TMS) even for?
Original reply
Лично мое мнение, что на данный момент ТМС ИРЗ впереди планеты всей, очень удобный блок, абсолютный ноль глюков, унификация и т.п. Они долго к этому шли, активно работали, и получили то, что имеют. Это касается ТОЛЬКО ТМС. СУ нормальные, но не совсем удобные (интерфейс), надежность средняя, лично мое имхо, ни кому не навязываю.
Насчет флюса и импортных прецизионных деталей позабавили! :) Тема флюсов изучена вдоль и поперек! Детали, не смешите мои подковы, Китай производит все что угодно и плевать он хотел на мнение США.
Насчет давления и температуры до тысячных, это конечно маразм, но десятые это ОЧЕНЬ удобно, когда ты не разгильдяй и понимаешь, что в данный момент тебе пишет станция, можно за первые несколько часов работы, строить довольно точные прогнозы и отслеживать "здоровье" и производительность системы в целом. Помню времена (не такие давние), кода опрос по давлению происходил раз в 20 минут и без десяток, нафик вообще такой ТМС?
udar17
User avatar
Posts: 27
Joined: Thu Jan 31, 2019 1:50 am

Re: Data interface between downhole sensor and SIU

Post by udar17 »

You can laugh at fluxes as much as you like, poke soldering irons into telemetry, and so on :) Your right.

Glitches of the most reliable IRZ downhole monitoring system (TMS) that they will never fix:

Loss of link on motor start

Loss of link when running PMMs at certain frequencies

Insulation-resistance monitoring

Now another operating quirk has been added - dropouts on RS-485.

And today they told us a brilliant IRZ marketing move :) To raise reliability they duplicated the electronics in the downhole part of the downhole monitoring system (TMS)!!! Price accordingly also doubled :) Reliability is probably in real trouble.
Original reply
Можете сколько угодно смеяться над флюсами, тыкать паяльниками в телеметрию и т.д :) Ваше право.
Про глюки самой надёжной ТМС ИРЗ которые они никогда не решат:
Потеря связи на запуске двигателя
Потеря связи при работе с вентильными двигателями на определённых частотах
Контроль сопротивления изоляции
Теперь ещё добавилась особенность в работе - пропадание связи по RS485.
А ещё сегодня рассказали гениальный маркетинговый ход ИРЗ :) Для повышения надёжности задублировали электронику в погружной части ТМС!!! Цена соответственно тоже двойная :) Вероятно с надёжностью совсем беда.
kolt86
User avatar
Posts: 15
Joined: Mon Feb 04, 2019 3:11 am

Re: Data interface between downhole sensor and SIU

Post by kolt86 »

I captured an IRZ-2 log but I do not understand what to do with it.

Frame 1 at the bottom, frame 2 above

Please help me figure it out.
IRZ-2-frame-1.png
IRZ-2-frame-2.png
Original reply
Снял лог ИРЗ-2 но что с ним делать не понимаю.

внизу кадр1 выше кадр2


Помогите разобратся.
IRZ-2-frame-1.png
IRZ-2-frame-2.png
You do not have the required permissions to view the files attached to this post.
TMSnick70
User avatar
Posts: 73
Joined: Wed Jan 02, 2019 11:41 am

Re: Data interface between downhole sensor and SIU

Post by TMSnick70 »

Vasiliy writes: I captured an IRZ-2 log but I do not understand what to do with it.

Familiar pictures, and even the digits. I think the first three frames are different. I only looked for half a day, so I did not really have time to study it. Counter-question: what do you need this for? I ask because operations usually do not need the analyzer signal.
Original reply
Василий пишет. Снял лог ИРЗ-2 но что с ним делать не понимаю.

Знакомые картинки, и даже цифирьки. Там по моему первые три кадра разные. Смотрел всего пол дня, поэтому рассмотреть толком не успел. Встречный вопрос. Вам это для чего? Спрашиваю потому-что для эксплуатации сигнал с анализатора обычно не нужен.
kolt86
User avatar
Posts: 15
Joined: Mon Feb 04, 2019 3:11 am

Re: Data interface between downhole sensor and SIU

Post by kolt86 »

I am building a multi-brand simulator.

Manchester protocol. The first five bits are present in every frame and most likely sync the receiver. The next 8 bits are the frame number. After that nothing is readable - looks like it is calculated by a formula. At the end the check should be 4, 8, or 16 bits.
Original reply
мультимарочный имитатор собираю
Протокол манчестер. Первые пять бит присутствуют в каждом кадре и скорее всего синхронизирует приемник. Следующие 8 бит номер кадра. Но дальше ничего не разобрать похоже что через формулу расчитывается. В конце контролька должна быть 4 , 8 или 16 бит.
TMSnick70
User avatar
Posts: 73
Joined: Wed Jan 02, 2019 11:41 am

Re: Data interface between downhole sensor and SIU

Post by TMSnick70 »

Unlikely there are any formulas. I would look at this. The first bits. The analyzer does not capture them. I had the same thing. If the analyzer did capture them, the numbers would be completely different. Though maybe that is the wrong direction...

Post more different pictures (with readings). Ideally with max and zero pressure readings (in turn, one arm of the pressure sensor to the housing) and motor temperature (open and short on the temperature sensor). Separately. And if you can, files for Saleae.
Original reply
Вряд ли там есть какие-то формулы. Я бы вот на что обратил внимание. Первые биты. Анализатор их не захватывает. У меня было то же самое. А вот если бы анализатор захватывал, то числа были бы совсем другие. Хотя может это и ошибочное направление…
Выкладывайте больше разных картинок (с показаниями). Желательно с максимальными и нулевыми показаниями давления (поочерёдно одно плечо датчика давления на корпус) и температуры двигателя (обрыв и к.з. термодатчика). По отдельности. И если есть возможность файлы для Saleae.
kolt86
User avatar
Posts: 15
Joined: Mon Feb 04, 2019 3:11 am

Re: Data interface between downhole sensor and SIU

Post by kolt86 »

I dropped the first bits myself because they carry no information and are present in every frame. I am studying the Transfer protocol now and still cannot figure out how the received data are converted into the values output from the SIU (surface interface unit, TMS). Put simply, if you know the conversion algorithm you can simulate any data for display.


Transfer-protocol.pdf
Transfer-protocol_2.pdf
Original reply
Первые биты я сам исключил так как ни какой информации не несут и присутствуют во всех кадрах. Сейчас изучаю протокол трансфер и пока не могу разобратся как полученные данные конвертируются в значения вывода из наземного блока ТМС. Проше говоря зная алгоритм конвертации можно имитировать любые данные для вывода.

https://www.youtube.com/watch?v=EdFR7FG5-2s
Transfer-protocol.pdf
Transfer-protocol_2.pdf
You do not have the required permissions to view the files attached to this post.
ALEngineer
Site Admin
User avatar
Posts: 530
Joined: Wed Mar 18, 2026 2:51 pm

Re: Data interface between downhole sensor and SIU

Post by ALEngineer »

There were server problems; after service was restored, the last post in this thread was deleted. Restoring the text:

From user Ildar:

From what is written it is not clear what exactly you cannot figure out. You write: "I cannot figure out how the received data (from what?) are converted (where?) into the values output from the SIU (TMS)". Ask the question more precisely. Transfer, in general, is described in detail. What is not spelled out is the frame transfer order. Right now, right after power-up, frames are sent in turn (frame-type field) - 1st (13 bytes), 2nd (13 bytes), 128th.....128th (17 bytes).
Original reply
На сервере были замечены неполадки, после восстановления работоспособности, удалилось последнее сообщение из этой ветки, восстанавливаю текст сообщения:
От пользователя Ильдар, сообщение:
Из того, что написано не понятно, в чём именно не получается разобраться. Вы пишите: «не могу разобраться как полученные данные (от чего?) конвертируются (где?) в значения вывода из наземного блока ТМС». Ставьте вопрос корректнее. Трансфер, в общем-то, подробно описан. Из того что не расписано – это порядок передачи кадров. На данный момент, сразу после включения поочерёдно передаются кадры (поле тип кадра) - 1-й(13 байт), 2-й(13 байт), 128-й…..128-й(17 байт).
TMSnick70
User avatar
Posts: 73
Joined: Wed Jan 02, 2019 11:41 am

Re: Data interface between downhole sensor and SIU

Post by TMSnick70 »

Good day all. Vasiliy wrote: "I captured an IRZ-2 log but I do not understand what to do with it."

I looked at the IRZ-2 signal. Here is what came out.

1. The first frame (screen 1) is empty (sync). Marker line A1 is the start of this and all following frames.

2. Then comes frame zero (screen 2). I have not unpacked this yet. Looks like constant data.

3. Next is the first frame (screen 3). All frames are ten bytes + 5 check bits. 1st byte is the frame number (1). 2nd byte is a constant - two. That is a kind of frame-type ID. Bytes 3, 4 and 5, 6 are temperature. Byte 4 is the high byte, so temperature is calculated as: multiply byte 4 by 256 and add byte 3. Divide the result by 100. That is the temperature. In this case (8 x 256 + 130) / 100 = 21.78 C. Same for bytes 5 and 6 - (7 x 256 + 102) / 100 = 18.94 C.

Bytes 7-8 and 9-10 carry pressure - reservoir and oil. Calculated the same way. In this case (1 x 256 + 33) / 100 = 2.89.

4. Second frame (screen 4). 1st byte - frame number (2). 2nd - constant 65. Bytes 3 and 4 temperature. Bytes 5, 6, 7, 8 and 9, 10 - vibration on X, Y, Z respectively. Calculated the same as above.

Then frames with IDs 2 and 65 simply alternate (with the frame number changing).

5. After the 10th byte of each frame there are five bits - a checksum. I assume this is CRC-5. There are three standard CRC-5 versions. Which version is used I have not been able to pin down on a first pass.

Useful link https://leventozturk.com/engineering/crc/
IRZ-2-protocol-screenshots.rar
Original reply
Доброго всем дня. Vasiliy писал: «Снял лог ИРЗ-2 но что с ним делать не понимаю.».
Посмотрел сигнал ИРЗ-2. И вот что получилось.
1. Первый кадр (скрин1) – пустой (синхронизация). Маркерная линия А1 - это начало этого и всех последующих кадров.

2. Далее идёт нулевой кадр (скрин2). Тут пока не стал разбираться. Похоже на константные данные.

3. Следующий - первый кадр (скрин3). Все кадры по десять байт + 5 контрольных бит. 1-ый байт номер кадра(1). 2-й байт константа - двойка. Это типа идентификатор типа кадра. 3, 4 и 5, 6-й байты – температура. 4-й байт старший, поэтому значение температуры рассчитывается так – умножаем значение 4-го байта на 256 и прибавляем значение 3-го байта. То, что получилось, делим на 100. Это и есть температура. В данном случае (8 х 256 + 130) / 100 = 21,78 гр. Аналогично рассчитывается температура для 5 и 6-го байт - (7 х 256 + 102) / 100 = 18,94 гр.
В байтах 7-8 и 9-10 передаётся давление - пластовое и масла. Рассчитываются аналогично. В данном случае (1 х 256 + 33) / 100 = 2,89.

4. Второй кадр (скрин4). 1-й байт – номер кадра(2). 2-й – константа 65. 3 и 4-й температура. 5, 6-й, 7, 8-й и 9, 10-й байты – вибрация по осям X, Y, Z соответственно. Рассчитываются аналогично предыдущему пункту.
Далее кадры с идентификаторами 2 и 65 просто чередуются (со сменой номера кадра).

5. После 10-го байта каждого кадра идут пять бит – контрольная сумма. Предполагаю, что это CRC-5. Стандартных версий CRC-5 три. Какая именно версия использована мне пока с наскоку определить не удалось.
Полезная ссылка https://leventozturk.com/engineering/crc/
IRZ-2-protocol-screenshots.rar
You do not have the required permissions to view the files attached to this post.
TMSnick70
User avatar
Posts: 73
Joined: Wed Jan 02, 2019 11:41 am

Re: Data interface between downhole sensor and SIU

Post by TMSnick70 »

On the previous post. Point 5, the CRC-5 guess was wrong. The checksum is 4 bits. The fifth bit (far right) is always 0. It is computed as bitwise XOR from the first nibble through the last (20th). Checked on a calculator, not yet in hardware. The Elekton developer was right after all about a simple checksum.
Original reply
По предыдущему посту. В пункте 5 предположение по CRC5 оказалось неверным. Контрольная сумма состоит из 4-х бит. Пятый бит (крайний правый) всегда равен 0. Вычисляется побитовой xor начиная с первого полубайта до последнего (20-го). Проверено на калькуляторе, в железе пока не проверял. Прав был-таки Электоновский разработчик на счёт простой контрольной суммы.