From mxu at sanjole.com Tue Feb 4 19:10:51 2014 From: mxu at sanjole.com (Min Xu) Date: Tue, 4 Feb 2014 09:10:51 -1000 Subject: Fast SIM cards loosing bytes In-Reply-To: References: <20140124215520.8400.qmail@stuge.se>

Message-ID: Hi Dean I believe that you are seeing incomplete or partial (maybe even) ATRs. I believe I experienced something similar when I see parity error in the debug messages (from the debug port). The first byte of the ATR must be 3F or 3B. I believe the firmware code I currently have should NOT break and ATR into multiple segments. Besides, ATRs are transmitted in a single frame, so there would not be an idle time to push out the partial ATR into the USB transmit buffer. So I believe you are having similar problem that I experienced when the ribbon cable is twisted, or bent close together like a U (which might have caused interference... ) Try get a serial cable plugged into the simtrace board, and capture the debug output to see if parity error were seen. Best regards On Sun, Feb 2, 2014 at 4:40 AM, Dean Chester wrote: > 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 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 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 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 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 at 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 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Feb 5 10:01:35 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 5 Feb 2014 11:01:35 +0100 Subject: OsmoDevCon 2014: CFP Message-ID: Dear all, Time has come to fill out the "Talks/Discussions/Workshop / Hacking" section of the wiki page. If you have something you'd like to present, talk about or hack on, add it there. A simple descriptive title along with an estimated duration is enough. I guess we'll collect those for 2/3 weeks and then start making the schedule. Cheers, Sylvain