Onstep MiniPCB2 basic questions #iOptron


 

Hello guys, Currently I have my G-11 modify with Onstep MiniPCB2 (Tenssy 3.2) with Smart Hand Controller (ESP32 version)
 
Before I ask questions... I'll explain how I use 1st..

My Step by Step Using Onstep:
After power up MiniPCB2 success Connect WiFi Onstep on Smart phones then I lunch Onstep ApK set Date & Time then key in coordinate altitude and latitude & upload, after that I set my home park & try do a object goto slew..it was slewing to wrong direction. I didn't do any star alignment yet.

My Questions:
1. Izzit must do star alignment to tell onstep system to recognize all the sky objects location before get accurate goto slew?

2. Izzit possible to build a GPS in onstep for easy recognize the sky ones power up MiniPCB2. Similar like IOptron system? 

3. If my coordinate show in SkySafari N 04º 03' 24.3"  E 101º 37' 15.1" +8 timezones ( what should actually look like in onstep ) ?

I do hope anyome could help me solve this last step to get it all working correctly, appreciate anyone for advice & help. Thx


Shai
 

2. Izzit possible to build a GPS in onstep for easy recognize the sky ones power up MiniPCB2. Similar like IOptron system?

I'm about to start building a MiniPCB2 with Teensy 4.0 and I'm also thinking of adding GPS somehow. I was looking at the PCB and as far as my limited understanding of electronics can tell, there are no free serial ports on the Tennsy (correct me if I'm wrong).
There are however both TX and RX port on the Wemos that are connected to nothing. I was thinking of maybe using double male headers for the TX, RX, 5V and GND on the Wemons, and this way to have all 4 needed connection points on the same board. The only question is whether or not it is possible to transfer the GPS data from the Wemos to the Teensy. Intuitively I think it should be possible because we are doing that when using a smartphone's wifi to send this data to Onstep.

If this was completely wrong tell me and I'll stop trying to find solutions to problems in fields I'm far from being an expert in :)


Howard Dutton
 

On Mon, Nov 30, 2020 at 05:12 AM, Shai wrote:
I was looking at the PCB and as far as my limited understanding of electronics can tell, there are no free serial ports on the Tennsy (correct me if I'm wrong).
Not on the PCB (other than giving up the WiFi or Bluetooth) but there are other unused serial ports on both the T3.2 and T4.0 here's the T4.0...

https://forum.pjrc.com/teensy40_pinout2.png


Shai
 

Do you mean soldering the weirs to the bottom of the board? (say pads 24 and 25).
And since I'm not using BT (not using a smartphone, so there's nothing to do with it. And this is the main reason I want to add GPS), is it possible to do the same "trick" as Roman did, only with a GPS module? It would be better then having weirs coming from under the Teensy.


Howard Dutton
 

On Mon, Nov 30, 2020 at 08:46 AM, Shai wrote:
And since I'm not using BT (not using a smartphone, so there's nothing to do with it. And this is the main reason I want to add GPS), is it possible to do the same "trick" as Roman did, only with a GPS module? It would be better then having weirs coming from under the Teensy.
If nothing else is in the socket normally used for the WeMos D1 Mini for WiFi you can use those serial port pins to connect the GPS.  Then using Serial1 for GPS should work.  Refer to the EasyEDA schematic to see where the Teensy's serial port pins are on that WeMos socket.

Just be sure to set SERIAL_B_BAUD_DEFAULT OFF in OnStep's Config.h file.


Shai
 

Ok, I don't think that's an option, because I still want wifi.
Just to be clear we're on the same page and not missing something, my idea was that the Wemos will read the GPS data (through it's free serial ports) and then send it to the Teensy. Does it make any sense?

If it can't work I'll just solder weirs to the pads at the bottom and get 5V and GND from one of the components


Shai
 

And thanks :)


Howard Dutton
 

On Mon, Nov 30, 2020 at 10:43 AM, Shai wrote:
Ok, I don't think that's an option, because I still want wifi.
Just to be clear we're on the same page and not missing something, my idea was that the Wemos will read the GPS data (through it's free serial ports) and then send it to the Teensy. Does it make any sense?
Probably could work, if you're capable of doing the coding for it, have at it.


Shai
 

Cool. I'll give it a try (will probably take some time because I still don't have all the parts for the build and can't test anything)


Howard Dutton
 

On Mon, Nov 30, 2020 at 11:11 AM, Shai wrote:
Cool. I'll give it a try (will probably take some time because I still don't have all the parts for the build and can't test anything)
If I were interested in doing this I'd:
1. Use a software serial library since the ESP8266 has only one available hardware serial port that can receive data.
2. Run the NMEA decode library on the ESP8266.
3. Get the Latitude/Longitude/Date/Time then send that info. to OnStep via the standard LX200 commands.


Shai
 

Which means I've got some reading to do (always glad to learn something new) because most of my programing was done in pascal and some C++ many years ago. I'm still working with logic in university, so the intuitions are there, but I do need to learn a new language.


Shai
 

Kokoro San, I hope it will be useful for you too (if I manage to get it to work)


Mike Ahner
 

On Sat, Nov 28, 2020 at 04:39 AM, Kokoro San wrote:
My Questions:
1. Izzit must do star alignment to tell onstep system to recognize all the sky objects location before get accurate goto slew?

2. Izzit possible to build a GPS in onstep for easy recognize the sky ones power up MiniPCB2. Similar like IOptron system? 

3. If my coordinate show in SkySafari N 04º 03' 24.3"  E 101º 37' 15.1" +8 timezones ( what should actually look like in onstep ) ?
Hi Kokoro,
1) Yes you must do at least a 1 star alignment with OnStep. If your mount is permanently located (not moved) then I think you can just start tracking, slew to a star and sync. I believe you only use Park if your mount is permanent and you can leave aligned.

2) There are answers in this thread.

3) OnStep uses the opposite of a Timezone offset to calculate UTC offset by changing the sign. So if your timezone is +8, then in OnStep, the UTC offset should read -8. You use the Android app to set current location, date & time but you may have to verify UTC offset is correct.


 

 
am grateful to have Howard & Shai & Mike reply on my post.

Reply Shin: sadly...i have no experience on coding or get GPS running... usually i learn from ppl that been ready build, then i just follow their step by step  :)   hope to see you success GPS build in on Minipcb2 !
Reply Mike: you mean after onstep apps lunch and upload all date time & coordinate without unpark at 0 position then just do 1 or more star alignment with manually slew to target then Sync? not goto then Sync right?
Reply Howard: if GPS able to work on minipcb2 will it better accurate sky recognize when using on Onstep?  


Shai
 

I was reading last night and it seems much simpler now (still need to understand how to send the data to Onstep, needed to go to sleep).

Kokoro San, if it will be workable for me it should be workable to anyone using ESP8266 without any coding done by yourself.


Shai
 

Howard, what is the format Onstep uses for the location and time data (including EW and NS)? So I can convert it correctly.

And I was thinking of telling it to update the data only when a minimal number of satellites are available (say 4), and to update it only periodically (say every 10 minutes, or maybe even just once after startup and good signal acquisition).


Dave Schwartz
 

Any time you have a question about command formats, the ultimate reference is command.ino. They may also be listed in the command protocol reference in the Wiki but that is sometimes not complete or up to date (although its getting better).

OnStep supports two formats: the normal LX200 mode which does not need to be ultra accurate and a high-precision mode for weenies like us who like to be ultra accurate even though it will have virtually no effect on the result.

Here are the commands OnStep supports for getting and setting latitude and longitude:

// :Gt#       Get current site Latitude, positive for North latitudes
//            Returns: sDD*MM#
// :GtH#      Get current site Latitude, positive for North latitudes
//            Returns: sDD*MM:SS.SSS# (high precision)

//  :St[sDD*MM]# or :St[sDD*MM:SS]# or :St[sDD*MM:SS.SSS]#
//            Set current site latitude

// :Gg#       Get Current Site Longitude, east is negative
//            Returns: sDDD*MM#
// :GgH#      Get current site Longitude
//            Returns: sDD*MM:SS.SSS# (high precision)

//  :Sg[(s)DDD*MM]# or :Sg[(s)DDD*MM:SS]# or :Sg[(s)DDD*MM:SS.SSS]#
//            Set current site longitude, east longitudes can be negative or > 180 degrees

As far as when to update in the software, I believe the way OnStep does it is to ignore the GPS port until the PPS signal becomes good (no GPS units start to output the PPS signal until they have achieved a fix). Then read the date, time, latitude and longitude once from the GPS and never again that session.

On 2020-12-01 5:03 a.m., Shai wrote:
Howard, what is the format Onstep uses for the location and time data (including EW and NS)? So I can convert it correctly.

And I was thinking of telling it to update the data only when a minimal number of satellites are available (say 4), and to update it only periodically (say every 10 minutes, or maybe even just once after startup and good signal acquisition).


Shai
 

Thank you Dave, I'll convert it accordingly and next time I'll know where to look


 

Wow thx Dave n Shai!
Cant wait to see the final results! Appreciate every help can get! Thx guys


Dave Schwartz
 

The location data may not be the most accurate when PPS first becomes valid because the fix it has at that point is using the minimum number of satellites needed to obtain a 2D fix. Eventually, the position error may become less as more satellites are acquired (and the fix will become 3D). However, you can't really wait for a certain error estimate or number of satellites because for any given time or location you never know how good its going to get.

Regardless, that initial position even with the maximum error estimate is probably as accurate as required for the non-high precision commands. Holding out for the best location accuracy is really only going to benefit you by getting the first alignment star closer to the center of the eyepiece and even that is highly dependent on your polar alignment. Once you've completed the alignment, a more accurate fix does no good so some complex algorithm to wait for and update with better data is a waste of time.

If you travel a lot such that you want to have the location set by GPS, then your polar alignment probably isn't going to be good enough to take advantage of the highest location precision.

If you have a permanent pier-mounted telescope, your polar alignment is probably good enough to take advantage of the highest accuracy a GPS could output but since that first fix probably has the lowest accuracy the GPS will get in that session it works against you as that position will often be wandering randomly around your true location.

Perhaps there should be a setting that disables location update from GPS for such permanent locations already in NV memory so as not to undo a very carefully derived location that was previously uploaded.

On 2020-12-01 9:31 a.m., Dave Schwartz wrote:

As far as when to update in the software, I believe the way OnStep does it is to ignore the GPS port until the PPS signal becomes good (no GPS units start to output the PPS signal until they have achieved a fix). Then read the date, time, latitude and longitude once from the GPS and never again that session.