2.0.0 System requirements

[barjac]

I have had a report from a Windows 10 user which may be useful in helping to specify minimum system requirements for RADE - or may even be a bug.
He is using Win 10 and has RADE working OK on this machine:

However this machine launches into the GUI fine but crashes on clicking Start.

Sightly off topic I have installed 2.0.0 on a RPi4b with 8GB ram and it never crashes but does not decode anything legible in RADE mode.

[Tyrbiter]

I think that the RPi system issue is well ahead of the development situation at present, but if you can identify what is going wrong using console output error messages you may be able to correct the problem.

The Windows report is useful but doesn't mention how much RAM is in the system. A 3rd generation i3 (10 years old?) is likely to be struggling so anything that can be done to help it out would be sensible.

For now development is concentrating on Windows as it gets the best coverage for the effort expended, however it's not the time to concentrate on performance using less capable hardware as the RADE code is not yet implemented in C.

[tmiw]

I mean, closing without any meaningful feedback as to why isn't helpful either, so that should be fixed. Definitely needs more investigation in any case.

[Tyrbiter]

If the i3 system can have additional RAM added it will give a new data point, but some older systems may not have the ability to add more. Feedback on this would be useful to tell us why this system is crashing.

[tmiw]

I was looking at the RADE code and I think I can at least make it not quit on error so we can get a better idea of what's going on. @drowe67, can I go ahead and open a PR to make that change?

[drowe67]

@tmiw not now - this is precisely the sort of rabbit hole we need to avoid right now. Lets stay focused on maturing RADE V1 for modern Desktop machines. I'm OK to add to drowe67/radae#28 for PLT level consideration in the next phase of development.

[tmiw]

@tmiw not now - this is precisely the sort of rabbit hole we need to avoid right now. Lets stay focused on maturing RADE V1 for modern Desktop machines. I'm OK to add to drowe67/radae#28 for PLT level consideration in the next phase of development.

I should clarify. Currently the RADE API just calls exit() on error which on Windows doesn't provide sufficient time for errors to be reported (even if only via the console you can enable via Tools->Options->Debugging). The absolute minimum change would be to flush stdout/stderr and add a, say, 5-10 second sleep before exiting to allow screenshots of that particular console window to be taken. By doing so, we'd properly be able to triage this particular issue (especially since this is at least the second report I've gotten of RADE causing freedv-gui to close on startup for Windows users). Otherwise, the alternative is that I get on a call and walk someone having this issue through installing a debugger and attaching to freedv-gui to get a stack trace or other actionable output, which would suck up more time IMO.

Of course, we really should improve error handling in the long run, but I'll go ahead and add that to the v2.0 list you linked above.

[Roturbo]

Hi,

Some users don´t wait for the Dos window to finish by it self, and they close it
before it ends, this lead to missing things, were i found one PC that i have to
help installation because FreeDV was working fine in TX but crash or not
decoding on RX,, the user just close the window before time.

Some friends have old pc´s, and just for reference the actual FreeDV
works on low machines as Dual Core E6750 @ 2.66Ghz

Desktop
Processor Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
RAM 3,50 GB (3,36 GB usable)
win10 Pro 64 bits

---

Laptop
Processor AMD Athlon Silver 3050U with Radeon Graphics 2.30 GHz
RAM installed 4,00 GB (3,38 GB usable)
win10 home 64 bits

[barjac]

If the i3 system can have additional RAM added it will give a new data point, but some older systems may not have the ability to add more. Feedback on this would be useful to tell us why this system is crashing.

The working system (Sandy Bridge) has 16GB and the non-working (Ivy Bridge) has 8GB.
Note that these are both i3 64bit systems.

[tmiw]

If the i3 system can have additional RAM added it will give a new data point, but some older systems may not have the ability to add more. Feedback on this would be useful to tell us why this system is crashing.

The working system (Sandy Bridge) has 16GB and the non-working (Ivy Bridge) has 8GB. Note that these are both i3 64bit systems.

FWIW FreeDV only seems to be using a few hundred MB of RAM on my machine when set to RADE (just listening, no signal on frequency). I would think that'd be well within the capabilities of an 8 GB machine, at least immediately on startup.

[Tyrbiter]

If the i3 system can have additional RAM added it will give a new data point, but some older systems may not have the ability to add more. Feedback on this would be useful to tell us why this system is crashing.

The working system (Sandy Bridge) has 16GB and the non-working (Ivy Bridge) has 8GB. Note that these are both i3 64bit systems.

FWIW FreeDV only seems to be using a few hundred MB of RAM on my machine when set to RADE (just listening, no signal on frequency). I would think that'd be well within the capabilities of an 8 GB machine, at least immediately on startup.

My immediate thought was that this might be a very marginal machine with 2GB of RAM, some of which will be used by the internal graphics. 8GB suggests something entirely different, but I don't know what exactly. I wonder if there is some anti-virus activity preventing access to some directories.

[barjac]

He has tested with AV disabled and no other large applications like browsers running, with no change.

[tmiw]

He has tested with AV disabled and no other large applications like browsers running, with no change.

I can't really do much to debug this right now (especially since the long term plan is to port RADE to C) but I can tell you a workaround I had to do in a Windows VM that I was using which may help. Basically, open Registry Editor and make sure HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders has the following keys:

• AppData
• Common AppData
• Local AppData

If one of these is missing, add it as a "string" key with a path that makes sense (i.e. if "Common AppData" has C:\Users\User\AppData\Roaming, make sure "AppData" also has that value). You'll likely need to either reinstall the preview version of FreeDV after doing this, or you can try rerunning C:\Program Files\FreeDV-2.0.0-devel-2024-10-18-b6d65bc2\bin\rade-setup.bat as administrator.

[barjac]

I have pointed two users to the above and both are either afraid of touching the registry or just too confused by it. Understandably.

I am currently using a LIVE (persistent) Mageia 9 linux system on a USB stick with freedv-2.0 installed and it is performing perfectly on air, so I am considering providing an image for this on request for people with this Windows issue to test/use.

The gz compressed image is currently around 9GB for a plasma install and would fit on a 32GB stick (currently on a 64GB for testing), but this could be reduced with a lightweight D.E.

WIP... :)

[tmiw]

I think the Windows issue should still be solved in some manner, so hopefully those willing to use regedit.exe will be able to provide some feedback soon (or we get to the point where Python isn't needed anymore, making this moot).

BTW RADE seems to work on the Raspberry Pi 5 using automated tests but I can't comment on audio quality, so this is definitely not an endorsement.

[barjac]

I tested again in a Pi4B today using a recording of a RADE signal on the system to avoid the load of a browser. It decodes fine but only 50% of the audio i.e. about 1 sec on and 1 second off. I can recognise the person's voice and the quality of what is decoded is good. With a browser running it gets much worse.
I have used the Pi as a remote SDR monitor but no longer possible - shame.

[tmiw]

@barjac, I was testing on another Windows 10 machine and it turned out to have the issue you were describing. I was able to fix it by installing the VS2019 redistributable package: https://aka.ms/vs/17/release/vc_redist.x64.exe. Try suggesting that to the people you've heard issues from and see if that helps? If so, I might be able to include it in the next installer.

[Tyrbiter]

I had a quick look at this, it shows up as the MS Visual C++ redistributable 2015-2022 x86_64 package, it's already installed on my Windows 10 machine which is probably why I have not see this problem with the RADE freedv-gui.

[barjac]

@barjac, I was testing on another Windows 10 machine and it turned out to have the issue you were describing. I was able to fix it by installing the VS2019 redistributable package: https://aka.ms/vs/17/release/vc_redist.x64.exe. Try suggesting that to the people you've heard issues from and see if that helps? If so, I might be able to include it in the next installer.

So far 50% success from 2 cases, one more yet to report back. :)

[barjac]

I tested again in a Pi4B today using a recording of a RADE signal on the system to avoid the load of a browser. It decodes fine but only 50% of the audio i.e. about 1 sec on and 1 second off. I can recognise the person's voice and the quality of what is decoded is good. With a browser running it gets much worse. I have used the Pi as a remote SDR monitor but no longer possible - shame.

Further to this I have now tested with ms-rade-cport on the RPi4 and its no better than before. Only very short bursts of unintelligible decode. Around 25 lines of WARN...from main.cpp:3094: RX FIFO full.
These are interspersed with single lines of the usual state:.... which appear every few hundred msec.