The RX888 is a $200 software defined radio that has a 16-bit ADC and tuning range from 1 kHz up to 1.8 GHz, with a bandwidth of up to 64 MHz between 1 KHz to 64 MHz and 10 MHz between 64MHz - 1700MHz. The design is based on the RX-666 which is turn was based on Oscar Steila's (IK1XPV) BBRF103 original open source hobby design. The product is designed and manufactured in China and is sold on Aliexpress and eBay without any official company backing it.
While on paper, the RX888 has great specs and a great price, it appears that the software driver support from the manufacturer has been extremely poor, and no one has really been able to get this SDR working in practice without it constantly throwing errors and locking up.
@Aang245 & @Ryzerth are the developers of the popular open source SDR programs 'SatDump' and 'SDR++'. They often get queries to support the RX888, but have been unable to get much working due to broken drivers and no support from the manufacturer.
They have written up a scathing several page document about all the problems they have with the RX888, in an attempt to bring awareness to the problems, and to hopefully initiate a push on the manufacturer to properly support the device.
In the document Aang245, author of SatDump, discusses the technical problems he's been having with the library and drivers, noting that almost all of the library drive code is broken, leaving him unable to support the device in his software.
When actually attempting to use the library on any of my machines, pretty much nothing would work reliably, and even when streaming samples would work, gain control, frequency or simply loading the firmware would fail horribly.
Later, I tried instead using the ExtIO code, maintained by the original project maintainers. By then, libsddc mentioned above had been merged into that main repo. Seemed great… Until I tried to use it. To put it simply : It was bad before, but now it relied on an entire ExtIO, segfaulted seconds after trying to do anything, and of course what worked before didn’t even anymore.
A good reason for that is that when the library was “merged”, it instead was made to rely on ExtIO internals, with barely half of the functions even implemented or working...
...In summary, it just feels like the BBRF103 hobby project commercialized without any thoughts about consequences or the ecosystem, and not even usability. Same hardware, usually sold as a premium, but really just a bunch of parts hacked together.
Ryzerth, author of SDR++ then adds the following reinforcing viewpoint:
The code quality in the library was absolutely horrendous. Functions were unimplemented, stuff was hardcoded everywhere and it was just generally hacked together. Same goes for the firmware, it seems to be a barely modified “streaming” example from Cypress (the FX3 chip manufacturer)...
...I have tried multiple times to reach back to the manufacturer on twitter but they have been radio silent since April 2022...
...Something else that bothers me is that SDR seems to be popular in the SWL community. A bunch of people recommend it when the performance can only be described as mediocre. Making a wideband HF frontend is an art, and you’re not gonna get any good result from something built down to a price like it. It’s a cool ham radio project, but not something that can be marketed as a commercial SDR. I’ve seen people claim that it has superior performance to Airspy and SDRplay SDRs, which is complete bullsh*t...
...This SDR has been unlike any other SDR I’ve had to support. Other manufacturers have clean APIs, proper drivers and libraries. It usually takes me at most a day or two to support the hardware properly. Being an “aliexpress special”, I guess I shouldn’t be surprised, you get what you pay for. All the money went into the BOM and none into the R&D and software.
This entire saga highlights the fact that software defined radios are not only about the hardware specs. The support and state of the drivers from the manufacturer is key to allowing third party developers to integrate the device into their software.