Dear Osmocom,
I have been following your SIMtrace project for some time and wanted to build and try a few things. However, it seem that the project is abandoned since it has not been updated on your Wiki for ages. I know you guys are very busy with your many other and more interesting projects and that this project is very old, but we would still appreciate if you could at least try to keep your own GIT repo updated with the stuff you are showing on the wiki. 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. So my questions are:
1. Have you abandoned the project?
2. Where can I find/download the latest Firmware, KiCad (Schematics and PCB) design files?
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
If your answer to (1) is a Yes, then perhaps it would be better to publish your project to GitHub instead, so that other people can help and take over the maintenance? This is actually a great idea, reagrdless as your Redmine/cgit based git repo is very slow and hard to navigate and the bug tracking of GH is superior in simplicity to anything else freely available.
Kind Regards, E:V:A
Hi EVA,
nice to hear from the xda-developers hero ;)
On Thu, Mar 16, 2017 at 03:04:50PM +0200, E:V:A wrote:
I have been following your SIMtrace project for some time and wanted to build and try a few things.
great.
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.
I know you guys are very busy with your many other and more interesting projects and that this project is very old, but we would still appreciate if you could at least try to keep your own GIT repo updated with the stuff you are showing on the wiki.
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.
- Have you abandoned the project?
Not really. SIMtrace v1.4 has been produced and sold in hundreds of units and is successful from that point of view. There are plenty of users around the world. We still ship several units every week from sysmocom (and of course don't know who might have built their own circuit boards).
What I believe it suffers from is however a very "consumerist" behavior of many users. Meaning that they obtain the device and use the existing firmware + host software, without understanding (or caring about) the fact that it is a collaborative project that only lives by contributions. 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. 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.
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 mor versatile USB confiugrations CCID / Card-Emulation / 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.
The initial v2.0 hardware is exactly the v1.4p simtrace board, but with a AT91SAM3S soldered instead of the AT91SAM7S.
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.
If anybody wants to help, by all means, you're more than welcome.
- Where can I find/download the latest Firmware, KiCad (Schematics
and PCB) design files?
* schematics + PCB design files for v1.4 are in the simtrace.git repo https://git.osmocom.org/simtrace/ git://git.osmocom.org/simtrace
* firmware source code is in http://git.osmocom.org/openpcd/ git://git.osmocom.org/openpcd
- 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.
If your answer to (1) is a Yes, then perhaps it would be better to publish your project to GitHub instead, so that other people can help and take over the maintenance?
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.
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.
Maybe it relates to geography. Most developers appear to be in continental Europe. Where are you based? Can you send a tracerounte?
The redmine interface to git is slow, but then that's exactly why cgit is running. Maybe we should disable it in redmine?
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 dependant on them. "freely available right now" is "Free as in Beer" but not "Free as in Freedom". Also look at formerly large sites like google code or gitorius, and how they disappeared and what it meant for many projects. Not to forget the recent backup/restore issues at gitlab...
Finally, even in terms of "free as in beer", nothing can guarantee you that github will stay free of cost for FOSS projects forever. Just wait until another investor comes around, and then they will start to SPAM all your usrs with advertisements or the like.
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?
One of the strength of the FOSS culture is the fact that it is distributed and diverse. Reliance on a single service just because it is convenient is not a good excuse to give up that diversity and resilience.
FYI: there are some automatically mirrored repositories at https://github.com/osmocom and I'm happy to extend those to the simtrace related repositories, if it helps. We have an auto-responder in case somebody sends pull requests, indicating to them how to submit patches to our projects instead.
Regards, Harald
Hello Harald,
Nice to hear from you so quickly and directly.
On Thu, Mar 16, 2017 at 4:01 PM, Harald Welte laforge@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...
- 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! ;)
- 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
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 https://gerrit.osmocom.org/ - 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://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?
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 clear.
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.
Regards, Harald
On Fri, Mar 17, 2017 at 04:39:34PM +0100, Harald Welte wrote:
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.
we changed the v1.0 design so to fit the production. The manufacturer of the board had a surplus of some components (mosfet, diode), so we decided to replace some of the components we initially chose to speed up and ease the production (the component requirements were identical, only the footprint were different). I think we did the same for v1.1 and v1.2, and we just kept the 'p' (for production) from there on but the design didn't need to be changed. This confusion is now only due to historical reasons.
Hi Harald,
Thank you so much for taking the time to respond to all my inquiries and challenging comments/requests. Your response has indeed convinced me that this project is very much alive, but that it need a whole lot more of community TLC.
On Fri, Mar 17, 2017 at 5:39 PM, Harald Welte laforge@gnumonks.org wrote:
hi E:V:A, ...
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?
You're probably right, but another aspect of contribution is what effect even the smallest ones has. What I mean is, that when a drive-by developer finds a minor error somewhere, he/she just doesn't bother to open email and register and so on, just to send a patch for some misspellings, minor buffer allocation error and the like, in the hope someone else will fix it. So given the low external developer participation in this project, it may seem dead from the outside perspective as there are barely any new pushes or changes. Now, perhaps I could be very wrong here, but my own thinking goes like that. I regularly find github projects that have been forked in dozens, and although the original or older forks are better, I still usually choose to use one of the later ones, just to be sure that if I do make some changes or have some comments or bugs to report, that someone is on the receiving end..
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)
Good idea.
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.
Yeah, I noticed almost immediately. Very good. Also have you tried to run the files in the latest KiCAD 4.0.6? There are some new changes there, that require some files to be updated. (automatic)
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 ;)
I knew you would mention this. ;) But that has quite a different project scope doesn't it...
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.
I agree, you have me convinced.
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 see. I would suggest trying a new approach of working on this "on top of the scene" so that people see that something is happening and that they can jump right in to contribute if they want.
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*].
True and fair enough. I would be happy to deal with the documentation in case I ever get my hands on the new HW.
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?
No offense taken. They (bodziow and kamwar) just recently responded to my question here: https://github.com/kamwar/simLAB/issues/1 and indeed thay have made several improvements.
--------------------------------------------------------
"We have refactored that source code (i.a. removed unneeded modules), separated reader and forwarder functionality and added some improvements and bugfixes. The most important work has been done on the Python (Host) side."
and:
"simLabTrace is APDU forwarder - it receives APDU data from UE, forward it to simLAB and send back the data from simLAB to UE. As Szymon already mentioned, we removed unused files and do basic refactor to split functionality between forwarder code and CCID reader. Most changes in the firmware code are for CCID reader but there are also several fixes and improvements for APDU forwarder. Although original simTrace firmware should work in passive mode it turned out that sometimes the SIM inserted into the SIM slot is not recognized at all, e.g. simTrace doesn't allow to sniff card reader connection (CCID reader -> simTrace -> SIM in simTrace slot). I can't recall the exact solution for this problem but it was related with PTS procedure."
--------------------------------------------------------
This seem very promising, so I guess a closer collaboration with them would benefit everyone.
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.
Awesome and very encouraging!
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 clear.
Very good and you have me convinced. Thanks again for your time and I think it has been well spent.
Many Cheers, E:V:A
Hi E:V:A,
On Tue, Mar 21, 2017 at 03:48:41PM +0200, E:V:A wrote:
Thank you so much for taking the time to respond to all my inquiries and challenging comments/requests. Your response has indeed convinced me that this project is very much alive, but that it need a whole lot more of community TLC.
I'm not sure what TLC is? But yes, like most projects, we can use help on various sides.
No offense taken. They (bodziow and kamwar) just recently responded to my question here: https://github.com/kamwar/simLAB/issues/1 and indeed thay have made several improvements.
Well, the problem that I see is that they have created a fork or done an independent new implementation or something in between. So rather than working collaboratively with the existing project, and contributing their work, they have created their own project. Everyone is of course free to do what they want, but it makes me somehow sad. Have we ever done something to them that made them go away?
The worst thing that a user wants is that there are 25 different programs, all having different feature sets and different bugs, maybe even based on different forks of some code made at some point in time.
From a user point of view, you want one software in which everyone tries
contributes their bug fixes and feature enhancements.
And particularly, as we are talking about the firmware and host programs separately, there should at least be some level of standardization on the USB protocol, so that you have interoperability between the in-device firmware and different host programs.
However, I haven't seen anyone showing up and proposing (let alone implementing) a more flexible/standardized/future-proof USB protocol.
This seem very promising, so I guess a closer collaboration with them would benefit everyone.
I do not recall ever having turned down any collaboration with anyone. But collaboration is not "I silently take this code and make my own version of it", but collaboration is to actively work together, to submit proposals, code, comments, etc.
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.
Awesome and very encouraging!
Thanks. I would never do it any differently, and I guess anyone who has been following some of my past work would see where my priorities are.
There are too many projects out there that are suffering (from my point of view) of too much corporate/commercial influence.
Osmocom has existed before sysmocom came around (and hopefully will exist after sysmocom is history?), and sysmocom is only involved in a certain subset of projects.
Thanks again for your time and I think it has been well spent.
I'm happy my feeling about this was right :)
-
E:V:A -
Harald Welte -
Kévin Redon