FYI for Sensorgnome V2 users: the same issue affects Raspberry Pi based Sensorgnomes. The SensorGnome V2 software has similar patches (more below). Due to the diverse variety of HW it’s a bit more difficult to characterize which combinations cause issues. I now have 4 FCDs to test with thanks to Birds Canada (!) and hope to do some more testing soon. Some known issues:
- the raspberry Pi USB subsystem can provide at most 1.2A of power (total for all 4 ports), thus any configuration that exceeds this needs an externally powered hub (using a non-HAT cell modem certainly does), a lack of power can cause FCDs to “drop”
- the raspberry Pi root hub (which is what provides the 4 physical ports on the device itself) is “single-TT” and not “multi-TT” (more below) and can only support one directly plugged in FCD, so in general, all FCDs should be plugged into an external multi-TT hub
Sensorgnome V2 releases
Currently: Sensorgnome V2 RC14 (2024-) detects and logs dropped and low-rate FCDs, and also attempts to restart them, but the restart is not reliable. I still need to implement the more robust restart we worked out for the SS (that’s an oversight of mine).
Release candidates RC13 and RC14 both measure the FCD and RTL-SDR sample rates and the data can be viewed in a chart on the radio tab of the Web UI as well as on SGhub (www.sensorgnome.net).
Single-TT vs Multi-TT hubs
FCDs are USB1 devices, they run very slow. Once USB2 came out hubs started to translate USB1 transactions to USB2 speeds so they don’t hog the bus for so long. A single-TT hub can do this for one device only. A multi-TT hub can do this for multiple devices (typ all its ports). Thus connecting 4x FCDs to a single-TT hub accelerates one and the other three continue to hog the bus at USB1 speeds. A multi-TT hub would accelerate all 4.
Raspberry Pi4B
The rPi 4 root hub is a Single-TT hub, so plugging FCDs directly into the Pi is not a good idea. When an external hub is plugged in it is possible to determine whether it is multi-TT by using the command-line (sorry) and issuing the command
sudo lsusb -v | grep TT
look for the bInterfaceProtocol lines (and ignore errors and other stuff). For example, my SG has one 4-port multi-TT hub:
bInterfaceProtocol 1 Single TT
bInterfaceProtocol 2 TT per port
The Single-TT is the root hub and the TT per port is the multi-TT hub. Since the rPi itself doesn’t have a multi-TT hub the presence of TT per port indicates that the added hub is indeed multi-TT.
Raspberry Pi3B+
Undetermined…
Raspberry Pi3B (V1.2)
The hub of the rPi3B is a Multi-TT hub, thus plugging FCDs directly into it is a good idea. The full story is that the root hub is Single-TT and has only one device on it, which is a fast-ethernet plus 4-port hub combo chip. This combo chip has a Multi-TT hub. All this makes sorting out whether an external hub is also Multi-TT a bit more difficult. When plugging in an external hub I recommend to verify that it is Multi-TT using the following command:
sudo lsusb -v | grep -E 'TT|Bus'
On an rPi3B without any external hub this shows:
Bus 001 Device 028: ID 04d8:fb31 Microchip Technology, Inc. FUNcube Dongle V2.034
(Bus Powered)
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
bDeviceProtocol 2 TT per port
bInterfaceProtocol 1 Single TT
bInterfaceProtocol 2 TT per port
TT think time 8 FS bits
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bDeviceProtocol 1 Single TT
TT think time 8 FS bits
The “Bus” lines show the devices found and the bDeviceProtocol the Transaction Translators. The SMC9514 hub is what matters (and I don’t know why it also lists a Single-TT something). An external hub should show in addition to the above lines.
Notes
- USB3 is completely irrelevant: a USB3 hub internally consists of a USB3 hub plus a USB2 hub, the transfers in question here do not touch the USB3 side, it’s as if it didn’t exist (and the standard prohibits translation from USB1/2 to USB3).
- the majority of 7-port hubs consist of 2 stacked 4-port hubs, which is fine, but useful to know if you’re looking at lsusb output
- Multi-TT is not something that is normally listed in hub specs and more recent hubs don’t seem to have a higher chance of being multi-TT than older ones, at least not in my sampling of cheap hubs from Amazon
Acknowledgments and caveat
A lot of people contributed to chasing down the issue, in particular Josh Sayers, Adam Smith, Matt Webb, Garret Rhyne, Nick Haddad, Bob Fogg, David La Puma and Kylle Lamoree (I hope I’m not forgetting someone). The symptoms depend heavily on how the hardware is configured and it feels like there are still some ingredients that elude us. The team set-up more than a dozen systems, some with up to 6 FCDs, and swapped hardware and software pieces to try and narrow down the issue. Sometimes everything looks fine but then errors show up a couple of days later: it has been quite frustrating at times! I still have the feeling that while the fixes are real improvements we haven’t quite seen the end of this. Thank you for all the hard work and to CTT for jumping in!
NB: I also want to add that despite a multi-page write-up with details of the issues and examples we got basically zero support from the creator of the FUNcube, even though Motus has resulted in hundreds of FCD sales. I found that quite shameful and it has contributed to me wanting to figure out how to make RTL-SDRs as effective as FCDs.
