OsmocomBB

ping?

ping?

i mounted the board on a carrierboard together with a mv-uart board.

2 diodes in series with the vcc-in reduce the 5V from the psu to 3.5-4.2V

i installed the whole thing on powersocket #4 of osmo-gsm-tester-prod.

the mv-uart got ttyUSB13 and ttyUSB14 (this time)

the rf is connected like the c123 - via a 30dB attenuator to the base-unit

i just added simcards and put those into the ressources.conf of the production tester (still commented out)

ttyUSB13 is /dev/serial/by-path/pci-0000:00:12.2-usb-0:5.1:1.0-port0
ttyUSB14 is /dev/serial/by-path/pci-0000:00:12.2-usb-0:5.1:1.1-port0

I'm not sure why is this task assign to me, and it's really not clear what I am expected to do regarding this task. Can you please provide some more information?

I'm als not sure why this was assigned to pespin.

As per the original description, the FCDEV1B shall be set up in a way that it can be remotely accessed by fixeria. This means that there also must be a suitable BTS next to it, so it can be used. I'm sorry to say that 10 months later I don't recall at this point what exactly was the original reason for this :(

I'm not sure whether the osmo-gsm-tester setup is the right place for it, as it would mean that the automatic osmo-gsm-tester runs would have to be stopped/blocked whenever the board is used manually.

Hi Harald!

I'm sorry to say that 10 months later I don't recall at this point
what exactly was the original reason for this :(

AFAIR, the idea was to test some calibration related changes on FCDEV1B,
which would run OsmocomBB. This is not urgent, so no need to rush :)

It needs to be noted that the Calypso chip on the FCDEV3B has non-standard baud rates of 203125, 406250 and 812500 bps, and these are the only baud rates available above 115200 - no 230400 or 460800 or 921600. It also needs to be noted that the CP2105 adapter in the mv-uart only supports such non-standard baud rates on its ECI UART channel but not on the SCI channel, i.e., only one out of the two UARTs. Which FCDEV3B UART is the better ECI UART connected to? Furthermore, the cp210x driver in the Linux kernel had a bug until very recently that caused it to not allow non-standard baud rates on newer-than-CP2102 adapters such as CP2105; the fix has made it into mainline as of 4.19-rc1, but there is no fully released kernel as of yet with this fix included, and it will be even longer before the fix makes its way into distro kernels. Longer description here:

https://www.freecalypso.org/pipermail/community/2018-September/000603.html

Therefore, if anyone is going to need to talk to the FCDEV3B at a higher baud rate than 115200, you will probably need to apply a local patch to the cp210x driver in the kernel on whichever machine the mv-uart is connected to - or replace the mv-uart with an FT2232x adapter as explained in the linked post.

the serials moved:

its on

pci-0000:00:12.2-usb-0:5.3:1.0-port0 - ttyUSB2
pci-0000:00:12.2-usb-0:5.3:1.1-port0 - ttyUSB3

now

as for the original ticket: should this stay connected to the osmo-gsm-tester-prod or move to another machine? (with another bts?)

roh wrote:

as for the original ticket: should this stay connected to the osmo-gsm-tester-prod or move to another machine? (with another bts?)

that's up to fixeria and pespin to state. My thinking is that a separate/independent setup (e.g. using one of the many old nanoBTS we have?) might make more sense as it is less likely to interefere with osmo-gsm-tester-prod.

I'd say I don't really mind whether same machine is used or not, but in case same machine is used, then one must disable following two jobs to avoid colliding with them:
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_ttcn3/
Once it's disabled, if there's a job in process you need to wait until they are done, since cancelling them may be dangerous unless you really know what you are doing (leaving several processes dangling, and a corrupt reserved_resources.conf file). And nowadays a full run of osmo-gsm-tester_run-prod takes around 4h iirc, so that can mean a long wait time if not scheduled in advance.

So all in all, using it or not depends more on how much it takes to set up another system so h can test, and whether is worth it doing it or re-use the same system.

My thinking is that a separate/independent setup (e.g. using one of the many old
nanoBTS we have?) might make more sense as it is less likely to interefere with osmo-gsm-tester-prod.

I am agree, I don't really need to interact with the osmo-gsm-tester setup.

In any case, this task is not urgent since I am working on 'SMS over GSUP' ATM. Having the working setup
would be important as soon as I am back to the RF-calibration related patches in OsmocomBB.

Some reminder, why do we need this setup: http://lists.osmocom.org/pipermail/baseband-devel/2017-November/005417.html

it should be a separate setup with a nanoBTS, preferably one of the old rugby-sized units. Some RF parts might be recycled from the defunct eSeal tester.

• FCDEV1B connected via 50dB ATT. to a zapd20 splitter
• a nanobts165 dcs1800 via 30dB ATT on the TX and RX ports to the same zapd20 splitter
• poe injector for the nanobts
• 5V psu for FCDEV1B with diodes for voltage reduction.
• multivoltage uart board connected to both serials like in the picture above.

• what kind of / which 'host' should this be connected to? (another apu?)
• deploy in osmo network-segment

installed a apu on 10.9.25.60

not active yet - waiting for mechanics (rack)

do we still want/need this?

do we still want/need this?

I think it's a low priority task, as I don't have time to work on it now. Setting to low.

Unless anyone else needs remote access to a FCDEV3B, I think we can close this ticket.