Hello,
I’ve finished building the controller (V2.0 with plug-in fuse) but the steppers doesn’t move at all.
When powering the board, they locks-up, and then that’s it.
Any ideas on how to debug this ?
I use “-m 204 -s 19200 -r /dev/ttyUSB0 -C timeout=200” for HAMLIB_UTILS_ROT_OPTS.
I tried from my laptop to use rotctl and the move position but no results too.
Here is pictures of the board right now:
I’m assuming you flashed the firmware onto the arduino. From your pics, looks like you’re going the UART/RS232 route (Not the RS485 route)
Hook up your laptop directly up to the pro mini and open the serial monitor
Send the following:
AZ10 EL10
That should move 10 degrees on each motor
Then issue a RESET, that should try to re-home if you want to test your endstops (manually pushing them)
if you’re trying to access it from raspberry, use this command:
rotctl -m 204 -s 19200 -r /dev/ttyUSB0 -C timeout=200 -vvvvv might be /dev/ttyUSB1 depending on what it’s showing up in the raspberry.
then issue
P 10 10
That will move 10 degrees each motor
believe
p
re-homes
also, looks like one of your motors is wired wrong. I had mine wired like yours and my AZ was backwards, I couldnt figure out how to flip it in the firmware, so just did it via wiring.
Should be opposite mirror of the EL motor
So example: (Not sure which one is which on your pic, but you should just reverse mirror the EL motor)
black, green, blue, red - red, blue, green, black
Also, check rotator_pins.h file, I’ve seen a lot of mixups. and what not. Here is the one I’m using (I believe) rotator_pins.h.txt (585 Bytes)
See attachment.
I also see that you have the 0 ohm resistors (jumpers) set on JP1 - JP6. This will select for 1/16th microstepping and has a conflict with the current firmware.
See How to set up microstepping (#14) · Issues · librespacefoundation / SatNOGS / satnogs-rotator-firmware · GitLab and How to set up microstepping on satnogs-rotator-controller v2.2
I have set some lines in satnogs-rotator-firmware\stepper_motor_controller\rotator_config.h like this to use 1/16th microstepping:
#define MAX_SPEED 6400 #define MAX_ACCELERATION 2400 #define SPR 3200L /*Steps Per Revolution*/
I didn’t understood very well at all the wiki page about the microstepping part so I might have messed this part.
I will try with this patch to see if it’s better thanks !
Changing the three parameters didn’t changed anything.
I removed the three zero-ohm jumpers and flashed back the unmodified firmware.
@ka4jwb using screen or rotctl didn’t do anything, also edited “libraries/rotator_pins.h” but nothing better
rotctl produced this output:
Rotator command: P 10 10
rotctl_parse: input_line: P 10 10
easycomm_rot_set_position called: 10.000000 10.000000
easycomm_transaction called: AZ10.0 EL10.0 UP000 XXX DN000 XXX
write_block(): TX 34 bytes
0000 41 5a 31 30 2e 30 20 45 4c 31 30 2e 30 20 55 50 AZ10.0 EL10.0 UP
0010 30 30 30 20 58 58 58 20 44 4e 30 30 30 20 58 58 000 XXX DN000 XX
0020 58 0a X.
Rotator command: p
rotctl_parse: input_line: p
easycomm_rot_get_position called
easycomm_transaction called: AZ EL
write_block(): TX 7 bytes
0000 41 5a 20 45 4c 20 0a AZ EL .
read_string(): RX 7 characters
0000 41 5a 20 45 4c 20 0a AZ EL .
easycomm_transaction read_string: AZ EL
easycomm_rot_get_position got response: AZ EL
easycomm_rot_get_position: unknown response (AZ EL
)
get_pos: error = Command rejected by the rig
Rotator command:After two or three reflash, I think I’m using @ka4jwb pinout, which seems to have the sensors behaving correctly (does nothing with stock firmware IIRC)
When powering the board and if the sensor is not blocked, the motor starts spinning in one direction (then stops but noise continue) and then goes the other direction and stops.
P 10 10 in rotctl still does nothing
What noise are you referring to? The hum of the motors? Could be because you’re using microsteps, I use full steps (no jumpers) There will be a small noise coming from the motors because it is engaged (so they wont move)
Might also check your motor controller voltage. (VREF) and make sure you’re not over powering you motors. Think I have mine set at 1.5 amps (which for my motors is .625V reading off the A4988 Chip)
Also Word of advice, TWIST AND SHIELD YOUR MOTOR CABLES! Otherwise you will pick up a ton of noise on the SDR. If I ever tear mine down, I will probably un-solder wire that comes with it and re-solder with shielded cat6 or something similar. Right now, I just twisted my wires and wrapped some of the foil out of a cat6 cable over top.
So you’re saying you can make the motors move using serial monitor connected directly to the arduino chip? If so, then sounds like something between raspberry and board.
Unplug and plug up the USB/TTL Adapter from the raspberry, run this command
sudo dmesg
This will show you the hardware log and let you know what USB port you’re using.
Here is a video about the startup of the motors : https://www.youtube.com/watch?v=LvCJW5W2VFg
EDIT: I already have removed yesterday the 6 jumpers on the back so I shouldn’t be using microstepping anymore
Also the motors doesn’t seems “locked”, I can freely move the shafts.
VREF is ~.524 si it shouldn’t over-power right now.
I will twist and shield the cables when putting it in the final usage, right now I need the thing to works.
I’m connecting from my laptop to the FTDI adapter, and there is only one serial adaptor so ttyUSB0 is right,
When using a serial terminal (19200 bauds) all I get is an echo of what is typed.
I’m starting to think that there is a big mismatch between the expected pinout of the firmware and reality.
You try reversing TX and RX pins?
Also, how did you flash your firmware? Via the INO file or did you compile / make via linux? Do you get any compile errors?
If you’re using the makefile method, you need to add:
AVRDUDE_ARD_BAUDRATE = 57600
To your makefile
Also, as far as your video, my motors don’t do that when I boot up but I’m also running an older firmware. There may be a auto home or something in the controller firmware now on startup that wasn’t in my version.
Reversing the pins had no effect.
I’m flashing using the make command, and I also have the good AVRDUDE_ARD_BAUDRATE, no error on flashing.
I will compare the kicad schematic of the v2.0 and the pinout file to see if there is something looking weird.
EDIT: schematics looks like the same as yours rotator_pins.h (which is not the same as the current one from repository)
You might try asking in the freenode channel. The main guys are from Greece so they should be popping in there about now.
made a bit of progress.
I ended up reading the code and discovered the controller can talk a bit more !
I flashed a “hello world serial” onto the board to make sure it is working, and yup.
then reflashed with right pinout, and if I connect to the board with serial monitor (line ending = newline) and send “VE” I get in the console “VESatNOGS-v2.2” (the VE here is probably local echo I guess).
I finally slapped everything with dual-face scotch and quick tie wrap, so both motors and rotary encoders are wired.
Nothing really better, “AZ10 EL10” don’t move anything, the motors just do a little dance at startup.
When sending a “GE” (Get error register) it returns “GE4”, 4 is “homing sensor”.
IP0 returns “IP0,0” but I don’t think the temp chip may be related to my issues.
Hey!
Take a look at this issue.
Also have you change the #define SPR, Step Per Revolution, according to your stepper motor step/deg and microstepping.
hi @azisi
Yes I’ve seen it but I have removed all the 6 jumpers so I shouldn’t have any microstepping setting to do, right ?
So you if your step angle is 1.8deg (take a look at your stepper motor specs) the
definition of SPR must be 200. I add an example in wiki.
Thanks that’s perfect !
I’ve choosen:
#define MAX_SPEED 800
#define MAX_ACCELERATION 200
#define SPR 200
Reflashed, and after a couple of reset, the rotator finally homed itself.
I can issue AZ an EL commands and also RESET and it seems to works.
The gears are noisy but it works !
Thanks all and I think it’s solved, I will add a bit about troubleshooting of the controller in the wiki.
This happens due to software limits in homing function,
#define MIN_M1_ANGLE 0 ///< Minimum angle of azimuth
#define MAX_M1_ANGLE 360 ///< Maximum angle of azimuth
#define MIN_M2_ANGLE 0 ///< Minimum angle of elevation
#define MAX_M2_ANGLE 180 ///< Maximum angle of elevation
Also you can reset the controller by sending RB command in serial.
Take a look in easycomm implementaion.
It would be nice to upload pictures of your build. 
I’ve seen the easycomm readme that’s where I took some commands for status and error register.
I have added a bit of troubleshoot infos (status/error register, etc.) here: https://wiki.satnogs.org/SatNOGS_Rotator_Controller#Troubleshooting_hints
Which I hope might be useful without spending too much time digging for informations 
Yes I will definitely upload pictures !
But for now, I have to look on re-aligning a bit the AZ gears, and finalizing everything.
Glad you got it fixed! Please post any firmware changes you made like if the pins config was wrong etc.
The pin configuration (rotator_pins.h) is referred to a not released board. The master branch of rotator firmware is referred to released board v2.2. That is the reason
of different pin configuration. 