Took working SD card out of my WF imaging rig and put it in the card reader, ran sudo fdisk -l for a list of drives but the card showed as only 30MB.  One of the new ones showed 14GB.  Very strange!!

Put card back in imaging rig and powered up.  "Huston - we have a problem!!"  RPi didn't boot and no green LED for disk activity.  Seems the card is dead!!!  DRAT.  Can't see anything that could have destroyed the card!  Now I have NO IMAGING RIG!! 

I've just done the same with mine but ran it by ssh'ing into the pi itself

it returned a lot of drives but it is 128GB card

astroberry@astroberry:~ $ sudo fdisk -l
[sudo] password for astroberry: 
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mmcblk0: 119.3 GiB, 128043712512 bytes, 250085376 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: 0xd9b3f436

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 250085375 249552896  119G 83 Linux

Disk /dev/zram0: 64 MiB, 67108864 bytes, 16384 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/zram1: 64 MiB, 67108864 bytes, 16384 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/zram2: 64 MiB, 67108864 bytes, 16384 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/zram3: 64 MiB, 67108864 bytes, 16384 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
astroberry@astroberry:~ $ 

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.

OTOH without focuser I could just use the card that's in the img2 RPi.  With dew heater on all the time I don't need the Astroberry Board driver.  But for any sensible imaging I really need remote focussing!!

Run the following to grab the version with BCM support:

git clone https://github.com/rkaczorek/astroberry-diy.git
git checkout 3283e99

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
gina@img2:~$ 

Change into the astroberry-diy directory before running the second command?

James

I'll try that - thanks.

WOW!!  Thank you James - that worked.  Next to check with Ekos...

Both Astroberry Focuser and Board are showing in the INDI Control Panel.  Next to check the GPIO connections and make sure the hardware matches the drivers.

Thanks to @RadekK and @JamesF - it seems I'm back in action

Good news

James

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.

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.

From the C++ code I could see that the stepper driver type was a switch in the Options tab and this confirms it.

I also see that the resolution (microstepping) now has a setting here.

I might as well implement all available settings that Radek has provided including changing focuser resolution, particularly as this same hardware will be used on telescopes as well as lenses.  The very fine focussing I use with the lenses may not be needed for telescopes where I use the 28BYJ-48 geared stepper motor with the fine focus knob.

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!!

The clone works.

One point though...  The resolution is limited to full steps or half steps.  For my lenses I want 16x microstepping so will have to patch the code.

No problem - changed from 2 to 5 in file rpi_focus.cpp in astroberry-diy directory.

 Maximum resolution switch
 1 - 1/1
 2 - 1/2
 3 - 1/4
 4 - 1/8
 5 - 1/16
 6 - 1/32
 Note that values 3 - 6 do not always work. Set to 2 by default
*/
#define MAX_RESOLUTION 5

Hmm... seems to be more to it than that.  Set to 5 but the Options tab still only allows 2.  I'll look into it tomorrow.  If I have a problem sorting it out I'll just preset the microstepping to 16x.  That will work whichever imaging system I use - just might be a bit slow on some.

3 hours ago, Gina said:

Trouble is there's no progress bar or any other idea of how far it's got

Add status=progress when using dd 😉

3 hours ago, Gina said:

Hmm... writing time was 42.5m - nearly 3/4 hour

Add bs=8M when using dd 😉

bs it stands for block size - it will significantly shorten the time

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.

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.