i found this, searching google/codesearch for 'ftm_cmd'
svn co http://hwplatform.googlecode.com/svn/trunk/
about 1.5G of datasheets, sourcecode, and tools
for various phones.
willem
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
Hi,
First off, thank the community--OsmocomBB for launching and then sharing the
development of mobile protocol stack first.
As we can understand, the current mailing list has been acting as the
primary way of communicating between one another on the project basis.
For these quick questions as well as immediate discussions, however, most
likely there should be yet another way to complement, like irc on the
freenode.
Or, for the above issue you guys out there have other ways to solve, eh? If
so, please take me into the circle as well, just because I have too many
questions to ask. :)
Thanks.
Best Regards,
Samuel
> 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.
i had a similar problem with an unconnected input pin which caused a
reset of a microcontroller, just by moving some centimeters in a
distance of one meter. check if you have left unconnected input pins on
your USB converter. what about hardware flow control input? (RTS/CTR)
andreas
hi harald,
>> 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.
from the specs it is quite clear that every access burst has different
random number when resending. but how does the network know if the burst
is from the same phone but retransmitted? in case of poor uplink many
bursts may be resent. will the network allocate a channel for every
burst received and waits for timeout? (if this is the case, emergency
calls could quickly 'evacuate' the cell.)
>> 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?
it is something to remind me that there are memory leak problems. in
some functions of gsm_04_08.c there are messages allocated at the
beginning and sent at the end. sometimes during processing, the function
returns due to error conditions, but the message is not freed before
return. i will check that later together with my new code.
as far as i can see right now, it just happens in gsm48_cc_tx_setup().
regards,
andreas
Hello Andreas,
On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> from the specs it is quite clear that every access burst has different
> random number when resending. but how does the network know if the burst
> is from the same phone but retransmitted? in case of poor uplink many
> bursts may be resent. will the network allocate a channel for every
> burst received and waits for timeout? (if this is the case, emergency
> calls could quickly 'evacuate' the cell.)
It does not even need a poor uplink. I experience this behaviour for example
with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent
fast enough, a retransmitted RACH burst will allocate another channel
(the timeout for releasing an unused channel is around 2 to 5 seconds in
"real" GSM networks). The maximum number of the retransmitted RACH burst
is controlled by a parameter in the SYSTEM INFORMATION messages (there
are several parameters which control the RACH transmission behaviour).
Of course a "bad phone" can ignore those parameters and a DoS attack
with continuous RACH bursts works quite well because the BTS or
network does not know from which phone the burst come from.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Christian,
On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> I'm using a self-made cable consisting of a known good FT232R
> converter @ 3.3V and a cut off headset cable (that also worked
> flawlessly without any noise on another mobile phone before). My C123
> also looks pristine. I manage to upload and run hello world
> successfully in maybe one out of ten attempts, often have to remove
> the battery because the phone just gets stuck. So I have ordered a new
> cable from Akku-King as suggested on the Wiki.
My experience: I work under Windows with Cygwin so the OS internals
how the serial port is handled are (totally) different than Linux.
With the non-blocking variant of "osmocon" it was nearly impossible
to download the code to the phone in a reliable way. So I had to apply
an ugly hack to my version which basically switches the serial connection
to "blocking mode" during the download phase. This way it works rather
reliable here (regardless of using a "real" RS232 port or an USB to serial
converter).
So you might experience the same problem instead of a bad cable. You
can try the attached patch to "osmocom.c". The patch is not for the
latest GIT version, however it should be quite easy to apply it to
the current on. Again, its an ugly hack, but it works for me.
Best regards,
Dieter
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Willem,
On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote:
>
> 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?
Hello Harald,
On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> 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.
According to the specification the random value has to change on every
transmission:
a random reference which is drawn randomly from a uniform probability
distribution for every new transmission.
In the TSM30 firmware this is done by having a table with random values
and an index into the table which is initialised to a random value when
the Immediate Assignment Procedure is started and incremented with every
random number taken for a retransmission. The table has 32 values because
the random reference is not larger than 5 bits.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
