Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-08-23T10:25:05ZOpen Source Mobile Communications
Redmine SIMtrace 2 - Bug #6140 (Resolved): ngff_cardem: vid and pid example inconsistencies in manual https://osmocom.org/issues/61402023-08-23T10:25:05Zmschramm
<p>In the ngff_cardem manual, there are some inconsistencies for pid:vid examples.</p> OpenVizsla USB tracer/analyzer - Bug #5109 (Resolved): reduce solder stop opening sizes for pads ...https://osmocom.org/issues/51092021-04-09T14:01:41Zmschramm
<p>The solderstop openings overlap for the RAM IC, so there are no ligament between - I'm fine with that for a 0,8mm pitch IC.</p>
<p>But let's reintroduce something that has been better in the former design than now: for QFP packages, please reduce the size of the pads' solder mask openings for U2, U4 and U7.</p>
<p>Their pads are (here: FPGA) 0,3, and gap 0,2mm. PCB house would always remove solder stop overlaps on solder pads anyways, so you can use the minimum distance pad copper-solder stop of 0,03mm. If you use this, the remaining segment would be 0,14mm which is about twice the allowed minimum of 0,075mm.</p> OpenVizsla USB tracer/analyzer - Bug #5108 (Resolved): adapt differential traces' properties to i...https://osmocom.org/issues/51082021-04-09T13:27:03Zmschramm
<p>The layer stack-up of the orginal PCBAs differs to what we are going to produce. Changing the materials for the layer stack means no pooling option, so let's change the three differential pairs to the following values:</p>
<ul>
<li>wire track width: 0,184 mm</li>
<li>wire track spacing 0,194 mm</li>
</ul>
<p>These values here result in characteristic impedance of 50 Ohms and a minimum differential impedance of 90 Ohms. Affected are the pairs</p>
<ul>
<li>TARGETDTAP_N / ~_P</li>
<li>USB_N / ~_P</li>
<li>TARGETD_N / ~_P</li>
</ul>
<p>As discussed, please also make them a 'differential pair class'. We don't insist in sharp 45° angles, you might better want to go with bent traces.</p>
<blockquote>
<p>The good news is that if the current design works with somewhat unmatched trace lengths and a nice T intersection, it should mean this is less critical than I might have imagined.</p>
</blockquote>
<p>OK, but now we (you) can make it better! ;) Maintain a maximum pair lenght difference of less than 3,81mm (150mil), do a meander where the parallels are disturbed anyway, and not at a sane end. This might only be needed for TARGETDTAP_*, which unfortunately crosses a THT header. Don't introduce more vias on those traces.</p>
<p>If you want to 'play' with the inbuilt diff pair helper tool (or another tool of your choice): at 500 MHz, the material has an Er= 4,21. Layer distance (height of dielectricum) is 0,119mm, end copper is 35µm. And let me hear your results, if the Altium helper tool is far off the mentioned values.</p> OpenVizsla USB tracer/analyzer - Bug #5098 (Resolved): exported 'ov_ftdi.DWG' appears to be a DXF...https://osmocom.org/issues/50982021-03-28T16:47:25Zmschramm
<p>The exported PCB as 'ov_ftdi.DWG' actually appears to be a DXF file - which is even better than DWG! ;)</p>
<p>Let's please stay with DXF and simply do a <pre>git mv ov_ftdi.DWG ov_ftdi.DXF</pre>.</p> OpenVizsla USB tracer/analyzer - Feature #5095 (Resolved): export project in ASCII interchange fo...https://osmocom.org/issues/50952021-03-26T13:11:02Zmschramm
<p>As this round of design improvements comes closer to its end, it would be nice to have the major design files also saved in another interchange format to gain access with other eCAD software for wider spread.</p>
<p>A way would be exporting from Altium into Specctra/P-CAD ASCII format, but it looks like as if comtemporary Altium is no longer able to export schematic editor files to PCAD ASCII but only PCB editor's content (which IIRC was different some years ago)? If so, then only a *.pcb file would come out. An ASCII netlist could help additonally. Library elements could be rebuilt and are not a major concern.</p>
<p>(The eagle import for PCAD/Protel/Accel ASCII is far from perfect (see <a class="external" href="https://theanythingapprentice.wordpress.com/2017/06/28/altium-files-in-eagle-incompatibility-issues/">https://theanythingapprentice.wordpress.com/2017/06/28/altium-files-in-eagle-incompatibility-issues/</a>), but basically works with an additional amount of manual extra work. - KiCAD got an native Altium import a year ago. - Freerouting can interface via a Specctra .dsn file from both KiCAD or Eagle).</p>
<p>What do you think <a class="user active" href="https://osmocom.org/users/733705">cibomahto</a> ? Also, is there still the possibility to export an Altium schema to PCAD-ASCII?</p> OpenVizsla USB tracer/analyzer - Feature #5086 (Resolved): place 3 fiducials https://osmocom.org/issues/50862021-03-22T19:37:30Zmschramm
<p>The PCB lacks fiducials. Please add three of simple round-shaped ones of 1 or 1,5mm, free of solder stop and surrounded by a gap w/o copper nor solder stop. Place them in an orthogonal arrangement, close to the mounting holes. Their position shall be reflected in the p'n'p data as well.</p>
<p><img src="https://osmocom.org/attachments/download/4580/fudcial_15.jpg" alt="" /></p> OpenVizsla USB tracer/analyzer - Feature #5078 (Resolved): round all SMD pads https://osmocom.org/issues/50782021-03-17T13:07:36Zmschramm
<p>On the current design, all bigger ICs have rounded pads, but none of the smaller ones and also none of the passive parts have.</p>
<p>We prefer rounded pads (and rounded shapes of the respective openings in the solder cream stencil) as they both reduce the probability for solder beads and also reduce the number of stencil cleaning cycles during a production run (amongst other advantages). Of course the solder stop openings shall then adapt to the changed shapes.</p>
<p>Please slightly round all SMD pads which do not have a similar shape already. - While the IPC-7351B recommandation is a full radius pad (adapts to more different solder paste grain sizes, and preferred for tall and long pads like for the huge TQFP), for the simpler parts we prefer a rounded rechtangle over an oblong (see image; anim gif).</p>
<p>For Eagle, I usually start with these setting as a minimum (see 2nd image); maybe you also can automagically adapt it percentaged to the pad's size.</p>
<p><img src="https://osmocom.org/attachments/download/4566/round-shaped.gif" alt="" /></p>
<p><img src="https://osmocom.org/attachments/download/4567/shapes-global.jpg" alt="" /></p> OpenVizsla USB tracer/analyzer - Bug #5073 (Resolved): repair single via restring rule violationhttps://osmocom.org/issues/50732021-03-12T11:34:58Zmschramm
<p>For the technology class we want to use for the upcoming production run, an inner and outer restring (annular ring) of at least 0,125mm is needed for the defined finished hole size for vias of 0,25mm. This is maintained all over the PCB - except in one spot (see image (animated gif)), on that spot the restring would only be 0,079 mm, and hence the pre-flight shows an error.</p>
<p>This could have been caused by different settings for e.g. min. distance of copper layers to PCB outline in your defaults over the ones in project. Likely the easiest way to repair this is to move that single via slightly more inwards - better than touching the design rules, but you decide.</p>
<p>(I'm going to report this in github too, it's just to keep track this issue also here.)</p>
<p><img src="https://osmocom.org/attachments/download/4522/restring-violation.gif" alt="" /></p> osmo-clock-gen - Bug #4387 (Resolved): wrong BOM attributes for ATSAMD21 https://osmocom.org/issues/43872020-01-31T16:52:14Zmschramm
<p>wrong BOM attributes for ATSAMD21 - they contain the attribs for an LDO...</p> osmo-clock-gen - Bug #4386 (Resolved): Mini-USB footprint needs to have positioning drills for se...https://osmocom.org/issues/43862020-01-30T16:49:28Zmschramm
<p>preferred Hirose type UX60-MB-5ST is a part w/ two drills, whereas UX60A-MB-5ST has no drills, as used in the design... Let's use the type with positioning drills in the design.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4241 (Resolved): measure insertion loss for two a...https://osmocom.org/issues/42412019-10-22T09:42:20Zmschramm
<p>We want to know insertion loss for both alternatives we are thinking of for placing them on the NGFF breakout PCBA:</p>
<ul>
<li>the custom RF cable assembly w/ THT SMA jack (right angle,; don't solder this one, it can be tested self-supporting) and attached pigtail cable, and</li>
<li>a similar combination w/ a short uFL<->MHF4 cable + THT SMA soldered (on the spare PCB where you already placed the MHF4 on).</li>
</ul>
<p>For the first part, we don't yet have the MHF4 version but a uFL variant; so additional adapters are needed.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4231 (Resolved): connect /PERST line @NGFF to POW...https://osmocom.org/issues/42312019-10-17T17:12:51Zmschramm
<p>Let's accept that there are some people who use POWERGOOD signal as a synonym for /PERST... This change finally made the breakout board succesfully enumerated to a PCIe host when a PCIe-enabled WWAN card is loaded (tested with EM7565), so connect them.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4230 (Resolved): cross Rx/Tx on breakout boardhttps://osmocom.org/issues/42302019-10-17T16:40:34Zmschramm
<p>As <a class="user active" href="https://osmocom.org/users/72">roh</a> found out during evaluation, the Rx and Tx pairs have to change their places if we want to go on with the selected PCIe breakout set.</p>
<p>Let's do so.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4216 (Resolved): connect PCIe conn pin 7 on NGFF ...https://osmocom.org/issues/42162019-09-28T00:10:59Zmschramm
<p>NGFF/M.2 breakout v1 lacks a proper GND connection towards PCIe apart from shield. <a class="user active" href="https://osmocom.org/users/72">roh</a> today identified pin 7 for the PCIe interconnect set as plain GND.</p>
<p>Let's connect PCIe conn pin 7 PCIe interconnect (USB3-A socket) to local GND.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4211 (Resolved): find solution for inverted polar...https://osmocom.org/issues/42112019-09-17T17:10:17Zmschramm
<p>This ticket is about a needed polarity inversion of the SIM detect switches and a partly re-designation of the respective pins.</p>
<ul>
<li>The modems tested here with the M.2/NGFF prototype (ME936, EM7565) both make use of pin 40 and pin 66 (SIM_DETECT_1) of the M.2 connector, but only the EM7565 is capable of running a 2nd SIM card. This results in a different usage for pin 40: on EM7565 it is <strong>SIM_DETECT_2</strong>, but on ME936 it is <strong>I2C_SCL</strong>! This also means a change in pin type (input vs. output).</li>
</ul>
<ul>
<li>The selected SIM card holder uses N.O. contacts to detect SIM presence; they now connect to GND when SIM is inserted. For the modems tested, this means inverted polarity: both recognize low as 'not present'. For the respective primary (or only) SIM they mention an internal pull-up, so Sierra recognizes even a floating SIM_DETECT input as "SIM present". Huawei claims to detect edges, not levels on that input (for 'hot swapping')...</li>
</ul>
<p>As <a class="user active" href="https://osmocom.org/users/7">laforge</a> mentioned, the SIM_DETECT signal can be considered a rather 'esoteric' signal as the SIM can be polled anyway, we might drop the SIM_PRESENT logic completely. However, Sierra claims their primary SIM_DETECT (pin 66) a "required signal"... During testing the prototype, contact legs were isolated from each other to simulate constant SIM presence.</p>
<p>What do you think on how to solve these two contraints together? More jumper to be more flexible? Drop the SIM_DETECT contacts' connections at all?</p> M.2 (NGFF) WWAN modem USB breakout board - Feature #4210 (Resolved): PCIe conn could be moved inw...https://osmocom.org/issues/42102019-09-17T15:27:22Zmschramm
<p>The PCIe x1 connector could get moved inwards by about 3mm. However, it sits tightly, so this change is optional.</p> M.2 (NGFF) WWAN modem USB breakout board - Bug #4209 (Resolved): PWR_ON pull-down too strong (R9 ...https://osmocom.org/issues/42092019-09-17T13:27:49Zmschramm
<p>On the prototype, the PWR_ON signal has a PD and PU of each 10k; PU goes to 1V8. For switching on, the resulting 0,9V are not enough to power up the modem. By replacing the PD (10k) to 100k, the modem went on as expected.</p>
<p>Let's replace this 10k R with a weak PD.</p> SIMtrace 2 - Feature #4087 (Resolved): remove bogus targets from build process and ftp dirhttps://osmocom.org/issues/40872019-07-04T08:56:15Zmschramm
<p>In ftp.osmocom.org/binaries/simtrace2/firmware/ three bogus files are made by the build process (same is true for a local build). They are rather useless and lead to ambiguity.</p>
<p>files with twice the string "dfu": {owhw,qmod,simtrace}-dfu-{$version}-dfu.bin</p>
<p>Let's have the Makefile avoid this (and also not upload it to that ftp dir if it is a seperate process).</p>