Closed grant-h closed 5 years ago
Perhaps yes, feel free to try that out and submit a PR if you find it useful. Thanks
I'm not a signal processing guy and I'm not really sure how I would go about doing that and validating it. Where and which files would you recommend I change? It's hard to know the right place to change that won't adversely affect timing. Also, how would I know when my change actually worked?
Hello @grant-h, sorry for the late interaction, but were you able to solve your n210 clock rate problem with the modification proposed above? I'm having the same difficulty even though I already know in advance that srsLTE doesn't support it. I'm waiting for your answer...
Hello @grant-h, sorry for the late interaction, but were you able to solve your n210 clock rate problem with the modification proposed above? I'm having the same difficulty even though I already know in advance that srsLTE doesn't support it. I'm waiting for your answer...
Hi! I don't have the signal processing skills necessary to do this. I just bought a supported device.
Hi! I don't have the signal processing skills necessary to do this. I just bought a supported device.
I understood. Thanks for the feedback!
From the research I have performed online, the N210 has a fixed clock rate of 100MHz (100 Ms/S). This is unlike the B series devices which have a variable clock rate, allowing for easy integer decimation of the samples to LTE preferred rates.
OpenLTE appears to have a working fix for the N210 TX path: https://github.com/osh/openlte/blob/01251fb2ae1ae18c6cced21e0eee9d7c5e2205bf/LTE_fdd_dl_scan/src/LTE_fdd_dl_scan_flowgraph.cc#L246-L251 It involves a FIR filter + rational resampler to properly resample 25 MS/s (100 Ms/s / 4) down to 15.36 Ms/s (10 MHz LTE bandwidth, Nrb = 50)
Given that srsLTE purposefully re-wrote the PHY to avoid GNU radio blocks, how could a similar fix be deployed in this repo? Would something like the below work?
where rate is some ratio applied to the actual sample rate to bring it into LTE spec.