<< return to Pixycam.com

SPI specifications for Pixy

Pixy Software
#1

hi,

I now finally got my cable and crimp plugs to customize 10-to-(6+4) wires to utilize CS/SS wire 7 and make the Pixy run in SPI-CS/SS-mode.

So I have a couple of questions about the SPI specifications for Pixy:

  1. what is the default SPI clock speed used for Pixy (MHz) ?
    a) AVR SPI clock-devider = ?
    b) ARM SPI clock devider = ?

  2. what is the maximum cable length for SPI cables used at the default SPI clock speed ?

  3. Is it possible to use standard SPI clock speed for Pixy (4 MHz) by CS/SS mode ?
    (AVR SPI-clock devider=4, for ARM SPI clock devider = 21)

  4. what is the maximum cable length for SPI cables used at the 4Mz standard SPI clock speed ?

#2

Hello Helmut,
Good work with the cable! Regarding the clock rate, since Pixy is an SPI “slave”, the clock rate is completely up to your controller (the “master”). The Arduino library sets the SPI clock rate to 1 MHz for AVR and ARM. I believe if the cable is much longer than 20 inches, you start getting some bit errors. This might be fine however because the serial protocol has checksums, so this may not be a problem. (It depends on your application, whether you can tolerate a few missing blocks every now and then.)

Hope this helps!

#3

hi,
I’m a little concerned about what happened if I set the SPI clock to 4 MHz standard then, and what would happen next if several devices are plugged to the bus additionally also running at 4MHz (e.g., a SD card and a TFT display in the first line), because at 1MHz especially the TFT would be too slow actually.

So I would patch the Pixy lib then preferably to 4 MHz if I got a “go!” by you/by the developers…
But this might limit the cable length to something shorter, or what would you think ?
:?:

#4

Hello Helmut,
I would use the cable length you want to use and the clock rate you want to use and give it a try. You aren’t going to damage anything by trying. :slight_smile:

Edward

#5

I just have 1 cable and 1 block adaptor to crimp and I need it as long as possible, so reliable data would be appreciated!

First of all I needed information from you how Pixy works with the standard cable at 4 MHz clock speed,
and what actually the reason is why you clocked the PCI down from 4 to 1 MHz?

For the future it would be wishful to have a finished 10-to-6 plus 4 cable to use both SS and UART, too, delivered with the cam!

#6

I just have 1 cable and 1 block adaptor to crimp and I need it as long as possible, so reliable data would be appreciated!
First of all I needed information from you how Pixy works with the standard cable at 4 MHz clock speed,
and what actually the reason is why you clocked the PCI down from 4 to 1 MHz?>

bump

#7

Hello Wunder,
We chose 1Mhz because it results in no bit errors in a relatively noisy environment with motors turning on and off. Cable length and datarate are all related to the amount of electomagnetic noise. Your environment might not have motors or other large sources of electromagnetic noise, so you might be able to use a longer cable and a higher datarate.

Hope this helps!

#8

Actually I have all over 16 motors running, not always simultaneously though. The cam is placed at the grabber of the 5 DOF arm, motors for arm manipulation are quite close (2 Lego motors (9V 1A) each at either joint). The length of the streched arm is about 1 meter which would be roughly the distance to the Arduino board.

#9

Helmut - can I see a picture of your creation? It sounds fascinating. Rob

#10

there are some photos on facebook - the older construction by 1 motor per joint axle and 2 vor the drive, and the new arm under construction with 2 motors per arm joint and 4 motors for the drive
https://www.facebook.com/helmut.wunder.3/photos
but that doesn’t actually solve the SPI timing and cable issue…

#11

so is this an issue just about shieldings against interferences or are there general cable length issues additionally?

#12

hi,

could I please get some reliable (!) tested (!) data about SPI clock speed (1-4 MHz) , cable length (20 - 100 cm) and Pixy data transmission / data corruption ?

#13

Hello Helmut,
Sure. 1Mhz, 12 inches.

Anything different you are on your own.

Hope this helps!

#14

are you fooling me?

about your standard cable and your clocked-down non-standard 1MHz I already know!

I want information about standard 4 MHz clock speed and different cable lengths!
Please strive to overcome with the data!

#15

Hello Helmut,
We aren’t a big corporation with lots of resources (money, equipment, people). :slight_smile:

What information did you have in mind? Please be specific!

Edward

#16

SPI clock speed for Arduino Due:
4 MHz (= standard ARM SPI_clock_devider=21)
SPI CS/SS mode

any encounterd read errors or data corruption, drop outs, checksum error (cs), or reorders by
cable length = 100 cm?
cable length = 80 cm?
cable length = 60 cm?
cable length = 40 cm?

#17

bump

now what about cable length vs. clock speed?
I wouldn’t like to encounter the same bugs and issues as I did already for UART (cs errors, reorders) when I finally had cut and fabricated my SPI-CS cable!

I was not able to make the Due work with my Pixy cam al all so far, which is extremely annoying, tbh!

Please recall, I’m working with DUEs !

My setup:
SPI clock speed for Arduino Due:
4 MHz (= standard ARM SPI_clock_devider=21)
SPI CS/SS mode

read errors or data corruption, drop outs, checksum error (cs), or reorders by…

cable length = 100 cm?
cable length = 80 cm?
cable length = 60 cm?
cable length = 40 cm?

#18

bump

#19

bump

#20

because I didn’t manage so far to get my Pixy working with my Arduino Due reliably (neither by UART nor by SPI) and because of your lousy support I have therefore now initiated the return within the warranty period.

I would recommend no one to buy this miserable working and miserable documented Cam at the present time and I have no desire to do the beta tester’s work for you!