I had to delete the very first line (Version 4.1) in the *.asc file for it to be imported.
And it looks weird:
Here is the *.asc file’s contents:
Version 4.1
SHEET 1 880 680
WIRE 80 48 80 32
WIRE 80 144 80 128
WIRE 192 144 80 144
WIRE 80 160 80 144
WIRE 192 160 192 144
WIRE 80 256 80 240
WIRE 192 256 192 240
FLAG 80 32 0
FLAG 80 256 0
FLAG 192 256 0
SYMBOL res 64 32 R0
SYMATTR InstName R1
SYMATTR Value 1
SYMBOL res 64 144 R0
SYMATTR InstName R2
SYMATTR Value 1
SYMBOL res 176 144 R0
SYMATTR InstName R3
SYMATTR Value 1
As above, please create an issue on Gitlab and upload any relevant files to it. You can find a handy button to do this in the kicad preferences dialog.
You can now.
padding to 20 chars… sigh…
That does look odd, but it seems to produce the correct netlist for ngspice. See, that all three resistors connect to node Net-_R1-Pad2_
.title KiCad schematic
.save all
.probe alli
.probe p(R1)
.probe p(R2)
.probe p(R3)
R1 0 Net-_R1-Pad2_ 1
R2 Net-_R1-Pad2_ 0 1
R3 Net-_R1-Pad2_ 0 1
.end
On @JeffYoung 's announcement post the dots are also missing. Not sure why.
I submitted a merge request that fixes the version number problem: Schematic: Fix Ltspice import with minor version number (!2218) · Merge requests · KiCad / KiCad Source Code / kicad · GitLab
1 Like
Hello!
Could you please try this one:
The *.asc as the text:
Version 4.1
SHEET 1 880 680
WIRE 96 48 96 32
WIRE 192 48 192 32
WIRE 96 144 96 128
WIRE 288 144 96 144
WIRE 96 176 96 144
WIRE 192 176 192 112
WIRE 288 176 288 144
WIRE 96 272 96 256
WIRE 192 272 192 256
WIRE 288 272 288 256
FLAG 288 272 0
FLAG 192 272 0
FLAG 96 272 0
FLAG 96 32 0
FLAG 192 32 0
SYMBOL res 80 32 R0
SYMATTR InstName R1
SYMATTR Value 1
SYMBOL cap 176 48 R0
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL res 80 160 R0
SYMATTR InstName R2
SYMATTR Value 1
SYMBOL res 176 160 R0
SYMATTR InstName R3
SYMATTR Value 1
SYMBOL res 272 160 R0
SYMATTR InstName R4
SYMATTR Value 1
I submitted another merge request that fixes the junction issue: Schematic: LTSpice importer add junctions (!2219) · Merge requests · KiCad / KiCad Source Code / kicad · GitLab
For now you can use the following workarounds:
- Select all (ctrl+a) and then move everything a bit. This will recalculate the junctions and they then appear.
- A work around for the previous error is - as you already discovered - to remove the line with the version or remove the minor version number i.e.
Version 4instead ofVersion 4.1.
1 Like
Thank you. I hope it will be implemented well before KiCAD drops win10 support.
Using these workarounds it is possible to import some LTspice schematics but not others.
Here is an archive to test.
The import fails silently - neither error messages nor warnings, just a blank sheet.
LTspice_import_test.zip (8.4 KB)
It depends if one of the lead developers has time to review the merge requests. The first one was already merged into the master branch yesterday. So, that one should be in the nightly builds, but it’s most likely too late for 9.0.2.
I looked at the file and I am a little bit suspicious of the encoding. There are lots of special characters. That might be something KiCad chokes on. But that is really just a guess.
078-RIAA_MM-MI_75usLR.asc is in “UTF-16 LE” encoding instead of the expected UTF-8. How did you create this file?
Акулиничев_1989-10-56~58_tweaked.asc import works:
1 Like
Some fixes were added to 9.0 testing builds and master.
1 Like
I see several commits in Testing, so please test urgently. The freeze for 9.0.2 cannot be far away.
1 Like
The 9.0.2-rc1 is probably going to be tagged on 23rd.
4 Likes
LTspice uses UTF-16 LE format (without a byte order mark) for what it calls Unicode support, for any file that contains a character that cannot be represented by the system’s 8-bit extended ASCII code page.
This file contains some Cyrillic characters (see line 619 and 6120) so it is saved as UTF-16 LE.
If all characters can be saved using the extended ASCII encoding then that 8-bit UTF-8 compatible format is used instead. LTspice does not use UTF-8 encoding.
1 Like
There’s example files with µ symbols where the encoding appears to be CP-1252, and when trying to decode them in UTF-8, these symbols appear as �
Some threads suggest they were planning to switch to UTF-8 (https://ez.analog.com/design-tools-and-calculators/ltspice/f/q-a/570800/issues-with-file-encoding-on-macos---workaround-bug-fix-feature-request)
1 Like
One of the developers said “Soon, in one of the next releases, the simulator core will switch to UTF-8 encoding”
I think the key word here is “were”. That message was posted in 2023-06 and there have been many updates to LTspice 24 since then. It’s now 2025-04 and the current version, 24.1.6, still uses UTF-16 LE.
I suspect they are concerned about backwards compatibility with prior versions of LTspice and are reluctant to make such a change.
I believe the mu or micro symbol is available in the extended ASCII code page that LTspice uses for 8-bit non-unicode files. It is commonly used for the 0.000001 scale multiplier for values. The user can enter the ASCII letter “u” and LTspice will convert it to a mu or micro (I’m not sure which character is included in the extended ASCII code page) for display and when saved to a file.
1 Like
The Windows CP-1252 code page encodes a micro symbol as 0xB5. This is compatible with the Unicode micro symbol U+00B5.
The Unicode encoding for the Greek small letter mu is U+03BC. I’m not sure if LTspice accepts both characters as alternate codes for the 0.000001 multiplier.
In UTF-8, U+00B5 is encoded as C2 B5. just B5 appears as �