EEVblog® Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: pcprogrammer on May 09, 2024, 07:41:38 pm
-
As announced in the original thread about the FNIRSI 1014D (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg5488975/#msg5488975) is here the new thread about the reverse engineering project.
I just finished coding the main functions for displaying most of the user interface objects. It was a lot of tweaking and looking for the bitmaps in the original code to write it all up and get the positions on the screen to be correct.
So far the following bits are coded:
- My logo :)
- The basic display with the grid
- The run/stop text
- The fast/slow text
- The trigger information
- The channel information
- The time base information
- The trigger status (Waiting.../Triggered)
- The measurements in the six slots on the right side of the screen
- The main menu
- The channel configuration menu
- The measurements menu
There are still plenty of user interface items to code, like the generator menu and the file view screens, but my next step will be to code the controlling of the settings with the buttons and the knobs.
Once that is working I will try it on the actual scope, for which I have to write additional code, like setting up the clock synthesizer, serial interface and other initialization. This will give me a base project to build further on.
A lot of the code written by me for the 1013D can be used, but I have seen that there are some differences in how it works with the FPGA, so I have to figure that out and test things to see if actually needed.
After finishing with the scope functionality the bigger challenge lies in the function generator. That will require more looking into the original code with Ghidra.
So sit back and enjoy the ride.
:popcorn:
Edit: For Windows users there is a program for loading the new firmware to the SD card. See here (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4700534/#msg4700534) for more information about this.
-
Short update with a picture. :)
First test of the screen setup code on the actual scope. It works without problems.
Next up is adding the code for getting the data from the secondary microcontroller, which is simple and already investigated by donwulff. Needs a bit of polish to rid the unneeded like setting it up for transmit interrupt and never have it handled by an actual interrupt handler. Is a straight copy from the original. Same as for using the FIFO, which is not needed since it is a request/response system based on a single byte.
A bigger part is setting up a state machine for handling the user input and allow the control of the settings. Will do that on a step by step approach.
So, wait for more to come. 8)
-
Things are coming together. :)
Some of the basic functions are coded, like setting the trigger channel, run/stop control, channel sensitivity, etc. For the things that work with a menu more work has to be done. It needs handling in a secondary state instead of changing the one setting and continue with sampling.
The sample gathering and trace displaying is done with the 1013D code and needs more tweaking, but it is doing something.
It is promising, even though it still needs lots of work done.
-
Again a short update.
Since the size of the trace section on the 1014D is smaller than on the 1013D I had to tweak a lot of the positions and sizes in the code that displays the cursors and the traces. Implemented the movement of the trace positions, trigger horizontal position and the trigger level, and had to correct the limits of movement for these too. Did the cursor measurements display, which also needed tweaking of the dimensions and positions. Trying to make everything a pixel accurate copy of the original takes its time with taking screen captures and enlarging them in pinta to zoom in on the actual pixels.
Have to correct a textual error, but since it is based on a bitmap makes it a bit more work then just deleting a letter. The text in the lower right corner states "Waitting ..." :palm:
All in all I'm having fun with it. But the tricky actual reverse engineering still has to come. My first goal is to have the basic scope functionality working, with the menus, calibration, sampling, etc. and release that for testing, while in the mean time do the code for the picture and waveform saving and viewing.
Also have to look into Atlan his work for the 1013D to improve on some things around the calibration.
And when all of that is done the signal generator is next on the list. Will also be quite the job.
-
Hit a bit of a wall. :palm:
Working at implementing the main menu, after finishing the time and volt cursor handling, I thought it might be a good idea to do the USB connection first, because with that working it makes it possible to write and clear new firmware on the SD card.
But for some reason the SD card bit fails when started from the SD card. At least with the code loaded via FEL, for both the original scope code and my new code. When the scope is started from FLASH it works as intended.
Have to try it with my new code directly loaded from the SD card and see if that suffers from the same problem. If so, some debugging is going to be needed.
-
Well it turns out that one 4GB card I have has problems, because it does not work in the 1013D either, but the original 8GB card that came with the scope does work in the 1013D also via USB, and it starts on the 1014D but there the USB connection fails on al sorts of errors. It works with the original firmware.
To rule out that it is my hardware causing it, I wonder if anyone with a 1014D scope is willing to try it with the attached firmware file.
It won't brick the scope, but worst case you need to open it and put the SD card in a PC connected SD card reader/writer to clear sector 16.
To load the test code, having Linux would be the easiest.
Connect the 1014D to the PC, open the USB export function on the scope. Check on Linux to which device it is connected, i.e. /dev/sdb or so. (lsblk)
Then unmount the partition (not the drive), write the new code to sector 16 and reboot the scope. The .txt extension in the attachment is to be able to attach it here. Can be removed or add it to the line to copy the file to the SD card. Make sure to use the correct /dev/... in the commands given below.
sudo umount /dev/sdc1
sudo dd if=fnirsi_1014d.bin of=/dev/sdc bs=1024 seek=8
The PECOs sCOPE startup screen will flicker because it is meant for the 1013D and there is a slight difference in the FPGA, but after that the new 1014D code starts. Press the menu button, scroll to the USB export setting and press ok. See what it does and if it also fails with problems on the PC (dmesg shows errors in red like "I/O error, dev sdc, sector 24 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0" and commands in white like "reset high-speed USB device number 34 using xhci_hcd") you will have to open it up and stick the SD card in a PC connected reader/writer. In the other file more commands are listed on how to load and clear the SD card.
The new firmware is far from finished, but one can try if moving the traces, setting the sensitivity, setting the time per division, enable the cursors, etc. works as expected.
Please report back here on how it went.
-
A typical "Or you stick the power plug in the outlet" type of error. :palm:
For testing in the emulator on the PC the mounting of the file system is disabled, and that also means that the mass storage driver has no active SD card to talk to. Enabled the mounting of the file system and now it works without problems, at least with the original card.
So don't bother with the code from the previous post unless you like to see what is up and running so far.
There is still a, probably speed, issue with the 4GB card, because it just won't work with that one. I'm able to use it to boot into FEL with DRAM enabled, but that is it. Something that needs to be looked at, but not now.
Back to implementing the code for the rest of the main menu items.
-
Back on track after the bit of a f..up. :-DD
I copied the picture and wave file saving code from the 1013D and modified it to fit the differences with the 1014D, like only 6 measurements being displayed. The picture saving works fine and the images can be viewed on my Linux PC when connected via USB. The wave files are also there, but have no code to verify them. Has to be checked on the scope itself when the opening of the items has been implemented.
At the moment I'm working on that for the picture part, which can then also be used for the wave files. To make it look nicer than the original, and already more or less implemented on the 1013D, I made it look more like the real scope screen, as can be seen in the attached picture.
After that it is implementing the rest of the main menu items, the measurement menu, the channel settings menu, etc. Still lots of work to be done.
-
Another short update.
Basically I'm just as far as I was a couple of days ago, but with a completely rewritten state machine. I was not happy with the previous setup, which did not easily allow some functionality that was needed. So I thought about a better solution and implemented that.
All this still for the file viewing, which is working for a large part, but now needs the functionality for selecting and deleting items. When that is done it is back to the main menu to, for instance, fill in the setting of the brightness, and a very important part, the base line calibration.
After that the measurement select menu and the channel configuration menu needs to be implemented, which will conclude the basic functionality and allows for the release of a test version.
Hopefully some of you that have a FNIRSI-1014D are willing to do some testing.
-
Sorry I cannot help with the testing as I have Rigol, but I literally shake might head in mild disbelief at the amount of work involved and time spent on your project, amazing.
Is there a major issue with the FNIRSI OS or is this just something you want/need to do? I can understand either reason. :)
-
Sorry I cannot help with the testing as I have Rigol, but I literally shake might head in mild disbelief at the amount of work involved and time spent on your project, amazing.
Is there a major issue with the FNIRSI OS or is this just something you want/need to do? I can understand either reason. :)
There are several issues with the FNIRSI scopes, and I reversed the 1013D out of need due to a faulty touch panel when I got the scope. It turned into a bit of a hobby. :)
For another project I want a scope user interface on the PC and thought the 1014D layout is suited for that purpose so I started programming. Then I thought "I might as well do the work for the actual scope too".
These projects do take time for sure, but as I wrote, it is a hobby.
-
Today I set up a simulator on the PC for the development and testing of the new firmware for the scope. I already had the emulator, but that uses the actual ARM based code for the scope and does not have support for the SD card and therefore does not help for the development anymore.
With the simulator the C code is compiled for running on the PC itself and makes debugging a lot easier. Already helped me with some of the problems I had while deleting files on the scope.
The file viewing is almost finished. Need to add some error handling when a file won't open or is no longer available. Since it is used for both pictures and wave forms, the latter is now also implemented to be accessed from the main menu.
It will most likely also fit the output capture file handling, but that is something new compared to the 1013D so needs looking into.
Still a long list to go through before everything is done.
-
Today I worked on some cleanup with replacing a lot of the same fixed values with global defines to make changing for instance the location of the trace window a lot easier and consistent. On the 1013D the position of the trace window is different and using the source code as a basis resulted in the traces to be in the wrong Y position due to not modifying a value in one location. With the global defines it now is tied together and can't cause this kind of problem anymore.
So not a lot of progress, but it will be more robust in the end.
-
Here is a first version that allows calibration and USB connection, making and viewing of picture and wave files.
Still a lot to implement like selection of the measurements, channel configuration and many other things. Also improvements in displaying the measurements to avoid flicker is needed, but it gives a first impression of what is to come. The traces also need re positioning to match the pointers because they are on the top instead of the center.
Feedback on problems found is welcomed, but only on already implemented stuff. No need for stating the obvious like "the generator is not working".
Edit: I forgot to mention that the settings are not yet stored, so base line calibration needs to be done on every startup to get it right. No need for it when just playing around with the controls.
-
Found a new FPGA command and its function used in the 1014D sampling code. Command 0x18 is used to read the trigger status and with this I can update the status on the display.
There is another command 0x29 that is written at the start of the sampling process with either 0 or 1 but I have to find out what this is used for. For the rest the sampling code looks the same.
Today I'm going to implement the brightness settings and see if I can get the other main menu options filled in.
My list with to do's is rather long and filled with things that needs checking or fixing, like the whole X-Y mode trace displaying that also needs to be re positioned due to the different origin of the trace window. And with every new thing implemented it seems to grow first as other issues come to light.
Ah well, one day it will be finished. :)
-
The brightness settings are working and I improved on the scale (grid) brightness setting such that it changes it in the background while adjusting, so you can see the result directly and only not after closing the menu to find out you need to change it some more.
Learned something about the compiler for ARM I'm using (arm-none-eabi-gcc) in the process. I was using char for the settings and assumed them to be signed. It works that way in my simulator, but on the actual scope the limiting on < 0 did not work as intended. So a bit of thinking and debugging was needed.
Turns out by default the compiler assumes char to be unsigned.
Tomorrow onto the next bit.
-
To keep things interesting for myself I started looking at the function generator that is build into the scope. With my emulator I captured what is written to the FPGA and it luckily is not to complex. Only three commands are used.
0x47 sets the length of the buffer used by the generator. Form reverse engineering the FPGA I know that the function generator uses 1KB of memory, so the max would be 1024, but what I have seen in the software is that it uses a max of 1000 samples.
0x48 is not fully clear yet. Either a 0 or a 1 is written to it, so a bit of testing is needed to see what it does.
0x46 is used to write the data to the buffer.
The max clock that the clock synthesizer generates seems to be 200MHz, which leads to 200KHz if the 1000 samples ares used and hold a single period of the signal. For a square wave the scope allows a max of 2MHz on the output, and to make this frequency the scope only uses 100 samples.
For the sine wave the maximum is 10MHz and yes for that the number of samples is reduced to 20. So it depends heavily on the output filter to make it a nice wave.
A bit more research is needed for the clock synthesizer as to how it needs to be programmed to make the needed frequencies. I also have to look into the other wave functions the generator uses. It seems to do calculations to make them, instead of using a wave table, so for that the code in the Ghidra archive needs to be studied more.
-
Now that I have more things working it turns out that using the 1013D code for the sampling is not as straight forward as thought.
While working well on the 1013D for determining the signals frequency it fails at it on the 1014D, even though the signal on the screen looks ok.
Checking the FPGA command trace on the emulator shows that it always uses the same value for writing to command 0x0D, which in the 1013D is used to set the sample rate. The command 0x0E values seem to be the same for as far as I checked, so it might be that this is used in the FPGA to also select the sample rate, and not just some setting for the time per division, like in the 1013D.
Looking at the trace data did show the usage of the new command 0x29. When written 0 it only reads from one ADC per channel, and when written 1 it reads both ADC's for each channel. The latter is only done for the 10ns/div setting.
So more experimenting is needed to get a properly working scope.
Edit: I added command 0x29 to the code and now it shows some stable frequency reading, only way off what it should be. 100KHz reads as 19.2Hz. :-DD
That does match with the trace shown on the screen. 10ms/div and ~5.2 divisions for a period. :palm:
Edit 2: Ahum, that is due to aliasing. When the time per division is set to 2us/div it shows the correct frequency, but the signal on the screen has a lot of artifacts, not seen on the 1013D.
Edit 3: It has been to long since the reversal of the 1013D. |O
I thought I had the special IC fully implemented in the 1013D emulator I wrote back then and used it with modifications for the user interface to make the emulator for the 1014D. But it turns out I did not do that and therefore the command 0x0D value it outputs to the FPGA trace file is not correct. Can't remember how I found the values for it when working on the 1013D, but need to do it again for the 1014D.
One thing I did notice, when looking through the code in Ghidra, is that the handling of the roll mode (long time base settings) is done differently. Just like when I did the 1013D, I'm going to skip that part.
Another thing is that the values used for command 0x0E are different except for the last one used for sampling at 200Msa/s. But these are easily copied from the code in Ghidra.
-
It is still a bit of a mystery as to why the distortion happens. |O
I have been doing al sorts of tests with the differences found between the 1013D and 1014D code on the part of the sampling but failed so far to get a proper result. On the 1013D the signal is nice and stable but on the 1014D all sorts of distortion comes in. I took some screen captures on the scope and these show the different shapes that pass by.
The first image looks good and is what also shows on the 1013D.
The second image shows some small ripple in the bottom half of the first period.
The third image shows a lot of distortion.
Also an issue is that the center of the signal is not on the correct location, even though the zero line calibration has been done and without a signal connected the line is on the center of the trace pointer.
This calls for a better scope brought in and do measurements on the ADC inputs to see what is going on. Luckily I have a couple that I can use for that.
An so a, what was supposed to be a simple straight forward, reverse engineering job becomes more of a trouble shooting job. :palm:
-
Sorry I cannot help with the testing as I have Rigol, but I literally shake might head in mild disbelief at the amount of work involved and time spent on your project, amazing.
Same here (Siglent), and I'm also really impressed and following progress.
-
Found the causes of the problems I'm seeing.
1) I forgot about the crappy input design, where they lift the ground level to 1.25V, and when the USB port is connected to the PC which is grounded to the same level as the signal source the signal center drops to -1.25V. :palm:
2) The power supply setup in the scope with the use of an external switching power supply is so crap that it does not reject it properly and that gives the distorted reading. I tested the scope with the battery pack of one of my 1013D scopes and it cleans the signal right up.
And that explains why the original firmware relies so heavy on the filtering they build in to the software.
This means that the code I have so far is working as intended, but to make use of it a much better power supply is needed for the scope. I have to mention that I'm not using the original power supply, because the scope came with a US style adapter. So can't rule out that the one I'm using is making it worse. Have to try with a couple of other ones I have lying around.
Now it is back to work my way through the to do list I have.
-
Still slaving away on this. My to do list just refuses to shrink. :-DD
Every time I add something new or think of an improvement I come up with a couple more things to check or change.
For instance the trigger level should be allowed outside the trace window, which on the original is not the case. So I modified that and added arrows to indicate where the trigger level pointer is.
That leads to the horizontal trigger position, which should also be allowed outside the trace window due to the fact that there are most often more samples there. So that's on the list.
At the moment some 32 items on the list that need to be looked at for either implementation or changing.
Attached is a screen capture of my simulator showing the trigger level arrow on the top side of the trace window.
-
First post. Kudos to you for the dedication and persistence.
Following the thread.
I have a couple of Ubuntu VMs and also WSL installed, and I have a FNIRSI 1014D for which I volunteer testing.
-
Another small update.
The to do list is still on 32 items to handle, even though I tackled quite a bit of them. |O
A first test release will come soon. Need to finish the X-Y mode on correct limits in positions and information, and add a save and restore of the normal mode channel positions.
A bit more work is in the thumbnail part that needs some work for the X-Y mode too, but also fixing the wrongs that arose from the trigger positions outside the visible trace window.
Hope to get that done tomorrow, with which there will be a testable version of the basic scope functionality.
No generator, FFT or roll mode.
-
Not fully done, but don't have the time to work on it for the rest of today, so no source release just yet, but a version to play with.
Instruction to load it on the SD card can be found earlier in the thread or in the thread about the 1013D or in the repository for the 1013D firmware.
Issues already found by me:
- After closing the item view screen (picture or waveform) there can be yellow lines on the left of the screen.
- Thumbnail pointer positions for XY mode are still missing and the trigger pointers can be in the wrong place when outside of the visible window.
- Not sure how, but the measurement items can be mixed up when going back and forth between the different modes. (XY, item viewing and normal)
If this one is found see if it can be replicated and report on it if so. - After USB connection is closed the sampling does not start until user input.
Have not checked this on the actual scope. - Measurements are very volatile and need filtering.
I have not tested this version on the scope with actual signals.
Well have fun playing with it.
-
Fixed some of the issues and made a new startup feature that allows a choice of firmware.
The startup menu mode can be activated by holding any other button when pushing the POWER button for starting the scope. With the F1, F2 or F3 buttons the wanted option can be activated. By default it will start in the new firmware. See the attached image for what the screen is showing when the startup menu is active.
Also made the repository public. https://github.com/pecostm32/FNIRSI_1014D_Firmware (https://github.com/pecostm32/FNIRSI_1014D_Firmware)
The project is going on hold for a while. Got other things I need to do.
-
Back on track after the bit of a f..up. :-DD
I copied the picture and wave file saving code from the 1013D and modified it to fit the differences with the 1014D, like only 6 measurements being displayed. The picture saving works fine and the images can be viewed on my Linux PC when connected via USB. The wave files are also there, but have no code to verify them. Has to be checked on the scope itself when the opening of the items has been implemented.
At the moment I'm working on that for the picture part, which can then also be used for the wave files. To make it look nicer than the original, and already more or less implemented on the 1013D, I made it look more like the real scope screen, as can be seen in the attached picture.
After that it is implementing the rest of the main menu items, the measurement menu, the channel settings menu, etc. Still lots of work to be done.
In firmware 1013d v0006, there was an error when displaying wave previews. I fixed it. Use the corrected code from the latest firmware versions
-
https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Test%20code/fnirsi_1013d_scope/dist/Debug/GNU_ARM-Linux/How_to_load_scope.txt
I used your latest source to get the different fixes you made. 8)
Also skipped some for later or as not relevant for the 1014D.
-
Found the causes of the problems I'm seeing.
1) I forgot about the crappy input design, where they lift the ground level to 1.25V, and when the USB port is connected to the PC which is grounded to the same level as the signal source the signal center drops to -1.25V. :palm:
2) The power supply setup in the scope with the use of an external switching power supply is so crap that it does not reject it properly and that gives the distorted reading. I tested the scope with the battery pack of one of my 1013D scopes and it cleans the signal right up.
I wrote about it.
https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg4802837/#msg4802837 (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg4802837/#msg4802837)
Complected power adapter is normal. Problem is inside of scope and I wrote how to resolve. Speech about "all clean with battery" is wrong.
-
I wrote about it.
https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg4802837/#msg4802837 (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg4802837/#msg4802837)
I know and have read that before since it was in the time that donwulff was looking into the scope firmware. But with getting older memory fades on details.
Complected power adapter is normal. Problem is inside of scope and I wrote how to resolve. Speech about "all clean with battery" is wrong.
The testing solely on battery did rid the interference I was seeing, so not wrong.
Crappy design of the whole front end, for sure, but with better power supply rejection, or running on a battery the noise is low enough for some use.
-
.... running on a battery the noise is low enough for some use.
Your power from battery only neutralizes the noise, which is removed by grounding the sockets (the zero is shifted, but that doesn't matter to me).
Is it really not clear that the interfering DC-DC do not have any blocking on the power circuits, which is found even in the cheapest pocket TV?
-
I'm a bit late to this but I have a 1014D I don't mind breaking - am looking into getting a new 'scope anyway.
It looks like a few weeks since any updates posted to this this thread but if you're still working on it, I'm prepared to have a go, I'm a long time user of Linux - Fedora, since FC3.
Can't help thinking this amount of effort might be better spent on something like the Hantek 2000 series. Apparently better hardware, apparently very buggy software.
-
I'm a bit late to this but I have a 1014D I don't mind breaking - am looking into getting a new 'scope anyway.
It looks like a few weeks since any updates posted to this this thread but if you're still working on it, I'm prepared to have a go, I'm a long time user of Linux - Fedora, since FC3.
Can't help thinking this amount of effort might be better spent on something like the Hantek 2000 series. Apparently better hardware, apparently very buggy software.
Hi RobtP and welcome to the forum.
I have put the project on hold after getting a basic part of the scope working. You can try it on your scope. The change of bricking it is near zero, because the new firmware is loaded onto the SD card, and can easily be deleted again or a simple replacement of the SD card brings it back to the original state.
And yes the Hantek 2000 series are better on both fronts, even though the software is a bit buggy. But the story is that I already did the 1013D, out of need to solve a problem with the touch panel, which has similar hardware to the 1014D so it was reasonably simple to tackle it. I also own a Hantek 2D10 and have reverse engineered the schematics of it. Maybe some day I might look into the FPGA and tackle the software when I feel like it. Depends on if my curiosity gets the upper hand. >:D
-
Can we have an sd image of your firmware to be uploaded on the sd via e.g. win32imager?
-
I'm a bit late to this but I have a 1014D I don't mind breaking - am looking into getting a new 'scope anyway. ....
...... Can't help thinking this amount of effort might be better spent on something like the Hantek 2000 series. ...
I would like to point out that all of these oscilloscopes are bad. Discussing the differences between them is like discussing the softness of toilet paper grades. However, 99% of the time their performance will be sufficient, so their main purpose is to be broken and thrown away instead of an expensive device, which at that moment is stored in a safe place.
-
Can we have an sd image of your firmware to be uploaded on the sd via e.g. win32imager?
Some member made a windows program to load the firmware on the SD card. You can find it in the thread about the 1013D (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/2275/#lastPost). You need to search for it though.
It takes the firmware file you can find here (https://github.com/pecostm32/FNIRSI_1014D_Firmware/blob/main/fnirsi_1014d_scope/dist/Debug/GNU_ARM-Linux/fnirsi_1014d.bin) and writes it to the SD card. It also supports for some settings like display position and touch panel orientation, but these are not implemented to be used on the 1014D. They won't cause problems being there.
-
Would you just rip your sd into an image?
-
Great! I'll have a go then. Didn't want to bother if you'd firmly decided not to pursue further.
-
Would you just rip your sd into an image?
The resulting image would be large and might not match with the SD card you have. Use the loader that you can find here (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4700534/#msg4700534). Read the posts following that one to get insight in how to use it.
-
Great! I'll have a go then. Didn't want to bother if you'd firmly decided not to pursue further.
With these projects it comes and goes, the itch to work on them. :-DD
To many hobbies and ideas and not always the drive to finish one of them. You know greener grass. :)
-
I broke the SD card "sd card can't read superblock". Presumably wrote the file to the wrong place or possibly unplugged the device while the card was still being written. Will try again.
While I was at it, I updated to the latest version of FNIRSI firmware I could find (20211006-v3.0-A-FSI-1014 - Happy to learn if anyone has anything newer!) by writing it to a new card and inserting that into the 1014D. It appears the device looks for a file called "FSI-1014.bin" and installs it. Now that I have it open anyway, is that a feasible method of trying new firmware - writing it to a new card as "FSI-1014.bin" and running it from there, then just swap cards to return to the official firmware? I suppose there might be a danger of bricking the device by putting it into a state where it wouldn't look for the new software?
-
The official firmware updates from FNIRSI write over the old one in FLASH. At startup the system checks if there is a file called "FSI-1014.bin" and if so checks if it is a valid update based on some check values at the end of the file. If these check out the new firmware is written to the FLASH memory. I think you do have the latest one. It is the last one I have here too.
To cater for the different LCD versions out in the field they supply two versions of the new firmware. You will know that you have the wrong one when the display is shifted some 5mm or so. This functionality is not (yet) available in the open source firmware, but can easily be added as a configuration file. Have done the same for the 1013D.
When the FLASH gets corrupted somehow it is always possible to restore it with the use of the SD card and some dedicated to be written code. >:D
To see if your original SD card is indeed broken try to format it with GPARTED. Make sure to select FAT32 and leave at least 1MB free at the start of the card.
-
I did actually try to open it with Gparted. Didn't immediately work but didn't try very hard, had other things to do. Shouldn't have bothered, had a day of minor failures. That, broke a tea bag making a cuppa, forgot detergent in the washing machine, spent 90 minutes trying to get a v1.3 camera to work with an Rpi zero only to realise the little camera module wasn't clicked in place on the PCB properly :-//
-
I did actually try to open it with Gparted. Didn't immediately work but didn't try very hard, had other things to do. Shouldn't have bothered, had a day of minor failures. That, broke a tea bag making a cuppa, forgot detergent in the washing machine, spent 90 minutes trying to get a v1.3 camera to work with an Rpi zero only to realise the little camera module wasn't clicked in place on the PCB properly :-//
Ah one of those days. Think we all have them from time to time. Better luck next time then.
-
I recently purchased a Fnirsi 1040d and I need to ask the users of this instrument if it is normal that the trigger does not activate when setting times greater than 10msec in Normal and Single mode?
Is it a limitation of the instrument or am I not using it correctly?
Thanks everyone!
-
Hi motomanual,
welcome to the forum.
When asking a question please only do so in a single thread. (Same question is asked in this thread (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg5597057/#msg5597057))
The original firmware indeed has this limitation. You may want to try out the open source firmware I wrote for it. You can find more information on it in this thread.
It is far from finished, but it does trigger on all the available time base setting it has available. The slowest setting is 200ms which has a slow refresh rate since it needs to gather the 3000 samples in the sample buffer. The original firmware uses roll mode for that setting, which is not supported in the open source firmware, at least not yet.
No idea when and if it ever will be finished though.
-
Thanks for the quick answer, I apologize for the double thread but I couldn't identify the most appropriate one for the topic.
I will try the suggested open source firmware version, hoping you will continue to develop it because the original version seems to have many problems besides the trigger...
-
Hi all
can any one please help me.
I read first post about the firmware is FNIRSI-1014D and I don't know what tempted me to download the file you provided “fnirsi_1014d_V_A0.002.bin.txt” and rename it to “FSI-1014.bin” and upload it to my 1014D
Now the oscilloscope stands on a black screen after startup and I can't do anything.
I thin I bricked my device :(
Is there any chance to upload the firmware again?
Please help
-
I read first post about the firmware is FNIRSI-1014D and I don't know what tempted me to download the file you provided “fnirsi_1014d_V_A0.002.bin.txt” and rename it to “FSI-1014.bin” and upload it to my 1014D
Now the oscilloscope stands on a black screen after startup and I can't do anything.
I thin I bricked my device :(
It won't be bricked, so no worries about that.
My guess is that you wrote the FSI-1014.bin file to the SD card via the USB connection of the original firmware. On startup it then sees the file and think it is new firmware for the FLASH and it nulls the first program sector of the FLASH. Not being actual new firmware for the FLASH it can't startup again.
Now you will need a screw driver and open up the scope. Take out the SD card and put it in a suitable card reader/writer connected to the PC. Delete the FSI-1014.bin file and replace it with a proper one. I noticed that the official FNIRSI site no longer has the firmware for the 1014D available, so try the one I found here: https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg3739810/#msg3739810 (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/msg3739810/#msg3739810)
If that does not bring it back there are other ways to resurrect your scope. Procedures are to be found in the threads about the 1013D and 1014D:
https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/ (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/)
https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/ (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/)
If you want to try the new firmware I wrote, best read this thread first on how to install it.
-
thanks for your quick reply
that's what I meant
now my oscilloscope came to life again :)
thanks again
-
A member wrote me a personal message with the request for some information about the development of the software for the 1014D as they want to join in. I answer the questions below so others might find it beneficial.
- Can you give me a brief about the the current state.
The development state is where I left of in this thread. Only the basic scope functionality is implemented, but hardly tested. It is based on the development done for the 1013D, but rewritten to fit the 1014D user interface. It does give a good starting point for further development. - What loads the fw from SD.
This is basic functionality of the F1C100s. There is code in ROM that scans for a valid bootloader. It checks the SD card before it heads on to the SPI connected FLASH memory. By having a signature header in the first 32 bytes of sector 16 of the SD card, the code knows that it needs to load the program from the SD card. This bootloader then initializes the DRAM within the F1C100s and other hardware needed for running the main program, before loading the actual firmware to the internal memory. It also allows for starting the original firmware or the FEL mode. - Why 16meg.
I assume 16GB is meant as size for the SD card. This is not mandatory. It works with different sizes of SD cards, as long as there is enough free space before the FAT partition. 1MB is sufficient. There is an issue with detecting the card speed though, as can be read in this thread. - Does the firmware backup file work on the 1014D.
Yes there is a version made for backing up the original 1014D firmware. It can be found here (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Test%20code/fnirsi_1014d_firmware_backup). - Does it back up the FPGA.
No, because this is not possible with the way they implemented it. The FPGA is loaded from a separate FLASH chip and there is no way for the processor to read from that FLASH. - Does it backup the full flash or a set range?
The code creates two files. One is a backup of the full FLASH and the other is just of the firmware section of the FLASH. Have not tried it, but I think it is possible to use it in the way a normal firmware upgrade is done on the 1014D.
The message I received stated the below.
I'd like to start with the function gen and a bode plot to get more helpers and support.
Thanks for the hard work you've been putting into this. It opened doors that I couldn't even imagine.
The latest version of the code is in the repository found here (https://github.com/pecostm32/FNIRSI_1014D_Firmware).
For the function generator it is necessary to implement the controlling of the clock synthesizer chip. The code so far only initializes it for the needed FPGA main clock and sets the function generator clock to its max of 200MHz. See "clock_synthesizer.c" for more on this.
The function generator is made with a lookup table in the FPGA and the step through is based on the frequency set with the clock synthesizer. I will have to consult my notes on my other system to provide more information on this.
My advice is to fist look into the code in the repository and play with it a bit. For easy testing the FEL mode can be used to load the new code to the internal memory via USB causing less wear on the SD card. Scan the thread about the 1013D (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3420026/#msg3420026) to find more information about this.
-
Hello everyone, I swapped the F1C100s for a F1C200s on a broken 1014d (ordered the wrong one :D), but the USB doesn't work. I see in the data sheets that there are differences, is there a solution to get the USB to work?
-
.... but the USB doesn't work. ....
If it makes you feel better, my USB has never worked since I bought 1014d.
I take screenshots like this:
-
.... but the USB doesn't work. ....
If it makes you feel better, my USB has never worked since I bought 1014d.
I take screenshots like this:
Not really, it worked normally. :) There is no 5V on the USB port, no USB sticks work, there is only a connection to a PC. In an emergency, i install a micro SD card extension.
-
Hello everyone, I swapped the F1C100s for a F1C200s on a broken 1014d (ordered the wrong one :D), but the USB doesn't work. I see in the data sheets that there are differences, is there a solution to get the USB to work?
If I recall correctly, there was a 1014D out there that had the F1C200s factory installed. For as far as I know the only difference between the two is the DRAM size, but have not looked at it that close.
Check the "main" thread about the 1014D on this: https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/ (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/) Or see on the FNIRSI download page if there is a dedicated firmware version for it. They have different versions for the models with different LCD panels, so maybe also for the F1C200s.
-
If I recall correctly, there was a 1014D out there that had the F1C200s factory installed. For as far as I know the only difference between the two is the DRAM size, but have not looked at it that close.
There seem to be a few more differences.
Check the "main" thread about the 1014D on this: https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/ (https://www.eevblog.com/forum/testgear/new-bench-scope-fnirsi-1014d-7-1gsas/) Or see on the FNIRSI download page if there is a dedicated firmware version for it. They have different versions for the models with different LCD panels, so maybe also for the F1C200s.
That would be great, ok, I'll take a look. THX
I definitely need to back up the FPGA memory (EF2L45L)
-
.... it worked normally. .... there is only a connection to a PC. ...
The connection picture is present, but on the computer either "insert the disk into the drive" or disk io error.
-
I definitely need to back up the FPGA memory (EF2L45L)
You will need a JTAG interface for that. Look at this post for more information: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5668099/?topicseen#msg5668099 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5668099/?topicseen#msg5668099)
-
Hello everyone, I swapped the F1C100s for a F1C200s on a broken 1014d (ordered the wrong one :D), but the USB doesn't work. I see in the data sheets that there are differences, is there a solution to get the USB to work?
Where did you get the datasheets from that show these differences?
When I did the reverse engineering of the 1013D (the knobless version) I found no proper programming information about the USB interface and used code samples I found to determine what was what and got it working on the F1C100s. Part of the samples came from the Linux tree that floats around for the F1C100s. The documents I found are in my repository here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Manuals (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Manuals)
I noticed that you also have a Hantek DSO2xxx and have played with the linux of it a bit. The sources for the Linux used in it are available (DavidAlfa has them) and you might be able to see if it actually needs different code for the USB interface.
-
.... it worked normally. .... there is only a connection to a PC. ...
The connection picture is present, but on the computer either "insert the disk into the drive" or disk io error.
Ok, it worked for me, it was recognized as a data carrier and now with the F1C200s the device is not recognized.
I definitely need to back up the FPGA memory (EF2L45L)
You will need a JTAG interface for that. Look at this post for more information: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5668099/?topicseen#msg5668099 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg5668099/?topicseen#msg5668099)
I'll have to take a closer look at this, the available circuit diagram doesn't quite work for me. But I still have to take care of the power supply first anyway, the TPS61041 has also given up, I've already replaced most of the rest.
Where did you get the datasheets from that show these differences?
When I did the reverse engineering of the 1013D (the knobless version) I found no proper programming information about the USB interface and used code samples I found to determine what was what and got it working on the F1C100s. Part of the samples came from the Linux tree that floats around for the F1C100s. The documents I found are in my repository here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Manuals (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Manuals)
I noticed that you also have a Hantek DSO2xxx and have played with the linux of it a bit. The sources for the Linux used in it are available (DavidAlfa has them) and you might be able to see if it actually needs different code for the USB interface.
I only have the normal datasheets, F1C200s V1.1, V1.2 and F1C100s V1.0.
Yes, I also have the Hantek :D Unfortunately I'm not that good at code, but I'll take a look.
With the FNIRSI I will probably just install an SD extension so that I can access it from the outside.
-
Just for the record, I have the datasheet for the chip, but it's in chinese.
-
.... it worked normally. .... there is only a connection to a PC. ...
The connection picture is present, but on the computer either "insert the disk into the drive" or disk io error.
Ok, it worked for me, it was recognized as a data carrier and now with the F1C200s the device is not recognized.
....
I didn't bother to figure out the reasons, having checked only the cable. However, now I can assume that this is a defect of the chip itself. I saw such a defect on counterfeit stm32f407, out of 4, one of them didn't have a working USB (HS module).
-
.... it worked normally. .... there is only a connection to a PC. ...
The connection picture is present, but on the computer either "insert the disk into the drive" or disk io error.
Ok, it worked for me, it was recognized as a data carrier and now with the F1C200s the device is not recognized.
....
I didn't bother to figure out the reasons, having checked only the cable. However, now I can assume that this is a defect of the chip itself. I saw such a defect on counterfeit stm32f407, out of 4, one of them didn't have a working USB (HS module).
-
Just for the record, I have the datasheet for the chip, but it's in chinese.
The English version is attached here.
-
Ok, it worked for me, it was recognized as a data carrier and now with the F1C200s the device is not recognized.
Did you check the signals on the USB connector and the F1C200s. It just might be a hardware problem.
As mentioned before, I remember to have read that they have the same core and peripherals and the only difference it the DRAM size.
A bit of search provided this: https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/ (https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/)
-
Ok, it worked for me, it was recognized as a data carrier and now with the F1C200s the device is not recognized.
Did you check the signals on the USB connector and the F1C200s. It just might be a hardware problem.
As mentioned before, I remember to have read that they have the same core and peripherals and the only difference it the DRAM size.
A bit of search provided this: https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/ (https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/)
I checked it again with a different USB connector and cable, but for whatever reason it doesn't work. Well, not that important.
The JTAG programmer seems to be working so far, a quick guide on how to save the flash without deleting the old content or something like that would be very helpful. :D
-
The JTAG programmer seems to be working so far, a quick guide on how to save the flash without deleting the old content or something like that would be very helpful. :D
I have only used the IDE to load the configuration to an AL3-10 FPGA to test. Can't recall (aging sucks) if I also wrote the external FLASH of my test board with it. (Not the scopes for sure)
The IDE should allow you to both read and write the one you have, if there is no protection used of course.
I have no experience with the ELF2, but I assume you can load a bitstream to the memory of the FPGA without flashing it, just to test if a configuration is working.
You can try the firmware I made, and if the scope itself is working with it, you can assume the configuration in the ELF2 is the same crappy design as in the AL3-10. Although not completely finished I did reverse engineer that part too.
-
The JTAG programmer seems to be working so far, a quick guide on how to save the flash without deleting the old content or something like that would be very helpful. :D
I have only used the IDE to load the configuration to an AL3-10 FPGA to test. Can't recall (aging sucks) if I also wrote the external FLASH of my test board with it. (Not the scopes for sure)
The IDE should allow you to both read and write the one you have, if there is no protection used of course.
I have no experience with the ELF2, but I assume you can load a bitstream to the memory of the FPGA without flashing it, just to test if a configuration is working.
You can try the firmware I made, and if the scope itself is working with it, you can assume the configuration in the ELF2 is the same crappy design as in the AL3-10. Although not completely finished I did reverse engineer that part too.
I'll leave it for now, I'm glad the scope is working again. I took a look and apparently you can't get the chip, otherwise you could order one for experiments. The IDE, I don't know exactly how to use it either, the instructions are in chinese.
Of course it could be good that the flash is protected anyway, they always do that normally.
-
You can get the chip on Aliexpress.
https://nl.aliexpress.com/w/wholesale-EF2L45LG144B.html?spm=a2g0o.productlist.search.0 (https://nl.aliexpress.com/w/wholesale-EF2L45LG144B.html?spm=a2g0o.productlist.search.0)
Also a development board is available: https://nl.aliexpress.com/item/1005007199557737.html (https://nl.aliexpress.com/item/1005007199557737.html)
-
Now with external SD card and working function generator. Not pretty but rare. :D Everything works again, except the USB.
-
Now with external SD card and working function generator. Not pretty but rare. :D Everything works again, except the USB.
Just today I received a F1C200s from Aliexpress to try and repair a broken FNIRSI 1013D. Soldering QFN is not my forte, but this third try I succeeded. It did not solve the original problem with inverted colors on the display, but I can assure now that the USB on the F1C200s is exactly the same as on the F1C100s. My 1013D with the F1C200s connects without problems to my computer and I can open image files on it.
So you might want to check the traces and solder connections for the USB path on your scope.
For first attempt with a F1C100s see here: https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311)
For the second attempt also with a F1C100s see here: https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317 (https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317)
-
Now with external SD card and working function generator. Not pretty but rare. :D Everything works again, except the USB.
Just today I received a F1C200s from Aliexpress to try and repair a broken FNIRSI 1013D. Soldering QFN is not my forte, but this third try I succeeded. It did not solve the original problem with inverted colors on the display, but I can assure now that the USB on the F1C200s is exactly the same as on the F1C100s. My 1013D with the F1C200s connects without problems to my computer and I can open image files on it.
So you might want to check the traces and solder connections for the USB path on your scope.
For first attempt with a F1C100s see here: https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311)
For the second attempt also with a F1C100s see here: https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317 (https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317)
Oh very interesting, thanks for the information. The device had a 230V accident with the USB plugged in. I checked everything several times, but there must still be an error somewhere. It wasn't really easy to solder, it's no fun. ;)
-
Now with external SD card and working function generator. Not pretty but rare. :D Everything works again, except the USB.
Just today I received a F1C200s from Aliexpress to try and repair a broken FNIRSI 1013D. Soldering QFN is not my forte, but this third try I succeeded. It did not solve the original problem with inverted colors on the display, but I can assure now that the USB on the F1C200s is exactly the same as on the F1C100s. My 1013D with the F1C200s connects without problems to my computer and I can open image files on it.
So you might want to check the traces and solder connections for the USB path on your scope.
For first attempt with a F1C100s see here: https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-as-much-use-as-a-chocolate-fireguard/msg4652311/#msg4652311)
For the second attempt also with a F1C100s see here: https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317 (https://www.eevblog.com/forum/microcontrollers/f1c100s-dram-problems/msg5741317/#msg5741317)
I modified the power supply for the display slightly, the negative voltage was too high.
-
I modified the power supply for the display slightly, the negative voltage was too high.
Thanks, I'm planning on checking every voltage to the display and if needed verify the signals with a logic analyzer to try and solve the problem.
For as far as I know the scope has worked normally for quite a while and started to show problems like the inverted colors and random restarts. The owner checked the voltages and found nothing wrong. Based on that I thought the problem to be the MCU, but clearly I was wrong, unless this new one has the same fault. :-DD
-
on the software filtering of power supply...
I wonder if that is why the scope is less sensitive than others, because of the filtering... I just bought one for $50"untested" we will see...
-
on the software filtering of power supply...
I wonder if that is why the scope is less sensitive than others, because of the filtering... I just bought one for $50"untested" we will see...
The sensitivity is defined by the hardware, not the filtering in the software.
The filtering in the software removes noise and makes the signal look nice, but through this lacks reality. The suppression of power supply noise should have been done in the hardware, avoiding it making it into the signal path.
The two FNIRSI scopes I know of (1013D and 1014D) are cheap crappy designs, but for 50 bucks you got yourself something fun to play with.
-
I looked through all of the schematics, I bought one of these($50), and it is likely broken (wrong power supply). I was wondering if you would know the backlight voltage?, if I need to remove the inverter IC, can I just provide a DC voltage to power the backlight for further testing?
-
The backlight works with current limiting. If you have a lab power supply that allows you to set the max current, turn it down to 20mA to start with. Voltage can be set to 10V or so. Check to see if there is some light coming from the LED and monitor the current flowing. Increasing the current will increase the brightness.
-
i also have a damage 1014d backlight driver, what i did is that i used buck-up converter and set the voltage to 7.4v and the backlight works, but the brightness controll on the software dont work. but at least the device is working again. hehehe
-
use a buck converter, mine works fine setting to 7.4v. cheers
-
Sorry I missed the replies, this forum works a little differently, and does not notify by default, fixed it! I received the replacements for the 2 bad chips (PHOI, and BIIG8) and the scope is working except for the function generator. Is there an amplifier, or buffer between the FPGA and the BNC electronics? Can you tell me what pin on the FPGA has the output of the function generator.
I know this is a basic scope, but it will work fine for my needs, I also have a messed up TEK TDS2012, which has a display issue, a much better scope, after it is fixed.
-
The schematic for the DAC part is here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_ADC_DAC.png (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_ADC_DAC.png)
It uses a RS8751 opamp to buffer the signal.
On the FPGA there are 8 outputs used to make the signal. The DAC is a R/2R based one.
See the schematic here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_Data_Acquisition.png (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_Data_Acquisition.png)
-
So this is the buffer, The generator is always running correct? so I should see data on all of the data resistors? Is there any feedback, like if the opamp is dead, would that shut down the data? Is thete a separate power supply for the generator that could have failed, and the rest of the scope still work properly?
-
I don't know if the generator is always running. I don't use the scope. >:D
But for what I recall is that the memory in the FPGA, dedicated to the generator, has to be loaded with data for it to work. Also is it clocked by a separate clock input on the FPGA. The clock synthesizer in the scope provides two clock signals to the FPGA. One is 50MHz used for the sampling of the scope signals and the other is a variable clock running up to 200MHz to control the stepping through the generator memory.
So push the generator button and select a sine wave for the output. If everything is running you should see data on the DAC signals.
You can measure the supply voltage of the opamp. Everything you need to know about this can be found in the schematics I made.
-
So, as far as I can tell, the RS8751 is shorted on, I ordered some, back when they get here. I don;t see how this could be damaged by the over-volted power supply, as the previous circuitry failed shorted low, but as I may be the 3rd owner, the function generator is maybe what started the problems, I think it may have been returned, because someone killed the function generator, and the person i bought it from, burned out the other chips putting 20v into the power jack. Being a cheap and simple scope, there is a bright side in that it is easy to repair, and get parts for, thanks to your research. Thanks, Scott
-
Replaced the 8751 chip, Now the signal generator is working, so everything is working. I think I am finished. The signal generator is always running.
-
Sorry to bother you all, but since your knowledge of this scope components in this post is miles ahead of what I could possibly achieve, I was wandering if any of you could help me with the repair of a 1014d fnirsi oscilloscope that could be my first oscilloscope if i succeed in repairing it.
I opened it up and found some burnt resistors and shorted capacitors near the channel 1 socket, as well as a burnt PT4103 step up converter in the power supply section of the motherboard.
It could have been an easy repair if those were the only broken things, but that's not the whole story. Continuing with diagnostic I've found shorted to ground capacitors near the FPGA, the GD32E230 micro controller and the F1C100S cpu(voltage injection on those caps and a thermal camera confirmed these ICs are all faulty as well).
I kindly ask if anyone could help me understand if the chips can be replaced or they need to be programmed first (I see some flash memory soldered on the board and i guess it will suffice) and how can I program them if needed/possible.
I just found out the microsd shorted out as well, measuring vdd and ground pin on it give me about 3 ohm so, if it possible to repair the oscilloscope, I also got to reflash the firmware on a new sd card. I wander what could have caused it all.
-
I can't help with the chips, but 3 common issues that kill these things, are the wrong power adapter,(needs 5v) a short of the probe ground to the grounded device being tested's power rail, a short from one probes ground through the other probes ground through power. From what I have read, the FPGA is programmed with no way for us to program it, there is also encryption , but I am not sure it is being used. with all that damage, I think it is too far gone. The Sd card image is available, I believe some people have replaced the MCU, but there were issues with broken functions in the FPGA.
Since most of the parts are connected in parallel, try removing shorted power supply parts first. I read a lot of shorted parts, until I removed the bad power supply chips in mine, then many shorted readings disappeared. The blown trace appears to be the ground of channel 1
-
Thank you for your reply, i tried first to remove the burnt trace and power supply component, unfortunately measuring coils and other things in the psu section individually has not lead me to believe I could resolve the whole shorted capacitors around those chips situation.
I inspected every shorted caps injecting 0.6v 1a and a thermal camera, I could see how this 3 main ICs were internally faulty. Furthermore, removing them and the sd card seems to have cleared all the caps on the board from being shorted to ground. Anyway I really appreciate your help, I guess it is now destined to the scrapboard pile, i was just wandering if the fpga/cpu/mcu could have its instructions secured on the external flash memory chip i see on board so that replacing them could be possible. Oh well, it is what it is
-
I purchased mine broken for $50, and the seller told me he tried a 20vdc power supply on the 5v power input, I thought it would only take out the PS parts, but the signal generator ended up being dead also, likely from a separate incident, from the original buyer. These are poorly protected, and are limited bandwidth (30mhz), really only hobby grade, and easily damaged. I'm sure more cheap dead ones will pop up on e-bay for parts in the future. There are lots of videos and info to repair them.
-
As I don't visit the forum as much lately, I just now read about this broken 1014D scope.
@nht7 Not sure if you found the schematics I made, but these are for a version with the Anlogic AL3-10 FPGA, and I think yours is using a different FPGA with internal FLASH.
But for good measure here is a link to the schematics. https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics/1014D (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics/1014D)
The firmware for the GD32E230 is available, because there was no read protection on it in my scope. The FPGA is a different matter, but the programming for the AL3-10 version used in the 1013D scope has been reverse engineered and can easily be adapted for the 1014D when one switches to the open source firmware, which is not finished, but it gives basic scope functionality.
It depends a bit on how much energy you are willing to put into reviving this thing, but it might not be worth it.
-
to the autor or anyone that used this version, does it increase the vertical range? like going to 10mV/div
or does it need to change the fpga code itself to achieve it
-
Seem to remember that 100mV/div is a hardware limitation.
-
Yes the vertical range is limited by hardware and would need more than a change of the FPGA code.
If my recollection is correct tunk is right on that the limit is 100mV/div. To achieve the 50mv/div they advertise with the values are multiplied in software, which is just a digital zoom as such.
The input hardware is the same as used in the 1013D version of this scope and reverse engineered schematics can be found in my github repository. https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics) Note that capacitor values are not measured and in the 1014D version of the schematics also not mentioned. In the 1013D version they are listed but most likely not correct.
-
Thank you for your reply, i tried first to remove the burnt trace and power supply component, unfortunately measuring coils and other things in the psu section individually has not lead me to believe I could resolve the whole shorted capacitors around those chips situation.
I inspected every shorted caps injecting 0.6v 1a and a thermal camera, I could see how this 3 main ICs were internally faulty. Furthermore, removing them and the sd card seems to have cleared all the caps on the board from being shorted to ground. Anyway I really appreciate your help, I guess it is now destined to the scrapboard pile, i was just wandering if the fpga/cpu/mcu could have its instructions secured on the external flash memory chip i see on board so that replacing them could be possible. Oh well, it is what it is
Ef2l45 in the 1013D oscilloscope was able to be loaded, it was not locked. And it was also possible to write the content again. So try loading the content. In the worst case, it would be possible to write the content from the 1013D to the fpga if the pins are seated, the oscilloscope would work but without a signal generator
-
Hello again, after a long wait for aliexpress to ship the components, I've finally taken the time to change what was causing the short on my 1014d. When connected to the power the oscilloscope turns on a faint backlight and does nothing, if I press the power on button the backlight becomes a bit weaker but nothing changes. At this point I was reading in the forum about programming the GD32E230 because it controls the power circuitry but firmware flashing, uart and programming I think are all above my current knowledge level and it's confusing me all the more, even the sd firmware loading part I've not fully understood yet. I guess I'll give up this fight, for now. :-[