Так и есть. Для 5-ой частоты дискретизации период составляет 416.929 мкс, для 6-ой - 417.857. Отбрасываем дробную часть и всё сходится.

Стандарт не против, так почему бы и нет? Конечно, если нужна именно частота - то надо уж ее пихать в канал.

Это при частоте 50 Гц, что бывает далеко не всегда.
Решение необычное, не спорю. Но стандарту не противоречит и имеет право на жизнь.

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

Формально - низзя. У нас частота - это частота напряжения. Но если бы и можно - там насыщение, ну его нафиг.

Было бы неплохо. Но, что-то мне подсказывает, что никто этим не займется.

Коллеги.
Есть блоки БМРЗ которые записывают осциллограмму. Есть программа FastView которую мы делали для анализа осциллограмм записанных в первую очередь нашими блоками. Это ведь логично, если программа еще и бесплатная.
В блоках БМРЗ есть два варианта расчета частоты сети, для обоих мы должны предоставить возможность просмотра. Первый вариант через частоту дискретизации второй это запись частоты которую рассчитал блок.
Во всех последующих блоках мы будем реализовывать второй вариант.
Делать функцию расчета частоты сигнала по любому каналу мы точно не будем делать.
Для прозрачности стоит в редакторе формул для функции расчета Частоты указать для блоков БМРЗ.  Для решения возникшей проблемы мы это сделаем.

в принципе, это правильно, но откуда взять N? В комтрейде не задана N, там задана частота_дискретизации=f*N и номинальная частота сети fnom.

N можно достать из частоты дискретизации делением на номинальную частоту сети с округлением, но ни из какой части файла не следует, что, скажем, N=48 всегда.
т.е. можно использовать алгоритм типа N=round(частота_дискр/fnom), и далее всегда делать фурье с N, но тогда N будет вычисляться правильно не при любых частотах, а только при близких к 50 Гц.
возможно, кому-то пришла в голову идея сделать "универсальный" вариант, записывая частоты дискретизации, чтобы Фурье всегда шло с "правильным" N.

но комтрейд-то универсальный)

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

я делал как-то свой просмотрщик комтрейда, как раз долго думал, откуда там N взять. имхо, либо N=round(частота_дискр/fnom), либо делать базу данных на устройства и доставать оттуда N по названию.
а частоту сети далее добывать как f=частота_дискр/N

ну так-то да, проблема с фурье выглядит немного надуманной, все равно, если N считать по той формуле N=round(частота_дискр/fnom), то для частот, близких к 50 Гц все четко.

Yesли бы! Стандарт определяет общие принципы. А каждый разработчик допускает свои вариации. В свое время написал статью в журнал Релейная защита и автоматизация. Кто-то из разработчиков попросил подзадержать публикацию для доработки (кому-то часы понадобились, кому-то - месяцы, а кто-то и по сей день спустя годы дуется: ты чей заказ выполнял?).
Файлы каждого разработчика, к тому же сохраненные в разных форматах COMTRADE, разные просмотрщики смотрят по разному.

Вместо "узнали" можно "посчитали", о чем и писал в почте #23. Как считать - по ситуации. Например, тот же блок PLL в Simulink.

Я так понял, Вы - представитель этой фирмы. От того пояснения не стают более ясными. Сделайте так, чтобы любой просмотрщик (да и конечный потребитель) Вас понимал, и будет Вам счастье!