Project

General

Profile

Support #2704

set up FCDEV1B board so it can be remotely accessed remotely

Added by laforge 11 months ago. Updated 13 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/03/2017
Due date:
% Done:

80%

Resolution:
Spec Reference:

Description

We have one FCDEV1B FreeCalypso board. It would make sense to connect this to a remotely switchable power supply and a computer which has access to its serial console so a developer (particularly in this case, vadim/fixeria) can access it an do some testing/development with it.

P7240895.jpg View P7240895.jpg 421 KB freecalypso mv-uart board roh, 07/24/2018 02:33 PM
3273

Related issues

Related to OsmocomBB - Feature #3581: Merge FCDEV3B board supportNew2018-09-21

Related to OsmocomBB - Feature #3582: Merge reading of factory RF calibration valuesNew2018-09-21

History

#1 Updated by laforge 5 months ago

ping?

#2 Updated by laforge 5 months ago

ping?

#3 Updated by roh 3 months ago

3273

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)

#4 Updated by roh 3 months ago

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

#5 Updated by roh 3 months ago

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

#6 Updated by laforge 3 months ago

On Tue, Jul 24, 2018 at 02:35:49PM +0000, roh [REDMINE] wrote:

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

please specify the /dev/serial/by-serial/ path, as that one is long-time
stable.

#7 Updated by roh 3 months ago

  • Assignee changed from roh to pespin
  • % Done changed from 70 to 80

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

#8 Updated by pespin 2 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from pespin to laforge

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?

#9 Updated by laforge about 1 month ago

  • Assignee changed from laforge to roh

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.

#10 Updated by fixeria about 1 month ago

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 :)

#11 Updated by falconia about 1 month ago

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.

#12 Updated by laforge about 1 month ago

@falconia: Thanks for your very useful input regarding the FCDEV baudrates.

#13 Updated by roh about 1 month ago

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?)

#14 Updated by laforge about 1 month ago

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.

#15 Updated by pespin about 1 month ago

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.

#16 Updated by fixeria about 1 month ago

  • Priority changed from Normal to Low

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.

#18 Updated by fixeria about 1 month ago

#19 Updated by fixeria about 1 month ago

  • Related to Feature #3582: Merge reading of factory RF calibration values added

#20 Updated by laforge 13 days ago

  • Priority changed from Low to Normal

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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)