Автор |
Сообщение |
|
Дата: 16 Янв 2011 16:19:05 · Поправил: toksin (16 Янв 2011 17:45:12)
#
Вторая моя попытка вникнуть ЦОС. Хочу попробовать написать декодер азбуки Морзе на питоне, в пионе будет использоваться модуль numpy скомпилированный на Си, поэтому скорость обработки сигнала будет аналогичной.
Есть wav файл длительностью 5 с частота семплирования 11025 16 бит, в нем записана последовательность "ab c de" http://www.radioscanner.ru/uploader/2011/ab_c_de11025_16_5c.zip можно любой другой файл с CW взять, файл я генерировал в скайсвипере, к сожалению скорость не запомнил. Частота сигнала манипуляции 1кГц.
Вот код
#!/usr/bin/env python3
import wave
import numpy
FILE_NAME = "ab_c_de(11025_16_5c)with_noise.wav"
FREQ = 1000
SAMPLE = 11025
N = 512 #частота квантования
wav = wave.open(FILE_NAME, 'rb')#читаю файл
raw_bytes = wav.readframes(wav.getnframes())#достаю данные, без заголовка
mas = []
for el in range(0, len(raw_bytes), 2):
mas.append(raw_bytes[el]+raw_bytes[el+1])#здесь я получаю массив, каждый элемент которого равен 2 байта(16 бит)
m = []
mas = mas + [m.append(0+0j) for i in range(12287)] #здесь я добавляю в конец массива #элементы с нулевым значением, чтоб длинна массива была равна двойки в степени n, в данном #случаи 65536
elem = len(mas)
#вот с этого места нужна помощь т.к. скорее всего делаю не правильно
#здесь нужен цыкл
res = numpy.fft.fft(mas[i1*N:i1+N], N) # это преобразование Фурье И=512 - freq step=21,5 Hz #freq=1000 ->46,47 element
Как дальше поступать, сколько элементов из полученного массива и с каким шагом квантования или можно без Фурье обойтись ?
Этот декодер хочу для понимания темы написать, если получится, то хочу написать ACARS и HFDL декодеры и благодаря python они будут мультиплатформенными, но это пока мечты.
Так, что приветствуется любая помощь и критика. |
|
Дата: 16 Янв 2011 17:02:48
#
зачем изобретать колесо? если хочеться просто это моё и всё, то понять можгл. если хоеш чегото лучше существующего проще взять что нить из NIX-овых и модернизировать. раз в програмных кода понимаеш
|
Реклама Google
|
|
|
Дата: 16 Янв 2011 17:33:17 · Поправил: toksin (16 Янв 2011 17:34:44)
#
zepki
Хочется понять принцип работы, улучшить - это врядли. Если получится вникнуть, то цель - написать несколько декодеров авиационной связи, встроить их в одну программу, которая помимо декодирования будет рисовать пути на карте и работать с сервером. По аналогии с моими acars tracker, ads-b tracker и hfdl tracker, только там использовались сторонние декодеры, что накладывало некоторые ограничения, которые очень мешали, а главное это не позволяло работать с Linux и Mac, а я хочу написать готовый комплекс в одной программе, которая будет работать во всех этих ОС. Естественно все будет бесплатным. Таких декодеров под *nix я не встречал, разве, что использовать gnuradio, но лучше самому вникнуть.
|
|
Дата: 16 Янв 2011 17:34:56 · Поправил: Maxwel (16 Янв 2011 17:36:58)
#
можно бес Фурье обойтись
Такая программка ещё на PK-86 была и бес всякого
Фурье
|
|
Дата: 16 Янв 2011 17:49:25
#
Maxwel
Ой ошибочка, поправил.
Т.е. просто брать и считать максимальные значения амплитуды ? И получится, что не важно какая частота манипулирующего сигнала, будут браться пики ?
|
|
Дата: 16 Янв 2011 18:01:21
#
toksin
Там было всё конечно значительно проще(это же середина 80х).
На выход приёмника подключалось реле.
|
|
Дата: 16 Янв 2011 20:47:36
#
toksin Гм, Есть wav файл длительностью 5 с частота семплирования 11025 16 бит, в нем записана последовательность "ab c de" Это точно? Судя по всему вы не проверяли, что и как слепил скайсвипер.
![](http://www.radioscanner.ru/uploader/2011/mrze.jpg) Увеличить |
|
Дата: 16 Янв 2011 21:06:18
#
Действительно, нужно тогда обрезать файл, оставить только первую букву, для начала думаю будет нормально. Mesh а есть алгоритм для такого декодирования ?
|
|
Дата: 16 Янв 2011 21:18:34
#
toksin Действительно, нужно тогда обрезать файл, оставить только первую букву, для начала думаю будет нормально. Неа. :-) Нужно взять в привычку, чекить всё, абсолютно всё. Свои действа, чужие. Свои алгоритмы, чужие. Иначе можно писать вечно. :) Оно и тотальный чекит ничего не гарантирует, но хоть пенять не на кого будет, кроме как на себя, не углядел, не заметил, не догнал и всё такое. А так, так можно написать чудный алгоритм который всё равно ничего не покажет, так как не известно чего он вобще декодит. :) Ну эт ладно. А какой тут алгоритм? Детектор, и по уровню смотреть. Точка в три раза короче тире. Пауза между точкой или тире длиной в точку. Пауза между знаками длиной в тире. Ну и всё. Но это как бы это, слишком гладко. В жизни всё ж не так. Морзе вы выбрали это не лучший метод для тренинга, Морзе крепкий орех для алгоритмизации, особено если чел на качалке будет передавать, да ещё с каким почерком специфичиским, да ещё если помехи будут, да ещё если он будет не один в полосе. :)
|
|
Дата: 16 Янв 2011 22:49:44
#
Урок понятен, действительно выбор далеко не лучший, спасибо :) Mesh А что лучше выбрать ? Как бы цель - это acars, hfdl, ads-b, тут стандарт и все четко, что Вы посоветуете ?
|
|
Дата: 17 Янв 2011 00:00:19
#
toksin Дык, мне советовать оно как бы и не с руки. Да и не очень это я люблю. За мной ничего нет такого. Кроме когда-то написаной конвертилки из i/q в реал. Так и то, там всё было на чужой базе. И в итого оказалось что можно всё сделать быстрее, что и сделали другие. Тут вариант один, зарядится и смотреть как сделано у других. Разбирать чужое. Тут есть вроде на Дельфи исходников на сайте. Что по чекитам, так просто на эти грабли наступал, когда свято веруешь что оно так как думаешь, а не деле, всё оно не так и не туда, и как правило всё это связано с тем, что лень было проверить, а так ли оно вобще как представляется. Я не знаю что советовать в вашем случае, не делал таких штук. Но как-то ж пишут люди, они ж не боги в конце концов, просто тренируются наверно. Имхо.
|
|
Дата: 17 Янв 2011 00:25:07
#
Тогда всеобщий хэлп к тем, кто уже писал, поделитесь опытом :) И с чего посоветуете начать ?
|
|
Дата: 17 Янв 2011 01:03:22
#
toksin
Самое простое из цифровой связи пожалуй QPSK для АБГШ канала.
|
|
Дата: 17 Янв 2011 01:03:50
#
Кроме когда-то написаной конвертилки из i/q в реал. Mesh И где сие чудо можно найти? Давно ищу такое .
|
|
Дата: 17 Янв 2011 01:17:11
#
RadioKoteg Лежит там где и была в файлах. Я ей не пользуюсь. Давно. Там ж и исходники по моему.
|
|
Дата: 17 Янв 2011 11:45:00
#
petr0v
Можете поделится записью сигнала ? Не могу найти.
|
|
Дата: 17 Янв 2011 12:36:04
#
toksin
Есть же в местной базе такие сигналы, вот например:
QPSK-31 |
|
Дата: 17 Янв 2011 12:43:09
#
Спасибо, а какой алгоритм декодирования ?
|
|
Дата: 17 Янв 2011 12:54:15
#
Ностальгия!
Как только доступ к компу получил, первое что сделал написал декодер морзе.
Подавал с контактов реле ключа или на COM, или на LPT, теперь уж и не помню.
Подсчитывал время замыкания и время до начала следующего.
По соотношениям принималось решение это продолжение символа или новое.
Ну коэффициентики всякие, подстройка под скорость.
Надо сказать весьма устойчиво работало, если резко скорость не менять.
Попробуйте, дело интересное!
|
|
Дата: 17 Янв 2011 13:13:37
#
toksin
Алгоритмов много всяких, в двух словах не опишешь, придётся вам книжки соответствующие почитать, модельки в матлабе поделать и т. п.
|
|
Дата: 17 Янв 2011 13:15:23
#
petr0v
Понял, спасибо, сейчас поставлю на закачку матлаб.
|
|
Дата: 19 Янв 2011 00:07:48
#
Морзе вы выбрали это не лучший метод для тренинга, Морзе крепкий орех для алгоритмизации, особено если чел на качалке будет передавать, да ещё с каким почерком специфичиским
А в чём сложность? Определить по амплитудному детектору длительности посылок, построить гистограмму и разбить на две группы? )))
Или речь про реал-тайм?
|
|
Дата: 19 Янв 2011 00:27:54
#
На данный момент все читается из wav, но дальше нужно будет реал-тайм.
|
|
Дата: 19 Янв 2011 00:41:27
#
Или речь про реал-тайм? неужели алгоритм работы амплитудного детектора настолько занимает вычислительные ресурсы, что его нельзя реализовать в реал-тайме? Определить по амплитудному детектору длительности посылок наверное, это будет самый простой и в то же время надежный алгоритм декодирования. но я бы вместо построения гистограммы добавил пару АРУ для выделения посылок и пауз. я так делал для выделения пакетов из сигналов TDMA. вероятность пропуска пакетов при этом была ничтожно мала даже при низких отношениях С/Ш.
|
|
Дата: 19 Янв 2011 00:58:16
#
mikasa76 но я бы вместо построения гистограммы добавил пару АРУ для выделения посылок и пауз. я так делал для выделения пакетов из сигналов TDMA. вероятность пропуска пакетов при этом была ничтожно мала даже при низких отношениях С/Ш. Гм, это на КВ? Когда в полосе приёмника несколько систем ТДМА? :-) Как это должно работать в реалтайме, если у вас 10 телеграфов стучит с разносом в 50-100 герц? Странно иногда. Если говорить о качественном декодере CW, то это не фигли-мигли. Об этом сразу и говорю. Если говорить о лишь бы он декодил чего нибудь, то о каких алгоритмах тогда вообще стоит рассуждать? На выход ПРМ реле, как оно было в 80 и всё будет работать, да только это уж точно не ЦОС и не алгоритмы. Но начинать нужно с простого конечно, но где CW и конечная цельACARS и HFDL декодеры ? Общего мало. Боле того, "лишь бы работал" CW декодер ни на шаг не приблизит к цели даже если и будет декодить одиноко стоящий колом показательно красиво работающий телеграф. А хороший декодер CW это не для тренинга задачка, а сама по себе задача ещё та. :) Но пробовать ессно надо, с чего-то все начинают, это факт.
|
|
Дата: 19 Янв 2011 07:18:48
#
toksin
Вот мои советы - плюнуть на убеждения и изучить уже готовый софт для декодирования морзе.
См здесь http://radio.linux.org.au/?sectpat=morse
Лично я рекомендую demorse --- Command line tool for decoding and printing Morse code signals
Это простая консольная программа с открытым кодом, по ней легко можно понять основные принципы работы декодирования морзе кода чисто софтварными средствами
Все советы по припаиванию реле - оставить тем людям, которые не дружат с программированием.
Все-таки речь идет о программном декодировании, а не об аппаратном.
Да, если demorse будет компилиться с ошибками, то там в маке надо исправить. |
|
Дата: 19 Янв 2011 11:34:58
#
renice
Спасибо за ссылку.
Я вот думаю начать с psk-31, вроде как ближе всего к hfdl и в тоже время, относительно простое. Сейчас ищу алгоритмы декодирования.
|
|
Дата: 19 Янв 2011 11:55:56
#
На мой взгляд, лучше делать программу модульную, согласно unix-way, когда каждый модуль делает маленькую, но безошибочную и слаженную работу.
Один модуль - входной, работает с звуковым потоком (в случае сигналов с кодами Морзе или Бодо - пользоваться алгоритмом дискретизации со значениями 0 и 1), преобразуя его по принципу ЦАП, а на выходе выдавая, к примеру, поток точек и дефисов.
Другой модуль декодирует поток точек и дефисов, на выходе выдавая текст.
Затем можно уже дописать пару разных интерфейсов, которые свяжут эти два модуля и обеспечат интерфейс пользователя.
Плюсы данного решения:
1) модифицируемость программы
2) лёгкость документирования
3) надёжность
4) возможность пользоваться готовыми решениями, тем же demorse в качестве второго модуля.
5) возможность будующей коллективной разработки...
Если Вы предполагаете в будущем реальное использование программы (не в чисто аккадемических целях) - поступайте именно так - не ошибётесь :)
Всех Вам благ!
|
|
Дата: 19 Янв 2011 12:07:35
#
cutnioff
По такому принципу и планирую писать иначе и не выйдет, вот получение звукового потока в win, lin, mac происходит по разному с использованием разных модулей т.е. будет определятся ОС и соответственно подключатся нужные модули. Программу и пишу для реального пользования, просто нужно вникнуть в это дело, поэтому хочу начать с простых вещей. По сути я лишь хочу переписать ранее написанные трекеры, собрать все в одной программе и использовать свои декодеры т.к. работа со сторонними программами накладывает ограничения по получаемым данным и по возможности использования в других ОС, я уже не говорю о лицензирования декодирующего софта. Вот получится ли, я не знаю, но буду стараться, тем более, что есть такой замечательный язык, как питон(спасибо Гвидо), который в разы легче С или С++ и в тоже время, используя откомпилированные на С модули, не уступает им по скорости обработки. Спасибо за пожелания:)
|
|
Дата: 19 Янв 2011 12:17:15 · Поправил: cutnioff (19 Янв 2011 12:18:12)
#
toksin
По такому принципу и планирую писать иначе и не выйдет
Оно может и выйдет, только не очень интересно :)
win, lin, mac происходит по разному с использованием разных модулей т.е. будет определятся ОС и соответственно подключатся нужные модули
ИМХО логичнее будет сделать отдельный слой в виде нулевого (перед первым) модуля между ОС и модулем декодирования звука, который будет отдельный для каждой ОС. А сам пакет софта лучше тоже делать для разных ОС. Опять же, я так вижу. Модуль этот, по моему мнению должен заниматься лишь тем, что из операционки брать поток и тут же перенаправлять его модулю номер один.
Программу и пишу для реального пользования, просто нужно вникнуть в это дело, поэтому хочу начать с простых вещей.
Значит, однозначно, стоит дробить функционал до некоторого уровня. Вот уже три модуля нарисовываются. И это не предел. Реальный софт - штука, сами понимаете, не академическая.
Вот получится ли, я не знаю, но буду стараться
В любом случае - это будет интересно, я думаю.
Спасибо за пожелания:)
Пожалуйста! Дело хорошее, почему бы не поделиться. Кстати, ещё момент: Вы можете оформить это проектом например на гугле или соурсфорже, того и гляди кто-то присоединится.
Удачи Вам в этом не лёгком и увлекательном деле!
|
Реклама Google |
|