There was a problem in setting date in onestep and LX200Generic that I just fixed (uint8_t was used for years which does not work, it's now uint16_t). Please git pull and merge in your branch these changes.

Many thanks Jasem

I bought a non motorized one and then decided to modify it for EKOS scheduling rather than buy another. It uses a cheap little geared stepper like car vents use glued into the center shaft and a uln2003 driver board. I was working out which driver I want to emulate when we started looking into changes on this project.

Hi,

cooking, baking ... and tuning!
A propos the sniffer you want to rebuild, why not use linux

example: run this in a terminal (user must be in group tty)
========================================================
jpnevulator --ascii --print --tty /dev/ttyACM0 --pty=:/tmp/serial --pass --read > /tmp/teensy .............. (command)
jpnevulator: slave pts device is /dev/pts/8 ...............................................................................................................(return message)
========================================================
then in another terminal just run
========================================================
tail -f /tmp/teesy

in the meantime you connect your driver to /dev/pts/8 (where /dev/pts/8 is the device that jpnevulator returns

you end up with all the data in /tmp/teensy

and you have an in/out sniffer without risk of falling into the cable salad

As I said before, no coding:
I test the full document function by function before going further
Lets say I use it a a testing protocol

But I like salad! just not smoked. I've had fits with that inline in the past but since you mentioned it i'll have to try again. I think I was using TEE in the past.

I took a screenshot of that Time problem. I thought it was in 12hr mode but the code doesn't even allow that. It is for some reason bumping the time incorrectly and reporting 0800 instead of 2200 from UTC0300. I bet it's mishandling the return on the backwards way lx200 reports UTC. This is why I get horizon limit errors too and may exonerate the gps issue completely if we can fix it. Note the system time in the far upper right corner to see the proper time.

[later edit: and weird... When I set it manually forward it started working correctly, even after I redid UTC NOW - could it be something my mount is doing perhaps, maybe due to the lack of an RTC module?]

The weird picture is my asi120 on its side in the shop watching the mount and reducing stair climbing by a factor of about 48.

I checked this time issue and could not find an issue.
When I set the time with kstars the commans send to the controller look correct:
==============================
/tmp/serial
3A 53 47 20 2D 30 31 23 :SG -01# command issued by Indi, set UTC offset
/dev/ttyACM2
31 1 Onstep says OK
/tmp/serial
3A 53 4C 20 31 34 3A 31 37 3A 33 35 23 :SL 14:17:35# command issued by Indi, set local time
/dev/ttyACM2
31 1 Onstep says OK
/tmp/serial
3A 53 43 30 31 2F 33 31 2F 31 38 23 :SC01/31/18# command issued by Indi, set local date
/dev/ttyACM2
31 1 Onstep says OK
==============================
I remember when I first did test it long time ago I had trouble understanding the way LX200 sends in fact UTC * -1 so that the UTC becomes negative
.... it makes sense only after reading the definition that says "offset to add to local time" so iit must be negative

The only thing that is treated differently it that indi add a space between the actual command and the parameter but OnStep handles both correctly.

So still at the question, what is not working on your side?
For my setup I seee really no issue, but the writer is often the blind reader

I wonder if it happens when UTC wraps over midnight? I was questioning it myself after updating and having it show correct, but the screen shot clearly shows the discrepancy, as did the starfield that is exactly +5 instead of -5 at startup. Does yours have an RTC board installed? I was trying to avoid having a pesky i2c bus on this design but this would explain things. Or perhaps we have different firmware versions. When I saw last night that the "*" was in my version of the Arduino code I started wondering if we might have something different. !!!OH!!! I have the arduino Mega version! yikes! I hope they aren't different, that would be a mess.

Hi,

for the time beeing I have no RTC.
My setup is based on teehsy 3.5 which has an RTC inside and would need a battery solded in but i checked this on another teensy 3.2 which is busy on other tasks.
I even did not check if OnStep supports the builtin RTC (I neve seen code doing this but ...)

when you speak about arduino version do you mean OnStep code behaves differently hardware dependent?
I'm pretty sure there is no differnence between the versions, all interpretation is done by command.ino which is the same for all the platforms.
I had an arduino mega 2560 already mounted with all the motor drivers ..., I could test it there.

Yes, If command.ino is the same then that theory is out. I remember now that it was the focuser conde that had different files/versions based on hardware selections. OnStep has compiler directives instead.
I'll wait for your okay to do any more testing and reporting to cut down on confusion and let you follow your checklist without my wanderings. I look forward to your next update.

Yes for the focusers there are some diiferent things but for today (I am working on Alapha) I see only one implementation, and this is for stepper motor driven focusers.
This is one of the reason why at a first step I did not develop for it ... I did build a CC driven focuser that is pretty enought for me.
So now I have to check also how I cand do support for two fosusers (not speaking about derotator ... which also an additional option that exists)

Nevetheless even with the compiler directives that OnStep has, I don't think they change the behaviour of the commands with one exception, when Fork, AltAZ is selected, then yes.

May be I am not the right person, I think khalid baheyeldin whould be the right person that has this knowledge on OnStep.

Please feel free to check whatever you feel is important, I will include this is the todo jsut to keep track.

I take a break on coding and will read a bit the Indi literature, may be some lights will switch on

Finally got a night worth at least setting up. Really quick Suggestion, add a sync to driver[at startup] to get object from mount in case mount is already aligned and running...also sync and update the control window object(might be kstars problem) This would cut down on redo's when things go sideways. --[except it already does when things are working right.]
Onward and alignment!

I get a weirdness occasionally. no kidding right? this time it was the position would not update and the scope position was bouncing from place to place in kstars. (boggle)

Hi,

Syncing at startupt of the controllerby reading OnStep's actual taget you mean?

A propos parking, I think there is a strange thing I observed many times, parking fails (:GU# returns this at least also when parking via terminal)
I think there is a synchronization mechanism between the way indi manages the mount status and OnStep way to do that.

I also tested OnStep on Arduino Mega and having two kstars, one on raspberry the other on computer) I uncountered:
- Object below horizon on Raspberry
- And ok on computer
After aligning both Kstars version no more difference.

I really have to go more deep in detail how Parking / Unparking interacts.
I have the impression I made a fundamental error here .
Could not check anything, other todos were in the way