hi,
i like to give a short update:
currently i am testing the processes of selecting a cell and the
network. the processes depend on the coverage, the sim card (network,
inserted or not) and the mode (manual or automatic network selection). i
hope i will finish this week.
to configure mode and sim card and other parameters in the future, i use
the VTY, you already know from the OpenBSC project. there you can get
informations about the subscriber, the mobile station and the received
cells (system informations).
i will move all hacked parameters (test sim) to VTY config file. manual
network selection mode requires reaction of the user, so it will also be
added to the VTY. later the VTY can also command the "call" part to
dial, answer and hangup a call.
my idea: later these VTY command structure may be used for the phone's
menu (up - down - enter - escape), if compiled appropiate. also: if
layer 3 is running on the phone, the serial port could directly connect
to the VTY, so the phone gets a console interface for debugging and
faster configuration.
currently the process (with sim card) ends while trying to do a location
update. if the given channel is not supported, the program exits. to
prevent this, just keep radio TX feature disable. the cell will be
re-selected again and again (hopefully if the process works correct).
sometimes, especially at the first run, the radio process stops. (no
results for measurements, no sync to selected frequency.)
also there is something i am wondering: calibration especially for the
burst signal phase is measured and then stored on the eeprom by the
manufacturer. do we use it? or do we need to do our own calibration?
regards,
andreas
Hi all!
In case you're interested, there seems to be a public project on
code.google.com that contains the build environment and baseband
firmware sdk from mediatek:
svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project
Please note that I don't know about the legality of this. However, it
is distributed on a public server/service without any kind of
authentication...
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!
Right now, one of our many issues in L1 is the frequency stability
(or lack thereof).
What we do right now is very primitive and is mostly based on guesswork,
rather than measurements and good algorithms.
In order to change this, we need some measurements to be done. As I am
currently again travelling a lot, and my time for OsmocomBB is more
limited now, I hope that somebody else will be able to take the
measurements as described below.
There is a big number of people in this project who now have a Racal 6103 (or
similar) measurement device. Also, for those in Berlin, the CCC Berlin has
one in its basement lab.
What needs to be done:
1) Determine the relation between AFCDAC output and actual carrier
frequency.
All that is needed is some manual control over the AFCDAC value (e.g. based on
keypad events) while the AFC is disabled.
Then we continuously transmit bursts (content is unimportant) to the
Racal 6103 and note the measured frequency error by the 6103 for every
AFC value that we input. Those measurements should then be repeated
for each supported band of the phone, preferrably each with a low-frequency
channel, a medium frequency and a high-frequency channel.
This means something like 10 different AFC values for 3 different channels
of each of the 2 bands that the c123/c155 support.
Basd on those measurements (preferrably do that series with 2-3 phones)
we can construct a function that will tell us which AFCDAC value we
should program if we want a given carrier frequency increase/decrease.
2) Determine the temperature related frequency drift and corresponding
temperature ADC reading
Especially when we transmit, the temperature in the RF section of the
phone is assumed to change quite a bit. This means we need to measure
the temperature in the oscillator (using the RITA-internal temperature
sensor connected to one of the ADC channels of IOTA) and compare that
with the frequency drift.
In order to measure this, we first need a temperature-ADC driver. Once
that exists, we can lock onto a BCCH, then make sure the AFC is disabled
and the AFCDAC output value will be stable. Next, one can use e.g. a
hairdryer or ice spray to change the temperature. While doing that, we can
measure the difference in carrier frequency with the Racal 6103.
The absolute temperature in centigrade/kelvin is not actually interesting to
us all. All we want to know is: What is the 6103-measured frequency error at
a given temperature-ADC-reading.
Once again, the measurements should be done for high (1800) and low (900)
band independently, just to be sure.
Based on their relation we can also model a function, table or other
approximation and include that in our AFC code.
I think I'll be able to write the code even while I'm on the road - if
somebody is able to do the measurements and post them to the mailing list.
Thanks in advance,
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,
I checkout the prom/loader AND prom/loader-crc part and merged it
(perhaps I use git wrong way)
When I run the loader with "osmcon -m c123xor" the loader starts but
says "Failed to initialize flash".
I tried to "romload" it with "-m romload" there only beacons but no
valid response from phone.
Sending beacon...
Sending beacon...
got 1 bytes from modem, data looks like: ff
got 1 bytes from modem, data looks like: 00
got 1 bytes from modem, data looks like: ff
Sending beacon...
Sending beacon...
Sending beacon...
Sending beacon...
1. Why the flash initialization fails?
2. Is it (currently) possible to run programs (ex. L1test from
flash)?
I (think I)read all this rom/ram/bootloader stuff.
-------------------------
Marco Rust
FOKUS - Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31, 10589 Berlin
marco.rust(a)fokus.fraunhofer.de
hi,
tests with layer 3 pointed out a problem. when i select a cell, i get
updates of system informations, paging requests and immediate
assignments. after about half an hour, i get some corrupt frames. i
don't know yet what is wrong.
1. is the communication between the layer 1 and layer 2 (over serial
link) secure?
2. i must be sure that a message between layers always are:
- never get lost (except unit-data or data when connection is aborted)
- never are corrupt
- received in the order they are sent
3. does layer 1 drop (bcch) frames, if they have biterrors? (as it
should do)
andreas
