Products > Test Equipment
New bench scope - Fnirsi 1014D, 7", 1GSa/s
pcprogrammer:
--- Quote from: donwulff on December 27, 2022, 07:31:45 am ---Spectacular work with the reverse-engineered firmware! I've been wondering though, given this is the FNIRSI 1014D thread, what are the chances of building open-source firmware for the 1014D as well? it sounds like their hardware is very similar, save for the signal generator? For the price it might be a nice platform to perhaps try some simple signal processing/UI improvements. Maybe I should start with some of the tear-down comparisons of the two models people were referring to?
--- End quote ---
Yes the hardware is very similar to the 1013D. Only differences are the function generator and the user interface.
The function generator is based on an eight bit R-2R network connected to FPGA output pins. In the FPGA it uses a block of memory to create the signal. Partially looked into the FPGA design while reverse engineering the 1013D FPGA. The sampling system is most likely the same.
The user interface is handled by an ARM MCU which scans the buttons and rotaries and sends the needed information to the F1C100s processor.
The firmware is also very similar, but instead of being controlled with a touch screen it processes the serial data from the secondary ARM MCU. Another difference is the function generator. A lot of the investigation has already been done. There is a Ghidra project with already a lot of the functions identified.
It should not be to big of a deal to make new firmware for it based on what I wrote for the 1013D, but I'm not going to do it >:D
--- Quote from: donwulff on December 27, 2022, 07:31:45 am ---Also about the true performance. If I understand right both probes have two-channel 100 megasample 8 bit ADC:s? So if the FPGA is indeed driving this at 100 megasamples (And I see the datasheet might have little leeway to increase that higher, maybe?) that would be 2x200 megasamples at 7.5bit? 3nS rise-time spec would mean 6 times oversampling, but I guess the real rise-time is more like 10nS? The 1 Gs/s, while made up, is close to the combined analog bandwidth, so I guess if you knew the waveform and/or it was repeating, you could interpolate up to that? ~200Mhz sine-wave? Then again I suppose they're already using a lot of those tricks.
--- End quote ---
The performance of the system is based on 200MSa/s for the fastest time per division settings. It then has 3000 samples available of which only ~2500 are used on the display. There is a lot of filtering to make it look smooth. (I removed all of that) For the other time per division settings it only uses one ADC and 1500 samples at max. The sample rate is controlled with the time per division setting. (Which I changed in the new 1013D firmware)
Above ~44MHz the software just calculates a sine wave based on the measured zero crossings and the measured max amplitude. (This has also been stripped)
It might look very nice on the screen, but for realistic measurements it is crap.
Another drawback is the vertical sensitivity, which with only 100mV per division true range with a 1x probe setting it is not very good. The advertised 50mV per division is based on software zoom.
--- Quote from: donwulff on December 27, 2022, 07:31:45 am ---Basically wondering what the actual specs & capabilities are, derived from the firmware, and if the stock firmware is already using those to the max. Still could benefit from things like stacked & fading traces, trace differences etc.
--- End quote ---
The new firmware could do with improvements and there is also some room in the number of available samples. Now using 3000 samples, but in the FPGA it has room for 4096. But as I wrote above, I'm not going to do any work on it in the foreseeable future.
Take a look at the reverse engineering repository, if not already done so. https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack
donwulff:
Just for the record, I'm aware of the sampling theorem, ie. "a signal has to be sampled at least with twice the frequency of the original signal". "at least" is doing a lot of work there. With 100MHz signal you'd like to have at least 5 samples per cycle to recover any of the waveform. Of course, if you already know the signal is around 200MHz, it would be possible to fit a sine (or square) wave to even fewer measurements. According to the ADC datasheet, it could possibly handle up to 475Mhz (the analog paths likely can't) if you know the waveform you're looking for.
Practical example: Matching signal edges on a bus/to a clock, where you know the signal frequency and are only interested in determining the phase.
pcprogrammer:
Even if the used ADC's are genuine it does not matter because the front end is bandwidth limited to ~30MHz. Did not check the order of the filter, but at 200MHz on the input I don't think there will be much signal left to sample. Can't test it because my signal generator only goes up to 100MHz.
There are plenty threads on this forum about sampling and the theory behind it, so not going to fill this one with it.
To do more interesting things with these scope(s) one should write up a better FPGA implementation to at least make use of the available memory in it, to quadruple the memory to 24KB per channel. Still not much compared to for instance the Hantek DSO2D15.
It is a nice platform to play on and develop skills in developing scopes, but that is it, at least for me.
Fungus:
--- Quote from: donwulff on December 27, 2022, 04:48:47 pm ---Just for the record, I'm aware of the sampling theorem, ie. "a signal has to be sampled at least with twice the frequency of the original signal".
--- End quote ---
Not quite.
It should be: "a signal has to be sampled at least with twice the bandwidth of the original signal".
Bandwidth != frequency.
donwulff:
Not me derailing the thread to sampling theory, ahem... :-// Anyway, bandwidth is an important concept for any kind of high-frequency instruments. The sampling theorem was mostly for the benefit of @py-bb asking if 1Gs/s 2 channel scope shouldn't be 500MHz, as well as to pre-empt anyone needing to point out to me that you can't turn 200Ms/s per channel into a full-fledged 200MHz scope, nor should anyone expect that sort of performance. (The sampling theorem doesn't fully hold, however, if the signal isn't fully unknown, which is why I've successfully used true 100MHz scope to align 200MHz bus signals, for example).
But the Nyquist-Shannon sampling theorem is a purely mathematical construct, and as such it assumes a perfectly spherical cow. In other words, the Shannon theorem paraphrased above actually goes "If a function x(t) contains no frequencies higher than B hertz, it is completely determined by giving its ordinates at a series of points spaced 1/(2B) seconds apart." Of course, the interesting signals in real world aren't pure sine waves (In fact, a perfect square wave is an infinite series of harmonics, to well, infinite frequency. Luckily you don't get a perfect square wave in practice, either) and hence 5 samples per frequency cycle is good minimum to interpolate min, max and zero crossings. And you need to also be able to get your 2 or 5 samples, where every component along the way has a bandwidth limit/attenuation.
I actually acknowledged that with "the analog paths likely can't". In retrospect, it makes sense that there would be an intentional filter around the actual capability of the scope's ADC's, so you don't get aliasing and other unwanted effects from higher frequencies. As a counterpoint though you could alter that filter, and for the signal-aligning use-cases I mentioned, you don't even care about significant attenuation as long as the peaks are discernible. But in the end, I don't expect the hardware can be pushed much further that way. It's just a thought because there ARE use-cases where you don't care about the exact waveform, or where the signal is repetitive so you could fold over the measurements (Unless the sampling rate is a perfect multiple of the signal, you don't even need to shift the sampling points, just align them in software).
Regarding modifying the FPGA, that's a thought, but reviewing some of the earlier thread it seems there's no way to re-program the FPGA via USB or SD-card for example (Could there be a hidden command for it though?) so while exciting, the actual number of people who would be doing that is probably fairly low... At least here in Europe the FNIRSI 1014D is less than half of the Hantek DSO2D15 for example, which places it a price category where you can buy one to toss around, experiment & possibly break, OR use if for hobbyist projects in the 20-30MHz range. But it's certainly cheaper to buy DSO2D15 or even 1013D than trying to replace the existing firmware for personal use. It does look like there's already something bootable for 1014D in the repo though, so who knows.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version