FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Tried my firmware backup on the 1014D and noticed a problem with the flash reading, which I also saw on my new scope.

In hind sight, this also explains why the new scope failed to bypass the hardware check when I restored it with the firmware of the old scope. The first byte read is zero due to the clock being on the edge.

Checked the boot loader of the 1014D against the one on the old 1013D and noticed the clock setting for the SPI being different. I remember doing tests with this clock speed while I was reversing the SPI code, and it seemed to work fine on the one but highest clock setting. Lowered it one more click and tested it on the new scope, and the things that failed on the higher clock work without problem now.

So one more issue put to bed

[pcprogrammer]

Learning more about the display control stuff.

Reversed the 1014D software down to the display initialization and found only two differences, which have to do with the horizontal and vertical back porch.
Need to test the found values to see if they do the trick.

Only looked at the code I extracted from my scope. Not the latest firmware found on the FNIRSI site.

Also noticed that the SPI clock setting is much lower in the 1014D. ((AHB clock / 12) versus (AHB clock / 4)) In my code it is now (AHB clock / 6)

Reversing the 1014D code in Ghidra looks easy for a large part of it. Just look at the 1013D code and copy the function names. But the rest of it is for later. Need to finish the 1013D first.

Edit: Just changing these two values did not make a difference, so more research is needed.

[pcprogrammer]

Updated to do list

Implemented so far:

• System setup
• Timer interrupt
• Touch panel interface
• Flash reading and writing
• SD card functionality based on FatFs
• USB interface with mass storage functionality
• FPGA interface functions
• Display library
• Battery charge measurement
• Power off interrupt for settings save
• Saving and loading of the settings to and from flash
• Cursor measurements display
• SD card boot loader for startup screen program
• Startup screen program for showing the startup screen and loading the main scope program
• Touch panel calibration after update No longer needed since it now uses the existing configuration
• Firmware update (This means both code within my version as creating an actual firmware update that can be loaded on a scope) No longer needed since the switch to SD card boot
• User interface
  
  • The main screen with all the menus
  • The picture view screen with picture view almost done. (Still needs displaying of the trace data)
  • The waveform view screen with waveform view almost done. (Still needs displaying of the trace data)
  • Saving of pictures and waveforms
• Trace data handling and displaying
  
  • Long time base settings 50S-100mS. (This is in roll mode and fully done, except for an error in the highest vertical resolution setting)
  • Short time base settings 50mS-10nS. (This is partially implemented. Channel 1 data is fetched and displayed raw. Only part of the processing is implemented.)

Still to do:

• Finish the picture and waveform single item view. Needs the trace data processing functionality
• Trace processing and displaying for the short time bases (50mS-10nS)
• Calibration
• Auto set
• Measurements calculations and displaying
• FFT calculation and displaying
• Possibly needed display calibration functionality

[Fraser]

Pcprogrammer,

I just wanted to congratulate you on your work to date. You are clearly committed to this project and achieving steady progress. I have seen many similar projects started and then the development work trails off as the software coder loses interest or discovers other projects to code for that are more interesting.

I do not own one of these scopes but was considering the purchase of one some time ago as a basic tablet DSO. I ended up buying a ‘used’ MICSIG ATO1102 automotive DSO as it was ‘as new’ and the right price. I still read your posts though as it is good to see the project progress. I hope you continue your work and achieve the end result that you have worked hard for 

Fraser

[tv84]

He's a resilient inspiration. 

[pcprogrammer]

Back on the signal processing, which still needs a lot of work

I have implemented the up sampling routines basically based on the original code, but there is a big difference between the original and what I made.

For 250nS/div and 100nS/div it is fine, since that is only interpolating between the samples. None of the filtering done on the 50nS-10nS/div settings. On 50nS and 25nS/div with a 10MHz sine wave input my versions look like shit

On 10nS/div it is not that bad.

Still have to get the triggering right, which will skip the samples at the beginning so it might look better that way.

In the original code, on 25 or 10nS/div, there is some artificial signal generation done when the input frequency is higher then some value. I skipped that bit of code because it is a real pain in the bum to reverse, and does not do a scope justice. You want to see the actual signal, not something an engineer thinks it should be. Sure it looks good, but helps you nothing when there is trouble.

My version is also very restless, which might be caused by the faster code. To many screen updates and reads from the FPGA causing problems.

This means still a lot of research to get things more or less right.

[pcprogrammer]

I'm wondering if any of the 4 7 9 11 down loaders of the scope test firmware has tried it yet.

Would be nice to hear what the results are and what needs to be looked at. I know there are still a couple of issues in there.

Edit: I just looked back and noticed it has been downloaded some more

[simba15]

Very cool project!

I hope you are able to resolve some of the issues with this scope.  It seems like a very nice product to use (large screen) but the issues with the measurements leave lots to be desired.

That's where you came in! You clearly look like you may be able to resolve these!

Your progress makes me want to buy one to assist you with the user feedback of the firmware.

Thanks!

[pcprogrammer]

Becoming more and more convinced the original short time base trace data processing is not worth the effort of full reversal, I'm going to take another route in making better software, for as far as the FPGA programming allows.

With the FatFs and USB mass storage implemented it is possible to create sample files and copy them to the computer. The idea is to write a bunch (50 or more) consecutive signal captures (raw sample data) to a buffer and when the count is reached write them to a file. Need to do this for the different sampling speeds the FPGA supports. E.g. for 10 and 25 nS/div it uses the same 5nS sampling. For 50 to 500 nS/div it uses 10nS sampling. (Actually the data written to the FPGA is the same for 10nS - 500nS, but for the two lowest the second ADC data is also read. Not sure if this second set is always available.)

This way I can look at the data on the computer and decide on what processing is needed to show a good signal representation.

Another thing I thought of, is there a way to re-program the FPGA connected FLASH chip without opening up the scope. The Intel/Altera Cyclone IV does provide support for it, but I doubt the FNIRSI engineers made provisions for it in their FPGA design. Did not find any clue in the software to suggest there is a command that allows writing new FPGA programming, which is a pity.

Since there is more support from the manufacturer for the 1014D it might be that it supports this. The firmware updater program is different, at least a binary compare shows a lot of changes, but I have not looked at that in Ghidra.

The 1014D code is certainly inconsistent In the boot loader they write one byte of data for the screen brightness, while in some parts of the main program they still write two bytes (the 0xEA60), but the function to set the screen brightness writes only one byte and does not use the translation chip anymore

[pcprogrammer]

First investigation shows a good signal for the 25nS capture.

On the first try I saved the separate buffers loaded from the FPGA, and after that I modified it to save the interleaved buffer. Both signals show the input is a sine wave (10MHz), where the separate buffers show as double frequency on my test screen. The interleaved signal has a slight error in the first couple of samples, but not noticeable.

It is only in the first 4 samples, but I see it in all the captures I made. (The first two samples of the separate buffers are always the same)

Code: [Select]

0x76 0x8B 0x76 0x8B 0xA0 0xB9 0xD0 0xDE 0xEC 0xF0 0xEE 0xE4 0xCF 0xC1 0xA6 0x91
0x7C 0x6B 0x60 0x59 0x5D 0x67 0x76 0x8A 0xA1 0xB9 0xD0 0xDD 0xEC 0xF1 0xEE 0xE4
0xD0 0xC1 0xA7 0x90 0x7C 0x6B 0x60 0x59 0x5D 0x68 0x77 0x8A 0xA1 0xB9 0xD0 0xDE

Have to make more captures with different input signals to see what the scope returns.

Also need to figure out where the trigger point is and how the trace offset system they made works.

One thing is for sure, this is more fun to do then trying to reverse the crap code they wrote.

[pcprogrammer]

Verified a finding by comparing the two scope versions next to each other.

Made a video of it: https://youtu.be/SApQPL3pDvc

I wrote before that the scope makes up its own signal when the input frequency is above some value. Did calculations on it, and determined it is more then 43.3MHz This can be seen in the video near the end. I start at 80MHz, which it does measure, so hats of for that, but the amplitude is faked. My version next to it shows a much smaller signal. There only the up sampling is done.

When I lower the frequency the signal on both gets bigger and I have to lower the sensitivity. After that I start fiddling around the 43MHz. When I switch to 44MHz you can see the signal strength increase (Near 0:49 into the video) This is not the case on my version.

Found an error in my x10 up sampling, which was causing the 50 and 25nS setting to be crap.

The reason my version is unstable has to do with the fact that I display from the start of the buffer without regard for the trigger point. That still needs research.

Also sorry for the crappy quality of the video. Don't have the equipment for doing professional work.

[Ultimator]

Hi everyone!

... I wrote before that the scope makes up its own signal when the input frequency is above some value. Did calculations on it, and determined it is more then 43.3MHz This can be seen in the video near the end. I start at 80MHz, which it does measure, so hats of for that, but the amplitude is faked. My version next to it shows a much smaller signal. There only the up sampling is done.
When I lower the frequency the signal on both gets bigger and I have to lower the sensitivity. After that I start fiddling around the 43MHz. When I switch to 44MHz you can see the signal strength increase (Near 0:49 into the video) This is not the case on my version. ...

This "trick" has also been noticed in one of previous reviews:
https://www.ixbt.com/live/instruments/obzor-dvuhkanalnogo-oscillografa-fnirsi-1013d-s-7-dyuymovym-sensornym-ekranom-igrushka-kotoraya-sovsem-ne-igrushka.html

A detailed study of the origin of such a suspicious smoothness of the oscillogram showed that at sweeps of 10 ns / div. and 25 ns / div. when the frequency of the input signal goes from 43.3 MHz to 43.4 MHz, the oscilloscope begins to turn any signal into the purest sine!

But in my case neither this or other accuracy/bandwidth/sample-rate related issues seem to be the most disturbing.

Not sure if this may be dependent on my particular device which may of course have some kind of "personal" manufacturing faults, but anyway - periodically the scope just freezes at random intervals and stops reacting to actual input signals, usually this happens with simultaneous turning to orange background color of one of menu buttons CTRL/V+/V- (the latter two cases usually then lead to respective change of V/div setting by the scope itself even without me doing anything at that time), also I've noticed that attempt to modify "T" settings menu leads after some random pause to "T" button background turning violet while background area to the right of it (where actual triggering settings are displayed) turns white at the same time and signal display also freezes, then after some ~10 seconds "T" menu opens again by itself (!) and sometimes disappears after a while but sometimes not and still needs tapping on "T" to close it, frequently just to repeat the same strange cycle again.

Tapping some button to "wake up" the scope seems to always work (i.e. the scope stops reacting to input signals and freezes the last view but still reacts to control actions) but it's really difficult to use the device when "activating" it every few seconds sometimes becomes necessary, the more that I still haven't noticed any "rules" for such behavior which retains the same random manner even regardless of whether any signals (which could provoke some response of device) are applied to scope inputs or not.

So my questions regarding this are the following:
- has anyone experienced similar behavior of this scope?
- any idea what could cause it (apart of specific hardware fault in my particular device)?
- what orange background color of CTRL/V+/V- buttons and violet/white background colors of "T" menu area could mean?
(seems like the latter color change should rather be implemented by device design than be a result of some accidental fault - regrettably, I couldn't find anything mentioned about this in manual)

Also by the way, for pcprogrammer and all others who could be working on device improvement - maybe it is possible to implement some "error messaging" service into control system of this scope as by default there seem to be too much cases when seemingly unclear and unpredictable behavior is caused by device not reporting anything about its internal actual state and actions - which so remain unknown to a user.

The device I'm using is a never model which was ordered about a month ago from Aliexpress warehouse in Europe and is one of the last units from previous party i.e. before recent price increase.

And, in all aforementioned cases of input signal freezing the scope still keeps displaying "run" as an actual state, while trigger setting still remains in "auto" mode (in which sudden display freezing is best noticeable and most inadequate).

Thank you.

[pcprogrammer]

Hi Ultimator, and welcome to the forum.

Your problem with the scope, to my opinion, has to do with the touch panel. The turning orange of the "buttons" means they are being touched. Same as for the trigger (T) menu changing color. When the scope is touched it also freezes the signals on the screen.

This could easily mean that the touch panel has a hardware problem or reacts to some interference due to sensitivity settings.

Could you run my firmware backup program I posted on the previous page? Take the new one. When you follow the steps given in the post with the red warnings you will be fine. Upload the files here on the forum and I can take a look at the touch panel settings to see if it differs from "normal"

Also try to make a video of the behavior and open a dispute on Aliexpress, even though the 15 days might be over. Use the chat function to get them to open a dispute for you. It is not how the scope should behave and thus makes it a defective device.

[pcprogrammer]

Based on new findings, I decided to stop reverse engineering the crap and start writing new code.

The FPGA hardware offers samples from both ADC's for all ranges giving 3000 samples per channel for the 10mS - 10nS/div settings and 1500 samples for the 50mS and 20mS/div settings. Based on what I reversed so far they assume the trigger to be in the middle of the buffer, which is done by looking if there is the needed transition. (Rising or falling)

This gives room for a far simpler displaying of the trace data, without all the "special" handling done in the original, but requires a rewrite of a fair bit of the code. The waveform and picture view needs to be changed, which will also be an improvement

I will also change the time base setup. Going to make a user select-able sample rate and move the time/div select to a drop down menu. In a later stage I might look into touch gesture for zoom functionality.

Also thinking about dropping the roll mode time base settings. On this scope I do not see a use case for the >200mS/div modes, but might be wrong. Have to see what is doable on the lowest sample rates with only 1500 samples.

With the save to file setup I made it is possible to do the testing on the computer, which makes it a lot easier.

The story continues again

[pcprogrammer]

Working on a scope simulator now. Based on the emulator, but without the arm core emulation. It runs the scope code compiled for the x86-64 cpu.

Already working to some extend. It draws the scope screen and it is possible to "touch" the screen with the mouse. The user interface works. Menus can be opened, cursors can be moved etc. This part uses the same code as what runs on the scope.

Need to implement the peripherals with stub functions to make signal acquisition, parameter loading and saving, file handling etc. work. This makes it usable for the new development. Testing and debugging becomes very easy this way.

[Ultimator]

... The turning orange of the "buttons" means they are being touched. Same as for the trigger (T) menu changing color. When the scope is touched it also freezes the signals on the screen.

Oh, of course. I haven't noticed this because I cover buttons with my finger while touching them and I didn't pay attention what's happening there under.

This could easily mean that the touch panel has a hardware problem or reacts to some interference due to sensitivity settings.

However, freezing isn't always related to scope considering menu button being touched and so altering button color - it frequently freezes without any visible changes on the screen, likely this needs some more investigation.

Could you run my firmware backup program I posted on the previous page? Take the new one. When you follow the steps given in the post with the red warnings you will be fine. Upload the files here on the forum and I can take a look at the touch panel settings to see if it differs from "normal"

As far as I understand from your referred post, the proposed method implies using Linux as PC OS while all my machines are Windows at this moment, so it seems not so straightforward in my case, nevertheless what's the easiest workaround?

Also try to make a video of the behavior and open a dispute on Aliexpress, even though the 15 days might be over. Use the chat function to get them to open a dispute for you. It is not how the scope should behave and thus makes it a defective device.

I checked product page once again and yes it has some warranty statement in description so maybe it's worth following your proposal, I just want to collect more exhaustive data as it's still appearing, yesterday more-less normal work of the device was present after it has been on for a few hours, today after switching it on I've noticed some more strange things apart of those already mentioned - such as partial display of input signal, when left side of the screen displays close to reality, while from center and to the right some garbled-frozen mix is displayed.
Interestingly the actual miss-behavior of the device is clearly dependent on activation of menu buttons (tapping some button always alters the actual visible fault to something different, usually the correct functioning is being restored for a while) so these problems seem to be at least partially software-related.

[pcprogrammer]

Hi Ultimator,

It has been a long time ago since I used windows for anything else but gaming , so I can't offer an easy solution there. If there is an easy way on windows to write raw data to a disk sector then that is the way to go. For the program to work it needs to be loaded to sector 16 going up. 512 bytes per sector

For checking if the touch panel is the sole cause of your problems, open up the scope and disconnect the touch panel cable. Small 6 pin connector near the bigger display connector. Many pictures in this thread showing the inside.

The scope freezes where ever the touch panel is touched. So no button needs to be active.

If the freezing keeps happening it is safe to say there is an other problem

No matter which seller, if you bought it on Aliexpress they can force the restitution if they decide in your favor.

Edit: It is possible to run linux from an usb stick. As long as dd is available on the stick it will work without wrecking your windows machine, as long as you make sure the drive you target is the correct one. Look for live linux on google or so. (https://www.linuxliveusb.com/)

[Ultimator]

For checking if the touch panel is the sole cause of your problems, open up the scope and disconnect the touch panel cable. Small 6 pin connector near the bigger display connector. Many pictures in this thread showing the inside.

Yes I've seen this.

The scope freezes where ever the touch panel is touched. So no button needs to be active.
If the freezing keeps happening it is safe to say there is an other problem

I still should say that if freezing won't happen without touch-screen this still shouldn't strictly mean its pure hardware problem, may also be wrong software reaction to panel signals - not actually happening while disconnected.

No matter which seller, if you bought it on Aliexpress they can force the restitution if they decide in your favor.

The problem is that after 15-day period there's no more option to "open dispute" thus involving Aliexpress, the only option now seems to be contacting particular seller, what I've already done and waiting for response.
(correct me if I'm wrong)

Edit: It is possible to run linux from an usb stick. As long as dd is available on the stick it will work without wrecking your windows machine, as long as you make sure the drive you target is the correct one. Look for live linux on google or so. (https://www.linuxliveusb.com/)

Ok, I'll see this option on occasion.

The latest recently found "partial display" fault can be seen on this screenshot:

[pcprogrammer]

No matter which seller, if you bought it on Aliexpress they can force the restitution if they decide in your favor.

The problem is that after 15-day period there's no more option to "open dispute" thus involving Aliexpress, the only option now seems to be contacting particular seller, what I've already done and waiting for response.
(correct me if I'm wrong)

You should start a chat session with the Aliexpress robot eve and insist on getting a human on the line. Might take a while, but it will help. Explain your problem and mention that you have proof. Best to have your video ready. Insist on them opening a dispute for you. I have done this a couple of times and with success. One time even after months of the protection period running out.

[pcprogrammer]

Concerning your trace looking weird, I have no explanation for that   That is one strange looking signal. What is the source you are measuring?

But still, opening the scope up and disconnecting the touch panel and do measurements without it will give a better insight in the problem. Without it, it is very unlikely that there will be touch detected. It needs a specific response on the I2C bus, even though it is bit banged, to decide there is touch.

If it removes the problems you will have to replace the touch panel. Not an easy task but doable. Lots of info about that in the thread too.

Signing off for today

[Ultimator]

You should start a chat session with the Aliexpress robot eve and insist on getting a human on the line. Might take a while, but it will help. Explain your problem and mention that you have proof. Best to have your video ready. Insist on them opening a dispute for you. I have done this a couple of times and with success. One time even after months of the protection period running out.

Ok, I'll try this option if I won't succeed with the seller.

[Ultimator]

Concerning your trace looking weird, I have no explanation for that   That is one strange looking signal. What is the source you are measuring?

I'm as usually just touching the probe tip with my hand, so it's the common inside-building 50Hz interference on the screen.

But still, opening the scope up and disconnecting the touch panel and do measurements without it will give a better insight in the problem. Without it, it is very unlikely that there will be touch detected. It needs a specific response on the I2C bus, even though it is bit banged, to decide there is touch.

Of course I'll also try this. But my notice was that if there's say wrong software reaction to correct panel signals, the former may not happen while the latter remains disconnected.
There are ate least two things backing this option:
 - touching the "frozen" button always corrects the situation (while if there was panel failure falsely imitating respective touch signal, there should rather be no reaction to actual touch of the same button),
 - freezing frequently happens without any visible menu button alteration (while in case alike "bad panel - good software" it should be always followed by altered menu button color as the "legal" cause of freezing).

If it removes the problems you will have to replace the touch panel. Not an easy task but doable. Lots of info about that in the thread too.

With all existing and awaiting problems it seems that just getting one more such scope could become best option overall - for both cross-diagnostic and cross-repair purposes, the only concern being as it's already clear - its already compromised reliability.   

[pcprogrammer]

You should start a chat session with the Aliexpress robot eve and insist on getting a human on the line. Might take a while, but it will help. Explain your problem and mention that you have proof. Best to have your video ready. Insist on them opening a dispute for you. I have done this a couple of times and with success. One time even after months of the protection period running out.

Ok, I'll try this option if I won't succeed with the seller.

I would not wait. The seller will not offer you anything since there is no dispute. Delaying it their game.

[pcprogrammer]

Concerning your trace looking weird, I have no explanation for that   That is one strange looking signal. What is the source you are measuring?

I'm as usually just touching the probe tip with my hand, so it's the common inside-building 50Hz interference on the screen.

Ah ha, 50Hz signal a like. Think it is better to use the calibration signal to do a more proper diagnosis.

But still, opening the scope up and disconnecting the touch panel and do measurements without it will give a better insight in the problem. Without it, it is very unlikely that there will be touch detected. It needs a specific response on the I2C bus, even though it is bit banged, to decide there is touch.

Of course I'll also try this. But my notice was that if there's say wrong software reaction to correct panel signals, the former may not happen while the latter remains disconnected.
There are ate least two things backing this option:
 - touching the "frozen" button always corrects the situation (while if there was panel failure falsely imitating respective touch signal, there should rather be no reaction to actual touch of the same button),
 - freezing frequently happens without any visible menu button alteration (while in case alike "bad panel - good software" it should be always followed by altered menu button color as the "legal" cause of freezing).

The idea of bad software is less likely. To my opinion a fallen over bit won't show such behavior. Since I reversed the whole user interface part of the software, I can explain all the freezing behavior, except the weird signal stopping and re-starting on a later location on the screen. The two problems might not be related.

There is a video of someone who had a similar "touch" problem and he claims to have solved it with a 470 ohm resistor on the "miso" line. Since it is I2C there is no "miso" line, but the design of this part of the scope is crap, so that resistor might do the trick. There is a capacitor between the SDA and the SCL line to overcome a problem with glitches. I have tested various scenarios, like removing the capacitor, other resistor values, bigger capacitor, while measuring the signals with an other scope. I could see the glitches. Since it is bit banged it does not filter like a proper I2C interface. In the video he now uses my reversed schematic and writes about a resistor on the reset line. In the text description of the video he write "miso" line because that it what a possible use of the MCU pin is. On the board it is on the capacitor at the SCL line.

My explanation for the behavior he was seeing is that when the MCU reads the status register of the touch panel, the bit signaling touch is flipped, and then when it reads the coordinates it gets the last coordinates touched. In your case it might be reading a prolonged false being touch status. The scope waits for the touch to be released before continuing.

If it removes the problems you will have to replace the touch panel. Not an easy task but doable. Lots of info about that in the thread too.

With all existing and awaiting problems it seems that just getting one more such scope could become best option overall - for both cross-diagnostic and cross-repair purposes, the only concern being as it's already clear - its already compromised reliability. 

Sure that is an option, but I would then consider buying a Hantek DSO2C10 and upgrade that to a DSO2D15. A better scope with more options and not that much more expensive. Lots of info about it on this forum.

[pcprogrammer]

Hi Ultimator,

It would be interesting to see if your problem with the touch panel also occurs with my version of the software. The whole user interface part works the same, and there is trace display on channel one.

I wrote my own I2C bit banging and like to believe it is better than the original

The procedure to get it running is the same as the firmware backup program, so in your case a bit of a problem.

The package is also on page 45 of this thread.