Qik 2S9V1 Nightmare

Hello everyone out, there please help me out. I recently purchased 4 qiks for a project using arduino and 7 computer case fans. I cant use the library referenced elsewhere for controlling it because I am using more than one controller in pololu mode. Long story short 2 of the controllers work fine and 2 of them dont respond to commands but do function just fine in demo mode I cant figure whats going on. I figured that I am addressing the controller with the wrong ID number but when I do an 0X83 command with 0 as the parameter it returns a -1 (int, it gave me gibberish with byte). If anyone could give me some direction I would really appreciate it, I can provide code, outputs, etc, anything you need.

Thanks

OK i might have found something, I am using it on auto baud detection if I am trying to use the 0X83 get info code do I still need to preceed it with the 0XAA? The 0XAA is not listed in the manual as being required for the compact protocol for the 0X83 Command.

THanks

Hello,
In auto baud detect mode you need to make sure that the very first byte you send the qik is 0xAA. Is that what you are doing?
-Paul

I do add that when I address the motor controller for actual motor control since i am running in pololu mode. when I was using the get config parameter code (pg 16 of the manual) I was not using it because it was not called out in the compact protocol. I was using compact b/c when I run that there is only one controller on the line so my command to read the controller ID should be 0XAA,0X83,0? I do want to run it in auto baud detection…

In auto baud detect mode, the very first byte received after power-up must be 0xAA, no matter what protocol you want to use. The reason is that 0xAA presents a simple alternating pattern of 0’s and 1’s that the device uses for accurate baud rate synchronization. After the 0xAA, you can either continue with the rest of a Pololu protocol command or send as many commands as you want in compact mode without the 0xAA. For example, you could get the device ID and the PWM parameter by sending 0xAA,0x83,0x00, … wait for response … , 0x83,0x01. Does that make sense? You should be able to tell whether the qik has successfully detected the baud rate or whether there are other problems by paying attention to the LEDs.

-Paul

Ok so I have tried this code,

void setup()
{
Serial.begin(9600);

}

void loop()
{

byte baud=0XAA;
byte command=0X83;
byte param=1;
int recieved=0;

Serial.print(baud);
delay(1000);
Serial.print(command);
Serial.print(param);

recieved=Serial.read();

Serial.println(recieved);
Serial.println(recieved);
Serial.println(recieved);
Serial.println(recieved);
Serial.println(recieved);
Serial.println(recieved);

}

I am trying to get the controller number from this but it keeps giving me jibberish see below
ª?-1
-1
-1
-1
-1
-1
ª?0
0
0
0
0
0
ª?0
0
0
0
0
0
ª?0
0
0
0
0
0
ª?0
0
0
0
0
0
ª

Im not sure where im going wrong with this I have a feeling it has to do with the baud rate, should I change the arduino baud? I tried this with a qik that I know is functioning properly and it gave the same output. Any ideas?

Dan

OH i forgot to mention the qik accepts the signal, no error LED clean heartbeat LED.

Dan,

Please wrap BBCode [ code ] [ /code ] tags around your code to make it easier to read. You might be experiencing problems due to the way the Arduino uses its hardware serial lines for programming and debugging. Just programming your Arduino would most likely cause the qik to detect and configure itself for the programming baud rate, which I believe is much higher than 9600 bps. Can you try rewriting your code to use sofware serial on different I/O lines (I think this is what the existing qik Arduino library does)? There are also a few other things you could try:

  1. Do you get the same behavior with all qiks when performing this test (with only one connected to the serial lines at a time)?
  2. Do you get the same behavior if you reset the qik after programming your Arduino?
  3. Do you get the same behavior with the qik in fixed-baud mode?

Also, why do you print the “recieved” variable six times in a row? Finally, you should expect to see gibberish results since you are trying to print the ASCII characters that correspond with your byte values. Serial.print((byte)7) will not print ‘7’. Rather, ‘7’ has an ASCII value of 55, so it takes the line Serial.print((byte)55) to get ‘7’ to print on the screen.

- Ben

Note: I edited this post to add the bold byte casts to correct my statement. I was trying to make a clear example, but I neglected that 7 has the default type int, not byte, which causes Serial.print() to treat it differently. Thanks to Paul for catching that and correcting me.

Hello again,
I don’t really know anything about Arduino, but I am going to disagree with Ben on one point - Serial.print(7) actually does print “7”, doesn’t it? At least, the documentation indicates that it behaves differently when given a byte and when given an int. That explains why your code is printing the -1 at first - a value of -1 means that no byte was available. That is, your qik did not respond to the command. When you tried converting that -1 into a byte, you ended up printing character 255, which would probably look like gibberish in your terminal.

I am very skeptical about the way you seem to be using the hardware serial line for the qik, when that is usually connected to something else on an Arduino. You have not described your connections or told us what board you are using, but since you are doing the println() on the same it sounds like you might have two separate UART outputs (one from a USB-serial chip and one from the qik?) shorted together. If I am understanding that correctly, it is very unlikely to work that way. Please switch to different pins and use the software serial library!

-Paul

Thanks for the correction, paul; I added the proper typecasting to my above post to make it accurately convey the original message I was trying to get across. As far as your above quoted sentiment, though, I don’t see anywhere in Dan’s code where he converts “recieved” into a byte (I’m a little under the weather right now, though, so hopefully I’m not missing something stupid and obvious!). Rather, the variable is of type int and he doesn’t perform a cast, which is why his output includes non-gibberish ‘-1’. I think the gibberish comes from trying to print the “baud”, “command”, and “param” variables, which are byte types (where 0xAA corresponds to a weird ASCII character and 1 corresponds to a special non-printing character).

- Ben

Ok, there is alot here so Il just start answering questions. I am running this all on an arduino mega arduino v15. I upload the code to the board unplugged from the qik so that the serial lines dont interfere with the qik. I can and have used one of the other hardware serial lines (there are 4 on the mega) but they gave the same issues so I removed that coding for simplicity. I have not tried using a software serial program, the reason for this was I am trying to reduce code space as much as possible because I am running a fairly demanding FFT algorithm with this (once its all working). The weird thing about it is that I am running 4 motor controllers in the final program currently two of them work fine, in the two that dont I am trying to confirm that they have been assigned the correct number and to do that I am running the program quoted above with only one on the line. I have not yet tried the qik in fixed baud mode. The two that functionally work fine when commanded will not respond any differently than the two that dont to the code above which makes me think that I am doing something wrong with the interface between the two and trying a software serial might be beneficial.

On the Arduino Mega, the RX line already has an output (from the USB-to-serial chip) connected to it. That means you will probably not succeed if you try to connect another output. Whether it works or not depends on exactly how strong each of the two outputs is, and it might be right on the edge of working with a qik, so it could very well work on some of your qiks and not on others. You really need to move to another pair of ports.

-Paul