Hi Min, 

I've just been using the new firmware with a different type of sim card and noticed that the ATR is scrambled, at least for the header of the ATR. The ATR is the same length as the one I had great success with. The cards are running at the same speed according to the ATRs however the new card seems to send it's ATR over 3 commands not just one. Whats also interesting is the ATR scrambling is different. Here is an example with the Simtrace Header attached: 

01 01 01 01 01 00 00 00 1a 00 e7 9a 03 1f c7 80 31 00 00 00 00 00 00 00 00 00

01 00 01 01 02 00 00 00 0f 00 00 00 00 00 00

01 00 01 01 03 00 00 00 12 00 00 00 00 00 00 00 00 00

And the ATR should look like: 

3B 9F 96 80 1F C7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

And with the same card from the same company I got: 

01 01 01 01 01 00 00 00 16 00 9f 96 80 1f c7 80 31 00 00 00 00 00 

01 00 01 01 02 00 00 00 13 00 67 42 70 02 10 00 00 01 f9

01 00 01 01 03 00 00 00 12 00 ff 10 96 79 ff 10 96 79

With the card I had success with I got the following input in: 

01 01 01 01 01 00 00 00 20 00 3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And the ATR looks like: 

3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Any ideas where these errors are coming from in the firmware. I notice that the lengths in the failed are equal to 3B which is the start of the ATR if thats of any help. The tests were done with the same phone connected to the tracer just swapping the sim cards.

Kind Regards, 

Dean Chester

On 30 January 2014 21:47, Min Xu <mxu@sanjole.com> wrote:

That does make sense to me since I had issues where before I changed the usb header, the host was sometimes merging multiple req_ctx into a single usb read.

I am attaching a tar.gz file containing all my changes as separate git commits / format-patches and hopefully it will get committed to the repository.  This includes the latest change to the usb header as well as a change (as Peter suggested) to the bDeviceProtocol in usb_descriptors_openpcd.h, setting the new value to 0.

Best Regards

On Thu, Jan 30, 2014 at 6:21 AM, Dean Chester <dean.g.chester@gmail.com> wrote:

It was mostly the lost bytes/scrambled data with a variety of handsets that i'd tested with, compared with ubuntu running natively. 

Dean

On 27 January 2014 18:37, Min Xu <mxu@sanjole.com> wrote:

P.S.  What problems were you experiencing of it running in a virtualized system, can you elaborate?

Thanks

On Mon, Jan 27, 2014 at 8:36 AM, Min Xu <mxu@sanjole.com> wrote:

I am contributing it to the project.  Once I incorporate Peter Stuge's suggestion, hopefully within the next few weeks I will submit another commit.

Best Regards

On Mon, Jan 27, 2014 at 1:05 AM, Dean Chester <dean.g.chester@gmail.com> wrote:

Thanks Min it works a treat it also fixes the issues running in a virtualised environment which I do for Ubuntu. 

Is your new firmware under the same licence as the original?

Kind Regards, 

Dean Chester

On 24 January 2014 21:55, Peter Stuge <peter@stuge.se> wrote:

Min Xu wrote:
> I would be happy to send them the USB protocol changes.  However,
> it will be INCOMPATIBLE with earlier firmware based SIMTrace boards.

There is a standardised way to deal with protocol changes in USB;
change either the bDeviceProtocol field in the device descriptor or
the bInterfaceProtocol field in the interface descriptor, and make
host software do the appropriate thing based on the descriptors of
the connected device.

Of course only new host software will work with the new protocol, but
this way new host software still continues to work with the old protocol.


//Peter