Вот интересную инфу по обсуждаемому микрокомпьютеру нашел, правда нужно зарегистрироваться.
https://www.pinterest.com/pin/174725660516104840/
Честно говоря глаза разбежались, чувствую все это только молодым под силу.
Вид для печати
Вот интересную инфу по обсуждаемому микрокомпьютеру нашел, правда нужно зарегистрироваться.
https://www.pinterest.com/pin/174725660516104840/
Честно говоря глаза разбежались, чувствую все это только молодым под силу.
На Raspberry PI B+ у меня работает удаленное управление трансивером TS-590 с передачей звука по сети вот видео https://www.youtube.com/watch?v=Usxk0ZpDg8g
Реальная задержка 20-30мс примерно в одну точку на скорости 25 WPM.
Проект реализован под ОС Linux, на винду планов нет!
Трансивер подключен к Raspberry одним шнурком по USB - в нем и CAT и голос и манипуляция CW.
А можно получить консультацию? Попробовать на даче оставить Кенвуд, только вот интернет там будет через свисток сотовой связи.
Я к вам в скайп постучался
Что конкретно интересует?
Почему линукс? - внем намного проще работать с железом и сетями да и переносимость между дистрибутивами очень хорошая, например сама оболчка управления трансивером написана на QT5 - у меня есть сборка и под линукс и под виндовс и под андроид, а вот со звуком пока только линукс дает минимальные задержки.
В принципе как вариант можно строить ремоут на двух микрокомпьютерах типа Raspberry - один у трансивера - другой дома(можно поключить по HDMI монитор и клаву с мышью по USB), дома кстати можно подключить трансивер в режиме TWIN и крутить ручку не в программе а в реальном трансивере, при этом слушать местный и удаленный приемник.
PS Скайп я авторизовал
Я уже начал оболочку писать на Qt5, и даже уже опробовал ее работу. Правда, передавал по сети звуковые данные
без сжатия и меток времени, соответственно, задержку не оценивал, рано еще и далеко до "продукта."
Но результат вполне меня удовлетворил для прототипа, потому что концепт получился полностью рабочий,
и не использующий никакие коммерческие ресурсы.
Опыт показал, что можно работать без VPN, DynDNS и аналогичных ресурсов,
и теоретически можно даже не использовать ipecho, если самому сканировать свою же почту для определения своего внешнего адреса.
Что за оболочка управления трансивером на Qt5 с передачей звука? Если уже кто-то написал готовую, было бы интересно узнать, где ее можно посмотреть.
Тогда нет смысла писать свою.
Посмотрел видео, стало понятно, кто сделал программу.
Насколько я понял, никакого сжатия звука не реализовано, поэтому и трафик такой большой.
Наверное, можно возможность внедрить какое-нибудь сжатие без потерь, уже почти в 2 раза трафик снизится.
Ну и на десерт прикрутить что-то вроде ogg, чтобы фоновый звук в дежурном режиме совсем мало трафика ел,
его же можно будет использовать в качестве средства для восстановления данных потерянных звуковых пакетов.
Я все равно зимой не буду ничего серьезного делать на даче, так что у меня еще время есть.
Сколько времени потратили на реализацию программной части?
RA0SP, Наверное попросим у автора архив с пакетом для Малинки. Ну а может быть и образ карточки загрузочной
Сжатие конечно использую! Причем самым бысрым кодеком задержка которого всего 16мс!
На видео звук идет в UDP пакетах длиной 27 байт - при битрейте 32кбс и ресемпл 16кгц
При ресемпл 8кгц звук становиться как в бочке :) , битрейт можно снизить до 24кбс - при этом звук немного начинает терять качество, у меня биртейт можно менять на лету с шагом 400 б/сек для этого задействана библиотека ORTP. Хочу еще прикрутить UPnP чтоб порты автоматом открывались для UDP.
Если давить тишину - слабые сигналы начинают пропадать или рваться.
Пакета готового пока нет, в стадии экспериментов многое приходиться запускать в ручную из командной строки линукса.
Проектом занимаюсь больше 2-х лет(когда время есть)
Спасибо, oRTP выглядит по описанию неплохо.
У меня есть своя примитивная реализация подобной библиотеки, написанная еще в стародавние времена,
но это намного вкуснее. Будем изучать.
А про 27 байтные пакеты никому не рассказывайте, а то засмеют. Один заголовок самого простого пакета UDP намного длиннее.
А как на счет TCPDUMP см картинку :) - длина данных 27 байт, а что касается служебной информации 8 байт заголовок UDP + 20 байт заголовок IP :)
Так при битрейте 24кб/с длина данных 27 байт, а уже при битрейте 32кб/с длина 31 байт вот и получается 50% полезная информация + 50% служебная - много не сэкономишь на трафике.
Длина IP-заголовка переменная, в локалке IPv4 вполне может быть и 20 байт, согласно спецификациям максимум - 60 байт.
Но это все я к чему: чтобы использовать пакеты короче 100 байт нужно иметь серьезные основания.
Мне еще придется повозиться, пока можно будет не стыдно показать результат.
Успехов!