I suppose airprobe handled that sort of thing for GSM reception, back in the 3.6 days.
But disturbing is your mention of frequency hopping, since that would require some real-time performance between the software and hardware, if it requires changing the center frequency (PLL synth) of SDR source/sink hardware. I'm would assume such latency is not guaranteed even slightly. On Thu, Dec 19, 2013 at 11:05 AM, Sylvain Munaut <246...@gmail.com> wrote: > 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 >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
