Hello techies!
I am new to the list and I acquired a c139. I'd like to buy a rs232/jack
2,5mm named t191 flash (and not unlock) cable. They look 100% the same (even
stickers). Is this important? I understand that I have also to use a
rs232/usb adapter. The one I have (U232P9 with link/tx/rx leds) gives +/-9,4
v. So my concern is to not fry the Moto..Any advise welcome.
Cheers.
hi all,
About voice,I have one question.
In the latest git code, when I use bb to call other phone, it will product a
file voice.raw.
How I can play the voice.raw?
which kind of format? 16bit or 8 bit pcm?16khz and 8khz?LSE or MSE?
In fact i used the cooledit to play it, both 16khz and 8khz, it has only
noise.
Other question, I want to input voice from pc that run BB, then the voice
can be sent by C123.
But I found the voice that be sent by C123 is C123 input voice.
Can we realize the idea?
Best Regards
Shrek W
Hi!
Is AreasOfWork in the wiki still up to date? I intend to work on the UI
(Sorry Dieter, GSM testset too expensive at the moment :( ) and want to
choose a RTOS. A small collection that I came across:
FreeRTOS
What is the problem?
TNKernel
http://www.tnkernel.com/tn_description.html
Scheduler, Mutexes, Queues, etc. available
strange (at least unfamiliar) API for memory
eCos
http://ecos.sourceware.org/about.html
many target MCUs but are their any other than ARM in BB chipsets?
powerful but complex (at least at first glance)
NUT/OS
http://www.ethernut.de/en/
minimalistic RTOS, easy to port
seems to have sound community
familiar APIs: malloc, fopen's devices, ...
cooperative multithreading: Is that OK? We still have IRQs for
realtime...
Since we seem to barely need an OS, a full-blown OS like eCos seems
excessive. For compatibility with MT6235 user space, malloc and fopen is
the right direction. Hence, my favourite is NUT/OS. In fact, I tried
porting it to calypso just for fun. With some wrappers, Osmocom's
platform files can be used. Only turns on the backlight and occasionally
outputs some bytes on the UART at the moment. However, I still call this
success. It took me just a day from knowing nothing about NUT/OS and
very little about calypso and ARM to do this. Seems promising in terms
of portability and documentation to me.
Open question: How much overhead can we afford, i.e., how much spare
time is there on the CPU? Does "Disable RTC interrupt as it causes lost
TDMA frames" (layer1/init.c) indicate issues? (Yes, sorry, haven't read
GSM specs yet...) If yes, is it reasonable to independently handle GSM
stuff with FIQ and only give IRQ to whatever OS we choose?
Regards,
Stefan
Hi,
good news: mails are back
bad news: phone lost a battery pin :(
Here are two small patches to help the mediatek-branch compile without calypso
references. These were tested before the breakage and 'make all' still builds
fine for compal.
Regards,
Wolfram
Wolfram Sang (2):
comm: msgb: don't set backlight on error
lib: move delay.c from calypso to lib
src/target/firmware/calypso/Makefile | 2 +-
src/target/firmware/calypso/delay.c | 16 ----------------
src/target/firmware/comm/msgb.c | 1 -
src/target/firmware/lib/Makefile | 2 +-
src/target/firmware/lib/delay.c | 16 ++++++++++++++++
5 files changed, 18 insertions(+), 19 deletions(-)
delete mode 100644 src/target/firmware/calypso/delay.c
create mode 100644 src/target/firmware/lib/delay.c
--
1.7.2.5
Hi Sylvain, hi list!
I saw you commiting a generic viterbi de-/encoder in libosmocore core/conv.c. Just when I started to learn how to implement something like that some days ago... :-)
Now I'd like to know if there are also some precomputed tables available for next_output and next_state implementing the convolution codes described in GSM 05.03/3.9.
Regarding the soft input bits to the algo, my guess is when just having hard bits you have to simply convert 1 to 127 and 0 to -127 in sbit_t, right?
And what came to my mind while reading the code is that couldn't you improve its performance on punctured codes by remembering the re-inserted bits and excepting them from next accumulated error calculation (line 291)?
If I'm understanding viterbi the right way, as punctured bits doesn't contain any information and introduce some random additional error, only real input bits should be incorporated in state decisions.
Regards,
Mad
It shows the communication messages like Osmocom? Does it also supports SMS messages?
Maybe you can also write a small wiki on how to use (with Wireshark).
Hi,
do the following assumptions and conclusions make sense?
- The Sciphone G2 is intended as a platform where we want to run L1/2/3
natively on Linux (somewhen).
- Thus, from all the applications in osmocom-bb for the targets, we only
need the loader to get the first bootloader onto the system (in case
JTAG is not available or wanted)
- Being that different, it doesn't make sense to fit the
mediatek-platform into the existing makefile-templates which build all
applications for all boards.
I'd suggest to create a new top-level target "mtk" which only builds the
loaders for mediatek-phones. All unneeded applications and libraries are
skipped. A preview of a possible directory-structure to add mtk-support
could look like this then:
.
├── board
│ ├── mediatek
│ │ ├── exceptions_redirected.S
│ │ ├── exceptions_redirect.S
│ │ ├── handlers.S
│ │ ├── header.S
│ │ ├── macros.S
│ │ ├── ram.lds
│ │ ├── start.ram.S
│ │ ├── start.rom.S
│ │ └── uart.c
│ └── mt62xx
│ └── init.c
└── include
└── mtk
├── bfe.h
├── bpi.h
├── bsi.h
├── emi.h
├── mt6235.h
├── mt6235_sciphone_g2.h
├── system.h
└── tdma_timer.h
It can be cleaned up a bit once there is a working state. Of course, a
few modifications to makefiles are also needed. Note there is now a
seperate uart.c in the mediatek-folder.
Any objections? Anything I missed?
Regards,
Wolfram