Hi,
So I've wanted for a while to use GR more for TDMA systems I'm working
with like GSM and GMR and I'm having a bit of trouble figuring out
what the best way to do that.
Back when I started osmo-gmr, GR didn't have many features to deal
with packets and so I rolled my own hack to go from channelized IQ
stream from Gnuradio to my demodulator function that takes sliced
'windows' of IQ samples of known length and ideally I'd like to
replace most of it with GR. I'll try to explain below exactly what the
current code does and what it must deal with and hopefully someone
familiar with all the new packet feature of GR can guide me how to
implement it in GR.
The input comes from GR currently. It's basically a group of
channelized IQ streams that correspond to the various channels. They
don't necessarely have the same sample-rate, some can be N times
larger (N being an integer). All those streams are synchronized and
must be kept in sync (for example it's needed for hopping, or channel
assignements, ...).
Once the process is started, a "sync detection" task is started on
each channel that will try to acquire initial alignement. This
essentially captures a chunk of each channel long enough and give it
as a big sample array to a function that will find sync pattern for
whatever protocol it's configured for. Once it finds that pattern, it
will initialize a TDMA context that basically knows how to slice the
input into frames. Once those initial frames boundaries are known, the
main TDMA scheduler can be started for each context that was created.
This scheduler basically keeps a list of active / running "tasks". An
example of such a task would be a BCCH task that will slice the BCCH
IQ samples (purely based on the samples number and acquired alignement
and the known/specified TDMA scheduling) and hand them off to the BCCH
demodulator function. Each of those task can spawn new tasks, possibly
on other (or dynamic) channels. So if we see an "IMMEDIATE
ASSIGNEMENT" command in the BCCH/CCCH for example, it will create a
new 'SDCCH task' for example that will go and follow this channel with
it's own state ...
Now of course when starting a new task (after having demodulated /
processed the IQ data), it's sometime important to know where in the
IQ stream that command originated and it's important that the TDMA
slicer didn't take too much advance because if it did, we might miss
some of the TCH frames of the newly assigned channel. In the current
code, everything is done in a single thread so I'm sure that the
slicer didn't avance at all while I was processing the current packet.
So, how would you implement this (architecture wise I mean) with PDUs
/ tagged stream / ...
Cheers,
Sylvain
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
