Frequently Asked Questions
Win-GUI apps of different Simulyzer types may be installed in parallel on your PC.
But you may only have one version of the same type of Win-GUI app as an official installed version on your PC. But before de-installing an older version (in order to install a newer one), you may create a copy of your C:\Program Files (x86)\SesKion GmbH\*Type*-Simulyzer directory and rename it to for example C:\Program Files (x86)\SesKion GmbH\*Type*-Simulyzer_Vx.y . You need Admin rights to do this!
*Type* may be PSI5, SPI, DSI or SENT
After having the copy directory you may de-install the old version and install a newer version.
To use the old version you may create a link on your desktop to C:\Program Files (x86)\SesKion GmbH\*Type*-Simulyzer_Vx.y\*Type*_SimulyzerGUI.exe .
To get rid of such an older version, just delete the C:\Program Files (x86)\SesKion GmbH\*Type*-Simulyzer_Vx.y directory and remove the desktop link.
existing license
and new license
can be combined into a single file:
The order of the features is of no relevance.
See also: Where to copy seskionLicense.xml license files on your PC
Normally the SesKion standard Win-GUI app needs a license to be operaded together with a Simulyzer USB box.
However if the customer does not yet have a Simulyzer USB box, he still may download and install the app and he may have a look-and feel about the GUI app and the API.
SesKion license files always have a filename of “seskionLicense.xml”. The license file will not be recogized with a different name.
The license file has to be copied to locations on your Windows System-Disks (mostly C:) depending on the type of Simulyzer:
- PSI5-Simulyzer licenses: copy to
C:\ProgramData\SesKion GmbH\PSI5_Simulyzer - SPI-Simulyzer licenses: copy to
C:\ProgramData\SesKion GmbH\SPI_Simulyzer - DSI3-Simulyzer licenses: copy to
C:\ProgramData\SesKion GmbH\DSI_Simulyzer - SENT-Simulyzer licenses: copy to
C:\ProgramData\SesKion GmbH\SENT_Simulyzer - Simulyzer-RT licenses: copy to
C:\ProgramData\SesKion GmbH\Simulyzer-RT
After starting a licensed application, even with not yet having the license, this app will create the directory location.
If you have a license-file with license “features” for different types of Simulyzers, just copy it to all related deirectory locations. The SesKion app just picks the license “features” out of the license-file and ignores the features belonging to different kind of Simulyzers.
See also: “FAQ How about licensing of Simulyzers”
See also: combining and splitting SesKion license-file features
A Break-out ECU is a special case of a standard ECU (for example an Air-bag ECU) to be used in HIL (hardware-In-the-Loop) testing environments. A Break-out ECU does not go to production. The benefit of a “Break-out ECU” is to route SPI signals that normally go to one or several SPI sensor(s) inside the ECU out of the ECU box. For this an extra connector, for example an extra D-Sub connector has to be place at a suitable position of the ECU case and an hardware expert has to make short wire connections from the SPI-sensor chip to the extra connector.
Here is a photo of a “Demo” ECU where SesKion made its own Break-out connector.
The “Demo” ECU has been purchased as evaluation board from freescale company for some 150 Dollar. Its intent has been for users to learn about sensors and about ECUs in Automotive application. 
SesKion de-soldered the SPI-sensor chip in the mid of the board and made some connections to a post connector serving as Break-out connector.
Another strategy may be to leave the SPI sensor in place on the board and only make some cuts of the SO (Slave Out) signal traces to give the sensor simulating device the chance to feed in its simulated SPI responses.
The scheme of the unchanged SPI signals in relation to the SPI-sensors may look like this insde the ECU:
Since the simulating device has to drive its simulated responses to the MISO pin of the µC, the original sensor(s) have to be inhibited to drive the MISO line.
One possibility is, to cut the copper-trace of the SO outputs of the SPI sensor before going to the MISO input of the µC. Instead, the SO lines of the sensors have to be joined to the Break-out connector and go to the SPI-Simulyzer. The Simulyzer has the chance to read the real sensors response and even has the possibility to re-connect the original sensors SO lines to the MISO input of the µC.
Additionally all outputs
- CS* chip-selects
- SCLK SPI clock
- MOSI master out
have to be joined in parallel to the Break-out connector.
Aditionally the supply voltage of one of the SPI-sensor(s) has to be joined to the Break-out connector; this is for the SPI-Simulyzer may sense the availability of power at the sensors. As long as power is not detected, the software sensor-model in the Simulyzer will not react on any SPI master request and will be held in a Reset state.
Last but not least the MISO input of the µC has also to be joined to the Break-out connector:
Connection is straight forward:
Shown are the pin numbers of both
- LVDS-POD, Sub-D-25, in case of a SPI-Simulyzer-LVDS and
- post connector 26, in case of a SPI-Simulyzer-Single-ended
You may also prepare a “Shorting plug” to be placed into the Break-out connector in case of not simulating the sensors. This revokes the separation cut in the MISO line inside the ECU.
.
For best result, use a SUB-D-25 male connector as Break-out connector, use a flat-ribbon cable of length not exceeding 10cm (4 inch) and connect each signal together with its GND as pairs to your copper traces of Break-out ECU (signal to signal, GND to GND nearby):
- The VDD signal is used by the SPI-Simulyzer to detect if sensor-power is present.
- The SCK signal is used by the SPI-Simulyzer as SPI-Clock imput
- The MISO signal is used by the SPI-Simulyzer asa SO output
- The MOSI signal is used by the SPI-Simulyzer as SI input
- The CS0 signal is used by the SPI-Simulyzer as Chip-select-0 input
- The CS1 signal is used by the SPI-Simulyzer as Chip-select-1 input
- The CS2 signal is used by the SPI-Simulyzer as Chip-select-2 input
- The CS3 signal is used by the SPI-Simulyzer as Chip-select-3 input
- The DIO4 signal is used by the SPI-Simulyzer as input of the original sensors SO signal
| Signal Name | Pin Sub-D 25 | Pin post-connector 26 | wire in flat-ribbon cable |
|---|---|---|---|
| GND | 1 | 1 | 1 |
| GND | 2 | 3 | 3 |
| GND | 3 | 5 | 5 |
| GND | 4 | 7 | 6 |
| GND | 5 | 9 | 9 |
| GND | 6 | 11 | 11 |
| GND | 7 | 13 | 13 |
| GND | 8 | 15 | 15 |
| n.c. | 9 | 17 | 17 |
| n.c. | 10 | 19 | 19 |
| n.c. | 11 | 21 | 21 |
| do not use | 12 | 23 | 23 |
| do not use | 13 | 25 | 25 |
| VDDA1 | 14 | 2 | 2 |
| CLK | 15 | 4 | 4 |
| MISO | 16 | 6 | 6 |
| MOSI | 17 | 8 | 8 |
| CS_0 | 18 | 10 | 10 |
| CS_1 | 19 | 12 | 12 |
| CS_2 | 20 | 14 | 14 |
| CS_3 | 21 | 16 | 16 |
| Reset | 22 | 18 | 18 |
| Eclock | 23 | 20 | 20 |
| DIO_3 | 24 | 22 | 22 |
| DIO_4 | 25 | 24 | 24 |
| n.c. | 26 |
A more versatile approach for a Break-out ECU is to cut the SO line of each sensor and to route this SO lines individually to the Break-out connector:
This opens the posibility decide for each sensor if it should be handled by the original chip inside the ECU or by the SPI-Simulyzer.
For this, a Distribution board has to be constructed
- to allow routing of the probably different pin numbers of the Break-out connector and the SPI-Simulyzer and
- to set jumpers of each sensors MISO line for either be simulated or be the real sensor
Here is an even more complex Break-out scheme using 2 SPI interfaces.
On side of the SPI-Simulyzer 2 interfaces (and PODS in case of LVDS) hace to be used,
To ask a bit more precisely:
How large have the file-based ringbuffers of the PSI5-Simulyzer to be configured to hold the data of a given timespan
1. sensordata
Sensordata contain the acquisition of sent and received PSI5-frames / sync pulses
The formula for calculating the size is:
fileSize = (sizeSyncInfo+sizeRespFrame*numberOfSlots)*numberOfInterfaces*numberOfSynperiodsPerSecond*numberOfSecondsToAcquire;
sizeSyncInfo = 6; // Byte
sizeRespFrame = 12; // Byte
numberOfSlots = 4; // lets asume a worst case of 4 timeslots in P10P-500-4H
numberOfInterfaces= 2; // lets asume a worst case of both interfaces
numberOfSynperiodsPerSecond = 2000; // lets asume a typical case of 500µs Syn-periode
When using the values above, the formula reduces to
fileSize = (6 + 12 * 4) * 2 *2000 * numberOfSecondsToAcquire;
fileSize = 216000 * numberOfSecondsToAcquire;
In this worst case scenario, you need a ringbuffer filesize of 216000 Byte for each second to acquire.
Lets say, you want 10 Minutes to acquire:
fileSize = 216000 * 60 * 10; // gives 129600000 Byte (124 MByte)
The standard WIN-GUI app can handle this and even larger file sizes if
- The used filesystem supports this file size
- There is plenty of room on the drive to hold the file
- The file has to be a local file, not a network file!
2. rawdata
Rawdata contain the acquisition of PSI5 voltage and current curves being sampled with 3MSamples/s. Only one of the two interfaces can be sampled at a given acquisition.
The formula for calculating the size is:
fileSize = 12MB * numberOfSecondsToAcquire;
You need a ringbuffer filesize of 12 MByte for each second to acquire.
Lets say, you want 10 Minutes to acquire:
fileSize = 12MB * 60 * 10; // gives 7200 MByte (7.1 GByte)
The standard WIN-GUI app can handle this and even larger file sizes if
- The used filesystem supports this file size (NTFS does support even larger files)
- There is plenty of room on the drive to hold the file
- The file has to be a local file, not a network file!
3. Conclusion
In the examples above, you would have to set this sizes:
But please consider, despite this storage size will be handled properly, it may not be so easy to find special parts inside this acquisition.
Nor may it be practical to handle a csv export of such large files.
To be precise: What supply voltages can be used for power supply settings of DIO-1 card
Our first requirement was to be able to generate output voltages on SUPPL_1 .. SUPPL_4 between 1.5V and 5V. This found his way into first version of the technical data-sheet.
But in practice, we found the voltages can be generated with defined accuracy between 0.5V and 6V.
So our automatic test-procedure checks all DIO-1 cards between 0.5V and 6V and would give error if accuracy is out of limits.
You also have to distinguish between
- Values that can be reasonable set inside the API (range of DAC): 0V .. 6V
- tested and guaranteed voltage range: 0.5V .. 6V
- recommended values of SUPPL_4: 0.5V .. 5.5V
The tightened range of SUPPL_4 can be constituted because this SUPPL_4 also serves to supply our 48 DIO Driver chips inside the DIO-1, and these chips are only specified up to 5.5V.
We will correct this in our technical data-sheet.
The PSI5-Simulyzer recogizes following errors upon receiving a Manchester Frame:
| Error | Error bit | Meaning |
|---|---|---|
| timeslotError | 0x01 | data frame starts before start of timeslot or ends after end of time-slot |
| startBitError | 0x02 | error in requested value ’00b’ of startbits |
| manchesterError | 0x04 | no polarity change in mid of Manchester bit or number of bits different to configured one |
| parityError | 0x08 | error in parity bit or in CRC bits |
| currentError | 0x10 | only detected if ‘CurrentCheckMode’ is enabled; reported if “0”-current is outside 0-upper or 0-lower limit or if “1”-current is outside 1-upper or 1-lower limit |
| noDataError | 0x20 | no data (polarity change) within time-slot |
| bitTimeError | 0x40 | only detected if ‘ExtendedTiming’ is true; the bit-times do not match the default the default tolerance of +5% and -5% |
In sensor simulation there are 3 modes what signal data is used:
- Intern, using an internal cyclic incremental signal (Sawtooth). Warning: The saw-tooth spans the comblete data range of -512 .. +511 (at 10 bit signaldata). This may interfer with init-data being in the area of -512 .. -481 or +481 .. +511. Sow the sawtooth is nice but gives problems if init-data are important!
- Extern Program, using configurable constant data or imported signal sequence
- Extern Analog, using selectable analogue inputs to be the source of signal data.
The selection box for mode can be found in our WIN-GUI app in the “PSI5 Bus Configuration” panel beneath section “Sensor Simulation” 
In this example we will use Extern Program and prepare an excel sheet for import.
Please note, you have to do this independently for each channel (interface) by selecting the appropriate “channel”-tab.
All SesKion Simulyzer boxes like
- PSI5-Simulyzer,
- DSI3-Simulyzer,
- SPI-Simulyzer and
- SENT-Simulyzer
- PSI5-POD
- SQUIB-Box
- Simulyzer-RT
and their software can be licensed in three very different manors.
box stored license-bit
The original kind of licensing (and still the most used one), is by storing license information in the nonvolatile memory of the box. This is normally done in factory at SesKion. It is the case when additional licenses are directly ordered together with the box. Additional licenses can also be ordered later when the box is at customer site. In this case SesKion will send a license key to the customer via e-mail that can easily be programmed to NV memory of the box. This kind of licensing is call “box stored”. If it is a hardware feature, like activation of a second interface, this is the natural kind of licensing. Features, licensed “box stored”, can be used with this box from any PC having installed our WIN-GUI app.
boxSN-bound license-file
If a “boxSN-bound license-file” is used, the license is not in the NV-memory of the box but in a license-file on the PC. The license feature is not bound to this PC but to the SerNo of the box. Features, licensed as “boxSN-bound license-file”, can be used with the box having this SerNo, from any PC having a copy of the license-file.
PC-ID bound license-file
Application as our standard WIN-GUI app can also be licensed “PC-ID bound”. This means, the Simulyzer box does not have the license in its NV memory but the license is in a license-file on the PC. A “PC-ID bound license-file” feature may only be used on this PC The advantage is, it can be usd with any Simulyzer box.
Activation of the license has always to be done by the customer. You have to start one of our WIN apps, no matter if it is still not licensed. Here you have the possibility to send an e-mail to SesKion with your PC’s HostID. Seskion then will create the license, bound to this HostID and send it to the customer where it has to be placed in the file-system of the PC with this HostID.
Overview of licenses:
| Feature / Option | available as box stored license-bit | available as boxSN-bound license-file | available as PC-ID bound license-file | Remarks |
|---|---|---|---|---|
| second interface (channel) for Simulyzer box | yes | yes | yes | “PC-ID bound” maybe not very useful |
| optinal CAN interface (PSI5, SPI) | no | no | no | hardware option |
| optinal CAN interface (PSI5-POD) | yes | yes | yes | |
| standard WIN-GUI app (PSI5, DSI3, SPI, SENT, PSI5-POD) | yes | yes | yes | |
| PSI5-Tester app | no | yes | yes | |
| PSI5 programmer | no | yes | yes | |
| PSI5 EMC-test app | no | yes | yes | |
| SPI sensor model | no | yes | yes | box stored license-bit is planned in future |
| Simulyzer-RT WIN-GUI app (PSI5) | no | no | yes | |
| Simulyzer-RT activation of monitor-mode in API | no | no | yes | |
| Simulyzer-RT endurance app | no | no | yes | |
| Simulyzer-RTconf-tool | no | no | yes |
This is about getting sensor data while your app is running.
There are two situations when you may want to get the data:
- Immediately after starting the data acquisition you want to look at the data while it continuously streams from the box or
- after stopping of the data acquisition you may want to look at the data.
In case 1, you have to to hurry to get the data fast enough to keep up with new arriving data. This may be the preferred method if you have a long acquisition time, even with no predefined end.
In case 2, you have all the time you want to get the data. his may be the preferred method if you have a short acquisition time, lets say some seconds. Then you start acquisition, stop it after some seconds and then look at the data.
You will find examples below your installation directory in C:\Program Files (x86)\SesKion GmbH\PSI5-Simulyzer\API\
You also will find a complete Visual-Studio project PSI5-Simulyzer4AnsiC.vcxproj in C:\Program Files (x86)\SesKion GmbH\PSI5-Simulyzer\API\ANSI-C\PSI5_Simulyzer4AnsiC\PSI5_Simulyzer4AnsiC
At this time, this information can be found in a PDF document:
We may also transfer this information directly to this page in the future.
First of all, the files in the temp-directory are not intended to be processed after terminating the your application. They just are intended as a file-based ring-buffer where received binary data is temporary stored. While you application is still running, there are API calls to get data out of these temporary files (see discussion further down).
If you want your acquired data to be available after terminating the your application, you should call
StoreData(HANDLE hSensor,unsigned char mode,char *rawDataFile, char *sensorDataFile);
if your .ppf project files is named myProject.ppf and is located in /your/Path/to/Config/
you should give following parameters:
StoreData(yourSensorHandle, 3, "/your/Path/to/Config/myProject.rawData", "/your/Path/to/Config/myProject.sensorData");
Of course, you may chose different path, different file-basename and different extension, but doing it this way has the advantage you could use our standard WIN-GUI app to open /your/Path/to/Config/myProject.ppf and the GUI will automatically find and open the myProject.rawData and myProject.sensorData files and also open them for showing them as graphs and tables.