simtrac hw

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

Harald Welte laforge at
Sun Nov 21 19:53:49 UTC 2010


On Sun, Nov 21, 2010 at 03:14:34PM +0100, ml at wrote:

> His solution is way easier, and more reliable. This is why I've now done
> a hw design for it.

thanks a lot.

> I don't know if it's the right mailing list, but it seemed to be the best.

well, I think it is low-traffic and we might just use this mailing list
for the time being.

> - the AT91SAM7SXXX
> - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual
> size, as on the rebelSIM
> - 1 SC port (IN) to connect the SIM for the phone (I would use the ones
> from rebelSIM)
> - 1 SC port (OUT) to be able to use the signal using external HW
> - the sam-ba port to be able to flash it

I think we should consider the following use cases:

1) passive sniffer

this is what simtrace is doing right now and what your hardware is also
prepared for. 

2) card simulation

this is possible with the same circuit.  Simply connect it _only_ to
the phone and not to a smart card at all.  The wiring will be the same,
but the USART will be used in Rx and Tx mode.  Only software/firmware
changes required.

3) man in the middle

in this case, we want to connect as master (reader) to the SIM card,
and as slave (card-side interface) to the phone.

In order to make we run USART0 as clock-slave (like in case 1 + 2 above),
but we also connect a sim card socket to USART1, which we can then run
in clock-master mode, i.e. like any 'regular' SAM7 based smart card reader.

The easiest solution would be to add yet another sim card socket which is
connected to USART1 (TXD1/SCK1).  But then we have 3-4 sim card sockets
in one device, which I think is clumsy.

It may be possible to add some jumpers or dip switches that change the
behavior, i.e. "one setting for sniffer + card simluation, another setting for

> here the schema :
> please tell me if there is something wrong, or needs some improvement. I
> will design the PCB shortly.

please take time for detailed review before doign any pcbs... thinking more
before prototyping will save time and money.

Another request: Pleaes make the DRxD / DTxD (Debug UART) pins available on the
board, preferrably on the same type of header that we use on the OpenPCD.  It
will not add any cost to the design, but enable you to print debug messages to
a serial port, which is very useful during firmware development.

Also, the JTAG lines should be routed to a standard 20-pin ARM-JTAG connector.

Both the Debug-UART and the JTAG headers can not be placed/soldered for normal
boards, but people who want to do development will likely find both of them
very useful.

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list