Author Topic: FNIRSI-1013D "100MHz" tablet oscilloscope  (Read 379333 times)

tokar, boojum and 9 Guests are viewing this topic.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1175 on: November 23, 2021, 09:33:07 am »
Hi Maurits,

thanks for the feedback. I will rework the menu based on it.

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

This is good to hear. Did you have any problems with the SD card format, or did the partition already start on a high enough sector?

And why not use the correct lowercase 's' for seconds in the 'Time per Division' choices block?

The capitol S is in the original and I just copied that as is :-DD Already changed it in the source :-+

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

I'm working on determining this at the moment. Making a spread sheet with all the possible sample rates and time per division settings to determine what is useful. For instance, when using the highest sample rate and 5us/div there are not enough samples for a full screen. Only 21% of the screen can be filled. The question is if this has any use and if it is better to limit the settings to only 1us/div on which it has enough samples for a full screen?

This boundary shifts with the lowering of the sample rate. At a certain point it makes not a lot of sense to switch to the smaller time per division settings. It will only be a straight line from one side of the screen to the other.

Something to think about. Input is welcome :)

The math is not difficult when floating point is used. As the MCU does not support it, no floating point co-processor, I like to avoid this so have to work it into fixed point math.

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.

This is something for later on the list. Like to get trace display working as is first. Have been thinking about it though.

Hope to get something working today

Offline morris6

  • Regular Contributor
  • *
  • Posts: 81
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1176 on: November 23, 2021, 12:15:23 pm »

Did you have any problems with the SD card format, or did the partition already start on a high enough sector?


The smallest micro SD the local 'Expert' shop has available was 16GB. I dd'ed your test firmware on it and copied the standard files as well. Swapped the card with the original (8GB) one in the box. It simply worked!! I did not do any re-partitioning.

I'm working on determining this at the moment. Making a spread sheet with all the possible sample rates and time per division settings to determine what is useful. For instance, when using the highest sample rate and 5us/div there are not enough samples for a full screen. Only 21% of the screen can be filled. The question is if this has any use and if it is better to limit the settings to only 1us/div on which it has enough samples for a full screen?

This boundary shifts with the lowering of the sample rate. At a certain point it makes not a lot of sense to switch to the smaller time per division settings. It will only be a straight line from one side of the screen to the other.

Something to think about. Input is welcome :)

Some kicking in open doors(Dutch expression): At a rate of 200MSa/s maximum there is a sample available every 5ns. With memory length 3000 bytes that fills in 15us. The screen uses about 50 pixels per division. When using two samples per pixel this would represent 500ns/div and 30 (-15 to + 15 as seen from the mid trigger point) screen divisions. For slower timings the sample rate must be decreased, potentially giving longer (time) record length. For faster timings less samples per division are available. Going further down in time per division equivalent time sampling for repetitive signals has to be used to get a meaningful result. Maybe processing the results of several acquisitions in a frame buffer. Sounds easy but what about triggering?

As it is with the original firmware isn't the box trying to use equivalent time sampling at the shorter times per division to make the claim for 1GSa/s? As it looks to me when observing the behavior it looks more like the box is generating its own signal synchronizing it with incoming samples and so avoiding the trigger issue.

For now you are aiming to get straight forward real-time sampling going. I'll be happy to try-out any further results of your work.

Regards,
Maurits
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1177 on: November 23, 2021, 12:46:05 pm »
Quote
Some kicking in open doors(Dutch expression):

I'm Dutch so understood :-DD

Don't think the original box does actual equivalent time sampling. Way to complex for them, since they can't even interleave the samples of the two ADC's per channel in the FPGA.
They went out of there way to make a "smooth" product, but in doing so made it basically crap. It looks nice, but it is so full of rubbish, like actually generating a sine signal based on the measured min, max voltage and the frequency. To make it special they throw in the timerticks % 3.

The rest of the code is so full of memcpy from one buffer to another for who knows what. This is where I left of. Could not take it anymore.

The triggering is also an issue. For the 10ns - 10ms/div it is done in the FPGA, but there is no feedback about where in the sample buffer the trigger is. The software looks at 10 samples in the middle of the buffer to see if there is a trigger there. If not then I don't know. Have to see how it is going to work with what I'm making now.

Trying to make it work over the complete range of settings, which means only one sample on the screen for a lot of settings, or the ability to scroll through then when more available. Choose this setup to allow for variable zoom later on.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1178 on: November 23, 2021, 12:52:49 pm »
Did you have any problems with the SD card format, or did the partition already start on a high enough sector?

The smallest micro SD the local 'Expert' shop has available was 16GB. I dd'ed your test firmware on it and copied the standard files as well. Swapped the card with the original (8GB) one in the box. It simply worked!! I did not do any re-partitioning.

Ah you went down the opening the box route :)

It is possible to get it done without opening it up. Just use the scope as the card interface via it's USB connection. Tried that on both my scopes without problems. (After the first failures that is :-DD)

Received the last SD cards yesterday. Did not test these with the scope yet, but will be interesting to see if the 8GB cards I ordered are going to work. The PC shows them as 250GB cards, and I was able to write to them, at least some 300MB files. :-DD

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1179 on: November 23, 2021, 06:03:22 pm »
Managed to get something working. I checked out how to use soft floating point and tried it in my code. It works and the speed is very good. Dropped a lot of unneeded code, but need to improve and finish what I made so far. Is just an early proof of concept :-DD

Based on the sample rate and the time per div the signal is scaled on the fly. No separate routine with copying and interpolating. The interpolation is done by the display draw line function :) Just a straight line between the two sample points.

Made another video of how it looks now. Again not great quality, but it shows what is needed.

https://youtu.be/88QXE-WfLAo

Still need to add the trigger point location and correct display location of it based on the top trigger pointer and lots of other stuff to finish it, but it is a step in the right direction.
« Last Edit: November 23, 2021, 06:11:11 pm by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1180 on: November 24, 2021, 06:19:09 pm »
Making progress. Cleaned up quite a bit and added the second channel acquisition.

Unfortunately it is still very unstable in the triggering. Did add code to detect the trigger point, which looks to be working when debugged on the computer. Also when there are few samples to work with it does get pointy, so the displaying algorithm needs improvement.

Need to do a bit more cleanup on the code I wrote today to, at least, get rid of my work comments. :-DD Tend to add a lot of stuff like "I need to add a bit here and this needs to be changed", during development.

With this new acquisition and displaying setup, the save and view picture or waveform code needs to be rewritten. Was not pleased with it anyway, so not a big deal, but it takes a bit of time.

In the attached pictures, channel 1 (yellow) has a 10MHz sine at the input, where channel 2 (cyan) has a 20MHz sine at the input. The second picture shows the traces shifted to the right, to show the trigger position setting is working :)

Offline ledtester

  • Super Contributor
  • ***
  • Posts: 3032
  • Country: us
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1181 on: November 24, 2021, 06:50:06 pm »
Regarding the display algorithm... I know that pro scopes use "sin x/x" interpolation (but that's about all I know!):

https://edadocs.software.keysight.com/kkbopen/how-does-sin-x-x-sinc-interpolation-work-616372293.html

so maybe that's something to look into.
 
The following users thanked this post: pcprogrammer

Offline morris6

  • Regular Contributor
  • *
  • Posts: 81
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1182 on: November 24, 2021, 09:09:55 pm »
@pcprogrammer: Concerning the trigger point I have a question about your pictures. I can't see the trigger level setting working. The trigger setup is channel 1, falling edge. The level of the falling edge of the signal in channel 1 right below indicator 'H' is not equal to the selected trigger level at indicator 'T'. So I presume triggering is not working yet?
In the second picture the whole signal pattern is shifted right, together with indicator 'H'. OK, was that what you wanted to show? But I think that the horizontal position of the trigger point has no relation with the trigger setting. It simply shifts the 'picture' left and right, as observed with my box:

What follows here is my -speculative- view of how triggering is working. It appears that the trigger point is always at the center of the processed data. After a single capture when you select a slower time base it shows that the total initial capture was equivalent to 30 divisions length. The trigger point is always in the middle of the capture, irrespective the trigger setting, level or horizontal position. To me it looks as if the FPGA is storing about half a capture worth of samples, then arms a digital comparator with the required trigger level. From the point where the comparator trips another half length capture is sampled. Together with the correct number of samples from the trigger point backwards it completes the acquisition.
One would expect to see the processor loading the trigger parameters in the FPGA. However, I didn't find any trigger level commands in the decoded processor to FPGA data stream you captured. Or maybe these are not recognized yet? Or is it done with the command '0x0E' that you called the 'Trigger time / div' setting in your FPGA explained file? 
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1183 on: November 25, 2021, 05:41:24 am »
Hi Maurits,

I also spotted that the trigger level is of in relation to the trigger position indicator. It actually works but I might have missed some level correction in my code. The problem is that the FPGA implementation is also crap, which makes it very hard to create code that works properly. The trigger level command for the FPGA is 0x17, which takes one byte of data. Contrary to trace offset being handled in the FPGA, the trigger position is not. For as far as I found, there is no command that sets this in the FPGA.

My new code assumes that the trigger point is in the middle of the buffer and does, just as the original, a check to find the actual transition point based on the edge direction and the level within 10 samples. (starting at center point -  5) This found position is what the trigger position indicator is located at. Moving the trigger position indicator moves the signal display based on that same point, bringing more samples in at the left or the right depending on the direction. Since I stopped trying to figure out how the original code does it, I have to experiment with things to make it work properly.

The FPGA captures you mention are made in the beginning of the project on my emulator and I have never updated them after discovering more about how it works during the reverse engineering of the code. The code of the test software you had running on your box tells a better story. The scope_get_short_timebase_data function (scope_functions.c) shows what needs to be done for channel 1 to get the data. Also look at the functions in fpga_control.c . These show a lot about the meaning of the commands.

At some point a new FPGA programming needs to be made. With proper ADC interleaving before trigger detection and longer sample buffers. The FPGA has 270Kbits of ram to work with. Should be possible to use more of it then the 3000 samples per channel it gives now.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1184 on: November 25, 2021, 11:39:38 am »
There are still several issues with it but this version has both channels working with the new sample rate setting system.

Tapping on the screen will change both the sample rate and the time per div based on the current time per div. (Only in run mode) When the menu is used the sample rate setting makes the change in the FPGA but leaves the time per div setting on the display unchanged. In the time per div part the viable settings for the current sample rate are displayed with a white text. The settings that show less then a full screen, or only a straight line due to the fact only two samples can be used are shown in a grey color.

When stopped it is possible to change the zoom by tapping on the screen. The sample rate will remain as is, until the scope is started again.

The trigger level does work, but the relation with the trigger position might not be correct. On my development scope (the old one) it looks to match for channel 2 but not for channel 1. So might be a calibration issue. Needs further research.

The view and save item part has not been modified yet, so that bit of the system is useless. USB works and can be used to remove the firmware again. (Zero out sector 16 on the SD card)

Will also upload the source as is now to the https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/fnirsi_1013d_scope folder.

Offline morris6

  • Regular Contributor
  • *
  • Posts: 81
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1185 on: November 25, 2021, 01:00:55 pm »
@pcprogrammer:

Thanks for answering my questions, it confirms the limited view of the inner workings I have so far. Horizontal position of the trigger indicator 'H' is processed by the MCU.

Unfortunately one answer leeds to more questions, so, continuing the brain storm for a bit:

The fact that the original software has to look for the actual trigger point in the buffer of samples, near the midpoint, suggests that the FPGA is not registering this as some pointer value, to be read by the MCU. On the other hand, per definition the trigger point has to be the mid point. Maybe this looking for the trigger in these ten samples you mentioned is done to eliminate jitter caused by noise. Comparing samples with a previous trace and averaging?

The functions in your file fpga_control.c are clear to me. Where the so called parameter IC comes into play is still to be found? Are all captured data processed by this chip before being read by the MCU? In that case is it some kind of look-up table to speed up calculations? That is not clear to me from the FPGA captures.

I certainly agree that writing your own FPGA functions is appealing here. Although difficult when debugging is not available on the actual hardware. Next step is designing a new PCB with... (add your wish list).

Just found your new test firmware...
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1186 on: November 25, 2021, 02:12:08 pm »
Hi Maurits,

I have not found any comparing with previous samples or averaging with them in the code I looked at so far. There is definitely a lot more code but it took to much energy to continue reversing it. So it might be that there is such a thing going on. The actual trigger point determination is also something I did not find either. After reading the first ADC sample buffer there is a routine that scans the 10 center samples and sets a flag, but how this flag is used did not become clear to me.

About the special so called parameter ic (named it so because I thought it was a storage for the settings at first) is more like a translation ic, but does have a relation with the working of the FPGA sample gathering. How is also not clear to me, but to have the FPGA return valid samples for channel 1, it does require the 0x0C parameter with the active trigger channel id to be send to the parameter ic. It returns the command to read the samples from the FPGA. I have not tried to confirm the returned command value yet, but captures made of the communication with this ic showed it returning 0x20. For channel 2 it is 0x0D, which seems to return 0x22.

In the beginning I did try to read the data without this call to the ic, but it does not work.

For reading the second adc samples it does not require this, but have not tried reading them without first reading the first adc samples.

The problem with making a new FPGA programming is the loading it to the scopes out there. You have to open up your scope and attach a programmer to the flash connected to the FPGA. The scope needs to be on to be able to read this flash, at least that is my experience. So most like the same applies for programming.

That is why I have been trying to make something based on the hardware as is now.

Redesigning the total hardware is a bit out there :) Of course it can be done, but it becomes expensive real fast and where does it end.

Cheers,
Peter

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1187 on: November 25, 2021, 05:09:28 pm »
Added the x-y mode displaying and while comparing it with the original I noticed some behavior what made me think that @morris6 might be on to something with the averaging of the sample buffers. While switching between the lowest time per div settings (50 - 10ns/div) it is best noticeable. With 4MHz sine wave applied to both channels, and some phase shift between them the display takes some time to change. At these time per div settings the scope also does a lot of processing for the up sampling. This slows updating down. So might explain the weird. :palm:

See the video I made. https://youtu.be/dGSvxxPtG20

The picture shows a circle made with my firmware. When running it is also very unstable showing lots of erroneous captures.

Have to think about improvements, or just bite the bullet and switch to designing new FPGA programming.

Will see after it sinks in ;)


Offline morris6

  • Regular Contributor
  • *
  • Posts: 81
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1188 on: November 26, 2021, 09:21:28 pm »
Hi Peter,

The problem with making a new FPGA programming is the loading it to the scopes out there. You have to open up your scope and attach a programmer to the flash connected to the FPGA. The scope needs to be on to be able to read this flash, at least that is my experience. So most like the same applies for programming.

That is why I have been trying to make something based on the hardware as is now.
Sure, I do agree with that view. Loading another FPGA content is a delicate business, avoiding to damage anything. And maybe it isn't needed to improve the box's behavior. The original firmware seems not too shabby getting the 'wiggly lines' on the screen.

So, I have loaded the new experimental firmware on the card and tried it out and of course I have some observations and questions:

I like the sample rate indication in the menu line, that is nice information.

The battery charging icon, the arrow, points to the right, to the bottom of the battery symbol. My first thought was: the battery is discharching. Maybe point the arrow to the left to indicate that battery level is increasing.

About the ACQ menu: When selecting a sample rate in the upper block the available gray - white indication in the lower block does not change. Only after selecting a gray or white item in the time per division block the gray - white indication changes according the earlier selected sample rate.

The trigger levels on both traces are about right, from time base 10 ms / div. up to 500ns / div. The 50% button is not active? On the highest speeds trigger is way of. On the slowest time base settings roll mode is not implemented yet, and the trigger level indicator is still showing.

Now about the signals on the screen: The new firmware, like the previous one causes flashing interruptions of the traces, combined with wild excursions. They occur at irregular intervals of about several seconds, irregular, Like missing a heart beat. More noticeable on the higher speeds. This needs to be solved somehow.

Comparing this new firmware with the original one it is obvious that the original firmware does average a few captures. This can be observed by using the single mode. In single mode the original firmware shows a trace with noise while this noise is filtered out when running in normal or auto. It is averaged out by averaging at least two or more captured traces.*) Your new firmware does not do any averaging (as yet) and so the trace in auto or normal mode shows the noise the same as single mode. And it makes the trigger point 'jittery'.

*) This same effect is noticeable on my Hameg when variating the number of averages of the trace.

So it seems the original firmware uses averaging. Now I start speculating:.... Most probably this is done by the FPGA, even at the same time as capturing a new trace. Maybe some of the memory blocks are used for this purpose, storing intermediate results. Together with the use of the secret IC, it makes me wonder:... can't you use the capture functions as they are in the original firmware?. The original firmware is OKish here. Only the shortest time / div settings are producing nonsense. Here it is better just to show the user what is captured and maybe try to do real equivalent time sampling...? With fixed 50% trigger level?

I have a lot of respect for your efforts, but since it is unpractical to change the FPGA programming I think the best thing is to use it as it was designed. When the original capture stuff is working in your firmware you have already achieved a lot. And there is more coming.. I hope.

Regards,
Maurits
 

Offline Alex62

  • Contributor
  • Posts: 10
  • Country: ru
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1189 on: November 26, 2021, 10:50:42 pm »
Hello everyone.
I have an oscilloscope with the inscription FNIRSI on the front panel. Extracted the firmware.
When installing a new firmware, the image is shifted up and to the left.
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1190 on: November 27, 2021, 05:15:05 am »
Hello everyone.
I have an oscilloscope with the inscription FNIRSI on the front panel. Extracted the firmware.
When installing a new firmware, the image is shifted up and to the left.

How interesting. Your box seems to have yet another display that looks like one on the 1014D.

Did you use my firmware backup program, or opened up the box and used a programmer to read the flash, or did you go the FEL way?
No indication if yours has the special touch panel?

The display issue is not a big problem. Will have a look at your back-upped firmware to see what the needed settings are.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1191 on: November 27, 2021, 06:09:33 am »
Hi Maurits,

first of all, thanks for testing. It is nice to get some feedback.

Loading another FPGA content is a delicate business, avoiding to damage anything. And maybe it isn't needed to improve the box's behavior. The original firmware seems not too shabby getting the 'wiggly lines' on the screen.

The fact that the original software is able to provide a nice stable display, does not mean it is good. It shows it takes a lot of effort to fix the crap the FPGA delivers. :-DD
Sure more of an effort can be made to fix what is wrong, but not fixing the core will always leave us with a problematic scope. Not saying I'm not doing the fixing in the code, but will do it based on experimenting and not further digging in the original code.

The battery charging icon, the arrow, points to the right, to the bottom of the battery symbol. My first thought was: the battery is discharching. Maybe point the arrow to the left to indicate that battery level is increasing.

This is something I spotted the first time I plugged in the original scope, but it did not bother me that much that it made me change it. I'm surprised you did not spot the unstable behavior of the battery charge indication itself :) It is on the list of things to look at.

About the ACQ menu: When selecting a sample rate in the upper block the available gray - white indication in the lower block does not change. Only after selecting a gray or white item in the time per division block the gray - white indication changes according the earlier selected sample rate.

I have to check if I fixed this after the release or that what I changed does not do the trick. Noticed it myself too at some point ;) Will check this.

The trigger levels on both traces are about right, from time base 10 ms / div. up to 500ns / div. The 50% button is not active? On the highest speeds trigger is way of. On the slowest time base settings roll mode is not implemented yet, and the trigger level indicator is still showing.

Nope the 50% is not implemented yet. The intention is to fully discard the roll mode and have the 200 and 100ms/div settings work the same as the other settings. Sure the update time will be slow, so have to see how it pans out.

Now about the signals on the screen: The new firmware, like the previous one causes flashing interruptions of the traces, combined with wild excursions. They occur at irregular intervals of about several seconds, irregular, Like missing a heart beat. More noticeable on the higher speeds. This needs to be solved somehow.

Comparing this new firmware with the original one it is obvious that the original firmware does average a few captures. This can be observed by using the single mode. In single mode the original firmware shows a trace with noise while this noise is filtered out when running in normal or auto. It is averaged out by averaging at least two or more captured traces.*) Your new firmware does not do any averaging (as yet) and so the trace in auto or normal mode shows the noise the same as single mode. And it makes the trigger point 'jittery'.

*) This same effect is noticeable on my Hameg when variating the number of averages of the trace.

Nice observation. Have to run some test on this to see what this does. About the trigger, to get a more stable reading I guess it is necessary to decide on the correct trigger point after the averaging. Feels a bit artificial.

I have made a scope and FFT spectrum analyzer two years ago, based on a 100KHz 16 bit ADC. Did not use averaging for the scope and did the trigger on the PC. Looked rather nice and fairly stable compared to what is seen here. So to my opinion it should be possible to get good results with proper FPGA programming. But that is for a later stage.

So it seems the original firmware uses averaging. Now I start speculating:.... Most probably this is done by the FPGA, even at the same time as capturing a new trace. Maybe some of the memory blocks are used for this purpose, storing intermediate results. Together with the use of the secret IC, it makes me wonder:... can't you use the capture functions as they are in the original firmware?. The original firmware is OKish here. Only the shortest time / div settings are producing nonsense. Here it is better just to show the user what is captured and maybe try to do real equivalent time sampling...? With fixed 50% trigger level?

I agree with you on the fact that the original uses averaging to get the stable display. But it is definitely not done in the FPGA nor the secret IC. I'm using basically the same code as the original to get the sample data, at least in my first effort to recreate the original code. For the new version I did more optimization by moving code to avoid copying data from one location to another. The FPGA commands are still the same though.

On wards from the point where I left off in the code reversal, no FPGA commands are called for as far as I could see. It is just a lot of code with memcpy's and what ever. Based on what I have seen in the code I did reverse it is very likely that this is where the averaging is done. For the up sampling they where also not able to do multiple actions in one loop, so why should that be different for the averaging :-//

I have a lot of respect for your efforts, but since it is unpractical to change the FPGA programming I think the best thing is to use it as it was designed. When the original capture stuff is working in your firmware you have already achieved a lot. And there is more coming.. I hope.

I agree that it is best to try to get it running with what is available. Frustrating though |O

At the moment I'm working on the simulator. Going to add a signal generator and emulate the FPGA behavior, including the random error behavior as far as possible. This way it hopefully will be easier to write code to make the scope work better, and get things done faster.

It is a bit of a pain in the bum to have to load the code to the scope for every test, even though it is directly to DRAM, it is still turn the scope off, turn it back on again, run the sunxi-fel command on the PC, test things on the scope, etc.

Lots of work ahead.

Cheers,
Peter

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1192 on: November 27, 2021, 07:13:23 am »
Hi Maurits,

such a big post (yours and mine :-DD) that I missed this one

Here it is better just to show the user what is captured and maybe try to do real equivalent time sampling...?

"Real" equivalent time sampling can't, for as far as I know, be done in software. It needs phase shifting of the sample clock in the hardware. To do this on this scope (200MSa/s real time sample rate) the clock needs to be shifted 5 times to get to 1GSa/s. So sample a 5th of the buffer on phase 0, then shift 1ns and sample the next 1/5th for phase 1 and so on. As you stated yourself before, it only works on repetitive signals.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1193 on: November 27, 2021, 08:53:38 am »
Hi @Alex62,

forgot to welcome you to the forum, so welcome :)

Hello everyone.
I have an oscilloscope with the inscription FNIRSI on the front panel. Extracted the firmware.
When installing a new firmware, the image is shifted up and to the left.

I looked at your firmware and found the needed values for your version. (I hope) With this adapted version, on my test scope the display shifts the other way, so should be ok.

Hope you are willing to test it.

Regards,
Peter

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1194 on: November 27, 2021, 09:58:45 am »
Hi Maurits,

About the ACQ menu: When selecting a sample rate in the upper block the available gray - white indication in the lower block does not change. Only after selecting a gray or white item in the time per division block the gray - white indication changes according the earlier selected sample rate.

I checked this and it was indeed after the release that I fixed it. :)

Cheers,
Peter

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1195 on: November 27, 2021, 12:52:01 pm »
Hi Maurits,

especially for you :)

Offline morris6

  • Regular Contributor
  • *
  • Posts: 81
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1196 on: November 27, 2021, 02:12:54 pm »
Hi Maurits,

especially for you :)
Hi Peter,

Yes.., looks better this way, got my own symbol now in a Chinese oscilloscope..., thanks.

Regards,
Maurits
 

Offline Alex62

  • Contributor
  • Posts: 10
  • Country: ru
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1197 on: November 27, 2021, 06:44:48 pm »
Hi,
@pcprogrammer
Saved the firmware using sunxi-fel.
There is also one saved using your backup program.
Checked the firmware everything is OK.
 
The following users thanked this post: pcprogrammer

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1198 on: November 30, 2021, 12:23:38 pm »
It took a bit of time, but the signal generator front panel is finished. Next up is to implement the user interface and signal generation. Hook it all into the scope simulator FPGA handling and the real development can continue.

Will be another couple of days.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #1199 on: December 02, 2021, 09:42:19 am »
Progress is a bit slow, but filled in the signal display. Next up is making it possible to change the settings.


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf