YateBts Running problem.

[habib]

hi everyone.
i am using bladerf x115 with ubuntu 14.04. i am trying to run YateBts. i follow the instruction of wiki. As i have no usb 3.0 port on my laptop, i used extra power sourec of presize 5V-1.5Amp.when i use this command sudo yate -sd -vvvvv -l /var/yate.log .the LED 2 is blinking LED 1 & 3 is light up. i am totally new on bladerf bord. so i don,t know the function OR indication of LEDs. as far i know LED 2 is for FPGA and 1,3 for RX,TX. when RX,TX function is running on bord is they are blinking or lighting up?
the outpot of log file of yate is

Code: Select all

Yate engine is initialized and starting up on Satellite
2014-12-19_06:58:26.021560 <INFO> Creating first message dispatching thread
2014-12-19_06:58:26.421714 <cpuload:NOTE> Updating CPU core number from 1 to 4
2014-12-19_06:58:26.861917 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 1
2014-12-19_06:58:27.863197 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 2
2014-12-19_06:58:28.864380 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 3
2014-12-19_06:58:29.865512 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 4
2014-12-19_06:58:30.866665 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 5
ALERT 139741592594304 06:58:30.8 TRXManager.cpp:430:powerOff: POWEROFF failed with status -12014-12-19_06:58:30.866737 <mbts:NOTE> TRXManager.cpp$

2014-12-19_06:58:30.866786 <mbts:WARN> TRXManager.cpp:430:powerOff: POWEROFF failed with status -1
2014-12-19_06:58:30.934589 <mbts:NOTE> OpenBTS.cpp:144:startTransceiver: starting transceiver ./transceiver-bladerf w/ 1 ARFCNs and Args:
2014-12-19_06:58:31.707971 <transceiver:NOTE> bladeRFDevice.cpp:106:open: Opened bladeRF serial=bf922ab76ae11915ff145093139e3eb7 firmware version$
2014-12-19_06:58:32.403082 <transceiver:NOTE> Transceiver.cpp:68:Transceiver: running 1 ARFCNs with oversampling 4
Starting transceiver
2014-12-19_06:58:35.902877 <transceiver:NOTE> bladeRFDevice.cpp:239:start: starting bladeRF in high speed mode...
2014-12-19_06:58:35.905683 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 4222184780922892 at 1 in buffer 0/4
2014-12-19_06:58:35.905738 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3659239122566928 at 253 in buffer 1/4
2014-12-19_06:58:35.905782 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 4081445145214486 at 505 in buffer 2/4
2014-12-19_06:58:35.905821 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3237018067598617 at 757 in buffer 3/4
2014-12-19_06:58:35.905848 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3518495191858205 at 1009 in buffer 0/4
2014-12-19_06:58:35.905896 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3659234827696928 at 1261 in buffer 1/4

....same type of output of last line then the log file show

Code: Select all

MBTS ready
2014-12-19_06:58:36.687464 <ybts-signalling:INFO> Received [0x9ffd00]
-----
Primitive: RadioReady
Info: 0
-----
2014-12-19_06:58:36.687499 <ybts:NOTE> State changed Running -> RadioUp
[ERROR @ libusb.c:711] Got transfer error for buffer 0x1b70080
[ERROR @ libusb.c:711] Got transfer error for buffer 0x1b6a050
2014-12-19_07:01:56.994970 <transceiver:MILD> bladeRFDevice.cpp:607:writeSamples: Samples TX failed at 213814693: Operation timed out
2014-12-19_07:01:57.495144 <transceiver:MILD> bladeRFDevice.cpp:607:writeSamples: Samples TX failed at 213814945: Operation timed out
2014-12-19_07:01:57.995278 <transceiver:MILD> bladeRFDevice.cpp:607:writeSamples: Samples TX failed at 213815197: Operation timed out
CRIT 139996962752256 07:01:58.4 bladeRFDevice.cpp:857:checkHealth: Excessive I/O errors, bailing out2014-12-19_07:01:58.495442 <transceiver:MILD>$

2014-12-19_07:01:58.495513 <transceiver:WARN> bladeRFDevice.cpp:857:checkHealth: Excessive I/O errors, bailing out
Received shutdown signal
Shutting down transceiver...
EMERG 139741591709440 07:01:58.7 OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 139. Exiting.
2014-12-19_07:01:58.702810 <mbts:GOON> OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 139. Exiting.
2014-12-19_07:01:58.710730 <ybts-signalling:WARN> Socket send error: 111 Connection refused [0x9ffd00]
2014-12-19_07:01:58.710784 <ybts:ALL> Restart scheduled in 1ms [0x7fccb3af4ce0]
2014-12-19_07:01:58.710795 <ybts:ALL> Scheduled stop in 0ms

and hence tne next importent section of log file

Code: Select all

2014-12-19_07:02:01.047967 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 1
2014-12-19_07:02:02.048716 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 2
2014-12-19_07:02:03.050005 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 3
2014-12-19_07:02:04.051111 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 4
2014-12-19_07:02:05.052303 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 5
ALERT 140220497205120 07:02:05.0 TRXManager.cpp:430:powerOff: POWEROFF failed with status -12014-12-19_07:02:05.052366 <mbts:NOTE> TRXManager.cpp$

2014-12-19_07:02:05.052431 <mbts:WARN> TRXManager.cpp:430:powerOff: POWEROFF failed with status -1
2014-12-19_07:02:05.118806 <mbts:NOTE> OpenBTS.cpp:144:startTransceiver: starting transceiver ./transceiver-bladerf w/ 1 ARFCNs and Args:
ALERT 139874990876544 07:02:05.1 bladeRFDevice.cpp:96:open: Could not open bladeRF device: No devices available
2014-12-19_07:02:05.122648 <transceiver:WARN> bladeRFDevice.cpp:96:open: Could not open bladeRF device: No devices available
ALERT 139874990876544 07:02:05.1 runTransceiver.cpp:119:main: Transceiver exiting...

2014-12-19_07:02:05.122703 <transceiver:WARN> runTransceiver.cpp:119:main: Transceiver exiting...
EMERG 140220496320256 07:02:05.1 OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 256. Exiting.
2014-12-19_07:02:05.123120 <mbts:GOON> OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 256. Exiting.
2014-12-19_07:02:10.014192 <ybts:NOTE> Peer pid 3254 vanished

this also include

Code: Select all

2014-12-19_07:02:49.015315 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 1
2014-12-19_07:02:50.016568 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 2
2014-12-19_07:02:51.017563 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 3
2014-12-19_07:02:52.018824 <mbts:MILD> TRXManager.cpp:283:sendCommandPacket: TRX link timeout on attempt 4
ALERT 139646196205440 07:02:53.0 TRXManager.cpp:430:powerOff: POWEROFF failed with status -12014-12-19_07:02:53.020077 <mbts:MILD> TRXManager.cpp$

2014-12-19_07:02:53.020132 <mbts:NOTE> TRXManager.cpp:293:sendCommandPacket: lost control link to transceiver
2014-12-19_07:02:53.020161 <mbts:WARN> TRXManager.cpp:430:powerOff: POWEROFF failed with status -1
2014-12-19_07:02:53.091026 <mbts:NOTE> OpenBTS.cpp:144:startTransceiver: starting transceiver ./transceiver-bladerf w/ 1 ARFCNs and Args:
ALERT 140133268064128 07:02:53.0 bladeRFDevice.cpp:96:open: Could not open bladeRF device: No devices available
ALERT 140133268064128 07:02:53.0 runTransceiver.cpp:119:main: Transceiver exiting...

2014-12-19_07:02:53.094811 <transceiver:WARN> bladeRFDevice.cpp:96:open: Could not open bladeRF device: No devices available
2014-12-19_07:02:53.094849 <transceiver:WARN> runTransceiver.cpp:119:main: Transceiver exiting...
EMERG 139646195320576 07:02:53.0 OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 256. Exiting.
2014-12-19_07:02:53.095175 <mbts:GOON> OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 256. Exiting.

From this output, the YateBts first time found my bladerf but after showing Excessive I/O errors ,it show Received shutdown signal
Shutting down transceiver... and no device available.for this may be my problem is Excessive I/O errors am i right? how to solve this Excessive I/O errors?. i have no GSM antenna on my RX,TX port. is it a reason for this type of problem?Please some on help me.and sorry for a big post. Thanks.

[jynik]

If you're running with libbladeRF >= v0.17.0, you need to apply this patch to YateBTS (more info here). I suspect this may be one of the problems you're encountering, given this output:

Code: Select all

2014-12-19_06:58:35.905683 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 4222184780922892 at 1 in buffer 0/4
2014-12-19_06:58:35.905738 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3659239122566928 at 253 in buffer 1/4
2014-12-19_06:58:35.905782 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 4081445145214486 at 505 in buffer 2/4
2014-12-19_06:58:35.905821 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3237018067598617 at 757 in buffer 3/4
2014-12-19_06:58:35.905848 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3518495191858205 at 1009 in buffer 0/4
2014-12-19_06:58:35.905896 <transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by 3659234827696928 at 1261 in buffer 1/4

It looks like what's happening here is that IQ data is being misinterpreted as timestamp metadata. With the introduction of the libbladeRF timestamp support, configuring the sync interface with BLADERF_FORMAT_SC16_Q11 would disable timestamps, wheras BLADERF_FORMAT_SC16_Q11_META would enable them. Since Yate is using BLADERF_FORMAT_SC16_Q11 and then manually turning on the FPGA timestamp bit underneath libbladeRF (as it predated this API support), the call to bladerf_sync_config() is now turning the timestamps off.

The patch I linked addresses this by moving the call to manually flip an FPGA control bit for timestamps AFTER the bladerf_sync_config() call. I believe in the future, the Yate team will be using the libbladeRF timestamp support.

So, I'd say start with that patch first. If you don't get questions answered here, you may find the YateBTS forums to be more helpful with Yate-specific questions.

[djrevmoon]

Don't know about the error, but running without Tx antenna is a bad idea. It can cause hardware damage.

[habib]

Don't know about the error, but running without Tx antenna is a bad idea. It can cause hardware damage.

Ya so i never run it more than 3 min.Please if it possible provide me some information about LED1,2,& 3. thanks

[jynik]

I highly discourage transmitting without a 50-ohm load for any amount of time. Consider getting a dummy load.

LED 1 and 3 will be lit when the FPGA is loaded. 1 turns off momentarily with there's an RX overrun on the FPGA. 3 turns off momentarily when there's a TX underrun on the FPGA. If they appear dim, then may be blinking too quickly to see.

LED 2 blinks when the device is in "RF Link" mode -- the mode of operation where the device can transmit and receive samples.

[habib]

I highly discourage transmitting without a 50-ohm load for any amount of time. Consider getting a dummy load.

LED 1 and 3 will be lit when the FPGA is loaded. 1 turns off momentarily with there's an RX overrun on the FPGA. 3 turns off momentarily when there's a TX underrun on the FPGA. If they appear dim, then may be blinking too quickly to see.

LED 2 blinks when the device is in "RF Link" mode -- the mode of operation where the device can transmit and receive samples.

Thanks a lot for your suggestion and valuable information.i never try this without dummy load or antenna.After loding FPGA, When led 1,3 is Light on that means RX,TX is overrun on the FPGA. am i right?

[jynik]

After loding FPGA, When led 1,3 is Light on that means RX,TX is overrun on the FPGA. am i right?

No. Please re-read what I wrote.

ON is good, OFF is bad. They turn OFF momentarily in overrun/underrun conditions. In cases where lots of overruns/underruns are happening, you may see this LED become dim, because it is turning ON and OFF so quickly.

[habib]

They turn OFF momentarily in overrun/underrun conditions. In cases where lots of overruns/underruns are happening, you may see this LED become dim, because it is turning ON and OFF so quickly

Thank you very mutch. Now i am clear about the indication of LEDs.