JRK distance between controller and motor

Hi Folks

I’m replacing an old, analogue focus, zoom, pan and tilt head system to operate fairly large cameras and I’m loving the JRK for it’s size and versatility.

However, this is on a bench. In real life it will mostly operate a camera 6m (20ft) from the operator but occasionally needs to operate 30m (90ft).

This presents me with two options. 1) Keep the controllers close to me so I can programme it easily but have a long run of cable to the motor with an equally long run back for the analog feedback. 2) Have the controllers near the motors, be unable to program on the fly and have long runs of analog control.

Are there any issues with long cables and PWM?

It seems the ideal situation is to cut the JRK in two and have the input half, with its joystick calibration, 12 bit input and other benefits close to me, and the output half near to the motors!!

Can anyone with more experience than me cast a fresh mind on my dilemma. Incidentally, I would dearly love to make this into a radio system later, but for now…

Many thanks for reading.



I recommend keeping the jrk close to power and the motors. Long leads on motors can make motor noise be a bigger problem, and your motors will get less power. You can try having long wires for the input potentiometer, but that is probably not ideal.



If you’re planning on eventually bringing radio into the picture, you might consider trying out our new Wixels. I think they would work very well for what you’re trying to do assuming you are comfortable setting the position with serial commands rather than an analog voltage directly.

- Ben

Thanks David and Ben for your replies, I’ll put the controllers at the far end.

So, for now I’ll run 5v from each controller, common ground and take the wiper reading back to the controller. That’ll make 4 long 5v lines and 4 long analogue input wires. Is there a better way of doing this? If I used a common 5v, I assume each variable resistor would interfere with the others? Also, what can I do to make my system fail-safe if I lose any wires to the controllers? Ah, there’s something in the program on that, so I’ll experiment in a moment.

Now, the next step is to go full serial. Should I consider this immediately to avoid the multi-wires or take it all step by step? If you suggest serial immediately, then I’ll need some knowledge from elsewhere, whether it’s a long wire or wireless. I’m sure there other areas on the forum where people have done this, I just don’t know where to start looking.

Sounds like two threads really!!

Any thoughts?

Thanks again


So you have 4 jrks? If the GNDs of all the jrks are connected, then you could get by with 6 wires: GND from one jrk, +5V from one jrk, and then 4 wiper wires from your 4 potentiometers.

But it sounds like you want to use the disconnect detection feature of the jrk so you can detect when the input potentiometer is disconnected. In that case, you would need more wires, because each input potentiometer must be powered from the AUX line of the jrk that it is providing input for. So you would need 4 wires for the AUX lines from each jrk, but you still only need one GND line.

If you’re looking to do serial communication at 90 feet, you might want to look for some RS-485 transceivers.


Hi David

Many thanks for your reply.

Yes, I’ve considered powering them all from one 5v feed but there are one or two issues that spring to mind.

First, if I start ganging pots together, doesn’t that effect their resistance? I don’t mean the parallel effect, which is probably true, but the effect each change will have on the reading of the others, or am I being paranoid again?

Second, and talking of paranoia, safety is the number one issue here. Ok, a rogue pan and tilt camera isn’t going to kill someone, but if it goes out of control, it messes up a few expensive cables, ruins the shot and has an adverse effect on my career.

For the record: I’m not going to involve Pololu in any of my design failures. If I can’t make it work, it’s my fault.

Is there a simple way of hitting the PANIC button to stop everything? Maybe reset would work, but can I daisy-chain that. Another wire, possibly!!

Thanks for your advice about RS485. You are right and I need to learn about this as well.

Yes, this is the way to go for cable and I’ll use this. As you’ve probably gathered, I’m trying to reduce this, safely, to one or two wires and then go wireless.

Oh dear, I’m just a cameraman with a small amount of technical knowledge!!

Nasdrave, as we say in Bulgaria!!


Now that I think about it a little more, I think that if all the potentiometers are fed from the same +5 V node at the end of a 90 ft cable, then maybe while you are turning one of them the others would get affected. The effect would depend on the properties of your wires, and you might be able to decrease it by configuring the jrk to take a larger number of analog readings on the line. I’m not sure about any of this.

If your number one concern is reliability, not the weight of your 90 ft tether, then using three separate wires for each jrk should be better. Also, you should power each potentiometer from the AUX pin and enable the disconnection detection feature.

You should be able to connect the reset lines of all the jrks together and reset all of them with a single button. Another thing you could do is put a switch for each jrk on your control panel that will disconenct the AUX line of the jrk from the pot. Then (if you have disconnect detection enabled) the jrk would detect that the input is disconnected and stop of the motor when you hit the switch.



Thanks once again for your help.

The AUX and reset comments are extremely useful.

So, now I’ll carry on using cable to prove the concept, then move on to RS485, then wireless.




So, there I was designing the wiring layout last night and immediately stumbled upon a problem.

I was going to take David’s advice and use RS485 to chat to the controllers from a USB adapter at the local end. This would be daisy chained to the RX pins as per the manual. The idea of this was to make a migration to wireless a little easier later. Of course, that makes the RX pins unavailable as analogue inputs!!!

Ok, so I’ve seen a way of extending USB using Cat5 cable but it’s all starting to get a bit messy.

David or Ben or anybody, for that matter, is there a more elegant way of achieving my aims? I should also point out that the pan and tilt head will be 20ft up in the air, so the idea of setting the boards up and then unplugging, is not an option. The cable is still 90ft as it has to run safely around the building.

Many thanks again.


I didn’t realize that you wanted to send serial commands to the jrks and have potentiometers at the same time. I thought these were two separate plans.

You are correct: the jrk can either accept serial commands on the RX line, or it can accept an analog voltage on that line. These input modes are two alternative ways to tell the jrk what position to go to (setting the Target variable), and you can’t use both at once. If you have a serial connection from your computer to a jrk, you could write a little program on your computer to control their positions. If you want to have a potentiometer interface, you can get rid of the serial connection or program a microcontroller that reads potentiometers can sends serial commands over RS-485. Our Baby Orangutan or Wixel will probably fit your needs (just make sure that your RS-485 transceiver’s voltage levels are compatible with the microcontroller).

You realize that you can simply change your wiring and reconfigure the jrk using USB when you want to change from analog input mode to serial input mode, right?

Also, just to be sure, you know that the feedback potentiometer goes to the FB pin (not RX), and is different from the control/input potentiometer, right? You can have analog feedback and serial input at the same time.


Hi David

Well, I didn’t realise that it would be an issue until I tried to figure out the wiring!! I suppose I should have noticed earlier that the RX pin was used for three input modes.

I’m going to carry on with the original concept of having the boards at the remote end and to try to tune the motors ‘on the ground’ with USB. I assume I can program four of them using a USB hub. That way I shouldn’t need to use the USB for that first 90ft job.

When that’s finished, I’ll have more time to look at your idea of an Orangutan board to control the motors serially.




Another thing you might consider doing is extending USB over RJ45 (ethernet) cables. I don’t know how well it would work for you, but it wouldn’t be too expensive to try.

- Ryan


Yes, that’s a great idea using RJ45.

I know that I should ask Bytec but I wonder if you know whether I can run a hub at the far end to talk to the four JRKs. I presume, or hope, that each board would appear with its own address in the programming software. What do you think?

Maybe I’m using a hammer to crack a nut here. Once the boards have been programmed with all their setting, then can I disconnect and use them stand-alone?

When they power-up again, are they ready to use on their own?

Thanks for a great forum here.




I haven’t tried using a hub. It might be possible; it wouldn’t be costly to test it. The Jrk Configuration Utility is designed to be used to configure the jrk and does not need to be connected to it while it is in operation. The configuration settings are remembered in the jrk’s non-volatile memory, and are recalled, even if the jrk loses power.

- Ryan

Hi Ryan

Thanks for all your previous posts.

I’ve been playing around so far, mainly using the USB port, and now the time has come to use the correct bits.

I have searched the forum but maybe I’m putting in the wrong keywords. I’m sure this has been answered before and you’re sick of answering it so just point me there.

Problem is, using a 100k pot as control with no feedback used or selected, the motor achieves max speed, forward and backwards, within a few degrees of centre. This also occurs using USB control, within a few hundreds of 2048.

I used the learn mode, and all settings, apart from amps, are at max.

It’s me being stupid, isn’t it?



Hello, Keith.

What are your input scaling settings? You should set the Maximum Target to 2648 (which corresponds full speed forward if Feedback Mode = None) and set the Minimum Target to 1448 (which corresponds to full speed reverse if Feedback Mode = None).



You’re a star!!

That solves the problem of pot range for the time being. This means I can do a temporary fix for one of my problems, two motors with no feedback.

So, are you saying that with feedback the whole system becomes more responsive?

Well, I suppose that’s obvious, but will I have more resolution and smoothness of speed or is everything in 600ths?

Oh, by the way, is this solution in the manual? I searched but maybe I’m just old.

Thanks again, the service is spectacular.


Hello. I’m glad that you were able to fix your problem.

The jrk does its PID calculations using mostly 12-bit math (numbers between 0 and 4095), but the end result will be an integer between -600 and 600; those are the speeds that the jrk can drive the motor at. The number 600 comes from the fact that the microcontroller is running at 12 MHz and the PWM frequency is 20 KHz: 12000/20 = 600.

That solution is not written explicitly in the manual. We have three input modes and three feedback modes. We explain each of them individually, but we did not write something to explicitly explain every possible combination. You could have come up with the solution yourself if you read the right parts of the Jrk User’s Guide:

3.c. Feedback Options : "None indicates that feedback and the PID calculation are disabled. In this mode, the duty cycle target is equal to target - 2048 instead of being the result of a PID calculation. This means that a target of 2648 will correspond to driving the motor full speed forward, 2048 is brake, and so on. However, the jrk still performs all of its calculations once per “PID period”."

3.b. Input Options : Input Scaling subsection: "The scaling options in this tab determine how the raw input values map to target values, which determine the output of the system. The parameters Maximum and Minimum should be set to the maximum and minimum possible values of the input device; these will be scaled to the target values specified in the right column. "

In general, every calculation the jrk does is documented and all the variables are displayed in a graph for you, so that should help you figure out what is going on.