FNIRSI-1013D "100MHz" tablet oscilloscope

[dfw_ee]

Does TP work properly?

Yes, I've had it working properly for several days now since I hex edited the original TP1 program. But now I have built your code with the table modifications needed that match the "hacked" version that also works. Thanks, again!

[tokar]

Tokar: does that mean it's good?
...

This is better than all previous compilations. There are no very long freezes when performing autoset. The longest is 8 seconds when moving from 0.5V to 1V

[Atlan]

The flood started at a sensitivity of 100mV.  The original firmware starts at the highest range, even 24c.  Hopefully today I will be able to recalculate the coefficient so that the signal shift corresponds to the displayed value.

[Atlan]

firmware v0.024d
If the DC offset. Added recalculation coefficient for correct calculation of measured values, recalculation coefficient for axis placement, recalculation coefficient for waveform placement, recalculation coefficient for trigger level.

[Atlan]

I have to start a small project with ch32v003 as a replacement for ZK SMC01.  It will take some time until I study it and come to uP.  The firmware of the oscilloscope should be quite usable.  If you come across a mistake, I'll look into it again.

[pcprogrammer]

The flood started at a sensitivity of 100mV.

I have to ask what you intended to say here. I have seen you use "the flood" on many occasions and I can't see the meaning of it in the context of the scope, so my guess is you are using a translator to make up your posts and it results in this. 

[Atlan]

I don't use diacritics, so that can also be a problem when translating I usually at least take a quick look at what the translator produces.  Flood was meant as your firmware.  The translator allows the word to be translated as "original".  Which confuses me, because it can mean firmware fnirsi.  (I didn't want to think about it) so I left the flood version of the translation flood even though it's stupid.

[Atlan]

0.024d is not perfect, because it uses a constant to shift the signal, by which it multiplies the value of the centers, obtained by the multiplied number.  Then it does not apply to individual ranges because they have their own calibration constants.  It will be necessary to think about it.  But basically it works.  Just the code is currently full of parts // and also located in files test.C test.H

[polyman]

Atlan:

is the 0.024 version supposed to be fully functional firmware or only meant to test particular features
you are working on? I am asking because I tried flashing 0.024d on my device and I get a flatline on
both channels. I tried baseline calibration but it did not make any difference.

A quick check shows that 0.022g displays the 1KHz calibration signal correctly on both channels, so
I am reasonably confident that the scope is functional.

Polyman

[dfw_ee]

Does TP work properly?

I finally figured out why TP1 had an axis reversed and using TP3 didn't change it. It is because the last byte of the array was 0x00 in tp_config_data3[]. It has to be an 0x01 to signal that there is fresh data otherwise the controller deems it as invalid data and does not store it. So TP3 was making no change. I made this slight modification and the original data now works perfectly. Also have done another backup and compared the 2 tp_config files and they exactly match.

I already had it working as I mentioned before but wanted to get to the bottom of it all since it made no sense that the reversed x values were not making any difference.

Thanks again!

[Atlan]

POlyman Always give images from the oscilloscope.  Screen shot with progress and visible settings.  And in this case, mainly a picture with calibration data.  I assume that they will be 0 in the calibration.

Call up the calibration of the input dividers via the menu of calibration values. You have 0 there. there should be calibration values 35xxxx or basically something like 36000, 38000 40000

[dfw_ee]

Atlan:

is the 0.024 version supposed to be fully functional firmware or only meant to test particular features
you are working on? I am asking because I tried flashing 0.024d on my device and I get a flatline on
both channels. I tried baseline calibration but it did not make any difference.

A quick check shows that 0.022g displays the 1KHz calibration signal correctly on both channels, so
I am reasonably confident that the scope is functional.

Polyman

I saw this initially with v0.023x. I put in v0.023p which worked and then put v0.023x back in and it then worked. Subsequently v0.024 and v0.024d have worked correctly as well.

[dfw_ee]

Here are 2 utilities derived from the Atlan TPx code that will write a FNIRSI_1013D_tp_config.bin file to the scope. This makes it easy to restore a tp_config file back to the scope. There are no changes needed to the FNIRSI_1013D_tp_config.bin file written by the fnirsi_1013d_fwb.bin program and the name has to remain to be found correctly. This utility will write an 0x01 in the last byte to signal that fresh data is coming so this does not have to be done to the saved back up file. The only byte that might have to be changed is the very first byte in the backup file if a number higher than what is in this file has been written to the scope subsequent to the backup.  If the backup file starts with 0xFF there won't be a problem. The FNIRSI_1013D_tp_config.bin file needs to be in the top level directory of the SD card in the scope. This utility itself is written to the SD card the same as fnirsi_1013d_fwb.bin or any of the other firmware posted here using dd or equivalent.

If there is no FNIRSI_1013D_tp_config.bin file found then the utility will report an error and will not write any data to the scope.

There are 2 versions attached. The first is: write_fnirsi_1013d_tp_config.bin.txt. This works as described above. The second is: write_fnirsi_1013d_tp_config_save.bin.txt which works the same but additionally stores a file named my_tp_config.bin on the SD card which is the same data written to the scope to verify what was written.

These work with my scopes but as always use at your own risk!!

[tokar]

v0024d. DC mode. When manually selecting the measurement limit, the signal range is 8 cells! Those. whole screen! Thanks for the solution.
Among the disadvantages, maybe insignificant:
After calibration, without connected probes, and USB.
1) Two channels are included. When autoset, a limit of 50 mV is selected, and a bias (multiple polarity) is obtained from the “0” indicator to half a cell on both channels.
2) One channel is on, any channel. When autoset, a limit of 50mV is selected, but there is no shift from the “0” pointer.

[Atlan]

fixed 0.024e try.

[engineer.r152]

Great version! But there is still a displacement of the rays relative to zero on a slow scan. I didn't find any more problems.
https://youtube.com/shorts/kM7rwTxG14M?feature=shared

[Atlan]

Try it one more time, but wait until the signal is rendered in the short mode of 200ms, it will take a while.

[engineer.r152]

it doesn't help, the signal will also be shifted

[Atlan]

Do the basic calibration, put the picture with the calibration values ​​here.

Long mode does not use ADC channel difference compensation.  But that shouldn't have a significant effect on the shift.

[engineer.r152]

After the basic calibration

[Atlan]

engineer.r152 try this. it should be fine.

Did you make any adjustments on the oscilloscope?  Those values ​​look scary, as does the signal flow.

I see that it shows the temperature I haven't even had time to test it yet.

[engineer.r152]

Excellent! The problem is solved, the beam is stable at zero value! Thanks! The temperature is displayed, as far as I know, it is issued via I2C from the clock chip. It is displayed correctly!

[bpeletronica]

Hello, I hope everyone is well!

Sorry for any spelling mistakes, I'm using a translator!

Today I ventured to change the 1013D's firmware. I changed the SD card, and imported the firmware through "Loader". All very well. At this moment, I have firmware v0.024f, recently posted.
I was testing other firmware versions, and they all had this ripple, and this small imperfection in the square wave (images attached). I tried to do the calibration in the menu, and nothing changed. The original firmware fixes this.

What could I be doing wrong? Is there any procedure to be done besides updating the firmware? How do I calibrate this?

Thank you all, and congratulations on the project! The new firmwares greatly improve the equipment’s functionality!

[bffargo]

I was testing other firmware versions, and they all had this ripple, and this small imperfection in the square wave (images attached). I tried to do the calibration in the menu, and nothing changed. The original firmware fixes this.

1) It appears you have not done proper voltage calibration. All your defaults are ending in 00000. You must provide a stable voltage in 0V3, 0V6, 1V5, 3V0, 7V5 and 15V0 levels when re-calibrating those levels

Atlan's Calibration post with video example: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5279620/#msg5279620

2) The new firmware shows actual level readings, what you are calling jitter. The original firmware averaged those out giving a fake display that did not represent the actual levels. 

I posted about that way earlier in the thread, here is that post and the response from others regarding that:
My Post: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4573744/#msg4573744
PCProgrammer's Reply: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4574389/#msg4574389

[Magua]

fnirsi_1013d.bin v0.024f.txt   -   CH - 1     CH - 2