Products > Test Equipment

New bench scope - Fnirsi 1014D, 7", 1GSa/s

<< < (45/67) > >>

Rasz:

--- Quote from: donwulff on January 01, 2023, 12:00:10 pm ---If anybody can suggest better than 2 independently 250MSa/s+ channels Digital Storage Oscilloscope under 200 dollars/euros

--- End quote ---

already did - ~$80 2 channel SigPeak DSO2512G, it actually has ~90MHz of frontend BW unlike Fnirsi garbage


--- Quote from: pcprogrammer on January 01, 2023, 01:28:18 pm ---You mention a 400MSa/s versus advertised 1GSa/s for the two FNIRSI scopes.
--- End quote ---
thats probably my fault, I wrote that few post above erroneously giving Fnirsi scammers some benefit of a doubt


--- Quote from: pcprogrammer on January 01, 2023, 01:28:18 pm --- It is not possible with the FPGA as is, to do 400MSa/s on a single merged channel. The two ADC's in a single AD9288 chip are clocked with 180 degree phase shift to allow for the 200MSa/s sampling rate. The two AD9288 chips in the scope are clocked on these same clocks. To do 400MSa/s the clocks would need to be on phase 0, 90, 180 and 270 degrees to make it work.
--- End quote ---

fantastic, so the fraud is selling 1/3 to 1/5 of advertised specs :o


--- Quote from: pcprogrammer on January 01, 2023, 01:28:18 pm ---About the protocol decoding. This is not trivial with the current setup. There is no way to do fast enough continuous sampling of the signal into the F1C100s memory to do analyses on it.  You mention sigrok and turning the scope into a data logger for that. Even with a dedicated FPGA implementation the limiting factor is the low memory amount in the FPGA and the speed of the interconnect between the FPGA and the F1C100s. Even though it is a parallel bus it can't even reach 100MB/s due to the way it is implemented. (Have not done actual speed tests on it)

--- End quote ---

you could do it with DSO1511G/DSO2512G and custom CYUSB3014 (~370MB/s usb3 transfer) board replacing F1C100s

pcprogrammer:
It is interesting to see that FNIRSI used yet another FPGA in a bunch of 1013D's. The tear down https://www.cnx-software.com/2022/11/16/fnirsi-1013d-teardown-and-mini-review-a-portable-oscilloscope-based-on-allwinner-cpu-anlogic-fgpa/ shows a clear picture of the PCB and that they did not remove the marking on the chip in this one.

The question is if this is a newer revision then the one with the AL3-10. Don't think the firmware will be any different going by the screenshots.

But this is about the 1014D and your intentions to play with it.  :)

About the JTAG for the FPGA. In the 1014D there is provisions for a 2.54mm double row header as shown in the schematic, so easy enough to do direct uploads to test new designs. I modified my 1013D with some wires soldered to the components to get access to the JTAG. Morris6 went a bit further and did an impressive job in adding a header and some additional LED's to his scope.

There is also a design based on a bluepill and unfortunately closed firmware for a JTAG programmer for the Anlogic IDE. https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Anlogic_JTAG_Programmer

You mention the different FPGA's as complicating things, and that is true when the road of designing a new setup for it, is taken. You would need access to all types to make it work for every scope out there. Not really optimal to say the least, but not a lot of people might be interested in upgrading the FPGA flash, which could mean the stock firmware won't work anymore. (You would need to adapt your design to be backward compatible)

In a similar way there is the usage of the different LCD modules with shifted screens as a result. I solved that with a separate configuration file, where as the manufacturer choose to supply different versions of the firmware. Also had to do this for the touch panel on the 1013D, which also has different configurations out there leading to swapped x and or y coordinates.

You mention not having success in reading the FPGA FLASH ic. The trick here is to do it with the scope up and running. Only connect the SPI signals and the ground, not the 3V3 power. The FPGA screws with the signals when not powered up. So even though there is the diode in the FLASH supply chain it did not work for me until I powered up the scope.

There is indeed some development environment I created for the 1013D, and the repository you found modified it to use the QEMU instead of my own ARM emulator I wrote just for this reverse engineering task. I have not tried it. You can try to adapt it to make a 1014D version. But don't forget that all this code is unfinished and wrote up just to aid me during development.

About the 1014D firmware backup I wrote. It is a copy of the one I wrote for the 1013D, but lacks the touch panel configuration backup. For the rest it is practically the same. It writes a full backup of the FLASH for the F1C100s to the SD card and also a separate backup of the firmware part with the needed check bytes to be able to reload the firmware based on the update procedure the manufacturer uses.

After I f...ed up my second 1013D with that procedure, I decided to pursue the SD card firmware route.

And finally, yes, like I wrote before, a good starting point for you to make something for the 1014D would be to further reverse engineer the firmware of the user interface controller. Knowing the commands send to the F1C100s is the first step in to being able to mod the 1013D firmware.

And now the fun starts  8)

donwulff:
A scope with two 500MSa/s (What unit do we even use) is called 1GSa/s scope, I guess I need to make it clearer it's specifically 200MSa/s per channel. Note that definitions do give some "scamming" leeway, as some manufacturers quote the equivalent-time sampling Sa/s for example (Of course, I don't know if FNIRSI does even that, so yes, it's just completely made up), likewise with the bandwidth which in general is just saying amplitude drops to around 70% at that bandwidth (Though I'm sure the standard didn't intend imagined signal, and I haven't checked if the scope does even that).

We may (hopefully!) see about the protocol decode. It may be misleading to call this protocol decode, if I just need to read serial protocol I can use Bus Pirate or program another microcontroller to dump it. However for example I recently (or currently..) ran into a case where the serial bus will occasionally glitch, but not all the time, and no matter the price of the scope it's hard to get a scope to trigger to that. Do we call that protocol trigger or something? And for protocol decode we only need 2X the bit speed at most. But yeah, remains to be seen about the full capabilities.

I was figuring I'll have to access the SPI flash with the board powered on (In fact, I did with the Segger J-Link, but turns out it doesn't even support WinBond chips, read the chip ID though??). I was leaving trying it with Bus Pirate as last resort or until I get to the part on the threads, because the Bus Pirate documentation is pretty skimpy on what you're supposed to do with the 3v3 in that case. Plus I don't actually do anything with the FPGA flash right at this point. I can even leave the knob-controller firmware as is and just figure out how to interface to it from the Allwinner.

Hantek DSO2C10 is interesting, I couldn't find confirmation of the sample rate anywhere, most indications were it's another 200MSa/s (Looking at the specs, I think that's actually people misreading the specs which seem to indicate FFT bandwith limit is 20MHz? Or the Arbitrary Waveform Generator). If the cheaper model doesn't have BNC connector for AWG etc. it's also bit of work. By full bandwidth, do you mean 150MHz or 100MHz? Annd... of course we're somewhat more interested in full MSa/s per channel with both channels in use. AliExpress doesn't presently appear to have DSO2C10, and I'm seeing prices starting at 240 EUR's. Not to haggle over prices, <200 is pretty arbitrary choice, but if the specs and features aren't certain it's a meh at the start. Interestingly I note it has EXT trigger but only on the AWG model. The existing protocol support is quite nice indeed, so need to wait for someone to make open firmware for this ;)

SigPeak DSO2512g "Bandwidth 120M(ch1 only),dual channel mode is 60M" like what does that even mean? https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/msg4282615/#msg4282615 says it's with ONE of the 8bit ADC's like FNIRSI 1013D/1014D, so it's actually half the sampling rate, and hence practical bandwidth, and ~50MHz (-3dB) cutoff on frequency with just one channel.

pcprogrammer:
I'm no expert in scope semantics, but guess that the specified sample rate in the specification for a single channel might be what is used on the label. The Hantek DSO2 series uses the exact same hardware for the four available models. For some earlier versions it has been reported that the AWG components were not placed, but lately it seems they are.

About the price it varies. The link given in this post https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4611130/#msg4611130 showed ~218 euro when I looked just now.

I reverse engineered the schematics for the DSO2D10 I have, but know almost nothing about the software.

Another point, the equivalent time sampling you keep mentioning, unless you know more about it then I do, is not something that is possible on modern sampling scopes like the ones at hand. What I know about it is that to reconstruct a repetitive signal with a higher frequency (bandwidth) then your sampling rate you have to take samples at varying intervals to be able to do so. This means you have to shift your sample moment in time for every sample you take, and not at the same regular interval like done in the 1014D. For this shifting you still need some high resolution delay or fast clock signal. The Anlogic AL3-10 can work up to ~400MHz, but it takes a very careful planned design to make it work, and then still won't bring you GSa/s rates.

Looking at the Hantek in that respect, the ADC used in it is a ADC08D500 you also mentioned in your notes. To reach the 1GSa/s on a single channel the inputs of the two internal ADC's are fed from the same signal and they are clocked with a 180 degree phase difference. The connection with the FPGA uses four 8 bit buses, so every 4ns 32 bits are clocked into the FPGA and that is quite fast.

The 1013D and 1014D clock 32 bits in every 10ns. Still fast, but easier to get it right. I wrote a design for loading 125Msa/s DAC's using the AL3-10 and managed with the help of BrianHG from this forum to get it working. It was not easy and yet an interesting journey for sure.

About your use case with glitches in a serial data stream the way to catch these is to have a lot of sample memory and then zoom in to see if it is there. More expensive scopes like from Rigol and Siglent come into play here. Not something with at best 28KB. Sure you can create a new FPGA design and write software to continuous sample into the F1C100s memory. At least 16MB is free for this, but the sample rate will drop a lot. Sure all interesting experiments to do, but I have moved on to other projects for now.

donwulff:
On the heatsinks for the (unmarked) ADC, the ADC's don't heat very much here on my table keeping the scope running. I'm not sure if there's anything I cold do to really press them, I assume 10nS timescale will keep them running at max speed. I suppose heat-sinks might still not hurt. Nice thing with two channels is you can make changes to one and try to observe difference between them. Something to test out later, for sure. https://www.analog.com/media/en/technical-documentation/data-sheets/AD9288.pdf page 10 shows SINAD/SNR dropping quite precariously over room temperature, and I'm sure the Chinese clone likewise.

If DSO2D10 has ADC08D500 (Really? The list price is about 100 dollars apiece even at bulk) that's quite a steal, and if it's running Linux, who knows how easy it is to re-program. But that's another adventure as they say, though to be honest I didn't catch that it has protocol decoders (well, for standard protocols anyway...) already, so it might already do some of what I'm hoping. So I'll definitely keep an eye out for a good price. How's it I'm not finding any of this information on Google though, lol.

For now though, the FNIRSI is almost fully reverse-engineered (Minus the 1014D bits I guess?), sounds like a small community of knowledgeable people, some possible avenues of experimentation and improvement, and not too expensive to break. What could possibly go wrong, haha.

* EEVblog review at calls FNIRSI 1013D 1 gigasample/s equivalent-time sampling, however I'm thinking that must be in error, especially as you listen further to the video they say "but they're trying to do real-time sampling here because otherwise you need extremely good trigger ability" or so. Anyway as I say on the notes-file, I don't think you necessarily need nanosecond delays, because the sample-rate won't be exact multiple of the input "frequency", you'll just need to fold it over. But it's surely better to (attempt to) do than discuss it. I don't think you may even need the FPGA to do anything extra, since it's for repetitive signals. What can you fit on the MCU?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod