Поиск фризов в видео сигнале

[pepelxl]

Какова общая концепция поиска неисправности при поиске помех в параллельном видео сигнале? Хотел попробовать вывести видео на штатный монитор автомобиля. видео идёт от магнитолы на дисплей(условно) по двум проводам. в провод, видео загоняется через серилизатор max9247.

выкинул магнитолу

взял max9247 и макетку под корпус.

на входе у неё rgb666 (CLK, DE, VSYNC, HSYNC).

припаялся к ней соплями на rpi.

Выставил в ней похожие тайминги как в оригинальной магнитоле.
получилось так:

dtparam=spi=off
dtparam=i2c_arm=off
dtoverlay=dpi18
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x7f025
framebuffer_width=800
framebuffer_height=480
hdmi_timings=800 0 20 20 212 480 0 13 2 31 0 0 0 60 0 33000000 6

получаю фризы после того как встречается белый цвет в изображении. например, весь белый текст полосит по горизонтали, а серый нет. Логично предположить, что белый это всё в 1, и может быть просадка где угодно. На макетке распаял все конденсаторы по питанию как по мурзилке.

Фризить может как в параллельном, так и последовательном. Как отыскать проблему? В параллельном могу подоткнуть осла, а вот в последовательном такого прибора я не найду. Настройки по таймингам я пробовал крутить, ничего не меняется, кроме частоты, занизить её нельзя из-за десериализатора. Но мне казалось, что если это наводки, то шевеление проводов в пространстве и прочее, должно хоть как-то влиять на помехи, а тут вообще никакого эффекта.

Может я что-то упускаю из вида, и проблема решается программно?

[Дим-мычъ]

@pepelxl

видео идёт от магнитолы на дисплей(условно) по двум проводам. в провод, видео загоняется через серилизатор max9247.

Может, сначала, без “серилизатора” попробовать.? Т.е. на входе сигнал норм?

[pepelxl]

это не так просто, надо разобрать монитор, а потом искать порт под шлейф, паять.

Я тут слона и не приметил

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

небольшая программа, заполняет FB монотонным цветом, полоса стоит колом.

import time
import struct

# Параметры экрана
WIDTH = 800
HEIGHT = 480
PIXEL_COUNT = WIDTH * HEIGHT

# Цвета в формате BGRA (B, G, R, A)
COLORS = {
    "blue":   (255, 0,   0,   255),  # синий
    "green":  (0,   255, 0,   255),  # зелёный
    "red":    (0,   0,   255, 255),  # красный
    "white":  (255, 255, 255, 255),  # белый
}

def fill_color(color):
    """Заливает экран указанным цветом."""
    b, g, r, a = color
    color_bytes = struct.pack('BBBB', b, g, r, a)
    with open('/dev/fb0', 'wb') as fb:
        fb.write(color_bytes * PIXEL_COUNT)

try:
    print("Начинаем смену цветов: синий, зелёный, красный, белый (каждые 3 секунды).")
    print("Нажмите Ctrl+C для остановки.")
    while True:
        for name, color in COLORS.items():
            print(f"Заливка: {name}")
            fill_color(color)
            time.sleep(3)
except KeyboardInterrupt:
    print("\nПрограмма остановлена.")

И вот тут я вообще вступоре.

[Дим-мычъ]

@pepelxl

Но потом подключил оригинальную магнитолу и увидел, что полосы то нет.

Ну так, здесь и копать. Искать, чём отличие дисплеев, схемы, и.т.д

[pepelxl]

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

сейчас долез до потрохов монитора. матрица LCD Sony GCX156AKM-E.

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

задающий генератор на приёмнике:

32 956 906 Гц ≈ 32,957 МГц
Отклонение от 33 МГц: --43 094 Гц (или --0,1306%, --1306 ppm)

со стороны оригинальной магнитолы:

32 999 082 Гц ≈ 32,999 МГц
Это на ~918 Гц ниже ровно 33 МГц (отклонение --0,0028% или --28 ppm).

со стороны rpi:

32 998 075 Гц ≈ 32,998 МГц
Это на 1 925 Гц ниже 33 МГц (отклонение --0,00583% или --58 ppm)

в мурзилке на max указано отклонение не более 2% для синхронизации:

Для частоты 33 МГц отклонение в ±2% составляет:
33 000 000 × 0,02 = 660 000 Гц = 660 кГц = 0,66 МГц
Таким образом, диапазон допустимых значений:
Нижняя граница: 33 МГц – 660 кГц = 32,34 МГц
Верхняя граница: 33 МГц + 660 кГц = 33,66 МГц

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

Я так понимаю что по этому можно судить, что проблема не со стороны тунеля? тогда вообще не понимаю где засада.

[vvb333007]

@pepelxl

Выставил в ней похожие тайминги как в оригинальной магнитоле.

А в оригинальной магнитоле тоже провода по которым сигнал идет такой же мочалкой? Может, CLK поиграться, уменьшить. Ставлю на то, что если проваода сделать нормальными то пропадет помеха.

[pepelxl]

Нет конечно. Суть в том, что как раз clk трогать нельзя, он не может отличаться от приёмника более чем на 2%. Иначе приёмник не синхронизируется.

[pepelxl]

От мочалки с крестиком там особо не избавишься. Порт использует по порядку gpio0-21. А они разбросаны в перекрёстном порядке на разъёме. Вроде как можно некоторые переназначить, но не для того что бы выстроить в ряд, а для высвобождения пинов для других интерфейсов.

[Дим-мычъ]

@pepelxl

hdmi_timings=800 0 20 20 212 480 0 13 2 31 0 0 0 60 0 33000000 6

Может тогда здесь косяк?

[pepelxl]

Есть такое ощущение. Datasheet на панель не нашел в открытом доступе.

Поменял на

hdmi_timings=800 0 20 20 212 480 0 13 2 30 0 0 0 60 0 33000000 6 и верхняя полоска исчезла. Но иногда всё равно проскакивает, когда в изображении сбоит много строк.

Но даже если тайминги не верны, то само изображение как то не понятно ведёт себя. Проблема начинается в произвольном месте строки(там где преобладает белый) и до конца строки. То есть линии hsync vsync не участвуют в этот момент времени. То есть идут линии пикселя и clk. Если бы была наводка на h,v то тогда бы съехала следующая строка. Кроме того чтобы max передал h,v ему ещё надо подать сигнал DE. По сути двойная защита. Если предположить что поплыл джиттер clk, то просто съехал бы пиксель, тоже не вяжется.

[Дим-мычъ]

@pepelxl

изображение как то не понятно ведёт себя

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

Из описания HDMI:

• При превышении безопасной длины кабеля появляются задержки, падает сила сигнала и могут возникать артефакты.

[pepelxl]

ещё раз перепроверил по логическому анализатору с оригинальной магнитолой, всё совподает, кадр 552300 тактов.

[Дим-мычъ]

@pepelxl

на входе у неё rgb666

@pepelxl

dpi_output_format=0x7f025

Ввёл в гугл - выдало , что это RGB888

[pepelxl]

Детальная расшифровка битов 0x7F025

Группа битов	Биты в 0x7F025	Параметр	Значение
FFFF (биты 0-3)	0101 (5)	Формат цвета (output_format)	DPI_OUTPUT_FORMAT_18BIT_666_CFG1. Это означает, что для передачи цвета используется 18 бит (по 6 бит на каждый канал R, G, B), задействуя определенный набор GPIO (GPIO 0-21).
OOOO (биты 4-7)	0010 (2)	Порядок цветов RGB (rgb_order)	DPI_RGB_ORDER_BGR. Порядок битов цвета инвертирован (Blue-Green-Red вместо Red-Green-Blue).
M (бит 8)	0	Режим Output Enable	DPI_OUTPUT_ENABLE_MODE_DATA_VALID. Сигнал DE (Data Enable) активен только во время передачи данных.
P (бит 9)	0	Инвертировать тактовый сигнал	Сигнал не инвертирован. Данные на выходе меняются по переднему фронту (rising edge) тактового сигнала.
Биты 10, 11, 15	0	Зарезервированы	Не используются.
H (бит 12)	1	Отключить H-Sync	HSYNC отключен. Сигнал горизонтальной синхронизации не генерируется.
V (бит 13)	1	Отключить V-Sync	VSYNC отключен. Сигнал вертикальной синхронизации не генерируется.
E (бит 14)	1	Отключить Output Enable	Output Enable отключен. Этот сигнал также не выводится.
h (бит 16)	1	Полярность H-Sync	Инвертирована.
v (бит 17)	1	Полярность V-Sync	Инвертирована.
e (бит 18)	1	Полярность Output Enable	Инвертирована.
Бит 19	0	Зарезервирован	Не используется.
h (бит 20)	1	Фаза H-Sync	DPI_PHASE_NEGEDGE. Сигнал HSYNC (если используется) будет меняться по заднему фронту (falling edge) тактового сигнала.
v (бит 21)	1	Фаза V-Sync	DPI_PHASE_NEGEDGE. Аналогично для VSYNC.
e (бит 22)	1	Фаза Output Enable	DPI_PHASE_NEGEDGE. Аналогично для DE.
Биты 23-31	0	Зарезервированы	Не используются.

Вроде так.
Я могу прикрепить файлы от анализатора если кто готов посмотреть. может я смотрю в книгу и вижу фигу

[Дим-мычъ]

@Дим-мычъ

@pepelxl

pi_output_format=0x7f025

Ввёл в гугл - выдало , что это RGB888

Ввёл ещё раз - выдало уже что RGB666. Так что, ложная тревога.

[MMM]

@pepelxl

Вроде так.

Показанная вами табличка не соответствует значению 0x7F025
Обратите внимание, что старший ненулевой бит в таблице это бит 22, то есть это шестой нибл. А у вас их всего пять.

Если я не обсчитался в битах, значение по таблице должно быть 0x777025

[pepelxl]

спасибо что откликнулись. Нет, старшие опущены. фазы(биты 20,21,22). по сути можно записать как0x0007F025. точнее у вас правильная мысль, но я уже пробовал жонглировать ими. по факту лучший вариант, это пока 7F225. здесь перевёрнуты все управляющие сигналы включая clk, что соответствует оригинальному виду сигнала из магнитолы. условно если я запишу 77F225, то я получаю картинку более похожую на 7F025, что логично.

Но как не жонглируя от этого я избавится не могу:

[Дим-мычъ]

@pepelxl

Но как не жонглируя от этого я избавится не могу:

ИМХО, надо смотреть схему(которую вы не выложили).
Какой кабель используете?
И, согласен с @vvb333007 , надо избавиться от кучи проводов, развести печатные платы.

[pepelxl]

мужики, спасибо что откликнулись. проблема была дейcтвительно в наводках. питание взял одной точкой с rpi. а на max питание 6 точек. в результате припаял все 6 точек массы на 6 точек колодки rpi и проблема исчезла.

[MMM]

Как то даже смешно