Author Topic: Reverse engineering FNIRSI-5012H (Read 110477 times)

alx359 · « **Reply #125 on:** January 22, 2020, 05:51:13 am »

Got mine 5012H the other day. @Alex: are you still motivated to finish and release your FW now that the hardware-changed & FW-updatable 1C15 seems upcoming so soon?

ataradov · « **Reply #126 on:** January 22, 2020, 05:55:49 am »

Yes, I'm still working on it. It is getting close to release. I expect initial release to happen this weekend or the next weekend.

I finished calibration mode and majority of vertical control stuff last weekend.

I don't care much about their new hardware. I'm just not interested at all. Plus I know that their software will be unusable crap. And better hardware will not save it.

ataradov · « **Reply #127 on:** January 27, 2020, 02:42:35 am »

The source code is now public! You can have a look at it here https://github.com/ataradov/open-5012h

It should be considered to be a beta or even an alpha version. The main functionality is there, but it was not tested apart from testing I did during the normal development process.

The main thing that is missing is menus of any sort. So all the settings that depend on the menus (like 1X/10X or backlight brightness).

1X/10X mode is also not implemented yet, all values are shown in 1X mode.

All of those things and more features are coming. I just wanted to release some code, and what I have now is releasable.

Overall I'm very happy with the results. This is a solid platform and a lot of functionality can be added on top of that. After the basic menus and stuff like this, I'm considering implementing serial decode, and even serial console mode, where entire screen just turns into a console. No trace is displayed, but just the received characters. Spectrum analyzer is also a possibility, but it may take a while.

I want to implement the necessary parts and then use it for a while and implement things that are useful in real life.

BravoV · « **Reply #128 on:** January 27, 2020, 02:46:33 am »

Alex, just a suggestion, update the 1st post with the latest update you've posted and the upcoming onces, as I believe once matured, this thread will be drowned into gazillion pages and makes new comer hard to track as they need to read every posts.

ataradov · « **Reply #129 on:** January 27, 2020, 02:49:07 am »

Quote from: BravoV on January 27, 2020, 02:46:33 am

Alex, just a suggestion, update the 1st post with the latest update you've posted and the upcoming onces, as I believe once matured, this thread will be drowned into gazillion pages and makes new comer hard to track as they need to read every posts.

I've put the link in the first message already. This is the first thing people finding this thread will see.

ataradov · « **Reply #130 on:** January 27, 2020, 03:55:03 am »

A few comments on the architecture. This will eventually go into the documentation, but I'm too tired to format that appropriately.

First of all sample buffer size. There are two buffers. The primary buffer is 128K samples and this is the buffer filled by the DMA. At the end of the capture (when necessary number of post-trigger samples were captured), the data from this buffer is decimated 4 times and transferred into 32K buffer. After this transfer, in Auto and Normal modes, the DMA goes back to looking for the trigger.

So the contents of the 128K buffer are gone. This makes for the shortest blank time. The disadvantage - in Auto and Normal modes the effective sample rate is 1/4 of the configured. The only way to use full sample rate is to use Single mode.

This is not a real issue in practice. It all feels good.

Another difference compared to what you would see in other scopes is trigger positioning. The trigger here can only be positioned in the sample buffer. So the sample rate is selected automatically to fit the currently displayed window and the trigger point inside the sample buffer.

You can also limit highest sample rate value if for whatever reason you want to capture more data than necessary according to your current window.

And another thing is that because trigger search happens in the software, the trigger level is limited to the displayed vertical span. Trigger level can never go outside of the visible window.

For the same reason it does not move with the vertical offset. So if you had vertical offset at 0V and trigger at 1V, and then you move your vertical offset to -3V, you will end up with a trigger at 4V. This part is mildly annoying, but in real life you don't need to adjust vertical offset too often, so it is probably fine.

Also, if you are adventurous and actually want to try this firmware, let me know, I will provide all the help I can.

I'm using some questionable programming adapter. I'll think about making a dedicated PCB for that.

ataradov · « **Reply #131 on:** January 27, 2020, 08:01:00 am »

Quote from: GeorgeOfTheJungle on January 27, 2020, 07:56:33 am

What's "dual channel mode" ?

125 MSPS sampling rate. In this case two ADC channels running at 62.5 MSPS are combined.

The wording on the documentation could be better. I threw it together in an hour because I wanted to release this stuff before the end of the day.

Quote from: GeorgeOfTheJungle on January 27, 2020, 07:56:33 am

Can't upload the FW via USB to the blank new GD32F407VET6 soldered in the scope? If not, won't you sell us at least a few pre-programmed chips, please?

No, you need a programmer. There are plenty of cheap ARM programmers out there.

I can't really pre-program a chip without some sort of a socket. Also, there is no point. The firmware is so beta at this point that you will want to change it, so having a way to program the device at will is really necessary for this.

USB connector does not have actual USB signals in it, so USB boot is not an option.

You can try to identify good points to tap into those other interfaces, of course. But there are no obvious test points, so it might be hard. Much harder than actually finding a programmer.

ataradov · « **Reply #132 on:** January 27, 2020, 05:45:53 pm »

Yes, USB connector is what I was using all this time. It alone is enough to program the device.

I still don't want to be in a business of shipping devices. That's sounds like a recipe for disaster.

I'm using my own tools, so I don't know the extent of support for those GigaDevice devices in other tools. You need to research that. The hardware will probably fine. The question is what tools to use.

Bigger flash size should not be a problem. But is it really worth for a $1 difference? You only need a few devices.

Martinn · « **Reply #133 on:** January 28, 2020, 05:33:23 pm »

Hi Alex, I've been watching this thread for some time... thanks a lot for making this available! I think when the Chinese are back from holiday, I'll order a scope and a couple of the GD32F407.
Nice to see some code without the usual STM32 HAL bloat.
I guess I can manage (with enough effort) to put your code into an Truestudio (CubeIDE) or IAR project (I am using those regularly), but it would help a lot if you could publish a compiled binary along with the source code (particularly as I believe your sampling code will be time/compiler optimization critical).
I wonder if STM32CubeIDE or the STLink tool can handle GD32 devices directly.

- Martin

thinkfat · « **Reply #134 on:** January 28, 2020, 05:45:03 pm »

I just read your remark about the backlight better be at 100% brightness for the calibration.

ataradov · « **Reply #135 on:** January 28, 2020, 05:55:56 pm »

Quote from: thinkfat on January 28, 2020, 05:45:03 pm

I just read your remark about the backlight better be at 100% brightness for the calibration.

What is wrong with it? I don't think there are actual issues, but backlight is dimmed though the PWM on the LDO enable input. Why not eliminate all sources of the noise, even if they don't actually contribute much or anything at all?

Again, I have zero evidence that BL PWM actually adds noise. Having charger plugged does add noise.

I will publish binaries at some point.

thinkfat · « **Reply #136 on:** January 28, 2020, 06:46:46 pm »

Quote from: ataradov on January 28, 2020, 05:55:56 pm

Quote from: thinkfat on January 28, 2020, 05:45:03 pm
I just read your remark about the backlight better be at 100% brightness for the calibration.
What is wrong with it? I don't think there are actual issues, but backlight is dimmed though the PWM on the LDO enable input. Why not eliminate all sources of the noise, even if they don't actually contribute much or anything at all?

Again, I have zero evidence that BL PWM actually adds noise. Having charger plugged does add noise.

I will publish binaries at some point.

No, no, it's all good. The

was towards the hardware design. I interpreted your remark such that the backlight circuit produced enough noise to upset the calibration when not at full brightness.

ataradov · « **Reply #137 on:** January 28, 2020, 06:51:53 pm »

Ah, ok. No, it is actually surprisingly non-intrusive. I expected that PWMing LDO enable pin at 120 Hz would not be great, but it seems to work fine. That being said, I ran at 100% backlight most of the time. The dimming was added just last week. So it may show itself.

On the other hand, I'm not sure it makes sense to run it at less than 100% anyway.

states · « **Reply #138 on:** January 30, 2020, 09:27:15 am »

https://gd32mcu.21ic.com/en/index

GigaDevice Vendor documentation

Evi · « **Reply #139 on:** January 30, 2020, 09:41:13 am »

I guess, the first thing that must be done before any reverse engineering is to correct input resistive divider to remove undercompensation on 2V range. Here(https://mysku.ru/blog/china-stores/73960.html#comment3255111), an attempt was done, in rather clumsy manner, which does not fully remove the problem.

ataradov · « **Reply #140 on:** January 30, 2020, 05:12:45 pm »

Yeah, I'm divided on what to do with analog part.

Also, it appears this is one more variation of the board. With one relay, but only 6 optocouplers.

OwO · « **Reply #141 on:** January 30, 2020, 05:21:43 pm »

The hardware is very simple and all the parts are easy to get, so have you considered redesigning the whole thing from scratch "properly"? It seems it wouldn't be too hard and you can get the cost close to the sell price of that thing, even in prototype quantities. FPGAs are also cheap (< $5 for a spartan 6) so you could consider that path as well.

ataradov · « **Reply #142 on:** January 30, 2020, 05:28:02 pm »

Quote from: OwO on January 30, 2020, 05:21:43 pm

The hardware is very simple and all the parts are easy to get, so have you considered redesigning the whole thing from scratch "properly"?

Yes, I did consider that. I need to give attention to some other projects, but redesigning this thing from scratch is definitely on the list.

On that note, if anyone has good and proven designs for ~40 MHz front-end, I'd like to see them to get a general idea of what to do.

wasp09 · « **Reply #143 on:** January 30, 2020, 11:52:59 pm »

Quote from: ataradov on January 27, 2020, 02:42:35 am

The source code is now public!

Thanks. I'll see if I can replace the MCU or add an font end, when my 5012H arrives. The source code should give me an idea how the software triggering works.

My oreder cleared Customs on te wrong side of Canada on Jan 13, supposed to be delivered on Jan 17 but I am still waiting for it 2 weeks after. $:=\$

wasp09 · « **Reply #144 on:** February 08, 2020, 02:17:57 am »

Finally mine arrive today, 51 days after order. CanadaPost blew its delivery standard by 3 weeks.

It turns out a FNIRSI with single relay and smaller battery inside. I found it restarted on its own quite often while I was playing with it. It also hanged in autoset, I guess, when it didn't know how. It also picked up some noise, sine wave at around 78MHz, when it was charging. The noise only appears at 10/100V input setting and most obvious at 6nsec timebase. Hard to figure out why it does not show any at lower input settings. I don't have another scope which can handle that frequency to troubleshoot the input stage and amp. It would be an interesting exercise.

Those may be battery or condensation related after a long cold journey. I'll charge it up and keep it warm tonight.

ataradov · « **Reply #145 on:** February 08, 2020, 02:23:22 am »

The noise from charging is always there. I would strongly advice against using this device while it is plugged in. This is one of those cases where you should not trust the design to not kill you.

Johannsen · « **Reply #146 on:** February 08, 2020, 11:29:55 am »

Hi can you write a sentence in your github project how to program this new chip? Which tools software is needed?

wasp09 · « **Reply #147 on:** February 08, 2020, 05:00:12 pm »

The test probe wasn't attached when I saw those noise while charging. I can't tell the status of the battery unless I power it up. It has to support power up charging I suppose.

Mine still hangs showing "autoset" everytime when I press the "auto" button and there is a valid input signal. If there was no input, it survived and set the timebase to 500us. The scope wasn't plugged in.

Is it FW, something like stack over or watchdog kicking in when it is too busy? Or do I get a lemon with bad hardware? Do you know of any debug logs accessible on the unit?

Mine is far from what a realtime scope does. No single shot at slower timebase. Haven't figured out how to scroll horizontally. Basically the scope picks the window it wants to show. The time it covers is too short and I have little chance of hitting the piece I want to see.

It looks great but it is more a toy than a tool for now.

ataradov · « **Reply #148 on:** February 08, 2020, 05:52:44 pm »

Quote from: Johannsen on February 08, 2020, 11:29:55 am

Hi can you write a sentence in your github project how to program this new chip? Which tools software is needed?

Yes, I will. I totally forgot about that. So far I've been using solution that is really hacked together. I will make a proper adapter and add instructions.

One of those connectors https://www.ebay.com/itm/10Pcs-Mini-Micro-USB-5-Pins-Male-Connector-Port-Solder-Plug-Plastic-Cover-Useful/293118487488 or a simple cut off from a micro USB cable would be required. Note that because connector is deep, in case of a micro USB cable you may need to cut a bit of the plastic close to the connector, so it fully seats in the scope.

Then you will need any SWD programmer. I've used my own, because I have them (https://www.tindie.com/products/ataradov/cmsis-dap-compliant-swd-debugger/). But you can use any. There are dozens, including implemented on Arduino.

In case of a programmer it is important to remember that there is no reference voltage (+3.3V) on the outside connector. So if your programmer has level shifters and uses target voltage as a reference, then you will have to supply this voltage externally somehow.

ataradov · « **Reply #149 on:** February 08, 2020, 05:55:38 pm »

Quote from: wasp09 on February 08, 2020, 05:00:12 pm

The test probe wasn't attached when I saw those noise while charging. I can't tell the status of the battery unless I power it up. It has to support power up charging I suppose.

Yes, the noise is induced though the ground. It is fine to have it on, as long as you are not measuring anything , and generally staying away from the BNC connector. Again, it is 99.99% paranoia, but I personally don't want to take even 0.01% chance.

Quote from: wasp09 on February 08, 2020, 05:00:12 pm

It looks great but it is more a toy than a tool for now.

I really have no idea about its default firmware. I've only used it for 10 minutes to figure out it was a joke.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Reverse engineering FNIRSI-5012H (Read 110477 times)

Share me