Fix renderer for v1.7x

[JonnyTech]

Reverted the value of SWEEP_POINTS because no graph was being drawn

[berkon]

@JonnyTech, that's very strange. I just tested with 1.7.3 and the graph is drawn without any issue. The intention to set it to -1 (more or less undefined) was to let the software detect the number of sweep points automatically by reading that information from the device. I've introduced this change on request of a RackPro user. That device is capable of drawing more than 112 sweep points. Thus it seems odd to keep it hard coded to 112.

[JonnyTech]

I understand, and I agree with you, but -1 was a breaking change for me. Any value >0 worked, not sure why autodetect did not work..

[berkon]

Indeed really strange. Did you get an error message on the console? What RF Explorer model are you using?

[JonnyTech]

No console error message. Everything was working apart from the blue line drawn on the graph. Tested using my handheld analyser on Debian (laptop x64) and Raspberry OS (Pi 3b ARM).

[berkon]

Indeed it looks like there is an issue on Linux. Its no quite clear yet what causes it. The issue is not always reproducible, but I was able to find a way how I can reproduce it in most of the cases. I'll have to check/rework the section that discovers the device parameters.

I found a simple workaround: When no graph is seen, simply simply zooming in/out or change the frequency range with the arrow keys or the mouse scroll wheel. In my case this always brought back the graph.

I will open an issue here on GitHub to track this problem.

[JonnyTech]

Ah, I should have specified Linux initially - although when testing I tried both of your workarounds but they did not work for me.

[berkon]

@JonnyTech, I've pushed a fix of which I hope it should solve your issue. Can you please pull the changes and check if it indeed solves the problem? Then I'd create a new official release. I tried on Windows, Mac and Linux and couldn't see any problems.

[JonnyTech]

Thanks @berkon, looks like you have been busy with this. But I am afraid that the current code fails to connect to the device. The v1.7.3 release does find the hardware. Tried rebooting both computer and RFE device with no success. This is from Debian: Is there any way of obtaining a log for you to analyse?

What RF Explorer model are you using?

Sorry, I missed this question. The display states: RF Explorer Spectrum Analyzer ver 01.33 13-Apr-21

[berkon]

@JonnyTech, hmmm strange. Can you let me know the exact Debian version you are using? Then I'll try on Debian as well. On Ubuntu I can't see any issue. Just one note: My impression is that the RF explorer (I have the same device), has some firmware issues. If flooding it with requests, it doesn't recover anymore. That means that when sending many configuration requests quickly after each other, it stops sending config answer back (I discovered this during my tests). My tool relies on this config data, because it contains the number of sweep points which is required to initialize the graph. If it doesn't get it, you'll see exactly that error which you mentioned. The only way to recover from this situation, is to stop the software and un-power the device for at least 10s (it obviously has some capacitors which must be discharged fully). Then start it up. Now it is important to wait before starting the software until the "Pre-Calibration" string has disappeared from the display (if starting the software earlier it will hang and keep showing this string on the display until restarted). So now start the software.

No, there is no debugging file. All debug output is curently on the console. I will improve this in future so that we get a real logfile which I can analyze.

[JonnyTech]

@berkon thanks again.. I do wait at least 10 seconds, then wait for the pre-calibration, but still no connection. I have v1.7.3 installed in another folder and when I start that then it detects it every time. Hmm, strange indeed. I shall continue testing when I can.

My laptop currently has MX Linux 19 XFCE x64 "ahs" (https://mxlinux.org/download-links/)

$ uname -a
Linux WOPR 5.10.0-5mx-amd64 #1 SMP Debian 5.10.26-1~mx19+1 (2021-04-01) x86_64 GNU/Linux

[berkon]

Guess what! I've just installed your version of MX Linux on a physical machine and the tool worked without any issue. I even didn't have to add the username to the "dialout" group (which is necessary on Ubuntu). I'm running out of ideas ;-) ... let me think it over once more ...

[JonnyTech]

Wow, above and beyond! What is different on mine? Different versions?

$ cd ~/Downloads/RFExplorer/wireless-microphone-analyzer-1.7.3
$ npm --version
7.24.0
$ node --version
v16.10.0
$ npm run-script start_linux
> wireless-microphone-analyzer@1.7.3 start_linux
> node_modules/electron/dist/electron .
(node:12358) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
$ cd ~/Downloads/RFExplorer/wireless-microphone-analyzer-master
$ npm --version
7.24.0
$ node --version
v16.10.0
$ npm run-script start_linux
> wireless-microphone-analyzer@1.7.4 start_linux
> node_modules/electron/dist/electron .
(node:12208) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
$ 

[berkon]

Just to be sure ... I don't think that's an issue, because you said it works with older versions ... but can you please do:

cat /etc/group | grep dialout

and check if your username is listed there? It should look like this:

dialout:x:20:<your username>

[berkon]

FOUND IT!!! As soon as I install the latest Node version 16.10.0 I'm getting the same error! Need to check why ...

[berkon]

Oh no, its not related to node 16 (would have totally surprised me). It looks, it only works once. Then I have to do the procedure described above (power off). Then again it works once. Really strange. I'll check ...

[berkon]

Looks like this is an issue specific at least to MX Linux. As said, I can't see it on Ubuntu. Ok, next try. I've pushed a patch which improves the behavior on my MX Linux a lot. In some rare cases I'm still getting this hang - behavior, but then the power-off procedure above always helped to get it back in service. If it doesn't help for you, I'll have to check the exact command sequence/timing which they are using on their original Windows software, but that will require more time.

[JonnyTech]

Shall test soon, FYI the reason for using MX is that by default it does not boot with systemd - for other software that I use. Could it be a systemd/sysvinit issue?

[JonnyTech]

@berkon great work!

The new version seems to work, and work consistently every time, I no longer have to keep powering off the unit. This is on x64 Linux, shall test on a pi when I get my hands on one again.

I am getting frequency error message when I start or switch bands / presets. Should I worry?

Going to give it to my friend to test (I am just a computer guy, it is him that wanted to get it working) so will report with feedback once I get some.

Many thanks again for all of your efforts :)

[berkon]

Hey @JonnyTech, your very welcome! I'm very glad to hear that it helped! In my main profession I'm working as a software developer, and as a sw developer I hate bugs by nature, especially when the bug is located in your own little GitHub project. :-) You most likely know this feeling. :-) So thanks a lot for point out this issue. Yeah and my second job is wedding-DJ. :-) So that's how I came into this topic regarding wireless microphones. In rare cases I'm also doing some corporate events, and its very bad if the CEO can't be heard properly. ;-) So I bought the RF Explorer to scan/check whether there are any interferences before an event starts.

Nice, so just let me know if your friend can confirm that it works. I'll create an official build then.

Regarding the frequency error: I must admit that I only tested with the right module (right antenna) which covers a big range. Are you using the left one (big antenna for lower frequency ranges)? So as stated in the message this error pops up when trying to show a range which the antenna/module can't scan.

Can you please send me that string that shows up on the console immediately after startup (could be that it is shown twice ... that's not a problem). That string in fact is the read-back of the settings. Then I can see which antenna module is active and whether the frequency ranges match.

[JonnyTech]

Aha,I did not connect any antennas, did not realise that it could detect them - I shall get the unit again and plug some in, just me being stupid, sorry..

[berkon]

No no, it can't detect them! The question is just which module is selected via the device's menu. My device can handle 240 - 960 MHz on left module and 15 - 2700 MHz on the right module. You said that you are scanning 5GHz as well. That would mean that you device differs from mine. Maybe there are still some differences regarding the handling of the sw commands.