Re: OpenPhoenux@FOSDEM2014

[matteo sanvito]

Hello Boudewijn
Thank you so much for this summary, I appreciate it very much because I
could not be there. I'm very happy to see that our community is still
alive, so thank you very much!

Best regards,
Matteo
Il 05/feb/2014 23:25 "Boudewijn"  ha scritto:

> Hi List,
>
> As you know, last weekend FOSDEM was held at the Brussels Free University.
> For
> the first time in years, OpenPhoenux didn't have its own stand. Luckily
> enough
> Michael from OpenPandora/Pyra offered to use part of their stand.
>
> There were a GTA04 in Freerunner case and a Freerunner to admire, both
> running
> QtMoko (v58/56), and lacking a spare GTA04-board I put the old Freerunner
> board next to it for the idea (it had been nice if all visitors had
> recognized
> the imposter immediately, they didn't though ;-) )
>
> Besides the hardware there were some flyers for the GTA04 as well as the
> Neo900. There were a couple of people dropping by thinking of their
> Openmoko
> in a drawer, pleasantly surprised by the looks of QtMoko and asking about
> the
> battery life of the new boards. I can get by, with about a day of battery
> life
> with light usage. That seemed reasonable to them, one of them got just six
> hours out of his Freerunner.
>
> There was quite a lot of interest in Neo900 as well, even though the flyers
> were not more than the specs page of neo900.org.
>
> OpenPandora's successor, DragonBox Pyra was on show. With OpenPandora
> being a
> sister project, running very similar hardware and production facilities, it
> would be nice if we can keep sharing hardware. The Pyra got a fast dual
> core
> A15 CPU, and it seems you can throw anything at it. We haven't spoken about
> power consumption though, I just know one of the strong points of
> OpenPandora
> is its huge battery.
>
> The stand next to us was about power savings in software (
> http://mageec.org/),
> such as optimization flags at compile time. Perhaps some of their findings
> are
> applicable in ARM as well.
>
> There were more than a few list members; Chris pointed me to the
> powersavers
> above and we had a general chat, PaulK came by to talk about Replicant and
> the
> kernel. I haven't had time to do much more than keeping up with the
> mailinglist, so there wasn't anything I could tell him first hand. GNUtoo
> was
> at the CoreBoot stand, I only spoke him shortly.
>
> Later on the day I got my new SIM for the Limesco network. Limesco is a
> MVNO
> in the Netherlands, run by hackers and activists for the same. In case
> you're
> in the Netherlands, give them a look (Disclosure: I'm involved in Limesco,
> so
> I'm a bit biased ;-) ) The nice thing is that this way you can run the
> whole
> mobile stack "in house": we got either our own hardware or firmware, our
> own
> printed case, on our own network, and perhaps we can use Sysmocoms
> programmable SIMs.
>
> We ended with a dinner with members of different projects. I had a great
> time,
> enjoyed meeting old friends and telling people about our project. Thank you
> all for making it possible!
>
> Best regards,
>
> Boudewijn
>
>
> PS: I got some photos, I'll send an update when they're available online.
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

OpenPhoenux@FOSDEM2014

[Boudewijn]

Hi List,

As you know, last weekend FOSDEM was held at the Brussels Free University. For 
the first time in years, OpenPhoenux didn't have its own stand. Luckily enough 
Michael from OpenPandora/Pyra offered to use part of their stand.

There were a GTA04 in Freerunner case and a Freerunner to admire, both running 
QtMoko (v58/56), and lacking a spare GTA04-board I put the old Freerunner 
board next to it for the idea (it had been nice if all visitors had recognized 
the imposter immediately, they didn't though ;-) )

Besides the hardware there were some flyers for the GTA04 as well as the 
Neo900. There were a couple of people dropping by thinking of their Openmoko 
in a drawer, pleasantly surprised by the looks of QtMoko and asking about the 
battery life of the new boards. I can get by, with about a day of battery life 
with light usage. That seemed reasonable to them, one of them got just six 
hours out of his Freerunner. 

There was quite a lot of interest in Neo900 as well, even though the flyers 
were not more than the specs page of neo900.org. 

OpenPandora's successor, DragonBox Pyra was on show. With OpenPandora being a 
sister project, running very similar hardware and production facilities, it 
would be nice if we can keep sharing hardware. The Pyra got a fast dual core 
A15 CPU, and it seems you can throw anything at it. We haven't spoken about 
power consumption though, I just know one of the strong points of OpenPandora 
is its huge battery. 

The stand next to us was about power savings in software (http://mageec.org/), 
such as optimization flags at compile time. Perhaps some of their findings are 
applicable in ARM as well. 

There were more than a few list members; Chris pointed me to the powersavers 
above and we had a general chat, PaulK came by to talk about Replicant and the 
kernel. I haven't had time to do much more than keeping up with the 
mailinglist, so there wasn't anything I could tell him first hand. GNUtoo was 
at the CoreBoot stand, I only spoke him shortly. 

Later on the day I got my new SIM for the Limesco network. Limesco is a MVNO 
in the Netherlands, run by hackers and activists for the same. In case you're 
in the Netherlands, give them a look (Disclosure: I'm involved in Limesco, so 
I'm a bit biased ;-) ) The nice thing is that this way you can run the whole 
mobile stack "in house": we got either our own hardware or firmware, our own 
printed case, on our own network, and perhaps we can use Sysmocoms 
programmable SIMs.

We ended with a dinner with members of different projects. I had a great time, 
enjoyed meeting old friends and telling people about our project. Thank you 
all for making it possible! 

Best regards,

Boudewijn


PS: I got some photos, I'll send an update when they're available online.

signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Customised speech for Navit

[L.B.]

Hi all,


I worked a bit on Navit config file for QTMoko, I though this may
be helful for some users. I was a bit bored of the poor sound
quality at the start of each announcement due to the sound card waking
up just as the speech starts. So I tried to include a sound file before
each announcement to give enough time for the card to prepare before the
speech (as explained here ).
However this was not exactly useful because each sound file was
suffering from the exact same problem, so the speech was still degraded.
Therefore I decided to merge the two wav files into a third one so that
the sound would not be interrupted as the two are being played. Here are
the steps I followed (let me know if you have a better way to do it).
First of all I installed sox and its dependancies:

apt-get install sox

then I changed the config file ~/.Navit/navit.xml to redirect speech
commands into an external file at line 742 (I got this from the Navit
website):



I created the folder /media/card/Navit that contains the file Sound.wav
(whatever you like as long as it is mono and 22050 Hz sample rate, I
used a 1.5s bleep-ish sound) and the script speech.sh that follows:

#!/bin/bash/
espeak -ven-uk+m1 -s 140 -a 100 -p 50 "$1" -w ./speech.wav
sox -r 22050 -e signed-integer -b 16 -v 1.5 ./Sound.wav ./tmp1.raw
sox -r 22050 -e signed-integer -b 16 ./speech.wav ./tmp2.raw
cat ./tmp1.raw ./tmp2.raw > ./tmp3.raw
sox -r 22050 -e signed-integer -b 16 ./tmp3.raw -r 22050 -e
signed-integer -b 16 ./playing.wav
aplay -r 22050 ./playing.wav

make it executable:

chmod +x /media/card/Navit/speech.sh

Then you can try the result by typing something like:

/media/card/Navit/speech.sh 'this is a test'

the result is quite nice, the sound is a bit scratchy at the beginning
of the sound file due to the wake up problem but the speech is now
completely clear.

All the best,

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: TIFFS in vitro analyzer tool released

[Michael Spacefalcon]

Giacomo 'giotti' Mariani  wrote:

> Here we are:
> # diff -r michael-ffs my-ffs

Thank you for these diffs; explanation follows inline.

> Binary files michael-ffs/Test/Production.bin and my-ffs/Test/Production.bin
> differ

Yup, expected - if you hexdump this file, you'll see that it contains,
among other things, the non-IMEI "serial number" which Om/FIC assigned
to each Neo unit.

Incidentally, these files under /Test (Production.bin and Teststate.bin)
are neither written nor read by the modem firmware (any version); they
were written by the factory production line and remain as decorative
relics afterward, not actually used by the fw for anything.  (Kind of
like your belly button - serves no real purpose except to remind you
how you came into being. :-)

> Binary files michael-ffs/gsm/cops/operimsi and my-ffs/gsm/cops/operimsi
> differ

This file gets frequently rewritten during normal operation of the
modem; it contains the IMSI read from your SIM card and some other
info I have yet to understand.

Regarding the flash dump on my FTP site, I read it out of my FR's
modem before I put any SIM into it, so whatever IMSI-related info is
in that image, it must be an artifact of testing or whatever by the
manufacturer/distributor/etc.

> Binary files michael-ffs/gsm/l3/rr_white_list and my-ffs/gsm/l3/rr_white_list
> differ

I have yet to learn what these files under /gsm/l3 are for, so I don't
have much to add currently.  However, I do know that these files get
rewritten by the modem quite frequently in normal operation, so they
are definitely in the "dynamic state" category, not factory-programmed
data.

> diff -r michael-ffs/gsm/rf/afcdac my-ffs/gsm/rf/afcdac
> [...]
> Binary files michael-ffs/gsm/rf/tx/levels.900 and my-ffs/gsm/rf/tx/levels.900
> differ

These are the interesting ones: all files under /gsm/rf are calibration
data recorded at the factory and never changed afterward, so the diffs
we are seeing here are the measured physical variations from one
produced unit to the next.

The next natural question here is how great or small these differences
are, i.e., the magnitude.  To answer that, we need to look at the
actual content of these RF calibration files.  They are all binary,
and are read directly into RAM data structures belonging to the Layer1
code in the firmware.  I will give these structures their deserved
scrutiny when I reach the point of deblobbing the L1 code and
integrating it into my gcc-built FC GSM fw - IOW, not yet.

In the meantime, I think it would be a good idea to collect the content
of this /gsm/rf directory subtree from as many Neo units as possible -
understanding the actual magnitude of per-unit differences in these
calibration values would help us provide the best possible recovery
for anyone unlucky enough to lose their FFS, and may also give us an
idea as to what to expect in this department when the time comes to
build new FreeCalypso phones and modems.

Because all files under /gsm/rf are written only on the factory
production line and not afterward, there is no personal information in
there: nothing read from your SIM(s), no history of network connections
or the like, and no IMEI or other identifying numbers, just measurements
of physical process variations.  Therefore, there should be no privacy
problems in publishing this data.

If you would like to contribute your RF calibration data to public
knowledge, you can make a .tar.gz from your extracted /gsm/rf subtree
(just that subtree, don't include any other directories which may
contain private personal info), send it to me, and I'll put it on
ftp.ifctf.org - I'll make a new directory for this calibration
collection.  Oh, and inside that tarball, add a note indicating
whether the unit in question is a GTA01 or a GTA02, and whether it is
the 900+etc or the 850+etc frequency band version.

To repeat: if you choose to do the above, be sure to extract the
content of your FFS with mokoffs xtr and then make a .tar.gz of just
the /gsm/rf subtree - you probably do NOT want to publish your
complete raw flash dump, as there's a lot of personal info that can be
extracted from a complete FFS image.

> Binary files michael-ffs/pcm/IMEI and my-ffs/pcm/IMEI differ

Obvious.

> Binary files michael-ffs/pcm/IMSI and my-ffs/pcm/IMSI differ

Same deal as with /gsm/cops/operimsi seen earlier.

> Binary files michael-ffs/var/dbg/dar and my-ffs/var/dbg/dar differ

This file appears to be rewritten every time the modem boots up.  But
TI's DAR component (Diagnostics And Recovery) is coming up next to be
integrated into the fledging FC GSM fw source, so we will understand
this file very soon. :-)

> Glad to help. I hope this gives you some information :-)

One part which I have yet to learn is how the SMS receiving path works.
It seems to me that when the network delivers an MT (mobile-terminated)
SMS to the mobile, the modem has to store that SMS on its own and
acknowledge receipt to the GSM network before it can pass that SMS to
the applica

[QtMoko] PyQt compatibility

[Giacomo 'giotti' Mariani]

Hello Radek, everyone,
   I'm looking at PyQt and, after installing all the necessary packages,
I tried to run a simple program, but (as expected) I got:

# python first.py
Fontconfig error: Cannot load default config file
first.py: cannot connect to X server

Do you think it is possible to run it integrated in QtMoko?

Thanks,
  Giacomo

-- 
##
giacomo 'giotti' mariani
gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859
O< ASCII ribbon campaign: stop HTML mail
www.asciiribbon.org
##


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: TIFFS in vitro analyzer tool released

[Giacomo 'giotti' Mariani]

Hi Michael,
> Because my sample size so far has been 1, I would like to know how the
> FFS content on other FR units differs from mine. I would appreciate it
> if you could do a mokoffs xtr on your FFS image, then do the same on
> the image from my FR (from my FTP site, URL posted earlier), and then
> let me know what diff -r between the two extracted trees shows. 
Here we are:

# diff -r michael-ffs
my-ffs  
  

Binary files michael-ffs/Test/Production.bin and
my-ffs/Test/Production.bin
differ
Binary files michael-ffs/gsm/cops/operimsi and my-ffs/gsm/cops/operimsi
differ

Binary files michael-ffs/gsm/l3/rr_white_list and
my-ffs/gsm/l3/rr_white_list
differ  
diff -r michael-ffs/gsm/rf/afcdac
my-ffs/gsm/rf/afcdac


1c1 
  

<
p   


\ No newline at end of file
---
> ??
\ No newline at end of file
Binary files michael-ffs/gsm/rf/afcparams and my-ffs/gsm/rf/afcparams differ
Binary files michael-ffs/gsm/rf/rx/agcparams.900 and
my-ffs/gsm/rf/rx/agcparams.900 differ
Binary files michael-ffs/gsm/rf/rx/calchan.1800 and
my-ffs/gsm/rf/rx/calchan.1800 differ
Binary files michael-ffs/gsm/rf/rx/calchan.900 and
my-ffs/gsm/rf/rx/calchan.900 differ
Binary files michael-ffs/gsm/rf/tx/calchan.1800 and
my-ffs/gsm/rf/tx/calchan.1800 differ
Binary files michael-ffs/gsm/rf/tx/calchan.1900 and
my-ffs/gsm/rf/tx/calchan.1900 differ
Binary files michael-ffs/gsm/rf/tx/calchan.900 and
my-ffs/gsm/rf/tx/calchan.900 differ
Binary files michael-ffs/gsm/rf/tx/levels.1800 and
my-ffs/gsm/rf/tx/levels.1800 differ
Binary files michael-ffs/gsm/rf/tx/levels.1900 and
my-ffs/gsm/rf/tx/levels.1900 differ
Binary files michael-ffs/gsm/rf/tx/levels.900 and
my-ffs/gsm/rf/tx/levels.900 differ
Binary files michael-ffs/pcm/IMEI and my-ffs/pcm/IMEI differ
Binary files michael-ffs/pcm/IMSI and my-ffs/pcm/IMSI differ
Binary files michael-ffs/var/dbg/dar and my-ffs/var/dbg/dar differ

Glad to help. I hope this gives you some information :-)


Changing the subject, I wonder if the following makes sense: would it be
possible, through the GSM, to obtain (backup) ALL the content of the SIM
so to be able to "fake" the SIM at software level?
This would make the phone a pseudo-dualSIM: for example, owning two SIMs
(and their software backups) it should be possible to switch from one to
the other at software level.
What's your opinion?

Best regards,
  Giacomo


-- 
##
giacomo 'giotti' mariani
gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859
O< ASCII ribbon campaign: stop HTML mail
www.asciiribbon.org
##


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community