Same issue here, most FITS files produced lack the filter entry (it intermittently appears in some of the files).
Unfortunately I'm not sure what version of KStars was running since the data is from over a month ago running on a Pi4 I don't have access to right now. Speaking of which: it would be great if KStars/EKOS could record the executable version number in the header.
If I get a chance I might try to debug it, since it's certainly pretty annoying...!
Read More...
wjdrijfhout wrote: Just checking in to see if there has been any follow up on this. Is there agreement on how to solve the issue, leaving the SS2 settings leading and ensure the INDI driver does not override profile vs Ignore the SS2 settings and set all parameters in Ekos?
I'd be happy to try out a 'nightly build', but don't know how to install that, and would like to limit that to only this driver.
Hi Willem, I'll chase up with Jasem on how best to handle motor settings precedence. In theory it ought to be possible to offer the user an option as to what takes precedence - so I might look into that.
Regarding installing an INDI nightly build - it depends on the CPU architecture and OS you're running INDI on....?
Read More...
knro wrote: I see your point. So if the values were really stored in the EEPROM, they were not then read correctly by the driver?
The driver never read the motor settings values before my changes - it just simply applied the default "slow" motor settings preset stored in the EEPROM via a serial command on connect:
bool SestoSenso2::setupRunPreset()
{
char res[SESTO_LEN] = {0};
if (command->loadSlowPreset(res) == CMD_FALSE)
{
return false;
}
return true;
}Perhaps there should be an option within the driver to determine whether the EEPROM or INDI motor settings take precedence?
Read More...
@Willem: Sorry, I only just saw your original message. The original INDI driver logic applied the built-in Slow motor preset for the Sesto Senso 2 on connect. The changes I made to expose the motor settings via the INDI driver removed this - so all recent nightly builds shouldn't override the current SS2 settings, even if they were set outside of INDI. So I think the issue is you weren't using a recent enough version of INDI. Unfortunately, the main changes went in immediately after the most recent (v1.8.
release of INDI in January. So you will need a recent nightly build to see the changes.
@Jasem: I'm on the fence about overriding the SS2 motor settings via the saved INDI values. I was taking the approach that the settings stored on the SS2 flash were authoritative. It is quite possible that users may use the SS2 web interface to fine tune the motor settings outside of INDI. But that said, perhaps the INDI settings should have precedence? I wasn't sure where you typically draw the line when it comes to devices that maintain their own state...?
Read More...
I've just submitted a new pull request with a simple workaround that allows custom motor settings to be saved and loaded (despite the firmware bug).
github.com/indilib/indi/pull/1319
With that in, I think the driver is just about functionally complete. If you run into anything just let me know and I'll take a look!
Cheers,
Will.
Read More...
gilesco wrote: I've been working with just modifying the loadSlowPreset in sestosenso2.cpp to load the Esprit profile I created in the Web App, and checking again after loading. It appears to either have not loaded the slow preset and kept the functionality that was previously set by the Web App, or it actually reloaded the Esprit profile.
Yep. You can apply any of the three built-in presets, but none of the custom ones will apply successfully. In this case the motor settings are just whatever you last applied via the web app.
gilesco wrote: I was wondering, what hold current are you using on the Esprit, I set mine to 3, but not had enough chances to work out whether it's an improvement (it's the only setting I've actually used to focus with since I got the Esprit). In any case, focusing is working very well, I'm getting a good gradient curve for focus operations and I have not noticed any slippage - I probably need to run some dry tests with the OTA mounted indoors.
I've tried with a hold setting around 3, but haven't had much chance to experiment since I completed the code. However, it'll only really make a difference if you're shooting up towards the zenith, generally I didn't have too many issues until I started trying to target objects high in the sky - only then did slippage become an issue.
Read More...
I've managed to save into the custom preset slots using the Windows Focuser Manager 1.3 and the Virtual HandPad web app as well as through the INDI driver code. However, irrespective of the client used, actually loading/applying one of the custom presets always fails for me with:
{"res":{"cmd":{"RUNPRESET":"Error: empty preset"}}}I checked this in the Virtual HandPad web app by setting a breakpoint where the JSON command is sent to the REST endpoint. The same error result is seen in this as when using the serial interface.
I'm hoping to hear back this week, but if it takes any longer I'll just create a pull request without the custom preset functionality since it actually achieves what I needed and perhaps I can add it later once a firmware fix is available.
Read More...
As a quick update to this: I've implemented support for setting all of the motor move rates and voltages (including hold). This all seems to work well. However, while attempting to add support for loading/saving the custom motor presets, I discovered that the Sesto Senso 2 1.3 FW doesn't actually seem to apply the custom motor presets when requested. I'm waiting on a response from the Prima Luce Lab before proceeding as I suspect they'll want to fix the issue in their driver.
Hopefully I'll hear back soon!
Read More...
That's great! Thanks for the heads-up on the new 1.3 firmware - I also installed it last night and thankfully it looks like the changes are fairly safe:
Last version 1.3 22/10/2020
1) Added Virtual HandPad compatibility with more WiFi devices
2) Added "Reverse motor" feature
3) Bugs fixed
4) Removed maxstep limit in ASCOM drivers
Also, thanks for dumping the serial output. I reformatted the JSON below as it shows some interesting state (voltage in, LED dimming, hold status etc) that might be nice to expose via the INDI driver:
{
"req": {
"get": ""
}
}
}{
"res": {
"get": {
"SWID": "001",
"MODNAME": "SESTOSENSO2",
"SN": "SESTOSENSO20716",
"HOSTNAME": "SESTOSENSO20716",
"MACADDR": "70:B3:D5:32:95:2F",
"SWVERS": {
"SWAPP": "1.3",
"SWWEB": "1.3"
},
"LANCFG": "ap",
"LANSTATUS": {
"LANCONN": "disconnected",
"PINGGW": 0,
"PINGEXTHOST": 0
},
"WIFIAP": {
"SSID": "SESTOSENSO20716",
"PWD": "primalucelab",
"IP": "192.168.4.1",
"NM": "255.255.255.0",
"CHL": 2,
"MACADDR": "70:B3:D5:32:95:30",
"STATUS": {
"HIZ": 0,
"UVLO": 0,
"TH_SD": 0,
"TH_WRN": 0,
"OCD": 0,
"WCMD": 0,
"NOPCMD": 0,
"BUSY": 0,
"DIR": "In",
"MST": "stop"
}
},
"WIFISTA": {
"SSID": "MySSID",
"PWD": "MyPassword",
"IP": "",
"NM": "",
"GW": "",
"DNS": "",
"MACADDR": "70:B3:D5:32:95:2F"
},
"EXT_T": "-127.00",
"VIN_12V": "13.97",
"ARCO": 0,
"LEDBLINKSTATUS": "PowerInLess11Volts",
"PRESET_1": {
"NAME": "",
"M1POS": 0
},
"PRESET_2": {
"NAME": "",
"M1POS": 0
},
"PRESET_3": {
"NAME": "",
"M1POS": 0
},
"PRESET_4": {
"NAME": "",
"M1POS": 0
},
"PRESET_5": {
"NAME": "",
"M1POS": 0
},
"PRESET_6": {
"NAME": "",
"M1POS": 0
},
"PRESET_7": {
"NAME": "",
"M1POS": 0,
"M2POS": 0
},
"PRESET_8": {
"NAME": "",
"M1POS": 0,
"M2POS": 0
},
"PRESET_9": {
"NAME": "",
"M1POS": 0,
"M2POS": 0
},
"PRESET_10": {
"NAME": "",
"M2POS": 0
},
"PRESET_11": {
"NAME": "",
"M2POS": 0
},
"PRESET_12": {
"NAME": "",
"M2POS": 0
},
"DIMLED_1": 200,
"DIMLED_2": 200,
"DIMLED_3": 200,
"MOT1": {
"ABS_POS": 18075,
"EL_POS": 0,
"MARK": 0,
"SPEED": 0,
"ACC": 5,
"DEC": 5,
"MAX_SPEED": 4,
"MIN_SPEED": 0,
"TVAL_HOLD": 0,
"TVAL_RUN": 20,
"TVAL_ACC": 20,
"TVAL_DEC": 20,
"T_FAST": 25,
"TON_MIN": 41,
"TOFF_MIN": 41,
"FS_SPD": 1023,
"OCD_TH": 2,
"STEP_MODE": 4,
"CONFIG": 11904,
"ALARM": 255,
"STATUS": {
"HIZ": 1,
"UVLO": 0,
"TH_SD": 0,
"TH_WRN": 0,
"OCD": 0,
"WCMD": 0,
"NOPCMD": 0,
"BUSY": 0,
"DIR": "Out",
"MST": "stop"
},
"NTC_T": "36.96",
"CAL_MAXPOS": 17639,
"CAL_BKLASH": 0,
"CAL_MINPOS": 0,
"CAL_HOMEP": 1000,
"CAL_NUMOF": 0,
"CAL_DIR": "normal",
"LASTDIR": 0,
"LOCKMOV": 1,
"HOLDCURR_STATUS": 1,
"FnRUN_ACC": 1,
"FnRUN_DEC": 1,
"FnRUN_SPD": 2,
"FnRUN_CURR_ACC": 7,
"FnRUN_CURR_DEC": 7,
"FnRUN_CURR_SPD": 7,
"FnRUN_CURR_HOLD": 1
},
"RUNPRESET_L": {
"RP_NAME": "light",
"M1ACC": 10,
"M1DEC": 10,
"M1SPD": 10,
"M1CACC": 3,
"M1CDEC": 3,
"M1CSPD": 3,
"M1HOLD": 1
},
"RUNPRESET_M": {
"RP_NAME": "medium",
"M1ACC": 6,
"M1DEC": 6,
"M1SPD": 6,
"M1CACC": 5,
"M1CDEC": 5,
"M1CSPD": 5,
"M1HOLD": 1
},
"RUNPRESET_S": {
"RP_NAME": "slow",
"M1ACC": 1,
"M1DEC": 1,
"M1SPD": 2,
"M1CACC": 7,
"M1CDEC": 7,
"M1CSPD": 7,
"M1HOLD": 1
},
"RUNPRESET_1": {
"RP_NAME": "Esprit",
"M1ACC": 1,
"M1DEC": 1,
"M1SPD": 2,
"M1CACC": 7,
"M1CDEC": 7,
"M1CSPD": 7,
"M1HOLD": 3
},
"RUNPRESET_2": {
"RP_NAME": "User 2",
"M1ACC": 6,
"M1DEC": 6,
{
"req": {
"get": ""
}
}
}"M1SPD": 6,
"M1CACC": 5,
"M1CDEC": 5,
"M1CSPD": 5,
"M1HOLD": 1
},
"RUNPRESET_3": {
"RP_NAME": "User 3",
"M1ACC": 1,
"M1DEC": 1,
"M1SPD": 2,
"M1CACC": 7,
"M1CDEC": 7,
"M1CSPD": 7,
"M1HOLD": 1
},
"MOT2": {
"ABS_POS": 0,
"EL_POS": 0,
"MARK": 0,
"SPEED": 0,
"ACC": 35,
"DEC": 35,
"MAX_SPEED": 30,
"MIN_SPEED": 0,
"TVAL_HOLD": 1,
"TVAL_RUN": 18,
"TVAL_ACC": 18,
"TVAL_DEC": 18,
"T_FAST": 25,
"TON_MIN": 41,
"TOFF_MIN": 41,
"FS_SPD": 1023,
"OCD_TH": 2,
"STEP_MODE": 4,
"CONFIG": 11904,
"ALARM": 255,
"STATUS": {
"HIZ": 1,
"UVLO": 0,
"TH_SD": 0,
"TH_WRN": 0,
"OCD": 0,
"WCMD": 0,
"NOPCMD": 0,
"BUSY": 0,
"DIR": "In",
"MST": "stop"
},
"CAL_MAXPOS": 0,
"HSENDET": 1,
"HEMISPHERE": "northern",
"COMPENSATION_DEGS": 0.00000,
"CAL_STATUS": "stop",
"CAL_MINPOS": 0,
"CAL_HOMEP": 1000,
"CAL_NUMOF": 0,
"CAL_DIR": "normal",
"LASTDIR": 0,
"LOCKMOV": 1,
"HOLDCURR_STATUS": 0
},
"DIMLEDS": "on",
"LOGLEVEL": "no output"
}
}
}The approach of using a preset is probably the simplest for getting things up and running. However, it would still be great to be able to control the presets and motor hold state via INDI rather than having to go via the Virtual Handset or Focus Manager.
I'm hoping to get some time next week to see if I can start hacking the driver support - unfortunately this week didn't allow me much time.
Read More...
I just tried to see if the hold current settings would persist if set via the Wifi Virtual Handpad (and also via the Windows ASCOM driver) but it seems that they don't. Or at least, as soon as I connect the INDI driver it seems to reset the hold current resulting in focus slippage - especially towards the zenith.
The hold current setting definitely need to be exposed via INDI as without it focus is going to be highly unreliable with heavier setups. If I get a chance I might take a look at implementing it in the driver myself but that depends on knowing what commands are required... Anyone? 
gilesco wrote: I have a question, I have the Sesto Senso v2 already, with the cigarette adapter, I notice that the usual 2.1mm power connectors don't fit the Sesto Senso v2 power port. Do you know what port I can use to avoid the cigarette adapter?
Congratulations on the new telescope! The 12VDC socket on the Sesto Senso 2 is 5.5 x 2.5mm barrel socket rather than the more standard 5.5 x 2.1mm barrel socket. I ended up making my own DC cable to run from my Pocket Power Box to the the Sesto Senso 2 which works fine. Alternatively (if you already have 5.5 x 2.1mm cables), you could perhaps get an adapter like this .
If you have any other questions, feel free to drop me a line!
Read More...