set up FCDEV1B board so it can be remotely accessed remotely
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.
- File P7240895.jpg P7240895.jpg added
- Status changed from New to In Progress
- % Done changed from 0 to 70
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)
- 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.
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:
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.
#14 Updated by laforge about 2 months ago
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 2 months 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:
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 2 months 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.
#17 Updated by fixeria about 2 months ago
Some reminder, why do we need this setup: http://lists.osmocom.org/pipermail/baseband-devel/2017-November/005417.html