When connected to an RTL_TCP instance, there may be a brief set of data decoded from the previously tuned channel instead of the current channel. This can cause the Channel Settings FFT to skew the initial set of power averages and also can cause the "PVR Info" information ("O" during playback) to show the wrong MUX name and skewed/inaccurate quality metrics.

The problem could be solved in either the addon by dumping some initial data, or I feel more appropriately, by a change to RTL_TCP to dump any local/device buffers on a client disconnect.

Sadly OSMOCOM completely ignored my other requests for simple changes to RTL_TCP so I think any improvement will be limited to the "RTL-SDR Toolkit" built as part of this project.

I took out the WFM demodulator to save CPU% but I think it would be nice to have RDS and Stereo indicators in the channel settings dialog since the user can't hear the station. Also displaying the RDS channel (mux) name, if detected, might be helpful for the user.

I think I need to find out how well lower-end devices like RPi can deal with this dialog first, though, generating the FFT may produce enough of a CPU load on it's own. Once there is a Matrix distro that works on RPi to test, of course.

This should be very possible now by using a coefficient of variation percentage for the tuned frequency. This will need to look at 100KHz boundaries between 87.5MHz and 108.0MHz outside of North America so whatever the cutoff percentage ends up as needs to take 100Khz stations into account.

I'll have to analyze if testing the CV of a 200Khz station tuned +/- 100KHz is high enough to properly discard it from a scan.

The term 'gain' in the context of this PVR addon means the gain to be applied to the antenna by the RTL-SDR device. This isn't obvious and can be misconstrued as output audio gain, which is not really adjustable in and of itself.

Without the missing channel settings dialog, it's also unclear that to activate manual antenna gain one must disable automatic antenna gain. A proper UI would help illustrate this.

While still a (major) work in progress, the updated signal meter is unable to compensate for DC offset spikes anymore. Have a look at this: https://www.rtl-sdr.com/wp-content/uploads/2017/02/Getting-rid-of-that-center-frequency-spike-in-gnuradio_07.pdf?ffccfa&ffccfa, and see if it's possible to filter that out from the FFT plot without changing the device's center frequency.

Neither the HD Radio or DAB demodulators allow for offset tuning, which is what caused this. An alternative approach would be to add that support for both HD Radio and DAB.

The logic to generate a channel ID from the frequency is all kinds of wrong since the implementation of Weather (WX) radio. WX channels allow for three digits of the Kilohertz portion, the current channel ID only accommodates one digit here. This needs to be fixed for both Matrix and Leia.

The signal meter has no means to stop itself if the target device stops returning data. A normal playback stream would terminate.

If the device (FILE or otherwise) stops returning data, it would be better for the FFT to simply stop. Something indicating that the connection/stream has been lost might be nice, but probably isn't necessary. Just leaving the last FFT in the meter and never refreshing it is likely just fine.

The bug in libusb v1.0.24 that caused all the problems with Windows appears to have been fixed; once libusb v1.0.25 is released update and re-test on all platforms

I originally thought this was just the one channel but upon additional testing, multiple local channels are coming up with RBDS call signs that are incorrect and showing up as "K" instead of "W"; this is pretty clearly a bug in the RBDS decoder that needs to be figured out.

It would be kind of cool to support multiple RTL-SDR tuners here; it opens up possibilities for accessing Channel Settings or running a Channel Scan while the device is in use, speed up channel changes, etc.

I envision this as relatively simple to do in the Kodi Addon settings GUI, and not too bad to implement if all the tuners are connected via USB on the system running Kodi. RTL-TCP tuners, on the other hand, are likely to be a problem without enhancements to RTL-TCP itself.

US and Canada should be good to go, I need to find a reliable source of information as to how Mexico is encoding their call signs. It was actually kind of hard to find this for Canada.

I believe this to be a Kodi limitation, but it might be able to be solved by providing different channel identifiers and/or bogus EPG data from the radio PVR. Will need to investigate the options.

Hi,

Thanks for the time and effort on this. I have the RTL-SDR Blog R820T2 RTL2832U but after installing the zip addon in matrix (windows 10) run is greyed out. Can you point me in the right direction? I am able to play FM via SDRSharp. I'm also about to test on raspberry pi 400.

Thanks,

Even though proper (World) RDS support doesn't exist, I expected the RBDS implementation to work properly for the PI information. I've noted instances where the station name reported via 'Mux' in the PVR info (SIGNAL_STATUS) popup is just flat out wrong. Investigate if the existing US-only RBDS implementation is still flawed before expanding it to Canada and Mexico, and ultimately full RDS

When the PVR addon is connected via rtl_tcp, the user must stop playback and wait up to 10 seconds before selecting another channel, otherwise a 'recv() error' will occur.

This is a problem caused by an assumption in the PVR that needs to be addressed. When developing the addon I used USB exclusively, and there was no problem with initializing/uninitializing the RTL-SDR device at the stream level in Kodi. However with rtl_tcp, when the connection is closed, it takes the server up to 10 seconds to reset itself. In that time the client can't reconnect.

The best solution to this will be to cache off the internal RTL-SDR connection for a period of time, perhaps 30 seconds, and re-use it if the user opens another stream. There used to be a "SwitchChannel" API in Kodi that no longer exists that would probably have been a good solution too, but in current Kodi the expectation is that a proper pair of Open/Close operations will occur when switching channels.

The as-is implementation is kind of sad. Refactor everything to work more like the NRSC5 demodulator, the meter should not be responsible for the device in any way and needs to be able to sit between a demodulator and the channel settings dialog.

It was OK for analog radio, but moving forward modulations like HD Radio and DAB need to be able to detect multiple channels within an "ensemble" that sits on one center frequency. To accomplish that the demodulators will be needed. Changing the signal meter such that just it knows what the signal properties are upon creation and then requires the caller to pipe in the raw 8-bit samples it's working with should prove to be a much more flexible implementation.

This is a roadblock for DAB/DAB+.

While going through a major refactor for DAB support, I think it would not only be best to move "region" to a global/general setting, but I think it's prudent to prompt the user during load to choose between "North America" and "World" one time.

"North America" should default to allowing FM, HD Radio, and Weather Radio channels and disable DAB.
"World" should default to allowing FM and DAB and disable HD Radio and Weather Radio.

The user must remain free to enable/disable other modulations at their discretion, and nothing in the channels database should be removed based on this prompt.

This is coming up as a result of refactoring the "add channel" operation for DAB, which in turn affects Weather Radio. Moving forward, the user will need to select a named channel for these modulations and will not be able to enter a frequency anymore. The frequency selection dialog will need to know in advance what the region is to limit key entry of analog FM for "North America" and HD Radio to those same key entry restrictions.

DAB and Weather Radio are being converted into a selection dialog based on a new static database table that defines the available frequencies for these modulations.

Calculation of the signal strength to report to Kodi takes time. For example, running the addon on a Raspberry Pi 3B+ this math may account for 2-3% extra CPU utilization.

Many users will not care much about this, if they care at all. Every cycle counts on low powered systems, the default for this should be OFF. If the user is interested in this they can turn it ON.

While it's possible for the user to manually add channel logo images through Kodi, a better solution is to allow them to specify the URL as part of the metadata provided by the PVR addon.

This would be a fairly simple database change to make, especially since there are no Channel Add / Channel Edit dialogs yet (see Issue #4). The user can add the URL to the logo they want to use in the import/export JSON.

If no URL is set in the PVR database, the user can still use the Kodi interface to set it if they choose, but it's awkward to work with that interface.

This really only affects the signal meter as opposed to playback streams, but upon receipt of a raw sample dump for DAB(+), I noted that the signal meter will read and display all of the data as fast as possible and then freeze. The idea of the "file" device type is to allow debugging against raw files and is not intended to ever be exposed publicly. Putting in a throttle to return the data at the specified sample rate as if it were coming from a real device or RTL_TCP shouldn't be too difficult, and doesn't need to be 100% perfect.

Placeholder Issue to add support for DAB(+) channels to the addon. This will be more difficult for me than Wideband FM / Narrowband VHF / HD Radio since I am located in North America and have no access to DAB(+) channels unless I can manage to make my way to Europe again :)

I need to look into what's possible here. The RDS RadioText string will scroll in the "RDS" dialog if it's longer than the UI allows for, but the request is to have it do that during normal playback.

The RDS implementation in Kodi appears to have been somewhat abandoned as of Kodi 18 "Leia", but it may be possible to keep two copies of the RadioText string in the PVR addon and make it scroll by manipulating the character order and sending Kodi new RadioText packets more frequently. I think this would have a bad side-effect with the "RDS" dialog, but will have to see.

This one feels like a PR for Kodi rather than an addon change.

The concern is that the audio output will speed up and slow down as opposed to the expected proper cadence, similar to the 'wow' effect one might get from an old tape recording.

I believe this to be related to a 'solution' I put in place to solve something else. I switched to using a real-time program time stamp for the output stream to combat an issue with Kodi. Given that it may take different periods of time to process the input samples, this isn't accurate. Kodi is speeding up/slowing down playback to try and match the bogus timestamps.

The original problem this intended to solve will likely come back by undoing it -- if the client system cannot keep up with the output sample rate (100% CPU, for example), when the PTS diverges by more than 1 second Kodi will attempt to buffer/sync the stream, which is an operation that cannot succeed since it's coming in real-time. The end result is that playback will start to become choppy (or stop) and the user must stop and restart the stream to correct.

I haven't found a better way to deal with this, and it happens on some types of TV streams as well when the video bitrate is less than the audio bitrate. Best solution is probably to put it back the way it was and see what, if anything, could be done at the Kodi level to combat this when streams are flagged as 'realtime'.

On Android, the addon cannot currently access a directly attached USB RTL-SDR tuner device. The limitation will be revisited when libusb v1.0.25 becomes available. Current libusb cannot be upgraded beyond v1.0.23 due to problems on Windows platforms.

This is an issue with the Kodi GUI. A change was proposed to fix this that I will re-propose via a Pull Request.

Testing the channel settings dialog on OSMC (Matrix) revealed that if the addon is configured for a non-existent or otherwise unavailable TCP-based tuner it will lock up Kodi with no way to recover other than rebooting the system. While Channel Add / Channel Settings aren't expected to be perfect anytime soon they do need to be able to gracefully handle situations like this. This can't go "live" with a defect like this.

There is support in Kodi for full RDS data, as opposed to just the North America-specific RBDS data. The addon should support both standards as best as possible.

There needs to be a way to detect RDS vs. RBDS as well. In future versions of Kodi (Matrix and later), I think I can use the system language identifier to figure this out (en-us being RBDS, for example), but that doesn't seem available in Leia. For now, the addon will treat the RDS/RBDS setting of "Automatic" as RBDS.

The version of libANGLE the project uses is very old, but it was the last version that would compile with Visual C++ 2017. Now that the target platform is Visual C++ 2019, should be able to update this further.

This is a serious pain to do, and shouldn't have any effect on the application, so it's not a priority by any means. When I have a free weekend with absolutely nothing better to do.

Hi,

Will there be an Xbox version? I was able to get this to work with Windows 11, ubuntu, raspberry pi 400. I tried using the windows 10 x64 and 32 on the Xbox series x but the install fails.

Thanks,

While working through DAB, I found that signal overload is a significant concern. This probably applies to HD Radio as well but I hadn't noticed to date. What is happening on DAB is that overload causes the I/Q samples to max out at -1/1 (0/255), and the welle.io backend requires a certain amount of deviation in the signal to determine it's "sync" state and actually start processing the data.

For welle.io, at least, an overloaded signal may cause it to effectively lock up in an infinite loop waiting for a "sync" that may never occur. For now, based on the sample input I have (which is overloaded), I changed welle.io to not be so picky and it's moving along, but I think that tweak needs to be undone moving forward.

Implementation should be pretty simple; when converting the pair of 8-bit samples into Complex I/Q samples, if either input byte is 0 or 255 the signal can be assumed to be overloaded. Add a simple decrease_gain() function to the device implementation that "ticks" it down one notch from whatever it is currently set to. I feel there is no need or valid use case for the opposite operation -- detecting headroom in the signal and automatically increasing gain. That operation would make this more complex than it needs to be, this is not trying to be software-based "automatic gain control", it's trying to be something to ensure that noise spikes on very wide channels like DAB and/or HD Radio don't prevent those demodulators from doing their thing.

I feel like this should be something that the user should opt-in on as opposed to being the default and forcing them to opt-out. Option might be attached to the device settings if it appears to have any value for FM/WX, but I think it might be better served attached to HD Radio / DAB settings.

The Channel Settings dialog is basically unusable without a mouse; this needs to be fixed. With a Remote Control only system I can't do anything in here.

This is a Kodi problem that occurs when a realtime PVR stream does not contain a video component. This also happens with TV PVRs where the audio stream has a higher bitrate than the video stream (MusicChoice, for example). The current Kodi VideoPlayer component isn't very well equipped for this scenario, and any resolution is likely to be challenging.

The condition will clear after a "few" seconds but it can be a bit jarring for a new user to encounter. The audio speed will settle down, but it won't be immediate.

Documenting as a "bug-external" Issue here since it's bound to come up.

The OSMC platform is not reporting the LANG_FMT_ISO_639_1 string with the expected suffix ("-us", "-ca", "-mx"), which breaks RDS/RBDS auto detection. For now this can be a documentation-only issue by directing the user to set RDS/RBDS manually, but I'd like to understand if this is specific to OSMC or not.

Unfortunately, for the "kit" devices like Raspberry Pi 3, LibreELEC Matrix is not yet available so OSMC is the only package I've been able to test.

Will test on an Ubuntu 20 VM to make sure this isn't systemic to all *nix systems.

See (closed) xbmc/xbmc#21681.

I can work around this for now by implicitly setting the first subchannel as not selected, and detect "cancel" as having it come back in the same state, first subchannel false, all others true, which should be fine for HD Radio, I can't envision a scenario where a user would only want the secondary streams. For DAB, maybe not so much since they will be sorted alphabetically, but it still seems unreasonable for only the first sub to come back as false, at least while working around this.

I'd also like to change the "OK" button to "Add" if this is a new channel anyway.

It would be helpful to provide the end user with a way to capture a raw RTL-SDR data stream for diagnostic/debugging purposes. My vision here is a relatively simple Client Specific setting that would prompt the user to select from the list of existing known channels, specify a capture path, and specify a capture length (something like 30s, 1m, 5m, 10m).

The debug version of the addon would of course need the ability to read data from this capture as opposed to a USB/RTL_TCP device for the value-add ...

I've been working on this, but custom dialogs in Kodi are difficult. I think the addon will be hard to use on some platforms like Android if there is no UI-based way to manipulate channels.

The current Import/Export JSON function works for now, but having the UI elements in place would open the addon up to a wider audience of Kodi users.

The PVR addon will cause either a crash or a lock-up depending on the platform when changing channels in Kodi. This is not related to the rtl_tcp limitation referenced in Issue #3.

The actual bandwidth of an analog FM radio channel (at least in the US) is 258.722KHz (-129.361Khz - 129.361Khz), not 200KHz. While there shouldn't be any audio data out that far from the center, it does make the implementation more accurate and allows the signal meter to provide a better SNR reading.

The problem, at least here in the US, is that HD Radio screws with this. Hybrid channels can (and seemingly always) truncate the analog bandwidth back to 200KHz. A quick test bumping analog to 258.722KHz shows that I need to do some work on the signal meter before changing this in the code, since it would give very inaccurate information for Hybrid channels, the calculated "noise" frequency moves into the digital signal, which is pretty much always around 10dB lower than the carrier, making the displayed SNR worthless.

Leave it as-is for now. The only real downside to the current implementation is that users may not be getting the "best" SNR possible from the signal meter for analog-only channels. The process of maximizing the SNR they do see by adjusting the tuner gain is still a very valid and correct process to follow.

When DAB(+) comes into play with it's crazy 1500KHz bandwidth, the entire concept of the signal meter needs to change anyway :)

The reported "Signal Quality" and "SNR" are still bogus and I need to fix this before any type of general release. Additionally, the value reported in Channel Settings is actually Dynamic Range, not SNR as it would lead you to believe.

I want Signal Quality to equate to Dynamic Range. The ideal Dynamic Range should be around 48dB, but that's not really attainable. Something around 36dB seems better to equate to "100%", but I've gotten it as high as 40dB.

I want SNR to be a true SNR based off of the input I/Q samples. I'll have to figure out what to set as "100%" here and how/if I want to report that in the Channel Settings or not.

The 'tools' archive that contains compiled versions of the RTL-SDR tools as well as a compatible SQLite database tool should include a version number for clarity. While changelogs for external tools like these are not feasible, there still should be some way for the user to differentiate between what they are running and what has been provided.

Using the osmocom/sqlite version information may be unrealistic since they are packaged together, but if that could be made to work the user will have a very good visual clue that something changed and they should use newer tool(s).

This is mainly for my own purposes, and I can really only do the WD EX4100, but having an RTL_TCP application would be a heck of a lot better than SSH-ing into the thing and manually running it. Maybe it will be of value to others, but again, this is a purely selfish enhancement.

The signal strength and signal-to-noise ratio metrics the PVR is reporting are fairly bogus. Signal strength is a SWAG based on an imaginary logarithmic curve I made up that seemed reasonable and SNR is fairly useless since it's based on that SWAG.

There should be a more accurate/scientific way to report these values. SNR in particular seems fairly pointless to try and calculate without going really crazy and sampling the RMS of the whiteband between channels and comparing that to the RMS of the center frequency. A better option may be to emulate pvr.rtl.radiofm and report the SNR of the output samples rather than the input signal ..

The initial implementation for HD Radio with the analog fallback is "pretty good" all things considered, and there are channels where the analog and digital audio are simply not synced up (WWMX Baltimore, for example), but the rough cut at making this work can be improved upon.

The analog and digital DSPs generate a different number of audio packets given the same I/Q sample input. It should be mathematically possible to track this better and discard some audio samples from the digital signal if the analog signal is "ahead". I don't think there is any way for the reverse scenario to work, the digital signal being "ahead" of the analog signal based on how this needs to work.

I've added a setting that will allow the user to disable the analog fallback feature completely via cc4357f if it's too annoying.

Gross sync errors as were noted with WWMX Baltimore were confirmed as generally accurate using a real HD Radio receiver. That station is truly sending different audio on their analog and digital streams.