Hello Joachim,
On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh(a)hyte.de> wrote:
>
> ps: according the the schem the vibra should be controlled by the auxdac
> of iota. i poked it and some enable bit few minutes, but couldnt get it
> doing anything.
Have you turned the Auxiliary DAC on ? It has its own power control
bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC
on. I just did a quick test with a C123, and the following seems to
work:
twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on
twl3025_reg_write(AUXDAC, 1000);
delay_ms(1500);
twl3025_reg_write(AUXDAC, 0);
twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
sorry for not writing anything earlier, but i'm currently moving so i'm
a bit short of time.
i have been working on the bci and madc block already, so if you are not
already done, i'd like to do that.
its a bit tricky since one needs to do quite a lot to charge the battery
correctly, but in the end we could even charge nimh and i guess small
lead batterys also if we want to (with different code).
i have done the irq handlers, the charger plug in detection and the
async madc stuff is already working.
it just needs some cleanup before commit.
about the bci stuff: i'm now done reading and understanding the iota
datasheets and appnotes (the latter one having invaluable information
not in the datasheets).
'just' need to get it written down in code and debug it. ;)
summary: if you can live with charging your batteries for another week
or 2, just try figuring out the ringer and or vibra for example
ps: according the the schem the vibra should be controlled by the auxdac
of iota. i poked it and some enable bit few minutes, but couldnt get it
doing anything.
so there is still a mystery or 2 left.
kind regards
--
roh
Hi everyone
Without further introduction and in a similar manner to laforge's last
mail I would like to note that I am working on a bootloader that will
allow for larger binaries in RAM and flexible flashing.
To avoid troublesome interaction between the Calypso bootrom (which we
use for interrupt redirection) and CFI support, I have decided to go for
an interrupt-less approach. So don't be surprised to see me committing a
polling mode to fundamental drivers (keypad, uart) sometime soon.
Luckily, the required changes are trivial.
I'll push my branch sometime soon, just dropping a line to keep everyone
informed. Feel free to drop a line in case you are interested in other
flash-based tasks like hammering out linkage details and implementing
some kind of filesystem.
Greetings
prom
Hi!
Just to avoid any possible duplicate work: A member of this list already has a
working C155 color display driver. So if you were thinking of working on
this: Please rather do another TODO item.
I'm supposed to be merging that driver during the next couple of days.
Cheers,
Harald
p.s.: I'm back in Berlin now, will be working with zecke of getting layer2
(bi-directional) up and running.
--
- 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,
First I'd like to thank all people involved with the project. I don't
know about GSM but as Harald said [1] I can contribute with
microcontroller development.
I have an old functional Motorola C200 phone. I'd like to know if it's
possible use it? I've search for some information about C200 baseband
processor without success, so I'm asking in the list.
[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-February/000000.html
--tm
Hi Yanis,
I'm CCing the OsmoconBB list who could perhaps help setup a MSC-GPS
data collector.
On Feb 22, 2010, at 8:09 PM, Yanis Pavlidis wrote:
> Hi all,
>
> not exactly related to airprobe itself, but I am sure people on this
> list could answer my question.
> So, after reading Tobias Engels' presentation on 25c3 ( http://events.ccc.de/congress/2008/Fahrplan/attachments/1262_25c3-locating-…
> ), I found out you can perform an HLR lookup and come up with the
> current MSC number that "controls" the connection of the subscriber,
> for any subscriber.
Yes, every telco company and VoIP provider with SS7 access in the
world always knows where you are. Scary.
> My question is, is this MSC number, visible from the mobile phone
> side? If yes, somebody could actually wardrive, to get the MSC
> number-to-location mapping?
> Can airprobe, or OpenBTS help?
Creating the {MSC -> location} mapping database would be a very
worthwhile exercise. The data collection would have to happen from
phones. Either we create an application for one of the popular phone
platforms (Symbian, Android, iPhone). Anybody on the list knows if
these phones expose the MSC number to application software?
Alternative, the Osmocon project could probably expose the MSC
information easily. The project is still in early stages and it will
take a few months until a collector software could be running. I
wonder if any of the supported Motorola phones have GPS?
> Forgive my ignorance on all-things-gsm, I am just beginning exploring!
Thanks for bringing up the topic!
> Thanks all,
> Yanis
Cheers,
-Karsten
Hi;
It is really a good work. Congratulations...
I hope to develop in this project. Although I do not have any
experience about microcontroller development and gsm,
I think I can do. I can develop with C or C++.
Does anyone suggest me any document, site to start?
Thanks...
>> But I guess you can use two MSs, one for transmit and one for receive
to
>> overcome this limitation. Is there any problems with this approach
other
>> then good clock synchronization?
>
>You need a very good clock sync :) But that's something that could be
>tried I guess.
maybe..
you could sync the "receiver phone" to the "transmitter phone" by using
one timeslot. (TS7)
or you could sync the receiver phone to a nearby bts and use a control
line on the serial link to sync the transmitter phone to the receiver
phone. (you need to cross-connect the serial ports on the phones for
signalling anyway.)
andreas
> But I guess you can use two MSs, one for transmit and one for receive to
> overcome this limitation. Is there any problems with this approach other
> then good clock synchronization?
You need a very good clock sync :) But that's something that could be
tried I guess.
> PS Looking at pictures of ip.access Nanostation we didn't find any duplexers.
> How does it work then? Or have we just missed duplexers on the photos?
Nope, no duplexers.
There is a TX antenna and a RX antenna. I think they are patch antenna
that don't radiate sideways so that they don't leak into one another.
There is also a massive chunk of metal between them to isolate :)
Sylvain