Qik 2s9v1 and Freeduino EtherTen serial communication issue

Otte · June 27, 2012, 12:09pm

UPDATE
Problem solved. The new PololuQik library solved my problems.
I guess the reason is the improved timing in the serial communication with the board.
The wheels of the bus are now going round and round

Thank you Kevin!
UPDATE

I have a similar situation - new Qik2s9v1, new small 240:1 motors, Freeduino EtherTen board. Wired up properly, I think (board Rx goes to Qik Tx and vv.). 5V on board, for logic, separate 9V supply for motors (Motor Vcc and GND). System: Arduino 1.0.1 on Ubuntu 10.4 with USB link to Freeduino.

–UPDATE–
Demo mode (short jumpers A and B together) works, the motors 0 and 1 are moving back and forth. Not too fast (240:1 and nearly empty 9V batt), but they move anyway.
Fixed baud rate at 38400bps changes things a bit - error LED remains OFF but serial communications still seems to be bugged - I only get 0xFF back from the SoftwareSerial line, it seems.

–

Pins:

Duino --- Qik
GND ---- GND
5V ------ Vcc
3 -------- TX
4 -------- RX
5 -------- RST
n.c. ---- ERR
Mot1- --- M1-
Mot1+ --- M1+
Mot0- --- M0-
Mot0+ --- M0+
9V- ----- GND
9V+ ----- Vmot

Jumpers A and B not used, unless testing demo mode and fixed baud rate.

Freeduino Code:

#include <CompactQik2s9v1.h>
#include <SoftwareSerial.h>

/*
	Important Note:
		The rxPin goes to the Qik's "TX" pin
		The txPin goes to the Qik's "RX" pin
*/
#define rxPin 3
#define txPin 4
#define rstPin 5

SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin, false);
CompactQik2s9v1 motor = CompactQik2s9v1(&mySerial,rstPin);

void setup()  
{ // initialize Serial monitor and SoftwareSerial for Qik comms
  Serial.begin(9600);
  mySerial.begin(9600);
  // initialize motor, stop both of them
  motor.begin();
  motor.stopBothMotors();
  // rx/tx comms sync, then error LED comes on permanently
  // so let's grab the error information and some other details if we can
  int ID = motor.getDeviceID();
  Serial.print("Device ID: ");
  Serial.println(ID);
  int fwv = motor.getFirmwareVersion();
  Serial.print("Firmware version: ");
  Serial.println(fwv);
  int err = motor.getError();
  Serial.print("Error: ");
  Serial.println(err);
  boolean doe = motor.hasDataOverrunError();
  Serial.print("Data overrun: ");
  if (doe) Serial.println("TRUE"); else Serial.println("FALSE");
  boolean fe = motor.hasFrameError();
  Serial.print("Frame error: ");
  if (fe) Serial.println("TRUE"); else Serial.println("FALSE");
  boolean crc = motor.hasCRCError();
  Serial.print("CRC error: ");
  if (crc) Serial.println("TRUE"); else Serial.println("FALSE");
  boolean fmt = motor.hasFormatError();
  Serial.print("Format error: ");
  if (fmt) Serial.println("TRUE"); else Serial.println("FALSE");
  boolean tim = motor.hasTimeoutError();
  Serial.print("Timeout error: ");
  if (tim) Serial.println("TRUE"); else Serial.println("FALSE");
  // try to do something with the motors
  motor.motor0Forward(16);
  motor.motor1Forward(16);
}

void loop() 
{   // nothing to do
}

Result:

red error LED blinks around 3x (serial baud rate detection), then remains ON. Sending get_error() code does not change anything;
green status is green and blinking every 0.4s, error pin voltage is around 5Vdc;
nothing happening with the motors, they can be moved by hand;
Serial (USB) monitor output at 9600 baud:

Device ID: 255
Firmware version: 255
Error: 255
Data overrun: TRUE
Frame error: TRUE
CRC error: TRUE
Format error: TRUE
Timeout error: TRUE

Dunno what I did wrong… everything which is being read back seems to be 0xFF. Would be OK for the error (although bits 0…2 are supposedly not used) but at least the Device ID and the FirmwareVersion should read something else but 0xFF, wouldn’t you think?

There is around 10Vac on the rx pin of the Qik (so something is coming in there) and also on the tx pin of the Qik, so it seems to be acknowledging the incoming signal even though loop() does nothing. (Sorry, I have no scope available, but a vintage voltmeter instead …).

Any clues anyone? Perhaps the bug (if any) is actually in the SoftwareSerial stuff, I don’t know.

UPDATE
Problem solved. The new PololuQik library solved my problems.
I guess the reason is the improved timing in the serial communication with the board.
The wheels of the bus are now going round and round

Thank you Kevin!
UPDATE

Otte

kevin · June 27, 2012, 7:17pm

Hello, Otte.

We have moved your post to its own thread, since it seems unlikely you are having the same problem as in the original thread.

A 9-volt battery (especially a drained one) is not a good source of motor power because it does not have the ability to provide much current, but that should not affect serial communication. Your description of your connections sounds fine, but if you could post a picture that clearly shows your wiring, we can double-check it for any problems.

I did not find any obvious problems with your code either, although you should simplify it a lot until you get things working. Do you get the same behavior regardless of the baud rate?

You can also try using our newer Arduino library for the qik and see if you can get any of the example programs to work with your controller.

- Kevin

Otte · June 28, 2012, 2:24am

Hi Kevin,

UPDATE
Problem solved. The new PololuQik library solved my problems.
I guess the reason is the improved timing in the serial communication with the board.
The wheels of the bus are now going round and round

Thank you Kevin!
UPDATE

thanks for making a new thread out of this.
I acknowledge that a drained 9V battery is not fantastic - it’s all I have at the moment but as I said, the demo mode works, wheels are spinning when A-B are connected.
I’ll snap some pictures of the wiring tonight and will post these. Will possibly make a quick Fritzing schematic as well, to clarify things.

I can clean up the code a bit but all I do is use the functions from the Qik2S9v1 library to initialize, read the error byte, read the device ID and firmware and read the error bits (same as byte, just bit by bit), and dump them on the Serial terminal. I can skip all the HasFrameBufferOverrun stuff (since it’s all covered in the getError() byte anyway).

Yeah, same 0xFF return values and no motor response at 1200baud, 9600, 38400 and 38400 with Qik jumper A (loosly) wired. I didn’t bother with the CRC option so far.

Oooh ! A new library - will try that, who knows

Could well be a timing issue here … I noticed a minor difference between the May 2009 version of the CompactQik2s9v1 library and the new PololuQik library, apart from the usual inttypes.h issues, which are I thin irrelevant for a one byte response:

Old 2009 library

uint8_t CompactQik2s9v1::getError()
{
	sendByte(ERRORPACKET);          <--- no delays in sendByte()
	_errByte = readByte();          <--- no delays in readByte()
	return _errByte;
}

New 2012 library

byte PololuQik::getErrors()
{
  write(QIK_GET_ERROR_BYTE);
  while (available() < 1);         <--- delay here, wait until we have data
  return read();
}

Thx again and I’ll keep you posted.

UPDATE images attached.

UPDATE
Problem solved. The new PololuQik library solved my problems.
I guess the reason is the improved timing in the serial communication with the board.
The wheels of the bus are now going round and round

Thank you Kevin!
UPDATE

Otte

kevin · June 28, 2012, 5:47pm

I’m glad to hear you were able to get it working. Thanks for the update.

- Kevin