-
It is a mystery to me. I'm no expert on DSP and have no idea why it is done the way it is done. It is about the code in the previous post. There are errors in it, concerning the pointers usage, which I checked with trace output of my emulator.
But here is what I make of it in descriptive talk
- copy the input samples to another buffer with a 10 sample interval to make room for 9 samples in between
- fill in the 9 samples in between the copied samples. Use linear interpolation for this
- copy from this temporary buffer starting on the 5th sample every tenth sample to another buffer with a 10 sample interval (So copy interpolated samples to the other buffer)
- in this second temporary buffer fill in the 9 samples in between the copied samples. Use linear interpolation for this
- make an average of the samples in the two temporary buffers back into the input buffer. Here they made an error. They start on the first sample of the first temporary buffer, but the -10th sample of the second temporary buffer, which is not written to in step three or four.
- copy samples from the in step five written input buffer starting on the second sample with a five sample interval to the second temporary buffer.
- in this second temporary buffer fill in the 4 samples in between the copied samples. Use linear interpolation for this
- average the samples in the in step five written input buffer with the samples in the second temporary buffer. Here they made a similar error as in step five. Correct start on the input buffer but incorrect on the second temporary buffer.
Hope this makes any sense. My layman instinct tells me that it does not help on the signal and they could have done with what is done for the other two ranges. Just up sample with interpolation. (What I read about up sampling is insert zero's and run the samples through a filter to fill in the blanks, which might lead to the same result depending on the filter)
It might be that the errors are needed for special alignment of the sample ranges, but it still corrupts the first samples.
So anyone any thoughts on this
-
I must say I'm a bit disappointed about the lack of feedback. I really hoped on some input about the up sampling issue
But that aside, a fan of my work kindly donated a FNIRSI-1014D and it arrived today. Played with it a little and it is nice, but certainly not wow. They display things a bit nicer with some color shading.
Noticed some changes to the 1013D:- like the trigger edge symbol flips the same way I made it do in my version of the 1013D code
- Another is that they start the long time base traces (100mS/div and up) away from the trace pointers on the left, where as in the 1013D they draw them through the pointers
- It shows positions on the screen of the trace and trigger point, but for the trigger it does not change correctly. When passing the center line it flips from sign, but the value remains the same.
- For as far as I can see, it only allows for 6 measurements to be shown at the same time. These are on the right of the display and can be changed with the function buttons next to it
Have not opened it up yet, but think it uses the same front end as the 1013D. The sensitivity adjustment is the same. Relays clicking for the top 5 settings, but not for the lowest setting. My guess is they recycled the FPGA, sampling and trace display code form the 1013D. It at least behaves the same on change of time base setting.
Another project to play with once finished with the 1013D
- like the trigger edge symbol flips the same way I made it do in my version of the 1013D code
-
Yup, basically you're alone most of the time.
I also discovered that, I was expecting a more involved community but... nope! -
I will will be more than happy to test any alpha/beta versions of firmware when you get so far.
But I do not know enough about scopes or low level programming to help you out during development... -
One small step forward, but far from finished and needs some checking of what is going on because it is not what it should be
Trace data displaying for the long time base settings (100mS/div and up) is implemented. Was quite the struggle to grasp the meaning of a part of the code. It turns out to be some signal rise speed detection.Code: [Select]void display_channel1_long_timebase_trace(void)
{
undefined2 *puVar1;
undefined *puVar2;
int iVar3;
uint uVar4;
uint ystart;
uint uVar5;
uint yend;
bool bVar6;
bool bVar7;
set_display_fg_color(DAT_80006890);
puVar2 = PTR_DAT_80006894;
uVar4 = (uint)*(ushort *)PTR_DAT_80006894;
if (uVar4 == 0)
{
puVar1 = (undefined2 *)(PTR_DAT_80006894 + 0x16);
*(undefined2 *)(PTR_DAT_80006894 + 2) = *puVar1;
*(undefined2 *)(puVar2 + 6) = *puVar1;
}
yend = (uint)*(ushort *)(puVar2 + 0x16);
ystart = (uint)*(ushort *)(puVar2 + 2);
uVar5 = yend + 0xf;
bVar7 = ystart <= uVar5;
bVar6 = uVar5 == ystart;
if (bVar7 && !bVar6)
{
uVar5 = ystart + 0xf;
}
if (bVar7 && !bVar6)
{
bVar7 = yend <= uVar5;
bVar6 = uVar5 == yend;
}
if (!bVar7 || bVar6)
{
uVar5 = ystart + 0x14;
bVar7 = uVar5 <= yend;
bVar6 = yend == uVar5;
if (!bVar7 || bVar6)
{
uVar5 = yend + 0x14;
}
if (!bVar7 || bVar6)
{
bVar7 = uVar5 <= ystart;
bVar6 = ystart == uVar5;
}
if (bVar7 && !bVar6)
{
display_draw_line(uVar4 + 3,ystart,uVar4 + 3,yend);
display_draw_line(*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 2) + 1,*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 0x16) + 1);
goto LAB_80006828;
}
}
else
{
yend = yend + ystart >> 1;
*(short *)(puVar2 + 0x16) = (short)yend;
}
display_draw_line(uVar4 + 3,ystart,uVar4 + 4,yend);
display_draw_line(*(ushort *)puVar2 + 3,*(ushort *)(puVar2 + 2) + 1,*(ushort *)puVar2 + 4,*(ushort *)(puVar2 + 0x16) + 1);
LAB_80006828:
iVar3 = DAT_80006898;
*(undefined2 *)(puVar2 + 6) = *(undefined2 *)(puVar2 + 2);
*(undefined2 *)(puVar2 + 2) = *(undefined2 *)(puVar2 + 0x16);
*(undefined2 *)(iVar3 + (uint)*(ushort *)puVar2 * 2) = *(undefined2 *)(puVar2 + 0x16);
return;
}
At first I had to identify the functions called as being display_draw_line. Then it took a while to notice that the first two calls use the same x point. One reads what one wants to read
Also the bit with all the compares if one of the points plus 15 is less then the other and then the points plus 20, so I made test code of it and ran it through with a debugger.
Turns out that on the absolute difference a check is done to see if the delta is less then 15. If so take the average between the two points, if less then or equal to 20 use the points and draw them on consecutive x positions. Is it more then 20 draw the points on a single x position.
This is what I made of it.Code: [Select]//Check on rise speed of the signal
if(disp_ch1_y < disp_ch1_prev_y)
{
//previous bigger then current so subtract from it to get positive delta
dy = disp_ch1_prev_y - disp_ch1_y;
}
else
{
//current bigger then previous so subtract from it to get positive delta
dy = disp_ch1_y - disp_ch1_prev_y;
}
//Take action based on the delta
if(dy < 15)
{
//Less then 15 apart slow the trace by stopping on the average of the two points
disp_ch1_y = (disp_ch1_y + disp_ch1_prev_y) >> 1;
}
else if(dy > 20)
{
//Else if delta bigger then 20 draw on a single x position
xpos2--;
}
//Draw the lines. When on a single x point it is a bit inefficient. Would be better to only draw one line and make it one longer for the double width
display_draw_line(xpos1, disp_ch1_prev_y, xpos2, disp_ch1_y);
display_draw_line(xpos1, disp_ch1_prev_y + 1, xpos2, disp_ch1_y + 1);
And the photo shows what the scope makes of it
-
Found the bug causing the drawing problem. Was in the draw line code. A what needed to be a singed result wasn't
Managed to get the emulator to display signals on the long time base settings and was able to find the problem that way
The images show the before and after the fix.
On the scope itself it does not work yet. Has to do with the writing of the trace offsets to the FPGA. At the moment the FPGA thinks both traces are placed at the top of the screen, and returns max values, meaning signal at the top of the screen. Only on large enough input signals it flips down.
So that is next on the to do list.
-
Was a bit of a struggle with some fractional calculations and the need of 64 bit type casting, but the trace offset now works.
It is showing some sine waves, but there still is a problem with time. For the 100mS/div setting it is on it moves to slow, and the displayed waves are not correct. On channel one the input is 1Hz and on channel two it is 0.5Hz. Need to do some calculations and checking on the timer interrupt to find the root of this problem.
Next up is implement the changing of the time base setting, and the movement of the traces. Is part of the user interface I skipped because missing information that I gained now by implementing the long time base part of the trace handling.
It is one big puzzle with still many, many pieces to fit
Getting this bit to work was a booster of the spirits
-
I must say I'm a bit disappointed about the lack of feedback. I really hoped on some input about the up sampling issue
I missed the up sampling question. Would you mind repeating it or sending me a PM?
Have Fun!
Reg -
Found another blooper
For the long time base settings the max is 50S/div and the one below that, says on the display it is 20S/div, but the code and a stopwatch tell me it is actually 25S/div.
The problem I mentioned in my previous post was an oversight of me. Missed a goto in the Ghidra output that skipped over a 40mS delay call. Due to that delay it was not running on 100mS/div but 1,1S/div
Fixed it and it is running as needed now.
Working on the changing of the time base setting and hope to get that done soon. -
I'm feeding a 100 ns pulse at 1 MHz to CH1. I have a 50 ohm terminator on CH2 and am using a 50 ohm thru on CH1. Both traces look fine at 50 ns/div, but if I change to a faster or slower speed, there are bursts of a sine wave which appear on CH2. But only at 5 V/div!
There is also a 100 mV jump on the dead CH2 trace at 200 mV/div at anything faster than 1 us/div.
I've spent about an hour studying the code from msg #950 and so far can't make any sense of it. It doesn't look like any DSP algorithm I can think of. I'm going to try to compile and run it with some sample data to see if that helps me understand it.
Reg
-
That is what I meant with the Chinese logic
Had a similar idea but needed a bit of success to stay on the project, so moved on to the long time base stuff, which is basically very slow sampling.
For the 100mS/div setting it means 10 samples per 4mS, where I have no idea on when and how fast the samples are taken. The code averages these 10 samples and shows them on the screen, spread over two pixels in time. So 50 pixels per division filled with 25 averaged samples. For each setting above it just lengthens the sample loop, so 8mS for the next setting, 20mS for the one after that and so on to 2S for the 50S/div setting. -
Averaging over 10 samples applies a sin(x)/x filter in the frequency domain which has significant sidelobes. A triangle weighting would make it sinc**2 which has much lower sidelobes above the first zero. Essentially the average is a cheap and mediocre anti-alias filter. If the samples had been bit shifted to apply a taper it would have been almost as cheap computationally.
Sadly, there are far too many DSOs which don't implement *any* anti-alias filtering when operating at display sample rates below the acquisition rate. And people who claim this is good :-(
In my putzing with this I have come to the conclusion that the HW is *much* better than the SW. With better software I think it would be very usable for HF radio work and low clock rate MCUs. It's also a great test bed for developing DSO touchscreen UIs.
Have Fun!
Reg -
In my putzing with this I have come to the conclusion that the HW is *much* better than the SW. With better software I think it would be very usable for HF radio work and low clock rate MCUs. It's also a great test bed for developing DSO touchscreen UIs.
I don't now a lot about dsp, so will take your word for it about the "filtering".
But I agree with you about the hardware being better than the software. Also a big plus is the fact that the hardware is programmable. The question there is how much logic can be stowed away in it, and how fast can the bus between the MCU and the FPGA transfer data.
I like to see the work I'm doing as a stepping stone to something better. As written before, the code is by far no exact match to the original and I think it is already an improvement.
For instance the adjusting of the time base is made overly complex in the original code. When in stop mode they use a fractional computation followed by if's and switches to see if the new setting is within a plus or minus 3 step of the last active sampling rate. Had to go through the settings on the scope to find this logic behind it
Also the original setup of the touch handling code is very unstructured. The way I did it can still be improved, but is already much cleaner than the original.
Again a step closer to the finish line, but still a long list to handle
-
I've been studying the code in msg #950 more and realized I need to know the hardware details, byte sex, ISA, memory map, etc.
Where can I find that info?
Reg -
Download the f1c100/200s datasheet. You can find it anywhere, also in my Drive folder.
-
I've been studying the code in msg #950 more and realized I need to know the hardware details, byte sex, ISA, memory map, etc.
Where can I find that info?
Reg
Better yet everything you need is in the repository https://github.com/pecostm32/FNIRSI-1013D-Hack
You can find the reversed engineered schematics, the Ghidra archives, my reverse engineering work files, a bunch of test code, datasheets, etc. -
Implemented the changing of the time base setting. This works without problems down to 100nS/div. The switch to 50nS/div kills it, but this most likely has to do with the fact that the 50nS signal processing is only partially implemented
Worked through the code for moving the traces and the cursors and made my own spin of it. Implemented the trigger point position and the signal trace moving. Can not test the first since it needs the short time base trace display functionality
The signal traces can be moved, but the display flickers like crazy when that is done, so need to fix that with drawing in a separate buffer and then copy to the main display buffer to make it smoother.
Plan on making another, in my eyes, improvement. When in x-y mode display the signal center pointers are both on the left side, and can be moved with x and y movement on the display. X for channel 1 and Y for channel 2. My plan is to move the channel 1 pointer to the top to make it an actual X pointer. A fairly simple change.
But it is more and more starting to look and act like a scope
-
The trace area is about 722 pixels wide so at 500 ns/div, every pixel is a sample. The code properly interpolates 2:1 and 5:1, but fails at 10:1 or greater.
The proper trace interpolation operator is a minimum phase sin(x)/x function. In seismic processing an 8 pt operator is normally used for plotting. This puts the error at <0.1%. For each of the output points you need a table of coefficients which are then applied for each distinct offset in time from the samples. Each output time slot has its own table. The cost of a pixel is 8 multiply-add operations. At 10 ns/div it's 5664 MACs for a full trace.
I had many conversations with @tom66 about this for his project. I've also got plots and code somewhere.
BTW Much of the logic in the 50ns code is adding a sample to make the length even.
Now that I know what it does I can write it from scratch. We need to figure out where it reads and writes. Nothing else matters as I know the correct math.
Ideally it should store samples as read in an XY buffer of unsigned char as fast as the data can be transferred by the FPGA. Each time a sample maps to a bin in the XY map, increment the unsigned char, and on every trace renormalize the buffer. At 30 fps, perform the interpolation of that buffer to generate the screen. This provides persistence and allows making color histogram displays of the signal variation. I do not know of a single DSO that does this correctly. That includes $20K list kit.
Aside from transferring data from the ADC, the FPGA is critical for trigger filtering and logic. The display stuff can all be done quickly enough on the ARM. However, it all depends on what resources are available. Does the 1013D have any DDR? I didn't see any in the schematics. The XY histogram buffer needs at least 256 kB.
Have Fun!
Reg -
Hi Reg, this is useful information
The only RAM in the system is the 32MB DDR plus some 72KB of SRAM that is in the F1C100s and the 270Kb in the FPGA. For the latter the question is how much can actually be used without the loss of functionality.
The system is performance limited by the DDR in the F1C100s though. Not sure about the bus width, but the clock is a factor 4 to 5 lower than the CPU clock. It has caches but these are not that big. The DDR is shared memory between the CPU and the LCD, so also a limiting factor
So overall nice but not great. -
Data width is only 16 bit... RAM clock is not linked to the cpu in any way, each one has it's own PLL.
Default is 156 MHZ (312MHz DDR effective rate), cpu clock 408MHz.
Usually you can get close to 700MHz without issues. The DDR limit is around 192MHz.
I thought the fnirsi had a F1c200s? Same thing with 64MB.
Doesn't the DDR also store the CPU program? (The linux kernel does that) Or does it fetch the cache from the spi flash directly?
-
Unfortunately it just has a F1C100s, so just the 32MB, and indeed it loads the program into the DDR, but the program is not that big, and my version will be even smaller.
About the clocks I know they have separate PLL's. I was stating that the clock frequency of the DDR is a factor 4 to 5 lower than the CPU clock, which on the max workable settings improves to about 3.7. With the double data rate in account one can say it is even less, but with only a bus width of 16 bits it basically half's again
Where did you get the information about the bus width? I tried to find info on the DRAM controller settings, but failed. Used source code from the sunxi factory for it but it does not provide a lot of insight in the working of it all. -
Finished with the implementation of the moving of the traces, cursors and pointers.
Also made the change I wrote about a few posts back. Need to tweak the offsets when drawing the x-y traces though. It also moves in an opposite direction of the x pointer, so need to fix that too.
I will add a new folder in the binaries section of the repository with a compiled version of the code so far, plus the binary of the boot loader and instructions on how to get the scope up and running with it.
For the time base settings 50mS/div - 10nS/div it only displays the grid, pointers and cursors, which was needed to test the moving of them.
Getting the trace display for these time base settings working is the next step.
https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Binaries
-
A poll:
How many of the readers of this post want me to move the hacking updates to another thread?
If you do that then what would be left in this thread?
-
A poll:
How many of the readers of this post want me to move the hacking updates to another thread?
If you do that then what would be left in this thread?
Whow, you dug deep to get that one up
I guess nothing
-
Where did you get the information about the bus width? I tried to find info on the DRAM controller settings, but failed. Used source code from the sunxi factory for it but it does not provide a lot of insight in the working of it all.
Not sure actually. I think I saw that in a chinese forum.
Anyways, I made some benchmarks, stopping the TCON, so it doesn't used bandwidth.
CPU set to to 768MHz to reduce possible bottlenecks.
8GB memory copy:
dd if=/dev/zero of=/dev/null bs=1M count=8192
312MHz: 29.91s, 273.88MB/s
408MHz: 23.15s, 353.86MB/s
The performance increase is linear, so clearly the bottleneck here is the ram itself.
Being memory copy (read+write), the bandwidth would be 2x those numbers: 548 and 707MB/s
At 312MHz and 16bit bus, the theorical speed would be 624MB/s.
At 408MHz, 816MB/s.
The actual speeds are pretty close! Both benchmarks use 86-88%, with the performance drop caused by the timing signals overhead.