From craig at unreasonablefarm.org  Sun Feb  4 04:47:55 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Sat, 3 Feb 2018 22:47:55 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
Message-ID: <20180204044755.GA22057@localhost.localdomain>

Sorry for the premature mail posting. I did some more digging and found a quite good thread of information from around 2011 or so.

http://baseband-devel.722152.n3.nabble.com/Mediatek-MT6235-status-Sciphone-G2-td2519606.html

I note that Harald mentioned whether Marcin had suitable lab equipment and I was starting to wonder this as well. Harald, you suggested Racal 6103 or similar, spectrum analyzer/scope up to 900/1800/1900 MHz. I'm wondering if you have any more current recommendations for equipment. I would imagine I might use an RTL-SDR possibly to receive/monitor TX. I see Racal 6103 devices for around $100 on ebay so I could get one of those if need be.

So I found the uboot sources and looked through and see board/mtk/sciphone_g2/mt6140.c which has the rf_tx <arfcn> uboot command. So I'll check fernvale/mtk6260 and see if similar code could be made for fernvale.

-Craig


From craig at unreasonablefarm.org  Sun Feb  4 04:23:32 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Sat, 3 Feb 2018 22:23:32 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
Message-ID: <20180204042332.GA9984@localhost.localdomain>

Hello,

I have several of these devices now and am working on porting fernly code for the fernvale board (and other mtk626x devices) to osmocom-bb.

I found this document: https://elinux.org/images/9/9a/Getting_the_First_Open_Source_GSM_Stack_in_Linux.pdf

and was wondering about the "GSM RF chips slide" which seems to indicate that you may have written RF HW drivers enough to transmit?

I don't see the u-boot sources from the links at https://osmocom.org/projects/baseband/wiki/SciphoneDreamG2 but interestingly I can get to them directly with git. :)

git clone git://git.osmocom.org/uboot-mt623x.git

So I will take a look at what you have and see if I can get somewhere with these devices.

If you have any suggestions please let me know.

Cheers,
Craig


From laforge at gnumonks.org  Sun Feb  4 07:49:29 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 04 Feb 2018 08:49:29 +0100
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180204044755.GA22057@localhost.localdomain>
References: <20180204044755.GA22057@localhost.localdomain>
Message-ID: <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>

Racal 6103 is still a good choice for gsm/gprs, particularly at those low prices. Do not buy any ANITE devixes, as those don't have the normal software with the built in user interface, but rather need some conformance testing software suite on a PC, which nobody  seems to provide along with the devices.
-- 
Sent from a mobile device. Please excuse my brevity.


From holger at freyther.de  Sun Feb  4 22:35:04 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 4 Feb 2018 22:35:04 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
Message-ID: <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>



> On 29. Jan 2018, at 21:52, Holger Freyther <holger at freyther.de> wrote:
> 

Hey,

I wish I had better news. Instead of an end to end test I realize that picking "asyncio" was a grave mistake. Besides the lack AF_UNIX SOCK_DGRAM support, the process support is dangerous and doesn't scale. Today I stumbled into SIGCHLD handling of spawned processes. While normally neither virthphy/mobile would prematurely exit, a few exits could take the entire test down.

Speculating from the behavior of strace:

* SIGCHLD arrives
* Something will be written into one end of a socketpair[1]
* In the python code on wait(2) will be called on every registered process
(https://github.com/python/cpython/blob/3.6/Lib/asyncio/unix_events.py#L819)

As more processes exit the main python code is still in the for loop and the buffer runs full. It also means that the main application will be busy executing Xk syscalls instead of launching processes or events.


It is unfortunate that I only notice now but probably still better than having to deal mysterious failures of processes not starting and all tests failing. As not many people here know Go. I think I will stay with python but use the lower level epoll API directly. So we end up with a single "select" system... I should finally have something during the week.

I hope all of you had a nice fosdem!

holger


[1] A common trick to notify one thread or part of the application of an event. There is not much that is allowed in a signal handler so using a buffer is a reasonable approach.. It should forward the PID of the process that exited though.

From craig at unreasonablefarm.org  Mon Feb  5 21:50:38 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Mon, 5 Feb 2018 15:50:38 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
Message-ID: <20180205215038.GA16863@localhost.localdomain>

Hi all,

I have found a Racal 6103g with many options enabled and seemingly in good condition. I don't expect to have a manual so wonder if anyone here could help me get started with this device?

I would imagine I might need some cabling of some sort and ideally an RF isolation cage of some sort?

Thanks for any help you can give. My primary purpose is getting osmocom-bb layer1 ported for fernvale/sim800 modules (mtk 6260/6261).

Craig


From laforge at gnumonks.org  Mon Feb  5 22:12:51 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 5 Feb 2018 23:12:51 +0100
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180205215038.GA16863@localhost.localdomain>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180205215038.GA16863@localhost.localdomain>
Message-ID: <20180205221251.GN10874@nataraja>

On Mon, Feb 05, 2018 at 03:50:38PM -0600, Craig Comstock wrote:
> Hi all,
> 
> I have found a Racal 6103g with many options enabled and seemingly in good condition. I don't expect to have a manual so wonder if anyone here could help me get started with this device?

There are PDF manuals floating around, and many people in the Osmocom project have used a 6103 before.

> I would imagine I might need some cabling of some sort and ideally an RF isolation cage of some sort?

Just whatever RF cabling / adapters required to connect to the coaxial port of your phone / modem.  an RF
shield box is an option, but wired connection is much easier and less expensive.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From mychaela.falconia at gmail.com  Tue Feb  6 00:28:25 2018
From: mychaela.falconia at gmail.com (Mychaela Falconia)
Date: Mon, 5 Feb 2018 16:28:25 -0800
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180205221251.GN10874@nataraja>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180205215038.GA16863@localhost.localdomain>
 <20180205221251.GN10874@nataraja>
Message-ID: <CA+uuBqZP35p6orHd9A7jmrTKzryUGAO+0fsa0jRTsy6Vzn1TTQ@mail.gmail.com>

On the subject of RF test equipment for the testing and development of
GSM MS devices, chiming in here as a "professional hobbyist" active
manufacturer of such devices, my choice of equipment is Rohde&Schwarz
CMU200.  This model has been the "gold standard" in the world of GSM
chipset vendors and mainstream phone/modem manufacturers: TI used the
CMU200 as their primary choice of instrument when validating their RF
chips (Clara, Rita, LoCosto and so forth) and their complete GSM MS
development boards with those chips, and they provided turnkey
software to their downstream customers (phone/modem manufs) so the
latter could do production line testing and RF calibration of their
end product devices using the very same R&S CMU200.

CMU200 units are readily available on ebay at very reasonable prices -
that's where I got mine.  Most of them (including the one I got) are
equipped with hardware options not only for GSM, but also for WCDMA
(UMTS/3G) - as I see it, the _*only*_ sensible reason to invest the
absolutely enormous amount of effort to run libre MS firmware on some
newer-than-Calypso chipset would be to get UMTS/3G support (expending
such Herculean effort to move from the Calypso to some newer chipset
that is still 2G-only just to please some gerontophones is not
justifiable in my book), hence I similarly see little point in
investing in RF test equipment that is not 3G-capable.

The CMU200 can be operated both standalone (using the front panel
display and controls) and under external host control, and for the
latter mode it supports both GPIB and RS-232.  I use the RS-232 option
for my automated RF test and calibration processes, as it conveniently
avoids the need for exotic interface adapter hardware and equally
exotic drivers and libraries.  The documentation is very good; I got
it in the form of an original R&S documentation CD, but if someone
else needs it, I can upload it to my FTP site.

If you go the ebay-sourced CMU200 route, one issue to watch out for is
units with subtle defects which are not immediately obvious.  My unit
came with a defective main RF generator: the RF analyzer functions
worked fine (analyzing the signal put out by the DUT), but when I
tried to make the CMU200 generate its own signal, the output was so
severely attenuated that it was almost undetectable.  The Aux Tx
generator worked, and I used it as a hacky workaround before I fixed
the main one.  To fix the main signal generator, I first isolated the
fault to the Rx/Tx board inside: I checked the signal at the internal
interface from the Rx/Tx board to the front end module, and found it
to be just as badly attenuated as the external output, pointing the
blame to the Tx half of the Rx/Tx board.  Then I found a replacement
Rx/Tx board on ebay, bought it, swapped it in, and the main signal
generator started working.

Right now my CMU200 is at R&S's service center in Maryland where I
sent it for recalibration - one of my requirements is to measure the
Tx power levels put out by my FreeCalypso GSM MS devices as precisely
as possible (for production calibration), and to feed signals of a
precisely known power level to these devices for Calypso Rx path
calibration.  Given that I have swapped an internal module in the RF
path of my CMU200 in the process of repairing it, I now need to have
the instrument recalibrated in order to get that absolute highest
power level accuracy I desire, which is why I sent it to R&S.  The
cost of this calibration service is more than the cost of the used
unit itself, but that's life.

Professional hobbyist regards,
Mychaela


From holger at freyther.de  Wed Feb  7 09:31:16 2018
From: holger at freyther.de (Holger Freyther)
Date: Wed, 7 Feb 2018 09:31:16 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
 <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
Message-ID: <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>



> On 4. Feb 2018, at 22:35, Holger Freyther <holger at freyther.de> wrote:

Hi,


> * SIGCHLD arrives
> * Something will be written into one end of a socketpair[1]
> * In the python code on wait(2) will be called on every registered process
> (https://github.com/python/cpython/blob/3.6/Lib/asyncio/unix_events.py#L819)


there is a way to switch to a child reaper that is using wait(-1.. but even
then we have two issues.

1.) If I use await asyncio.create_subprocess_exec... then we can't tick
with 50ms. On a 60s schedule to start 10k processes there is a delay of +60s.

2.) If I delay the process creation then I can almost keep the schedule most
of the time but we run into buffering exceptions and/or not all tasks are
started within a reasonable amount of time.

Knowing what I know now I would have gone for Go. It is made for the kind of
concurrency where python seems unusable. I hesitated to build my own event
loop but will build something that looks like our C apps in python (single
select, no async/await).

holger

From craig at unreasonablefarm.org  Tue Feb 13 14:19:49 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Tue, 13 Feb 2018 08:19:49 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <CA+uuBqZP35p6orHd9A7jmrTKzryUGAO+0fsa0jRTsy6Vzn1TTQ@mail.gmail.com>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180205215038.GA16863@localhost.localdomain>
 <20180205221251.GN10874@nataraja>
 <CA+uuBqZP35p6orHd9A7jmrTKzryUGAO+0fsa0jRTsy6Vzn1TTQ@mail.gmail.com>
Message-ID: <20180213141949.GA19119@localhost.localdomain>

Thanks Mychaela,

I have opted to wait and purchase a CMU200 as you suggested. Can you suggest which features I should look for? I'm more of a hands on learner.

https://www.ebay.com/sch/m.html?_odkw=&_ssn=asset-resellers&item=292339250305&_osacat=0&ssPageName=STRK%3AMEBIDX%3AIT&_from=R40&_trksid=p2046732.m570.l1313.TR11.TRC2.A0.H0.Xcmu200.TRS1&_nkw=cmu200&_sacat=0

I figure GSM (all four bands), EGPRS, and HSDPA (HSPA/HSPA+? not sure how these three differ yet).

Thanks for any advice you can give.

Cheers,
Craig


From craig at unreasonablefarm.org  Tue Feb 13 15:47:26 2018
From: craig at unreasonablefarm.org (craig at unreasonablefarm.org)
Date: Tue, 13 Feb 2018 09:47:26 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <CA+uuBqZP35p6orHd9A7jmrTKzryUGAO+0fsa0jRTsy6Vzn1TTQ@mail.gmail.com>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180205215038.GA16863@localhost.localdomain>
 <20180205221251.GN10874@nataraja>
 <CA+uuBqZP35p6orHd9A7jmrTKzryUGAO+0fsa0jRTsy6Vzn1TTQ@mail.gmail.com>
Message-ID: <20180213154726.GB27819@localhost>

Apologies, after a very small amount of RTFM'ing I think I understand that WCDMA supports UMTS aka 3/3.5G. HSUPA and HSDPA are uplink/downlink and that I can likely focus on hardware options on the CMU200 and work on upgrading the software as I proceed up the chain of 2G and on.

Thanks y'all,
Craig


From craig at unreasonablefarm.org  Wed Feb 14 02:52:42 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Tue, 13 Feb 2018 20:52:42 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
Message-ID: <20180214025242.GA20211@localhost.localdomain>

Hi All,

A few comments:
- Can I get edit rights to some mediatek related pages, there are some things I might clear up/freshen up: 
https://osmocom.org/projects/baseband/wiki/SciphoneDreamG2
https://osmocom.org/projects/baseband/wiki/MTKRomloader
https://osmocom.org/projects/baseband/wiki/MediaTek?parent=MTKRomloader
https://osmocom.org/projects/baseband/wiki/Mediatek_Chipset
https://osmocom.org/projects/baseband/wiki/Hardware (to add new pages for the newer mediatek chipsets)
Or maybe just add pages and give me edit rights so I can add findings as I make them.

- the loader_mtk doesn't work in master and I can't find the steve-m/loader_sciphone branch in git, so either someone might find that branch or I'll need to fix things up.
- I have a start at supporting both mt6260 (fernvale) and mt6235 (sciphone dream g2) but the sciphone's lack of something easy to "blink" slowed me down a little ;) I tried the lcd backlight and the vibrate function but neither proved easy-fixes with the existing uboot code.
- I could add more info about various mediatek devices on more pages on the wiki. Maybe I could get access or we could create some pages for... fernvale, sim800, zte-obsidian/mt6735, rephone (ACSip mt2502) and adjust some more general info about romloader.
- I might take a crack at modifying the osmocon mtk loader bits to support different systems like -m mt6260 -m mt6261 -m mt6235 -m mt6735. Though much is the same the main differences seem to be startup behavior, baud rate and SRAM address.

Thanks,
Craig


From laforge at gnumonks.org  Wed Feb 14 12:08:11 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Feb 2018 13:08:11 +0100
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180214025242.GA20211@localhost.localdomain>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180214025242.GA20211@localhost.localdomain>
Message-ID: <20180214120811.GW13099@nataraja>

hi Craig,

On Tue, Feb 13, 2018 at 08:52:42PM -0600, Craig Comstock wrote:
> A few comments:
> - Can I get edit rights to some mediatek related pages, there are some things I might clear up/freshen up: 

you already had wiki editing rights for your user 'escogido'.  However, your other 
account 'craig_comstock' didn't have them.  Now you should have both.

Please let me know if it doesn't work for some reason. Thanks!

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From craig at unreasonablefarm.org  Fri Feb 16 04:48:50 2018
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Thu, 15 Feb 2018 22:48:50 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180214120811.GW13099@nataraja>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180214025242.GA20211@localhost.localdomain>
 <20180214120811.GW13099@nataraja>
Message-ID: <20180216044850.GA14304@localhost.localdomain>

> you already had wiki editing rights for your user 'escogido'.  However, your other 
> account 'craig_comstock' didn't have them.  Now you should have both.
> 
> Please let me know if it doesn't work for some reason. Thanks!

The craig_comstock account works fine. I added a bunch of MTK related bits to the wiki. Hopefully it's not too much or "out of style" or "vaporware". I tried to limit myself to stating facts that I am confident about.

I should probably try and fiddle some more with my simple-serial.py script to provide basic chip-id POC for various devices. I can use the osmocom-bb wiki as a place to share notes on addresses I find and such.

I ran into a snag trying to support a blink firmware on both sciphone dream g2 and fernvale since sciphone doesn't have an LED that I can find and the LCD Backlight is more complicated than the simple fernvale poke a value into an address. :( I also tried to figure out an LED blink firmware for ZTE Obsidian/MT6735 but again it looks more complicated according to linux kernael sources I found... a bunch of PWM stuff to fiddle with there.

Thanks and let me know where to RTFM about adding things to the wiki properly if there is a doc/page about that.

Craig


From laforge at gnumonks.org  Fri Feb 16 07:31:59 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Feb 2018 08:31:59 +0100
Subject: [OsmoBTS - Bug #2944] OsmoBTS master does not work with
 CalypsoBTS based transceivers
In-Reply-To: <redmine.journal-7646.20180215183849.5333785e6e1f1125@lists.osmocom.org>
References: <redmine.issue-2944.20180213231600@lists.osmocom.org>
 <redmine.journal-7646.20180215183849.5333785e6e1f1125@lists.osmocom.org>
Message-ID: <20180216073159.GM13099@nataraja>

On Thu, Feb 15, 2018 at 06:38:50PM +0000, pespin [REDMINE] wrote:
> So we now have the patches reviewed (+2) but due to the branch being old and having no jenkins.sh, Jenkins Builder set validate -1, and I'm not able to merge it. Help on how to fight against gerrit is required here.

I could manually override the V-1 and set it to V+1.

However, I guess the better solution would be to first merge a patch
that adds jenkins.sh to the respective branch, and then re-trigger the
validation of those patches.  This way we would have a working solution
even for future patches.

Or even better: Rebas those old but still relevant branches on top of
current master, and they would get the jenkins.sh and associated build
verification for free.

Do we have any volunteers for this?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Feb 16 07:51:42 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Feb 2018 08:51:42 +0100
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180216044850.GA14304@localhost.localdomain>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180214025242.GA20211@localhost.localdomain>
 <20180214120811.GW13099@nataraja>
 <20180216044850.GA14304@localhost.localdomain>
Message-ID: <20180216075142.GP13099@nataraja>

Hi Craig,

On Thu, Feb 15, 2018 at 10:48:50PM -0600, Craig Comstock wrote:
> The craig_comstock account works fine. I added a bunch of MTK related
> bits to the wiki. Hopefully it's not too much or "out of style" or
> "vaporware". I tried to limit myself to stating facts that I am
> confident about.

I did a quick review and think everything is fine with the way you added
information.

> I should probably try and fiddle some more with my simple-serial.py
> script to provide basic chip-id POC for various devices. I can use the
> osmocom-bb wiki as a place to share notes on addresses I find and
> such.

great.

> I ran into a snag trying to support a blink firmware on both sciphone
> dream g2 and fernvale 

well, I think the really interesting part of those devices is their
cellular/RF side, not the LEDs :P  But well it's of course your time and
your decision how to spend it :)

> Thanks and let me know where to RTFM about adding things to the wiki
> properly if there is a doc/page about that.

I don't think there are any manuals about this, aside from the redmine
wiki syntax reference.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From craig at unreasonablefarm.org  Fri Feb 16 13:49:29 2018
From: craig at unreasonablefarm.org (craig at unreasonablefarm.org)
Date: Fri, 16 Feb 2018 07:49:29 -0600
Subject: sciphone dream g2 mtk 6235 status? ;)
In-Reply-To: <20180216075142.GP13099@nataraja>
References: <20180204044755.GA22057@localhost.localdomain>
 <DBD7D9F1-8B03-4759-AEB2-B34005B00C6E@gnumonks.org>
 <20180214025242.GA20211@localhost.localdomain>
 <20180214120811.GW13099@nataraja>
 <20180216044850.GA14304@localhost.localdomain>
 <20180216075142.GP13099@nataraja>
Message-ID: <20180216134929.GA15552@localhost>

> well, I think the really interesting part of those devices is their
> cellular/RF side, not the LEDs :P  But well it's of course your time and
> your decision how to spend it :)

Yes. Was just trying to get a simple/quick "it works" firmware to confirm loading. Next step is probably porting serial comm from fernly into a layer1 start.

Craig


From laforge at gnumonks.org  Fri Feb 23 08:54:36 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 23 Feb 2018 09:54:36 +0100
Subject: port numbers in FakeTRX / trxcon
Message-ID: <20180223085436.GM16326@nataraja>

Hi Vadim,

while playing with fake_trx and trxcon I was wondering about the port
numbers you used.

I think it's not the best idea to re-use the same port numbers / port
number range on the MS side which are used on the network side.  Is
there any requirement to do so?  why not simply shift the entire base
port (5700) on the client side to something else like 6700?

(Side note: The entrire TRX protocol using so many non-standard/non-IANA port
 numbers, not containing any version numbers for extensions, etc. is a mess,
 but that's for a separate discussion altogether.  Would love to re-do
 this from scratch at some point)

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From axilirator at gmail.com  Fri Feb 23 10:09:01 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 23 Feb 2018 17:09:01 +0700
Subject: port numbers in FakeTRX / trxcon
In-Reply-To: <20180223085436.GM16326@nataraja>
References: <20180223085436.GM16326@nataraja>
Message-ID: <CAPEnp=b6nywE716+Wd7biMNwWm6C71wfwyeKpXfFzffPNBCMrQ@mail.gmail.com>

Hi Harald,

> I think it's not the best idea to re-use the same port numbers / port
> number range on the MS side which are used on the network side.  Is
> there any requirement to do so?  why not simply shift the entire base
> port (5700) on the client side to something else like 6700?

There is and was no requirement. I didn't expect this problem
during the initial development process of trxcon, but then also
started to think about changing the default port range.

So, I definitely agree with you and 6700 is fine for me.
I've already updated your change to use it:

https://gerrit.osmocom.org/#/c/6839/

With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20180223/ecc378c2/attachment.htm>

From holger at freyther.de  Sun Feb 25 22:08:13 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 25 Feb 2018 22:08:13 +0000
Subject: Approach to system testing for Osmocom stack
In-Reply-To: <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>
References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de>
 <20180110115513.GZ13147@nataraja>
 <F91114EE-EA17-4A83-B369-52FD12262C26@freyther.de>
 <20180110233926.GE13147@nataraja>
 <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de>
 <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de>
 <20180129105017.GM6630@nataraja>
 <54F00998-3383-47E2-8399-E53781864F3D@freyther.de>
 <84867A83-9E35-429A-9DE3-308BC3DDB710@freyther.de>
 <050F2DA3-1B7E-45E1-894F-0A14BC42680E@freyther.de>
Message-ID: <56C2A12A-7051-452F-85D8-159D83BA303F@freyther.de>



> On 7. Feb 2018, at 09:31, Holger Freyther <holger at freyther.de> wrote:
> 

Hey,


> Knowing what I know now I would have gone for Go. It is made for the kind of
> concurrency where python seems unusable. I hesitated to build my own event
> loop but will build something that looks like our C apps in python (single
> select, no async/await).


finally... still plenty of things to improve and do... The next thing is to
improve "mobile" to not add the >30s timeout for first cell selection.



python3 -mosmo_ms_driver
22:59:56.255200 ---                                -: Going to store files in  {tmp_dir='/tmp/tmp5wbisu2hosmo-ms-driver'}
22:59:56.256180 run                          lu_test: Starting testcase
22:59:56.256813 run                          lu_test: Pre-launching all virtphy's
22:59:56.257391 run                    osmo-ms/00000: Starting virtphy process  [lu_test?osmo-ms/00000]
22:59:56.258454 run                    osmo-ms/00000: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00000  [lu_test?osmo-ms/00000]
22:59:56.262654 run                    osmo-ms/00001: Starting virtphy process  [lu_test?osmo-ms/00001]
22:59:56.262793 run                    osmo-ms/00001: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00001  [lu_test?osmo-ms/00001]
22:59:56.269087 run                    osmo-ms/00002: Starting virtphy process  [lu_test?osmo-ms/00002]
22:59:56.269241 run                    osmo-ms/00002: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00002  [lu_test?osmo-ms/00002]
22:59:56.274869 run                    osmo-ms/00003: Starting virtphy process  [lu_test?osmo-ms/00003]
22:59:56.275031 run                    osmo-ms/00003: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00003  [lu_test?osmo-ms/00003]
22:59:56.280416 run                    osmo-ms/00004: Starting virtphy process  [lu_test?osmo-ms/00004]
22:59:56.280570 run                    osmo-ms/00004: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00004  [lu_test?osmo-ms/00004]
22:59:56.285699 run                    osmo-ms/00005: Starting virtphy process  [lu_test?osmo-ms/00005]
22:59:56.285809 run                    osmo-ms/00005: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00005  [lu_test?osmo-ms/00005]
22:59:56.291308 run                    osmo-ms/00006: Starting virtphy process  [lu_test?osmo-ms/00006]
22:59:56.291488 run                    osmo-ms/00006: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00006  [lu_test?osmo-ms/00006]
22:59:56.300046 run                    osmo-ms/00007: Starting virtphy process  [lu_test?osmo-ms/00007]
22:59:56.300352 run                    osmo-ms/00007: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00007  [lu_test?osmo-ms/00007]
22:59:56.306980 run                    osmo-ms/00008: Starting virtphy process  [lu_test?osmo-ms/00008]
22:59:56.307134 run                    osmo-ms/00008: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00008  [lu_test?osmo-ms/00008]
22:59:56.312373 run                    osmo-ms/00009: Starting virtphy process  [lu_test?osmo-ms/00009]
22:59:56.312526 run                    osmo-ms/00009: virtphy --l1ctl-sock=/tmp/tmp5wbisu2hosmo-ms-driver/osmocom_l2_00009  [lu_test?osmo-ms/00009]
22:59:56.319714 run                          lu_test: Checking if sockets are in the filesystem
22:59:56.539503 run                    osmo-ms/00000: Starting process  [lu_test?osmo-ms/00000]
22:59:56.539977 run                    osmo-ms/00000: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00000.cfg --vty-port=0  [lu_test?osmo-ms/00000]
22:59:56.607714 run                          lu_test: MS start registered  {at=282743.473796635, delay=0.06289598299190402, ms=00000}
23:00:09.926047 run                    osmo-ms/00001: Starting process  [lu_test?osmo-ms/00001]
23:00:09.926563 run                    osmo-ms/00001: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00001.cfg --vty-port=0  [lu_test?osmo-ms/00001]
23:00:09.994826 run                          lu_test: MS start registered  {at=282756.860905894, delay=0.06362233200343326, ms=00001}
23:00:15.424151 run                    osmo-ms/00002: Starting process  [lu_test?osmo-ms/00002]
23:00:15.425052 run                    osmo-ms/00002: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00002.cfg --vty-port=0  [lu_test?osmo-ms/00002]
23:00:15.488956 run                          lu_test: MS start registered  {at=282762.355019533, delay=0.05711088899988681, ms=00002}
23:00:19.724246 run                    osmo-ms/00003: Starting process  [lu_test?osmo-ms/00003]
23:00:19.724996 run                    osmo-ms/00003: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00003.cfg --vty-port=0  [lu_test?osmo-ms/00003]
23:00:19.785684 run                          lu_test: MS start registered  {at=282766.651760042, delay=0.05416889599291608, ms=00003}
23:00:23.325812 run                    osmo-ms/00004: Starting process  [lu_test?osmo-ms/00004]
23:00:23.326760 run                    osmo-ms/00004: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00004.cfg --vty-port=0  [lu_test?osmo-ms/00004]
23:00:23.393305 run                          lu_test: MS start registered  {at=282770.259381962, delay=0.06159330299124122, ms=00004}
23:00:26.427752 run                    osmo-ms/00005: Starting process  [lu_test?osmo-ms/00005]
23:00:26.428336 run                    osmo-ms/00005: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00005.cfg --vty-port=0  [lu_test?osmo-ms/00005]
23:00:26.494263 run                          lu_test: MS start registered  {at=282773.360336693, delay=0.059708705986849964, ms=00005}
23:00:29.627894 run                    osmo-ms/00006: Starting process  [lu_test?osmo-ms/00006]
23:00:29.628553 run                    osmo-ms/00006: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00006.cfg --vty-port=0  [lu_test?osmo-ms/00006]
23:00:29.683842 run                          lu_test: MS start registered  {at=282776.54991861, delay=0.04898471699561924, ms=00006}
23:00:33.226115 run                    osmo-ms/00007: Starting process  [lu_test?osmo-ms/00007]
23:00:33.226723 run                    osmo-ms/00007: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00007.cfg --vty-port=0  [lu_test?osmo-ms/00007]
23:00:33.288238 run                          lu_test: MS start registered  {at=282780.154311069, delay=0.055712109024170786, ms=00007}
23:00:34.052813 run                          lu_test: MS performed LU  {at=282780.918918862, lu_delay=37.44512222701451, ms=00000}
23:00:37.525812 run                    osmo-ms/00008: Starting process  [lu_test?osmo-ms/00008]
23:00:37.526370 run                    osmo-ms/00008: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00008.cfg --vty-port=0  [lu_test?osmo-ms/00008]
23:00:37.590594 run                          lu_test: MS start registered  {at=282784.456672404, delay=0.05611523304833099, ms=00008}
23:00:43.028214 run                    osmo-ms/00009: Starting process  [lu_test?osmo-ms/00009]
23:00:43.028898 run                    osmo-ms/00009: mobile -c /tmp/tmp5wbisu2hosmo-ms-driver/mob_00009.cfg --vty-port=0  [lu_test?osmo-ms/00009]
23:00:43.087549 run                          lu_test: MS start registered  {at=282789.95362104, delay=0.05322436196729541, ms=00009}
23:00:43.087727 run                          lu_test: All started... {duration=46.56737156602321, too_slow=0}
23:00:47.231257 run                          lu_test: MS performed LU  {at=282794.097388755, lu_delay=37.23648286098614, ms=00001}
23:00:52.878843 run                          lu_test: MS performed LU  {at=282799.744935023, lu_delay=37.38991548999911, ms=00002}
23:00:56.661687 run                          lu_test: MS performed LU  {at=282803.527769994, lu_delay=36.87600995198591, ms=00003}
23:01:00.411273 run                          lu_test: MS performed LU  {at=282807.277505226, lu_delay=37.01812326401705, ms=00004}
23:01:04.194030 run                          lu_test: MS performed LU  {at=282811.06022426, lu_delay=37.699887567025144, ms=00005}
23:01:06.060154 run                          lu_test: MS performed LU  {at=282812.926287126, lu_delay=36.37636851600837, ms=00006}
23:01:09.847484 run                          lu_test: MS performed LU  {at=282816.713489132, lu_delay=36.559178063005675, ms=00007}
23:01:15.475567 run                          lu_test: MS performed LU  {at=282822.341696909, lu_delay=37.8850245049689, ms=00008}
23:01:21.124497 run                          lu_test: MS performed LU  {at=282827.990630504, lu_delay=38.037009463994764, ms=00009}
23:01:56.525619 run                          lu_test: Tests done {all_completed=True, max=38.037009463994764, min=36.37636851600837}