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/.
Min Xu mxu at sanjole.comHi 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 <dean.g.chester at gmail.com>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 <mxu at 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 at 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 at 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 at 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 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 <peter at 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20140204/cef80701/attachment.htm>