Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

  • Announcements

    SGL 2017 SP

rpineau

Advanced Members
  • Content count

    62
  • Joined

  • Last visited

Community Reputation

23 Excellent

About rpineau

  • Rank
    Nebula

Contact Methods

  • Website URL
    http://www.rti-zone.org/astro.php

Profile Information

  • Gender
    Male
  • Location
    USA - CA
  1. Open source X2 plugins for TheSkyX

    I've posted a few recent update to some plugin : - MaxDome II : I fixed the calibration and Sync. I now have a MaxDome II card for testing so this is a lot easier to debug (I'll have to return it at some point to the nice person lending it to me). - NexDome : I fixed a few bugs and also fixed a few issues that showed up with the new NexDome firmware (1.10). Latter I'll add a few things to the settings dialog for the few new commands of the new firmware. Rodolphe
  2. Arduino Help - convert to hex

    char buffer[10]; snprintf(buffer, 10, "C: %02X#", tempC); Serial.println(buffer);
  3. The NexDome code on the Arduino only does what you would call slaving, AKA it expect a GOTO command from the computer to move to a specific position and then stops. So the software sends position update (slaved to the mount/telescope) to the controller to keep the slit aligned with the telescope. Most dome control system work like this and wait for position update command to move and do not move by themselves. As you said, the difficulty on constant tracking is getting the speed right. Rodolphe
  4. Feel free to ask questions. Based on your picture above you already have a stepper controller with a big stepper. The NexDome system uses an Arduino Leonardo to drive the stepper controller via ASCOM (or a native X2 plugin if you're using TheSkyX Pro). I wrote the X2 plugin for TheSkyX Pro and built a test rig with the code from the link above to test the plugin. This has been used by a few people directly with the original NexDome but also with their own dome just using the original code of the NexDome controller and a stepper controller (the one you have is fine and will work). I can go in more detail if you want . The advantages, all open source and all open hardware Rodolphe
  5. As you're already using a stepper motor you might want to look at the NexDome sketch and ASCOM driver : https://github.com/grozzie2/NexDome You might need to change a few values in the sketch to match your gearing. You can then control it via anything that can talk ASCOM and control a dome. Rodolphe
  6. 2017 Eclipse from Oregon

    thanks guys.
  7. 2017 Eclipse from Oregon

    I was lucky to have family not far from the path of totality. So we drove for about an hour north from their place to Corvallis and I was able to see my first total solar eclipse. I followed advices from here and other forum to not take a telescope but just a camera an not worry to much about taking picture and just enjoy. Best advice EVER !!! I set some sequence on my canon remote, press the button and walked away from it And yea .. ECLIPSE !!! WOW ... speechless. Bonus.. I got some picture : https://rti-zone.org/astro_eclipse_2017.php I even manage to do a small animation : https://rti-zone.org/files/animation.gif Rodolphe
  8. I've written a bunch of X2 plugin for various devices for TheSkyX. Some people might be interested so I though I'll drop a note here. I usually make them cross platform when possible (which has been the case so far for all of them) so they work on OS X, Windows, Ubuntu and Raspberry Pi : https://rti-zone.org/macosx_x2filterwheel_plugins.php https://rti-zone.org/macosx_x2dome_plugins.php https://rti-zone.org/macosx_x2mount_plugins.php https://rti-zone.org/macosx_x2focuser_plugins.php I hope someone finds these useful. Regards, Rodolphe
  9. Arduino Ascom focuser Mark2

    I just wanted to let people know that I wrote a focuser X2 plugin for TheSkyX (OS X, Windows, Ubuntu and RPI are supported) for the AAF2. If you're interested you can find it there : https://rti-zone.org/macosx_x2focuser_plugins.php Regards, Rodolphe
  10. Hi Marco. Yea , I forgot about the actual wire protocol. You're right .. 16 bit vs 8 in the usb data packet, even if they do usb bulk transfer async it's still twice as much data so half the speed makes sense. I plan on running more test on the Sun this weekend so I'm capturing at full resolution. I did some ROI test on my dsck and of course the FPS goes a lot higher which will be good for planetary Regards, Rodolphe
  11. Hi Marco. I agree with you about the announced speed... marketing fluff ?... that being said the AD converts 8 or 12 bit. in 12 bit mode it then expands it to 16 bits (left shift by 4 bits and nothing else so this takes no time). so the ratio of 12 to 8 gives almost the 128 FPS they announce for 12 bits... or it is indeed exactly half the speed because the 12 bit AD conversion does take twice as much time independently of the rest of the capture. Not sure either but I've seen the same thing in other apps, not just yours so I'm fairly sure it's not something in the code. It might very well be in their SDK and there is not a lot you can do about this. But I'm already pleased with a 130FPS or 66FPS. Thanks for the great work. Regards, Rodolphe
  12. Hi GuLinux I recompiled the latest v0.7 after updating my QT5 to 5.6.2 and also using the git version of libusb on OS X. Thing seem to have improved and it's also a lot more stable. I can get about 130 FPS in 8bit mode full res on the 174MC and 66 FPS in "16 RAW". So not yet the advertised speed from ZWO (174 FPS in 8 bit mode and 128 FPS in 12 bit (scales on 16 bit)) but that is already a lot better. I also saw that your repo has a v0.8, besides the scripting any significant differences ? Thanks Rodolphe
  13. I don't mean static Qt, just the other lib like libusb, boost and cfitsio... You can still have the Qt lib (or Frameworks on OS X) as Dynamic libs. I wouldn't want the Qt as static either and you can add the dynamic one (the framework) in the OS X app as shown in the link from the Qt doc. Having the other libs as static would allow a use to not have 'brew' or 'mac ports' installed to be able to launch the app. Here is the otool output for my compiled version (otool -L <exec file> gives you the same thing as ldd on linux) : /opt/local/bin/planetary_imager: /opt/local/lib/libopencv_shape.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_stitching.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_superres.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_videostab.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libCCfits.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libcfitsio.dylib (compatibility version 5.0.0, current version 5.3.39) /usr/local/QT5/5.6/clang_64/lib/QtOpenGL.framework/Versions/5/QtOpenGL (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /opt/local/lib/libopencv_objdetect.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_calib3d.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_features2d.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_flann.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_highgui.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_ml.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_photo.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_video.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_videoio.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_imgcodecs.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_imgproc.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_core.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /usr/local/QT5/5.6/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0) /usr/local/QT5/5.6/clang_64/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0) /usr/local/QT5/5.6/clang_64/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) As you see I had to chabge the @rpath for the Qt lib to point to my locally installed version (which is not the one from brew or mac ports). I built it with : cmake .. -DCMAKE_PREFIX_PATH=/opt/local/ -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_PREFIX_PATH=/usr/local/QT5/5.6/clang_64/lib/cmake/ -DQt5Widgets_DIR=/usr/local/QT5/5.6/clang_64/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake Then I used the install_name_tool command to change the rpath : sudo install_name_tool -change @rpath/QtOpenGL.framework/Versions/5/QtOpenGL /usr/local/QT5/5.6/clang_64/lib/QtOpenGL.framework/Versions/5/QtOpenGL planetary_imager as I don't have my Qt libs in my LD_LIBRARY_PATH environment variable (DYLD_LIBRARY_PATH on OSX). I'm not asking for these changes, just making suggestion so that OS X user can have a binary that doesn't require a full brew or mac port install with qt5 in it. In any case, I still appreciate your work and effort on this and will do my best to help you on the OS X side of things. Regards, Rodolphe
  14. Yep, cross-compiling for OS X is not the easiest thing :). One thing would be for some low level libs to link in the static lib instead of the dynamic ones (libusb, boost, ...). for the Qt frameworks there is a nice document about it : http://doc.qt.io/qt-5/osx-deployment.html They explain how to add the framework to the app so that the user doesn't need a full Qt install. Regards, Rodolphe
  15. I can try that (compiling is no issue for me). Right now the mac port version I have is 1.0.21_0 So I'll try with the latest git head. I probably won't have time to test before tomorrow. I'm testing on a Macbook Pro Mid-2015 with USB3 port (The ASI 174 MC is USB3), so these issues are probably only software related. Regards, Rodolphe
×