FNIRSI-1013D "100MHz" tablet oscilloscope

[jemangedeslolos]

Hello Ultimator,

I had problems with this scope (I have one of the first models with the old box).
Sometimes it didn't want to start at all or crashed.
It was due to bad soldering on the FPGA.
I re-worked it with good solder and the right amount of flux ( )
I cleaned everything with IPA and now it now works like a charm.

[pcprogrammer]

Hello Ultimator,

I had problems with this scope (I have one of the first models with the old box).
Sometimes it didn't want to start at all or crashed.
It was due to bad soldering on the FPGA.
I re-worked it with good solder and the right amount of flux ( )
I cleaned everything with IPA and now it now works like a charm.

That might be possible for the strange signal behavior, but not the freezing and buttons changing color. That is definitely touch panel behavior.

[Ultimator]

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

It's just a usual expression of politeness valid for for a few days while awaiting for seller response - as most sellers don't welcome customers raising disputes in advance of contacting them personally first.
And on the other hand, some additional fault-related evidence could appear in this time with my device - in case if what I do already have would be discarded.

[Ultimator]

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

Rather not in this particular case, as my goal was to expose freezing in auto mode when display update shouldn't stop even with unstable input signal - which so is more suitable to provoke this fault.

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.

It's a subject for further investigation, in addition to testing the touch panel and RC values on its bus.

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.

It's still unclear for me what causes freezing when there's no altering-color indication of some button seemingly still being touched.   

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.

No wonder that many full-size benchtop scopes are more capable even regarding their higher cost, but the very idea behind 1013D is it's unique field-portable-full-screeen form-factor - also being the reason of my interest in this device.

[Ultimator]

Hello Ultimator,

I had problems with this scope (I have one of the first models with the old box).
Sometimes it didn't want to start at all or crashed.
It was due to bad soldering on the FPGA.
I re-worked it with good solder and the right amount of flux ( )
I cleaned everything with IPA and now it now works like a charm.

I'll check for assembly-related issues when testing touch panel, but in case of partial display fault it's strange that signal crops frequently do happen in highly synchronized manner at exactly the same position on the screen as in my previous screenshot. This can hardly be explained by bad soldering of IC.

[Ultimator]

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.

This is also on "to do" list, just slightly further.

[pcprogrammer]

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.

It's still unclear for me what causes freezing when there's no altering-color indication of some button seemingly still being touched.   

Touch, no matter where on the screen, freezes the display. It is how the software is. The moment it sees touch it looks at the coordinates and decides what to do with it, but only does it after touch is released, or there is movement. (Trace offset, cursors, etc.) But as long as there is touch the updating of the signal stops. You can see this when in roll mode (100mS/div and up). Touch the screen and the updating stops.

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.

No wonder that many full-size benchtop scopes are more capable even regarding their higher cost, but the very idea behind 1013D is it's unique field-portable-full-screeen form-factor - also being the reason of my interest in this device.

For me it was the small size that made me buy it The fact that it arrived with a defective touch screen led me to where we are now. Almost reverse engineered software

[pcprogrammer]

I found this link with several options for DD on windows. https://superuser.com/questions/839502/windows-equivalent-for-dd Maybe of help for windows users wanting to use what I make

[pcprogrammer]

Fixed two issues that where bugging me

• In the long time base settings the original scope does not double the signal for the 50mV/div setting (1x probe magnification, higher for the other magnifications). I added that to my version, but the trace jumped off center when switched to this setting. That is now fixed. The trace stays nicely around the center mark.
• In the short time base settings the trace offset worked the other way around. Moving the trace pointer up made the signal move down. That is also fixed.

Also worked on the simulator, which now shows signals coming from the files I made on the real scope. Needs more work to make it a real simulator of the original FPGA, which for a part is still guessing what is in this black box.

They made such an idiotic system, where they set the trace offset in the FPGA, which then shifts it's result based on that. But then they do so much calculations in the MCU that this bit, they offloaded to the FPGA, fades in comparison It would have been so much easier if they just returned the 8 bit ADC data as is and did the trace offset handling in the MCU.

An other problem is the number of faulty captures coming through. I can see them in the captures, but have not analyzed them yet. It is clearly visible when the scope just runs that some captures are very high frequency garbage. Not sure if this can be avoided by sending FPGA commands in a different order. On the original these mishaps are less frequent, but they are there. 

[geoffCohen]

I’ve had my 1013D for a week –

Firstly, thankx to pcprogrammer for his fantastic work on the 1013D – it definitely needs a few improvments.

Anyway, here are my initial thoughts about the 1013D

The 1013D has MAJOR problems with calibration, with seemingly DUMB decisions made at FNIRSI

* Calibration is OK with a X1 probe and is just within 5%, HOWEVER, with a X10 probe, there’s a large 10% error - and it’s the same with both the FNIRSI probes and 350Mhz Tektronix probes. This is a major bug, apparently because FNIRSI didn’t know the input impedance of their own DSO – and it’s a bug that could be easily fixed in the software, by reducing the gain in X10 mode – however, as a quick KLUDGE, I soldered some 10M resistors across the BNC inputs &  GND, which makes X10 accurate to 2% - pic attached.

* The calibration is apparently derived from an internal 3V reference (also used by the1KHz squarewave output) – when tested with an accurate 3.00V input – the 1013D always read this 5% high (as 3.15) – so having a way to adjust overall calibration/gain down 5% for X1 and 10% for X10 would make this DSO much more accurate, and for zero cost too, I have no idea why FNIRSI didn’t do this !!!

* a minor annoyance – my probes didn’t have a yellow color coding ring – a few minutes with one of my 3D printers fixed this. I also made some stickon probe clips – pics & stl files attached

* I also don’t like the stand much – It’s floppy and the angle is completely wrong for me – as a quick kludge I glued on a couple of wedges to make it a bit better, with an improved stand design as a priority item in my 3D design queue.


Good
The 1013D is, by far, the easiest, most user friendly CRO/DSO I have ever used, and I’ve run Electronics workshops at the Australian National Uni with top of the line equipment.

Bad
After some (admittedly quick) testing, it looks like FNIRSI added an extra 0 to the bandwidth – the 1013D seems good up to 10MHz, much beyond that and it’s not great, but as a DC-10MHz DSO it’s great value and fun to use too – it just needs that calibration adjustment added to be really great.

=========================
Thankx
Geoff Cohen

https://www.thingiverse.com/geoff_cohen/designs
https://diyodemag.com/education/exploring_3d_3d_printed_gears_part_1
https://diyodemag.com/projects/paused_prints_arduino-based_filament_runout_sensor
https://diyodemag.com/projects/fixing_firmware_updating_firmware_on_the_arduino_bootloader_part_2

[pcprogrammer]

Hi Geoff, and welcome to the forum.

The calibration is a good point. Have not looked at it and it will go on the list of things to do for improvement. Is indeed not a big deal to tackle in the software, but will require user aid, and separate steps in the software to do a x1 and a x10 and perhaps a x100 calibration.

I'm not sure, but what is in the original now is just zero measurement and ADC difference (2 interleaved ADC's per channel) calibration.

My work so far at least solves some of the hang issues, like with the USB connection. The original code hangs the scope with almost any PC action, where mine, tested so far, seems rock steady.

My motto is, less code, less room for error

[pcprogrammer]

Added the ability to step through the sample files and buffers to the signal analyzer (just a simple display program) and looked at all the 1050 captures I made. Found a couple of errors, but the most common one is that one of the capture buffers has no signal, and it is always the main buffer they use for all the time base settings.

This is something I can filter upon

An other thing, not really an error is that for the 100uS/div setting they capture less samples at the correct speed, making the top so many samples unusable.

A third error I only saw once was in the 5mS/div setting captures. Half the buffers are sampled at a different rate.

See the attached images for what I found.

[pcprogrammer]

Started on the new path.

Implemented the modification of the top menu bar and made a screen capture with an error in the signal capture on the display.

Added the ACQ (acquisition) button to allow the setting of the sample frequency and the time per div via a menu, and no longer with the tapping on the left or right of the screen.
Have to see if it needs to be bound to some rules or left completely free in respect to the relation between the two settings.

Quite a bit of work ahead to make it work with the new idea I have, but with the testing now on the PC it is much easier to do.

I will add a new directory to the repository for the last version of the original based code, which will remain unfinished and use the current directory to hold the new code.

[morris6]

What do you think, is this a genuine Altera Cyclone IV?

[pcprogrammer]

On early pictures I have seen in this thread, or a video from Dave the chip had its original markings, which showed it to be a EP4CE6E22C8N.

The picture even is in my repository 

https://github.com/pecostm32/FNIRSI-1013D-Hack/blob/main/Pictures/Old%20version/Main_board_old_system_large.jpg

Don't think they will have abandoned it, but who knows if it is a clone. Not sure but I think @tv84 looked at the bitstream files and got some info out of it. This is somewhere in this thread

[1audio]

RE cloning software for windows. I used this for years to clone Linux images on windows: https://selfimage.en.softonic.com/  Its old and abandoned but works. Like dd the requirements have not changed much for an imaging program.  I have used Rufus but I think Rufus is too Windows focused for this.

[Ultimator]

Touch, no matter where on the screen, freezes the display. It is how the software is. The moment it sees touch it looks at the coordinates and decides what to do with it, but only does it after touch is released, or there is movement. (Trace offset, cursors, etc.) But as long as there is touch the updating of the signal stops. You can see this when in roll mode (100mS/div and up). Touch the screen and the updating stops.

In other words when display freezes without visible altering some menu button color - this likely means that false touch is still being detected but in area where there are no menu buttons, so this aspect can be considered logically explained.
However the partial display phenomena still needs remains unclear.

For me it was the small size that made me buy it The fact that it arrived with a defective touch screen led me to where we are now. Almost reverse engineered software

Who could know in advance that finally it will appear cheaper to buy "expensive" branded alternative. I seem to be closing to this too.

[pcprogrammer]

Correct about the touch, but indeed the other phenomena is not explained by it. That is why I suggested it could be two unrelated issues.

There are similar but more expensive alternatives for sure. The micsig brand has, to my understanding and not experience, better tablet scopes.

The funny thing for me was that I bought it for my hobby and then it became my hobby

[geoffCohen]

Can I put in a request to KEEP the Tap Left/Right method to change the timebase - I find this an extremely easy way to change timebase up/down - WITHOUT having to click away at menu's. Annoying menu's (especially for trigger settings), was the main reason I didn't get a Hantek, I found setting my (borrowed) DSO5102P annoyingly tedious

[pcprogrammer]

Can I put in a request to KEEP the Tap Left/Right method to change the timebase - I find this an extremely easy way to change timebase up/down - WITHOUT having to click away at menu's. Annoying menu's (especially for trigger settings), was the main reason I didn't get a Hantek, I found setting my (borrowed) DSO5102P annoyingly tedious

In itself an easy thing to keep, but needs some thought on sample frequency setting, because I think it has to change with it at some point. Since there is so little sample memory it only stretches so far in the time per div settings.

My new idea also scraps the roll mode time per div settings.(50S/div - 100mS/div) Trying to fit 100mS/div and 200mS/div into the normal sampling setup, but it depends on if it is possible to get a couple consecutive buffers on the lowest sample frequency. (2KHz) One buffer offers only 0.75S worth of samples and with 14 divisions a full screen at 200mS/div needs 2.8S so almost 4 buffers.

This roll mode is already working in what I made so far, so not to difficult to incorporate it as a separate mode, but for me there is no use case, so only on request it will make it in

[geoffCohen]

Guess I'll have to bit the bullet, and crank up a Linux system on a spare laptop - which version do you recommend. FYI - I've been a programmer for many, many years - microprocessor/Database/3D (OpenSCAD), with most using some flavor of C - but all Windows based. Now I'd like to be able to play with your emulator/1013D code, even possibly contribute something to the project.

[pcprogrammer]

I'm using Linux Mint 20, which I like over the Ubuntu version. Take the light weight version XFCE if your computer is not that powerful.

For development I use Netbeans 8.2. Not sure about the status of C development in newer releases. Have not looked at that for a long time. You need to setup the gnu arm compiler to make it all work.

The projects I'm using for development now are the "Scope_Signal_Handling_Development" and the "fnirsi_1013d_scope" which are both to be found in the repository. This is a simulator with stub functions for the FPGA and other hardware related stuff, and makes it possible to debug the code on the PC directly.

[pcprogrammer]

A couple of handy linux instructions to set things up

Code: [Select]

ctrl + alt + t to open a terminal window

sudo apt-get update                 #Load latest package list
sudo apt-get upgrade                #Upgrade what is needed to latest version

sudo apt-get autoclean              #Clean the package list
sudo apt-get autoremove             #Remove no longer needed packages


sudo chmod +x netbeans-8.2-cpp-linux-x64.sh    #Change the execution flag for this file
sudo ./netbeans-8.2-cpp-linux-x64.sh           #run this file to instal netbeans

sudo apt-get install gcc make build-essential  #install all the needed tools for making and building code
sudo apt-get install gcc-arm-none-eabi         #install the gnu arm compiler tools (needed for compiling the scope project for the real target)

Seems the netbeans package is not easy to find anymore. I have it here, but github won't allow it due to it being to big. (114MB) If you need it drop me a PM.

[pcprogrammer]

Implemented the new menu and as per request left the tapping on the left or right side of the screen in there.

It still needs logic to show possible combinations, but I have to see what these are. Also need to change the FPGA controlling based on the new settings.

Having both options makes it easy to make a big change with three touches (open menu, select setting, close menu)

Let me know what the thoughts are about the new menu

[morris6]

@PCprogrammer: It has been mentioned before: you are investing a lot of time and attention to improve this little box. Really awesome!

I am trying to follow along and so far I got your experimental firmware working on the box. It looks promising.

Now you invite users to give their thoughts about the new Acquisition menu, So OK, FWIW:

The indication of the sample rate in the top menu bar of the screen is very nice, I think.

I can understand why you call acquisition rate a frequency, but maybe the more usual expression 'sample rate' is called for here, like 200MSa/s or 50kSa/s. So better name it 'Sample Rate' at the top block. And why not use the correct lowercase 's' for seconds in the 'Time per Division' choices block?

Maybe you can add an indication of the resulting 'Samples per Division' somewhere, at the bottom of this foldout?.

A new item on the ACQ menu might be the choice of sample 'processing': to display the sample dots, linear interpolation or whatever approximation is possible with the processor. Or, maybe a choice of averaging 1, 2, 4, .., many.

Regards,
Maurits