piHPSDR / MacOS Catalina / usb-audio HELP

[Christiaan Roselaar]

Hi All.
Help..
I'm running DL1YCF's fork of piHPSDR on my MacBook Air.
All works fine (SSB) using a headphone plugged into the Mac's audio-connector, while at the same time using the build-in microphone.
I hoped I could use my Heil HC-4 headset instead of this on-board mic // external headphone combi. The Heil headset has a good set of earmufs/speakers and a very good mic attached to its boom.

The Heil has a 3-contact (stereo!) 3.5mm connector for accepting audio from the Mac, and a 2 contact (mono) 3.5mm connector for outputting the mic- signal to the mac. Since the MacBook Air has no seperate audio-out/audio-in connectors, I plugged-in a C-media USB-to-audio interface.
This interface shows up correctly, and the output (two channels) and input (one signal) are there.
All good so far. But now where the challenge begins.
When I route piHPSDR-audio out to the c-media device, the radio's audio clearly gets through my Heil. Great :) .
However, no sign of any signal coming from the Heil's boom/mic though.
Do I need to install a specific MocOS-driver for such USB-to-audio plug/device? Am I forgetting something?
NO mic-signal gets through. Not to piHPSDR, but neither to a program like Audacity.
Help...

73's Christiaan PA3FUN

[Christiaan Roselaar]

I don't know what I've changed in all settings on my MacBook Air, but it's working now.....

Op zaterdag 24 oktober 2020 om 21:35:05 UTC+2 schreef Christiaan Roselaar:

[DL1YCF]

I am after this as well. It happens quite often that the „local audio TX“ does not work
until one un-checks and the checks gain the „Local audio“ checkbox in the TX menu.
This happens only occasionally therefore hard to debug.

But unchecking/checking always worked so far. It only applies to the TX menu
(microphone input), I never had problems with the RX (local headphone audio).

Strange, but so it is for the moment. I might be MacOS-specific, I mostly
operate from the Mac.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/0eb4e7c6-d96d-4589-af9c-31d11997cf9do%40googlegroups.com.

[Mooneer Salem]

Not to hijack this discussion, but has anyone on MacOS noticed a lot of "sequence errors" with associated RX audio cutouts? I see this on both the official piHPDSR and the DL1YCF source trees on my 2017 MBP running Catalina. Not sure if I'm missing something obvious in the setup or if it's an indication of some other issue, especially since it seems to happen with both Ethernet and Wi-Fi.

(FWIW, "sequence error" seemed to show up a lot less on my Raspberry Pi 4B over Ethernet, even before I built and installed a RT kernel. Currently the setup that's working the best for me is X11 forwarding SparkSDR and tunneling PulseAudio over SSH so it can use my laptop's sound devices; I can post more info on how I accomplished that if anyone's interested.)

-Mooneer K6AQ

[ron.ni...@gmail.com]

I often get sequence errors (with relay clicks or audio cutouts, and increasing ep6 error counts) when connecting from my MacBook Pro running Catalina (or iPhone or iPad running iOS 14) to my HL2 over WiFi, especially using the 2.4 GHz WiFi band, or at any distance over just a few meters from the WiFi access point.  

But never get these errors when the connection is completely wired, either by direct ethernet cable, or Lightning to ethernet dongle, or via a common ethernet switch or router, unless perhaps something else high priority is already maxing out the network bandwidth or CPU utilization.

How many spectrum slices are you running at what sample rates?  Does the LED on your HL2 indicated that it negotiated a 1G ethernet connection?

73,

Ron

n6ywu

[Tokio]

Hi All,

Having read this thread, I installed today piHPSDR, which is quite new to me, on my Mac Catalina, based on the information of Christophe,  on Github/DL1YCF.

The screen after creating fftw wisdom file and connecting HL2 to Mac is as follows;

No audio, no spectrum on the above RX, RX1?

My HL2 has no antenna at the moment, simply connected to Ethernet, and HL2 is in Run Mode.

My installation has no error. Could you someone indicate what's wrong in my setup of piHPSDR, or provide the url of its adequate manual?

Is Apatche Labs PiHPSDR manual a good one?

73,

Tokio

ja1cca

2020年10月28日水曜日 10:02:34 UTC+9 ron.ni...@gmail.com:

["Christoph v. Wüllen"]

sequence errors usually are a result of a non-optimal ethernet connection between computer and radio,
and the RX dropouts are a logical consequence of this.

sequence error means that HPSDR packets from the radio are either dropped or arrive in
the wrong order.

It seems that in your setup you have a lot of traffic on your ethernet, does this problem vanish
if you have a „dedicated“ connection (direct cable from Mac to radio)? For example, for a Mac
with is „in the internet“ I use an additional USB-to-RJ45 adapter and connect the radio with
a direct cable there.


Yours, DL1YCF Christoph.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/60a1ad62-2bd9-4021-bcfb-bf8c7362a3fen%40googlegroups.com.

[Mooneer Salem]

Hi Christoph et al,

The sequence errors (from limited testing earlier tonight) seem to dramatically diminish but not completely go away when I drop from 1 receiver/384K to 1 receiver/48K on Wi-Fi. I tried to test on Ethernet (more accurately, a Thunderbolt to 10G fiber adapter) as well but ran into unrelated network issues that I'll need to resolve first. From what I remember with my Raspberry Pi testing, though, I was able to almost completely cure the dropouts by going to a RT kernel while also having it on Ethernet; while there probably isn't a separate RT kernel available for macOS, there may be things that can be done in the code to adjust scheduling/priorities and such that I can look into at some point. It may also explain why SparkSDR seems to work with no problems--I typically run that on the Pi due to there not currently being an available macOS build.

Weirdly, there shouldn't be much going on with the network normally. At least on the Wi-Fi side, I'm typically within a few feet/meters of the access point (Ubiquiti UAC-HD) and the Wi-Fi menubar on macOS shows the maximum possible 5GHz transfer rate of 1300mbps. Additionally, Activity Monitor showed around 10MB/sec of network traffic while at 384K, which shouldn't be coming anywhere close to the maximum real-world speeds. Then again, I also live in a fairly crowded Wi-Fi environment where 2.4GHz is useless (and there are still at least a couple of other 5Ghz APs/routers from neighbors that I can see), so some level of dropouts on Wi-Fi may be unavoidable.

Thanks,

-Mooneer K6AQ

[J P Watters]

Had exactly the same issue. Remembered reading that local audio needed to be checked, unchecked and rechecked in some cases.

And in my case, after doing just that, and restarting the program, it was then successful. 

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9086705f-1d2c-4b84-ad70-37bc7dbb8c9fn%40googlegroups.com.

[ron.ni...@gmail.com]

Dropouts, ep6 errors, and relay clicking are often indications of a network latency issue, which can happen even on very fast networks.

If using WiFi, test your connection by running the ping utility.  

Ping your HL2 for an entire minute and observe not the average latency, but the variance over time.

If you see a variance of more than a few mS, that's your problem, a fast but bad network connection or router.

Routers that are too smart might be doing a UDP packet combining "optimization" which destroys latency jitter numbers.

Other smart routers are too "polite", and go off the air for huge gaps of time to allow slower WiFi devices time to access the WiFi channel.

Bu if the ping times are all a couple mS or less and almost constant, then your problem is elsewhere.

BTW, I run lots of SDR apps on my on my Raspberry Pi 4 running stock Raspbian Buster, no RT kernel, and have zero network issues when the Pi 4 is directly hardwired wired to the same ethernet switch as the HL2.

73,

Ron

n6ywu

[ron.ni...@gmail.com]

A Mac located even just 2 meters from a fast 5G WiFi access point could be a problem.

The problem that seems specific to some models of MacBook might be that the WiFi antenna appears to be shared among multiple radio services (Bluetooth LE, AirDrop detection, and etc.).  The Mac might be holding up WiFi traffic for huge gaps of time while chatting with all the other macOS and iOS devices in the building, under the assumption that catching up with a gigabit fast burst of data later won't cause network issues.

So I mostly use my MBP wired (via USB C to ethernet dongle) to the same switch as my HL2.  Or very very near a dedicated access point for which I've pre-characterized the ping time latency jitter variance.

73,

Ron

n6ywu

On Wednesday, October 28, 2020 at 2:31:15 AM UTC-7 moo...@gmail.com wrote:

["Christoph v. Wüllen"]

> So I mostly use my MBP wired (via USB C to ethernet dongle) to the same switch as my HL2. Or very very near a dedicated access point for which I've pre-characterized the ping time latency jitter variance.

I even prefer using a single cable, plugging one end into the HL2 and the other end into the dongle.
I have seen switches which do store+forward and which send out UDP packets not exactly in the order
they were received.

[ron.ni...@gmail.com]

I've used a single cat-6 cable direct from the Mac (via USB C adapter) to the HL2.  Works using self-assigned IP addresses.

I've also used the Belkin Lightning-to-ethernet dongle to wire an iPhone 11 Pro directly to an HL2.  That also works just fine, and is the combo I plan on trying for SOTA/POTA portable ops with the HL2.

But ... I have more than one HL2 (on separate antenna systems).  

So I use a simple cheap TP-Link switch that reliably provides sub-200 uS ping latencies.

That configuration also allows access from my Raspberry Pi 4 server to the 2 HL2's without re-wiring.

But, in general, using WiFi between my Macs and the HL2 has been a disaster.

The Metis Protocol 1 transmit UDP latency jitter requirements are too tight.

And 2.4GHz WiFi almost never works (for me).  I've found that even using a dedicated 5GHz access point is still iffy.

73,

Ron

n6ywu

[Mooneer Salem]

This morning I tried pinging various devices on the network over Wi-Fi and I saw some interesting results:

HL2 with Bluetooth on:

--- 10.0.1.227 ping statistics ---
61 packets transmitted, 61 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.109/6.856/132.185/21.215 ms

HL2 with BT off:

--- 10.0.1.227 ping statistics ---
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.148/4.875/132.658/17.594 ms

Main network switch (Mikrotik CRS312-4C+8XG-RM; one of two between Wi-Fi clients and the HL2), BT off:

--- 10.0.1.131 ping statistics ---
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.377/5.928/112.581/15.307 ms

Ubiquiti UAC-HD directly, BT off:

--- 10.0.1.206 ping statistics ---
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.232/6.187/95.057/13.771 ms

I then started poking around on the UniFi controller and noticed this option (which wasn't checked):

Enabling multicast blocking now gives me the following when I ping the AP directly, a significant improvement:

--- 10.0.1.206 ping statistics ---
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.164/3.763/8.977/1.373 ms

I'll have to open piHPSDR later and confirm that this helped at least somewhat (and to see what latencies/jitter look like when on a wired connection). Thanks for the suggestion!

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/bd507983-cfed-4971-a3b1-647bf712bdd3n%40googlegroups.com.

[Jonas Sanamon]

Hi Ron,

What kind of access points have you tried? I have seen that the typical consumer grade APs does strange things to packet streams.

I have Aruba AP-325 access points in my house and detached garage/office building. I use my HL2 and Atlas based HPSDR with a WiFi connected laptop all the time, as long as I keep the bandwidth at 48, 96 or 192 khz it works fine.

I think that there is a big difference in using consumer APs and "office" APs from big companies like Cisco, HP, Aruba, etc.

Which app did you use on the iphone11 to talk to the HL2?

I agree that the MBP handles wifi worse than my Linux laptops though.

Regards, Jonas

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/cee153a0-4285-4b5f-b4ec-0253e622aed6n%40googlegroups.com.

[Mooneer Salem]

As an update, I tried pinging the HL2 over Ethernet and got ping times around 0.3ms or so. It also definitely worked a lot better on Ethernet in general as I only saw 4 sequence errors in the console (pretty much right when I connected to the HL2). Meanwhile, when with the previously mentioned config change, I still had far more sequence errors over Wi-Fi--and IPv6 stopped working, too--so that change immediately got reverted. 

Anyway, I think Ethernet is going to be my best bet long term, as much as I'd like to be able to use it without having to plug my laptop into the switch. That said, there may still be other settings I can adjust on the UniFi gateway and/or switches to reduce jitter/latency and hopefully allow at least 48K or 96K to be used. Thanks all for your help!

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAABBs1Uewv5Qh%2B109uv3K-cXLCNwNJc77wSCXN77s8OJUfvUDw%40mail.gmail.com.

[ron.ni...@gmail.com]

Hi Jonas,

> Which app did you use on the iphone11 to talk to the HL2?

I have a couple iOS/iPhone apps that I've been developing to talk to the Hermes Lite 2.

My rtl_tcp SDR app is already in Apple's App Store.  

See: http://www.hotpaw.com/rhn/hotpaw/ or https://itunes.apple.com/us/app/rtl-tcp-sdr/id1351164646?ls=1&mt=8 

This app was really designed to communicate with RTL-SDR servers, but I also wedged in HL2 support.

Since many people already just take their mobile phones along on hikes anyway, I want portable operation types to be able to use an HL2 with minimal additional weight (just radio battery, ethernet dongle, ether cable, etc.).  That's why I previously asked about heat sink solutions that did not involve the full (fairly heavy) 40mm AL case.  But that got sidetracked into the case shim discussion.

Email me directly to get added to Apple's TestFlight program (which is free) for beta test builds of the iPhone app.

73,

Ron

n6ywu

[ron.ni...@gmail.com]

To avoid having to always plug a physical ethernet cable into my MBP, I found that a least a few 5GHz Wifi access points, set up as a dedicated router (e.g. with a private SSID to which no other client can connect) can work at short range (halfway across my office).  Currently using a TP-Link "Nano Travel Router" (TL-WR902AC). But one of my two Airport Time Capsules also works most of the time.

With the other Time Capsule, receiving one slice from the HL2 works up to 384ksps, but attempts to transmit on the HL2 just cause the N2ADR relays to go crazy (due to UDP packet loss/lateness).
73,

Ron

n6ywu

[Tokio]

Hi Watters-san,

Thank you for your suggestion about piHPSDR on Mac Catalina.

Now piHPSDR works fine on my Mac as piHPSDR on Raspberry Pi 3.

Certainly, WiFi connection produces some SEQ ERRORs.

73,

Tokio

ja1cca

2020年10月28日水曜日 19:44:11 UTC+9 jpwa...@gmail.com:

[Mooneer Salem]

I actually did some more reading tonight and discovered some suggestions on https://www.reddit.com/r/Ubiquiti/comments/8wl21w/mysterious_10x_jumps_in_latency/. Looks like disabling location services seems to help significantly for me on Wi-Fi, at least with the lower sampling rates. I still occasionally get sequence errors but only one or two at a time (and they don't seem to disrupt audio). I may rescan 5GHz for additional clear channels to use at some point, too, even though DFS should in theory have less traffic due to less device support. Hope that helps anyone else with similar issues.

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/64f413b3-3095-4c62-aa27-d535d8891186n%40googlegroups.com.

[Jonas Sanamon]

Hi Mooner,

Yes, WiFi location services should absolutely be disabled, as these are generally implemented such that the AP stops serving data every X ms and instead switches channel to listen and report what it hears to the locating server for a long time (many ms), then after another X ms switches to another channel, listens and reports etc.

I didn't know some AP manufacturers enabled this by default?  I don't see the point for this as normally their average private customer will not have specified any location services server to send the heard MAC + RSSI data to.

Regards, Jonas

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAAzDfxMpXOHQEOfGWNEu2iwQ2uMofA3LD5013Km0vJ9xSVchfQ%40mail.gmail.com.

[Matthew]

I have updated the Wiki with some notes about WiFi (anyone can do this, all you need to do is have a (free) GitHub account). I wasn't sure if the FAQ was the best place, but if we can think of somewhere else more appropriate, it can easily be moved.

It seems that everyone has their own differing personal experiences with WiFi. However, for me, I upgraded my laptop WiFi card to 5 GHz and noticed a big reduction in buffer underflow problems. When in the same room, I hear no relay clicks. I have Ubiquiti WiFi gear and spent ages playing around with various settings when using a 2.4 GHz network, but didn't find any made a huge improvement beyond the defaults. Different SDR software sends data to the HL2 at different rates, however the HL2 consumes the data out of the buffer at a steady rate. SparkSDR, Quisk and linHPSDR send data to the HL2 every 2.7 (ish) ms. If you connect wireshark up, have 1 rx @ 48000, you should see; 1 packet from PC, 1 packet from HL2 in a nice steady pattern. However, a word of caution. I have this week been doing some investigations to improve CW in linHPSDR. I notice that sometimes linHPSDR doesn't get priority from the CPU and sometimes doesn't always send messages to the HL2 in the 2.7 ms window (wired link to my HL2). I have played around with nice, renice etc. The problem is more pronounced when things like Firefox (with YouTube) etc. are running. One could of course patch the kernel to get better real-time performance, but I prefer to modify the software to cope with this.

I know PowerSDR (don't know about other software beyond already mentioned) does big dumps of packets in bursts (sometimes with 25 ms between packets). If one of these bursts coincides with a WiFi packet burst, you may encounter problems in TX with relay clicks (HL2 has emptied the buffer and new packets haven't made it from the PC to the HL2 yet). I mention on the wiki page you can increase the buffer size and there is experimental gateware to increase this further. However, a word of caution, I experienced sometimes around 70 ms latency on a 2.4 GHz WiFi link during some experiments with an HL2.

I think the overall summary here is; use a wired connection where possible.

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

Thanks for the wiki updates!

73,

Steve

kf7o