FNIRSI-1013D "100MHz" tablet oscilloscope

[frenky]

My data is attached. 

[pcprogrammer]

Hi frenky,

thanks for the upload.

In your scope channel 2 also has a bigger difference then channel 1.

Channel 1 min, max: 0, -2
Channel 2 min, max: -1, -6

Based on the data seen so far it looks like a single compensation value is not good enough. Have to do some more tests with external applied DC voltages, to check if this spread is then also seen. If so full translation tables might be needed. For the 6 input ranges (the 50mV one is software zoom) and 4 ADC's it means 6KB, which is no problem in the DRAM nor the SD card. The problem is that I also noticed that it differs with a change of the sample rate. There are 18 of these, which would make 90KB. Not a problem space wise, but calibration will then take quite a while.

Another experiment showed that with the lower sample rates (for 200ms/div - 20ms/div) it is possible to have the FPGA return 1500 instead of 750 samples per ADC. Capturing a buffer doubles in time, but for me that is ok. Also noticed the command 0x14 returning data that might be usable to have the signal look triggered.

Needs more testing to have the top pointer match the right trigger level pointer. One thing is for sure, I'm getting to know the system better and better

[frenky]

I look forward to seeing any new development.

Can you please tell me something...
Yesterday I have put your .bin file that made calibration data file...
Do I have to flash my scope again with your firmware so that new code that generates calibration file does not run every time I turn on scope?

[pcprogrammer]

Hi frenky,

all you have to do is this

Code: [Select]

//Connect the scope to the computer and enable USB  (MENU -> USB Connection)
//Un-mount the partition. Make sure the scope is connected to /dev/sdc. Can be checked with lsblk command.
sudo umount /dev/sdc1

//Un-load the package
sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=8 count=1

A while back I found the option to load the new firmware from the SD card and leave the FLASH as is. The next test release will store it's settings also on the SD card, making it completely free from the original firmware. Also easy with updates. Just write the new package to the SD card with these commands.

This also applies for loading a previous version of my firmware. Soon I will add version info to the main menu.

Code: [Select]

//Connect the scope to the computer and enable USB (MENU -> USB Connection)
//Un-mount the partition. Make sure the scope is connected to /dev/sdc. Can be checked with lsblk command.
sudo umount /dev/sdc1

//Load the package
sudo dd if=fnirsi_1013d.bin of=/dev/sdc bs=1024 seek=8


And when not happy with the way it works remove it again with the first set of commands.

Edit: I did not read your post correctly. The answer is yes, to get rid of the writing of the calibration file at startup load a version that does not do this.

For now I wish, everybody a good ending of the year and a happy 2022.

Cheers,
Peter

[pcprogrammer]

I made a new version with different calibration.

It is now no longer using the DC offset like the original to move the traces on the screen. The plan is to add a DC offset setting to the channel menu. Setting this will then move the trace on the screen, but not the trace center pointer. This allows for full ADC range to be on the display when wanted.

Also changed the sample rate and time base settings to be able to get bigger buffers and triggering on the 200ms/div - 20ms/div setting. For it to trigger "stable" it seems to need a couple of periods of the signal. Have to do more research on this point. On 200ms/div - 50ms/div it takes a while to refresh.

The settings are read from the SD card, and when not there, it uses a default set. On power off it writes the settings to the SD card.

Still not to happy with the ADC difference compensation, so like to hear feedback from you testers.

[pcprogrammer]

To overcome the multiple firmware versions for the different displays I made a change to the boot loader and the display configuration.

On the SD card sector 710 can hold a display configuration for the different displays. When not there the firmware will use the default setting, but when it is there and valid it will use that setting.

For the people with a shifted display in their scope it is only loading this configuration file to the SD card and every new firmware will make use of it and display at the correct position.

Need to fix a couple of other mistakes before a new release. Noticed that the calibration data is still reset with default test settings.

But that is for another day.

[Alex62]

Hello.
100 Khz synchronization on video.

[pcprogrammer]

Here is a new version.

Fixed the issue Alex62 found. The trigger level in the FPGA is now conform the level on the display. Added something the original lacks. When switching between the two channels in the trigger menu, the trigger level pointer stays where it was, unless the auto 50% trigger is enabled. In my version it moves to the selected channel. Still have to improve here on volt per div selected, to make the trigger level actual volts related.

Also modified the calibration code to do less relay switching. Previous version selected a sample rate setting and went through the 6 sensitivity settings to do the sampling and then do the next sample rate. Swapped these two, to do the different sample rate readings on a sensitivity setting and when both are done select the next sensitivity.

Due to how the hardware works, it is not perfect, and almost impossible to get it to be perfect. It turns out that changing the other channel sensitivity changes the input center level. Might be a power supply issue and related to the changing load when a relay is switched on or off.

Going to leave it at what it is and move onto the next bit of the code. Auto set.

This new package is based on the display mod I posted about earlier. The people with shifted displays need to put the display configuration on the SD card.

Code: [Select]

//Setup the scopes USB connection
//See where the device is connected and use that in the below commands. Mine always pops up at /dev/sdc
//This is needed for dd to work properly
sudo umount /dev/sdc1

//This puts the config data in sector 710
sudo dd if=shifted_display_config_sector.bin of=/dev/sdc bs=1024 seek=355

The configuration data consists of two 32 bit markers, the two 32 bit settings, two 32 bit markers and a simple 32 bit checksum. When changing the settings it is needed to re calculate the checksum, by just adding all the 32 bit values. The data order is LSB first.

[tv84]

The data order is LSB first.

Nitpicking Peter: LSB or little endian?

[pcprogrammer]

The data order is LSB first.

Nitpicking Peter: LSB or little endian?

Least significant byte first, mark the big letter B, is little endian according to wikipedia, so to be specific, yes it is little endian.

[pcprogrammer]

Ran into a bit of a snag.

Coded frequency calculation and it works reasonably well on the simulator, and also on the settings up to 500ns/div on the real hardware, but it goes sour when going up to the 200ns/div - 5ns/div settings. According to the time cursors the frequency is correct when the cursors are positioned on the zero crossings, but the by code determined frequency is to low. And goes down with every next time per div setting.

This means I have to figure out what the hardware does on these time per div settings.

For the auto set function it does not matter, because on the 200MSa/s - 500ns/div setting it is possible to determine frequency from ~70KHz up, so with a single measurement it can do a large part of the ranging.

But it still has to wait until this snag is solved

[m3vuv]

In a not at all bandwidth related exercise I tested the 1013D's battery life.

It ran continuously for 6 h 45 m while monitoring two phases of a 4-phase stepper motor being accelerated and cycled clockwise/anticlockwise over a 270° sweep, pulse frequencies 7 to 44 Hz...

Pretty damned good, first thing I've tested that bettered the claimed spec. It took a 3½ hours to recharge at 1.8 A tapering to 0.3 A over the last ½ hour...

Aligns with what I have found.

Turn it on, forget that it is still running, go back two hours later, still plenty of power.  Would be a good in-the-field device if they could improve the UI and accuracy.  (Still limited by triggering options, capture depth, etc. – so not going to replace a 'real' portable 'scope for some applications.)

Plug it in to a PC or what have you, and it's fully charged very quickly.
Talking of chineese user interfaces,i have a hp 54503A scope,the on off/power switch is at the rear and not on the front panel,total ass to have to reach over the workbench to even turn it on! WTF!

[pcprogrammer]

Managed to resolve the snag with the frequency computation and code an auto setup routine.

It works well in the simulator, but with the changed DC offset setup, it needs to check if there is a DC offset in the signal, and if so switch to AC mode. I still have to implement this. This also means I have to modify the simulator to be able to filter the DC component. I skipped that while writing the simulator.

Fixed some other small issues with the trigger channel, like when the channel that is the trigger source is turned off, the trigger channel was swapped in the hardware, but not on the display.

A bit of a problem with the way the whole project came together. Without a clear design and a hard to crack black box, the code turned into a bit of a mess. Removed a lot of the rubble already, but the code can still do with a polish, and it still needs a rewrite of the whole waveform and picture view part.

When that is finished it is getting there, but still needs a lot of work to implement the FFT, measurements and what else that is missing.

At least the new code can easily be adapted to a new FPGA design.

[Alex62]

AUTOSET - sine good. Unipolar meander on video.

[pcprogrammer]

Hi Alex62,

thanks for the video and the testing, but the version you have does not have the proper auto set functionality. It has part of the original reverse engineered code which is not very good. Might even skip the time per division setting al together.

I did test the new version on my hardware and I'm very pleased with the result. For frequencies above 75KHz it is very quick. Worst case it does five captures. 1 to set the sample rate and time per division and 2 per channel to determine the volts per division. For frequencies between 750Hz and 75KHz it needs an extra capture for the time per division determination. The volts per division ranging can then become a bit slower, because it is done on the determined sample rate set for the channel that is the trigger source. This means that for the even lower frequencies it can at worst case be very slow. It does a third capture for the frequency determination and again the volts per division ranging is done on the now set sample rate, which might even be the 500Sa/s. This means 6 seconds per capture.

The volts per division determination is done by doing a capture at 500mV/div. The resulting peak to peak measurement is used to divide a maximum screen range the signal can use, and this results in a value that can be used to match the ranges including the 500mV/div and below. So if the signal is within this range it only takes one capture. If it is out of this range it does a second capture at 2.5V/div. The same calculation is applied and the correct setting can be determined.

The maximum screen range depends on if only one channel is enabled or both channels are enabled. For only one the signal center is placed on the center of the screen and the signal can use 7.8 divisions. When both are enabled channel 1 is placed in the top section and channel 2 in the bottom section. Now the signals can only use 3.8 divisions.

All that is needed now is a check on the DC content in the signal. I have to think about what is the best way to handle this. Either always switch to AC, or if it is small enough, stay in DC mode and shift the signal center to allow the signal to be displayed properly. Or just leave it as is and let the user deal with it, when auto set more or less fails.

Happy to hear your thoughts on this.

[pcprogrammer]

Just a short update.

Working on the picture and waveform saving and viewing. Decided I did not like the original thumbnails and made my own version of it.

Like to hear if this is for the better or not.

[ded]

Hi, I think it's better.  Above all, the visible numbering is great.

[pcprogrammer]

Another update.

finished the picture viewing part and polished the looks of the user interface a bit. Was not pleased with the buttons not being buttons, so modified most of that.

The new setup works with two directories. "\pictures" and "\waveforms" Was thinking about a no limits system, but with FatFs the needed code to step through pages of view items would be a pain in the bum. Going forward not that bad, but backing up a page would mean start at the beginning to find the first item of the requested page. So I reused an adapted version of the original code.

The original uses two fixed length files. One for the list with file numbers, and another for the thumbnails. I modified this to use only one file that grows with the number of saved items. It is still loaded into memory to be able to step through the thumbnail pages, which is why I limited it to the originals 1000 items per type.

The code for handling the items is for a large part the same for both types, so getting the waveform view working is not a lot of work. Need to adapt for the new sampling setup.

Once that is done, I still have to get the X-Y mode working again. Also needs to be adapted to the new sampling setup.

It will be a couple of day's before a new test release. This one will have a version number, which can be seen in one of the screen captures. Per advise of morris6 I placed it underneath the battery icon.

At some point I will setup a new github repository for just the new firmware. The reverse engineering and hacking is past tense. From now on only new code.

The picture view screen shows the file name in the bottom menu bar. As in the original this bar can be tapped away and back again by tapping outside of the button area.

[RolfNoot]

Thanks for the excellent work!

I'm an owner of this scope, can I get a recap on the current state of the firmware without having to read 50+ pages? I've got some questions:
- is it worth to update the firmware yet over using the factory firmware
- if yes, what are the advantages / disadvantages
- is the upgrade process easy

Cheers,
Rolf

[pcprogrammer]

Hi Rolf,

the state of this new firmware is still very alpha. Would not recommend it for real usage yet.

The advantages are that it is fully open source, responds faster and is non fictional in what you see on the screen. Also a lot of the errors found in the original firmware are fixed. It does not hang when switching back from USB connection and what more.

It is different in comparing with the original that it uses separate sample rate and time per division settings, uses 3000 instead of 1500 samples per capture and got rid of the roll mode. It allows a time per division range of 200ms/div to 5ns/div.

The upgrade process is quite easy. See: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3807689/#msg3807689 for the basic steps. These are only needed to prep the SD card and get it up and running for the first time.

Also take a look at these post for more info:
https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3809966/#msg3809966
https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3908555/#msg3908555
https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3917249/#msg3917249

It does not interfere with the original code and the scope can easily be restored to the original state, as you can read in the above mentioned posts.

It will still take a while to get the rest of the needed features into this new firmware.

Only the last couple of pages (page 45 and onward) tell about the development of the new firmware. Everything before that is about the reverse engineering of the original code. It tells a story of how much time it takes to do a project like this, and how frustrating it can be.

It would be great if you are willing to do tests on the new alpha release. I hope to get it done in a couple of days.

[RolfNoot]

Sure, I am willing to do tests.

I like this scope a lot regardless the buggy Chinese firmware. I own several oscilloscopes (Agilent, Rigol) and find this neat one very handy to use. Not for fast precision measurements of course but just for a quick measurement without having the hassle of plugging it to a wall socket and waiting a long time to boot.

Good to hear lots of errors are fixed. Will keep an eye on this topic!

[pcprogrammer]

Again a short update.

The waveform view part is implemented and working. Had to add a bunch of checks to disable changing scope settings that more or less need to stay what they are. Think of the trigger channel of trigger edge. The capture has already been done, so it will not make a difference. By disabling the changing of these settings it is clear what they were at the time of the capture. The menus show this by making the not selected options grey instead of white.

Also added the filename of the waveform being viewed to the right corner on the signal part of the screen.

Changed the file format too. Only the needed settings and the two trace buffers are saved. There is a version number and a simple checksum to safeguard it from a wrong file. Error messages are shown in that case, and the corrupted file is deleted.

Also thinking about allowing the volts per division setting to change when in stop or waveform view mode, to allow software zoom.

Next up is the x-y mode display. When that is done I will release a new test version. Then still a long list of to do items to work through, but the end is nearing.

[Alex62]

Hi, Peter.
So far, everything is very good, a small problem with synchronization. When the frequency increases above 1 MHz, an offset from the set value occurs (shown in the photo). Thanks for the work.

[pcprogrammer]

Hi Alex62,

thanks for the testing. This shift in the trigger position is something I have noticed before, but have not investigated it properly. It is a tricky one, because it has to do with the FPGA.

I noticed that you have build your own executable based on the repository. The V0.001 below the battery is the giveaway

Cheers,
Peter

[JimBeam]

Hi Peter,

I'm new to this group, I just got my FNIRSI (what a name...) a few days ago - and as always I could not keep my fingers from messing around with it (don't turn it on, tear it apart!)

The first thing I always do in this case is to look into eevblog to see if anyone has already done some investigations, and in most cases I'm lucky, and this time too 
So a big THANK YOU for your work to change this little beauty into a real gem!

Next thing - especially if someone has made a replacement firmware - is to test that and poke around in the source code.
While doing so I found a small bug: if channel 1 is turned off, then the AUTO-SET function does not work.
And because of my poking I also found the solution: it can easily be corrected by just changing a '1' to a '2' in 8th line in the function scope_do_auto_setup() in scope_functions.c ...

Currently it reads:

Code: [Select]

uint32 dochannel1 = scopesettings.channel1.enable;
uint32 dochannel2 = scopesettings.channel1.enable;

where the second line should better read

Code: [Select]

uint32 dochannel2 = scopesettings.channel2.enable;

I also guess how that happened - I only say: copy line...

Did not do a pull request, as it is such a minor change, and there is a new repository on the way anyway.

Andreas