This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
E:V:A xdae3v3a at gmail.comHello Harald,
Nice to hear from you so quickly and directly.
On Thu, Mar 16, 2017 at 4:01 PM, Harald Welte <laforge at gnumonks.org> wrote:
>> However, it seem that the project is abandoned since it has not been
>> updated on your Wiki for ages.
>
> 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. In addition, most people visiting your site, probably have no idea
that they can actually contribute to that Wiki. (more about this later...)
>> For example, I cloned the SIMtrace and opened the schematics in KiCad
>> only to find that the schematic is several HW versions behind the
>> currently shown one.
>
> 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:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/debian
remotes/origin/master
remotes/origin/v1.0_production
remotes/origin/v1.1_discontinued
remotes/origin/v1.1_production
remotes/origin/v1.2_production
remotes/origin/v1.3
remotes/origin/v1.4
remotes/origin/v1.5
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. Have you abandoned the project?
>
> Not really. SIMtrace v1.4 has been produced and sold in hundreds of
> ...
> Look at the mailing list archive and the git repository
> commit history to see how limited contributions there were so far.
> Basically Kevin, Holger and I did most of the initial development in
> 2011/2012, and then there was one patch series from Min Xu in 2014 - and
> that's it!
>
> I understand that contributing to the hardware is not easily possible
> for people without EE skills. But contribution on the firmware and on
> the host software is possible for anyone with a C development
> background.
>
> So SIMtrace suffers the fate of many, many other projects that I
> developed and/or was involved in developing: It does what the original
> author[s] wanted it to do, but it stays very far behind its potential as
> nobody seems to be interested in making it do more than it did ever
> since its creation.
>
> 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
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. The turn-around-time for all this is way beyond what
most hobby/FOSS developers want to deal with. In addition, I can tell
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.
> The more popular/active projects
> have moved patch submission to gerrit at https://gerrit.osmocom.org/ -
> for SIMtrace there simply was not enough activity to bother.
Cool, probably move it there. (more below..)
> 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?
SIM1 = UART1 <==> "M3" <==> UART2 == SIM2
//
PC <---> USB <====//
> Tracing, unlike the SIMtrace 1.x which is basically tracing only due to
> the limited number of USB endpoints. However, the firmware has still
> not yet reached a stage where it can do anything useful beyond SIM card
> emulation / forwarding, so I've refrained from announcing it anywhere
> before it reaches a point where it can do SIM tracing (like v1.x) as
> well as card emulation and there is some documentation on how to use it.
>
> The current work in progress for the firmware is in
> git://git.osmocom.org/simtrace2 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?
> 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! ;)
>> 3. There is a related project on GitHub that are using SIMtrace.
>> However, the firmware there seem different. What is the current status
>> of the firmware? Are you involved in that development?
>> https://github.com/kamwar/simlabTrace
>
> 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?
> From my point of view, I don't think there's a lack of maintenance,
> there's just a lack of patches to integrate. If people on this list
> disagree, please let me know, by all means.
Hey People, please speak up now!
>> This is actually a great idea, reagrdless as your Redmine/cgit based
>> git repo is very slow and
>
> This is the first time we have received complaints about the cgit or
> actual git servers being slow. All of the Osmocom projects are hosted
> there, and most of them are significantly more complex than SIMtrace.
Yes, my unclarity. cgit is ok, although I never liked navigating there either.
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.
>> hard to navigate and the bug tracking of GH is superior in simplicity
>> to anything else freely available.
>
> yes, and once we all use proprietary "cloud" services we will all become
> ...
> I really don't like to have FOSS projects depend in their development on
> non-FOSS software. I also don't like central/single points of failure,
> whether they're called SourceForge some decade[s] ago, or whether
> they're called github now.
>
> 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. 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.
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.
Kind Regards,
E:V:A