Click Analyzer issues

[VCC]

Hi mikroe team,
here are some questions and observation regarding Click Analyzer:

1. What is the latest firmware version on your side? Do you plan to open source it?

2. Did you ship multiple firmware versions with these boards?

3. What firmware version does the online documentation address? A range of versions or a specific (e.g. latest) one?
Do you have a newer version of the documentation? The current one is hard to follow. Please review grammar, typos, command details, installation (including OS driver), doc version and overall doc structure.

4. The documentation mentions some hardware serial ID, from the "GET PRODUCT" command.
There is no such field: {"product":{"name":"Click Analyzer - MikroE","version":{"HW":"1.0","FW":"1.05","COMM":"1.05"}}}

5. Is there a help command (from the GET CMD_INFO category) for Scope (the analog scope)?

6. The SCOPE command appears to be unsupported, at least in firmware v1.05, since entering "SCOPE PIN=1 NUMSMP=10 FREQ=10K;" (without quotes), the board returns an error (for all respone formats: BIN, JSON, XTERM).

7. For digital voltmeter (DVM), when set to JSON response, the pin index is reversed: Pin1 at index 13, Pin2 at index 12, Pin 14 at index 0.

8. For the LS command, the minimum/maximum number of samples is different between JSON and BIN response formats (i.e. 1/100 vs. 1/542) as reported by "GET LS_INFO" command.
However, for BIN format, the firmware responds with valid data, only if the NUMSMP field is set to less than 255 samples. Values between 256 and 542 seem to be updated as modulo 256 in firmware.

See also https://libstock.mikroe.com/projects/vi ... nalyzer-ui

Thank you

[hexreader]

Thanks for sharing your libstock utility.

Sadly there seems to be a severe trojan detected by WIndows 10 defender (against your .exe file)

Would you investigate please?

Thanks

[VCC]

Hi,
thank you for pointing out about the trojan. It seems that a simple usage of Win32 API can be detected as malicious. The scope UI component was using calls to GetAsyncKeyState(VK_CONTROL) and GetAsyncKeyState(VK_MENU), to display colored samples when Ctrl or Alt key were down. It looks like the same function is used by malware for keylogging. As far as I know, Microsoft mitigated this vulnerability, by limiting what the function returns when the application/window calling it, has focus or not. Windows Defender fails to detect the simple fact that these two calls are not monitoring the whole range of available keys, but simply regards any call as malicious, even when checking for Ctrl or Alt .

Here is what other antimalware products have to say: https://www.virustotal.com/gui/file/94f ... detection

Anyway, I replaced the GetAsyncKeyState calls with the built-in mechanism of detecting key presses (which is based on message passing), and uploaded a newer version. The only limitation with this approach is that the scope component has to be focused to react to key events. Reacting to Alt key was disabled anyway, because it is part of editing waveforms, which is not used in this application.

[hexreader]

Many thanks

[VCC]

Hi,
@mikroe team. May we know the answers to my questions, from the first post, please?
Thank you

[filip]

Hi,

As far as I know there is only firmware for this board, but I will check this. The documentation should address this firmware.

I must check the functionality / commands by myself and get back to you.

Regards,
Filip.

[VCC]

OK, thank you.

[VCC]

Any news on these?
Thank you

[VCC]

Just wanted to say "bump".

[VCC]

Hi mikroe,
any news?

Thank you