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.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Blog Comments posted by Gina

  1. Circuit Diagrams :-

    Cooling :-  The Peltier TEC is run continuously on a low level at about 5v to stop the camera overheating in the thermal insulation.  For night viewing, the TEC is run from the full supply of 13.8v switched by a GPIO pin on the RPi.  The J438 P-channel MOSFET is turned on via the EL8217 opto-coupler providing the full supply voltage to the TEC.

    Camera Cooler Control Circuit 01.png

    Dew Heater control :- In this case the dew heater is connected directly to the main supply and the return is switched by an N-channel MOSFET (IRLZ44N) to control it.  Again the power circuits are isolated from the delicate RPi data side with an opto-isolator.

    Dew Heater Circuit 03.png

    • Like 1

  2. I have the new micro SD card in the imaging rig RPi and what I have connected is working.   The focusing seems reasonable with the resolution set to 2 which makes me think I was wrong when I thought I was using 16x microstepping.  The 28BYJ-48 already has a 64:1 gearbox which, allowing for the approx 3x stride angle of a NEMA17, still makes around 20x the resolution of a NEMA17.  Then there is the reduction ratio of 10:1 of the focus gears.  Countering this is that the focussing range of the lens is from a few feet to infinity and we need very precise focussing.

    The full focussing range was previously of the order of several tens of thousands of counts and it needed the focus count to be within around 10 counts to get good focus.  The focus position for Ha used to be around 8000.  Now the range is 12,000 counts with the focus position for Ha at about 4000 counts so a resolution of 5 counts should work for the auto-focus routing.  I was using 20 counts before which was the default as I recall - I think this was a bit course and the reason manual focussing gave better results sometimes.

  3. Those worked, giving status of progress and reducing write time to 15m - a third of previously.  The different make of card could have made a difference though.  Previously Kingston and this time SanDisk.  The SanDisk 16BG cards seem to have  a few more MB of capacity, so Kingston to SanDisk was fine.  Kingston to Kingston was fine too with exactly the same capacity.

  4. Cloned working SD card to SSD and now trying to clone from image to new card.  Using dd.  Trouble is there's no progress bar or any other idea of how far it's got.

    Card to SSD

    gina@Mint-Desktop ~ $ sudo dd if=/dev/sdf of=~/rpi_img_backup.img
    [sudo] password for gina: 
    30244864+0 records in
    30244864+0 records out
    15485370368 bytes (15 GB, 14 GiB) copied, 246.319 s, 62.9 MB/s

    It seems to have worked eventually (over half an hour).  SSD to new card

    Disk /dev/sdf: 14.4 GiB, 15485370368 bytes, 30244864 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x00000000
    Device     Boot Start      End  Sectors  Size Id Type
    /dev/sdf1        8192 30244863 30236672 14.4G  c W95 FAT32 (LBA)
    gina@Mint-Desktop ~ $ sudo dd if=~/rpi_img_backup.img of=/dev/sdf
    30244864+0 records in
    30244864+0 records out
    15485370368 bytes (15 GB, 14 GiB) copied, 2551.79 s, 6.1 MB/s
    gina@Mint-Desktop ~ $ 

    Hmm... writing time was 42.5m - nearly 3/4 hour.  Now to put card in RPi and see if it works.  This is a 16GB card.  Just ordered an 8GB card to create a full system on to use fro cloning as cloning to same size card has proved dodgy in the past - may depend on make as to exactly how many bytes the card contains.  8GB card are dearer than 16GB cards!!

  5. There is a switch to set which type of motor driver module.  MS3 (16x microstepping) is used if the driver board is A4988 which mine is.  When I checked some time ago, Ekos didn't alter the resolution (motor speed) but maybe now it does otherwise I don't think Radek would have added the code.  Speeding up the motor for faster focussing may be advantageous.  OTOH I've found 16x microstepping fine so far.

  6. Checking the default Astroberry GPIO assignments against my current hardware :-

    Astroberry default

    / For BCM2835 use P1_* pin numbers not gpio numbers (!!!)
    #define DIR RPI_BPLUS_GPIO_J8_07	// GPIO4
    #define STEP RPI_BPLUS_GPIO_J8_11	// GPIO17
    #define M1 RPI_BPLUS_GPIO_J8_15		// GPIO22 // M1 // M0
    #define M2 RPI_BPLUS_GPIO_J8_13		// GPIO27 // M2 // M1
    #define M3 RPI_BPLUS_GPIO_J8_18		// GPIO24 // M3 // N/A
    #define SLEEP RPI_BPLUS_GPIO_J8_16	// GPIO23

    My connections:-

    • DIR     GPIO4
    • STEP GPIO17
    • Sleep GPIO23
    • MS1   GPIO22
    • MS2   GPIO27
    • MS3   Gnd

    Only difference is MS3 which currently has a link to Gnd.  Now to see if GPIO24 is actually used in the code.

  7. Thank you @RadekK

    Tried that and got

    gina@img2:~$ git clone https://github.com/rkaczorek/astroberry-diy.git
    fatal: destination path 'astroberry-diy' already exists and is not an empty directory.

    so deleted astroberry-diy and contents and tried again.  git clone seemed to work fine but the second command failed.

    gina@img2:~$ sudo rm -r astroberry-diy
    [sudo] password for gina: 
    gina@img2:~$ ls
     AstroPi3                Desktop           Music      Templates
     bcm2835-1.50            Documents         Pictures  'Terminal 1'
     bcm2835-1.50.tar.gz     Downloads         Public     Videos
     bcm2835-1.50.tar.gz.1   indi-astroberry   snap       wiringpi-latest.deb
    gina@img2:~$ git clone https://github.com/rkaczorek/astroberry-diy.git
    Cloning into 'astroberry-diy'...
    remote: Enumerating objects: 13, done.
    remote: Counting objects: 100% (13/13), done.
    remote: Compressing objects: 100% (11/11), done.
    remote: Total 288 (delta 3), reused 8 (delta 2), pack-reused 275
    Receiving objects: 100% (288/288), 132.38 KiB | 774.00 KiB/s, done.
    Resolving deltas: 100% (162/162), done.
    gina@img2:~$ git checkout 3283e99
    fatal: not a git repository (or any of the parent directories): .git


  8. I wanted to clone the card so put it in my desktop reader.  Listing drives with fdisk couldn't have destroyed the card and it worked in that card reader when I copied data off.  Very odd!!

    Maybe I can purloin the RPi and card from my ASC but this doesn't have the Astroberry Focuser.  Focus on the rig is currently set for Ha (if it hasn't moved).  Possible in desperation, I guess.

  9. I thought just copying the astroberry-diy directory and all its contents from the working card to the new one would work but something was wrong with the bcm2835 library.  Maybe I should just clone the card and leave it at that.  I've found I can change the network name so that I can use both old and new at the same time.  That would give me a second imaging rig.  I'm rather surprised that just copying all the Astroberry files across and recompiling didn't work.  Must be something in the rest of the system - different version of something perhaps.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.