kMaxUDPPacketSize to big for LED Lab ?
Closed this issue · 10 comments
I have tested LED Lab from iphone and ipad .
And not work .
for fixed the probleme change udp PacketSize
static const int kMaxUDPPacketSize = 65507; ( LED Lab not working , Processing working )
static const int kMaxUDPPacketSize = 1500; ( LED Lab working , Processing working )
This would limit the LEDs that can be addressed (the smaller packets might be useful for standard PixelPusher, but here we can do many more LEDs at once).
But why limit the number of LEDs when you have so many available ?
So this is not actually a fix, you are just indirectly limiting the number of LEDs you can address ( https://github.com/hzeller/rpi-matrix-pixelpusher/blob/master/pixel-push.cc#L451 ). But then you could just connect less panels.
So I guess the iphone app can't deal with the amount of LEDs, so it would be better to fix that instead. I presume the authors of that software just were playing with a standard PixelPusher and didn't think of many more LEDs ... I'd file a bug with them.
I'm the author of LED Lab, and I just found out about this PixelPusher emulation. It's an exciting development in the PP world. Thanks for writing it!
As for this issue: The header that PP sends to the client specifies the max number of strips/outputs to send in each packet. It's in a field called "max_strips_per_packet". LED Lab follows this without question, calculating the max bytes per packet like this:
_maxPacketLength = 4 + ((1 + 3 * _pixelsPerStrip) * _maxStripsPerPacket);
If a PP device/emulation returns a value that results in a max packet length greater than 8K or so, pixel data won't get sent. This is because iOS will not deliver UDP packets larger than 8K. This limit is not documented anywhere. It's just what we've occasionally seen.
You're not seeing this problem in Processing scripts probably because they're not running on iOS, but some other OS that doesn't impose this limit on UDP packet size, or they're using TCP packets.
Jas (PP's creator) has been adamant that UDP packets should be limited to 1492 bytes for efficiency. Therefore, I would suggest that max_strips_per_packet be calculated to keep packets this small. If for some reason this can't be done, I CAN add code to override the value returned by your PP emulation, reducing it to keep packets small. You tell me what the best way to proceed is. :-)
Cheers,
Christopher
Interesting limitation built into iOS.
I think I was just implementing the straightforward case to have one framebuffer fit completely into one packet, and it wasn't very clear to me that it was possible to address specific strips in the protocol ? If I have many strips, how are they addressed then - IIRC, the protocol only sends the requested data, but it doesn't say with which strip it starts - so it wouldn't be possible to send a large frame buffer in multiple pieces (e.g. a 192x96 panel I put together https://plus.google.com/u/0/+HennerZeller/posts/Ei9CTwkuVDn ).
Maybe I am missing something and it indeed allows to set the start strip (what I would like to do then would be something like : [start strip 0 + (data for 4 strips)], [start strip 4 + (data for 4 strips)] ...
If not, then I might have to simulate a number of different pixel pushers, each only responsible for a couple of strips, but that sounds pretty complicated and harder to deal with as 'one' framebuffer if needed in such context.
In general I agree that it should be possible to limit the data per UDP packet, as large packets usually have a hard time to be routed anyway. Also, there is a hard limit at 64k. However, currently it sounds like (well, I have to re-read the protocol spec), that we have to cram the whole frame buffer into one packet.
I think I'll have to consult Jas about the options.
Christopher: Since you are in Oakland and I am in San Francisco, we could maybe play one weekend with my LED panel and your L.E.D. Lab to get things running properly (I don't have an iOS device to test L.E.D. Lab).
Maybe at Noisebridge in San Francisco ? Shoot me an email if you're interested (couldn't find an email address of yours, mine is on my github profile).
Oh, looking at the code, I am already doing the right thing and use the right index into the row (data->strip_index). So just setting the kMaxUDPPacketSize to something smallish should work.
I'll update the code later today.
Thank you Henner and Christopher for working on a fix to solve this problem.
I made a 64x64 LED Matrix and i'm excited to see it working with Henner's pixelpusher emulation. controlled by LedLab App.
Antonio
Antonio, now the UDP packet size is configurable via an command line option. The default is now pretty small, but looks like you can give it up to 8k.
If you already have wired up your matrix, be aware that I refreshed the library dependency to the new version of the rgb matrix, which has a little different wiring (see README). If you want to run with the old wiring, make sure to call make with the RGB_CLASSIC_PINOUT define:
DEFINES+="-DRGB_CLASSIC_PINOUT" make
Henner,
thank you. Your pixel pusher emulation is great. You've done a real good
job.
I talked with Christopher a few days ago concerning the issue and sent
him a small video clip with the behaviour of the LedLab app connected to
a 64x64 matrix.
I'm a computer educator and scientist. We use your pixel pusher
emulation in our educational department on raspberry pi for our
students. We already made more than ten matrices, some with old wiring
and the 64x64 with new wiring and level shifters. Did you know, that
with original java bridge for sACN your virtual pixelpusher can be used
with a lot of free software (Bridge:
http://heroicrobotics.boards.net/thread/39/artnet-support-sacn)?
To use it, I made a little modification in 'pixel-push.cc'. The java
bridge wouldn't work with artnet universe/channel = 0 / 0.
I hard coded 1/1
Than you can use almost any artnet or sACN software, like glediator or
Jinx (http://www.live-leds.de/downloads/).
Do you know the ESP8266 microcomputer? It is a small, inexpensive chip
with wifi, webserver, i2c, adc, one wire, pcm, ...
We use it to open a garage with Siri/iOS (apple homekit) and with
Android (webapp) and built a lot of IoT things, eg. intelligent lamps,
temperature sensors, LED strips (!) and much more.
It is easy to flash and program this ESP8266 cpu, if it is connected to
a RPI (same 3,3V). We use nodemcu as mini OS.
Perhaps this would be interesting for you :D
Thank you again and greetings from the other side of the ocean :D
Antonio Jorba (Toni@jorba.de)
Germany
Am 12.09.2015 um 09:59 schrieb Henner Zeller:
Antonio, now the UDP packet size is configurable via an command line
option. The default is now pretty small, but looks like you can give
it up to 8k.If you already have wired up your matrix, be aware that I refreshed
the library dependency to the new version of the rgb matrix, which has
a little different wiring (see README). If you want to run with the
old wiring, make sure to call make with the RGB_CLASSIC_PINOUT define:|DEFINES+="-DRGB_CLASSIC_PINOUT" make |
—
Reply to this email directly or view it on GitHub
#3 (comment).
We use your pixel pusher
emulation in our educational department on raspberry pi for our
students. We already made more than ten matrices, some with old wiring
and the 64x64 with new wiring and level shifters. Did you know, that
with original java bridge for sACN your virtual pixelpusher can be used
with a lot of free software (Bridge:
http://heroicrobotics.boards.net/thread/39/artnet-support-sacn)?
To use it, I made a little modification in 'pixel-push.cc'. The java
bridge wouldn't work with artnet universe/channel = 0 / 0.
I hard coded 1/1
I wasn't aware of Artnet. I now added a command line flag to make that
easier to
set in commit a076d72
Do you know the ESP8266 microcomputer? It is a small, inexpensive chip
with wifi, webserver, i2c, adc, one wire, pcm, ...
We use it to open a garage with Siri/iOS (apple homekit) and with
Android (webapp) and built a lot of IoT things, eg. intelligent lamps,
temperature sensors, LED strips (!) and much more.
It is easy to flash and program this ESP8266 cpu, if it is connected to
a RPI (same 3,3V). We use nodemcu as mini OS.
Perhaps this would be interesting for you :D
I ordered a couple of these, but didn't have time yet to play with :)
Thank you again and greetings from the other side of the ocean :D
Antonio Jorba (Toni@jorba.de)
Gruesse in die Heimat!
Hi Henner,
thank you for adding artnet support :D
Grüße zurück aus der Heimat :D
Antonio
Am 12.09.2015 um 19:14 schrieb Henner Zeller:
We use your pixel pusher
emulation in our educational department on raspberry pi for our
students. We already made more than ten matrices, some with old wiring
and the 64x64 with new wiring and level shifters. Did you know, that
with original java bridge for sACN your virtual pixelpusher can be used
with a lot of free software (Bridge:
http://heroicrobotics.boards.net/thread/39/artnet-support-sacn)?
To use it, I made a little modification in 'pixel-push.cc'. The java
bridge wouldn't work with artnet universe/channel = 0 / 0.
I hard coded 1/1I wasn't aware of Artnet. I now added a command line flag to make that
easier to
set in commit a076d72Do you know the ESP8266 microcomputer? It is a small, inexpensive chip
with wifi, webserver, i2c, adc, one wire, pcm, ...
We use it to open a garage with Siri/iOS (apple homekit) and with
Android (webapp) and built a lot of IoT things, eg. intelligent lamps,
temperature sensors, LED strips (!) and much more.
It is easy to flash and program this ESP8266 cpu, if it is connected to
a RPI (same 3,3V). We use nodemcu as mini OS.
Perhaps this would be interesting for you :DI ordered a couple of these, but didn't have time yet to play with :)
Thank you again and greetings from the other side of the ocean :D
Antonio Jorba (Toni@jorba.de)
Gruesse in die Heimat!
—
Reply to this email directly or view it on GitHub
#3 (comment).