Current status of the SIMtrace project

Harald Welte laforge at
Fri Mar 17 15:39:34 UTC 2017

hi E:V:A,

On Thu, Mar 16, 2017 at 05:53:30PM +0200, E:V:A wrote:
> Nice to hear from you so quickly and directly.

likewise.  I guess we've been working on different ends of cellular
communications during the last decade but never really crossed roads.

> > Well, it is a collaborative effort.  With several hundred SIMtrace
> > device owners out there, one would hope that the wiki gets updated by
> > users if they find something is out of date.
> Aha, I understand. Well, that is exactly the problem. Today developers are
> very sensitive and lazy to signing up to anything, unless its a one-click
> operation.

I find that hard to believe. Today, contrary to 20 or even 10 years ago,
almost every website requires you to register, so I somehow doubt that.
We even support OpenID based authentication on our redmine, so you
should be able to log in with many other accounts.  That won't give you
write permission (see below), but maybe we can do something about that.

Also, if you cannot even bother to send a patch series by e-mail, or
send an e-mail to request commit / write access, then I don't think you
have time or energy to contribute to a project.  After all, what is the
one minute to send that mail compared to the many hours, days or weeks
of your life you're working on the actual contribution?

> In addition, most people visiting your site, probably have no idea
> that they can actually contribute to that Wiki.  (more about this later...)

We can either
* update the wiki to explicitly explain that, even add it to every page
* re-enable public registration with write permissions with some
  automatic spam filtering (wiki spam was the reason to disable it some
  years ago)

> > revision 1.4 (1.4p where 'p' is just for production) of the hardware has
> > been current since 2014.
> Sorry, my bad. I was looking only in the master branch, hoping that
> would reflect latest production releases. And they are not named "1.4p",
> AFAICT, but:

The 'p' is for 'production', kevin introduced that some time ago, I
don't recall the exact rationale.

> So I found the 1.5 schematics and it simply look funny as there are
> a number of "??" parts covering others while others are unconnected...

1.5 was an abandoned work-in-progress and is not what has shipped to
anyone, AFAICT.

v1.4p is what all circuit boards of recent years are labelled, so the
v1.4 tag is applicable.  The schematics should render nicely.

I've updated the wiki with a png and pdf schematics as well as gerber
for that revision. 

> > Osmocom has always been open to anyone. Anyone can post patches to the
> > mailing list, anyone can get write permissions to the wiki. Simply
> > register an account and let us know.
> Again, I sincerely believe this is because the contribution threshold is
> way too high for most small and highly technical projects like this. As I
> mentioned above, people simply don't use mailing lists anymore and

Well, I can equally state I won't use anything else for communication.
E-mail is perfect due to its offline/asynchronous nature.  I don't have
to be connected to read/write them.  I don't need a sluggish web
browser.  I don't need a mouse, even.

> they certainly hate to have to email their patches, just to find out that
> they conflict or have some other minor errors that prevents them from
> getting implemented. 

Well, then everyone would have to hate developing on the Linux kernel?
My experience in that field is quite different, even though I haven't
been doing much kernel work in many years ;)

> The turn-around-time for all this is way beyond what most hobby/FOSS
> developers want to deal with. 

Actually, if I am not working on something full time (e.g. just in the
evenings), then the turn-around time to wait for some feedback until the
one of the next evenings I spend on the project is actually fitting very
well the rhythm of my work.   Only poeple who work on something
full-time, with a tight deadline need quick turn-around times.

> what I learned from my own experience of failed projects. That unless
> the original developer or other highly skilled (in that project) is watching
> and maintaining it (from a feedback point of view) like a Hawk, it will
> quickly disintegrate and people will start doing weird shit all over, if not
> breaking it all together. Then for sure its dead.

sure, that can very well be the case.  But then, it's always up to
people to decide what they do or what they don't do.  If somebody cares
sufficiently, then it will be revived.  If not, then it might be dead
for good.  Which is maybe sad from an emotional point of view, but why
does it matter?  If nobody is interested in (and capable of) moving a
project forward, then what's the point o the project.  People with an
actual need / itch to scratch will work on it.  And if there are no such
people, then nobody needs the project :)

> > The more popular/active projects
> > have moved patch submission to gerrit at -
> > for SIMtrace there simply was not enough activity to bother.
> Cool, probably move it there. (more below..)

I would argue to do that with the new simtrace2.git firmware.  With the
old code it probably makes no sense unless somebody actually has
something to submit.

> > Behind the scenes we've been working on-and-off during several year on a
> > hardware + software refresh called 'simtrace 2'.  The controller has
> > been changed from SAM7S to SAM3S, which supports more USB endpoints and
> > thus allows for more versatile USB configurations CCID / Card-Emulation /
> I don't see why you need more USB endpoints for this? Isn't it enough
> with 1-2 since the 2 IF are using the UARTs. Shouldn't all the Tracing, MiTM
> and Emulation be done in the FW?

You can, but not if you want to have the "Card reader" part use a
generic driver and middleware architecture, i.e. a USB-CCID compatible
device on which you can run OpenCT or pcsc-lite and the likes.  I
strongly believe in interoperable standards.  And unfortuantely the SAM7
has insufficient USB endpoints to offer a two-interface configuratio
with one USB-CCID compatible one simultaneous to another one for the
'card emulation' part.

> > The current work in progress for the firmware is in
> > git:// but as stated I think it's not ready for
> > wider consumption.  The firmware is a complete rewrite without the
> > legacy of the openpcd project that lives in the SIMtrace v1.x firmware.
> Great! How well is the FW code compartmentalized in the sense that
> it can be used with or easily ported to different HW?

All the peripherals of SAM7 and SAM3 are [almost] identical.  They
basically switched the CPU core and left most other parts identical.  It
shouldn't be *that* hard with the excaption of the smaller number of USB
endpoints, as indicated above.

> > My roadmap would be to:
> > * complete SIM tracing, card emulation and CCID in simtrace2.git
> > * write related documentation
> > * start to transition to v2.x in the webshop
> > * maybe, if there is sufficient interest, try to port the v2.x firmware
> >   to v1.x, although it's rather comprehensive task due to the ARM7TDMI
> >   <-> Coretx-M3 transition.  At least the tracing and card-reader
> >   functions should work in theory, MITM will be v2.x only.  Advantage
> >   would be identical USB protocol to the host and identical host
> >   utilities for both v1.x and v2.x.
> Sound like the perfect opportunity to try GitHub! ;)

I'm not sure why? So far, nobody has even stated in any way that they'd
want to do some work on it [not even you *g*].

Also, as indicated before, I don't like to depend with my development on
third party web services.

> > I don't recall having seen this before, so I cannot comment on it.
> Please have a good look. It is quite nicely documented with beautiful
> pictures. I'd like to know how their FW and SW compares to your
> developments, and if something new have been already implemented?

No offence, but if you have an interest in such a comparison, I suggest
you create it?

> Hey People, please speak up now!

Indeed.  I guess nobody is used to receiving mails on this list anymore ;)

> Yes, my unclarity. cgit is ok, although I never liked navigating there either.

good (first part)

> It's your Redmine GIT/repo integration that is horrible. E.g. It doesn't show
> time stamps and when you hit browser back button it puts you back in the
> beginning rather than on the page you saw before the current one.

it isn't "our" redmine git integration, but it is the git integration of
redmine.  If you don't like it, I suggest you provide feedback and/or
patches to the redmine project.

All we can do is disable it (and redirect to cgit), if more people thing
it hurts more than it helps.

> > There are many FOSS projects that are not hosted on github, many of them
> > way before github existed.  If somebody claims they cannot or will not
> > contribute because it is too difficult to register an account on our
> > redmine, or to enroll their ssh key for commit access, then I am
> > somewhat doubtful as to how large their interest really is to
> > contribute.  Wouldn't you agree?
> I agree with most of what you say above, but this is the world we live
> in and try to be productive in. The same arguments can be used against
> your company, suddenly someone offers you a billion EUR and then
> the party is over. 

Which party is over?  When we started sysmocom, we made very sure that
it does not control the Osmocom projects in any way.  It doesn't hold
the trade marks, and all time Holger or I spent on development of
Osmocom code is our personal copyright, and not that of a company.
Also, there are no copyright assignments with contributors, making it a
safe guard against anyone who might want to come later to try to change
the license or whatever else.

We have started sysmocom to be able to generate business that funds more
developers and developments for Osmocom.

SIMtrace was btw. developed mostly outside sysmocom.  WE just used the
opportunity of having a company that has processes and workflows for
electronics development to provid ready-built units to interested people
who don't want to go through the effort of building it themselves.

> If you want to be productive, we need to use the best tools currently
> available and not worry so much what will happen to those 2 years down
> the line.

You are free to do what you want.  I will not compromise on this.  I am
not using non-free software to develop FOSS.  In fact, we even go beyond
this to a large extent even in sysmocom:  We do everything down to
accounting in FOSS, even non-tech staff works on Linux and the only
Windows machines are our Oscilloscope/Spectrum Analyzer/VNA.

Under some circumstances, I might even consider investing in a
source-code license of a proprietary project management software that I
could host myself, and fix/improve myself.  But I will certainly not
depend on third-party *services*, where I have no clear idea how to ever
migrate away from it, once they change their terms of service or go out
of business.

> Seeing in general how things are developing with privately maintained FOSS,
> I really think we should consider making some compromise. A good idea
> would be to do the opposite of what you proposed, by making your GitHub
> the offical repo and use instead your private as a mirror. As a FOSS you can
> also have free private repos.

I don't care where the primary git repository is hosted.  But  I do care
about not using all the non-free issue tracking and merge request
features of a proprietary service.

This discussion has been taking a significant amount of time over the
past days, and I think we have made both of our views sufficiently

I would love to see contribution from anyone, including you, in
whichever way.  I'm happy to gerrit-enable the related repositoires,
and also happy to provide SAM3-versions of the SIMtrace v1.4p boards for
free.  But I certainly won't make my development depend on tools I
cannot control.

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the simtrace mailing list