<div dir="ltr">I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that?<div>
<br></div><div>Scott<br><br><div class="gmail_quote">On Mon, Nov 22, 2010 at 4:49 AM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se">peter@stuge.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Harald Welte wrote:<br>
> > > - the AT91SAM7SXXX<br>
> ><br>
> > I'd use a more modern chip<br>
><br>
</div>> no, no, no, no ;)<br>
<br>
After seeing the schematic I tend to agree.<br>
<div class="im"><br>
<br>
> There is working firmware (drivers, T=0 sniffing, ...) for the<br>
> AT91SAM7 now, I put quite a bit of effort into making this work.<br>
> Furthermore, the AT91SAM7 USART has the unique property that you<br>
> can use it in T=0 mode but still operate as clock slave, i.e. run<br>
> as sniffer or card mode, not behaving like a card reader.<br>
<br>
</div>I think every sync serial peripheral that I've seen can operate in<br>
slave mode like that, and I agree that it's important.<br>
<div class="im"><br>
<br>
> We really do not need any external logic, simply connect the SIM<br>
> card to the right pins of the SAM7, load the (gpl licensed, of<br>
> course) firmware that I wrote and run the equally free software<br>
> 'simtrace' host program + wireshark.<br>
><br>
> Porting this to a different microcontroller will again require<br>
> significant development on the software side, which I don't think<br>
> is what we need...<br>
<br>
</div>I disagree that significant effort would be required. It should be<br>
straightforward to use another controller, but since the schematic<br>
wouldn't really be much simpler there may not be much point to it.<br>
<br>
But one thing that I think matters is that it's very easy and cheap<br>
to get hold of a really simple (e.g.) LPC1343 development board in<br>
neat size that people could use instead of having to build their own<br>
hardware. I think that wall clock time would be about same for<br>
porting the software and producing a board.<br>
<div class="im"><br>
<br>
<a href="mailto:ml@mail.tsaitgaist.info">ml@mail.tsaitgaist.info</a> wrote:<br>
</div><div class="im">> I could not login/register on the osmocom trac wiki to put the files<br>
> there.<br>
<br>
</div>Hopefully someone will fix that.<br>
<div class="im"><br>
<br>
> Here the current version :<br>
> <a href="https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps" target="_blank">https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps</a><br>
<br>
</div>Thanks for uploading it!<br>
<div class="im"><br>
<br>
> I added the JTAG and debug connectors. I hope it will not use more<br>
> then 2 layers in the end, so normal people can build the pcb at home.<br>
<br>
</div>Since the crystal is around 18 MHz this might even work OK as a<br>
single layer board, maybe with a solid ground plane on the back for<br>
the ambitious.<br>
<div class="im"><br>
<br>
> - the user has to tell the program<br>
> - or by detecting the presence of a card (provided by the id-1<br>
>   socket, but some tricks have to be used for the id-000 socket)<br>
> - or by having a switch with 3 modes (sniff,emulation,MiM) (my<br>
>   favorite solution)<br>
<br>
</div>It would be really nice to not have to deal with switches, and just<br>
let the host software tell the hardware which mode to use. A USB<br>
device control request could do the trick easily.<br>
<font color="#888888"><br>
<br>
//Peter<br>
<br>
</font></blockquote></div><br></div></div>