Hey, are you alive? about gsoc-contrib HOT 21 OPEN

@ben-kuhn @mdubinko @tonyluvsjazz I created repository with Debian distribution for GSOC https://github.com/d3cker/gsoc-puhumod Feel free to contribute or do whatever you want with this work. I'm moving slowly into alternative CAT support which means I will focus on G90 head protocol for a while. Btw. I opened 3 issues already :) Enjoy.

from gsoc-contrib.

I haven't seen any activity on this repo in a year or so. I submitted a bug to add some info to the wiki and it's been, well, radio silence.

I'm guessing everyone moved over to the x6100. I see there is a working armbian build with lots of the usual digi mode stuff running right on the rig. I learned about that effort yesterday but haven't had time to see if any of those efforts may be portable to the GSOC.

from gsoc-contrib.

Hmmm. The hardware of x6100 is different than GSOC as far I know, so I do not expect too much. For now I would be happy to find out how to trigger PTT and/or use full CAT features. I also took a look at the gsoc_app_v1 binary. It seems there is audio recording capability that is not accessible from the menu. I hope Xiegu will bring back some support and this hardware wont die. I like my g90 and this device is quite handy. Thank you for your response.

from gsoc-contrib.

Hey @d3cker yeah, they are different hardware, but I doubt the x6100 software was a total rewrite. Check out the scripts here https://github.com/Links2004/x6100-armbian/tree/main/userpatches/overlay/root to see how they are using socat to create a virtual serial interface to get CAT working.

My free time has been extremely limited lately, but maybe with the Thanksgiving holiday this week I'll have some time to dig the GSOC out and mess with it some more.

Did you happen to write down which files/libraries you needed to get WSJT-X running?

from gsoc-contrib.

@ben-kuhn This socat thing makes me happy :) Let me try that.
About the libs for WSJT-X. This is a total mess atm because I did some work with compiling Midnight Commander , OpenBox and IceWM too. But sure I can give you the whole list. There are a lot of files... Ignore non .so ones but keep in mind that some of them are also not needed. I managed to get window bar from OpenBox working so I can move WSJT-X windows now.

[root@gsoc:/wsjtx]# ls | wc -l 
390

libs.txt

I also did overwrite all content of /usr/lib/qt/plugins with plugins taken from Raspberry PI from /usr/lib/arm-linux-gnueabihf/qt5/plugins/.

from gsoc-contrib.

@ben-kuhn first excitement subsided and I think I don't understand socat idea. If /dev/ttyS2 is connected then I don't need any UDP for sending cat commands. I can point WSJT-X directly. Onyl /dev/ttyS0 and /dev/ttyS1 seems to be working. S0 is for console and S1 is unknow. As for now I cannot can confirm gsoc_app_v1 uses ttyS1
Output from lsof:

1582	/usr/local/gsoc/gsoc_app_v1	/dev/ttyS1

WSJT-X returns an error when I try to use it.

from gsoc-contrib.

This is speculation so take it with a grain of salt. I don't have an x6100 (yet) so I don't have much to go from other than what I'm seeing in their github repo.

My understanding is that x6100_app is listening for commands on /dev/ttyS2 which I'm guessing is the physical serial interface. From your comment above, it sounds like gsoc_app_v1 is listening on /dev/ttyS1 so that would be the equivalent on the GSOC.

The purpose of soccat is to create a virtual "loopback" serial port so that CAT commands sent to the virtual port are actually sent to the x6100 app. You can't connect WSJT-X to the physical port directly for two reasons. 1) gsoc_app_v1 is already listening on it and has it locked. 2) your commands would be sent out the physical serial hardware.

from gsoc-contrib.

Also, thanks for the file list. Once I get mine back up and online that should save some time.

from gsoc-contrib.

One other thing I noticed. In https://github.com/Links2004/x6100-armbian/blob/main/userpatches/overlay/root/run_x6100_app.sh, they are running the x6100 app in a chroot so they are using a bind mount to make the virtual serial port look like /dev/ttyS2 in the chroot environment. After creating the virtual serial port on the GSOC, since we aren't in a chroot, we have to either make the virtual serial port /dev/ttyS1 (and move the hardware one to a different device node, maybe with udev?), or figure out how to pass a different serial port to gsoc_app_v1.

from gsoc-contrib.

I'm still processing this... so gsoc_app_v1 uses /dev/rfcomm0 for CAT input. With my best understanding the architecture, it reads rfcomm0 and translates commands to whatever /dev/ttyS1 needs. So I need to create virtual rfcomm0. I'm afraid it won't be that easy. App is controlling bluetooth, so it might expect something to be connected first.

from gsoc-contrib.

Oh, right, /dev/ttyS1 is probably the serial connection to the G90 base.

My experience with rfcomm is that there needs to be a bluetooth device connected before the port is created. If nothing is paired the interface won't exist. Maybe try something like this:

socat -d -d pty,raw,echo=0 pty,raw,echo=0
ln -sf /dev/pts/2 /dev/rfcomm0

Where /dev/pts/2 is one of the linked virtual interfaces created.

Then again, if the app doesn't start the cat listener until bluetooth is up and paired, that might cause another issue.

from gsoc-contrib.

I did try this:

./socat pty,link=/dev/rfcomm0,raw,user=root,group=dialout,echo=0 tcp-listen:9091,bind=127.0.0.1,fork

./rigctld --model=3070 --rig-file=127.0.0.1:9091

No luck so far. Also, playing with /dev/ttyS1 was not the best idea. G90 main unit stopped responding. I/Q worked correctly but it neither communicated with GSOC nor with standard panel. Switching off and on power supply helped :)

from gsoc-contrib.

I tried the trick with pairing and connecting to BT. App seems to ignore this socat version of /dev/rfcomm0.Yet, it still creates some lock file:

-rw-r--r--    1 root     root            92 Nov 21 22:19 LCK..rfcomm0

It works only with rfcomm0 made by rfcomm watch command. Interesting.

from gsoc-contrib.

Ok, I managed CAT to work but now I have to figure out how to use sound because gscop_app_v1 is blocking it.
How to setup:

• Create socat for fake tty

socat pty,link=/dev/ttyVUSB0,raw,user=root,group=dialout,echo=0 pty,link=/dev/ttyrig

• gscoc_app_v1 refuses to talk to a link so I did:

touch /dev/rfcomm0
mount -o bind /dev/ttyVUSB0 /dev/rfcomm0

• start gsoc_app_v1
• start flrig and point it to /dev/ttyrig
  Now you can control your G90 over wifi with Flrig.
  And that's it. Now .. do you havy any idea how to fix access to alsa device :) ?
  

from gsoc-contrib.

Nice! I dug out my GSOC today but haven't gotten it on the network yet.

It looks like the x6100 is using PulseAudio for this. There may be some clues here:
https://github.com/Links2004/x6100-armbian/blob/main/userpatches/overlay/root/amixer.sh
https://github.com/Links2004/x6100-armbian/tree/main/userpatches/overlay/etc/pulse

and the pulseaudio systemd units here:
https://github.com/Links2004/x6100-armbian/tree/main/userpatches/overlay/etc/systemd/system

from gsoc-contrib.

Howdy, I'm still here. Changed jobs, moved cross-country, still unpacking my workshop, etc. When they never released any firmware after 1.3, it kind of put a damper on adoption of their platform....

@ben-kuhn I thought you had edit access to the wiki... let me check.

from gsoc-contrib.

Got wiki access now and closed my own issue. Thanks!

from gsoc-contrib.

When they never released any firmware after 1.3, it kind of put a damper on adoption of their platform....

I wonder if it has anything to do with a fact that they (should) suppose to release source for their Linux distro. Their application uses libQT and I bet they didn't purchase the license for commercial use on embedded devices :) It makes sense as there is even no download section for GSOC on cqxiegu.com and all firmware images come from resellers.
Nevertheless, lack of official support pushed me into hacking this thing. I also put my hands on Xiegu body <-> head communication. I managed to modify and run a script from: https://github.com/zeroping/xiegu-g90-headprotocol/ I would like to get rid of the gsoc_app_v1 and develop some CAT <-> xiegu panel software (network <-> /dev/ttyS1). This will save a lot of resources and make things easier to adapt as there won't be any conflicts when accessing hardware components. So far I have this:

from gsoc-contrib.

Hello all. I have been following this thread for some time now, hoping that the GSOC could be hacked and opened up to better potential. I have been out of the IT field for some time and feel rusty, however, if there is someway I can assist, please let me know. -Tony

from gsoc-contrib.

@tonyluvsjazz Hello. If you feel you can help fill free to post some ideas. It's too early to test anything as the development is a complete chaos at the moment :)
Just to wrap things up here. Since last post I managed to:

• modify uBoot configuration to enable USB boot
• create Debian 11 based distro and successfully boot it on GSOC (from USB pendrive)
• play some Doom... because "this is the way"

I think it is time to start writing things down and prepare some repository / image. Now , with fully working operating system and apt in place it should be much easier to hack this device. There is still one little flaw in the architecture: I used uBoot and uImage from Xiegu...

At this point I have thank @michalrudowicz (SP6MR) for helping me on this. Without his assist it wouldn't be that easy and fun! Thank you!

from gsoc-contrib.

@d3cker That's great. I spent a little time messing with trying to get Nix (the package manager, not the OS) going on the stock buildroot system, but there is no armv7l binaries available so everything would need to be cross-compiled or built on another 32 bit arm platform. Since you have Debian booting from an SD card that doesn't seem to be worth the effort.

I finally have everything set up for some to do some work on this. I also broke down and bought an x6100 so that may make understanding and porting some of the support scripts from that platform to the GSOC easier.

from gsoc-contrib.