openastrotech / openastrotracker Goto Github PK

Need to implement :gT#, :Gg#, and :Gt# as well as status query extensions

Re-create current UI in a real menu system so that we can get out of state-machine hell and easily add new menu behavior.

In the Calculations file in the Arduino code the pins were different than those in Init:
I believe this should be what it reads:

if (DECheat == 1) {
stepperDEC.enableOutputs();
digitalWrite(15, HIGH);
digitalWrite(16, HIGH);
digitalWrite(17, HIGH);
digitalWrite(18, HIGH);

Also when I enter my HA from based on Polaris in in stellarium the declination axis(initial position starting perpendicular to RA axis) goes nearly 180 degrees when I enter my HA and go to the Polaris tab and select it. Thanks in advance!

Stop the DEC from crashing into RA ring on power down.
Store step offset from home in EEPROM.

While it is probably not an issue regarding the print, I noticed that the Lholder stl files are vastly different in file size (15MB (!) vs 500KB) between left and right. Loading the file into Cura took considerably longer for me, otherwise I noticed no difference. Is it just due to different stl export settings?

Probably done over the properties "Slewing", "TargetDeclination" and "TargetRightAscension"

It would be great to use the common 608 bearings instead of the 12mm ID bearings required now. The price and availability are much better.
I modified the stl files myself before printing, but I don't have access to SolidWorks, so I can't contribute updated files. I'd be happy to help otherwise if needed.
Thanks for providing this thing for free!

Hey OpenAstroTech team!

Just recently, a community member of Wikifactory recommended your Project to join our collaboration platform for open hardware - with a community of over 100,000 designers, engineers and hardware innovators working on over 5K hardware and product innovation projects.

I am co-founder of Wikifactory myself and agree that the greater community on Wikifactory and especially our space and astronomy enthusiasts, would not only learn a lot from your project but would like the chance of contributing and building upon your amazing work.

As a social platform for collaborative product development, we definitely were inspired tools like Github and we focused on building a collaboration infrastructure built for product design from the ground up.

A few months ago, we launched an Import from Github feature to make it very easy to bring projects that already exist on Github into Wikifactory in just a few minutes.

I went ahead and imported your project to see how it would look, and whilst it is not listed for the broader community - I have the chance to show you how it would result! Take a look! https://wikifactory.com/@botler/the-openastrotracker

I would love your feedback. My hopes is that we could transfer the project to you so that it can be listed on our Platform for our community to find and engage with.

We have built Wikifactory for projects like yours, so I would definitely care to know what you think and I would even suggest that we show you around in a Demo too!

At the heart of this message is that I would hope to be able to see your project evolve and grow with our community.

STEP and Solidworks files for 02_angle_30deg are missing

In my experience, the M14_mount_rear_2020base_v2-part does not fasten completely in its current design.
It will shift vertically depending on pressure, rotating around the M4-screws.

Possible improvements:

1. Add the raised middle "band" that fits into the alu-profile.
2. Two M4 screws on each side, instead of just one.

Both of these design choices already are in the other 2020base-parts and stops them from rotating in relation to the alu-profile.
Example: M14_mount_right_2020base and M14_mount_left_2020base.

I cannot find information about how to contribute changes to the 3D parts to make these changes.
I can just assume a PR should include changes to the Solidworks,.step and .stl-files and I will try to make these changes if no one else beats me to it.

Closing issue due to opening a PR instead. Easier to discuss there.

When a Sync is issued from an ASCOM client the RA is not getting synced correctly.

Observed:

1. Sync RA/Dec Values
2. Dec value returned from device is correct
3. RA value is "seemingly random" but certainly not the passed in value for the sync
4. Sync RA/Dec values again
5. Dec is still correct
6. RA reverts to the pre-sync RA (basically seems to return to the value prior to the initial sync)

Sending subsequent syncs to the same RA/Dec will bounce the RA between the "pre sync RA" and the RA from 3 above.

Expected:
-Sync RA/Dec values
-RA/Dec values returned are the same or very close to synced values

Logs:
Sync multiple syncs to same coordinates starts here:
12:13:13.541 SyncToCoordinates RA 4.31251321778479, Dec 57.9046880388334

ASCOM.OpenAstroTracker.LocalServer.1212.135460.txt

I did some googling to find parts here in Brazil and I think it can help other Brazilians. Maybe you could include a column for each country so people can discover if this project is feasible easier and we can share cheaper prices!

New Shopping list

I just wanted to report an issue I ran into getting my new OAT build up and running. With the electronics hooked up and the latest firmware loaded, some of my buttons were misbehaving. Both the Left and Select buttons were acting like Select and the Down button was acting like Left.

I was able to enable LCD_BUTTON_TEST in Globals.hpp to see the output of my buttons and then change the cutoff values accordingly in the checkKey () part of Utility.hpp. I changed the cutoffs to 50/300/500/700/950. Now the buttons respond correctly.

For the record, I am using firmware 1.7.04 with a Mega 2560 clone (Sunfounder) and the DFRobot LCD Kaypad Shield v1.1. They key diagnostic is reporting: 0-Right, 205-Up, 405-Down, 623-Left, 824-Select, and 1023-None.

Looking forward to clear skies so I can try it out soon!

As you might gather from my previous issue I've been printing the parts for the base, and I've used the OAT Part chooser v1.5.1 to select the parts to be printed. I've chosen the option for threaded inserts, but after printing the base I notice only the holes that mount the 14_RAmotor_mount_NEMA_down bracket on the left and right rollmounts have the right dimensions for the inserts. The 4 holes to mount the rollmounts to the base all have non-TI dimension, and so does the hole on the bottom of the 02_angle_2020base part, which doesn't even have a TI version.

I haven't printed any of the moving assembly yet, but I'm wondering why not all places where bolts thread into plastic have been changed?

I have found that for lower latitude version (20deg) of the OAT, the RA motor physically clashes with the MKS bottom mounted case.
As of now I only know of 20deg version(since I printed this one).
I have created another bottom mounted MKS case which is mounted to the rear of case that solves this problem.
I would suggest if there could be a heads up for people printing the bottom mounted MKS case that it is not physically compatible with lower latitude versions of the OAT.

This should be Serial2?

My DEC motor doesnt work properly if this is set to Serial3.

The STEP Files seem completely up to date, but the SolidWorks files are behind a version in certain cases. I noticed specifically that the rollmount v3 is available in SLDPRT format, but not rollmount v4. I only ask because I am making my own revisions, the STEP files work just fine, it is just nice to have the history tree available to edit when working directly in SolidWorks. Awesome project, thanks for staying open source.

This repo doesn't seem to have the SCAD files mentioned in the readme. I do see that they're on Thingiverse. Should they be added here?

If Digitial Level is installed allow calibration and visualization of level

I've designed my own M14 bolt in Fusion 360 to use with the OAT, but after printing without any added clearance it fits very loosely in the M14 threaded holes of the OAT and wobbles around. I've used ISO Metric Profile M14x2 when creating my bolt, does the model use a different profile?

Update: I've overlayed the STL on my bolt in Fusion and the profile seems to be the same. There does seem to be a massive 0.4mm clearance on each side, or 0.8mm in total. Is this intentional?

I have been using v1.5.1 to collect all the printed parts required for my configuration and the part chooser is pointing to .rar files that dont seem to exist anymore (unless im doing something wrong?). It makes much more sense to have all of the files collected into a single download but the part chooser looks like it could do with updating.

What i lack in coding abilities, I could probably make up for with my spreadsheet nerdary and potentially update and make it a little more user friendly for future contributers/users to access the files.

From Indilib driver (https://github.com/indilib/indi/blob/master/drivers/telescope/lx200driver.cpp#L1020)
// Meade defines longitude as 0 to 360 WESTWARD
int setSiteLongitude(int fd, double Long)

So the driver sends 10°44E as :Sg349:16# which will be interpreted from OAT as 10°44W ...

My suggested fix is to negate the dt.getTotalSeconds():

`Longitude Longitude::ParseFromMeade(String s)
{
Longitude result(0.0);
LOGV2(DEBUG_GENERAL, F("Longitude.Parse(%s)"), s.c_str());

// Use the DayTime code to parse it.
DayTime dt = DayTime::ParseFromMeade(s);

result.totalSeconds = 0 - dt.getTotalSeconds();
result.checkHours();

LOGV4(DEBUG_GENERAL, F("Longitude.Parse(%s) -> %s = %ls"), s.c_str(), result.ToString(), result.getTotalSeconds());
return result;
}`

I've ordered the bubble level straight through the Aliexpress link on the shopping list page (https://wiki.openastrotech.com/en/OpenAstroTracker/ShoppingList) and now that I've printed the holder I find out that the holder is made for a bubble level with a diameter of 65mm. The shopping list itself still lists the 65mm version but maybe the listing itself changed? I'll probably hot glue it in for now as the level can be stuck through the smaller hole but won't stay in place.

Could someone make an updated model for the 60mm version, as I can assume more people have bought this version?

Current line 8 is
onehour = (float(RAsteps / 288)) * RevSteps;

Which leave RASteps as an int (this produces /u/mxpwr60's comment that 288 is the "lower limit" as seen here, since dividing any int < 288 by 288 returns 0.

It also results in the RA Rate being impossible to set as described in the setup/calibration instructions, since only RASteps values that are multiples of 288 (288, 576, etc) will produce any change in the value of onehour.

I believe code should be
onehour = (float(RAsteps) / 288) * RevSteps;

Have made this change in my mount, and see RA calibration results as expected.

Reddit post: https://www.reddit.com/r/OpenAstroTech/comments/icf009/compiling_errors_in_arduino_ide/

Compiling version 1.8.12 under Ubuntu Linux causes errors due to Linux discriminating against upper and lower case in the include statements. Apparently Windows doesn't care if the file is named "Configuration_pins.hpp" or "configuration_pins.hpp", but Linux does.

I'll be submitting a pull request for this issue shortly.

**Apparently I've forgotten how to run git, so I won't be submitting a pull request. Regardless, here are the files that I updated to make this compile on Ubuntu:

a_inits.hpp: Line 5, #include "Configuration_pins.hpp"
c72_menuHA.hpp: Line 3, #include "Configuration_adv.hpp"
c72_menuHA.hpp: Line 4, #include "Configuration_adv.hpp"
Line 5, #include "Configuration_pins.hpp"

With those changes I was able to compile just fine under Ubuntu Linux.

Hi
Could you probably post some assembly instructions or some close-up Photos of your assembled OpenAstroTracker to make assembly easier?

Thanks
Matthias

I've downloaded the latest release and extracted OATcontrol. When I try to run OATControl.exe, it crashes instantly; no error message, no error report, etc. I attached Visual Studio to the .exe and got a bit more information. It seems to be a registry access permission denied. Here is the stack trace:

 at ASCOM.Utilities.RegistryAccess.OpenSubKey(RegistryKey ParentKey, String SubKeyName, Boolean Writeable, RegWow64Options Options)\r\n   at ASCOM.Utilities.RegistryAccess.NewCode(Boolean p_IgnoreChecks)

And the accompanying message is:

OpenSubKey: Exception encountered opening key - Result: 0x5

I can probably build from source but I thought it important to point out that the release is crashing for me.

Navigating to POI M42 Orion nebula moves OAT to DEC 90°22' instead of -5°22'. It seems that in struct PointOfInterest using "byte degreeDEC;" is problematic since byte is unsigned. Using int degreeDEC solved this for me

nice project though. I made a slight modification to use A4988 stepper drivers with microstepping to see if it is possible to have smoother tracking. Just waiting for a clear sky now :)

I encountered a frustrating issue when trying to print 04_rollmount left_30°_v6_2020base_TI.STL where Klipper would crash with an SD card error message when attempting to print. I chased the issue for a while before I discovered it was the ° symbol in the filename that was causing Klipper to crash (Unicode character issue?). Once I replaced that symbol with deg, like most of the other file names, I was able to print successfully. There is also a space in the filename that should be replaced with an underscore _ to keep naming consistent and eliminate the need to escape the filename in Linux.

I believe all files that contain the ° symbol in the name should be changed to deg along with replacing the spaces with underscores _.

I can go into greater detail with my printer hardware and configuration and perform more thorough testing (once my printer is freed up) if needed, but wanted to document this asap in case someone else happened to be having the same issue.

Continue development of phone app to allow more functions.

The left button does not switch throught the menues.
It has the same effect as the down button.
Sometimes the left button switches the menue.

Should be possible, but some parts need modification

Allow the ESP32 to be used with ASCOM without a cable.

V1.6. not compiling properly. Errors are located in "d-calulation" and "f-printout" files.
I have no issues with v1.4.5 ...

Am I doing something wrong ?!

Hello,
first of all - thanks for that great project !
I'm still printing parts and found 2 issues

1. \OpenAstroTracker-master\CAD\STEP\03_polemount_6801_v2.step - this part has 0,5 mm bottom instad of around 5 mm. Easy to fix just need to extrude the bottom to correct hight.
   

2.\OpenAstroTracker-master\CAD\STEP\11a_splitring_part1_v4.step
\OpenAstroTracker-master\CAD\STEP\11b_splitring_part2_v4.step
\OpenAstroTracker-master\CAD\STEP\11b_splitring_part2_timingbelt.step
This is more complicated. 2 Holes are missaligned (on the outer parts) and there is a problem with the perimeter around the joint. A picture is worth 1000 words.

because

a) DEC stepper not precise enough. Could be improved by half-stepping

b) Declination axis unbalanced with guidescope attached. Could be solved by adding counterweights

Optionally allow the mount to enforce slew limits. User would manually slew to RA and DEC limits and confirm.
Tracking offset is added to RA to check position

Need this for manual control (and maybe homing through ASCOM?)

Add some LX200 extensions to allow query of Digital Level data