-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about running "lte_top_block_siso.py" ... #12
Comments
hi,jarodcs |
well Peggy, to be honest with you, it seems that I never had that problem installing the gr-lte package. Cheers. |
@jarodcs |
@a5552033 sure, it is [email protected]. write me there, hope I can help! |
Hi @jarodcs , have you solved your problem? |
Hi there everybody, hope you are doing great!
The following is a large question (forgive me in advance) regarding the use of the gr-lte lte_top_block_siso.py using as source files the ones generated by the openlte's applications:
Just to explain it briefly, LTE_file_recorder creates a file by recording it from the air interface, in other words, what it is being received from a real LTE base station through the air at a certain frequency and BW, this means that is included losses and multipath time disperssion, among others. On the other hand, LTE_fdd_dl_file_gen creates a file of a certain number of LTE frames. Both files can be checked wit the application LTE_fdd_dl_file_scan. More info here: https://github.com/osh/openlte
I generated both files:
LTE_file_recorder, earfcn = 3700
LTE_fdd_dl_file_gen
Then both files through LTE_fdd_dl_file_scan. Same cell_id=138
From what I know, I can tell that the recorded file (left side) has the same cell_id=138 as the generated file (rigth side), of course it has more info on the Scheduling info list because it is a real LTE base station I guess, and I think I even captured a M-TMSI which is some kind of S1-MME identifier. Again, I think. Well, both files show the expected data on the OpenLte applications.
Then, using each file as a source on the flowgraph lte_top_block_siso.py (on gnuradio) on different instances, it shows this:
Well, it seems to me that the file_generated.bin (rigth side) does not have the problem: ofdm_lte_remove_cp_cvc_0 OUT of sync!, because it is a "laboratory created file". On the other hand, the file_recorded.bin given that it has been recorded with an USRP device, probably it got overbuffered at some point and therefore it lost the time sync. Can anyone be so kind to point me where might be the problem that is causing this ofdm_lte_remove_cp_cvc_0 OUT of sync! on my -almost real world- test (left one).
Cheers
Blinko
The text was updated successfully, but these errors were encountered: