I've played around with the Ustepper-S now, and as near as I can tell, it is working correctly in closed-loop mode without issue. After the execution of each command, it shows error of 0.00, and it maintains closed loop operation to maintain its position even after the execution of the command, as it should. In my testing, Servo42A fails to do that, as well as having other problems, including lack of response to posted github issues.
Ustepper-S incorporates PID, so it should be able to do rapids and yet stop exactly where it should. Again, my initial impression is that seems to be the case.
I'm ordering UStepper-S for the x and y axis as well, which unfortunately will again take weeks to receive. However, I expect this will be the last stepper driver upgrade that I will ever need to do. If I later decide to upgrade to NEMA-23, the same UStepper-S can be used to drive it and only a different bracket would be needed to position it on the back of the NEMA-23.
As promised, what I found so far: the following dockerfile yeilds a usable cross-compile environment, provided you use it with a Makefile.
RUN apt-get update \
&& apt-get install --yes \
RUN git clone https://github.com/raspberrypi/tools
RUN git clone https://gist.github.com/3873805.git /build
CMD ["/usr/bin/make", "CC=/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc"
# Seems I need a real makefile for the above to work.
For cross compiling mysensors to work, hoever, you also need to properly seed the variable in configure, for it to work correctly. This is where I left off.
@172pilot said in Good thing mysensors has non-repeatable encryption....:
@NeverDie Is a signing chip really necessary?
If the packets are truly encrypted, and the hack you're trying to foil is a simple replay attack, I would think that including a simple incrementing counter into the message would do it. All the receiver would have to do is to only accept decrypted messages with a counter number GREATER than the last one it received. This should be simple to do if the encryption/decryption is already considered relatively secure?
I think the answer is probably yes. Today. At this moment. At least for me and probably you. I mean, one could reasonably ask: why bother with having better security than my garage door opener? But as cracker tools become more prevalent, who knows what's coming next? It's not just us against juveniles and thugs, it's us against whatever weapons juveniles or thugs can download or buy ready-to-use from kickstarter (or aliexpress for cheap soon thereafter).