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