Matrix value / Serial crash / Channel limit or bug?
-
Hi all,
I'm working on the control of a large LED array via serial control from Izzy(hopefully). The array itself is timed / controlled by a pair of Teensy 3.0's using the octows2811 library, (which are pretty amazing if you're not familiar with them). I'm using a matrix send / receive setup (with the same 40 hz text trigger/ blocker set-up as for DMX) to send pixel data to the teensy's, which then buffer it and display a new frame on receipt of an EOM character. The protocol between the two is similar to the DMX standard (ind RGB channels, using 2 digit hex, with channel number specified by byte order). The set-up is working in concept and uses a great library already written for the teensy, and reuse a bunch of prior izzy work using DMX.
My problem is that Izzy keeps hard-crashing whenever any changes are made to the send / receive set-up, or after a few minutes of operation whenever more than 512 channels are specified. I'm wondering if there's a limit to the # of channels of the matrix send / receive system can handle?
Ultimately I'll be needing to use ~ 4096 channels, which I know is starting to be a chunky serial message. However, I've been able to send that size message from Processing and have it go through so I think it's not a fundamental limit of serial. That said, the crashes typically only happen when the serial port is enabled.
I'm using f25/ osx 10.8.3 / retina.
Any thoughts, suggestions?
Thanks,
Ian
-
Have you tried slowing down the pulse generator to see if that works? In theory if your serial message is 4 times as long, the pulse needs to be one fourth so as not to crash.
-
Are you on mac or pc.
What speed serial are you using ? At that speed how long would it take to send the serial message you are trying to send (precisely how much data are you sending).In processing were you forcing it to send at 40Hz, or were you just sending as often as processing was able to ?- can you post the example code from processing. -
Hi Craig and Nick,
So in Izzy I've tried the following:
- slowing the pulse generator to as slow as .1hz
- setting it to off
- enabling and disabling serial ports
- The base serial speed I've been working with is 57,600 but I've tried changing the serial port speed rate in steps from 9600 to 115k (and setting the corresponding teensy serial port speed).
The issue is that none of those prevent the hard crash that happens when the I make changes to values in the matrix receive actor. That crash happens even if the izzy engine is paused, and the pulse generator turned off.
The message I've been trying to send is <1024 bytes (i.e. <1k), all are 8bit hex color values. In theory that's 40k sec when sending at 40hz (which should be well under the 115k maximum serial speed, although that's theory...
As far as the Processing question -- this may be a red herring on my part -- I'm going directly from Izzy to Teensy, and have just been using the Processing piece to test the Teensy. That said --- here's the test code in processing, which has seemed to send data fine to the teensy. The one caveat is that I'm able to test for certain whether it's being sent as one giant packet per frame or if it's being broken up into chunks.
-
Hi
I don't see any processing code.I have built the izzy patch as your picture (it would be more useful if you could attach the patch rather than a picture) and it is very sluggish once you push it up to 40Hz.Careful with your calculations about data rate. Serial port speed is bits/second, your values for transmitting data are bytes - in addition some of the bits transmitted are used for signalling, not transmitting data, so you get about 80% of the available bits for data if your serial is using 8-n-1 (8 bits data, no parity, 1 stop bit).If you are using the scheme in the picture shown, you are also transmitting as many commas as values, so your message size is more like 2048 bytes for 1024 numbers. -
Dear Ian,
Can you use the crash report gathering applet shown [here](http://troikatronix.com/troikatronixforum/discussion/65/bug-reports-guidelines#Item_2) to gather the crash reports so I can see what is causing the crash?Best Wishes,Mark -
Hello Nick (& Mark),
Thanks for the reminder on the separator bit. That's helpful.
Here's an update -- I've done another round of more systematic testing and have learned a more things:
1. Unclocked LED's (eg. the WS2811) are fussy, fussy, fussy about power : a small difference ground potential (10mv) between my computer's USB cable shield / V-; and V- on the Led array after ~ 15 pixels turns out to be enough to make the controller chip on the LED's hang, which appears to stall serial data transmission from the teensy, which causes Izzy to hang. Tying together the grounds at the end of the strings (in addition to beginning) resolved the difference in ground potential, and some of the crashes.
2. Once the v- difference was resolved I've been able to get the attached patch to transmit at a serial rate 215k. Right now I can get 1024 channels to run at a refresh rate of ~12 hz, and 2048 at ~6hz. Once it exceeds that the serial port hangs, izzy hangs, and then crashes (similar issue to what happens if the enttec is overloaded).
3. Getting rid of the separator bit helped the throughput a lot - thanks for the reminder.
4. When the Matrix send actor channel number are edited (whether or not the serial port is enabled) Izzy is still sometimes crashing.
I've just attached the serial to teensy patch for reference. Mark -- I've just sent you the crash log.
Once I get the Teensy piece working more reliably I'll post that code as well. A $19 controller (the teensy price) for a 1000 LED pixel array is pretty enticing.
Thanks,
Ian
