Reverse engineering the FNIRSI 1014D

[pcprogrammer]

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

The project is going on hold for a while. Got other things I need to do.

[Atlan]

Back on track after the bit of a f..up. 

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

[pcprogrammer]

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. 

Also skipped some for later or as not relevant for the 1014D.

[Postal2]

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. 

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
Complected power adapter is normal. Problem is inside of scope and I wrote how to resolve. Speech about "all clean with battery" is wrong.

[pcprogrammer]

I wrote about it.
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.

[Postal2]

.... 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?

[RobtP]

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.

[pcprogrammer]

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. 

[NoNickName]

Can we have an sd image of your firmware to be uploaded on the sd via e.g. win32imager?

[Postal2]

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.

[pcprogrammer]

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. You need to search for it though.

It takes the firmware file you can find here 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.

[NoNickName]

Would you just rip your sd into an image?

[RobtP]

Great! I'll have a go then. Didn't want to bother if you'd firmly decided not to pursue further.

[pcprogrammer]

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. Read the posts following that one to get insight in how to use it.

[pcprogrammer]

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. 

To many hobbies and ideas and not always the drive to finish one of them. You know greener grass. 

[RobtP]

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?

[pcprogrammer]

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. 

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.

[RobtP]

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 

[pcprogrammer]

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.

[motomanual]

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!

[pcprogrammer]

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)

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.

[motomanual]

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...