Hi Andreas,
some comments regarding your issues.txt:
> must random value in chan_request change on every resend or only on
> every RR establishment? (currently it changes on every RR
> establishment only.)
as far as I know, it has to change on every retransmission. Dieter is
probably the person who knows all RACH aspects in detail, maybe he can
comment on this.
> must be expanded: struct osmocom_ms:
no problem here, expand it how you see fit. I just generally prefer
caller-allocated structures to callee-allocated ones, and I'd like to
use static allocation whenever possible. So if there's only one 'struct
rrlayer' per ms, then we should simply include 'struct rrlayer' as
sub-structure of 'struct osmocom_ms', rather than having two structures
and pointers between them.
> OpenBSC: if tx-msg fails during process, the msg must be freed to
> avoid memory leak.
I don't understand, can you please explain this further?
> random acces via RSL?
I think we simply add some new / non-standard primitives, as it does not
have any notion of RACH bursts.
It might also be possible to encode it as UNIT DATA REQUEST for channel
(chan_nr) RACH (CCCH uplink), but then we still cannot specify details
like at which frame number, etc. From what I can see, your
RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement
we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom
RSLms message and nothing specified in the original RSLms spec.
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,
I started to play around with osmocon, but unfortunately my serial
cable (a FTDI232RL module from Sparkfun connected to the 2.5mm plug,
this one is set to 3v3 and worked flawlessly for several projects!)
seems to be quite unreliable in the host -> handset direction.
But to not procrastinate, I did some cleanup in osmocon to escape
non-printable output and added new "-c" option to start straight into
HDLC-mode without uploading any firmware to the mobile.
Are those kinds of mostly cosmetic patches appreciated or considered
unnecessary?
Chris
Hi,
what's currently the recommended toolchain for bb-osmocom?
The wiki says on http://bb.osmocom.org/trac/wiki/AreasOfWork
that most people are using gcc 4.0.2 from http://gnuarm.com/
but the binary there is only for x86_64 which I don't use.
So, as I've got to build from source, I'm going to download
the latest binutils/gcc/newlib(?) for that. Is it a good idea,
or are there known problems with gcc binutils 2.20.1/gcc 4.4.3?
Greetings,
Chris
Hi!
It seems we're loosing serial characters on their way from the (Linux)
PC to the phone.
I think I've seen this at some point in the past, but now I'm seeing it
constantly.
Let's assume we're trying to send the following sequence of bytes from
the PC side to the phone in one of the HLDC connections:
> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
what we actually get from the sercomm callback on the phone is:
> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a
> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
as you can see, there is a '00 01' missing between the '00' and the '02'.
Interestingly, putting a usleep(10000) after every serial write does not
solve the problem, so it is not timing related. We don't get any UART
overflows on the calypso, either.
If I change the data pattern, then the first bytes are transmitted fine,
but as soon as there is one 00 bytes, two characters are missing from
the stream.
If I strace osmocon, it is clear that we write every character,
including the null-bytes, and all of the writes are successfully.
I've again looked at (and played with) the termios settings, but could
not find any problem (nor solution).
It's also not the sercomm layer that is loosing bytes, as I the
characters appear already lost when printing them from within the
calypso UART driver, as you can see here:
getchar_nb(1) = 7e // flag character
getchar_nb(1) = 05 // hdlc
getchar_nb(1) = 03 // hdlc
getchar_nb(1) = 0a // l1ctl_hdr (undefined msg_type 10)
getchar_nb(1) = 00 // padding
getchar_nb(1) = 02 // here should be 00, 01, 02...
getchar_nb(1) = 03
getchar_nb(1) = 04
getchar_nb(1) = 05
[...]
Any ideas? It's really strange and I don't really know what else to do.
I'm quite sure our binaries contain multiple successive null-bytes and
their download is working great...
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 *,
i have an Motorola C123 without a battery and without a charger.
Can someone told me pinout of the battery Connector so that I can connect a nokia battery?
Or can I use a 5v power supply and connect it to the charger port and the phone boots without a main battery?
Bjoern
-----
#- Björn Riemer
#- FOKUS - Fraunhofer Institute for Open Communication Systems
#- -Sensor Applications and Networks -
#- Kaiserin-Augusta-Allee 31
#- 10589 Berlin, Germany
#- phone: +49 30 3463-7747
#- fax: +49 30 3463-8000
#- email: bjoern.riemer(a)fokus.fraunhofer.de <mailto:bjoern.riemer@fokus.fraunhofer.de>
#- http://www.fokus.fraunhofer.de <http://www.fokus.fraunhofer.de>
attached is a patch with several minor fixes:
added missing param in call to gsm48_rx_bcch.
added 'extern' in .h files for declarations of rsl_rlm_cause_strs and
target_board.
added several 'const' for strings.
removed useless 'bufptr,' from hexdump.
willem
Hello,
I'm very new here and I wanted to ask if you already choose an OS? On
the website I read that you don't want to use FreeRTOS. Is this
information still up to date? Which RTOS u want to use instead? I have
found a small summary of potential candidates at wikipedia:
http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
the best candidate seems to be BeRTOS, but i think it could be a little
bit too much (e.g. it has a complete graphics subsystem).
Regards
Arne
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: osmocon(a)ngolde.de
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hello Erik,
On Fri, 19 Mar 2010 09:51:48 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote:
>
> Yes. Mine has special US Tracfone firmware which seems to have a
> particularly evil unlock scheme. Cutting one of the balls in the BGA
> seems the way to do it..
I had a quick look at the bootloader from a dumped Tracfone C139
firmware. Its nearly the same the Osmocom loader supports, however
this special bootloader checks a flag in flash memory to decide wether
to allow RAM download or not. If it is disabled, only the FTMTOOL
check is done and no RAM download at the boot stage is possible.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
