More About Amp-ASL Server

Read Time: 7 minute(s)

I continue to fiddle with this interesting project. What did I do this week? Tried to add a WiFi adapter to the Dell 3040, swapped the speaker-mic, tried my Heil K-1 headset, added a battery for uninterrupted power, and fiddled with noVNC.

I do have this node running. It is AllStar node 578499.

Heil Headset

I’ll start with the headset. I’m disappointed. With the Heil name on it, I expected great audio. Nope. There is an audible power hum in my transmissions using this headset.

Heil Sound HTH-K Heil Handi Talkie Headset for Kenwood/Baofeng/Wouxon Handheld transceivers (affiliate link)

The headset is comfortable and helps me listen to nets while my spouse rests, but I’m not comfortable with the transmitted audio. I’ve got some snap-on ferrites stashed in a box somewhere. If I find them, I’ll try one with a few loops of the headset cable through it. Maybe that will help.

Commountain Speaker-Mic

I pulled my Kenwood KMC 45D speaker-mic (a genuine Kenwood speaker-mic, not a knockoff that looks like one) and put a spare Commountain speaker-mic (affiliate link) in service. I like the Kenwood audio better. The receive audio is very nice. My transmitted audio has a lot of treble but there is no distortion or hum in the signal that I can detect over a parrot. The sound is bright and clear, easily understandable.

The Commountain speaker-mic is much less expensive, but it also sounds muddier to me. The receive audio is not as smooth and full as the Kenwood, and my transmitted audio doesn’t sound as clear. However, it also doesn’t have as much treble boost in it, and maybe that’s the difference. It is certainly usable, I just prefer the Kenwood sound. The Commountain device feels sturdy.

I did have to adjust the Receive Mixer in Amp-ASL when I changed microphones. The Receive Mixer was set at about 23dB with the Kenwood speaker-mic. That was much too hot for the Heil headset and Commountain speaker-mic where a 3dB setting seemed to work well.

Can You Run Amp-ASL Server on Windows?

Yes! Well, kind of. I installed Ampersand-ASL Server on my Debian 12 subsystem on my Windows 11 Pro laptop. (Why? Because I’m poking at the software to see what might work!) That worked. I had to allow port 8080 through the Windows firewall so that I could access the dashboard for the Amp-ASL Server, but that only took a few minutes to figure out.

Where this is not working is allowing Amp-ASL to use the USB audio device plugged into the Windows machine. For whatever reason, Amp-ASL doesn’t see it. It doesn’t see it because the Linux subsystem doesn’t see it. I did try a Windows app sourced from a GitHub project that purports to allow USB audio to pass through, but I couldn’t get it to work. I “bound” the USB audio device and the software said it was working, showing it as shared between the two operating systems, but it still wasn’t seen by the Amp-ASL Server software.

I think this little experiment with running Amp-ASL on my Windows laptop is just about over. I will, however, also try this in a virtual machine on the laptop. Fingers crossed. Sometimes it’s easier to get audio to pass through when you use a VM.

CPU Load

By the way, I’m seeing only about 3% CPU utilization on the Amp-ASL Server running on my Dell Wyse 3040 thin client. That is a pretty light load. I’m impressed.

Amp-ASL Server Log

The Amp-ASL dashboard page has three links at the top: Home, Configuration, and Log. Home works. Configuration works. Log doesn’t go anywhere. Why? Because that part of the project hasn’t been implemented yet. Fair warning to those of us who are early adopters and who like to experiment: it is a young project that is still evolving. It has a lot of promise, and I’m comfortable saying that because it is working right now, even though some of the bits and bolts haven’t been finished yet.

Poking around with new software and systems is something I really enjoy doing.

Battery Power for the 3040

I was thinking about how to provide inexpensive backup power for the Dell 3040 that the Amp-ASL Server runs on.

I decided I’d try a 12V battery pack for just under $30:

Rechargeable 12V 5200mAh Lithium ion Battery Pack with Charger and DC5521 Port for 12V Devices (affiliate link)

The output plug is a 5.5mm x 2.1mm male barrel plug and the 3040 requires a 4.0mm x 1.7mm male barrel plug. Therefore, I also bought an adapter with a female 5.5×2.1 plug and a male 4.0×1.7 plug:

DC 5521 to DC 4017 Jack Power Adapter DC5.5×2.1mm Female to 90°Right Angle DC 4.0×1.7mm Male Power Extension Cable 22AWG (affiliate link)

Will it work? I figured it should…and did! The power cable on the battery pack has a male and a female plug. The 120VAC wall adapter plugs into the female connector. The male connector connects to the adapter cable which feeds the 3040. It sounds more complicated than it really is:

But…the battery pack says it is actually 12.6VDC. Is that safe? It appears so. My 3040 requires 12V for input power, but the Parky Towers website says the 3040 uses a buck converter that will accept up to 28V:

In March 2025, I heard from Tianyuan Lin who pointed out that the 3040 used a NCP81231 Buck Controller as the onboard power regulator and that the datasheet said that it supported “…a wide Input Voltage Range from 4.5V to 28V”.

Even if the battery pack does actually put out 12.6V, the buck converter should handle that without skipping a beat. So far it is working fine. The package looks like this:

Trying noVNC

And finally, I’m playing around with noVNC, using websockify to bridge between a web page request and the noVNC system. It isn’t working yet, but I’ve made progress. The noVNC program is installed in /usr/share/novnc. Running this command in the CLI does make that directory available over my local network:

websockify --web=/usr/share/novnc 8081 localhost:5900

I did get noVNC to run but then learned about Krfd.

Krfb Desktop Sharing is a server application that allows you to share your current session with a user on another machine, who can use a VNC client to view or even control the desktop.

I did install the KDE desktop environment, so I cranked that up and sure enough, Krfd was available. I started the program, set a few parameters, and used RealVNC Viewer on my laptop to connect to the Amp-ASL Server desktop (instructions here). Perfect. In the screenshot below, I erased the password (but you do need to set one) and set Krfd to allow unattended access. Without checking that box, you would have to log into the Amp-ASL machine either directly or over RDP in order to authorize the desktop sharing request. With the box checked, you skip past all of that.

So: there is no need for noVNC. I can VNC to the desktop quite easily this way. I was surprised that the desktop over VNC seemed more responsive than over Windows RDP. That was counter to my expectation. I learned a lot in this exercise, including that I could run an application on the Debian machine remotely using web sockets. That was eye opening and it has my mind spinning at the possibilities.

I will continue to poke at this promising project!