See code example got working below original post...

Original post: Sorry first posted this in the review section so adding it here. I am looking to use this run a DC motor forward and backward and none of the examples provide a clue as to how to do that??? I am using a Redboard and a SEEED Motor driver shield V2.0. Got the Redboard to drive the motor alternating back and forth with their example code. I was able to run all of the examples for the Twist. So I know all of the hardware works. However, the code for mapping the encoder steps to how fast the motor runs escapes me.

So after some experimentation got the following code to work very well. Using it as a DC throttle for model railroad application. Need to reset each time to get it to start up.

//SN300_DC_Throttle

//Sparkfun RedBoard and Encoder

//SEEED Motor Board V2.0

//Reverse switch is DPDT

//Code Modified by David Bradt

/* Read and interact with the SparkFun Qwiic Twist digital RGB encoder By: Nathan Seidle SparkFun Electronics Date: December 3rd, 2018 License: MIT. See license file for more information but you can basically do whatever you want with this code.

This example prints the number of steps the encoder has been twisted.

Feel like supporting open source hardware? Buy a board from SparkFun! https://www.sparkfun.com/products/15083

Hardware Connections: Plug a Qwiic cable into the Qwiic Twist and a BlackBoard If you don't have a platform with a Qwiic connection use the SparkFun Qwiic Breadboard Jumper (https://www.sparkfun.com/products/14425) Open the serial monitor at 115200 baud to see the output */

include "MotorDriver.h"

include "SparkFun_Qwiic_Twist_Arduino_Library.h"

//Click here to get the library: http://librarymanager/All#SparkFun_Twist

const float Factor = 6;

const int buttonPin = 4;

int buttonState = 0.5;

MotorDriver motor;

TWIST twist;

//Create instance of this object

void setup()

{

Serial.begin(9600);

pinMode(buttonPin, INPUT_PULLUP);

Serial.println("Qwiic Twist Example");

motor.begin();

if (twist.begin() == false)

{

Serial.println("Twist does not appear to be connected. Please check wiring. Freezing...");

while (1)

  ;

// initialize

}

}

void loop()

{

Serial.print("Count: ");

Serial.print(twist.getCount());

if (buttonState == HIGH)

{

Serial.print(" Pressed!");

Serial.print(buttonState);

motor.speed(0, Factor * twist.getCount());

// set motor0 to speed based on count

delay(50);

Serial.println();

}

}

I got 6 of these today, was in a hurry on a button box project but it's the 1st time I'm seeing an encoder without ability to use bolts to fix it on enclosure. The only way to fix this one on enclosure is to create 4 holes on the enclosure with spacer and nuts to attach the board. Not painless and looks terrific. So I'm not satisfied, for me it's just useless, this point should be mentioned on product description.

For those writing custom drivers, this device is one of the few you'll encounter that employs clock stretching, so your I2C driver code must be able to deal with that. Funny, so few devices use clock stretching that I had removed it from my I2C code.

The connectColor() function is incorrectly implemented in the standard Arduino library (code is dated November 25th, 2018). The 16-bit colors are supposed to be written Little-Endian, but that function writes them as Big-Endian.

I have ported the Sparkfun library to the Parallax Propeller P2, with the fix for connect_color(), and one or two additional methods for convenience.

Is it possible to know the absolute position?

wow

nice

Question about the max cps this can handle, I want to use an encoder to track the rotation speed of a motor (to keep two motors on separate drive and slightly unbalanced loads speed matched) and have some different re-purposed motors with 56/250/600 CPR encoders built in. While I could mount up a lower CPR encoder to the system output after all the pulley reduction and filter out any accidental velocity dither from the low cps that's more work and space. Nothing is going terribly fast, ~50RPM at the output max, but that's still in the 150kHz cps range using the lowest CPR motor encoders and I think it may be a bit fast for a board designed for fingers.

Can you lovely people make a Sparkfun, ahem, I mean, a Particle library for this Qwiic Twist? I own 2, and my Photon and Electron are lonely. Peace out, old dude.

Is there any chance I could get a number of these with a threaded bushing like that on your https://www.sparkfun.com/products/15141 encoder? I love the Qwiic idea, and this product is great, but I'm having a heck of a time coming up with a way to mount it to a front panel.

There is a CircuitPython library now available for the Qwiic Twist RGB Rotary Encoder and the Raspberry Pi. The source code, examples, installation information and documentation are available on GitHub.

https://github.com/fourstix/Sparkfun_CircuitPython_QwiicTwist

Hey! I was just wondering if the library you guys made for this is blocking or non-blocking code? I'm working with XBees so I want to avoid blocking code in order to read the Xbee as quick as possible.

On another note, did you guys end up making the non-LED version of this? I haven't found it on the store but maybe you did.

Thanks!

What are the physical dimensions, especially the mounting hole centers? Am I just missing it, or...?

I'm not that happy with this product. Even though it works to some extent it misses counts and has switch bounce issues I haven't been able to resolve yet. I have 4 of them chained together and being run using a Teensy 3.5. Even the most basic example provided has issues with it constantly non-stop firing off interrupts. Seems like this is due to I2C communication which when you perform a "GET" command in your loop it will non-stop perform an interrupt. This seems to be creating problems reading the encoder accurately and the push switch also. Is interrupts really needed for Ic2 communications? You can see this by my forum post here https://forum.sparkfun.com/viewtopic.php?f=14&t=49095 The ATTINY84 is suppose to, on idle go into a sleep mode but it looks like it never does. There is a very similar product offered on tindie. It uses a PIC microcontroller instead of an ATTINY84 and looking at the firmware code does not perform an interrupt on every I2C command that gets requested data. Here is that device to compare to https://www.tindie.com/products/Saimon/i2c-encoder-v2/ it is very similar. Actually this one was developed several years ago. I might try these out and see how well they work. Or at least prototype the circuit for testing.

I'm very happy this product finally exists. I ended up having to make my own version of this for a current project that uses 19 RGB encoders. I also went with the attiny84, but I discovered that there's quite a bit of variance in color (full white) from one to another. I'm using 1% resistors. Have you all at sparkfun found this to be true? I assumed it was because I'm not using constant current.

This seems like a really cool device. But I am wondering, are there any plans to offer this exact same thing but without the LED?

I can envision quite a few applications where this would be really handy. But the price is a bit high if you don't need/want the LED.

Thanks, Joe