То става така, ама ако вкарате ГУИ-то да се генерира в дисплея ще олекне много откъм изисквания за обем на данни и комуникация. Е, повечко работа за програмистите, ама нали и ние трябва да ядем хляб. Що не се допитваш до старите пушки тука как се правят тези неща

Еее не баш, ако гуи се генерира в дисплея това означава да му стриймваме данните от сензора при същата латентност. Да компресирани сигурно ще са по-малко сравнено с видео стрийм, но разликата няма да е голяма спрямо компресирано видео. Сега ако сравняваме с битрейта за hdmi то сравнение няма, но и затова гледам конкретни решения.
Въпросът е че от страна на сензора SBC си трябва, дали ще го наречем SBC или нещо друго ...трябва да поеме целия стрийм от сензора и да го докара до нещо годно за предаване по безжичен път. Ако генерира и GUI дисплея може да е съвсем тъп, ако предава само компресирани данни и в дисплея трябва да има нещо умно, а и перформващо.
Там винаги има вариант за стандартно у-во, но този вариант им някои недостатъци, например наличност. Утре сменят една буква в модела и трябва пак да минаваш през сертификации.

абе що не вкарате някакво безжично RS485, Profibus и т.н. или UWB или DECT NR, и верно в дисплея да си правите GUI-та и т.н.
А тънка оптика ще ви реши всичките проблеми - те разните медицински работници не мърдат много - една холокаска и си свиркате.

Е то моето беше спекулация базирана на значително по малко данни идващи от сензора отколкото е видео стрийма по хдми. То не, че пак не става де - всичката обработка на данни я правиш на Джетсона и след това изкарваш примерно през WiFi някакъв веб интерфейс т.е. разчиташ на нещо стандартно и изтествано в практиката. Това с безжичния ХДМИ ми идва прекалено екзотично и неясно колко стабилно във времето.

Отделно когато УИ-то ти е на отделна машина и имаш някакъв собствен протокол за комуникация между нея и тази на която събираш данните то тогава можеш да кешираш, де препредаваш при грешка и т.н. но съобразено с конкретния случай. При видеото всичко е на цели кадри, няма интелигенция освен да замръзне някой кадър ако следващия се е омазал - или направо да омаже екрана - което не винаги е приемливо. Абе специфики, специфики ... няма как да не разтягаме локуми като не е ясно какво и защо ти трябва да се направи. От друга страна ти си си наясно и щом си се насочил към безжично ХДМИ си имаш причините, така че ...

Аз като един прост и неразбиращ човек веднага си задавам няколко въпроса:
1. Аджеба що за сензор може да даде толкоз гигабити данни
2. На кой му трябва такава малка латентност. Ако го гледа човек, то човека реагира бавно. Ако е видео поток - ти гарантирано ще загубиш доста време във фрейм буфери. Поне 2-3-4 фрейма по целия поток. Докато се генерира, докато се компресира, докато се предаде, докато се декомпресира и докато се покаже. Може и над 5 фрейма да надхвърлиш. При 60фпс в най-добрия случай са ти 120-150-200 милисекунди само от предаването на видеото.
Та пак опираме до въпрос 1 - дали не е по добре да се пусне серийно роу данни от сензора а вече в приемната страна да правиш обработките и т.н.
А и рентгенови сензори - освен да е ЦЦД за друго не се сещам но там скоростите са бавни. А и сцинтилатори с фотоумножители ... пак няма кой знае колко данни. Цялата работа не се вързва.

И аз питах за скоростта, явно е нещо секретно

Ами това конкретно е TFT панел 1536х1536, в 1/1 режим 35 fps, 16bit а в 2х2 е 300fps сметката може да се направи лесно. Панела е с 1/2,5 Gb интерфейс.
Целта е режим 2х2 при 60fps, което е около 600Mbps необработени данни които не са във стандартен формат, т.е. това не е стрийм.
Именно защото има време и за обработка латентността на канала трябва да е ниска, залагаме грубо 10ms за обработка и рендиране на фрейм. Рендирането е доста определено, 1-4мс, обработката едва ли ще е по-сложно от компресия, т.е още 4-5, като цяло имаме 10ms.
Искам HDMI екстемдери тъй като там латентността е малка, там няма компресии и подобни, стриймва се HDMI нативно, в зависимост от производителите има между 1-20 ms. С 20 обаче отиваме на реално визуализирани 30 fps, което е лимита на заданието.
Да човешкото око е бавно, но някога опитвал ли си се да работиш гледайки видео с голяма латентност ? Това е продукт който се използва в реално време, по време на операцията.
Груби няма как да се използва оптика, сензора трябва да е изцяло безжичен.

Не, че нещо ама ако тоя сензор го набримчиш на пълния фреймрейт и очакваш да гледаш неща - пациента няма да живее дълго след операцията. Ще си го изпържил от рентгеновите лъчи преди да се е събудил.
А и пациента е заспал и не мърда много много. За никъде не се бърза освен ако не правиш нещо на биещо сърце, но и на сърдечните операции фреймрейта е нисък. Там борбата е много чувствително сензори и слабо излъчване с цел малка доза. При ангиография максимума е 15фпс като слизат на 7.5 и 3.8 фпс. А там си бъркат с катетри в сърцето за да поставят стентове и клапи. А и да постигнеш високите фреймрейти трябва да вдигнеш много енергията на лъча. Поне 130-140 киловолта. След такова изследване пациента от операционната се мести направо в онкологията.

С колко ще го пържат не е моя работа, има си хора които да го мислят, как точно ще се използва е още по-малко моя работа, има си fda и куп още организации които тестват, решават и преценяват дали е годно или не, дали е опасно и т.н. има си системни инженери, консултанти и кой ли още не. Аз имам зададени параметри и трябва да дам решение. Не мога да дам повече детайли, нолично аз не съм толкова загрижен за здравето на пациента в случая, имам други притеснения, изложил съм ги и до там. На мен ми се плаща да реша конкретен проблем, и самото предаване на изображението е един от малките проблеми, има доста по-сериозни но за момента се справяме
Убеден съм, че ако се наложи ще успеем да докараме малка латентност и през стандартно WiFi и видео стрийм, но това както писах е план Б който води до други усложнения.

Поизяснява се ... то ако трябва да предаваш само това което идва от ЦЦД матрицата като видео стрийм наистина разликата с безжичен ХДМИ е преди всичко протокола за комуникация. Т.е. ако не се очаква да има някакъв обратен поток с команди и т.н. а е само за гледане.

И въпреки това видео стрийма има едно предимство - с времето се появяват все по добри методи за компресия които хем ти намалят битрейта хем ти увеличават качеството - като h.265 или още по новия h.266. При читав хардуер латентноста за енкодване/декодване на видеото би влезла в допуските. А безжичното ХДМИ е квото е - най вероятно и то си има някаква компресия но за теб това е прозрачно и не ти омотва нещата - но не ти и помага с времето. Аз лично бих заложил на видео стрийм с h.265, че h.266 още е прекалено нов и няма навлизане на пазара т.е. достъпен хардуер и софтуер за енкодване/декодване.

Edit: Jetson енкодва с доста прилична скорост h.265 ... не съм го мерил колко го докарва като латентност защото ми трябваше за статични кадри от много камери от различни гледни точки да ги енкодна от 1гб jpegs до 50мб .mkv за да го качваме по бързо в облака. Ама на нас целта ни беше някой като го сканираме до минута да си получи на телефона мерките на тялото и коя дреха му става. Твоето е друго. Ама пък си с една камера т.е. ще има много добра компресия защото разликите между кадрите са сравнително малки и алгоритъма се справя.

За компресия компресира, и без да му напъваш кудите, само с хардуерния по спомен и до 200 може да отиде според резолюцията. Въпросът е че ние искаме да избягаме от стандартен WiFi, за да си улесним малко живота с киберсекюрити одита, а и както писах вече има цял стандарт за коекзистънс и колкото по-малко го засягаме толкова по добре.
Също така идеята да имаме тъп дисплей е доста примамлива. Иначе ако е за компресия на данните там подлежат на сериозна компресия, особенно обработените данни.
Не знам ти кой джетсън си пробвал, старото нано го спират, сега има орин нано, много овъркил но е най-малкото им, има купища ядра, и не е проблем и компресирано видео да стриймваме, от към перформънс нямам никакви притеснения.
В този случай обаче за да се гарантира латент ост трябва да се елиминират трети у-ва, трябва да е точйа-точка, което може да доведе до някои други драми, особенно с it отделите и въпросните стандарти за коекзистънс.

С малките Джетсони не съм работил. Имаха някакъв яд с хардуерните енкодери за х265 - май можеше само един пайплайн да пуснеш докато на големите батковци можеше два ли три ли вече не ги помня и аз т.е. доста по пъргаво се компресира (поне на теория де).

А ти като ги компресираш данните дали ще ги претакаш по ВиФи или по нещо друго не е чак толкова важно и търпи нагласяне според нуждите ти. Това което не ми харесва на това безжично ХДМИ е, че е тъп еднопосочен протокол, който не е ясно и колко компресира. А като няма обратна връзка не е ясно дали въобще се е показало нещо на монитора докато като е някакъв малко по умен протокол може да отработиш евентуално пропадана - там да препредадеш или да покажеше, че има проблем и т.н.

Да не говорим, че модерните ХДМИ монитори и тТВ-та които би ползвал на практика си имат и процесор и ОС който често позволява качване на апп. Отделно има достатъчно мегдан за лавиране да разделиш УИ-то от събирането на данни. Особено ако е андроитски тв или таблет. Тогава на практика си решаваш проблема с един андроидски апп (разбира се си вкарваш други проблеми ама това е друга бира).

Абе не е като да нямаш варианти. Ако това ХДМИ работи читаво действай с него - хубавото е, че не иска да се пише софтуер за второ устройство. Че програмистите хем сме скъпи, хем не е като да има излишък от такива дето вършат работа а не гледат само да ти вземат парите ...

Ами дисплея няма да е нищо стандартно, живота на стандартните е твърде кратък за такова приложение. За стандартен таблет и дума не може да става, модела му ще го сменят преди да сме успели да сертифицираме изделието. Мож3 да е някой индустриален дисплей но и там има подобен риск макар и доста по-малък. Дисплеят най-вероятно ще е изцяло,къстъм, там има почти пълен контрол, риск има само ако се спре матрица. Аз работя основно с AUO, там има добра предвидимост, информират от далеч, и ако ще спират апок0й о може да се купят 500-1000-10000 според зависи какви са плановетв на клиента, една матрица с тоя размер е $60, и си стои нейде в корея, не е като да купиш същото количество таблети.

Абе за всеки случай помисли и за вариант да добавиш на матрицата още един Джетсън Нано за УИ, че ако не се получи с това безжично ХДМИ да си подготвен и за други варианти. Предполагам, че едва ли ще оскъпи кой знае колко а е хубаво да имаш резервен вариант.

Да това го мисля. За оскъпяването ...Nvidia мен ако питаш умишлено спира първото нано, 90 пари сигурно им се виждат малко, сега най-евтиният модул е почти по 3, $259 ...

Но аз точно заради сертификацията гледам тия трансмитери да са модули, щото другото днес го има -утре не.