A few thoughts about sdrUno 1.2 CAT
• Bug?
The IF data that is sent by sdrUno every second by default is sent three times every time it's sent, which appears to be a bug,
ie. from my debug console I get three x IF00007090000 in one hit, accompanied by a single SM00002, whereas a single IF would be expected.
• Question:
The SM data according to Kenwood varies from 00~20. From my initial observations SM's as returned by sdrUno appear to be S values which pretty much follow a linear relationship with dBm up to S9 as per this typical table http://www.giangrandi.ch/electronics/radio/smeter.shtml
After that they appear no longer linear, I would really appreciate it if the sdrUno team could share their formula for generating their SM values to make it easier for me to convert them backwards into dBm values. Yes, I know it's rough but when remotely polling for signal strength it would help
• Suggestion for future sdrUno CAT:
1) It would be great if sdrUno returned an IF immediately after it was sent any command that changed it's receiver status. I know I can poll Uno for IF because I tried, but the round trip from my web browser even at 34800 baud and using web sockets is too long to be useful.
2) Sure it would be even better if the AI command was implemented so Uno could be commanded to send event driven Auto Information, but I can understand the reluctance to go down that route, so a 'handshake' IF as per the above request would help a lot.
3) Implementing the BY command would be good and may be essential for any implementation of scanning or remoting. Yes, Uno supports SQ squelch level but the delay is far too long to allow any remote CAT app to respond to received signals when "slow scanning" or "browsing" spot frequencies of interest, and the SQ levels are essentially variable and arbitrary. I'm not sure how the Kenwood actually uses BY because I don't own one, but the BY convention I believe is as implemented on my Yaesu's CAT, which is this:
BY returns true when the receiver demodulator returns something "meaningful" other than noise.
- For example I can remotely command my Yaesu FT-991 to "scan" at the rate of about 100 milliseconds per frequency change by sending it FA commands and then respond to the returned BY signal in time to stop it. That 100 milliseconds is the full round trip between a remote web browser on my LAN and the Yaesu hardware.
- on FM narrow, eg. when scanning ham repeaters or commercial services I can leave the squelch open and still scan, or at any setting and still scan, relying only on the BY signal to pause or stop my scanning.
• Scanning
Has been discussed as a future sdrUno feature, I've always been skeptical because of the large delays inherent in ADC as well as the rest of the chain, particularly audio.
As per the comments above I built a comprehensive scanner and control system for my Yaesus and modified it for the Kenwood command set so as to try sdrUno.
The sdrUno interface is by necessity slow to react but it was rewarding to see it frequency hopping at speeds up to something like 400 milliseconds scanning rate, though closing the main receive/waterfall window made no noticeable difference, I had hoped it might speed Uno's response up a bit.
The good bit is the lack of relay clacking when band changing which inhibits cross band scanning on conventional ham radio transceiver hardware but the bad bit is there would appear to be no obvious or easy solution for reducing the latency inherent in sdr in order to even get close to the expectations of anyone hyperventilating over a DC to daylight scanner.
• Bug/Improvement:
When remotely frequency hopping from HF up to VHF on an sdrPlay RSP2 the sdrUno antenna switches over from HF to A. The problem is that it does not switch back when returning to VHF from to HF. That's not a problem on the RSP1A but still needs fixing, ie. please save the user's chosen state of the antenna switch when using an RSP2 and restore it on the RSP2's relevant frequency thresholds. Saving user state is necessary because I sometimes choose to use A on particular HF bands and I'm sure that's not unusual.
There is a lot more that could be said and discussed, it's such a large topic, such as how to serve low latency audio and get it through routers for remoting sdrUno, but this post is more than long enough
------
Setup for above tests: Raspberry Pi 3 running node.js and connected via USB serial to a second computer running sdrUno. The homebrew node.js app provides a web interface with round trip times of less than 10 milliseconds between the radio and a web browser on a third machine on the LAN, using web sockets and 34800 baud which is the fastest my Yaesu supports.