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)
On 06/08/2010 09:41 PM, Huseyin Turan wrote:
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc
> -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a
> Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15
> UTC 2010 i686 GNU/Linux
>
please try b.) again (you miss the file part) and also please reply to
the mailinglist.
Hi!
It's about time that we find some kind of graphical project logo for the
Osmocom project.
Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN,
OsmocomBB and others.
So it might even be interesting to have some kind of 'family' of logos that
all have the same general theme.... At least the bigger projects like OpenBSC
and OsmocomBB definitely deserve their own incarnation within that family.
If you want to contribute to our project but are not a die-hard C developer,
this is your option to contribute!
The logo must be under a license that permits use+modification for the
Osmocom project itself. Editability for the general public is not important.
With regard to formats, I would prefer something as SVG that we can then
render into pngs of various sizes whenever there is demand for it.
If you have a proposal, simply send it (or a link to a URL) to the
openbsc(a)lists.gnumonks.org mailing list.
Thanks in advance for any submissions!
--
- 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)
>Do you already have experience with Osmocom and tried it
>with a phone ?
No i haven't , tried Osmocom with a phone yet, i have C139 and C117 available, once i tried but it reach up to downloading finish (of binary in firmware folder). after that it keeps in that state for quite some time and shows download NACK after wards, something went wrong , then operation aborted. i tried many times with it. As i don't have much experience with HDLC or serial communication to UART, some binary files even do not download completely and receive FMTOOL abort.. while downloading
I'm using prolific USB serial DATA cable ( seems very noisy) but no choice as my notebook doesn't have a serial port :-( I'm thinking to assemble new PC though.
I need you kind suggestions in this regard.
>What exactly do you want to do ? Only receive voice traffic ?
>You want to switch to an ARFCN and timelslot and listen to
>the voice traffic ? Of course this only works if the channel
>is not encrypted or you have Kc for decryption.
Yet again if i'm able to run the code and even able to interact using L2/3 or osmoload with phone i don't know how to use phones analogue BaseBand ( ADC) and download the fetched raw data after ( (of desired ARFCN n TS) to host PC and save it in *.cfile format or MatLab( simulink) supported format , if i'm able to do up to this extent i'm pretty sure i can convert it into Voice as i'm reasonably sound with MatLab...
Of course , the TCH/F should be without encryption, but i will create a interface in MatLab codes to supply Kc , if available, for future use. ( for digital BB processing )
>What about frequency hopping ? Without knowing the hopping
> sequence its not possible to follow a hopping channel.
Though i'm not die -hard with C or C++ , but rather fine.
have previous understanding for implementing frequency hopping in ISM band,
have seen protocol analysis using wireshark we can can easily extract hopping
sequence and and chase it , big problem is not to tune PLL synthesizer, but Time slot. and collecting the buffered data for processing , for this i have clear vision, i will share my source codes with you once finish my work.
Hello Dev,
On Sat, 31 Jul 2010 04:21:57 -0700 (PDT), "Dev Purohit" <devpurohit19(a)yahoo.com> wrote:
> Yet again if i'm able to run the code and even able to interact using
> L2/3 or osmoload with phone i don't know how to use phones analogue
> BaseBand ( ADC) and download the fetched raw data after ((of desired ARFCN
> n TS) to host PC and save it in *.cfile format or MatLab( simulink)
> supported format , if i'm able to do up to this extent i'm pretty sure i
> can convert it into Voice as i'm reasonably sound with MatLab...
The DSP does not directly deliver the raw ADC samples. You can get them
with some tricks but this won't help much because the UART is not fast
enough to transfer them continuously to the PC.
As far as I know Sylvain is trying to get the demodulated raw data bits
out of the DSP, he can tell you better about his progress.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
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)
* Move away from dispatching L1CTL message using signals ...
Only L1CTL works like that and I just can't figure out why ... we
read the l1ctl messages just to move their data into another structure
to redispatch them to a handler ...
l1ctl.c should just contain:
- The l1ctl_tx_XXX primitives
- A function for the 'application' to register it's own handler for
L1CTL messages.
- The rx call back to be called by lower layer when a l1ctl frame
is received.
This one would get the frame, set the hdr pointers, do basic
checks, possibly allow signal dipatching for the RESET signal (which
is kinda special), and then just hand the frame to the registered
handler.
* Split lapdm.c : Currently it contains lapdm code and RSLms. They
should be split and lapdm code should not be tied to a specific usage
but be 'instantiated'/configured in each app as they see fit. Some app
might need to track more than 2 lapdm channels ...
- lapdm.c would be in common/ (more like an utility lapdm library
than 'business' code)
- rslms.c would probably be in mobile/
* Rework the app in misc/ to remove the over-engineered bits. It's
clear from the sources that layer23 intended to become the full
featured phone and as such, is split in a bunch of elements for ...
not much in the end since Jolly restarted from scratch, splitting
better. So I'd like to simplify as much as possible those apps while
still separating 'utilities' function (like dump_bcch) to allow re-use
between them.
Theses are only the first few steps. My goal is to make it more easy
to write small test applications and to clearly separate that from the
full featured / layered mobile implementation while still sharing the
relevant 'library type' code.
Cheers,
Sylvain
surely i agree! (as i noted in my last mail)
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Mittwoch, 28. Juli 2010 09:17
An: Sylvain Munaut
Cc: baseband-devel; Andreas.Eversberg
Betreff: Re: Some refactoring proposals
On Tue, Jul 27, 2010 at 09:02:02PM +0200, Sylvain Munaut wrote:
> Hi,
>
> >> * 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
>
> Ok, this is done. It's waiting in my pending branch with a bunch of
> other fixes. It requires a libosmocore update as well.
I'll wait for some feedback from Andreas. If he either agrees or doesn't care,
then I'll merge it.
> (I moved a func to libosmocore, which required to update it, which
> bringed the msgb checks, which broke the target build and required
> fixing, it also showed some bugs in fw and layer23 code that required
> fixing as well ...)
I've merged your pending libosmocore changes to libosmocore.git master.
--
- 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)
>> 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!