Hello Marcel and good morning.
I have been giving this some thought and here are a few conclusions.
PLEASE allow for the fact that my head is blurred due a night out last night and lack of coffee this morning .
Firstly, there 'should' be no issue in step size for the BYJ stepper - at all !. (without using microstepping)
With the absolutely standard ULN board the stepper has the following spec.
The stepper itself has 32 steps per revolution (about 11 degrees per step which is poor) .. however, internally it is geared by approximately 64:1 meaning that the number of full steps per revolution is around 2040 steps. SO each full step is only moving the shaft about 0.175 degrees !!! , That is REALLY really small steps ! and should
never need microstepping at all.
So, where are the potential issues you are finding with 'jumping' movements or lack of /smoothness ?
Well, imho, it can be any, all or a combination of the following. -
The update rate of the data from the sim that AM sends to the Arduino.
The speed of update of the movement of the Arduino stepper output.
And, of course, this is all tied into the 'frequency' of the stepper HW set in AM.
It does appear that you CAN alter the speed in RPM of the stepper at will within AM ! - (apologies as I was unsure of this and thought you could not)
With 2040 steps per revolution of a STANDARD BYJ stepper, then asking for an RPM of, say, 10 RPM is asking for the arduino to produce 10 X 2040 (20400) steps per minute - or around 400 steps per second ! so around 2mS per step. In that 2mS, the arduino has to process the 4 pin code cycle (per step) for the ULN driver board. That is a hell of lot to ask, even of a mega2560... That is along with whatever else is happening on the arduino.
And of course, how quickly can AM process the updated data from the SIM, and, send it to the arduino, and do all of the other things within the AM code.
Then also, even if the speed and update are ok, then an RPM value - with a slow change of data from the sim - may well cause the needle to jerk in movement as the update is slower than the rpm so each updated position - say - 6 degree every second ( which is equal to rpm of 1), when the RPM is set at 10 (60 degrees per second), will cause quick jumps between updates at 10 times the speed of the required update. Hence it can be working as programmed, but, will cause stuttering and jerky movement.
If the RPM was set to 1 (6 degrees per second) and then the movement was actually required at 60 degrees per second (10rpm) then the needle will be too slow to keep up with a greater rate of movement (delta)
And then conversely if the RPM was set to 10 RPM (60 degrees per second) and the movement required was at 1 degree per second then the needles movement between updates would be too fast - causing jerky stuttering movements.
There needs to be an allowance in the code for the delta(rate of change). Unfortunately, this can only happen AFTER the next update from the sim occurs. This would require the RPM to be constantly altered to cope with different delta.
It may well be possible in AM as the RPM does appear to be able to be changed on the fly.
It would also be an ideal case for PID control - which accelstepper provides. or, careful considerations and continued calculation of the rate of change between updates and setting the RPM to compensate and react accordingly following each update - or indeed, a slight overrun with accelstepper accel / decel etc...
This is a main reason, I think, that you are seeing stuttering or jerky movement I believe, however, loss of 'steps' may well be a comms issue between AM and the Arduino (hence to the stepper) - there is a way to test this I would think by writing specific lUA code in AM to send data to the arduino at varying speeds until (and if) the missing steps are seen)
I definitely recommend grabbing a PICO to rule out any issue with speed of the arduino and then you can, in reality, ignore that side. AM 4 includes support for PICO without MP. Yes, you cant use accel stepper, but, it is immensely faster than the mega etc.
https://siminnovations.com/wiki/index.p ... ry_Pi_Pico
You can DL an image for the PICO here -
https://siminnovations.com/wiki/index.p ... ry_Pi_Pico
using this, you remove any worries about arduino update speed (or should do
)
Hope that helps ? (and makes sense) ?
Joe