Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-11-30T11:52:04ZOpen Source Mobile Communications
Redmine SIMtrace 2 - Feature #5805 (New): SIM Trace 2 Build for Windowshttps://osmocom.org/issues/58052022-11-30T11:52:04Zjelson_simEng
<p>Hello all,</p>
<p>I have been working on trying to have SIMTrace2 build for windows.<br />I am checking just in case someone has already done that and has something that might share.</p>
<p>Thank you,<br />Jelson G.</p> SIMtrace 2 - Bug #5770 (Feedback): simtrace2 firmware ignores any but the first USB message sent...https://osmocom.org/issues/57702022-11-14T17:46:04Zlaforge
<p>The simtrace2 firmware appears to have a problem (probably a race condition of some sort, with the USB stack) where it accepts the first USB message sent by simtrace2-list after a reset, but then ignores others. During investigation, it was noticed that when sending two commands in a row from a single instance of simtrace2, the first is ignored, and the second is processed.</p>
<p>So, in <a class="external" href="https://gerrit.osmocom.org/c/simtrace2/+/26864">https://gerrit.osmocom.org/c/simtrace2/+/26864</a> a hack was put into `simtrace2-tool` so that it sends a fake, empty, error message, to kick the remote SIM firmware into accepting the second, real message. The strange thing is, that when you send two messages like this, it has the side effect of keeping the processor from getting stuck.</p>
<p>So, something about sending two messages has two effects 1.) it kicks the SIM firmware, if it is stuck, and 2.) prevents the SIM firmware from getting stuck in the first place.</p> SIMtrace 2 - Bug #5639 (Feedback): No packet captured but only "Card state change:"https://osmocom.org/issues/56392022-07-31T16:18:56Zg1bbs
<p>Hello, I'm facing a problem when using the trace function. It doesn't capture any packets and the phone (iphone se/iphone xs) shows "No SIM card".</p>
<p>I used the latest version firmware, flashed with dfu-util. I inserted the valid sim card into the simtrace board, inserted the cable-sim into the phone, start the sniff program and turn on the phone. But it keep output "Card state change:". Is it a bug or my problem? Thanks!</p>
<p>(the board version on the back is v1.5 with ATSAM3SD8B chip)</p>
<p>Here's the console output when flushing.
*<strong><b></strong>*</b>**<strong>**</strong>*******************************<br />test@1-NUC8i7BEH:~/SIMtrace$ sudo dfu-util --device 1d50:60e3 --cfg 1 --alt 1 --reset --download simtrace-trace-dfu-latest.bin <br />dfu-util 0.8</p>
<p>Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.<br />Copyright 2010-2014 Tormod Volden and Stefan Schmidt<br />This program is Free Software and has ABSOLUTELY NO WARRANTY<br />Please report bugs to <a class="email" href="mailto:dfu-util@lists.gnumonks.org">dfu-util@lists.gnumonks.org</a></p>
<p>dfu-util: Invalid DFU suffix signature<br />dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!<br />Opening DFU capable USB device...<br />ID 1d50:60e3<br />Run-time device DFU version 0100<br />Claiming USB DFU Runtime Interface...<br />Determining device status: state = appIDLE, status = 0<br />Device really in Runtime Mode, send DFU detach request...<br />Device will detach and reattach...<br />Opening DFU USB Device...<br />Claiming USB DFU Interface...<br />Setting Alternate Setting <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> ...<br />Determining device status: state = dfuIDLE, status = 0<br />dfuIDLE, continuing<br />DFU mode device DFU version 0100<br />Device returned transfer size 512<br />Copying data from PC to DFU device<br />Download [=========================] 100% 23532 bytes<br />Download done.<br />state(7) = dfuMANIFEST, status(0) = No error condition is present<br />state(2) = dfuIDLE, status(0) = No error condition is present<br />Done!<br />dfu-util: can't detach<br />Resetting USB to switch back to runtime mode</p>
<p><strong><b>the console will stuck here</b></strong><br />------------------------------------------------</p>
<p>Here's the console output when tracing.
*<strong><b></strong>*</b>**<strong>**</strong>**********************************<br />test@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ ./simtrace2-list <br />USB matches: 2<br /> 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br /> 1d50:60e3 Addr=6, Path=1-4, Cfg=2, Intf=0, Alt=0: 255/255/0 (0.8.1.36-a5d53)<br />test@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ sudo ./simtrace2-sniff <br />simtrace2-sniff - Phone-SIM card communication sniffer <br />(C) 2010-2017 by Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>><br />(C) 2018 by Kevin Redon <<a class="email" href="mailto:kredon@sysmocom.de">kredon@sysmocom.de</a>></p>
<p>Using USB device 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br />Entering main loop<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted, reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />^Ctest@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ sudo ./simtrace2-sniff <br />simtrace2-sniff - Phone-SIM card communication sniffer <br />(C) 2010-2017 by Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>><br />(C) 2018 by Kevin Redon <<a class="email" href="mailto:kredon@sysmocom.de">kredon@sysmocom.de</a>></p>
<p>Using USB device 1d50:60e3 Addr=6, Path=1-4, Cfg=1, Intf=0, Alt=0: 255/1/0 (SIMtrace Sniffer)<br />Entering main loop<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />Card state change: reset de-asserted<br />Card state change: reset asserted<br />^Ctest@1-NUC8i7BEH:~/SIMtrace/simtrace2/host/src$ <br />------------------------------------------------</p> SIMtrace 2 - Feature #5600 (Feedback): SIMtrace2 fails to emulate EMV cardshttps://osmocom.org/issues/56002022-07-03T19:43:09Zboggy123
<p>Greetings!</p>
<p>I acquired a SIMtrace2 with the hopes of using it for my undergrad dissertation. Many thanks for the hardware and software. I want to relay an EMV ISO-7816 card and observe the communication. I've set the simtrace2-cardem-pcsc to use data found in a virtual smart card interface. When I attempt to make a payment(Ingenico 5000/Square reader) it fails as the command that I have to return to the card fails to transmit. There are traces in the log for an 'Unknown APDU case 0'.</p>
<p>My assumption is that the command received by the emulator(GPO - Get Processing Options) is not interpreted correctly.<br />Command in question: DLGLOBAL INFO => DATA: flags=0x01 (HDR ), <strong>80 a8 00 00 02</strong>. I can only assume that <strong>02</strong> is the length of data that should follow but no data is available.</p>
<p>firmware: latest -- simtrace-cardem-dfu-0.8.1.34-e450.bin<br />Terminal output: <a class="external" href="https://pastebin.com/raw/tYUGSc6k">https://pastebin.com/raw/tYUGSc6k</a></p>
<p>Many thanks</p> SIMtrace 2 - Bug #5464 (In Progress): cardem firmware unable to attach to cardhttps://osmocom.org/issues/54642022-02-21T19:07:57Zk_o_
<p>I'm using a Nexus 5 phone. I have a permanent problem that the remote SIM cannot be attached. I always see several RESETs after the phone is restarted. The trace firmware together with the command line works. The adapter cable is in a prepared SIM tray and works. What could be the issue?</p>
<pre>
simtrace2-cardem-pcsc --usb-vendor 1d50 --usb-product 60e3 --usb-path 2-1.4 --usb-config 1 -n 2
simtrace2-cardem-pcsc - Using PC/SC reader as SIM
(C) 2010-2020, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>
<0002> simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
<0002> simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
<0002> simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
<0002> simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f c7 80 31 e0 73 f6 21 13 67 56 03 27 00 89 01 02 28 )
<0002> simtrace2_api.c:284 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Entering main loop
-> 01 08 00 00 00 00 0d 00 01 00 00 00 00
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
</pre> SIMtrace 2 - Bug #5423 (New): "trace" firmware continuous test setuphttps://osmocom.org/issues/54232022-01-27T12:24:54Zlaforge
<p>Similar to <code>cardem</code> in <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: "cardem" continuous testing setup (In Progress)" href="https://osmocom.org/issues/5422">#5422</a>, we should also create a continuous test setup for passing SIM protocol tracing. The IUT is the simtrace2 firmware.</p>
<p>We can use diffeent modems / CCID readers accessing a SIM card via a SIMtrace2 device while tracing the communication.</p> SIMtrace 2 - Feature #5422 (In Progress): "cardem" continuous testing setuphttps://osmocom.org/issues/54222022-01-27T12:22:10Zlaforge
<p>We shuold create a test setup where we can continously test the <code>cardem</code> firmware for the various targets, such as at least simtrace2 and qmod.</p>
<p>The idea would be to use the TTCN3 test ports for SIMTRACE USB protocol on the one hand side and CCID USB protocol on the other hand side.</p>
<p>Tests should ideally not just test interop with one specific CCID reader model but with a larger number of different readers to cover reader-specific issues (I'm seeing different issues with different readers in manual testing).</p>
<p>The tests can then be executed with the latest cardem firmware of the day, on different IUT hardware (simtrace2, qmod) against different readers.</p>
For QMOD testing we would have to either
<ul>
<li>insert a modem with CCID capability (they do exist)</li>
<li>use a custom PCB adapter or some solder wire to hook up the SIM traces of the mCPIE sockets with some external reader</li>
</ul>
<p>But let's focus on simtrace2 for the initial setup, and then expand from there.</p> SIMtrace 2 - Bug #5419 (Stalled): cardem errors with higher baud ratehttps://osmocom.org/issues/54192022-01-25T18:27:00Zlaforge
Setup is as follows:
<ul>
<li>sysmoISIM-SJA2 in built-in CCID reader of my Thinkpad x260</li>
<li>SIMtrace2 with cardem firmware 'master' (0.8.1.7-ea9a) hooked up via FPC to</li>
<li>CCID reader "Identive CLOUD 2700 F" </li>
<li><code>simtrace2-cardem-pcsc</code> to forward request from IdentiveCCID -> SIMtrace -> st2-cardem-pcsc -> builtin-CCID</li>
</ul>
<p>This works fine with F/D ratio 372, and also works fine in most cases with F/D ratio 16.</p>
<p>However, sometimes with ratio 16, things break down at some point.</p>
<a name="log-output-of-cardem-firmware"></a>
<h2 >log output of cardem firmware<a href="#log-output-of-cardem-firmware" class="wiki-anchor">¶</a></h2>
<pre>
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9d 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9e 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9f 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 a0 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
N-I- 0: send_tpdu_header: 00 b2 a1 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
N-I- 0: send_tpdu_header: 00 c0 00 00 60
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 02 00 a4 00 04
-I- 0: flush_rx_buffer (5)
</pre>
two things noticable:
<ul>
<li>the 'N' being printed by card_emu as waiting time extension</li>
<li>the last TPDU header <code>02 00 a4 00 04</code> doesn't look like a TPDU header: The 02 seems wrong, the TPDU likely starts with <code>00 a4</code>.</li>
</ul>
<a name="situation-on-Identive-CCID-reader-side"></a>
<h2 >situation on "Identive CCID reader" side<a href="#situation-on-Identive-CCID-reader-side" class="wiki-anchor">¶</a></h2>
<p>pySim-shell "export" shows:<br /><pre>
update_record 159 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 161 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
# bad file: MF/DF.TELECOM/EF.ADN, Failed to transmit with protocol T0. Transaction failed.
EXCEPTION of type 'RuntimeError' occurred with message: '6881: Functions in CLA not supported - Logical channel not supported'
To enable full traceback, run the following command: 'set debug true'
</pre></p>
<a name="simtrace2-cardem-pcsc"></a>
<h2 >simtrace2-cardem-pcsc<a href="#simtrace2-cardem-pcsc" class="wiki-anchor">¶</a></h2>
<pre>
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9d 04 22
=> DATA: flags=1, 00 b2 9d 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9e 04 22
=> DATA: flags=1, 00 b2 9e 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9f 04 22
=> DATA: flags=1, 00 b2 9f 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a0 04 22
=> DATA: flags=1, 00 b2 a0 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a1 04 22
=> DATA: flags=1, 00 b2 a1 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 60
=> DATA: flags=1, 00 c0 00 00 60 : SW=0x6c23, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 02 00 a4 00 04
<0000> apdu_dispatch.c:112 Unknown APDU case 0
=> DATA: flags=1, 02 00 a4 00 04 : SW=0x6881, len_rx=0
</pre>
<p>it also agrees that this last APDU is somehow wrong and cannot determine the APDU case.</p>
<a name="USB-communication"></a>
<h2 >USB communication<a href="#USB-communication" class="wiki-anchor">¶</a></h2>
<p>last message from SIMtrace to host is "RX DATA" with header flag set and 0200a40004. The card still responds with SW 6881 to that, as obviously the APDU header is invalid.</p>
<p><img src="https://osmocom.org/attachments/download/4852/wireshark.png" alt="" /></p> SIMtrace 2 - Bug #3815 (New): simtrace2 fails USB-IF CH9 testhttps://osmocom.org/issues/38152019-02-23T15:10:02Zlaforge
<p>When running the Chapter9 tests of the USB IF against a simtrace2 device, they fail. The test claims SET_CONFIGURATION is failing, which is quite odd.</p> UmTRX - Feature #3747 (New): LMS6002D RX Gain Controlhttps://osmocom.org/issues/37472019-01-08T02:53:19Zjahredibanez
<p>Hi, with OSMO Rx-Gain Setting for UmTRX</p>
<p>osmotrx rx-gain <0-50><br />Set the receiver gain (configured in the hardware) in dB</p>
<p>LMS6002D Transceiver has gain blocks for RXLNA, RXVGA1, RXLPF, and RXVGA2.</p>
<p>which block does this setting change? and how does it change these values?</p> SIMtrace 2 - Feature #3501 (New): Multi-sim addon board ideahttps://osmocom.org/issues/35012018-08-26T18:12:10Zdemodulate
<p>If the SIMTrace2 board is redone, I would like to propose that the bottom of the board, or free space on the board, is used to hold additional SIM slots with the understanding that only one slot would be used at any given point in time. A single LED could indicate which SIM is in use, if the SIM selection used a software controlled switch. Alternatively, a second board could be created as an add on to hold any number of SIMs based on the area of the board. A physical slider switch for selecting the electrical path would be suitable in either case.</p>
<p>Would this be useful for anyone using the SIMTrace2?</p> Z-Netz - Feature #2814 (New): Create + Document classic CrossPoint setup on DOS (dosemu)https://osmocom.org/issues/28142018-01-01T13:41:48ZlaforgeZ-Netz - Feature #2813 (New): Create + Document OpenXP setup on Linuxhttps://osmocom.org/issues/28132018-01-01T13:41:26ZlaforgeZ-Netz - Bug #2809 (New): Build ZConnect <-> UseNet gatewayhttps://osmocom.org/issues/28092018-01-01T13:09:32Zlaforge
<p>possibly looking at <a class="external" href="https://www.daneben.de/odoconnect.html">https://www.daneben.de/odoconnect.html</a> as a tool</p> Z-Netz - Bug #2808 (New): Create + Document VM/emulation setup for running ZERBERUShttps://osmocom.org/issues/28082018-01-01T13:09:06ZlaforgeZ-Netz - Bug #2807 (Stalled): Obtain ZERBERUS software build[s] and manual[s]https://osmocom.org/issues/28072018-01-01T13:08:48Zlaforge
<p>I've sent mail to padeluun + rena about this.</p> UUCP and UseNet - Feature #2806 (New): Create Dockerfile and/or ansible playbook for UseNet nodehttps://osmocom.org/issues/28062018-01-01T13:04:27Zlaforge
<p>Should be possible using stock debian packages for taylor UUCP, inn2, exim, ...</p> UmTRX - Feature #1515 (New): Heat dissipation and mounting issuehttps://osmocom.org/issues/15152016-02-19T22:52:49Z
<p>Heat dissipation and mounting issue.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1516 (New): There are no port to control external equipment like PAhttps://osmocom.org/issues/15162016-02-19T22:52:49Z
<p>There is no port to control external equipment such as a PA.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1517 (New): U_FL (UMC) connectors are not reliable after few connectionshttps://osmocom.org/issues/15172016-02-19T22:52:49Z
<p>U_FL (UMC) connectors are not reliable after few connections.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1518 (New): Upper limit of the clock is too lowhttps://osmocom.org/issues/15182016-02-19T22:52:49Z
<p>Upper limit of the clock is too low.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Bug #1505 (New): OHM4 footprint incorrecthttps://osmocom.org/issues/15052016-02-19T22:52:48Z
<p>OHM4 footprint incorrect.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1511 (New): Solve Tx and Rx I/Q imbalance for wideband signalshttps://osmocom.org/issues/15112016-02-19T22:52:48Z
<p>Solve Tx and Rx I/Q imbalance for wideband signals.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1510 (New): Complete UHD integrationhttps://osmocom.org/issues/15102016-02-19T22:52:48Z
<p>Complete UHD integration.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1508 (New): Implement UmSEL diversity switch controlhttps://osmocom.org/issues/15082016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> diversity switch control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1507 (New): Implement UmSEL tuner controlhttps://osmocom.org/issues/15072016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> tuner control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1506 (New): Move to the latest stable UHDhttps://osmocom.org/issues/15062016-02-19T22:52:48Z
<p>Move to the latest stable UHD.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1509 (New): Store calibration values in EEPROMhttps://osmocom.org/issues/15092016-02-19T22:52:48Z
<p>Store calibration values in EEPROM.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1504 (New): LMS6002 phase error increases when Rx is enabled and varies with tem...https://osmocom.org/issues/15042016-02-19T22:52:47Z
<p>LMS6002 phase error increases when Rx is enabled and varies with temperature.</p>
<p>[Migrated from old Google Code tracker]</p> SIMtrace 2 - Feature #1463 (New): Add VCC current sensing circuit for SPA & DPA attackshttps://osmocom.org/issues/14632016-02-19T22:48:42Z
<p>It would be pretty good to be able to sense current going to the SIM.</p>
<p>The simple idea is to measure current like this :</p>
<pre>
A B
o o
| |
pwr >----/\/\/\----> to SIM
|
=
|
#
</pre>
<ul>
<li>Ideally use a '4 wire' resistor to make sure you have precision measurement.</li>
<li>Choose value appropriately depending on a typical smart card power consumption.</li>
</ul>
<p>Now, I would include added circuitery to make measurements easier.<br />Because in the simple form there are a couple of issue:</p>
<p>First the signal is gonna be pretty small.<br />Second is that to measure the current across the resistor you can't just put the gnd of your probe on A and the tip on B. That's because the GND of the scope is connected to earth of the mains supply, which in turn is connected to the GND on the PC and so the GND of the simtrace ...</p>
<p>You can either:<br /> - Use two scope probe and use A - B function but this has often less functions that a single probe channel. Also if you only have a 2 channel scope you can't monitor anything else (like the clk line or something).<br /> - Simply probe one point: But then you have the supply noise added to your measurement noise and you don't have absolute values.<br /> - Use a differential probe: Great option ... if you have a couple more k$ to buy one.</p>
<p>So ... all of these suck.</p>
<p>We could have an difference amplifier onboard, however, finding one with multi-MHz bandwidth isn't trivial and they all need dual power rails.</p>
<p>(sorry for the rambling, I'm thinking while writing the ticket ...)</p>
<p>Note that since this feature in its more advanced form may involve expensive / complex components and only be used by very few people. so it could be mounted as a simple 0R with other pad left to be mounted manually by the interested parties.</p>