OK sorry I misread that you actually wanted to test the online solver first.
In your log, I don't see the plate solver running, and I still see the CCD being requested a 2504x3362. Not the right log perhaps?
Apparently, the nova.astrometry.net service was down lately (bad luck somehow). This could be an opportunity for you to download index files and test the offline solver.

-Eric

i did extra tests and i will post a few replies in order not to cluter one post and confuse things.
The new tests include the following steps. Start Ekos/indi and at the alignment tab i enable the plate solver and at the option tab i tick the To log option and save configuration. All the tests are done with the offline solver in case the online server is down and i use the same star.

Test 1 RC 8'' camera 1280x1024 5.2 micron pixel size (default camera)

At both bin 1x1 and 4x4 the solver works

Test 2

RC 8'' scope and Atik 383l+

At bin 4x4 i noticed that the test star is not at the FOV as in the previous test. furthermore the solver seems to timeout but at the solution results i see that the previous request is still running up to the point i stop it. After that i have to manually delete the solution results in order to get proper indi/ekos shutdown or else the RPi will crash.

At bin 1x1 thes solver works fine and the star FOV is different that than one of the bin 1x1

Test 3

Ed80 and Atik 383l+. Thing here get weird.

For the expected FOV i pasted the FOV 1.73° x 1.29° since i wasn't sure that the 1.73' x 1.29' would work even though i specified at the solver options the dw for degrees. At bin 1x1 i had the same behaviour as the RC 8'' bin 4x4

same test as before but this time i let the solver calculate and enter the fov. same behaviour as before

next test with ed80 and default camera 1280x1024. the solver works at bin 1x1 but fails at bin 4x4

final test with ed 80 atik but longer duration at bin 1x1 the solver works but at 4x4 the solver fails and th fov is different than the one of 1x1

Binning should not modify the FOV that is pre-calculated and provided as a hint to the solver.

In the logs you provided I see that a second solve is started before the first finished. This prevents source extraction because the input FITS has a hardcoded name, not a temporary name, and the solvers fails systematically. This could be reported as a bug on the INDI github, but it's unexpected that a second solve request be requested before the first finished. However, I observe that you don't wait for the second solver execution to fail before disconnecting indiserver.

For instance, in indilib.org/media/kunena/attachments/4725/log_07-30-39.txt (this is CCDSimulator on a 24.4 arcmin FOV), a first CCD capture is forwarded at 7:32:20, solver starts, and then a second is forwarded at 7:33:26, before the first solver procedure is finished. The first solver procedure breaks because apparently the solver accesses the FITS file sources once per index file. The second solver procedure is aborted by the disconnection of indiserver. So in that log, I don't see any solver failure, only interrupted solver procedures.

On the opposite, in indilib.org/media/kunena/attachments/4725/log_07-27-28.txt (same CCDSimulator on a 24.4 arcmin FOV), the first CCD capture is forwarded at 7:29:32 and solved successfully at 7:30:18 with a pixel scale of 1.78"/pix.

I have no straightforward explanation for the duplicate capture occurrence. What I see (and you see that too of course) is that when you run a CCD simulator capture binned at 1x1 with GSC, the solver succeeds. So I'd stick to that configuration to successfully solve a frame in that configuration. 4x4 binning on the CCD simulator using artificial stars is not giving satisfactory results, that's all.

In your last run with a configuration matching your Atik, GSC produces a ~64.4 arcmin radius frame. Same observation as you, 1x1 binning works, 4x4 binning doesn't have time to complete. Here again, no failure, but an aborted solver procedure. However, the CCD Simulator rejects your width of 3362. So I guess from there the frame doesn't match the expected FOV anyway.

Note that while I don't observe failures, I'll admit that a solver procedure - in your situation - taking more than 3 seconds is actually bound to fail.

Even with these failures, I believe that your setup is ready for a live test with your real equipment. Do it simple, sync 15° from pole, bin 1x1 and let the solver find the solution.

-Eric

thanks for your input eric, i am waiting for the first chance for a live test, i made two profiles, for the ed80 and the rc8 and i will test first the ed80 and i'll post the logs

Sorry I have to add my comment which should be obvious.

There is no way Platesolving works with static parameters - yes have a base line which solves 70% of the time but hell the sky at night is never the same each night (even hr to hr) and you have to be prepared to "bend" a little and modify the parameters according to sky conditions.

I like many others have found Indi Platesolver very good but it cant be expected to know the sky conditions from one platesolve to another

As Eric says get out there and use it for real

I will now get back under my stone

And don't go too fast with tests. Let the solver finish its work before attempting to solve again, in order to get the full picture. On my setup, which is fairly low-end, solver takes 70 seconds to complete searching for a solution that is 4-5 degrees apart. Subsequent searches closer than 1 degree take less than 10 seconds. I reset the model before each target for robustness, because the incurred delay is acceptable as long as the procedure completes successfully.

-Eric