Hi all!
As Andreas has pointed out to me in a phone call yesterday and steve-m
mentioned on IRC: Building layer23 with the not-installed (make
install) libosmocore from osmocom-bb resulted in link failures.
I've now addressed those problems and the repo should be building just
fine again.
Regards,
Harald.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Prom!
I've now merged (a rebased version of) your prom/pending, including the
manifest part.
Only one minor issue that I've noticed: 'make clean' does not remove
the board/*/*.manifest.o files. Maybe you can fix that at some point.
Also, I think it would be better to only export a 'struct manifest' that
then has members for all the various parameters (so far only strings
with versions, but there might be more stuff in the future).
Thanks,
Harald.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello Harald,
On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Also, layer1 TX side still has a problem where it transmits the bursts
> all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are
> received correctly by the BTS, the other burst is sent at a different
> (wrong!) point in time, disturbing some other phone on the same cell.
With my fix from a while ago sending works as expected. In the meantime
I extended my test code so that I could also verify the correct behaviour
against a GSM test set when doing a Location Update.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
currently i am working on radio ressource layer and the sub processes
for 1) network selection, 2) cell selection, and 3) location update
trigger process. i have problems expecially with the cell selection
task. since it requires measurements and detection of carriers (for some
time depending on the slot configuration), it must work together with
the layer 1 (radio part). here are some examples of messages what i
think must exist between layer 1 and cell selection process:
(the primitive names are just examples and do not conform to GSM specs.)
L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated
mode (by given channel, frequency and later hopping sequence)
L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given
frequency)
L1CTL_IM_EST_CNF confirm valid carrier signal.
L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell
selection (depends on the channel configuration), shall include
measurement
L1CTL_MEAS_IND periodic info of measurements from the selected channel.
(required for cell reselection)
take these only as examples, not as required messages. while reading GSM
05.08, this is what i think is required to do cell (re-)selection
process or abort radio connection if fails (below minimum level).
any help/ideas/suggestions?
andreas
Hi Andreas,
some comments to your issues.txt:
> How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES)
> what triggers the sending? Or do we just send it from time to time to
> layer 1 where it is stored and sent when the time is right? (Then we
> might get something like RSL_MT_MEAS_CNF, so we can send the next one,
> if we have new measurements available, otherwhise the L1 will use the
> old measurement results and resends them without confirming it.)
measurement results are sent on the SACCH. The Layer1 has independent
transmit queues for the main channel (SDCCH/TCH) and its associated
SACCH. So the L23 code needs to send the respective packet to a
chan_nr/link_id that indicates transmission over the SACCH.
In the GSM TS, there is a primitive by which L1 can indicate that it
needs the next L23 message for a given channel, which we don't implement
(as we're tunnelling L1CTL through HDLC/serial, the answer would never
be back before the next TDMA frame anyway).
My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in
L1CTL, and every time we actually dequeue the frame (i.e. send it to the
DSP), send an indication of the current queue depth up to L23. We
should do this for both the main and the ACCH queue so higher layers can
implement some kind of flow control if they want.
> I need some RACH primitives like:
> - RACH request (tx_ph_rach_req already exists) including value and
> offset of RACH slot from now.
What exactly do you mean with 'value and offset of RACH slot from now'?
As we're operating asynchronously "now" is not defined precisely. I
think if you simply tell the L1 that you want to transmit at a specified
GSM time (modulo 51), we can schedule it that way.
L23 should understand the current CCCH/BCCH layout and determine which
lsots are applicable for RACH burst transmission. They can then either
say "please transmit at this full gsm time (uint32_t of the frame
number)" or "please transmit in next multiframe at fn % 51 == X where X
is something specified by L23"
> - RACH confirm, the RACK has been sent (with timeslot where is was sent)
that should be relatively easy to add, I'll add it during the next days.
Meanwhile we can simply assume that it was sent at the timeslot as
requested.
> Since RACH request must be queued in layer 1 until it the right slot
> is reached, I need to tell L1 to cancel it. Whenever I receive a
> confirm, I schedule the next one until the maximum number has been
> transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH.
I think we can ignore that for now. In the worst case, we send one more
RACH request than needed. I know this is dangerous if done by many
phones on real networks, but for our current goal of "getting something
working in our own gsm test network" this is the kind of shortcut we can
take.
I know your development style is very different. You seem to be trying
to implement something thats fully compliant with the spec. I usually
try to take a more incremental/iterative approach. Make something work
first, and then iteratively improve/complete it. I hope you can live
with the fact that at least for now, L1 doesn't have this support. If
you want, we can already define the L1CTL message for it but simply
ignore it on L1 until its implemented.
> RACH request on RSL:
> Does it make sense to put RACH request to the set of RSLms primitives?
> (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN)
> What do you say?
I think we should mark them explicitly as RSLms_MT_* to make it obvious
that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is
probably causing misunderstanding, lets just write the full word.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
I've added support for the Calypso "non-secure" romloader in my branch
steve-m/osmocon.
This means we now can execute our code on devices like the Motorola
W220, the BenQ A38 (which I've used for development), and the OpenMoko
devices (can anyone try to cross-compile osmocon and see if it works?).
For more information see in the wiki:
http://bb.osmocom.org/trac/wiki/CalypsoRomloader
I also added a new model switch for the C140 (-m c140), which
automatically adds the "1003" string in the uploaded binary.
This is meant for use with proms loader, so now you can upload
loader.ramload.bin on the C139/C140 and J100i, and load the application
itself with osmoload.
Regards,
Steve
Hi Harald,
That's a bright idea for all the developers behind the project as well as
those observers around the project to make a brainstorm with the development
and evolution of the project.
It's a little pity, however, for those people not going to participate
directly in the Developer Meeting at CCC near Berlin. If setting up a "green
pathway" connecting to the live meeting on the internet, so the people
strongly wanna share their ideas with others will be able to join into the
Developer Meeting simultaneously.
If there has difficulty in doing such things, maybe recording and uploading
the live video of the meeting into the public wiki of the project is another
way to share the content and fun of the meeting together with other people
all around the world.
Thanks.
Best Regards,
Samuel
On Mon, Apr 5, 2010 at 6:00 PM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte)
> 2. Re: noisy cable? (Nathan Fain)
>
>
> ---------- Forwarded message ----------
> From: Harald Welte <laforge(a)gnumonks.org>
> To: baseband-devel(a)lists.osmocom.org
> Date: Mon, 5 Apr 2010 09:24:45 +0800
> Subject: Developer Meeting in Berlin / 2010-04-10
> Hi all!
>
> Since I'm returning from holidays in two days, I think it's a good idea
> (for those who are in/around Berlin) to meet again at CCC Berlin.
>
> This is mainly for me to get an idea where we are (compared to before my
> holidas) and how we proceed. Especially the loader seems to have made
> progress, as far as I can tell from casual reading of the commitlog.
>
> I'm also curious to see what's happening on the battery charger, sim
> card reader (and other) parts of the system.
>
> I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in
> joining, feel free to join!
>
> Cheers,
> Harald
> --
> - Harald Welte <laforge(a)gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
>
>
>
>
> ---------- Forwarded message ----------
> From: Nathan Fain <nat(a)fains.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Sun, 04 Apr 2010 22:17:38 -0700
> Subject: Re: noisy cable?
> fyi, using the /dev/cu.** variant solved my problem of osmocon being
> unable to write CMD1 to the port. At least, it worked with an FTDI
> cable I built. I imagine it will solve the issue with the prolific
> cable as well (will try later).
>
>
>
> On 29/03/2010 03:39, willem wrote:
> > i managed to get hello_world working on my c121, connected through a
> > pl2303 usb/serial cable to my macbookpro.
> >
> > but found that the connection is extremely noisy.
> > often the movement of me putting down the phone on the table is enough
> > to break the upload.
> > is that a common problem with these headphone/serial cable plugs?
> >
> >
> > for the serial device i can use /dev/cu.PL2303-0000201A
> > or /dev/tty.PL2303-0000201A
> >
> > but when using the '/dev/tty...' variant, i have to add this to
> osmocon.c
> >
> > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
> > index f934dd7..b361eb1 100644
> > --- a/src/host/osmocon/osmocon.c
> > +++ b/src/host/osmocon/osmocon.c
> > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
> > /* hardware flow control off */
> > options.c_cflag &= ~CRTSCTS;
> >
> > + /* ignore modem status lines */
> > + options.c_cflag |= CLOCAL;
> > +
> > /* software flow control off */
> > options.c_iflag &= ~(IXON | IXOFF | IXANY);
> >
> > =============================
> >
> > willem
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
hi harald,
i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin?
in our company we do it this way:
- a conference number is dialed by all members.
- a phone with hands free option can be used on one place where multiple members are.
- netmeeting is used for presentation. this can also be via VNC remote desktop.
is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command?
my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number.
regrads,
andreas
-----Ursprüngliche Nachricht-----
Von: baseband-devel-bounces(a)lists.osmocom.org [mailto:baseband-devel-bounces@lists.osmocom.org] Im Auftrag von Harald Welte
Gesendet: Montag, 5. April 2010 03:25
An: baseband-devel(a)lists.osmocom.org
Betreff: Developer Meeting in Berlin / 2010-04-10
Hi all!
Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin.
This is mainly for me to get an idea where we are (compared to before my
holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog.
I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system.
I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join!
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi,
the current state of coding can be seen in the
src/host/gsm48-andreas/README file of GIT. as noted there, the process
of mobility management and call control is completed. this does not mean
that it is compiling and working. als debugging has to be completed. the
next step would be to follow the compiler errors step by step until all
missing and wrong symbols are found and fixed. i will do that later.
also the radio ressource is at a point where i like to start integrating
it into the layer23 application. today i checked out how the system
informations are received and how to send a random access burst. please
check out the issues about that at src/host/gsm48-andreas/issues.txt in
the GIT.
i must note that layer3.c and rslms.c is not needed in my case, since it
is part of gsm48_rr.c
in order to integrate it, i would like to open a new branch, since there
are many other existing files to be expanded. (new structures to header
files... see extra.c and extra.h) there must also be a way to get all
the changes in the master branch merged to the new branch, so i can
react on changes of master branch. i am not that familiar with git, so
is there any advice except cherry-picking all the time? or maybe there
is a better way of doing that?
andreas
i managed to get hello_world working on my c121, connected through a
pl2303 usb/serial cable to my macbookpro.
but found that the connection is extremely noisy.
often the movement of me putting down the phone on the table is enough
to break the upload.
is that a common problem with these headphone/serial cable plugs?
for the serial device i can use /dev/cu.PL2303-0000201A
or /dev/tty.PL2303-0000201A
but when using the '/dev/tty...' variant, i have to add this to osmocon.c
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
index f934dd7..b361eb1 100644
--- a/src/host/osmocon/osmocon.c
+++ b/src/host/osmocon/osmocon.c
@@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
/* hardware flow control off */
options.c_cflag &= ~CRTSCTS;
+ /* ignore modem status lines */
+ options.c_cflag |= CLOCAL;
+
/* software flow control off */
options.c_iflag &= ~(IXON | IXOFF | IXANY);
=============================
willem
