Silly question but have you tried the AZ-GTI device which has Wifi support built in and as its based on the EQMOD which will talk to MOST SW mount motors directly so is using the corrent "SW protocol" already. If nothing else its not a bad place to start looking at the coding

Forgive me in saying SW aren't going to create new boards/motor protocols for the newer GoTo Dobs as it doesn't make commercial sense - IMHO.

If nothing else no wiring (get it wrong and its bye bye board - e.g. 12v onto 3.3v = bang) - and do not trust wiring colours (color) - I have found that they dont match across the same cables - the pins do so follow the pin outs IMO.

But if you love "fiddling" thats great and good luck

deleted wrong

The AZ-GTI driver was already mentioned in this thread.
I would be happy if someone could tell me how to teach the eqmod driver that the mount is not in eqatorial but alt/az setup.
The eqmod driver can talk to an alt/az mount through UDP, I've tested it with my Virtuoso mount. That is good so far. But a big dobsonian mount cannot be tilted into equatorial configuration. Even the small Virtuoso mount does not work (seriously unbalanced) this way.

I've posted the pinout "fiddling" information for anyone who wants to make their own "eqmod cable".
If you are living in the USA surely you can just buy a ready made eqmod cable, and no fiddling is needed. You are right SW does not seems to change the motor board protocol/pinout, the old hand controllers seems to work with newer mounts too.
But I liv in estern Europe, for me ordering an eqmod cable would mean 20-30 USD shipping cost for a less than 10 USD cable. That's why I made one for myself.

I tend to agree with those who prefer cable connection over WiFi. Your Raspberry is on the mount anyways, right? No need for unreliable WiFi connection here. Especially problematic when the software on the RPI is responsible for tracking.

Gubi:
Thank you! That documentation is priceless. What a time-saver! As to C/C++, I'm not totally useless in that discipline, and both Object-oriented Perl and Java do the inheritance thing. It was just never my platform of choice.

Recently, there was a call for COBOL programmers to update some "my generation" software. I have written a lot of COBOL software, but always hated it. Each time I finished a COBOL project, I hoped it would be the last one I ever saw. Right now, it would be easier for me to get up to speed in C/C++ than COBOL, despite my previous experience, because I do, at least, respect C/C++ rather than loathe it as I do COBOL.

I'll order one of those FTDI cables today and see about the code while it is on the way. The FTDI cable should work well with the Pi4 I have mounted on the scope.

I understand very well what you are speaking about.
The low level protocol handler has pretty much already written in indi/drivers/telescope/skywatcherAPI.cpp so you do not need to have much headache about that. All the usability problems are deep in the details.

Yes, the FTDI cables are supported out of the box on linux. The RPI also has an onboard serial port (so called serial console, /dev/ttyS0) which is also TTL level. I have not tried to use it, but in theory it should also work.
Be careful ordering, there are a lots of type of FTDI cables. Be sure to choose the TTLUART ones. It doesn't really matter if you buy the +3.3V or the +5V one, since these only differ on the voltage the cabble supply on the power pin, which is not used here (Be careful, not to connect it to the mount's power pin, both are output! Connect only GND , RX, TX. Nothing else). But there is a type that has a 6 pin 100 mil block connector at the end, and there is a type with separate wires. Some has extra wires for SPI. These also works, you just don't use those extra wires.
FTDI is not the cheapest solution, but works. There are cheaper Chines ones, which maybe work, maybe not.

"The AZ-GTI driver was already mentioned in this thread." - yes I know (KNRO * 2,me once) ) but your answer was unclear if you had tried it or not Yes you did say about some annoying bits of Alt-GTI which seems to imply you have but I wasn't clear.

Plus the AZ-GTI is going to be nearer what you are looking for than Synscan or EQMOD especially if you are going to write a "new" Indi driver .

Just saying Last time promise

No, there is no annoying bits of Az-GTI (at least not I know about). I have taken a look at the source code of the Az-GTI driver, it is inherited from the EqMod driver. The only difference I see is that it defaults to network connections with the correct default UDP port and host IP.
So it is an EqMod driver. Which makes sense since the Az-GTI hardver officially has an equatorial configuration when one put it on a wedge (counter weights and everything). But what we are trying to achieve here (both me and JonCarleton) to use a big Dobsonian mount with Indi. This must be used in Alt-Az mode, putting it on a wedge is not an option.
In the beginning comment section skywathcerAPIMount.cpp it says:
* This file contains the implementation in C++ of a INDI telescope driver using the Skywatcher API.
* It is based on work from three sources.
* A C++ implementation of the API by Roger James.
* The indi_eqmod driver by Jean-Luc Geehalel.
* The synscanmount driver by Gerry Rozema.
So it is already based on the eqmod driver.
This driver is mostly works, with some annoying bits which I'm just trying to iron out through pull request to the indi github. But it is a slow process mostly because I myself have to became familiar with the quite complex Indi ecosystem. This is a huge peace of software!

Stash:
I appreciate your input and will look at the AZ-GTI driver before I commit to any code plan. I tend to look at as many options as I can and then start the process of elimination. What I have left on the table at the end is what I work with.

Sometimes that even works

Gupi: This is a huge peace of software!

The above is exactly why I appreciate the wisdom of this thread.

Alternative to waiting for Sky Watcher prodcuct and as long as you trust the pin outs (which are 99% ok) then you could just but a ready made EQMOD ( name is irrelant in this case it should work with anything) like this $12 inc del to USA www.aliexpress.com/i/32995620143.html

and just splice the mount end and put you own connector wired to the correct pin outs. The spec for EQMOD (e.g. AZEQ6GT) wiring is online on EQMOD so just a case of making sure you have connected to your new pin outs. Plus you of course can get the same cable in the USA

anyway I presume so only a couple of days waiting for delivery!

The SW product is, I am told, a Prolific Chip device where as the above is an FTDI which means no clash on USB ports (FTDI have a unique serial number) an in Linux Udev can be used to make that device a perm mount connection with appropriate name in /dev.

Prolific Chip devices are good too.

I've bought myself an USB-RS232 cable to update the firmware of the hand controller. The first one I bought was based on the Chinese CH340 chip, and it is very unreliable. In the middle of firmware upgrade just lost connection. I thought first I was managed to brick my hand controller. Fortunately the hand controller has some safety feature and recovered. I was never able to do anything useful with that cable (I bet the flow control is broken).
Later I bought an other one, based ont Prolific chip, and in works just fine!
Sometimes unfortunately one just cannot tell which chip a given product based on, just after buying and seeing the driver.