Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
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've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/)
which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin
from August 21/22 this year.
Before sending a response, I would like to inquire whom of you would actually
have any intention of visiting this conference and spending time in the
developer room to work on OpenBSC or OsmocomBB ?
I think the idea is great to meet some of you guys [again], not only at the
annual CCC congress in winter. But there is little point for me to go there if
there is no interest from the wider project community.
Please provide your feedback ASAP.
--
- 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 merged a number of layer1 related changes that I've been working on
for quite some time.
The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been
replaced by L1CTL_FBSB_REQ. When issuing FBSB_REQ, you can specify what
tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB).
Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP
with result=0xff. This means there is now proper error reporting.
Let's say you want a relatively quick indication if the ARFCN specified
could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return
even more quickly. You will definitely get a response after some 15 TDMA
frames if there was a frequency burst or not.
Furthermore, I have changed some details of the FB/SB acquisition process:
Rather than waiting for a fixed amount (500) TDMA frames before switching from
FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency
delta and SNR. The frequency thresholds can actually be specified by L1CTL,
the SNR thresholds are hardcoded.
One problem with fast scanning was that by erroneous FB0 reports, we tuned our
VCO so far off the desired frequency that it never synced to any cell at all
anymore. I have reduced that problem by simply resetting the AFC-DAC to
its default value every time we start a FBSB acquisition.
Andreas: I think it would make sense to use the S_L1CTL_FBSB_RESP and
S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR,
you can immediately switch to the next ARFCN without wasting further time.
My next API change will be to introduce a separate command, i.e. FBSB_REQ
will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the
application will have to explicitly request that. However, I don't think I'll
find much time throughout the next 10 days or so.. .sorry :/
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,
* Daniel Willmann <daniel(a)totalueberwachung.de> [2010-05-17 11:48]:
> For now just copied over the compal_e88 init.c and adapted the RF
> frontend functions. For osmocon to work with the GSM download cable
> SERCOMM_UART_NR and CONS_UART_NR need to be switched.
[...]
> +/* describe how the RF frontend is wired on the Openmoko GTA0x boards */
> +
> +#define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */
> +#define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */
> +#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */
> +
> +/* All VCn controls are low-active */
> +#define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */
> +#define ASM_VC2 TSPACT(1) /* Antenna switch VC2 */
> +#define ASM_VC3 TSPACT(4) /* Antenna switch VC3 */
> +
> +#define IOTA_STROBE TSPEN0 /* Strobe for the Iota TSP */
> +#define RITA_STROBE TSPEN2 /* Strobe for the Rita TSP */
> +
> +/* switch RF Frontend Mode */
> +void rffe_mode(enum gsm_band band, int tx)
> +{
> + uint16_t tspact = tsp_act_state();
> +
> + /* First we mask off all bits from the state cache */
> + tspact &= ~PA_ENABLE;
> + tspact |= GSM_TXEN; /* low-active */
[...]
I'm not sure what the correct value is in this case but
GSM_TXEN is not defined at this point.
Cheers
Nico
Hello,
these patches enable osmocom to be run on the Openmoko GTA0x devices
(only tested with GTA02). The first patch fixes an issue with baudrate
setting in osmocon.c (termios setting wasn't read prior to writing). The
second patch adds a gta0x board (currently only copied from compal_e88)
and implements the differences in controlling the RF frontend.
Use it as follows (on the device):
kill all processes communicating with the modem (fso, gsm0710muxd)
gta02# echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/download
Then on the PC connect the download cable and start osmocon:
# ./osmocon -m romload -p /dev/ttyUSB0 ../../target/firmware/board/gta0x/l1test.osmoload.bin
To initiate the download toggle baseband power on the phone:
gta02# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on &&
> echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
After the firmware is transferred the app should start.
Regards,
Daniel Willmann
Daniel Willmann (2):
osmocon.c: Fix serial_set_baudrate function
Add new board gta0x (for Openmoko Freerunner devices) and build it
src/host/osmocon/osmocon.c | 5 +
src/target/firmware/Makefile | 4 +-
.../firmware/board/common/rffe_gta0x_triband.c | 88 +++++++++++++
src/target/firmware/board/gta0x/init.c | 131 ++++++++++++++++++++
4 files changed, 227 insertions(+), 1 deletions(-)
create mode 100644 src/target/firmware/board/common/rffe_gta0x_triband.c
create mode 100644 src/target/firmware/board/gta0x/init.c
Hi all,
I wanted to give a short status update on the MTK platform, I spent the
last day implementing a minimal subset of the MTK romloader protocol in
osmocon.
We can now run our own C-code on the MT622x, I started by modifying the
linker script and run proms loader (because it doesn't need interrupts,
the interrupt redirection isn't yet figured out).
When writing something to the UART TX register, I see the output in
osmocon, and writing to the Baseband powerup register works as well
(otherwise you would have to hold down the power-button all the time).
Unfortunately there are no schematics for the Mobistel phone I've been
testing this with, so I haven't found out how to enable e.g. the
backlight, nothing happens when activating PWM1/2.
Today I tried to modify the Calypso UART driver for the MTK UART, but
currently I'm stuck with a strange hang somewhere in the driver, maybe
I'll look after it tomorrow.
That was it for the moment...
Regards,
Steve
Hi,
I've recently got pointed to this project. Haven't dealt with any GSM software since the mid-90ies, so I thought it may be some fun
to look at the software and participate if I find enough time. I've got access to a Racal 6103 and a C123 to start with.
A couple of questions:
1) Do I need attenuators if I wire the C123 to the Racal? Guess not, but I don't want to fry the input of the Racal.
2) External antenna connector on the C123 seems to be a MS-147. I got a couple of HF cables from a WLAN card with
this connector:
http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Cri…
but the inner conductor of the plug seems to be a bit short (may be my fault during assembly).
Does the MS-147 jack on the C123 switch off the internal antenna if anything is plugged in?
3) Does the PA of the C123 survive without any antenna connected (i.e. if it gets most of the HF reflected back) e.g. in continuous transmit mode?
4) A C123 without battery doesn't start the vendor firmware, display is blank, LED are on, flicker from time to time.
Is this a hardware problem or just the vendor firmware missing the battery, i.e. any problem to download osmocom software without any battery?
Thanks for any answers!
Hi,
I converted the X font 5x8 for use in BB and added an goto_xy
routine in case anyone wants to put something entertaining on
the LCD (besides Hello World).
Compared to the old 8x8 font..
- doesn't miss the topmost line of pixels :-)
- needs 475 bytes instead of 4k (only includes characters
ASCII 32 .. 126)
- allows for 19x8 characters on the screen
hello_world.bin prints out all glyphs for testing.
Applies to current "master" (as of 9.4.2010/15:30 MESZ).
Chris
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
