Since Teensyduino 1.18 Paul has integrated SPIFIFO into the Ethernet library, so make sure to use the latest Teensyduino. Then IIRC in the /utility folder of the Ethernet library in W5200.h or W5200.cpp you can increase (double) the SPI bus frequency By out commenting a line.
Artnet to OctoWS2811?
- Thread starter telmnstr
- Start date
- Status
mortonkopf
Well-known member
Yep, running 1.18. Will look into how I am using buffers, and look at the bus frequency, as this will be at its default value at the moment. My guess is that the data transfer rate at the moment via ethernet module is somewhat less that 1.5mbs.
I take it I will need to change the line:
Code:
SPI.setClockDivider(SPI_CS, 21);
Last edited:
hey great again!
just want to try it!
1x http://www.pjrc.com/store/teensy31.html
1x http://www.pjrc.com/store/wiz820_sd_adaptor.html
2x http://www.pjrc.com/store/header_14x1_d.html
and the wiz820io modul
do i need something else?
anyone know a european/german seller for this stuff?
just want to try it!
1x http://www.pjrc.com/store/teensy31.html
1x http://www.pjrc.com/store/wiz820_sd_adaptor.html
2x http://www.pjrc.com/store/header_14x1_d.html
and the wiz820io modul
do i need something else?
anyone know a european/german seller for this stuff?
Last edited:
mortonkopf
Well-known member
overclocking removes glitching to give 30fps
I have not made any changes to Manitous default 820i files, but over-clocking the teensy3.1 to 96MHz allows me to run at 30fps for a 60*8 array using 16 universe without glitching (although my physical array is only 30*8, the data being pumped through the ethernet and teensy is for 60*8@30fps. OR, i ran it at 15fps with array data for 90*8 leds without an issue.
I have not made any changes to Manitous default 820i files, but over-clocking the teensy3.1 to 96MHz allows me to run at 30fps for a 60*8 array using 16 universe without glitching (although my physical array is only 30*8, the data being pumped through the ethernet and teensy is for 60*8@30fps. OR, i ran it at 15fps with array data for 90*8 leds without an issue.
Last edited:
Ok I feel a bit silly, I just got a macbook air and was used to being connected to the network via a wire with my macbook pro...
Connected my macbook directly to the Wiz820 via the Thunderbolt Gigabit adapter and now with my 60 led strip it seems to run at 60fps smoothly !
What's curious is that the Air is 802.11ac so I was connected at 867mbps but it would still glitch...
Connected my macbook directly to the Wiz820 via the Thunderbolt Gigabit adapter and now with my 60 led strip it seems to run at 60fps smoothly !
What's curious is that the Air is 802.11ac so I was connected at 867mbps but it would still glitch...
mortonkopf
Well-known member
that is very cool, and i m only a little envious of the macbook air
. It would be good to double check that this is the case with multiple universe. What are you using to generate your artnet packet info? Have you tried sending in multiple smaller universe to test whether they all arrive?
mortonkopf
Well-known member
yep, you can check using the test sketch above, to see what output you get in the serial monitor. This should clarify that you are indeed receiving multiple universe through the ethernet module to the Teensy. I ran tests by loading sketch, then starting serial monitor, and starting Pixelcontroller. I set the pixelcontroller to a test setup of x=60, y=8, universe size = 30. this would then force pixelcontroller to send 16 universe as it divides up the total number of leds by the stated universe size. Also in pixelcontroller you need to uncomment the artnet ip address info. There is no port setting to change as this is automatically set to 6454 for art net.
if it works, you can then modify the sketch to bring back in all of the Opcode to use when sending packets. This gives lots of opportunity to set up listening and feedback systems, and should be able to be used to have multiple nodes with some output systems.
if it works, you can then modify the sketch to bring back in all of the Opcode to use when sending packets. This gives lots of opportunity to set up listening and feedback systems, and should be able to be used to have multiple nodes with some output systems.
Last edited:
mortonkopf
Well-known member
yes, this is because artnet will not count beyond 255 universe, it resets to the first (zero). It has been designed to support 256 universe, thats quite a lot of lighting.
mortonkopf
Well-known member
i just had to go and look that up, good grief… that is a lot of lightsI think the max object implements artnet3 which supports more than 256, I only need 2 so I'm happy
Now I need to figure out how to record and playback that data from sd...
mortonkopf
Well-known member
just had a thought, in the test sketch code the universe number is derived by creating a short from two bytes (byte [15] and byte [14] of the incoming data packet). How does artnet3 derive universe number? might be worth having a look at which bits in the incoming packet are set aside for this.
I was actually not talking abut the modified libraries hat manitou had provided but the standard Ethernet library that comes with Teensyduino 1.18. Both Paul's and manitous libraries utilize SPI FIFO. To use the higher SPI bus frequency in the "standard" Ethernet library in the utility folder in the W5200 file there is this code for W5100ClAss::Init();
Code:
uint8_t W5100Class::init(void)
{
uint16_t TXBUF_BASE, RXBUF_BASE;
uint8_t i;
delay(200);
//Serial.println("w5100 init");
#ifdef USE_SPIFIFO
SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_12MHz); // W5100 is 14 MHz max
#else
SPI.begin();
SPI.setClockDivider(SPI_CLOCK_DIV2);
initSS();
#endif
if (isW5100()) {
CH_BASE = 0x0400;
SSIZE = 2048;
SMASK = 0x07FF;
TXBUF_BASE = 0x4000;
RXBUF_BASE = 0x6000;
writeTMSR(0x55);
writeRMSR(0x55);
} else if (isW5200()) {
#ifdef USE_SPIFIFO
//SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_24MHz); // W5200 is 33 MHz max
#endif
CH_BASE = 0x4000;
SSIZE = 4096;
SMASK = 0x0FFF;
TXBUF_BASE = 0x8000;
RXBUF_BASE = 0xC000;
for (i=0; i<MAX_SOCK_NUM; i++) {
writeSnRX_SIZE(i, SSIZE >> 10);
writeSnTX_SIZE(i, SSIZE >> 10);
}
for (; i<8; i++) {
writeSnRX_SIZE(i, 0);
writeSnTX_SIZE(i, 0);
}
} else {
//Serial.println("no chip :-(");
chip = 0;
return 0; // no known chip is responding :-(
}
for (int i=0; i<MAX_SOCK_NUM; i++) {
SBASE[i] = TXBUF_BASE + SSIZE * i;
RBASE[i] = RXBUF_BASE + SSIZE * i;
}
return 1; // successful init
}the rest is self-explanatory ;-)
mortonkopf
Well-known member
well, i must be using the wrong library as this line and SPIFIFO are not mentioned, just the DIV lines. Either way, this is plenty fast enough for me. I realised that it is probably my wireless output from the old macbook that is the bottleneck now. As nlecaude showed above, ethernet cable direct to the module and not through the router seems plenty fast enough.
Last edited:
mortonkopf
Well-known member
Attached are the files for artnet to octows2811 using multiple universe. The test file checks to see if artnet is being received and if so, what universe number and sequence number the packages are. The second takes incoming artnet universes and and pushes them out to an octows2811 array. not tested on artnet3. I am not planning on doing any more work on this, as it seems to work just fine for my purposes.
cheers
mortonkopf
EDIT: artnet_octows2811 sketch deleted as superceded and so avoid confusion. Find up to date sketch later in thread. This sketch tests for incoming universe and sends info to serial monitor
cheers
mortonkopf
EDIT: artnet_octows2811 sketch deleted as superceded and so avoid confusion. Find up to date sketch later in thread. This sketch tests for incoming universe and sends info to serial monitor
Last edited:
mortonkopf
Well-known member
I was going to make it easier to use the sketch by removing as much of the defining as possible, so was going to have universeSize used to input to a bunch of variables. I did not get round to doing that, sorry, should have been deleted. The idea was to use this for the array loop functions and thebuffer size functions, etc
mortonkopf
Well-known member
not sure why this is. does universe one never appear, did it appear in the test sketch? What software are you using to output the artnet packets? Because I did not tie all of the inputs into a single universeSize object, you hve to go through a ensure that the object sizes are correct for your output configuration. So, check channel number (needs to be three times led number for the universe), universe number (should match what you have set up in your software), strip length, etc. What led array structure are you using?
I havent got the sketch open to look at, but if your strip length is 60leds, and your universe size is 30leds, your channel number would be 90, you would have two universe per strip. The channel buffer size also needs to be changed. As far as I remember from the docs for artnet, the max data packet size is 512 channels. See comment above to nlecaude about originally wanting to have all this be worked out and done for you by including just the universe size. But this not done yet, so I will need to check to see if number_of_channels stepped in for universeSize in the mean time.
Last edited:
- Status