FNIRSI-1013D "100MHz" tablet oscilloscope

[Atlan]

I interrupted the power supply for the main stabilizer 3.3V.  Now the main stabilizer is powered from the lipol converter => 5V, so the pad does not run when the battery is discharged.  The disadvantage is the constant consumption of the inverter of 0.157mA, Pin4 (AL142, FP6291, MT36291) dc converter enables it to be turned off, so it would probably be possible to connect it to pin 1 SPX293XX

Don't pay attention to the wires, they have a different purpose. The intervention in the pcb is minimal.

[Atlan]

I started making some modifications to the code, it's difficult because the code is long and I don't have enough free time.

But I edited the part dealing with calibration, if there is interference at 200MSa/200ns, but that's only on my device.
Automatic confirmation works when calibration is successful, no need to click on the screen.



BIN file is: v1.007

[Atlan]

 Corrected the TRIGGER setting function, it no longer moves when reconfirmed. Changing the color of the TRIGGER cursor, yellow for channel 1 and blue for channel 2.
BIN file 1.008

[Atlan]

A minor error appeared there. As for confirmation, during calibration. The flood was thought to be different. So fixed (I inverted it).

If someone were to ask why it is in version 1.00x, even though some changes were made in the ranges during calibration.

Since no one writes anything, you probably don't use it or it works.

!! I take no responsibility if anything goes wrong !!

bin verzia 1.009

[Atlan]

I still can't solve the problem with the thumbnail. When turning on the oscilloscope and saving an image or waveform. at the set range of 200MSa/s (200ns/div to 5ns/div) the created thumbnail is damaged.

instead of the signal value, the value 0xF5 is inserted there. I don't understand where it is taken there, and why it is not there with other settings.
I am attaching the thumbnail file.
2. wav is not ok, corrupted input hex0x3B 0x3A
17.wav is corrupted by multiple input of F5 instead of the correct value.

subroutine
void scope_thumbnail_set_trace_data(PCHANNELSETTINGS settings, uint8 *buffer) in scope functions

or here
void scope_create_thumbnail(PTHUMBNAILDATA thumbnaildata)

As you can see, the wav files look fine, but the thumbnail doesn't.
I also wondered if the preview is not made from the displayed data, instead of the raw data that contains the wav. It's been a long time, it definitely needs a fresh look.

The image of the problem overview is on page 62 at the very bottom https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/1525/

can someone look at it, thanks

[Atlan]

I fixed the color of channel 2 in the thumbnail. 
v1.010

[Atlan]

Something is wrong there, even on good files there is a recurring 2wav error. has B3 and A3

The problem probably does the subroutine scope_thumbnail_calculate_trace_data. It is not so visible on other ranges. There is inserted 0x3a and 0x3b, but the value there has nothing to do there. I don't know I will fail a subroutine or is somewhere with a memory that it is overlapped and overwriting what it does not.

[Atlan]

Thumbnail problem is FIXED.   (wavefrom 4.wav) although the remaining 15 bytes are random and unwritten, but I don't want to deal with it now. So far, no one has minded. It was very difficult to find the problem, without help.

The color of the TRIGGER cursors has been added to the thumbnail, to determine whether it is a TRIGGER of channel 1 or 2. verzia 1.012

I will try to remove the TRIGER problem.

[Atlan]

IMPORTANT !!!!
the software contains an error when deleting items (images or wavefrom) if you re-select items that are not displayed there (select or select all) and select DELETE, then confirm the deletion. the device will freeze, and only uploading the special file from page 51 will help (fnirsi_1013d_calib_capture.bin)

(who would do such a stupid thing )

After performing the data capture, it is possible to upload the firmware again, the device will work.

(it does not affect the original firmware, it always works)

FIX it!!! it will be updated in the next firmware release

[Atlan]

Modified source files (if anyone wants to improve) and bin files can be found here: https://github.com/Atlan4/Fnirsi1013D

ALWAYS contact me before use. The files are not always up to date. It is possible that I have a newer version on my PC.

[Atlan]

It seems that RMS measurement implemented in the version v0.006 requires some changes for the saved WAVE files. Currently it doesn't show correct value.
Possible solutions could be: save calculated RMS value with the other WAVE file settings or recalculate RMS value from the file samples after loading.

Good day. you can specify the problem more precisely. what it does, how it manifests itself, when and where.

[Atlan]

Fixed the problem with deleting non-existent thumbnails (with total freezing), fixed the graphics of the delete menu, fixed the range of the TRIGGER.

File 1.0.13.bin

[Atlan]

Fine-tuning of TRIGGER values, small correction. Refinement of the position of the course in relation to the horizontal and vertical TRIGGER
file 1.013a

Does anyone know of any bugs?

[Sleo]

Does anyone know of any bugs?

... You can move the wave up or down to see the bottom or top half, but there is a bug in the alternative firmware with displaying vertically shifted waveforms.
Pictures 1 and 2 - alternative firmware v0.006, pictures 3 and 4 - original Fnirsi firmware.

Look at pictures 2 and 4 in https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4768094/#msg4768094 - firmware .005 and .006 cute off top/bottom of wave that is higher half of screen, when center is shifted down/up (original firmware do not).

[pcprogrammer]

That has to do with the way the alternative firmware samples the data. In the original code shifting the display up or down modifies the offset voltage on the ADC, and can show the signal correctly because it then samples the shifted signal, where as the alternative firmware shifts the sampled data on the screen and therefore can't show the top of the signal because it is not there in the sampled data.

The benefit of this setup is that it is possible to move saved wave forms up and down, the down side that it does not work like the original.

[Sleo]

The benefit of this setup is that it is possible to move saved wave forms up and down, the down side that it does not work like the original.

It seems to me that the best way is a combination of two - offset shift when live waveform moved, and screen data shift when saved waveform moved.

[Sleo]

Does anyone know of any bugs?

One more bug (or a feature) is a very slow storage device mounting on Windows (fw .005 to .013 tested, Win10/11). It takes about a minute after pressing "USB Connection". Original firmware mounts in a second.

[Atlan]

Does anyone know of any bugs?

... You can move the wave up or down to see the bottom or top half, but there is a bug in the alternative firmware with displaying vertically shifted waveforms.
Pictures 1 and 2 - alternative firmware v0.006, pictures 3 and 4 - original Fnirsi firmware.

It's not a bug, it's a feature. The original programmer decided to move the signal only in software, the original firmware moves it by changing the voltage level on the AD converter. Otherwise, when you exceed the range of the converter in the alternative software, you will see the upper-limit or the lower-limit line.
This oscilloscope will never be good, so put a resistor in front of the probe and you will be in the AD converter range you will just have to use your head to calculate the voltage.

Look at pictures 2 and 4 in https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4768094/#msg4768094 - firmware .005 and .006 cute off top/bottom of wave that is higher half of screen, when center is shifted down/up (original firmware do not).

[Atlan]

Switch to linux, you will connect in less than 1s And the original soft line freezes when working with usb. To be clear, I will not talk about the periphery. This means no modification of usb, access to sdcart. Even though I'm considering finding out if it would be possible to modify the recording on the card so that data such as time and date can be recorded. However, I am worried about what the IO of the touch panel will say about i2c sharing

P. S. The connection speed problem for windows was fixed in version 0.019b

[pcprogrammer]

The touch panel won't mind since it uses a dedicated address on the I2C bus, which is bit banged by the way.

@Atlan: When you decide to make such a modification for date and time, I would advise to make it behind a system setting to enable or disable it, since it requires a hardware modification to make it work.

[Atlan]

OK, first I have to find where the data about the date and time of the file is hidden in the code....

I was playing a bit, who can guess what changed

[pcprogrammer]

@Atlan:
If you plan on using the date/time stamp on the file you can look into the file system code used in the project. (http://elm-chan.org/fsw/ff/) Not sure if it supports it.

I did make some modification to the code to protect it against NULL pointers.

[Atlan]

Added buttons to the measurement menu. Select All and Clear.

[Atlan]

Correction of measurement menu dimensions, increased select all and clear buttons

[Atlan]

This is just another test program, it takes data from channel 1, calculates the average and displays it on channels 2.

         scopesettings.channel2.tracebuffer = ((scopesettings.channel1.tracebuffer) + (channel1tracebufferAVG))/2;
         channel1tracebufferAVG=scopesettings.channel2.tracebuffer;

Anyone can guess what it will do with a non-repeating signal.

I would be interested in something like that, it can be seen better on the video. It's so stupid, but why not.