Kenwood TS-570

**DL1KBX** · 21.09.2003, 03:06

А что люди соединяют TRX с PC только ради получения данных о частоте?
Если это лог или DX-Cluster, то да... Про вид работы забыли

А вообще-то я не имел ввиду задержку аппарата в 2 секунды после поступления запроса... мне такое просто неизвестно.
Просто уже были звонки от знакомых (у меня тысячник и лог "Swisslog"). Товарища смущала задержка в 3 секунды, а она была по умолчанию в программе выставлена (причем вполне нормально на мой взгляд). Ну изменил он ее потом на более короткую, а толк то какой?
Я уверен, что для работы с логами и программами дистанционного управления скорость обмена по последовательному порту у TS-570 вполне достаточна.

В других программах другие запросы, это мне понятно, сам злился на медленный канал... и не только:
http://www.qsl.net/dl1kbx/scan-kbx.htm

В данном же случае мне показалось, что товарищ что-то путает, утверждая, что трансивер сам чего-то куда-то гонит

и делает это редко... И касался я только этого момента. Т.е. причем тут аппарат, если программа у него раз в две секунды запрашивает.
HW?

**RK3AAG** · 21.09.2003, 12:20

2 DL1KBX

>> Если это лог или DX-Cluster, то да... Про вид работы забыли

Вы не до конца поняли намек.

Трансивер через CAT еще можно настраивать. Нажимаете кнопку, наслаждаетесь задержкой. Некрасиво. Представляете, если бы с 2-х секундной задержкой работали пульты у телевизора?

>> А вообще-то я не имел ввиду задержку аппарата в 2 секунды после поступления запроса... мне такое просто неизвестно.

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

>> Я уверен, что для работы с логами и программами дистанционного управления скорость обмена по последовательному порту у TS-570 вполне достаточна.

Я повторюсь, что скорость тут не причем (трансивер передает относительно небольшие пакеты данных, поэтому скорости портов 9600 ему выше крыши).

>> В данном же случае мне показалось, что товарищ что-то путает, утверждая, что трансивер сам чего-то куда-то гонит и делает это редко...

Слова САМ нигде не было — его выдумали вы.

Попробую сам узнать у Александра детали той переписки.

>> Т.е. причем тут аппарат, если программа у него раз в две секунды запрашивает.

Речь шла о проблеме на стороне трансивера, поэтому софт на стороне компьютера тут не причем (сомневаюсь, что Александр [http://www.dxsoft.com/ru/] не знает, что данные у трансивера нужно запрашивать -- как бы он тогда написал HAMPORT?).

**VE3EUT** · 22.09.2003, 12:09

Первоначальное сообщение от EIKA
2 DL1KBX

>> Я тоже такого не ощущаю в своем аппарате, но жалобы были. Возможно, дело в старых компьютерах, неверно настроенных портах, кривых руках, полубракованных аппаратах и т.д.

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

**RK3AAG** · 22.09.2003, 12:54

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

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

P.S.
Кстати, Александр ответил на мое письмо -- приду домой, процитирую его здесь.

**DL1KBX** · 22.09.2003, 13:30

to EIKA:
Слова САМ нигде не было — его выдумали вы.
Может быть... уж и не припомню щас чего я только ни напридумывал

**VE3EUT** · 22.09.2003, 13:45

Первоначальное сообщение от EIKA
>>
Я почему сказал "в полубракованных аппаратах", потому что подразумевал, что этот "глюк" мог быть только в определенной партии трансиверов, где, например, была применена "кривая" микропрограмма для CPU. Т.е. работать эти трансиверы работали, но как -- это уже другой вопрос.

А, понятно ;-) Вероятность подобного глюка крайне мала, на несколько порядков меньше всего остального. Софт пишется заводом изготовителем и при этом чекается контрольная сумма. Это же не flash или eeprom.

**RK3AAG** · 22.09.2003, 16:32

2 isartw

>> Вероятность подобного глюка крайне мала, на несколько порядков меньше всего остального.

Я всего лишь привел пример, а причин можно насчитать с десяток, только смысла в этом нет, т.к. «глюка» этого я в глаза не видел. Вот если он у кого-то из читающих эту тему «глюк» есть, тогда можно будет проводить эксперименты и устанавливать причины…

Есть еще одни странный момент – дело в том, что уже есть два случая, когда HAMPORT 0.9 beta (http://www.dxsoft.com/ru/products/hamport/) вылетает с ошибкой именно при работе с G-версиями TS-570. Один из этих счастливых людей — я. А HAMPORT мне нужен позарез, т.к. он является как раз CAT-интерфейсом для программы AALog (ее я посчитал лучшим логгером для стран CIS). Александр (автор HAMPORT) сказал, что вроде как HAMPORT «захлебывается» данными при работе именно с G-версиями. Если это так, то это косвенно подтверждает, что в последних версиях TS-570 интерфейс RS-232C сделан по-другому.

>> Софт пишется заводом изготовителем и при этом чекается контрольная сумма. Это же не flash или eeprom.

Какая разница кем он пишется. И причем тут контрольная сумма?

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

**VE3EUT** · 22.09.2003, 18:37

Первоначальное сообщение от EIKA
2 isartw

>> Вероятность подобного глюка крайне мала, на несколько порядков меньше всего остального.

Я всего лишь привел пример, а причин можно насчитать с десяток, только смысла в этом нет, т.к. «глюка» этого я в глаза не видел. Вот если он у кого-то из читающих эту тему «глюк» есть, тогда можно будет проводить эксперименты и устанавливать причины…

Есть еще одни странный момент – дело в том, что уже есть два случая, когда HAMPORT 0.9 beta (http://www.dxsoft.com/ru/products/hamport/) вылетает с ошибкой именно при работе с G-версиями TS-570. Один из этих счастливых людей — я. А HAMPORT мне нужен позарез, т.к. он является как раз CAT-интерфейсом для программы AALog (ее я посчитал лучшим логгером для стран CIS). Александр (автор HAMPORT) сказал, что вроде как HAMPORT «захлебывается» данными при работе именно с G-версиями. Если это так, то это косвенно подтверждает, что в последних версиях TS-570 интерфейс RS-232C сделан по-другому.

>> Софт пишется заводом изготовителем и при этом чекается контрольная сумма. Это же не flash или eeprom.

Какая разница кем он пишется. И причем тут контрольная сумма?

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

Интерфейс вряд ли сделан по-другому. По крайней мере в сервис мануале каких-то отличий я не заметил. Но может дело в firmware. Исходников HAMPORT не видел, но думаю, что тестированию firmware серийного продукта такого как 570-й как минимум не меньше внимания. Так что проблема скорее не в трансивере ;-))

Разница большая, если софт пишется только заводом изготовителем и пзу read only, то нет никакой возможности там что-то поменять. Контрольная сумма притом, что она позволяет задетектить ошибку при записи ПЗУ.

**RK3AAG** · 22.09.2003, 19:10

>> Но может дело в firmware.

Так я об этом и толковал.

Кстати, можно ли в TS-570 посмотреть версию firmware? Если да, то как?

>> Исходников HAMPORT не видел, но думаю, что тестированию firmware серийного продукта такого как 570-й как минимум не меньше внимания.

Согласен.

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

>> Так что проблема скорее не в трансивере ;-))

Вроде как в нем. Позже будет цитата, из нее вытекает как раз это.

>> если софт пишется только заводом изготовителем и пзу read only, то нет никакой возможности там что-то поменять. Контрольная сумма притом, что она позволяет задетектить ошибку при записи ПЗУ.

Я говорил про ошибки в firmware. Если они есть, то read only ПЗУ или нет -- не важно. И контрольная сумма здесь тоже никак не поможет.

**VE3EUT** · 22.09.2003, 19:32

Первоначальное сообщение от EIKA
>>
Кстати, можно ли в TS-570 посмотреть версию firmware? Если да, то как?

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

>> Так что проблема скорее не в трансивере ;-))

Вроде как в нем. Позже будет цитата, из нее вытекает как раз это.

Я говорил про ошибки в firmware. Если они есть, то read only ПЗУ или нет -- не важно. И контрольная сумма здесь тоже никак не поможет.

Можно попробовать ID; - выдаст версию аппарата.

Если в firmware - такие грубые ошибки, то кенвудовский QA отдел нужно садить на хлеб и воду ;-))

Если сталкивались с этом багом, то дайте плс пошаговую инструкцию, как его воспроизвести при помощи терминалки. Чтобы быть уверенным что это не глюк какого-то конкретного логгера или CAT.

**RK3AAG** · 22.09.2003, 19:44

>> Можно попробовать ID; - выдаст версию аппарата.

Присоединиться к трансиверу и скомандовать "ID" или как? Если можно, то попобробнее...

>> Если в firmware - такие грубые ошибки, то кенвудовский QA отдел нужно садить на хлеб и воду ;-))

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

>> Если сталкивались с этом багом, то дайте плс пошаговую инструкцию, как его воспроизвести при помощи терминалки. Чтобы быть уверенным что это не глюк какого-то конкретного логгера или CAT.

Нет, не сталкивался -- просто наткнулся на дискуссию http://www.webboard.land.ru/mes.php?...343&lst=&arhv= и заинтересовался.

Потерпите, через часа 3 запощу обещанную цитату.

**RK3AAG** · 22.09.2003, 22:55

Вот что мне написал Александр на письмо с просьбой потчнее рассказать, что там было с TS-570, который был (есть?) у него:

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

**VE3EUT** · 23.09.2003, 11:07

Первоначальное сообщение от EIKA
>> Можно попробовать ID; - выдаст версию аппарата.

Присоединиться к трансиверу и скомандовать "ID" или как? Если можно, то попобробнее...

>> Если в firmware - такие грубые ошибки, то кенвудовский QA отдел нужно садить на хлеб и воду ;-))

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

Легко.
Берете любой эмулятор терминала который нравится. Если стоит винда, то можно взять Hyperterm, он часть винды. Настраиваете в нем соединение, в соответствии с установками трансивера - скорость, кол-во стартовых и стоповых битов и т.д.
Выключаете local echo, и все.
Теперь открываете юзер мануал на разделе Kenwood communication prtocol, выбираете любую команду, вводите ее руками и смотрите что получилось. Достоинство KCP в том, что он human readable и не нужно много напрягаться чобы понять что трансивер отвечает. После каждой команды нужно вводить ";", <Enter> не нужен. Трансивер воспринимает точку с запятой как конец команды.

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

**RK3AAG** · 23.09.2003, 12:24

2 isartw

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

Понимаете ли, тестировать обособлено можно различные модули сколько угодно -- то, что вы купите, может работать совершенно по-другому и вас не утешишь фразой «во время испытаний ЭТО работало стабильно».

Потому как хорошо оттестированный в лаборатории модуль потом прицепляется к другим модулям/закрывается экраном/меняется его печатная плата/он собирается на компонентах из другой серии/изменяется режим работы каскадов из «соседних» модулей и т.д., и та стабильность работы, которая была достигнута в лаборатории может просто испарится!!!