GSM power management improvements

2019-02-04 Thread Mychaela Falconia
Hello what's left of Openmoko community,

If there is anyone still using their FreeRunner (or GTA01) as a phone
with working GSM (perhaps on a private island whose owner likes GSM
and is committed to keeping it forever), there is a modem firmware
update which you might find interesting:

ftp://ftp.freecalypso.org/pub/GSM/GTA02/gsm-fw/moko-new-fw-20190128.tar.bz2

The primary diff from previous versions consists of a couple of sleep
mode improvements, i.e., improved ability to go into sleep modes which
draw less power from the battery:

* During those time windows in which the modem is disallowed from going
into deep sleep by the UART activity timer (10 s after each transmission
from the AP host to the modem on the AT command UART), previous fw
versions needlessly suppressed big sleep in addition to deep sleep,
allowing only small sleep.  The present version goes into big sleep
during these time windows, saving more power.

* Some Openmoko devices suffer from a hardware defect that requires
disabling deep sleep - the infamous bug #1024.  Previous fw versions
did not provide a sleep mode configuration that allows big and small
sleep, but not deep sleep, forcing the user to choose between small
sleep only or big sleep only on no-deep-sleep hardware.  OM AP software
distros have been using the big sleep only AT%SLEEP=2 config in these
circumstances.  Our new fw offers a new AT%SLEEP=5 option that allows
big and small sleep, but not deep sleep, which should be ideal for
deep-sleep-deprived OM hardware.  The default is still AT%SLEEP=4
allowing all 3 sleep modes (small, big and deep sleep), just like
before.

* Most of the Calypso chip's GPIO and multifunction pins are unused
and unconnected on Openmoko devices.  All fw versions for this modem
released prior to 2017, including all legacy mokoN versions produced
by the now-defunct original manufacturer of the hw, contain a bug in
this regard: they configure many of these unused and unconnected GPIO
and multifunction pins as inputs, causing them to float.  The general
dictum in digital hw design is that CMOS floating inputs are bad, and
they can sometimes cause increased power draw as a result of current
flowing through both transistors of the CMOS input structure when they
are partially open.  This bug has been fixed in the newer FreeCalypso
fw releases since 2017: the correct way to handle unused and unconnected
GPIO and multifunction pins is to configure them as dummy outputs with
a constant value, which is what our current fw does.

This new firmware release is brought to you by Falconia Partners LLC,
a manufacturer of new cellular modems under the FreeCalypso brand,
currently for GSM/2G but perhaps some day for UMTS/3G as well.  At the
present time we don't do any work specifically for legacy Openmoko
devices (there is no business case for it), but our own modem product
is very similar to OM's, thus whenever we make significant improvements
to the firmware for our own modem hw, it costs us nothing to compile
and put out a new fw image for Openmoko's old modem as well.

Please note, however, that even though our new FreeCalypso modem hw is
very similar to OM's old modem, it is not identical, and the firmware
images built for the two respective targets are NOT interchangeable!
We build all of them from the same source tree, thus functional
improvements made for one target automatically benefit the others as
well, but a few hardware configuration and external interface bits are
conditionally compiled.  If you take a firmware image built for our
FCDEV3B and flash it into an Openmoko device, it may corrupt your FFS,
so don't do it - please be sure to only flash fw images which were
built specifically for whichever hardware you have.

Happy 2019, and enjoy improved power management in the modem if you
still have a free-running Openmoko device.

M~

P.S. In case anyone is concerned about the legality and safety of
using new GSM products from Falconia Partners LLC, whether our new hw
or our new fw for legacy hw from OM, please note that the products in
question (both hw and fw) have been extensively used on public
commercial GSM networks in several countries (at least USA, Canada,
Austria, France and South Africa to my knowledge, plus maybe others I
don't know about) over the course of many years now, without a single
problematic incident anywhere ever.  Getting an official stamp of
regulatory approval is definitely in the plans, but no one has paid
for it yet.  In the meantime, despite having no official rubber stamp
that says so, we already know with almost 100% certainty that our
products (both hw and fw) function 100% correctly on the air, fully
compliant with all of the relevant technical standards.

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


Recalibration, band conversion and bug #1024 rework

2018-02-14 Thread Mychaela Falconia
Hello OM community,

I am pleased to announce that my company Falconia Partners LLC is now
offering GSM RF tract recalibration services for Openmoko's Neo 1973
and Neo FreeRunner devices.  Like all other commercial GSM phones and
modems, these smartphones had their GSM RF parameters individually
calibrated on the factory production line.  This factory calibration
normally persists for the lifetime of the device, but because the
calibration values are stored in the Calypso modem's flash file
system, it is possible that some Neo owners may have lost theirs as a
result of careless playing with modem flashing tools.  The latter
scenario is quite likely to have happened in the bad old days before
FreeCalypso when the modem was treated as some kind of "thou shalt not
enter" forbidden zone, and the modem flashing tools and documentation
were available only in a hush-hush, whisper-whisper manner.  GSM RF
calibration also needs to be redone if the RF hardware has been
physically modified in any way, e.g., to convert a 900 MHz device to
850 MHz or vice-versa.

Because my company produces new Calypso GSM modems that are very
similar to Openmoko's, we have the necessary facilities to perform our
own RF calibration that is no worse than what OM's factory did.  The
RF test instrument that is used to perform the calibration is a
Rohde CMU200, and this instrument itself needs to be kept in
good calibration standing - the chain of traceability goes back to
national standards labs like NIST.  Our CMU200 instrument has just
been calibrated by Rohde in Maryland; here is the official
calibration certificate:

https://www.freecalypso.org/members/falcon/calibration/CD_5000-309076293.pdf

In addition to the measuring instrument, the process of calibrating
the RF tract on a Calypso GSM device involves special software that
talks both to the firmware running on the Calypso (which naturally
needs to be TI-based) and to the CMU200 or other external RF test
equipment.  The original software that was used by OM's factory
appears to have been lost, hence an entirely new replacement had to be
developed from scratch here at Falconia Partners LLC, based on the
available bits of documentation from TI and meticulous reverse
engineering.  Our new calibration software is freely published, so you
can see exactly what we do when we calibrate a Calypso GSM device:

https://bitbucket.org/falconian/fc-rfcal-tools

If anyone has a GTA02 or GTA01 device that needs to be recalibrated or
could benefit from such, you can send it to Falconia Partners LLC to
be serviced.  As long as the demand is low, there will be no charge
for the recalibration service other than return shipping.  If you are
going to sending your device in for service, please take the battery
out, i.e., send the device WITHOUT the battery.  Postal services have
become very uptight about lithium batteries recently, hence the return
shipping will cost a lot more if I have to deal with the extra
bureaucratic hurdles of shipping the device back to you with that
Li-ion battery in it.

The calibration service is completely non-invasive, i.e., your device
won't need to be disassembled beyond taking the back cover off.  Your
Neo will have 3 cables plugged into it (USB for talking to U-Boot,
another USB-serial cable in the headset jack for talking to the
Calypso, and an RF test cable going to the CMU200 inserted into the RF
test port under the back cover), the application processor will be
booted into NOR U-Boot, the latter will be used to execute neo gsm on
and neo gsm off commands via USB, and the headset jack serial port
will be used to operate on the Calypso modem.  Whatever software you
are running on the phone's application processor will be left
completely untouched.

If there is interest, my company may also be able to offer a band
conversion service, i.e., converting a 900 MHz FreeRunner to 850 MHz
or vice-versa.  To make such conversion, one SAW filter part in the
GSM section of the motherboard needs to be changed (populate Epcos
B7820 for 900 MHz or B7845 for 850 MHz), followed by recalibration.
However, unlike pure recalibration, band conversion would require a
bit of invasive surgery on the hardware, and this hw surgery would
need to be performed at a professional board assembly and rework shop.
If there is any serious interest, I can have a discussion with
Technotronix (the shop where our new FreeCalypso modem boards are
assembled) and see if they would be able to perform rework on Openmoko
devices, and how much they would charge for the service.  I won't be
adding any margin of my own on top of whatever Technotronix folks will
charge, but I would need to act as a middlewoman for logistics because
devices would need to be recalibrated after the SAW filter change, and
the calibration station with the CMU200 (a big, heavy and expensive
instrument) resides in my own lab, not at Technotronix.

Finally, if anyone has a FreeRunner that hasn't had the rework for bug
#1024 and is 

Neo FR disassembly for bug #1024 rework

2018-01-05 Thread Mychaela Falconia
Hello OM community,

I know that a good number of Neo FreeRunner units have been subjected
to the hardware rework to fix the infamous bug #1024, and it is my
understanding that one or more shops used to perform this rework
service professionally once upon a time.  I am now looking into the
possibility of having my company Falconia Partners LLC offer this hw
rework service, as I have heard reports from FreeRunner owners who say
that their units never got the rework and do suffer from the bug, and
I would also like to be able to offer a band conversion service, i.e.,
converting any given FreeRunner between 850 MHz and 900 MHz bands in
either direction.  The band conversion would involve changing one SAW
filter component at reference designator U402 (populate Epcos B7820
for 900 MHz or B7845 for 850 MHz, I have the parts readily available)
followed by recalibration - and my little company has just the right
RF test equipment setup (and newly developed calibration software that
fully replicates the functionality of the apparently-lost Windows
version used by OM/FIC) to do the latter.

The extent of required disassembly is exactly the same for bug #1024
rework and for the SAW filter change - in both cases the metal
shieldcan cover over the GSM section of the motherboard needs to be
removed, and both reworks can be done in the same surgery.

I do wonder, however, if any of the people who used to perform bug
#1024 rework in the past on a professional basis (i.e., on customer
devices, not their own personal ones) might be willing to share some
tips as to what would be the absolutely least invasive way to open
that shieldcan and then put it all back together after the surgery.

One complication that exists on GTA02 devices but not on GTA01 (nor on
my newly made FCDEV3B modems) is that the WLAN daughterboard sits
directly on top of the shieldcan cover over the GSM section, and the
two are bonded together with some material that seems to be some form
of conductive glue.  It is not a strong glue, i.e., the WLAN module
can be easily pulled off by hand, but pulling it off like this leaves
a mess underneath, and thus I assume that my naive way of doing it is
probably not the right way.

Hence I wonder if any of the people who used to do the rework for bug
#1024 professionally might be willing to share the secret of how to
do it right:

1) Did you remove the WLAN daughterboard first and then lift the
shieldcan cover, or did you somehow remove these two pieces together
so they remain attached to each other with that bonding material?

2) If you removed the two pieces separately, how did you restore the
bonding between them upon reassembly?

3) If it is possible to remove the shieldcan cover along with the WLAN
module on top of it as a single piece, how does one do it?

TIA for any tips,
Mychaela

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


Re: moko13 firmware

2017-10-14 Thread Mychaela Falconia
Further on the subject of FCC type approval or lack thereof, your
change log at:

http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt

lists "Pass the PTCRB certification" under moko5.  Does it imply that
there was no PTCRB certification and thus no FCC approval number prior
to the time of moko5?  Yet you sold quite a few GTA01 devices prior to
that time.  Does it mean that those GTA01s, particularly the earliest
phase 0 devices, were sold or sent free of cost to people who weren't
OM employees without having FCC approval?  If you say that selling
devices without such full approval is absolutely illegal, then how
were you able to get away with it?

And when it comes to my *current* FreeCalypso devices (as opposed to
potential future ones) which lack FCC approval, please keep in mind
that these current devices are *development* boards, not intended for
end users.  These development boards are specifically intended for
developers and tinkerers who will be playing with their own radio fw
builds, and have no other purpose.  I doubt that such developer kits
(as opposed to end user products) are eligible for FCC approval at all.

Yet there are many, many companies that sell gear specifically for
developers, specifically for lab use in controlled environments, gear
that does not have FCC approval for end user operation.  Even TI back
in the day when they made cellular baseband chipsets made and sold
such development kits, and I even managed to score one of those
historical TI dev kits on ebay:

https://www.freecalypso.org/members/falcon/pictures/D-Sample/

TI's cellular development kits like the one pictured above were sold
to chipset customers who were developing their own products with TI's
chips, were delivered along with those infamous NDA-controlled firmware
sources or semi-sources, and were specifically intended for engineers
to try out their own fw builds.  I somehow doubt that these development
kits had FCC approval of the same kind as end user devices, yet I also
doubt that TI were breaking laws by selling these kits.

Thus if a piece of gear is explicitly sold as a development kit for
engineers, not as an end user product, and it is very clearly indicated
that it is not FCC-approved as an end user product and that the
engineer-customer must take the full personal responsibility for its
radio operation, then maybe it is not so totally illegal for the dev
kit manufacturer to sell such kits?

You are of course correct that if someone buys a non-type-approved
cellular development kit like TI's D-Sample or my FCDEV3B and uses it
to do their own radio fw development, they have a responsibility to do
their initial tests in a controlled environment, either without an
antenna, using a conducted connection to an RF tester like R CMU200
(that's my setup), or with radiated transmissions in an anechoic
chamber like you said.

But there also exists a phase in the development and testing cycle in
which a device has not received full approval yet, but is being tested
on real live GSM networks.  Such tests are conducted with the full
knowledge and cooperation of the network operator, with the test
device operator ready to unplug the power supply at any moment should
the device under test cause any kind of disruption or interference to
the live network.

The ONLY way in which my process deviates from the "fully legitimate"
process described above is that I do not seek special approval from
T-Mobile prior to sticking one of their SIM cards into one of my
development devices, but just do it.  But I never leave such a setup
unattended while powered on, and I always closely monitor the operation
of my devices whenever I conduct operational tests on the live T-Mobile
GSM network.  If the device ever misbehaves in any way (which has yet
to happen), I will most certainly power it off immediately.  Because
my devices function 100% correctly and in accord with the GSM specs,
no interference or disruption of any kind takes place, and absolutely
no harm is caused to anyone.

M~

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


Re: moko13 firmware

2017-10-14 Thread Mychaela Falconia
Joerg wrote:

> What will be your FCC approval number for [new GTA02 clones]

There will be one if someone pays for it, or none otherwise.

> what IS the FCC approval number (and URL to the publicly available FCC
> approval report) of the devices you already built?

There is none.

> Just asking since I might have missed that part and am wrong (as usual
> according to you) in assuming you're selling devices that have no approval at
> all

You are correct in that I am selling devices that have no approval at
all, however, the part you are missing is that these devices are
intended for those people who practice radical self-empowerment and
self-sovereignty, and do not need approval from anyone other than
themselves.

> and thus are illegal to operate outside an anechoic chamber

I've already asked you before: please cite at least one documented
example of any police force anywhere in the world using extrasensory
psychic powers to detect the use of a device which they deem to be
illegal (for lack of regulatory approval) but whose actual radio
transmissions are 100% correct, 100% in accord with the relevant
technical standards, and thus indistinguishable from type-approved and
thus presumably legal devices.

M~

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


Re: moko13 firmware

2017-10-13 Thread Mychaela Falconia
Stefan Monnier  wrote:

> Why would someone do that?  I mean this as a real technical question:
> what is the difference between 2G and 3G which would cause someone to
> take a stand against 3G?

The difference is that for GSM/2G there exists a practically usable
implementation whose source code you are free to study and improve,
running on hardware whose electrical schematics and even physical PCB
design are published, consisting of chips whose detailed register-level
documentation is also published, without any restricted boot mechanisms
to block you from running your own firmware, i.e., a completely
transparent glass box implementation with full end user empowerment in
terms of understanding and improvement.  Absolutely nothing of this
sort exists for 3G or 4G or newer, or for any of the non-GSM
technologies (CDMA etc) that are also called 2G in marketing terms.

M~

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


Re: moko13 firmware

2017-10-12 Thread Mychaela Falconia
Bob Ham  wrote:

> then
>
>the FreeCalypso firmware is not based on OM's historical firmwares.
>
> Therefore, the statement regarding the recently released moko13
> firmware update was not false.

The person I was refuting did not say that the new fw is not based on
OM's historical fw, he said that it is not based on "the original
licensed firmware for Openmoko devices".  A reasonable interpretation
of that "original licensed fw" phrase is "firmware which TI licensed
to OM", which would be the 20070608 build of TI's TCS211 fw.  FC is
based on the latter, hence the statement is false in this reasonable
interpretation.

It is true that FreeCalypso fw is based not only on this TCS211 fw
from 20070608, but also on a more recent TI source (TCS3/LoCosto) that
was released free to the world in the spring of 2012 by Dr. Amol Sarva,
the CEO of Peek Inc., as that company was closing, but both of these
starting sources were equally essential to allowing FC fw to become
what it has become (a deblobbed fw rebuilding from source, with
bugfixes and improvements over the original blob-laden TCS211 version
which OM must have used), and neither of the two sources can be said
to be more primary or more essential or more critical than the other.

However, the specific configuration of FC Magnetite fw that is featured
in the moko13 release is very conservative in that wherever some code
from the TCS3/LoCosto source has been used to replace some formerly
binary-only code from TCS211 (L1 and main.lib), that new code has been
massaged to compile into a perfect match to the original blob, as
verified through disassembly, modulo some bug-fixing changes like
fixing the floating inputs bug described earlier, so those parts are
still effectively TCS211-based despite using the new source - we just
regained the ability to study and modify those parts by deblobbing
them.  The more aggressive change of fully replacing the TCS211 blob
version of the G23M protocol stack with the new TCS3 full source
version (TCS2/TCS3 hybrid config) is not included in moko13 (this
hybrid config still needs to have its bugs shaken out), but is planned
for the next release.

Once FreeCalypso makes the transition to the hybrid config with this
entirely new G23M PS version, then you can correctly say that it is no
longer based on the same TI baseline as OM's historical fw, but not
until then.

I hope that my explanation clarifies this firmware situation for
everyone.  I am sure that some people are going to argue that my
continued maintenance of and improvements to OM's firmware are illegal
because I am not an NDA-bound employee of that company and thus have
no right to work on the code they got from TI, but then you need to
remember Openmoko The Company *no longer exists*, hence it would not
be possible for *anyone* to be an employee of that no-longer-existing
company.  So if your lawyer tells you that the no-longer-existing
status of Openmoko-Inc means that no one in the world can legally make
improvements to their firmware and your only legal option is to
forever use their ancient firmware from 2009 or earlier with bugs in
it, then so be it.  For the rest of Humankind who are not so deathly
afraid of lawyers, the new and improved firmware is freely available.

M~

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


Re: moko13 firmware

2017-10-11 Thread Mychaela Falconia
H. Nikolaus Schaller  wrote:

> Well, with necessary funding Goldelico would be mass producing a GTA17
> this year which would beat the latest iPhones and alike in quality,
> user-experience, functionality and openness.

The amount of funding I would need in order to turn my post-FCDEV3B hw
ideas into reality would be far less than what you would need for what
you just described.  Specifically, I would only need about 2 kUSD to
finish some work on FCDEV3B which needs to be finished before any
follow-up FreeCalypso hw project can be started (I'll cover this part
myself in a few months after I'm done with the current round of family
expenses), and then another 10 kUSD to do any one of the following:

Option 1: reverse-eng the PCB layout of BenQ's M32 module (historical
Calypso-based) and make a FreeCalypso modem module in the same SMT
form factor.

Option 2: for the FreeCalypso Libre Dumbphone idea, produce a bare
board with the functionality of this dumbphone, i.e., a dumbphone sans
case, allowing ad hoc wooden cases and such.

Option 3: produce a clone of OM's GTA02 motherboard (either verbatim
or with changes like Glamo-ectomy), bare, no case, no WLAN/BT add-ons,
plus new Toppoly displays from Alibaba.

Whoever donates the needed 10 kUSD gets to pick which of the above 3
options is to be done.  I cannot guarantee that each of the 3 can be
fully done to the finish line for that 10 kUSD, but 10 kUSD is all I
would need to get the ball rolling, and it would get more than 50% of
the job done.

Please correct me if I'm wrong, but I get the impression that for your
ideas you would need a lot more than 10 kUSD.

M~

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


Re: moko13 firmware

2017-10-11 Thread Mychaela Falconia
H. Nikolaus Schaller  wrote:

> So let merephrase: how do you think to get someone pay for it?

By spreading the message as far and wide as I can that making new
Calypso phones and modems (be they GTA02 clones or semi-clones, or my
proposed Libre Dumbphone, or my proposed FC modem in SMT module form
factor) IS possible, and that there is a small company able and ready
to do the job given the necessary funding.  I shall keep spreading
this message far and wide until it reaches the ears of someone who
sees the idea as a positive and who has the needed money.

M~

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


Re: moko13 firmware

2017-10-11 Thread Mychaela Falconia
H. Nikolaus Schaller  wrote:

> I wonder where you want to get all the tiny glue components from...
>
> E.g. toppoly display,

The last time I looked a few months ago, they were readily available
from AliExpress.

> pogo pins for speakers,

Are you talking about the ones on the motherboard itself?  Take a look
at this photo:

https://www.freecalypso.org/members/falcon/mehr/IMG_20170209_151417.jpeg

It is a semi-clone of the GTA02 motherboard made by an Iranian company;
it retains the Samsung AP and the Calypso modem from the GTA02, and I
developed some custom features in FreeCalypso firmware for them.  They
specifically needed the modem to be Calypso so they can do some special
things with it, and they hired me to implement the necessary firmware
support for their special features.

These people have made some changes to the functionality of the board
which make their board usable only for them and not for the community,
but as far as I can tell, all of the electromechanical interfaces are
unchanged from the original.  Thus all exotic components which sit on
the motherboard itself have been successfully located.  If these
Iranian folks have successfully made a GTA02 MB semi-clone with their
special modifications, we can likewise make one without those mods.

> speakers, vibramotor,

These are case components, not on the MB, but once again I remember my
Iranian contacts telling me that they got those components taken care
of somehow.  Literally the ONLY component they said they couldn't find
was the bow-shaped GSM antenna, which I assume would need to be
custom-recreated.  I told them about the green "cucumber" antenna
board depicted on your case kit page.

> battery connector,

On the motherboard and clearly visible in the GTA02 semi-clone board
photo above.

> HF08 battery,

Plenty of Chinese phone manufs make batteries in Nokia BL-6C form
factor, and it can't be too difficult to have a special version made
with an OM-style Coulomb counter built in.  Besides Christoph Pulster
told me that he still has a whole ton of NOS ones in stock.

> shields,

These would need to be custom-made, of course.

> And: can you produce Neo Freerunner plastic cases?

Sure, if someone pays for the cost of making new moulds.

M~

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


Re: moko13 firmware

2017-10-10 Thread Mychaela Falconia
David Arnold  wrote:

> FWIW, I think the last 2G network in Australia is shutting down in
> March 2018 (following the December 2016 and August 2017 closure of
> the other two networks).

And how many people have responded to this shutdown plan by taking a
vow to live without any cellphone at all instead of accepting 3G/4G
when such shutdown happens?  I have already made just such a vow for
myself when it comes to the threatened shutdown of T-Mobile's GSM/2G
network in my part of the world, which is also the last one.

And how many people are looking into building their own replacement
GSM/2G networks following the example of Rhizomatica?  See:

https://www.rhizomatica.org/

M~

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


Re: moko13 firmware

2017-10-10 Thread Mychaela Falconia
I forgot to add:

: Option 3: new production of Neo FreeRunner (GTA02) verbatim clones.

If people do desire to see new production of verbatim GTA02 clones
that differ from FIC-made ones only in the manufacturing dates and the
identity of the manufacturer, and someone steps forward to fund such,
the new FreeRunners will have a sticker inside the battery compartment
that officially names Falconia Partners LLC rather than Openmoko Inc.
as the manufacturer of record, thus no one will have any ground to
bitch about our firmware not being authorized or endorsed by the
manufacturer.

And for those who missed that news item, let me repeat that we
(Falconia Partners LLC, doing business under the brand name FreeCalypso)
have already successfully produced our first fully working Calypso
modem product, along with production line RF calibration no worse than
OM's, in the form factor of a standalone modem development board.  Thus
my talk about building new Calypso phone and modem products is not just
hypothetical, but quite real.

M~

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


moko13 firmware

2017-10-10 Thread Mychaela Falconia
Hello Om community,

A little over a month ago a certain disgruntled ex-Openmoko employee
posted a knowingly false statement on this list, a false statement
which I feel is still in need of factual correction.

On Tue Aug 29 01:05:29 UTC 2017 Joerg Reisenweber wrote regarding the
recently released moko13 firmware update:

> Please carefully note that this update is not based on the original licensed
> firmware for Openmoko devices,

This statement is false, and the poster knows it.  Both OM's historical
firmwares and the current FreeCalypso ones are based on the same
20070608 base code delivery from TI; in the case of the current openly-
source-published FC firmwares you can see the original 20070608 code
and all subsequent evolution in the public Mercurial commit history
(yay for open source), and in the case of OM's historical firmwares
for which there is no corresponding source, you can see the dates in
the component version strings displayed with AT%VER, or see the same
strings with dates in them by running strings(1) on a mokoN image
after converting it from *.m0 (byte-reversed SREC) to straight binary.

All of the post-20070608 updates that appear in OM's historical mokoN
firmwares are also included in moko13, with the single exception of
the unofficial L1 update from 20080421 that was a totally misguided
attempt at fixing bug #1024, which did not fix the problem (it
couldn't, as the fw was fine and the problem was in the hw), and which
according to OM's own Sean Chiang (public ML post from 2008 quoted
earlier) had not passed TI's internal quality control.  In fact, OM
had taken this unofficial and *experimental* L1 update from TI, and
despite knowing full well that it had not passed TI's internal quality
control, included it in their production moko10 and moko11 firmwares.
AFAIK whatever type approval or certification testing OM had done was
well before this bug #1024 wild hunt, and there was no recertification
testing with moko10/11.  Thus one could argue that OM should have
voided their certification when they included that known-to-be-
unqualified L1 update in their production fw.

Thus moko13 has NO functional or quality or stability regressions
relative to moko11, but contains improvements on the contrary: a more
proper version of L1 free of misguided and mysterious hacks, and a fix
for the floating inputs bug described earlier.  It uses the exact same
version of TI's code which was in use at the time when OM passed their
type approval or certification testing, and has been carefully vetted
by the FreeCalypso team which has much greater GSM expertise than OM
had ever demonstrated.

The bottom line is this: if you have stopped maintaining a piece of
software, you have no right to be upset and angry when someone else
picks it up and takes over its continued maintenance.  You have not
released any new modem fw updates since early 2009, and the last
release you made on 2009-02-24 still contains easily provable bugs:
being an EE, you surely know that floating inputs are a bad idea.  So
why are you upset that someone else has picked up the maintenance of
this firmware and is fixing your bugs?

If there is anyone still left who uses a Neo FreeRunner as his or her
primary everyday phone, I encourage you to update your modem fw to
this current moko13 release.  I am also working already toward the
next fw version in which the entire G23M protocol stack will be
replaced with a newer version from TI (newer than any of the versions
which OM ever had), and this newer version also comes in full C source
form, rather than blobs.  This new radically-deblobbed fw already
exists (hybrid configuration in FC Magnetite), but it still has a few
remaining bugs and missing features which I need to work on.

The FreeCalypso core team is also soliciting input from the wider
community as to what kind of new hardware products people would like
to see.  The current choices are:

Option 1: a packaged SMT modem module that can be used as a component
in new smartphone designs like Neo900, replacing the mainstream
proprietary ones, for those who desire a free modem badly enough to
forego all of 3G/4G and use GSM/2G instead.

Option 2: a self-contained "dumbphone" handset consisting of a Calypso
chipset, a 176x220 pixel (probably 2") color LCD and a 21-button
keypad, possibly 3 side buttons as well, for those who just want a
plain phone and do not wish to be burdened with the extra complexity
and power consumption of a Linux computer in their phone.

Option 3: new production of Neo FreeRunner (GTA02) verbatim clones.

We are definitely interested in hearing which of the above might be of
interest to people, if any.

Sincerely,
Mychaela Falconia
Mother of FreeCalypso
www.freecalypso.org

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


Re: modem firmware

2017-08-29 Thread Mychaela Falconia
Troy Benjegerdes wrote:

> Please advise how I may best encourage you to stop talking
> and take my money.

Take your money?  Which product are you seeking to buy?  An FCDEV3B
board?  I am hoping to have those boards available for retail sale by
the end of September, i.e., only one month of waiting left.  I have an
outstanding order for a batch of boards with my contract manufacturer,
the CM acknowledged the order on 20170810 and said it was going to be
3 to 4 weeks, so they are supposed to deliver by Thursday of next week
(20170907) and I am going to bug them at that time if they don't
deliver by then.  Once the CM delivers the assembled boards to me, I
will need to take them to my home lab and put them through the
production test and calibration process (I have successfully recreated
the CMU200-based RF calibration process despite never having obtained
a copy of OM's original software for it), that production test will
reveal how many of the assembled boards are actually good (so far the
good yield has been about 50%), and then the good boards will become
sellable.

> Now if only we could
> properly finance you to find bugs and reverse-engineer a
> better 4GLTE software defined radio...

Reverse engineering and SDR do not go together; with an SDR approach
there is nothing to reverse-eng and instead you have to forward-eng
everything yourself from scratch.

However, none of the mainstream commercial 4G/LTE modems are SDR-based,
instead they all use custom silicon.  USRP-style SDR approach is
totally unsuitable for a cellphone which you could carry in your
pocket, instead you would need custom silicon of the kind that
Qualcomm and MTK and their ilk make.

On the note of "if only we could properly finance you", I actually
happen to know some very good recently retired ASIC design engineers,
and if there were "proper" financing available, I might be able to
convince them to come out of retirement and work on a libre LTE modem
ASIC project with me.  But the "proper" financing for a project of
that sort would need to be well into millions of dollars, hence I am
not holding my breath for any such venture.

On the other hand, you can have a libre modem for GSM/2G based on the
elderly Calypso chipset for much much less: the already-developed
FCDEV3B modem boards for hobbyists and tinkerers will probably go for
somewhere in the $500-600 USD range retail, and if you are interested
in an SMT modem module (directly competing with SIM900 etc) based on
the FreeCalypso core, the development cost would be somewhere in the
low 5 digits USD, as opposed to the 7 digits for a new LTE modem ASIC.

M~

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


Re: modem firmware

2017-08-29 Thread Mychaela Falconia
joerg Reisenweber wrote:

> the moral aspects of calling somebody out for removing "no parking" signs so
> people would have to pay tickets for unknowingly parking there, or not telling
> people that they are in danger to even *do time in jail* when they install and
> use a firmware that person provides, are not arguable in my world.

Please explain *just how* someone can be in danger of doing time in
jail for installing and using my bugfix updates for your buggy fw when
the actual radio transmissions from the modem remain exactly the same
whether you run the old buggy fw or one of my newer versions.  They
remain exactly the same because:

a) The hardware is obviously unchanged.

b) The RF calibration values in FFS originally written there on your
factory production line remain the same.  I do plan on offering a
recalibration service whereby a GTA01/02 device owner can send their
device to my FreeCalypso warranty service center, it gets recalibrated
at my family company on our R CMU200 (the same RF test machine we
use to calibrate the new FreeCalypso devices we produce ourselves) and
sent back to the owner with this fresh calibration, but this service
is not up yet, and when it does become available, it is naturally quite
separate from an end user merely installing a firmware update.

c) The L1 code in my current firmware is a perfect match in logic to
TI's 20070608 version which appears in your old fw versions moko3
through moko8, inclusive, a range which certainly includes whatever fw
version you used in your type approval process.

d) The radio protocol stack layers above L1 (collectively called L23)
have not changed since moko8 all the way through my current moko13,
with the exception of a few functional bugfixes which do not affect
radio operation in any way.

The only way in which the modem's radio operation can be changed after
installing one of my fw updates would be if the user not only installs
the actual fw update, but also changes the /gsm/com/rfcap file afterward
(with the fc-fsio utility's set-rfcap command) to reflect the actual
triband configuration of the hw.  But even in that case the only change
will be that the modem will no longer attempt to operate in the
unsupported and uncalibrated 4th band, which means *less* possible
radio transmission, not more.

Or are you saying that my fw updates are illegal simply because you
have made that public post from an openmoko.org email address saying
that is not officially endorsed by Openmoko the company?  If that is
your argument, then it can be easily proven that Openmoko the company
no longer exists as a legal entity in any country and that you
personally as a mere ex-employee of that no-longer-existing company
have no special power to make statements on its behalf.

And please give me at least one documented example of any police force
using extrasensory psychic powers to detect and arrest a user of a
phone whose firmware has been updated in a way which they deem to be
illegal.  Given that the actual radio transmissions remain absolutely
unchanged, they would need ESP in order to detect such an illegal fw
update.

> telling OM about alleged violations of rules while bluntly admitting that you
> yourself don't care abouzt rules, have no clue about them and think they are
> made to get violated... YES that is the spacefalcon we know and love ... *NOT*

While I do not care for any of the laws imposed by any of the self-
appointed and ultimately illegitimate national governments, as an
engineer I am very diligent about making my very best effort to comply
with sensible technical standards, and I continue to argue that my
products are better in this regard than yours.

M~

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


Re: modem firmware

2017-08-29 Thread Mychaela Falconia
Fernando  wrote:

> Having said that, I find the physical threats out of proportion
> for the intended benefit. Not to mention counterproductive.

Please cite at least one physical threat within the last 4 y, i.e.,
later than 2013-08, after the FreeCalypso social justice project
successfully ended and the FreeCalypso technical project began.

OTOH, if you are still hung up about ancient history, i.e., about the
unpleasant things I had to do back in 2013, I am sorry if you don't
like it, but there was no other way.  The people in question were
sitting on the *world's last remaining copy* of TI's TCS211 firmware
for the Calypso+Iota+Rita chipset, *no one else in the world* including
TI had a copy of this chipset fw any more, all other available TI
sources were only for their later LoCosto chipset.

The TCS211 source in question has been liberated in the fall of 2013
thanks to another comrade who did what I was not able to do myself.
It is unfortunate that no such person had stepped forward sooner, but
willingness of other people to step forward and do something which I
could not do myself is not something that I ever had any control over.

joerg Reisenweber wrote:

> wanna come shoot me once more?

For what purpose?  Just to shut you up, to stop the flow of negative
commentary from your mouth/fingers onto this list?  No thanks, I have
no interest in spending the rest of my life in prison for killing
someone who does nothing more than post a bunch of bitter commentary
on mailing lists - instead I would much rather spend my life doing
some actual productive work, like building new libre phones and modems
with the Calypso chipset and finishing the deblobbing of their fw.
Wanna show us some examples of some actual productive work YOU have
done lately?

Have a nice day!

M~

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


Re: modem firmware

2017-08-29 Thread Mychaela Falconia
joerg Reisenweber wrote:

> Please carefully note that this update is not based on the original licensed
> firmware for Openmoko devices,

Your original licensed firmware has bugs in it; the updated firmware
has some of these bugs fixed.  Want examples?  Here are just a few in
no particular order:

* Your firmware configures many Calypso signals which are unconnected
in the hardware as inputs, resulting in floating inputs.  As an EE you
surely know that floating digital inputs are generally bad.  I even
found a document from TI specific to the chips in question that says
that such floating inputs can result in excessive current draw, wasting
the battery:

https://www.freecalypso.org/LoCosto-docs/SW%20doc/0002_4006_power_consumption_APN.PDF

* In April of 2008 some clueless moron at TI-Taiwan sent you a patch
for L1 in the form of a binary blob with mystery content that attempted
to fix the infamous bug #1024.  Later you figured out that it was a
hardware bug that cannot be fixed by firmware means, but even before
that realization you knew that TI's patch from 20080421 did not improve
anything, and you even knew that the patch in question was unofficial
from TI's perspective and had not passed TI's internal quality assurance
processes:

http://lists.openmoko.org/pipermail/openmoko-devel/2008-April/002582.html

Yet you included that bogus patch in moko10 and moko11, and unfortunately
I also kept it in moko12 (my first post-OM-Inc fw from late 2013) because
I didn't know any better back then.  In moko13 the bogon has been
removed, restoring L1 to the way it was in TI's baseline TCS211 firmware,
but even better, I have successfully reconstructed recompilable C source
that compiles into a bit-for-bit match to the original blobs, i.e.,
essentially the lost source which TI had wrongfully withheld from various
customers including OM has been reconstructed and We The People now have
the Corresponding Source to what used to be a bunch of blobs.

* A different clueless moron (this one had to be an employee of OM, as
the bogon in question is present in your code but not in TI's reference
version) has put in a "gem" in fw versions moko6 through moko11,
inclusive, that tells the RR (Radio Resource) layer of the G23M protocol
stack that the hardware is quadband, when it is only triband in reality.
As a result the fw will attempt to search for GSM cells in all 4 bands,
and you even posted on this list back in 2014 that you had a US-band
FreeRunner kinda-sorta-work in the 900 MHz band.

However, the factory production line calibration on GTA01/02 devices
was only performed for the 3 properly supported bands, not for the 4th
band, hence if the fw allows the use of that 4th band and the modem's
Rx tract manages to pick up a particularly strong signal that passes
through the wrong-band SAW filter, when the modem subsequently turns
its transmitter on in that band, it will be transmitting without
calibration.  When no calibration has been done for a given Tx band,
the fw will use its hard-coded values, but because you have always said
that you only got binary blobs and no source for that part of the fw,
I have every good reason to assume that those hard-coded values (which
are overridden by factory calibration values written into FFS for the
3 properly supported bands) are not correct for Openmoko hardware at
all, and were probably set up for some earlier TI board, most likely
Leonardo.  The RF tract on TI's historical Leonardo boards was quite
different from yours, including a different RF PA, hence when your
bogus firmware operates the modem in an uncalibrated band, the Tx
power levels are going to be wildly out of spec.  I will have some
actual measured dBm numbers for you in a few months when I save up the
money to get my CMU200 properly recalibrated by Rohde

The firmware bug in question has been fixed in moko12 and moko13: these
newer fw versions no longer overwrite the /gsm/com/rfcap file in FFS
on every boot, so if you do a 'set-rfcap tri900' or 'set-rfcap tri850'
via fc-fsio as appropriate to your GTA01/02 hw variant, your correct
rfcap setting will stay, the modem will no longer waste time trying to
receive in the unsupported 4th band, and it will never act as an out-
of-spec transmitter in that 4th band.

> has not been checked and is not endorsed by
> original manufacturer Openmoko

And what exactly is the worth of an endorsement by the dead ghosts of
a no-longer-existing company that did a shitty job of supporting this
modem back when it was in business?

> and thus will void your device's (FCC/CE/...)
> approval

The fact that a modem running your official firmware that falsely
believes itself to be quadband when running on triband-calibrated hw
VIOLATES the actual technical specs for the transmitted signals can
only mean that the approval you got was fraudulent or at least
erroneous (the certification testers overlooked the technical spec
violation), and the actual radio operation of the modem with my fw is
in 

Re: Openmoko IMEI survey

2017-08-18 Thread Mychaela Falconia
Ben Deering wrote:

> The US GTA02 I still have (FCC EUNGTA02) uses 3546510116x.

Thank you for the info!  Thanks to this tidbit from you, we know now
that FIC was quite lax in (not) following the official IMEI rules,
using the same TAC (the first 8 digits of the IMEI) for devices with
different frequency band hardware configs, which is a no-no per the
official rules...

I am still waiting for confirmation on that one, but it also appears
that they used the same TAC for both GTA01 and GTA02, contrary to the
official rule that the TAC must be different for every new model no
matter how minor the change is.  (The *only* difference they allow to
exist within one TAC is the case color!)  The entry for TAC 35465101
in GSMA's IMEI database lists the manufacturer as "FIC" (not Openmoko)
and the model as "FIC Neo1973 Smartphone", so all evidence suggests
that it was originally obtained for GTA01 and later reused for GTA02.
The same IMEI database entry also lists the frequency bands as
"GSM 1800,GSM 1900,GSM 900", so clearly the reuse of the same TAC for
the "US" GTA02 version was a later hack.

My own opinion: while I do not particularly agree with reusing the
same device type code (TAC) for devices with different frequency bands
in the hardware, I fully applaud FIC (or was it OM after they split
off?) for breaking the absolutely idiotic rule about getting a new TAC
for every change in the hardware model, no matter how invisible and
irrelevant a change like GTA01->GTA02 is from the perspective of GSM
networks.  Seeing FIC (or OM) take the TAC that was officially
assigned for GTA01 devices only and reuse it for the GTA02 will
certainly help me justify further reusing the same TAC for my GTA02-
derived FCDEV3B modems. :-)

> I have not tried inserting a SIM, but I have heard that frequencies
> have been repurposed and that it probably wouldn't work in the US and
> more.

I live in USA-occupied Incalia (one of the ancient names for the
continent now called North America), specifically on land which USA
wrongfully and forcibly took from Mexico (California), and I use
nothing but GSM/2G cellular devices.  Furthermore, none of these
GSM/2G devices that I use even have that "US" 850 MHz band, instead
they are all "European triband" or what I call tri900 in FreeCalypso,
i.e., 900/1800/1900 MHz, and they make use of the GSM/2G services in
the 1900 MHz PCS band.  The operator is T-Mobile USA.

The FCDEV3B modem board I have built is a clone of the tri900 ("EU")
version of the GTA02 in RF hardware terms.  I would not know how to
build a tri850 version unless someone tells me what SAW filter part
number I should populate for the 850 MHz band in the place of the
B7820 for the 900 MHz band.  I am hoping to never need to build
Om-style tri850 hardware and to go directly to quadband instead
(following TI's Leonardo+ and E-Sample designs) for my next hardware
iteration.

M~

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


Openmoko IMEI survey

2017-08-18 Thread Mychaela Falconia
Hello Openmoko and FreeCalypso communities,

I am doing a survey of Openmoko device users to see what portions of
Openmoko's IMEI number range (TAC 35465101, a range of 1 million
possible numbers) have been used to number the 15 thousand or so
devices that have been made, and what portions are unused.  Given that
fewer than 20 thousand units have been made out of the range of
1 million IMEI numbers, simple logic says that at least 98 numbers
out of Openmoko's IMEI range must be still unused, and thus potentially
usable for new production of GTA02 verbatim clones and/or FCDEV3B
boards which are just the modem part of the GTA02.  But I need to make
my very best effort to determine WHICH portions of Om's IMEI range
have already been used, so I use a different subrange for new device
numbering.

Unfortunately it appears that no official factory records of IMEI
assignments have survived the demise of Openmoko-Inc (I tried asking
Sean M-P several times by email, but never heard anything back), hence
I am making my best effort to reconstruct this lost knowledge by way
of a community survey.

To everyone reading this solicitation who owns an Openmoko device: I
would love to hear from you if your device falls into one of the
following 3 cases:

1: If you have a GTA01 (I have never seen one with my own eyes) as
   opposed to the more common GTA02, I would love to hear if the first
   8 digits of its IMEI are 35465101 (same as GTA02) or something
   different.

2: If you have a GTA02 hardware variant with "US" bands, i.e.,
   850/1800/1900 MHz (FCC ID EUNGTA02), as opposed to the much more
   common "EU" variant (900/1800/1900 MHz, FCC ID EUNGTA02E), same
   request as above: I would like to know if the first 8 digits of the
   IMEI are 35465101 or something different.  Like with the GTA01, I
   have never seen a "US" FreeRunner with my own eyes.

3: All Openmoko devices, whether GTA01 or GTA02, "EU" or "US": if the
   first 8 digits of your IMEI are 35465101, but the following two
   digits are something other than 16 or 96, I would like to know what
   those two digits are.

The two digits after the 35465101 TAC prefix are the first 2 digits of
the 6-digit SNR (serial number) field, and it is the usage of this SNR
space that I am after.  So far the only Openmoko devices I have laid
my hands on have been GTA02 "EU" version units, their TAC has always
been 35465101, and the SNR field has always been either 16 on
older units or 96 on newer ones.  However, if there have been
Openmoko devices made with something other than 16 or 96 in
the SNR field of the IMEI, I would really like to know about them so I
can avoid stepping on those subranges and pick a subrange that has not
been used at all.

TIA for your participation in the survey,

Mychaela Falconia
Mother of FreeCalypso
www.freecalypso.org

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


moko13-beta1 firmware release candidate for GTA01/02

2017-08-08 Thread Mychaela Falconia
Hello Om community,

It has been a long time since the last official modem fw release for
Openmoko GTA01/02 devices (leo2moko-r1 aka moko12 in late 2013), so I
decided that it is time for moko13.  The differences from moko11/12
are fairly minor, and mostly serve to bring the FreeRunner target
up-to-date with the recent FC firmware developments which FreeCalypso
users have already been enjoying on our own newly made FC modem
hardware:

* The binary blob version of L1 has been replaced with recompilation
  from our reconstructed TCS211 L1 C source.  This change has a side
  effect of reverting the L1 patch from TI-Taiwan from 20080421 which
  was a stab-in-the-dark at the infamous bug #1024: L1 binary libs
  with this patch included were used in moko10, moko11 and moko12
  releases, but when I was deblobbing L1 (reconstructing recompilable
  C source that fits exactly in the place of the original blobs), my
  reconstruction produced C source that compiles into an equivalent of
  the original 20070608 version (used in moko3 through moko8), rather
  than the patched 20080421 version.  Because the patch in question
  did NOT fix or improve anything, was probably made as an experimental
  hack and was not on TI's internal mainline (as evidenced by not being
  present in the TCS3.2 L1 source for LoCosto), I have every reason to
  believe that this patch is unnecessary and that its removal will not
  cause any regressions.

* When the Calypso is used as a basic modem like in the GTA0x, most of
  its peripheral interface signals are unused, and typically left
  unconnected in the hardware.  Previous fw versions configured many
  of the unconnected GPIO and multifunction pins as inputs, resulting
  in floating inputs.  Standard hw engineering wisdom says that
  floating inputs are generally bad.  The new fw configures all unused
  and unconnected GPIOs as well as the unused and unconnected
  DSR_MODEM/LPG signal as outputs instead, eliminating the floating
  input situation.

* In the process of deblobbing the init module a bogon was discovered
  (which existed in all previous fw versions) that configured the IO1
  output (output, not input!) to also act as an interrupt source.
  This bogon has been removed.

Changes visible only to developers who use the debug trace interface
provided on the headset jack, and I mean use it to talk to the fw as
it runs, rather than just for flashing:

* An additional AT command channel is provided over RVTMUX, in addition
  to the standard one going to the phone's AP.  This mechanism makes
  it possible to exercise the modem to a large extent from an external
  host with no working software on the FreeRunner itself except U-Boot.

* The FFS access protocol has been changed from TMFFS1 to TMFFS2.  The
  new protocol is supported by our fc-fsio GSM device file system
  manipulation utility, but some old Windows tools that must have been
  used by Openmoko (of which I never found a copy, thus it is not
  known for certain if this sw still exists anywhere at all or not)
  may stop working.

* TI's GPF misfeature that suppressed the responses to "system primitive"
  commands has been fixed: if you send an sp command through fc-shell,
  you'll get the expected response as per GPF documentation.

The developer features listed above have been standard in FreeCalypso
for the past two years and are now taken for granted when doing any FC
work, but they had not made their way into a mokoN fw release until
now.

Following the tradition established by my predecessors in Openmoko's
modem fw department, I am releasing the new firmware initially as
moko13-beta1, to be tested; if the test reports indicate that it is
good, the -beta1 designation will be dropped and the new fw will
become the official moko13.  The moko13-beta1 tarball for testing is
here:

https://www.freecalypso.org/members/falcon/experimental-builds/moko13-beta1.tar.bz2

The Corresponding Source is here:

https://bitbucket.org/falconian/fc-magnetite

For help with flashing and testing this firmware update, please join
the FreeCalypso community mailing list:

https://www.freecalypso.org/mailman/listinfo/community

Sincerely,
Mychaela Falconia
Mother of FreeCalypso
www.freecalypso.org

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


Modem ID strings

2016-11-17 Thread Mychaela Falconia
Hello Om community,

I have a question about the slightly peculiar format in which Om's
official mokoN firmwares emit their ID strings, and whether or not the
modem-interfacing software in QtMoko/SHR/AoF (any others?) requires
this peculiar ID response format, or if the more standard form would
also be acceptable.

Background: the GSM 07.07 spec defines 4 commands for retrieving ID
strings from the modem:

AT+CGMI  -- get manufacturer name
AT+CGMM  -- get model name
AT+CGMR  -- get hw/fw revision
AT+CGSN  -- get serial number or IMEI

This is what the responses to these commands look like with a random
off-the-shelf USB 3G modem:

at+cgmi
huawei

OK
at+cgmm
E303

OK
at+cgmr
21.157.31.00.519

OK
at+cgsn
86087401XXX

OK

(The last 7 digits of the IMEI in the AT+CGSN response have been X'ed
 out for privacy.)

But the ID strings returned by moko11 (and all previous mokoN fw
versions) look a little different:

at+cgmi
+CGMI: FIC/OpenMoko

OK
at+cgmm
+CGMM: "Neo1973 GTA01/GTA02 Embedded GSM Modem"

OK
at+cgmr
+CGMR: "GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11"

OK
at+cgsn
+CGSN: 35465101XXX

OK

My reading of the GSM 07.07 spec tells me that the form emitted by
Huawei's modem is the standard one, whereas the form emitted by mokoN
firmwares is non-standard.  FWIW, the ACI code in the TCS3/LoCosto fw
source which we (FreeCalypso) got from TI also implements the same
believed-to-be-standard form as Huawei, *not* the mokoN form.

The difference is that mokoN firmwares emit their ID strings wrapped
like this:

+CGxx: stringwithoutspaces

or like this:

+CGxx: "string with spaces"

whereas my reading of the GSM 07.07 spec tells me that the strings are
to be emitted "plain", without any wrapping, like Huawei and TI's code
do.

We may never know why the mokoN firmwares do it the way they do (a
historical oddity), but the relevant question is this: does the modem-
interfacing software in QtMoko/SHR/AoF/others actually require this
non-standard ID response format, or would it be equally satisfied with
the simpler response format called for in the GSM 07.07 spec and
implemented by others?

When I did leo2moko back in 2013, I reproduced the AT+CGxx response
output format of mokoN, but the current FreeCalypso Magnetite firmware
emits these responses in the standard GSM 07.07 format.  Because I
plan on continuing to provide support for Openmoko devices in the
future FC firmware versions, I would like to know if the difference in
the format of these AT+CGxx ID responses is going to cause any
problems or not.

If anyone would like to test this difference experimentally, you can
flash this modem firmware image into your Neo:

https://www.freecalypso.org/members/falcon/experimental-builds/gtamodem-magnetite-20161116.tar.bz2

It should function exactly the same as moko11 and moko12 (leo2moko-r1
from 2013), but the ID strings are of the newly adopted form:

at+cgmi
FIC/OpenMoko

OK
at+cgmm
Neo1973 GTA02

OK
at+cgmr
GTA02BV4/FreeCalypso

OK
at+cgsn
35465101XXX

OK

(The "FIC/OpenMoko", "Neo1973 GTA02" and "GTA02BV4" strings emitted by
 this firmware are read out of Om's factory-programmed flash file
 system; they are *not* in my code.)

If anyone cares about QtMoko/SHR/AoF/etc continuing to work with newer
Calypso modem firmware releases, I would appreciate it if someone
using those distros could give it a quick test.

M~

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


New Calypso modems

2016-10-17 Thread Mychaela Falconia
Hello Openmoko community,

For those of you who no longer have a GTA02 or never had one to begin
with, and you wish these devices were still produced and readily
available: if the one feature of the original GTA02 you miss the most
is its Calypso modem, then you now have a chance to get a shiny NEWLY
MADE Calypso modem just like Openmoko's:

https://www.gofundme.com/fcdev3b-board-production-2umevjw

This FCDEV3B board design is my solution to the problem of Openmoko
devices no longer being made or available from surplus.  Yes, mine is
just a bare modem by itself and not a smartphone like Openmoko's, but:

1. A bare modem by itself is necessary for modem fw development.
   Openmoko devices are great for AP software development, but not
   convenient at all for modem fw dev, as I have discovered through
   experience of doing the latter.  As far as I know, Openmoko never
   did any significant development on their Calypso modem fw, instead
   they relied on TI's office in Taiwan to give them code updates -
   and the people at TI-TW who did the actual code development did NOT
   use Openmoko devices as their platform, instead they used TI's own
   D-Sample and Leonardo development boards.  The modem board I am
   building is very similar to TI's Leonardo, and is meant primarily
   for modem fw development.

2. If anyone desires to see new production of GTA02-like (or better)
   complete smartphones with FreeCalypso modems, someone else will have
   to lead the smartphone part of the project, as it is outside of my
   areas of expertise and interest - but I would be more than glad to
   provide and support the FreeCalypso modem component.

Hasta la Victoria, Siempre,
Mychaela

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


Re: greetings from the freecalypso project

2015-11-16 Thread Mychaela Falconia
Paul Wise  wrote:

> You are reminding me of this talk and cartoon by Nina Paley.
>
> http://blog.ninapaley.com/2015/10/22/copyright-is-brain-damage/
> https://vimeo.com/50481436

Her talk is wonderful, I agree with her 100%, she should be an
inspiration to everyone here.  Thanks for posting the links.

M~

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