Optimize Alpaca exchanges

[cyrille.de.brebisson]

Hello,

I am working on a mount based on an esp32 and am moving away from having an ascom driver on the computer as ascom is saying: move to alpaca or die (soon).

However, the way SharpCap sends Alpaca request to the esp32 is sub-optimal and is causing load on the system (I assume that I will not be the only one who suffers looking at how much esp are used in astro gear, amateur or professional .

SharpCap sends 13 requests every 1/2 second to the mount (to get the "state").
This translates to 13 packets like this one (around 160 bytes).
"GET /api/v1/telescope/0/trackingrate?ClientID=1&ClientTransactionID=25899 HTTP/1.1
Host: 127.0.0.1
Accept: application/json
User-Agent: ASCOMAlpacaClient/2.2.1.0

"

Would it be possible to send all these request in a single TCP "send" instead of 13 separate send.
This would reduce the load on the esp32 by dropping the wifi count.
Furthermore, if you could drop the optional "Accept: application/json User-Agent: ASCOMAlpacaClient/2.2.1.0", this would save enough bytes to allow the full 13 request to fit in a single wifi frame.

It might also be possible to remove the request for the equatorialsystem which will not change once the mount has started..

Here are the 13 calls that I am seeing.
get_altitude -> 0.000000
get_azimuth -> 0.000000
get_sideofpier -> 1
get_targetrightascension -> 0.000000
get_targetdeclination -> 0.000000
get_equatorialsystem -> 2
get_tracking -> true
get_trackingrate -> 0
get_slewing -> false
get_rightascension -> 22.031948
get_declination -> 89.104324
get_atpark -> false
get_siderealtime -> er:ALPACA_ERR_VALUE_NOT_SET


In my case the problem is further increased because the same HW also handles the focuser, so I see these extra 4 calls:
get_connected -> true
get_ismoving -> false
get_position -> 32767
get_temperature -> er:ALPACA_ERR_ACTION_NOT_IMPLEMENTED

Thanks,
Cyrille

[admin]

Hi Cyrille,

I think I would need to transition from fetching the properties individually to fetching the device state in one call, but that is an ITelescopeV4 only feature, so I would need to check how the ASCOM client libraries handle fallback in that situation. I can trim back a couple of the update requests as you suggest - not quite sure why the co-ordinate system is being re-polled for instance!

Right now, you have a bit of a workaround available to you - there is a hidden setting that you can change via registry editing to adapt the mount refresh interval from the default 0.5s to anywhere between 0.1 and 2.0 s.

Create a REG_SZ (string) value in the registry called 'Hardware.MountRefreshInterval' at

Code: Select all

HKEY_CURRENT_USER\Software\AstroSharp Limited\SharpCap\4.2\misc

(note - that is for 4.2 - change the key name for 4.1, etc).

Set the value of that registry entry to for instance 1.5 for a 1.5s refresh interval.

cheers,

Robin

[cyrille.de.brebisson]

Hello,

Thanks for the tip on refresh rate, it does seem to help.

With regard to the property fetch, I understand the difficulty to change such things and how it might be hard for you...
But I do have a question, you are talking about ITelescopeV4.
But I thought that you implemented ALpaca yourself without going through the Ascom library. Was I incorrect?

Have a great day,
Cyrille