Activity for Jeremy Quirke
-
Jeremy Quirke modified a comment on discussion General Discussion
There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can deduce it is Msg3 being misdecoded (and not the RAR) due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_R...
-
There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can see it is Msg3 being misdecoded (and not the RAR) due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_RAR_...
-
There is also an issue where where the PRACH detector is significantly more sensitive than the PUSCH decoder which results in 3-6 RAR attempts typically before Msg3 is decoded with success. You can see it is Msg3 being misdecoded due to the timing (100ms - PRACH interval + mac contention timer vs 20ms PRACH interval). To partially compensate for this, will modify the RAR to increase the Msg3 power by the maximum (8dB): modify _mac.cc and change rar.tpc_command = LIBLTE_MAC_RAR_TPC_COMMAND_8dB;
-
This is when the RNTI timer expires. You need to give us the trace frm 5 seconds earlier to see exactly what happened. Please provide the full trace from first detection of RACH preamble.
-
This is when the RNTI timer expires. You need to give us the trace frm 5 seconds earlier to see exactly what happened.
-
Make the following code change and let know how you go, the idea here is to restrict the non radio threads off the last core. (I'm taking a stab here w.r.t. to how linux numbers logical CPUs, but if the /proc/cpuinfo is anything to go by, this is correct). LTE_fdd_enb_msgq.cc pthread_getaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-1, &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-2, &af_mask); //add this line pthread_setaffinity_np(msgq->rx_thread,...
-
Make the following code change and let know how you go, the idea here is to restrict the non radio threads off the last core. LTE_fdd_enb_msgq.cc pthread_getaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-1, &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-2, &af_mask); //add this line pthread_setaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask);
-
Yeah still almost certainly CPU limited mate, what I'm guessing is the single biggest issue is because that CPU is running everything, the L1/L2 caches are getting cleared out between the math-heavy stuff (process_dl) which is hurting performance. Not to mention hardware interrupts and bottom halves (especially USB controller ones that copy buffers around) will have no choice but to be assigned to that single CPU which will also likely cause cache evictions etc. The fact that 1.4MHz is getting somewhere...
-
Yeah still almost certainly CPU limited mate, what I'm guessing is the single biggest issue is because that CPU is running everything, the L1/L2 caches are getting cleared out between the math-heavy stuff (process_dl) which is hurting performance. Not to mention hardware interrupts and bottom halves (especially USB controller ones that copy buffers around) will have no choice but to be assigned to that single CPU which will also likely cause cache evictions etc.
-
Yeah still almost certainly CPU limited mate, what I'm guessing is the single biggest issue is because that CPU is running everything, the L1/L2 caches are getting cleared out between the math-heavy stuff (process_dl) which is hurting performance. Not to mention hardware interrupts and bottom halves (especially USB controller ones) will have no choice but to be assigned to that single CPU which will also likely cause cache evictions etc.
-
The pattern is too regular for it to be real gaps, so, no, I would say no issue with USB for you. Your issue is CPU, single core will not cut the mustard unfortunately for you. You might have some luck @ 1.4MHz bandwidth instead.
-
The pattern is too regular for it to be real gaps, so, no, I would say no issue with USB for you. Your issue is CPU, single core will not cut the mustard unfortunately for you.
-
There exists some scenarios where the radio thread will become stuck on RX overrun and not recover This occurs if a brand new bladerf_sync_rx call aligns perfectly with a USB buffer start. In such case, the bladerf_sync_rx will signal this by returning BLADERF_ERR_TIME_PAST not, by returning success and marking the meta as BLADERF_META_STATUS_OVERRUN. I personally don't like this inconsistent design in libbladerf, but nonetheless, the diff is attached.
-
There exists some scenarios where the radio thread will become stuck on RX overrun and not recover This occurs if a brand new bladerf_sync_rx call aligns perfectly with a USB buffer start. In such case, the bladerf_sync_rx will signal this by returning BLADERF_ERR_TIME_PAST not, by returning success and marking the meta as BLADERF_META_STATUS_OVERRUN. I personally don't like this inconsistent design in libbladerf, but nonetheless, the diff is attached.
-
On the upside, this experiment helped me reproduce a bug in the bladerf interface. I have started a new thread with the diff and bugfix.
-
tx config file=samples_15.36msps repeat=0 rx config file=samples_15.36msps.check n=76.8M set loopback firmware tx start rx start now run the python gaps on samples_15.36msps.check for some reason I can't run both TX and RX on windows Maybe you can If that doesnt work, no matter. I think our issue is CPU after all. 1 core may not be enough. I have core i7-4710 with 4xcore 8xHT, I can run fine with no skipping even with web browsing etc @ 5MHz LTE. Normally I run radio thread on logical processor 7,...
-
tx config file=samples_15.36msps repeat=0 rx config file=samples_15.36msps.check n=76.8M set loopback firmware tx start rx start now run the python gaps on samples_15.36msps.check for some reason I can't run both TX and RX on windows Maybe you can If that doesnt work, no matter. I think our issue is CPU after all. 1 core may not be enough. I have core i7-4710 with 4xcore 8xHT, I can run fine with no skipping even with web browsing etc @ 5MHz LTE. Normally I run radio thread on logical processor 7,...
-
tx config file=samples_15.36msps repeat=0 rx config file=samples_15.36msps.check n=76.8M set loopback firmware tx start rx start now run the python gaps on samples_15.36msps.check for some reason I can't run both TX and RX on windows Maybe you can If that doesnt work, no matter. I think our issue is CPU after all. 1 core may not be enough. I have core i7-4710 with 4xcore 8xHT, I can run fine with no skipping even with web browsing etc @ 5MHz LTE. Normally I run radio thread on logical processor 7,...
-
tx config file=samples_15.36msps repeat=0 rx config file=samples_15.36msps.check n=76.8M set loopback firmware tx start rx start now run the python gaps on samples_15.36msps.check for some reason I can't run both TX and RX on windows Maybe you can If that doesnt work, no matter. I think our issue is CPU after all. 1 core may not be enough. I have core i7-4710 with 4xcore 8xHT, I can run fine with no skipping even with web browsing etc @ 5MHz LTE. Normally I run radio thread on core 7, and everything...
-
no problem. OK yes, we need to clarify what you tested. Test A The instructions in the link I provided are testing only the RX path without any TX. This is the first step to pass. I would run the test with n=250M or similar at sample rates 1.92M, 3.84M, and 7.68M and 15.36M and even 30.72M. 15.36M will allow for a 5MHz carrier (2 directions). You should be using an SSD for this test as magnetic drive may be the limiting factor. If you don't have an SSD create a RAM disk of 1-2GB. Once you confirm...
-
no problem. OK yes, we need to clarify what you tested. Test A The instructions in the link I provided are testing only the RX path without any TX. This is the first step to pass. I would run the test with n=250M or similar at sample rates 1.92M, 3.84M, and 7.68M and 15.36M and even 30.72M. 15.36M will allow for a 5MHz carrier (2 directions). You should be using an SSD for this test as magnetic drive may be the limiting factor. If you don't have an SSD create a RAM disk of 1-2GB. Once you confirm...
-
no problem. OK yes, we need to clarify what you tested. Test A The instructions in the link I provided are testing only the RX path without any TX. This is the first step to pass. I would run the test with n=250M or similar at sample rates 1.92M, 3.84M, and 7.68M and 15.36M and even 30.72M. 15.36M will allow for a 5MHz carrier (2 directions). You should be using an SSD for this test as magnetic drive may be the limiting factor. If you don't have an SSD create a RAM disk of 1-2GB. Once you confirm...
-
no problem. OK yes, we need to clarify what you tested. Test A The instructions in the link I provided are testing only the RX path without any TX. This is the first step to pass. I would run the test with n=250M or similar at sample rates 1.92M, 3.84M, and 7.68M and 15.36M and even 30.72M. 15.36M will allow for a 5MHz carrier (2 directions). You should be using an SSD for this test as magnetic drive may be the limiting factor. If you don't have an SSD create a RAM disk of 1-2GB. Once you confirm...
-
no problem. OK yes, we need to clarify what you tested. Test A The instructions in the link I provided are testing only the RX path without any TX. This is the first step to pass. I would run the test with n=250M or similar at sample rates 1.92M, 3.84M, and 7.68M and 15.36M and even 30.72M. 15.36M will allow for a 5MHz carrier (2 directions). You should be using an SSD for this test as magnetic drive may be the limiting factor. Once you confirm no gaps @ 15.36M proceed to the next test. Test B Next...
-
OK, We need to eliminate your problem. Here are several possibilities CPU. The processor itself is fast enough to run 5MHz carrier, but either 1.1 there is lots of interrupt/bottom half processing going on 1.2 you are suffering lots of L2/L3 cache thrashing due to stuff running on the hyperthread/interrupts/bottom halves, this can hurt the downlink IFFT time bigly :P USB controller can't keep up. I would look here first. Follow this process to identify whether the controller can keep up https://github.com/Nuand/bladeRF/wiki/Debugging-dropped-samples-and-identifying-achievable-sample-rates...
-
OK, We need to eliminate your problem. Here are several possibilities CPU. The processor itself is fast enough to run 5MHz carrier, but either 1.1 there is lots of interrupt/bottom half processing going on 1.2 you are suffering lots of L2/L3 cache thrashing due to stuff running on the hyperthread/interrupts/bottom halves, this can hurt the downlink IFFT time bigly :P USB controller can't keep up. I would look here first. Follow this process to identify whether the controller can keep up https://...
-
OK so you have a performance problem, not a clock problem. Again, double check that the radio thread is running real time and affinitized to one hyperthreaded core. Make sure the other threads are affinitized to every other core and not the hyperthreaded sibiling of the radio core. Also check of course that other processes aren't chewing CPU etc (the obvious). There's one more obvious question - is the USB port operating at SuperSpeed (bladerf-cli -i, info command)
-
OK so you have a performance problem, not a clock problem. Again, double check that the radio thread is running real time and affinitized to one hyperthreaded core. Make sure the other threads are affinitized to every other core and not the hyperthreaded sibiling of the radio core. Also check of course that other processes aren't chewing CPU etc (the obvious).
-
One core runs the dedicated radio thread so everything else will go on the first core. Should be enough. Again, are you receiving warnings when you connect to the debug port about skipping frames? Be cautious on your platform that the code below isn't affinitizing the other message processing threads to run on the hyperthreaded sibling of the radio core (I'm not familiar with how Linux reports _SC_NPROCESSORS_ONLN) pthread_getaffinity_np(msgq->rx_thread, sizeof(af_mask), &af_mask); CPU_CLR(sysconf(_SC_NPROCESSORS_ONLN)-1,...
-
One core runs the dedicated radio thread so everything else will go on the first core. Should be enough. Again, are you receiving warnings when you connect to the debug port about skipping frames?
-
I would step back a moment. There's no convincing evidence that this is a clock problem. These devices are very well calibrated out of the box, so if you are going to play around with the trim dac at least save your old value. Now, given what you have told me, that you do see the network at 1.4MHz, and at no other bandwidths, this suggests it is more likely to be the system struggling to keep up. What does the debug console say? Do you get lots of messages about skipping subframes? One recommendation...
-
I would step back a moment. There's no convincing evidence that this is a clock problem. These devices are very well calibrated out of the box, so if you are going to play around with the trim dac at least save your old value. Now, given what you have told me, that you do see the network at 1.4MHz, and at no other bandwidths, this suggests it is more likely to be the system struggling to keep up. What does the debug console say? Do you get lots of messages about skipping subframes?
-
I would step back a moment. There's no convincing evidence that this is a clock problem. These devices are very well calibrated out of the box, so if you are going to play around with the trim dac at least save your old value. Now, given what you have told me, that you do see the network at 1.4MHz, and at no other frequencies, this suggests it is more likely to be the system struggling to keep up. What does the debug console say? Do you get lots of messages about skipping subframes?
-
That 67khz is a suspicious number. It's 1/4 of the GSM symbol rate which means the kal tool may not be working properly, 67kHz assuming GSM1800 network is over 35 ppm which does not sound right at all.
-
The BladeRF comes very well calibrated and has no need for external clock. I find however the TCXO needs a minute or so after cold power up before the clock is stable. You should confirm your device's calibration against a known GSM network using the kal tool.
-
The msg_sem should be initialized to non-signalled, so there is not an erroneous log message. Very trivial, but it's one of those things that bugged me for a while. diff against v00-20-05
-
The msg_sem should be initialized to non-signalled, so there is not an erroneous log message. Very trivial, but it's one of those things that bugged me for a while. diff against v00-20-05
-
This has been around for a while, apologies if fixed. It's insignificant but annoying. It's a trivial modulo arithmetic bug. Diff attached for v00-20-04 07/26/2017 16:54:22.487898 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10238), skipping 0 subframes 07/26/2017 16:54:22.488947 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10239), skipping 0 subframes 07/26/2017 16:54:22.489880 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (0), skipping 0 subframes...
-
This has been around for a while, apologies if fixed. It's insignificant but annoying. It's a trivial modulo arithmetic bug. Diff attached for v00-20-04 07/26/2017 16:54:22.487898 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10238), skipping 0 subframes 07/26/2017 16:54:22.488947 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10239), skipping 0 subframes 07/26/2017 16:54:22.489880 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (0), skipping 0 subframes...
-
This has been around for a while, apologies if fixed. It's insignificant but annoying. It's a trivial modulo arithmetic bug. Diff attached for v00-20-04 07/26/2017 16:54:22.487898 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10238), skipping 0 subframes 07/26/2017 16:54:22.488947 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10239), skipping 0 subframes 07/26/2017 16:54:22.489880 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (0), skipping 0 subframes...
-
This has been around for a while, apologies if fixed. It's insignificant but annoying. It's a trivial modulo arithmetic bug. Diff attached for v00-20-04 07/26/2017 16:54:22.487898 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10238), skipping 0 subframes 07/26/2017 16:54:22.488947 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (-10239), skipping 0 subframes 07/26/2017 16:54:22.489880 info mac LTE_fdd_enb_mac.cc 371 MAC_dl_tti - PHY_dl_tti != 2 (0), skipping 0 subframes...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
For those looking to play with win32, although the /dev/tun functionality is not there, you can still play with the basic LTE functions until I work out something for this. For windows to work properly (At least with bladerf h/w) there is a small patch here that enables real time scheduling and affinity on windows fixes a bug where devices don't re-enumerate correctly (find_bladerfs()) whilst the device is open - the \.\Device\USBPDO-XXX are not sharable in Windows NT, so the patch uses the saved...
-
Basic approach (technology agnostic) is apply power threshold in the uplink bands. Better approach is technology specific. For LTE, you would first identify the dominant cells in the area and their configuration - the corresponding uplink carrier and bandwidth, as well as the PCI and PRACH configuration. Then, probably the best way to detect UE in the area is to scan the uplink carrier for PRACH preambles. However, you would need hardware to scan all operators and all carriers in the same area.
-
diff on 20.03
-
diff on 20.03
-
Attached are diffs for liblte to support FDD bands 26,27,28. I suspect some here...
-
I raised this 2 years ago and modified my local copy (although it is becoming tiresome...
-
I second this. https://sourceforge.net/p/openlte/discussion/general/thread/bf01d...
-
modify liblte\src\liblte_interface.cc and it will support almost any frequency you...
-
Add support for all bands for 19.02. I am personally using band 28 for testing (there's...
-
Add support for all bands for 19.02
-
Add support for all bands for 19.02
-
Add support for all bands for 19.02
-
Good Evening. Posting here because I am not aware of any issue tracking system in...
-
Good Evening. Posting here because I am not aware of any issue tracking system in...
-
Good Evening. I have noticed there is a nasty crash due to the new inactivity timer...
-
Alright, so this sort of works. Sort of. The main problem I am having is typically...
-
Alright, so this sort of works. Sort of. The main problem I am having is typically...
-
Alright, so this sort of works. Sort of. The main problem I am having is typically...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
OK I'm somewhat embarassed by the state of this code at the moment, but I thought...
-
1) It works with bandwidth set to 10 MHz (I think this is because of bladerf_sync_config...
-
I have been playing with bladeRF on LTE_fdd_eNodeB in my spare time. Managed to get...
-
I have been playing with bladeRF on LTE_fdd_eNodeB in my spare time. Managed to get...
-
Evening, Recently discovered OpenLTE. Great project and terrific job. I have validated...
-
Evening, Recently discovered OpenLTE. Great project and terrific job. I have validated...
1