ProHoster > Blog > noticias de internet > "Manifesto para programadores principiantes de especialidades relacionadas" ou como cheguei a este punto da vida
"Manifesto para programadores principiantes de especialidades relacionadas" ou como cheguei a este punto da vida
O meu artigo de hoxe son pensamentos en voz alta dunha persoa que tomou o camiño da programación case por accidente (aínda que sexa natural).
Si, entendo que a miña experiencia é só a miña experiencia, pero paréceme que encaixa ben na tendencia xeral. Ademais, a experiencia que se describe a continuación refírese máis ao campo da actividade científica, pero o que diaños non é broma: pode ser útil fóra.
En xeral, dedicado a todos os estudantes actuais dun antigo alumno!
Expectativas
Cando rematei o meu bacharelato en Tecnoloxías da Infocomunicación e Sistemas de Comunicación en 2014, non sabía case nada do mundo da programación. Si, como moitos outros, cursei a materia de "Informática" no meu primeiro ano, pero, Señor, estaba no meu primeiro ano! Foi unha eternidade!
En xeral, non esperaba nada especialmente diferente dun título de licenciatura, e cando entrei no programa de máster "Comunicación e procesamento do sinal" Instituto Alemán-Ruso de Novas Tecnoloxías.
Pero en balde...
Só eramos a segunda incorporación, e os mozos da primeira aínda estaban facendo as maletas para a afastada Alemaña (as prácticas duran seis meses no segundo ano de máster). Noutras palabras, ninguén do círculo inmediato atopara aínda seriamente os métodos da educación europea, e non había quen preguntar polos detalles.
No noso primeiro ano, por suposto, tivemos varios tipos de prácticas, nas que normalmente se nos ofrecía democráticamente a posibilidade de escoller entre escribir guións (principalmente en linguaxe MATLAB) e usar varias GUI altamente especializadas (no sentido de que sen escribir guións - simulación). entornos de modelado).
Nin que dicir ten que nós, os futuros Mestres en Ciencias, pola nosa estupidez xuvenil, evitamos escribir código como o lume. Aquí, por exemplo, está Simulink de MathWorks: aquí están os bloques, aquí están as conexións, aquí hai todo tipo de configuracións e interruptores.
Unha visión que é nativa e comprensible para unha persoa que traballou anteriormente en deseño de circuítos e enxeñería de sistemas.
Un dos traballos prácticos do primeiro cuadrimestre foi o desenvolvemento dun transceptor de sinal OFDM como parte da materia “Métodos de Modelado e Optimización”. A idea ten moito éxito: a tecnoloxía segue sendo relevante e bastante popular polo seu uso, por exemplo, en redes Wi-Fi e LTE/LTE-A (en forma de OFDMA). Isto é o mellor para que os mestres practiquen as súas habilidades no modelado de sistemas de telecomunicacións.
E agora dannos varias opcións de especificacións técnicas con parámetros de cadros obviamente pouco prácticos (para non buscar unha solución en Internet), e abalanzamos sobre o xa mencionado Simulink... E dámonos na cabeza cunha tetera. da realidade:
Cada bloque está cheo de moitos parámetros descoñecidos, que asustan cambiar a simple vista.
As manipulacións cos números hai que facer, ao parecer, sinxelas, pero aínda hai que rebuscar, Deus o libre.
As máquinas da catedral ralentízanse notablemente debido ao uso frenético da GUI, incluso na fase de navegar polas bibliotecas de bloques dispoñibles.
Para rematar algo na casa, necesitas ter o mesmo Simulink. E, de feito, non hai alternativas.
Si, ao final, por suposto, rematamos o proxecto, pero rematamos cun forte suspiro de alivio.
Pasou un tempo, e chegamos ao remate do primeiro curso do mestrado. A cantidade de deberes utilizando GUI comezou a diminuír proporcionalmente co aumento da proporción de suxeitos alemáns, aínda que aínda non chegara ao punto dun cambio de paradigma. Moitos de nós, incluído eu, superando a nosa considerable amplitude para construír, usamos cada vez máis Matlab nos nosos proxectos científicos (aínda que en forma de caixas de ferramentas), e non o aparentemente familiar Simulink.
O punto das nosas dúbidas era a frase dun dos alumnos de segundo curso (que daquela acababan de regresar a Rusia):
Esquece, polo menos durante o período de prácticas, Similink, MathCad e outros LabView: todo está escrito en MATLAB, usando o propio MatLab ou a súa "versión" gratuíta Octave.
A afirmación resultou ser en parte certa: en Ilmenau tampouco se resolveu completamente a disputa sobre a elección das ferramentas. É certo, a elección foi principalmente entre MATLAB, Python e C.
O mesmo día, sentín unha emoción natural: non debería transferir a miña parte do modelo de transmisor OFDM a unha forma de guión? Só por diversión.
E púxenme a traballar.
Paso a paso
En lugar de cálculos teóricos, simplemente darei unha ligazón a isto excelente artigo 2011 dende tgx e nas diapositivas Capa física LTE profesores Michel-Tila (TU Ilmenau). Creo que isto será suficiente.
"Entón", pensei, "repetimos, que imos modelar?"
Modelaremos Xerador de cadros OFDM (Xerador de cadros OFDM).
Que incluirá:
símbolos de información
sinais piloto
ceros (DC)
De que (por simplicidade) abstramos:
de modelar un prefixo cíclico (se coñeces o básico, engadilo non será difícil)
Diagrama de bloques do modelo en consideración. Deterémonos no bloque FFT inverso (IFFT). Para completar o cadro, cada un pode continuar o resto por si mesmo -prometínlles aos profesores do departamento deixar algo para os alumnos.
Imos definir aqueles por nós mesmos. exercicio:
número fixo de subtransportadores;
lonxitude do cadro fixo;
debemos engadir un cero no medio e un par de ceros ao principio e ao final do cadro (total, 5 pezas);
os símbolos de información son modulados mediante M-PSK ou M-QAM, onde M é a orde de modulación.
clear all; close all; clc
M = 4; % e.g. QPSK
N_inf = 16; % number of subcarriers (information symbols, actually) in the frame
fr_len = 32; % the length of our OFDM frame
N_pil = fr_len - N_inf - 5; % number of pilots in the frame
pilots = [1; j; -1; -j]; % pilots (QPSK, in fact)
nulls_idx = [1, 2, fr_len/2, fr_len-1, fr_len]; % indexes of nulls
Agora determinamos os índices dos símbolos de información, aceptando a premisa de que os sinais piloto deben ir necesariamente antes e/ou despois de ceros:
%concatenation and ascending sorting
inf_and_nulls_idx = union(inf_ind, nulls_idx);
En consecuencia, os índices de sinal piloto son todo o demais:
%numbers in range from 1 to frame length
% that don't overlape with inf_and_nulls_idx vector
pilot_idx = setdiff(1:fr_len, inf_and_nulls_idx);
Agora imos entender os sinais piloto.
Temos un modelo (variable pilotos), e digamos que queremos que os pilotos deste modelo se insiran no noso cadro secuencialmente. Por suposto, isto pódese facer nun bucle. Ou podes xogar un pouco complicado coas matrices; afortunadamente, MATLAB permíteche facelo con suficiente comodidade.
En primeiro lugar, imos determinar cantos destes modelos encaixan completamente no marco:
pilots_len_psudo = floor(N_pil/length(pilots));
A continuación, formamos un vector que consta dos nosos modelos:
E definimos un pequeno vector que contén só un anaco do modelo: a "cola", que non encaixa completamente no marco:
tail_len = fr_len - N_inf - length(nulls_idx) ...
- length(pilots)*pilots_len_psudo;
tail = pilots(1:tail_len); % "tail" of pilots vector
Temos personaxes piloto:
vec_pilots = [resh; tail]; % completed pilots vector that frame consists
Pasemos aos símbolos informativos, é dicir, formaremos unha mensaxe e a modularemos:
message = randi([0 M-1], N_inf, 1); % decimal information symbols
if M >= 16
info_symbols = qammod(message, M, pi/4);
else
info_symbols = pskmod(message, M, pi/4);
end
"Ledicia!" —Pensei satisfeito e pechei o portátil. Tardei un par de horas en facer todo: incluíndo escribir código, aprender algunhas funcións de Matlab e pensar en trucos matemáticos.
Que conclusións tirei entón?
Subxectivo:
Escribir código é agradable e semellante á poesía!
O scripting é o método de investigación máis conveniente para o campo da comunicación e do procesamento de sinal.
Obxectivo:
Non hai necesidade de disparar gorrións desde un canón (a non ser que un obxectivo tan educativo, por suposto, pague a pena): usando Simulink, asumimos resolver un problema sinxelo cunha ferramenta sofisticada.
A GUI é boa, pero é mellor comprender o que está "baixo o capó".
E agora, lonxe de ser estudante, quero dicirlle á confraría estudiantil o seguinte:
Vaia!
Tenta escribir código, aínda que ao principio sexa malo. Coa programación, como con calquera outra actividade, o máis difícil é o comezo. E é mellor comezar antes: se es un científico ou só un técnico, tarde ou cedo necesitarás esta habilidade.
Demanda!
Esixir enfoques e ferramentas progresivas de profesores e supervisores. Se isto é posible, claro...
Crear!
Onde máis é mellor superar todas as llagas dun principiante, se non no marco dun programa educativo? Crea e perfecciona as túas habilidades; de novo, canto antes comeces, mellor.
Aspirantes a programadores de todos os países, únense!
PS
Para deixar constancia da miña relación directa cos estudantes, adxunto unha foto memorable de 2017 con dous reitores: Peter Scharff (á dereita) e Albert Kharisovich Gilmutdinov (á esquerda).
Pagaba a pena rematar o programa polo menos por estes disfraces! (broma)