Камеры ZWO ASI

[Ihtamnet II]

Я сейчас вынужденно посадил и основную 1600 и гидирующую камеру QHY 5 L-II на USB 2.0  - никаких замедлений в закачке кадров основной камеры или нарушения гидирования не заметил.

Я уже писал где-то выше - после съемочной сессии начал снимать флэты и обнаружил брак. Висела 120ММ в режиме VidoeDS на гиде и 178ММ на съемке. USB 2.0 Брак прекратился только после отключения камеры гида. Проявлялся в неравномерном освещении разных частей флэта. Экспозиции были около секунды. Игры и USB trafic не помогли.

[Alex1958]

Я сейчас вынужденно посадил и основную 1600 и гидирующую камеру QHY 5 L-II на USB 2.0  - никаких замедлений в закачке кадров основной камеры или нарушения гидирования не заметил.

Я уже писал где-то выше - после съемочной сессии начал снимать флэты и обнаружил брак. Висела 120ММ в режиме VidoeDS на гиде и 178ММ на съемке. USB 2.0 Брак прекратился только после отключения камеры гида. Проявлялся в неравномерном освещении разных частей флэта. Экспозиции были около секунды. Игры и USB trafic не помогли.

Желательно бы посмотреть на испорченный флэт . Проблемы взаимодействия двух и более камер ZWO, вернее их драйверов, мне знакомы. Не могу заставить нормально работать "дайтоновскую" камеру-гид, аналог ZWO 120-ки и 1600-ю. "Тормоза" гида замучили.

[Ihtamnet II]

К сожалению, не мог предположить, что бракованные флэты могут понадобиться. Поэтому они сразу были удалены.
Выглядело это так - 20-30-40 и более процентов кадра (горизонтальная полоса сверху, по-моему) в случайном порядке были намного темнее остальной части. Были и нормальные.

[EvgeniyM]

Не стоит сильно грустить. Этот буфер ничего не даёт.

Все же дает. Его наличие позволяет исключить зависимость величины ampglow от значения usb traffic.

[Alex1958]

Не стоит сильно грустить. Этот буфер ничего не даёт.

Все же дает. Его наличие позволяет исключить зависимость величины ampglow от значения usb traffic.

Вы сами проверяли это на практике? Если  Вы ссылаетесь на ту ерунду, которую китаец пишет на своем сайте, то  нужно полностью её озвучивать.   ...На слабом железе, при использовании USB 2.0, буфер позволяет устранить "засветку" кадра, возникающую  при медленном считывании кадра. Особенно порадовала фраза "более равномерная скорость". Этот буфер, случаем, не увеличивает скорость порта USB 2.0 до 3-5 Гиг? Это был бы прорыв!
Если это было бы правдой, я, лично,  давно увидел бы разницу в кадрах, благо скачивал кадры и с помощью  целероновского баребона через порт USB 3.0 и порт 2.0. и с помощью ноута с процем I-7. Но нет у них различий, есть только разное время скачивания!

[EvgeniyM]

Да. Сразу оговорюсь, что у меня 163 камера, но в силу их схожести по сенсору и скорее всего схемно, думаю уместно говорить и в этой теме.
Обратил внимание, что калибровка темновыми с различными значениями USB traffic приводит к различным результатам, все остальные параметры одинаковые. Ниже технические кадры (пытался выставить положение сенсора): без калибровки, с USB traffic=10, и с USB traffic=60. Лайты делались с USB traffic=10. При съемке использовал SharpCap с его встроенным (directly) драйвером, который видимо не умеет работать с буфером, т.е. выбирал камеру в меню QHY. При выборе ASCOM драйвера в том же меню, но ниже, подобного эффекта не наблюдается при различных значениях USB traffic. Вчера еще раз проверил, результат тот же, дарки измерял в Максиме.
Кроме того заметил, что темновые отличаются друг от друга, сделанные на разных компьютерах, когда используется прямое управление в Шарпе, а не через ASCOM.

[Ihtamnet II]

А зачем вообще трогать USB traffic при съемке дипская? Ладно, при больших ФПС например выпадают или портятся кадры. А здесь зачем?

[EvgeniyM]

У меня при некоторых значениях USB traffic вообще не происходит загрузка кадров, либо останавливается, например, после загрузки первых 10-и. Индикатор висит и ничего не грузится, поэтому я подбирал оптимальное значение. Получилось в Максиме - 20, а в Шарпе - 10. Казус с засветкой усилителя обнаружился только в Шарпе без ASCOM, но как будет в камерах без буфера - трудно сказать, просто нужно это иметь ввиду, наверно.

[Alexandrid]

Да. Сразу оговорюсь, что у меня 163 камера, но в силу их схожести по сенсору и скорее всего схемно, думаю уместно говорить и в этой теме.
Обратил внимание, что калибровка темновыми с различными значениями USB traffic приводит к различным результатам, все остальные параметры одинаковые. Ниже технические кадры (пытался выставить положение сенсора): без калибровки, с USB traffic=10, и с USB traffic=60. Лайты делались с USB traffic=10. При съемке использовал SharpCap с его встроенным (directly) драйвером, который видимо не умеет работать с буфером, т.е. выбирал камеру в меню QHY. При выборе ASCOM драйвера в том же меню, но ниже, подобного эффекта не наблюдается при различных значениях USB traffic. Вчера еще раз проверил, результат тот же, дарки измерял в Максиме.
Кроме того заметил, что темновые отличаются друг от друга, сделанные на разных компьютерах, когда используется прямое управление в Шарпе, а не через ASCOM.

Не уместно её тут обсуждать, она только матрицей похожа, а обвязка и драйвера другие.

[EvgeniyM]

Суть от этого не изменится - с увеличением времени считывания увеличивается засветка, именно потому, что сенсор один и тот же. А так, да, можно перенести в тему QHY.

[mo]

Суть от этого не изменится - с увеличением времени считывания увеличивается засветка, именно потому, что сенсор один и тот же. А так, да, можно перенести в тему QHY.

То есть разное время считывания при разной занятости шины даёт разную засветку от усилителя с разной температурой... очень много неизвестных. Надеюсь, QHY хорошо решил эту проблему.

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

[Alex1958]

Давно этот вопрос обсасывался. Скорость обмена трафика с USB , естественно, сказывается на засветке кадров, этого никто и не отрицает.  Но я ещё раз повторюсь, что  буфер памяти никак не может влиять на эту скорость. Смею утверждать, что при прочих равных условиях, кадры с двух идентичных сенсоров, с буфером и без,  будут иметь одинаковую скорость скачивания (особенно на USB 3.0). Возможно, опять же, на стадии никем не доказанного предположения, что буфер памяти позволяет установить в драйвере скорость обмена с USB-шиной  выше, чем без буфера. И опять же, нужно проверять, как эта скорость повлияет на засветку кадра.

[EvgeniyM]

Буфер, как я понимаю, позволяет установить постоянную (более высокую?) скорость считывания от сенсора в этот буфер, чтобы нормализовать засветку, а дальше уже не важно какая скорость по шине USB, на засветку она не повлияет. В драйвере QHY есть окошко с галочкой - log буфера DDR, если галочку установить, откроется окошко, в котором показывается процесс наполнения и считывания из него. Заполнение до 32 МБ занимает три строчки, а считывание 6, если предположить, что периодичность записи в этот файлик одинаковая, то время записи вдвое короче. Картинку сейчас не могу выложить, не добрался еще до дома. Т.е. китаец постарался реализовать идею постоянства скорости записи в буфер, чтобы посторонние процессы не оказывали влияния, претендуя на канал USB, что и подхватили ZWO  последней версии PRO.

[Alex1958]

Буфер, как я понимаю, позволяет установить постоянную (более высокую?) скорость считывания от сенсора в этот буфер, чтобы нормализовать засветку, а дальше уже не важно какая скорость по шине USB, на засветку она не повлияет. В драйвере QHY есть окошко с галочкой - log буфера DDR, если галочку установить, откроется окошко, в котором показывается процесс наполнения и считывания из него. Заполнение до 32 МБ занимает три строчки, а считывание 6, если предположить, что периодичность записи в этот файлик одинаковая, то время записи вдвое короче. Картинку сейчас не могу выложить, не добрался еще до дома. Т.е. китаец постарался реализовать идею постоянства скорости записи в буфер, чтобы посторонние процессы не оказывали влияния, претендуя на канал USB, что и подхватили ZWO.

Да, это вполне допустимо. Но требует проверки на USB 2.0.  Если предположение верно, то кадры, скачанные на установленных  в драйвере скоростях 80 и, допустим 20, будут идентичны. Поэкспериментируйте, сделав пару десятков кадров секунд по 30.  А я на своей попробую, без буфера. Всё и выяснится...

[EvgeniyM]

Я вчера проделал этот эксперимент дважды и с буфером, используя ASCOM драйвер в программах Максим и ШарпКэп и без ASCOM  в ШарпКэп с его внутренним драйвером без поддержки буфера. Результат с буфером: все файлы с разными скоростями одинаковые (измерял Фиты в Максиме), а без буфера - разные, причем с разных компьютеров -разные даже с одинаковыми установками скоростей. Иначе я бы сюда не писал. Опыта в астрофото у меня не так много, поэтому решил поделиться казусом с засветкой.

[warbird]

Да. Сразу оговорюсь, что у меня 163 камера, но в силу их схожести по сенсору и скорее всего схемно, думаю уместно говорить и в этой теме.
Обратил внимание, что калибровка темновыми с различными значениями USB traffic приводит к различным результатам, все остальные параметры одинаковые. Ниже технические кадры (пытался выставить положение сенсора): без калибровки, с USB traffic=10, и с USB traffic=60. Лайты делались с USB traffic=10.

Пользователи камеры аси1600 эту  особенность заметили еще летом 2016г Информация была на форуме клаудинайт. На официальном форуме ZWO также было
рекомендовано не менять параметр USB traffic при съемки калибровочных. Т.е. подобрать для себя нормальны USB traffic и лайты и калибровочные снимать при одном значении.

У меня при некоторых значениях USB traffic вообще не происходит загрузка кадров, либо останавливается, например, после загрузки первых 10-и. Индикатор висит и ничего не грузится

А вот это уже интересно... Ладно, этим изредка грешат камеры аси1600 без буфера, но QHY именно зная про эту проблему добавил буфер в камеру и тут выясняется что  все-таки  он не 100% решает эту проблему. Складывается впечатление что этот буфер работает примерно как вентилятор в камерах Risingtech 

[Ihtamnet II]

А откуда возник вообще весь этот гемор с USB traffic? Почему этого нет (ни проблемы, ни регулировки) на "классических" CCD камерах? Это из-за КМОПа? Связано с реализацией быстрого чтения?

[EvgeniyM]

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

[mo]

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

А всё к тому и идёт, похоже.
Попробовали мелким FIFO решить - начались глюки из-за непредсказуемости скорости чтения. Поставили буфер побольше.

Однако, такой же по сложности, как в CCD, обвязка всё равно не будет. Т.к. везде цифра, а это сильно-сильно упрощает смехотехнику.

[EvgeniyM]

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