Reverse engineering FNIRSI-5012H

[ataradov]

Ultrasonic cleaner helps. Even the cheapo ones for jewelry work ok, you may need to run them a bit longer.

But in this case it is not ideal, since display is soldered to the board.

[tzenis]

I changed period and error variables to float. It can handle now a non integer value of the BASE_SAMPLE_PERIOD.
PLL setting and BASE_SAMPLE_RATE is derived from F_CPU. If you want change the frequency, it can be done only in one place (Makefile). The picture shows a correct timing of the device running at 240 MHz.

The file with the patch was corrupted. I send it again.

Tibor

[tzenis]

Bug report.
Hello,
I found one small bug in the code. If the vertical scale is changed, the trigger position is wrong. There is missing

Code: [Select]

config.trigger_level_mv = config.trigger_level * vs_px_value[config.vertical_scale] in the function static void change_vertical_scale(int delta). I think it is better to call here change_trigger_level(0); instead of duplicate the code.

Cheers,
  Tibor

[ataradov]

Yep, fixed on GitHub.

[tzenis]

Hello,
I wrote a support of simple cursor lines. I introduced modes:

• Move: the normal one. Use arrows to change position, shift + arrows for scale.
• Zoom: the inverted mode. Use arrows to change scale, shift + arrows for position.
• Cursor: the cursor mode. The status line contains the time and voltage intervals between the cursor lines. Use arrows to move the cursor1 lines, shift + arrows for the cursor2 ones. During moving the cursor lines, the status line contains position of the corresponding cursor lines..

The cursor lines are shown only in the cursor mode.

Tibor

[tzenis]

All samples only in the single trigger mode?

Hello Alex,
it seems, that only the each fourth sample is displayed in the normal and auto mode, see photos of a 10 MHz clock signal captured in the single and the normal mode, and spikes of my device running @ 250 MHz. When the trigger edge is the fall one, not in the all cases is the edge at the trigger position.
Could you be so kindly and make a look to these issues? Or suggest what to check.
I used for the test the non-modified code from the git.

Many thanks,
  Tibor

[ataradov]

For the display in normal and auto modes the signal is decimated 4 times. There is not enough memory to keep the entire trace and continue signal acquisition. So when trigger happens (on a high sampling rate signal, 182K samples), every 4th sample is copied into a buffer that is 32K samples. The display works on that small buffer. The main buffer in the mean time is filled with the new data.

In a single mode mode there is no repeated triggering, so the whole big buffer is displayed. You can see that logic in the function capture_get_data() where it selects between g_capture_buffer_info and g_storage_buffer_info depending on the mode.

The trigger point between the samples is also normal. On the captures green part of the trace is a linear interpolation of the missing data. You can see the actual sampling points in yellow. It is possible that the actual triggering sample got removed in that 4x decimation process. Basically there is not much point in looking at things in extreme close up.

[tzenis]

Thank you for the explanation.

Tibor

[tzenis]

Preview of an auto cursor mode.

Hello,
I introduced an automatic setting of the cursors (msg. #305).
Button AUTO enable/disable this mode (in the cursor mode only).
SHIFT + AUTO cycles between auto modes:

• Follow Trace (FT). The y position follows the trace at the x cursors positions.
• Pulse Width (PW). The x cursors are set to an one signal period (at the trigger level).
• Positive Pulse width (PP). Similar to PW, but the positive pulse only.
• Negative Pulse width (NP). Similar to PW, but the negative pulse only.

Please let me know, if you have a suggestion to implement other modes, better 2-letters abbreviations or icons, ...
My suggestions: rising/falling edge, set y to maximum/minimum on the PW modes.

Cheers,
  Tibor

[ataradov]

Feel free to fork the code, of course, but I myself not interested in extending the functionality. In fact, I'm looking for ways to reduce it.

If I feel like I need cursors, I will bring out the real scope rather than this toy. Fiddling with the buttons is just painful.

But as far as feedback on the changes goes, if I were to implement the cursors, I would implement them tied to the signal in the storage buffer, not the display buffer. That way you could zoom in on one edge, set the cursor, zoom in on the other edge, set the other cursor, and have a good delta value.

Screen cursors only automate counting of the grid squares. And that's not that hard.

[tzenis]

Hello Alex,
thank you for the feedback. I have read all the posts on this topic. I am sure you are not interested for these changes. I did it for relax during vacation. I wrote the post mainly for other readers.
I am now interested if it could be possible to reconstruct a periodical signal in a time precision better than the sampling rate.

Cheers,
  Tibor

[ataradov]

If you mean true ETS, then it is impossible, since ETS needs analog triggering and precisely controlled trigger delay.

You may do some questionable tricks, like collecting multiple samples triggered from the same trigger and assume that the first point after the trigger condition is sampled at a random point in the actual analog signal. You can then depending on the amplitude of the first sample sample calculate possible analog delay and place that sample accordingly in the buffer. But that would  only work for slowly changing signals. And memory management would be an issue.

It may be possible to do some sinc-style interpolation, but it will be very slow. For this you basically need to replace my linear interpolation code with sinc. But I have not thought about how much calculation it would actually take. I feel like it is a lot.

[tzenis]

True ESR is not possible.
I mean, I have stored samples of many periods of the signal. I can calculate the period of the signal in very high precision. I can determine the phase shift (with respect of the signal periods) of the samples between adjacent periods of the signal. It should be possible to obtain many points of one period of the signal. Ratio of the signal frequency and sampling rate can not be a fraction of small integers.
In short. I can't set the timing of sampling with respect of the trigger point but I can calculate the timing of the stored samples.

Tibor

[ataradov]

This is what I described in the second paragraph. There are two possible options:
1. Work with multiple periods from the same capture. The issue here is to capture multiple periods at high enough sample rate. I'm not sure if that makes any sense.
2. Work with the first period from multiple captures. This has some potential, but a lot of assumptions and guessing will be involved, so it will work for some signals, but not others.

[gf]

If the frontend is fast enough and no anti-alias filter is present, then the ADC of a DSO can certainly act as digital down-converter. Meaningful results can only be expeted for certain frequencies, though, which which happen to alias to the 0...fs/2 range in a suitable way. For instance, frequencies which are integral multiples of the sampling rate won't work at all, while a periodic signal with (say) 1.2511 MHz, undersampled at 125kSa/s, can give a nice result, down-converted to 1.1 kHz (just an arbitrary example).

[ZebMcKayhan]

Just reflashed mine and what I difference! You just turned this toy into something useful. Special thanks to Ataradov for all your work!

As a hw guy I'm typically interested in transition details, so how would I do to change the code so all samples are viewed in auto and normal mode? Instead of having 128k capture and 32k data, could I just set these to 80k each? I understand the penalty for this, but would there be other parts that would need change as well?
Is there a reason to keep buffer size to 2^n and keep them at 64k both or would 80k work?
My c skills are somewhat limited but I have good help from programming friends.

//Zeb

[ataradov]

It would not be easy to do given the way memories are organized on this device. The memory accessible by the DMA (necessary for the capture) is a chunk of 128 KB. The reset of the memory (64 KB) is only accessible by the MCU. That's where I allocate 32 KB for the secondary buffer and the rest of the variables.

Splitting away part of the 128K buffer would mean that the other buffer would be discontinuous. So the code would have to handle this. It is not that hard, as the actual buffer for the display is populated in one function.

There is a lot of code that relies on the power of 2 size, but again it is only because I assumed that buffers will be power of 2 sized. There is nothing hard that requires that. But it still would be quite a bit of work to change that.

The easiest thing you can do is to not select every 1/4 sample when filling out the smaller buffer. You will end up with a trace that only fills 1/4 of the screen, but contains all samples.

[ZebMcKayhan]

Thanks for the answer. Sounds tricky.

If I understand you right, if both buffers were to be 64k they would both fit in the dma section and not be discontinous? Or is there any problem for the mcu to access this area? Or setting up the dma for only using 64k?

//Zeb

[ataradov]

Yes, if you split the 128 K buffer in two then it will work fine and both buffer will be continuous. There may be minor performance issues when MCU and DMA try to access the same memory. But it should not be significant.

The trickiest part with adjusting for 64K buffer would be to recalculate time/div values, since they all are calculated based on the 128 K buffer. I'm not sure how hard that would be.

[ZebMcKayhan]

Great! The code looks really well written so it seems to be mostly defines, and I need to check through the calculation for setting horizontal config.
The memory map looks fishy, is there 3 banks? Sram0 is 112kB  sram1 is 16kB and sram3 is 64kB but they all seem to be consecutive in memory. A good start may be to just change the size and location of the buffers and see if I can get it to run without performance or other issues...

//Zeb

[ataradov]

GD32F407xx only has SRAM0, SRAM1, and TCMSRAM. SRAM0 and SRAM1 are basically the same memory.  TCMSRAM is a very different memory at a different address.

While there are defines in the code, it does not mean you can just change them and things will work 100%.

[ZebMcKayhan]

Ill have too look more closely into the memory map.

I just meant that it only took me acouple of minutes to find 2 places where this is calculated and needs a closer look. The way the code is hierarchicallly structured I wouldn't expect there to be changes on too many places. But of course "assumptions are the mother of all f.....". I don't expect anything.

//Zeb

[neuralsim]

Hi all!

I'm new to the forum and also kinda new to electronics, but I am a highly skilled and experienced software developer, and I do understand the very basics of electronics, like what a ransistor/capacitor/diode/resistor does, how to build from a schematic, how to solder, how to interface with a simple IC, etc.

I have purchased everything necessary for this project, but haven't yet received the chip and some other parts. I've read all of the github repo instructions, and I've read a whole lot of the thread but I am still going through it (currently on page six).

Would you folks who have done the project be willing to kindly help me through the process?

The first questions I have are simple. Did I buy the right parts?

I got this debugger:
https://www.amazon.com/gp/product/B00PVJ8Q4C/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

And this USB connector:
https://www.amazon.com/gp/product/B07Q4J5NKZ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

And this cabling:
https://www.amazon.com/gp/product/B01DP13EDA/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

Question 2: I have no idea how I will get 3.3v power to the debugger. How do you suggest I shall do that? I was thinking perhaps I would just hook up a few AA batteries and a voltage divider? I'm a newbie but I think I have figured it out. Is my diagram and my math correct? Will this be OK to power the debugger?

edit, tried img tag but the image didn't show up? Here is the circuit (edit, nvm, I realized the resistance is way too high to power the board, and alex says I don't need an extra power source. But here's the very bad circuit I designed anyway):

[ataradov]

Why would you need to supply the voltage? I don't see any voltage shifters on this debugger. The only reason to supply the target voltage is if programming software cares about it. And chances are it does not.

And if it does, there is 3.3 V output right no that connector. Just short it to the target voltage sense pin, of there is one.

[neuralsim]

Ah, OK thanks. I don't have the programming board yet. So I take it the board is suitable?

I was just trying to understand your comment in github. Sorry, I'm very new to this and trying to learn a lot of things at once.

"It is important to keep in mind that programmers supporting multiple target voltages often use level shifters powered by the reference voltage provided by the target board. In this case there is no reference voltage, so you would need to provide that voltage (+3.3V) externally."

How will the board get power? Will it come directly from the scope?