¿ªÔÆÌåÓý

CM108 PTT randomly interferes with the mouse


 

I built some PTT modified CM108 dongles for my buddy and I to use with our uv5r's and direwolf+xastir. These are connected to headless pi5's running bookworm, and vnc is the primary means of access?(through LAN). At first glance the cm108 audio and PTT appear to work as expected, however after transmitting the vnc cleint mouse will randomly stop responding. The timing is completely random... sometimes it goes out within a few seconds, sometimes after an hour or so of operation. When it happens, I observed the cursor in the direwolf terminal goes from flashing on/off steady every second, to very rapid random flashing. The PTT itself doesn't seem to misbehave when this happens... the tx remains off. However once it happens there's not getting the mouse back without a reboot.

I am 99.9% sure the modifications were done properly and should work like other known good examples found online. I didn't precisely follow any one particular guide to do the mods, rather I read up on several designs and sort came up with my own preferred assembly. Some designs I saw didn't include a COS diode, some did, some had no PTT led, which I wanted... anyhow my schematic is typical of other mods known good mods nothing special. I'm happy to provide more details/photos if anyone thinks this might be a hardware issue. I also have an oscope and the other usual lab tools on hand if I need to probe around to help find the issue.

I have been using keyboard shortcuts to reboot when this happens. After reboot (as long as I don't actually trigger the cm108 ptt) the pi5 operates perfetly for weeks without issue (fldigi, ft8, logging, gqrx, etc). Also, I can run direwolf in udp mode with gqrx for days without any problems.

I tried researching this online and keep coming up short. I'm 99.9% certain the modifications were done properly with the correct components (I have a significant amount of experience designing/building such mods). The only thing I can thing that might be causing this is some sort of mixed up HID permissions with the vnc mouse and the local hid output. Alas, I'm somewhat a greenhorn when it comes to such things in linux. Has anyone else seen a similar issue, maybe not just with cm108 or pi5, but perhaps similar issues with HID and direwolf ptt? Is there something I can do to try and fix this? I'm happy to do additional troubleshooting since I know it may be needed to reach a conclusion. Any help is much appreciated.

I just finished designing a PCB to use GPIO for ptt (gonna mill a 10 pack on my cnc). So in the end I could just forget about using the cm108 for ptt anyways. However I'd like to learn something from this, and I'm concerned this exact same issue could occur even with GPIO. If someone provides me with the key to fix my cm108 ptt problems, I'll be happy to mail them a spare RPI ptt hat as a thank you.

Thanks,
Kevin KO6BLZ


 

If things are going fine, until you transmit, then something weird happens, it is probably RF getting back into your computer.

As an experiment, try changing to low power transmit.? If that improves your situation, it is good evidence that stray RF is the problem.

The solution is to put the antenna farther away from digital devices and to put ferrite beads on your cables.

73,
John Wb2OSZ


 
Edited

I probably should have described my antenna setup. I'm using a Comet GP-6 mounted ~70' from the radio on my rooftop (~20' from ground), with 100' LMR400 running to a switch, and 3' LMR400 between switch and ht. I added 2x 8" loops of coax near the antenna per the manual. I also have a ground strap connected to the steel mast it is attached to, a choke on the coax just before the radio, and another choke on the audio/ptt cable with 3-turns (both the correct mix from Palomar). So I hope it's not still somehow rf related... maybe a coax adapter or the switch. I did my VNA measurements where coax that enters the switch. The uv5r+antenna setup otherwise seems to work well... reaching distant repeaters, good audio reports, etc.

That experiment is a great idea, thanks. I switched to low power and will let it repeat throughout the evening. Fingers crossed it still works tomorrow. If it does I'll bump the power back up to high just to verify it isn't like some recent update or something else.?

On a side note, the $100's worth of coax and antenna is just for the $15 radio hehe... I plan on getting a 9700 (for satellite etc) to put next to my 7300. When that happens I'll have to come up with another antenna for this.


 

Unfortunately it already failed on low TX power. I then added more ferrites to the ptt line and got the same result. I will continue to experiment with this.

The cm108 modification I did connects the pi and radio grounds. So I figure CM current might lead to such issues. I might see if rebuilding the cm108 with an isolated circuit will fix it. I have some optocouplers and audio isolation transformers laying around that I can use.

On a related note:
I just finished testing my diy GPIO ptt adapter, and it works great on the pi5 using a small python script. However when I tried using it with direwolf, I stumbled in to a known issue with pi5 gpio:


 

A quick update... I am continuing to troubleshoot pi5 gpio. In the process of doing such, I compiled and installed the latest dev branch of direwolf. Since GPIO was going nowhere, I decided out of curiosity to try the cm108 again on the new dev code. It could be just short term luck, but it has been operating and txing now for about an hour straight on high tx power without issues. I will continue to monitor the setup and report back here if it eventually fails again. Otherwise I would conclude that there is something in the bookworm direwolf package that causes this, and compiling the current dev branch of direwolf gets it working again.


 
Edited

It turned out to be just luck, and after a few hours of operation the mouse was lost again.

So further testing got more confusing. I left direwolf running for several hours without issue using the cm108. However, once I opened up flrig and fldigi on the same pi5, the mouse gets lost very quickly. I also observed the default audio out volume control works as expected before running direwolf. This default audio is my 7300, which works fine with fldigi etc. I leave it set to 100% and attenuate tx audio in fldigi/wsjtx etc. If I start fldigi first, then open direwolf, the tx audio for fldigi stops working correctly, and the default audio slider drops to zero. If I try to raise the slider, as soon as I let go it rapidly drops back to zero (weird!). Sometimes I can't even get to the slider before the mouse is lost. I'm starting to lose hope for this pi5 working out the way I wanted (a pi to do handle all of my ham stuff at home). Based on my latest observations, it seems I could setup a second pi to do just direwolf/xastir and be fine. Hoping I can figure this out. Still monitoring if anyone has other things to try.


 

Just wondering, are you using 'bookworm' OS on the Pi? Last info I read on 'bookworm' was that it had problems. Just for S&G maybe try the previous version of OS, and I can't remember offhand what it is called. I would try another SD card and a new install with the older OS. The SD because if it does not work, then you can unplug the test and re-install what you have now, without starting over. I seem to remember reading something about the OS turning things off and there was a way to disable that function. It seems to me it was wifi that got turned off but maybe it also has something to do with other connected devices. It truly seems counterproductive to have some application built into the OS that disables devices.

On Wed, Mar 6, 2024 at 5:56?PM KO6BLZ <imelman2@...> wrote:

[Edited Message Follows]

It turned out to be just luck, and after a few hours of operation the mouse was lost again.

So further testing got more confusing. I left direwolf running for several hours without issue using the cm108. However, once I opened up flrig and fldigi on the same pi5, the mouse gets lost very quickly. I also observed the default audio out volume control works as expected before running direwolf. This default audio is my 7300, which works fine with fldigi etc. I leave it set to 100% and attenuate tx audio in fldigi/wsjtx etc. If I start fldigi first, then open direwolf, the tx audio for fldigi stops working correctly, and the default audio slider drops to zero. If I try to raise the slider, as soon as I let go it rapidly drops back to zero (weird!). Sometimes I can't even get to the slider before the mouse is lost. I'm starting to lose hope for this pi5 working out the way I wanted (a pi to do handle all of my ham stuff at home). Based on my latest observations, it seems I could setup a second pi to do just direwolf/xastir and be fine. Hoping I can figure this out. Still monitoring if anyone has other things to try.


 

I did a bit of looking and the general consensus is power supply insufficient current. The Pi5 is a hungry beast from what I understand.

On Thu, Mar 7, 2024 at 7:07?AM Gil Rand via <gilrand=[email protected]> wrote:
Just wondering, are you using 'bookworm' OS on the Pi? Last info I read on 'bookworm' was that it had problems. Just for S&G maybe try the previous version of OS, and I can't remember offhand what it is called. I would try another SD card and a new install with the older OS. The SD because if it does not work, then you can unplug the test and re-install what you have now, without starting over. I seem to remember reading something about the OS turning things off and there was a way to disable that function. It seems to me it was wifi that got turned off but maybe it also has something to do with other connected devices. It truly seems counterproductive to have some application built into the OS that disables devices.

On Wed, Mar 6, 2024 at 5:56?PM KO6BLZ <imelman2@...> wrote:

[Edited Message Follows]

It turned out to be just luck, and after a few hours of operation the mouse was lost again.

So further testing got more confusing. I left direwolf running for several hours without issue using the cm108. However, once I opened up flrig and fldigi on the same pi5, the mouse gets lost very quickly. I also observed the default audio out volume control works as expected before running direwolf. This default audio is my 7300, which works fine with fldigi etc. I leave it set to 100% and attenuate tx audio in fldigi/wsjtx etc. If I start fldigi first, then open direwolf, the tx audio for fldigi stops working correctly, and the default audio slider drops to zero. If I try to raise the slider, as soon as I let go it rapidly drops back to zero (weird!). Sometimes I can't even get to the slider before the mouse is lost. I'm starting to lose hope for this pi5 working out the way I wanted (a pi to do handle all of my ham stuff at home). Based on my latest observations, it seems I could setup a second pi to do just direwolf/xastir and be fine. Hoping I can figure this out. Still monitoring if anyone has other things to try.


 

For short term testing when you don't have a second uSD card and are running Linux on another machine (Windows may have a similar tool, but make sure the file system supports very large files), you can use sudo dd if=/dev/sd? of=pi5_sd.img (the "?" is the letter of the SD card and don't use any numbers - you want the whole drive ) to save the entire SDCard to your hard drive (providing you have room).? Since most hard drives these days are in the 100s or 1000s of GB and the SD card is likely only about 32 GB.? Then dd it back to the uSD card as needed, or delete it if not needed.

I haven't done it in a while, but there are plenty examples of using dd on the internet.
I do remember you must make sure the SD card is not mounted when you run dd!
Oh, and add status=progress to the command line helps view the progress.

Takes longer, but doesn't require additional hardware (usually).

Robert Giuliano
KB8RCO



On Thursday, March 7, 2024 at 10:04:26 AM EST, Gil Rand <gilrand@...> wrote:


Just wondering, are you using 'bookworm' OS on the Pi? Last info I read on 'bookworm' was that it had problems. Just for S&G maybe try the previous version of OS, and I can't remember offhand what it is called. I would try another SD card and a new install with the older OS. The SD because if it does not work, then you can unplug the test and re-install what you have now, without starting over. I seem to remember reading something about the OS turning things off and there was a way to disable that function. It seems to me it was wifi that got turned off but maybe it also has something to do with other connected devices. It truly seems counterproductive to have some application built into the OS that disables devices.

On Wed, Mar 6, 2024 at 5:56?PM KO6BLZ <imelman2@...> wrote:

[Edited Message Follows]

It turned out to be just luck, and after a few hours of operation the mouse was lost again.

So further testing got more confusing. I left direwolf running for several hours without issue using the cm108. However, once I opened up flrig and fldigi on the same pi5, the mouse gets lost very quickly. I also observed the default audio out volume control works as expected before running direwolf. This default audio is my 7300, which works fine with fldigi etc. I leave it set to 100% and attenuate tx audio in fldigi/wsjtx etc. If I start fldigi first, then open direwolf, the tx audio for fldigi stops working correctly, and the default audio slider drops to zero. If I try to raise the slider, as soon as I let go it rapidly drops back to zero (weird!). Sometimes I can't even get to the slider before the mouse is lost. I'm starting to lose hope for this pi5 working out the way I wanted (a pi to do handle all of my ham stuff at home). Based on my latest observations, it seems I could setup a second pi to do just direwolf/xastir and be fine. Hoping I can figure this out. Still monitoring if anyone has other things to try.


 

So I am running bookworm, because the last time I tried bullseye on the pi5 did not go so well. Gil, that's interesting an interesting comment about bookworm turning off devices; sounds like something that should be restricted to win laptops,? and a big portion of pis being used are for headless server applications where such behavior could break all sorts of things. Also I am using the official pi5 power supply, and the sdr's and 7300 I've got plugged in to a powered hub. Also fwiw, I'm not using any usb3 ports to avoid noise issues. I knew going in to this that pi5 is still bleeding edge and bugs are likely... especially considering wide sweeping fundamental changes like gpio, xsession, pulse, etc. I'm still hoping I won't have to break down and use one of my pi4's on this... then I would likely be in the same boat figuring out how to get pi5 working with different sets of apps.

Thanks to my long term geek lifestyle, a have many sd cards, usb ssd's, and a nas I could use to save an image.?However as my luck turns out, I may not benefit from an image anyways. I let the cm108 digipeat wide1-1 overnight since it was seemingly stable for hours before bed time. I found it effectively frozen this morning (no vnc access), so I rebooted, accessed vnc, and took kids to school. I got back home 30min later the vnc server was crashed once again. This time, no apps were running at all when it crashed. So something got hosed recently, and I should probably redo the os anyways. Fortunately I have all? my pi's setup to rsync to my nas. So all of my important files like .config, log databases, assorted shell scripts, etc are safely backed up (and more importantly restoring those files has been successfully tested).

I do have that second pi5 ready to go, but it also has bookworm. To get my digital back on air I'll probably set that up with everything but direwolf, and redo the os on other one to experiment with direwolf.


 

Well I was just reminded why bullseye on pi5 didn't go well... it didn't go at all. Now I recall correctly it was actually bookworm 32bit that didn't go well. The rpi imager app does not even offer bullseye for pi5. So I'm guessing it would be a bit of a battle to get that installed. I will just try to procede again with bw64, but this time I will only do things that I know had to be done to get things working, and no other side experiments. This hosed install, I did mess with pulseaudio and a few other things that could have caused problems. I'll more carefully document every single step I do in this process, and report back with the results.


 

¿ªÔÆÌåÓý


Hello Kevin,

I reviewed this long thread and here are a few thoughts:

? - The Raspberry Pi 5 *requires* Raspberry Pi Bookworm (or similar generation OSes) for the required firmware, HW support, etc.? Going to anything older will probably never work right.

? - For your crashing VNC issues, are you using Wayland or Xorg?? You might try switching back to Xorg as a test:?

? - For your volume slider issue, this sounds like the common symptom of miswiring your CM108 device.? Are you using a Digirig device?? .? Even if you aren't, Google around and you will find many other reports about this where you are probably connecting your radio's PTT to the CM108 VOLUME DOWN GPIO pin by accident.

? - For the mouse in vnc not responding" issue, I know you don't feel this is RFI related but it sure seems like it.? Please note that when you compare to other "programs" not having this issue, remember those radios probably aren't transmitting on the same frequencies / bands that Direwolf would be.? Anyway, some more questions / thoughts:

?? a) Beyond of putting your radio to low RF power (which can also still create RFI), try putting your radio in VFO mode and to a frequency the radio will not transmit on.? With this, you should be able to test but there will be ZERO RF being sent which should help isolate your issue more

?? b) What VNC client are you using??? Are you sure the VNC session is still operating?? Sounds like VNC keyboard still works since you can still reboot the Pi.? If you disconnect and re-connect a VNC session, is the mouse still frozen?

?? c) Can you SSH into the Rpi5 once this VNC issue comes up?? What is the load on the Rpi5?? Anything show up in the logs about this (sudo journalctl)?

--David
KI6ZHD


On 03/07/2024 09:33 AM, KO6BLZ wrote:

Well I was just reminded why bullseye on pi5 didn't go well... it didn't go at all. Now I recall correctly it was actually bookworm 32bit that didn't go well. The rpi imager app does not even offer bullseye for pi5. So I'm guessing it would be a bit of a battle to get that installed. I will just try to procede again with bw64, but this time I will only do things that I know had to be done to get things working, and no other side experiments. This hosed install, I did mess with pulseaudio and a few other things that could have caused problems. I'll more carefully document every single step I do in this process, and report back with the results.


 

Not sure exactly what happened but shortly after the fresh reinstall of bookworm 64, after getting things compiled/installed and going headless... the desktop resolution got borked in a weird way. While doing this work a buddy informed me that I can actually use bullseye 32 by first installing on a pi4 then updating. After updates I guess the kernel becomes pi5 compatible, and the sd card will now boot with pi5. I'm trying this now.


 

¿ªÔÆÌåÓý

Hello Kevin,

You might be able to get Bullseye going on an Rpi5 but the reality is that Bullseye won't be getting kernel updates for much longer as they always switch to the new OS shortly after a new OS release.? I always recommend to use the newest Raspberry Pi OS version available to maximize it's support lifetime.? No doubt, Bookworm has a lot of changes in it which makes it frustrating to adapt to but I haven't heard of any blockers making people unable to adopt it.

--David
KI6ZHD


On 03/07/2024 05:02 PM, KO6BLZ wrote:

Not sure exactly what happened but shortly after the fresh reinstall of bookworm 64, after getting things compiled/installed and going headless... the desktop resolution got borked in a weird way. While doing this work a buddy informed me that I can actually use bullseye 32 by first installing on a pi4 then updating. After updates I guess the kernel becomes pi5 compatible, and the sd card will now boot with pi5. I'm trying this now.


 
Edited

Hello David, it seems your post didn't refresh in my browser before I posted. Thanks for taking the time to read this lengthy and starting to get confusing thread. I quickly realized that you are right, pi5 will need bookworm, period. I was using Xorg, because wayland is broken. WRT the potential miswiring of the cm108... I definitely have the correct pin (pin 13) on the CM108 wired to PTT. The PTT does work fine otherwise. Also, the slider that's dropping is actually the one for my ic7300, not the cm108. For reference, here's the mod I used:??As you can see the photos, schem, and text are very clear, no possible confusion with pinouts I think. I copied the mod exactly, with the addition of a doide on COS (which isn't used here anyways). I agree it could still be RFI I suppose... and that's an awesome idea for a test. Unfortunately I have already verified that my stupid uv5r will tx out of range. It's not just lighting up, but actually putting out RF into my attenuators and tinySA when I tested on a NOAA freq. What I can do is put my 100W dummy load on for a test... but that doesn't guarantee no rfi. For VNC client, I'm using realvnc because I'm accessing from my iphone, ios tablet, and a win11 pc. I read some good stuff about like tiger and other clients, but the ios stuff doesn't offer it. Any other ideas for clients? Also, yes the vnc session continues to operate... keyboard still works through vnc. I can also ssh in when it happens, and htop shows normal loading for the apps at play (~13% or so). I haven't thought to look at journalctl yet though. What might this show?


 

I wanted to mention that cm108 mod site does omit ground... the author does in fact connect ground to his radio gnd as shown in another photo of the repeater build. In my case I did add a wire to radio ground as well.

Also David, WRT your last sentence... that is exactly the hopeful statement I was looking for, that others are operating pi5 without deal breaking issues. I figured it should work eventually... just need to sort out the gremlins at play.


 

I¡¯ve been running a Pi5 with direwolf for a little over a month now. That¡¯s running multiple direwolf instances on both VHF and HF without issues. Note this setup was running on a Pi4 for years and a Pi3 before that. ?

A couple notes. Initially with the Pi5 I was seeing stalls in my ssh terminals (I don¡¯t have a GUI on this Pi). That was due to an insufficient power supply. Once I moved to a power supply sufficient for the Pi5 that went away.?

Also, not on a pi, but on a PC. We have a gaming keyboard that absolutely cannot handle RFI. I had an APRS digipeater sitting in the same room as my kid¡¯s gaming PC and every time the digi would transmit the keyboard would stop working for a few seconds. I ended up moving that digi to another room in the house and that keyboard has been happy since.

For what it¡¯s worth.?
-Brent WG0A


 

*FACE PALM* It turned out to be the 10k resistor between COS and ground!

David's comment about the volume pin being miswired turned out to be the key to my discovery.? I saw that all of the cm108 ptt mods that include COS, have COS connected to pin48 on the cm108 chip (some with diode, some without). Pin48 happens to be defined as "volume down" on the cm108 datasheet. That clue led me to compare the COS circuit from several different mod schematics. I noticed most of them did not include that 10k resistor between cos and gnd. Unfortunately I followed one of the guides that did include the resistor. Not sure how/why this worked for the author of the article? I assume there may be some additional components on the COS line that aren't shown which make it work for the author (besides ground, which was also omitted from the guide).

Anyhow, after I removed that 10k resistor the volume dropping after the first tx is gone. I am 99.9% certain from all of this testing/research that the problem is now permanently fixed. Of course I will report back if not, but I think it's a safe time for me to kill this confusing thread. Thanks to all who gave me feedback. Also David, I think your comment about the vol pin is the key that led to the fix... so if you want that rpi ptt just let me know. It works 100% I swear!