Matlab Filter-Span-In-Symbols property for RRC: source bits lost

Question

I am using the matlab online simulator and taking the course "Wireless communications Onramp" where I need to use a Raised Cosine Transmit Filter to filter the data both in the transmitter and the receiver.

Now, the comm.RaisedCosineTransmitFilter has a property FilterSpanInSymbols,so if the FilterSpanInSymbols = 10, then the delay of the tx/rx filters is 5. Because of this filter both the receiver and the transmitter each have a delay of 5 symbols on the data transmission. So delay of 10 symbols in total.

In my minimal example I send 12 bits, with modulation order 2 ( so 1 bit = 1 symbol) to make it simple:

numBits = 12; %send 12 bits
modOrder = 2;  %1 bit = 1 symbol
bitsPerSymbol = log2(modOrder)  % modOrder = 2^bitsPerSymbol
txFilt = comm.RaisedCosineTransmitFilter; %make the transmit filter
rxFilt = comm.RaisedCosineReceiveFilter; %make the receive filter

srcBits = randi([0,1],numBits,1) %generate random bits to send
modOut = qammod(srcBits,modOrder,"InputType","bit","UnitAveragePower",true); %qam modulation of the bits to send
txFiltOut = txFilt(modOut);%pass the modulated symbols throught the tx filter.

rxFiltOut = rxFilt(txFiltOut ); %pass the data to the receiver;s filter.
demodOut = qamdemod(rxFiltOut,modOrder,"OutputType","bit","UnitAveragePower",true);%demodulate.

%Now the tasks are:
%how much is the total delay in symbols:
delayInSymbols = rxFilt.FilterSpanInSymbols/2 + txFilt.FilterSpanInSymbols/2

%We need to know the delay in bits, not symbols:
delayInBits = delayInSymbols * bitsPerSymbol

%Align source bits (extracting all bits but the last 10 bits which is our total delay)
srcAligned = srcBits(1:(end-delayInBits))

%Next, get the aligned bits from the received bit sequence by extracting all but the first 10 bits.
demodAligned = demodOut((delayInBits+1):end)

The result of the above is that I am sending 12 bits, the 10 of them get lost due to the delay of the filters, and I end up sending only 2 bits (the two first bits of the array), the demodAligned are the received and demodulated bits and the srcAligned are the source bits, before getting filtered, but 'aligned' to compensate for the delays of the rx/tx filters

My question is:

Why do the 10 bits get lost due to the delay? In the real world, using a real device (say something like Adalm-pluto) to send 12 bits, wouldn't the all those bits be sent? The transmitter device would wait for the filter's hardware or software to set itself up, and then start sending the data. The recevier (a second Adalm-Pluto) would have its recevier filter ready to receive data, so there would not be any loss in data, just the trasmitter's initial delay and the receiver's initial delay. But all of the 12 data would be sent and received, right?

I think that in the simulator, it assumes that both of the rx, tx filter's hardware set up at the same time, and while they do set themselves up, the transmission has already started, and the 10 bits just get lost due to that, in the below order:

1. simulation starts, 12 bits start transferring.
2. Tx filter hardware starts, with a delay of 5 symbols, the first 5 symbols get lost
3. Tx device sends the rest 7 symbols
4. Rx filter hardware starts, with a delay of 5 symbols, the first 5 symbols get lost.
5. Rx filter receives only the last 2 symbols.
6. demodulation takes place, only 2 symbols received.

Answer 1

Those bits are apparently lost because the rxFilt() function truncates its output to a window of the same length of the input (except for a factor of 8, which is the default oversampling factor).

Because of the 10-symbols delay, you see your first useful symbols in the positions 11 and 12 of demodOut. You would see the next ones in the positions 13 to 22, but those are not output by the function. That's not what would happen in the "real world"*, where the Rx filter would run continously and flush out those symbols.

Then you truncate srcBits to srcAligned just for convenience, in order to have the same size of demodAligned and compare the two vectors. But this does not mean that those symbols are not transmitted.

---

*Of course, such transients in the "real real world" are much more complicated, as the receiver needs to perform many more operations to achieve synchronization.