Перейти к содержанию
    

BPSK(QPSK) модулятор-демодулятор и гидроакустический модем

Просьба подсобить с общим пониманием как можно построить несложный гидроакустический модем учитывая то, что несущая частота = 35 кГц, а частота передачи данных = 1200 бод/сек (1.2 кГц) Протокол предполагается UART. Проще говоря на несущей нужно передавать последовательный цифровой код (единички и нолики) с частотой 1.2 кГц.

 

Можно-ли это организовать на базе BPSK?

Как примерно будет выглядеть структура такого устройства?

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тут подробности нужны. А то многое зависит от глубины. Если вблизи поверхности (или дна) работать, то очень сильное многолучевое распространение будет мешать. И тогда "несложно" не получится.

 

Но если по-простому, то нынче можно все просто в цифре сделать. Модуляцию, взять, например, GMSK. Передатчик просто ШИМ'ом контроллера сделать, а приемник - после некоторого предварительного усиления сразу цифровать штатным АЦП контроллера и дальше все в цифре - квадратуры, ЧМ-детектор и так далее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тут подробности нужны. А то многое зависит от глубины. Если вблизи поверхности (или дна) работать, то очень сильное многолучевое распространение будет мешать. И тогда "несложно" не получится.

 

Но если по-простому, то нынче можно все просто в цифре сделать. Модуляцию, взять, например, GMSK. Передатчик просто ШИМ'ом контроллера сделать, а приемник - после некоторого предварительного усиления сразу цифровать штатным АЦП контроллера и дальше все в цифре - квадратуры, ЧМ-детектор и так далее.

Спасибо.

Посмотрел в сторону GMSK. Вполне возможно. Если с передатчиком не должно быть сложностей то с приемником придется повозиться.

Подробности:

Необходимо организовать несколько подводных передатчиков которые должны передавать по очереди с небольшим временным промежутком (с общим периодом 1 сек) на несущей в ~35кГц данные в виде нескольких байт информации по протоколу UART (старт бит - 8 бит данных - стоп бит) на скорости ~1200 бод в сек.

Передатчики могут находиться на разных глубинах в том числе и на мелководье. Максимум до 40..50 метров. В данных должен содержаться код идентифицирующий номер передатчика и еще некоторая служебная информация в виде нескольких байт. Всего предполагается передать до 8...16 байт данных в одной посылке.

Приемник должен принимать данные от всех передатчиков (разделенные во времени) и индетифицировать их по коду-идентифкатору передатчика.

Если с передатчиком на микроконтроллере в общих чертах понятно то с приемником пока не врубаюсь.

Как примерно будет выглядеть структурная схема приемника организованная на микроконтроллере?

Не лучше-ли для таких целей все-же применить BPSK? Возможно-ли приемник в этом случае организовать в цифровом виде на микроконтроллере?

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если с передатчиком на микроконтроллере в общих чертах понятно то с приемником пока не врубаюсь.

Как примерно будет выглядеть структурная схема приемника организованная на микроконтроллере?

Не лучше-ли для таких целей все-же применить BPSK? Возможно-ли приемник в этом случае организовать в цифровом виде на микроконтроллере?

Видно, что Вы очень далеки от темы (обсуждаете сколько стопов и стартов в UART нужно - это даже не вторичные частности, а третичные).

Начинать нужно не с микроконтроллера и UART-ов, а с построения модели канала передача-приём в Матлабе, изучения свойств среды передачи (как Вам тут уже намекнули - отражения, многолучевой приём, изменения спектра, помехи, затухание и прочее) и учёта их в модели.

Когда в модели получите какие-то результаты - можно думать на какое реальное железо это положить.

Думаю задача вполне реальна, но потребует неплохого знания математики и ЦОС. И возможно - ассемблера целевого МК.

Лет 10 назад писал модемы на CPFSK и nQPSK. Правда среда передачи была - радиоканал. И делал на DSP TMS320CC5502 на 220МГц. Со скоростями 300,1200,2400,4800,9600 бод. 9600бод заняло ~30% производительности CPU. Код модулятора и демодулятора полностью был на ассемблере. Возможно, что если тот код для 1200бод переложить на ассемблер современного Cortex-M примерно на 200МГц, то он вытянул-бы. :biggrin:

Хотя конечно у Cortex-M есть аппаратная плавучка и благодаря ей многие фильтры можно было бы реализовать проще чем были у меня и тогда загрузка будет меньше.

 

PS: Ну или - поискать готовый интегральный чип модема, подходящий для Вашей среды передачи. Тогда программа будет очень проста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как примерно будет выглядеть структурная схема приемника организованная на микроконтроллере?

 

Как и любой другой приемник. Квадратурный гетеродин и смеситель, фильтры ПЧ, детектор. Например - http://www.dsplib.ru/content/fmdemod/fmdemod.html

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Передатчик просто ШИМ'ом контроллера сделать, а приемник - после некоторого предварительного усиления сразу цифровать штатным АЦП контроллера и дальше все в цифре - квадратуры, ЧМ-детектор и так далее.

Передатчик лучше ЦАП-ом. И 12 бит разрядности АЦП (которая обычно бывает в МК) может не хватить для обеспечения динамического диапазона и чувствительности.

У меня когда-то был отдельный 24-битный кодек, из которого использовал только 16бит, но было на пределе.

 

Как и любой другой приемник. Квадратурный гетеродин и смеситель, фильтры ПЧ, детектор. Например - [url="http://electronix.ru/redirect.php?

А перед ними: эквалайзер. Так как думаю, что в воде на разных частотах затухание разное. Хотя при таком узком канале оно ещё может и не сказываться.

После входного полосового фильтра и эквалайзера умножаем сигнал на sin() и cos() несущей частоты - получаем 2 квадратуры, фильтруем их ФНЧ, дальше - собственно демодулятор, а потом - битовый детектор. Как-то так.

Вот последний у меня в своё время вызвал как раз наибольшие сложности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возможно, что если тот код для 1200бод переложить на ассемблер современного Cortex-M примерно на 200МГц, то он вытянул-бы. biggrin.gif

 

Не хочу Вас расстраивать, но делал я как-то как раз гидроакустический модем, там была OFDM, скорость данных порядка 140кбит/с, полный дуплекс с несущими 500кГц и 1МГц (аплинк и даунлинк соответственно). Ну справедливости ради там перемножители были внешние. И внешний АЦП (банальный аудио-АЦП двухканальный), цифровать квадратуры уже после смесителя.

 

Работало это на 100МГц Cortex-M3 без особых проблем, без всякой плавающей точки, с загрузкой проца где-то в 30-40 процентов. Да-да, с Фурье вперед и назад, с эквалайзером и прочими необходимыми для OFDM пирогами.

 

А еще был другой, там именно GMSK был, на канале управления жил. Тоже, правда, с внешним АЦП, прямо цинично пьезокерамика на дифференциальный вход AK5384 была подключена. И несущая как раз была в районе 40кГц. Цифровал себе спокойно всю полосу, и дальше все по классике. Ну совсем же смешное было

#define F_CPU (100000000ULL)
#define RXLS_SAMPLE_RATE (97655ULL)

#pragma inline=forced
static long long QMULL(REG32 a, REG32 b, REG32 c, REG32 d)
{
 long long r;
 asm("SMULL %L0,%H0,%1,%2":"=Rp"®:"r"(a),"r"(B));
 asm("SMLAL %L0,%H0,%1,%2":"+Rp"®:"r"©,"r"(d));
 //return ((long long)a * B) + ((long long)c * d);
 return r;
}

static long long FMULADD64(long long r, long long a, UREG32 k)
{
 asm("SMLAL    %L0,%H0,%H1,%2":"+Rp"®:"Rp"(a),"r"(k));
 asm("UMULL    %L0,%H0,%L0,%1":"+Rp"(a):"r"(k));
 a+=0x80000000;
 asm("ADDS     %L0,%L0,%H1":"+Rp"®:"r"(a):"cc");
 asm("ADC      %H0,%H0,#0":"+Rp"®);
 return r;
}

static long long FMULSUB64(long long r, long long a, UREG32 k)
{
 asm("SMLAL    %L0,%H0,%H1,%2":"+Rp"®:"Rp"(a),"r"(-k));
 asm("UMULL    %L0,%H0,%L0,%1":"+Rp"(a):"r"(k));
 a+=0x80000000;
 asm("SUBS     %L0,%L0,%H1":"+Rp"®:"r"(a):"cc");
 asm("SBC      %H0,%H0,#0":"+Rp"®);
 return r;
}

#pragma inline=forced
static inline REG32 EXPDIVfast(long long f, unsigned long long a)
{
 UREG ea;
 UREG32 a32=a>>32;
 REG32 f32=f>>32;
 if (a32)
 {
   ea=__CLZ(a32);
   a32=(a32<<ea)|((unsigned long)a>>(32-ea));
   ea--;
   f32=(f32<<ea)|((unsigned long)f>>(32-ea));
 }
 else
 {
   a32=a;
   f32=f;
   ea=__CLZ(a32);
   a32=a32<<ea;
   ea--;
   f32=f32<<ea;
 }
 a32>>=16+1;
 if (a32)
   return (f32/(REG32)a32)<<8;
 else
   return 0;
}

#define DEFAULT_FREQ_HZ (32010ULL)
#define DEFAULT_FREQ ((DEFAULT_FREQ_HZ<<32)/RXLS_SAMPLE_RATE)
UINT32 freq_a=DEFAULT_FREQ;
UINT32 phase_a;
#define CHLPF_SHIFT (27)
#define CHLPF_PREGAIN_SHIFT (27)
//1.5kHz, 1dB, 5 poles, Z-transform
#define CHLPF_K0 (         961)
#define CHLPF_K1 (    98213853)
#define CHLPF_K2 (   521724849)
#define CHLPF_K3 (  1109599598)
#define CHLPF_K4 (  1181066974)
#define CHLPF_K5 (   629195138)
void I2S_IRQHandler(void)
{
 REG32 rxsig;
 rxsig=I2SRXFIFO;
   REG32 I;
   REG32 Q;
   UREG32 vo=phase_a;
   I=rxsig*SIN8[(vo+0x00000000)>>24];
   Q=rxsig*SIN8[(vo+0x40000000)>>24];
   phase_a=vo+freq_a;
   //Filter I
   {
     static signed long long y1,y2,y3,y4,y5;
     signed long long result;
     result=(long long)I*CHLPF_K0;
     result=FMULADD64(result,   y1,CHLPF_K1);
     result=FMULSUB64(result,y1=y2,CHLPF_K2);
     result=FMULADD64(result,y2=y3,CHLPF_K3);
     result=FMULSUB64(result,y3=y4,CHLPF_K4);
     result=FMULADD64(result,y4=y5,CHLPF_K5);
     y5=result<<(32-CHLPF_SHIFT);
     I=(INT32)(result>>(CHLPF_SHIFT-1));
   }
   //Filter Q
   {
     static signed long long y1,y2,y3,y4,y5;
     signed long long result;
     result=(long long)Q*CHLPF_K0;
     result=FMULADD64(result,   y1,CHLPF_K1);
     result=FMULSUB64(result,y1=y2,CHLPF_K2);
     result=FMULADD64(result,y2=y3,CHLPF_K3);
     result=FMULSUB64(result,y3=y4,CHLPF_K4);
     result=FMULADD64(result,y4=y5,CHLPF_K5);
     y5=result<<(32-CHLPF_SHIFT);
     Q=(INT32)(result>>(CHLPF_SHIFT-1)); //Без одного защитного бита
   }
   //Demodulation
   {
     static INT32 I1,Q1;
     REG32 id,qd;
     id=I-I1; I1=I;
     qd=Q-Q1; Q1=Q;
     long long f=QMULL(-I,qd,Q,id);
     unsigned long long a=QMULL(I,I,Q,Q);
     lsrx_lvl_a=a;
     //Qdata=-EXPDIVfast(f,a);
     Qdata=f>0?-0x200000:0x200000;
   }

... все, тут уже разбор чисто с цифровым потоком, 0/1 это Qdata<0 или >0

}

 

Передатчик лучше ЦАП-ом.

 

Нафиг он там не нужен. Делаются таблички для для плавного по Гауссу изменения фазы ШИМ в вариантах переходов бит 0->1 и 1->0 и все.

 

И 12 бит разрядности АЦП (которая обычно бывает в МК) может не хватить для обеспечения динамического диапазона и чувствительности.

 

Для такого АЦП да, АРУ надо делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Работало это на 100МГц Cortex-M3 без особых проблем, без всякой плавающей точки, с загрузкой проца где-то в 30-40 процентов. Да-да, с Фурье вперед и назад, с эквалайзером и прочими необходимыми для OFDM пирогами.

Дьявол как всегда кроется в деталях. :laughing:

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

Основная нагрузка была - входные фильтры и битовый детектор (выделение битов из потока сэмплов).

Да и по фильтрам и эквалайзерам - думаю не стоит Вам говорить, что даже небольшое ужесточение требований к крутизне АЧХ фильтра приводит к очень большому увеличению длин фильтров.

Я потом на этом же самом МК делал другой модем с частотой сэмплирования кодека на порядок выше, но с гораздо более чистым каналом (модем для фидеров 0.4-10кВ) и получил загрузку CPU всего в несколько процентов насколько помню.

Да и 30% - это было на максимуме - на pi/4 nQPSK непрерывным потоком на приём и передачу. На 9600бод в полосе 7100Гц. Если бы расширить допустимую полосу сигнала раза в два, то загрузка там падает в разы.

 

asm("SMULL %L0,%H0,%1,%2":"=Rp"®:"r"(a),"r"(B));

asm("SMLAL %L0,%H0,%1,%2":"+Rp"®:"r"©,"r"(d));

Что такое и как работают SMLAL и SMULL и прочие команды Cortex-M - я прекрасно знаю. Писал и оптимизировал работу MP3-декодера с отдельными функциями на чистом асм на Cortex-M. Не напугаете :laughing:

 

Нафиг он там не нужен. Делаются таблички для для плавного по Гауссу изменения фазы ШИМ в вариантах переходов бит 0->1 и 1->0 и все.

Конечно наверное можно обойтись. Но зачем? Зачем таблички и более сложные фильтры после ШИМ, если как правило почти в любом приличном МК Cortex-M есть ЦАП?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Конечно наверное можно обойтись. Но зачем?

 

А зачем потом линейный усилитель вместо двух ключей?

 

Дьявол как всегда кроется в деталях.

 

Конечно. Потому что OFDM более выгоден с точки зрения производительности процессора, чем простые методы. Особенно когда нужна эквализация канала. В OFDM это все практически бесплатно получается. Правда, есть нюансы с передатчиком, его нужно делать в виде линейного усилителя. Ну это если не думать ;)

 

битовый детектор (выделение битов из потока сэмплов)

 

Ну это отдельный разговор. Да, Витерби крайне похабно ложится на обычную архитектуру процессоров, так что его нужно избегать по возможности. Это, кстати, тоже плюс в копилку OFDM, там все банально с принятием решения.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А зачем потом линейный усилитель вместо двух ключей?
В принципе наверное Вы правы, здесь же гидроакустика: излучатель наверное - пьезо, с каким-то резонансным контуром?

Я работал на трансформаторы.

 

Ну это отдельный разговор. Да, Витерби крайне похабно ложится на обычную архитектуру процессоров, так что его нужно избегать по возможности. Это, кстати, тоже плюс в копилку OFDM, там все банально с принятием решения.

У меня этот момент был осложнён необходимостью работы модема с ранее разработанным оборудованием: изменить кодирование битового потока было нельзя, а в протоколе при наличии блоков состоящих сплошь из одних "0", в канале так и передавался поток "0". ...до килобайта длиной. И синхронизироваться можно было только по короткому заголовку.

Так что с битовой синхронизацией были большие проблемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да...

Я действительно далек от темы. Придется штудировать буквари.

Читая ответы возникают еще вопросы.

1. Если представить, что гидроакустические передатчики находясь на некотором расстоянии друг от друга передают (излучают) пакеты разных данных одновременно на одной несущей, то в каких-то точках водной среды пакеты могут перекрываться или налагаться друг на друга.

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

Если разделять передатчики по модулирующим частотам то получится сложный приемник для выделения нужной частоты из гребенки частот...

2. Трудно для понимания то, что модулятор и демодулятор можно выполнить на микроконтроллере. Ведь в этом сдучае нужно все оцифровывать, применять АЦП и ЦАП. Как в таком случае, для приемника, определить правильную частоту выборок (семплирования)? Неужели по Найквисту?

Изменено пользователем Acvarif

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Если представить, что гидроакустические передатчики находясь на некотором расстоянии друг от друга передают (излучают) пакеты разных данных одновременно на одной несущей, то в каких-то точках водной среды пакеты могут перекрываться или налагаться друг на друга.

Как в этом случае разделить или идентифицировать нужный пакет от нужного передатчика?

Например: организовать работу так, чтобы в каждый момент времени работал только один передатчик (не было коллизий).

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

 

Как в таком случае, для приемника, определить правильную частоту выборок (семплирования)? Неужели по Найквисту?

Лучше - с запасом. Читайте теорию, прочитаете - поймёте ;)

 

PS: У Вас вопросы совсем по разным уровням и частям. И сам модем и организация обмена в канале - рановато вам ещё этой темой заниматься. Прочитать придётся очень много. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

PS: У Вас вопросы совсем по разным уровням и частям. И сам модем и организация обмена в канале - рановато вам ещё этой темой заниматься. Прочитать придётся очень много. ;)

Вы правы. Не знаю с какой стороны к этому делу подступиться.

Чем больше информации, даже общего плана, тем больше возникает вопросов.

В тупик поставил еще один вопрос:

Как можно увеличить битовую скорость с 1200, например до 9600, 19200 не меняя длительность посылки?

Читал что для этого применяются сложные виды модуляции (QPSK, 8PSK, OFDM).

Грустно стало после того как прочитал про OFDM...

 

Нет-ли готовых микросхем модуляторов-демодуляторов способных работать с несущими порядка 35..200 кГц?

Изменено пользователем Acvarif

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нет-ли готовых микросхем модуляторов-демодуляторов способных работать с несущими порядка 35..200 кГц?

Вполне возможно есть. Но у Вас-то специфические требования: многолучевой приём, допплеровский эффект + ещё чего-то специфичного для гидроакустики.

Такой модем должен быть заточен под Вашу область применения.

Разработка модема - вещь сложная и с нуля с обучением займёт думаю не меньше года. С полным погружением в тему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...