>> Here's a few refactoring proposal that I'd like to get done. But
>> before I invest too much time in them I'd like to be sure there are
no
>> objections ... (I hate implementing stuff for nothing).
>>
>> * Split layer23/src into
>> - common: what makes liblayer23, purely generic stuff that needs
>> binding together to define an app
>> - mobile: The real complete mobile application
>> - misc: The test applications and their support code layer23 (which
>> I'd rename bcch_dump since that's what it does), echo_test,
bcch_scan)
>
> Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a
branch
> containing this split
i don't mind!
Hi All,
I just want to elaborate it my question is is there is some down link traffic between MS and a testing BTS , let say on ARFCN # 13 and Time slot 3 this traffic channel is non encrypted A5/0 , is osmocom BB or airprob is become to capable to tune to that particular ARFC in this case ARFCN no. 13 and time slot 3 and fetch the traffic channel data process it and convert it to pure voice or encode speech signals ( (CELP) or PCM format ) i specifically request to Harald as he is taking care for airprob also.
If these projects need more development to get this extent kindly guide me so that i can start my work and contribute to this project , why taken I have taken this approach is
1) will clarify other aspects and errors in this package to make a working, ready to use package. after wards we will start for transition section.
2) will confirm the feasibility and give all contributor a enthusiasm that we are developing significantly and can get at least any output from moths of hard work
3) will apply the changes and correct for the errors( instability) other developer and contributor will face or report during their voice reception.
i feel reception of voice , then transition of voice is very basic requirement of any mobile software, then we can add on other features like channel hoping , cell handovers, other UI features , various multimedia and messaging features..
thanks for your great work and wish to contribute at my best abilities..
--- On Fri, 7/23/10, Dev Purohit <devpurohit19(a)yahoo.com> wrote:
From: Dev Purohit <devpurohit19(a)yahoo.com>
Subject: progress..
To: baseband-devel(a)lists.osmocom.org
Date: Friday, July 23, 2010, 12:49 PM
Hello All,
My basic question is related to progress and accomplishment of this project and related project like airprob.
1 if any of these project have reached up to the point where Um or Abis interface traffic can be change to voice or at least to the stage where it can get PCM or ISDN level voice data
let say through layer1application we change synthesizer frequency to specific ARFCN, and tune to a specific TS. can it fetch traffic( without encryption, a5/0, testing down link traffic between MS and testing BTS ) channel and after base-band processing can it give voice data (either PCM o, analogue format, digital voice coding) if so what all sections/ applications will involve of this application or if this is possible through airprob so for now.
Thank you in advance..
Hello All,
My basic question is related to progress and accomplishment of this project and related project like airprob.
1 if any of these project have reached up to the point where Um or Abis interface traffic can be change to voice or at least to the stage where it can get PCM or ISDN level voice data
let say through layer1application we change synthesizer frequency to specific ARFCN, and tune to a specific TS. can it fetch traffic( without encryption, a5/0, testing down link traffic between MS and testing BTS ) channel and after base-band processing can it give voice data (either PCM o, analogue format, digital voice coding) if so what all sections/ applications will involve of this application or if this is possible through airprob so for now.
Thank you in advance..
Hi all
i run command osmocom-bb/src/host/osmocon# ./osmoload
Failed to connect to '/tmp/osmocom_loader'
and
osmocom-bb/src/host/layer23/src# ./layer23
Failed to connect to '/tmp/osmocom_l2'.
Failed during layer2_open()
kindly help me out with this i'm stuck..
Dev.
Hi all. I just swallowed the Osmocom red pill and am awaiting my Motorola
V171 which I just bought on eBay (it was the cheapest option).
I was interested in what people thought of the Contiki OS. I'm not an
expert, but this seems like a good option, since it's very compact, and has
been ported to many ARM-based devices.
Scott
> JFYI: The AGC control in L1 is now active. At least it didn't make
things
> worse for me. Maybe people who have had problems acquiring weak cells
> should give it a try again.
> I suggest to add the L1CTL_DM_REL_REQ into the state machine, I
suppose
> it should avoid that problem.
hi,
i will check this issue about releasing and establishment of dedicated
mode. also i will do the power control thing from L3.
i got stuck while transcoding RACH request / confirm from L1CTL into
RSL_CHAN_RQD/RSL_CHAN_CONF. the goal is to have pure RSL between layer 3
and layer 2. the biggest problem are things like power measurement, sync
requests and other L1CTL messages, all which are not defined for RSL
SAP. i don't like the idea about converting everything from L1CTL to RSL
and parsing it and vice versa. this take allot of time to implement,
also we would need to add several new messages and information elements.
my suggestion is to leave L1CTL as it is.
currently i think about how to control tx_power and TA (timing
advance/delay) from layer 3. it is not possible to set them in every
layer 3 message, because this message may be splitted or repeated or
layer 2 may send responses without interaction of layer 3. therefore we
must store the tx_power and TA at layer 2, and it must be sent with
every frame then. since we don't send any idle frame to layer 1 (this is
actually generated there), we can only give tx_power and TA at frames
with content. the values must be stored at L1 for idle frames. therefore
it think it would be much easier to use something like L1CTL_POWER_REQ
to set the current tx_power and a L1CTL_POWER_CONF to get the actual
(closest) power set. (also includes the TA). these values are stored and
for every frame sent afterwards until L1CTL_POWER_REQ is sent with
different values.
regards,
andreas
Hi,
I have been looking for sometime at OsmocomBB project, but haven't tied it yet.
I have seen that software supports a number of Compal phones :
Supported Phone hardware
Information specific to certain Calypso based phones that we support
Designed + Manufactured by Compal, OEM by Motorola
MotorolaC115/C117 (E87)
MotorolaC123/C121/C118 (E88) -- our primary target
MotorolaC140/C139 (E86)
MotorolaC155 (E99) -- our secondary target
MotorolaV171 (E68/E69)
SonyEricssonJ100i
So, I was wondering:
1) Which would be best to have to start with, as the most supported target ?
2) Where I can get this phone quickly and easily ?
3) What additional equipment is needed (how do you flash the software
and how do you debug) ?
4) Is there some software simulator in which I could see what is
happening and how the SW works without actual HW equipment ?
Best regards,
Drasko
hi,
i like to do extensions to the RSLms layer of osmocom. before that i
like to ask and discuss if this would be the correct way:
instead directly of calling l1ctl_* functions of l1ctl.c, i would like
to use RSL messages between layer 2 and layer 3. the lapdm.c would then
convert these messages and call l1ctl_* functions. (maybe i could split
up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an
RSL request could be made at layer2.c, as well as selecting the right
handler for the frames received from layer1. only the lapdm part could
be handled in lapdm.c. )
the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could
be the same message type, but i prefer to invent a new one: 0x18, but
using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the
RACH request, could tell the layer 1 about usage of power and TA (which
is normally 0 for RACH request).
the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if
omitted, the stored value from the last message with
RSL_IE_MS_POWER_PARAMS could used.
the (UNIT) DATA indication and request of SACCH may include
RSL_IE_L1_INFO IE to receive power and timing control as well as send
the actual power and timing advance. i could handle these IE at layer 3
(radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM)
depending on the supported radio power and on special VTY settings to
mess with power and fake timing advance.
regards,
andreas
