@karistouf re:artnet set

vvvv beta question
1

Hi Karistouf.

I’m having a problem using your artnet receiver arduino sketch

int packetSize = Udp.available();
if(packetSize==taille_chaine_artnet)//si un packet de la taille de la chaine art-net

The sketch here is looking for a 538 byte packet (taille_chaine_artnet) but whenever I send artnet to the arduino from vvvv, packetSize = 1614 bytes, (which is 3*538) so the sketch doesn’t recognise this as artnet.

Any idea what might be happening?

Thanks for the contribution

2

which is 3*538

hi mrboni, its normal, artnet protocol IS 512 channels only
to send more, you send channel 513 to 1024 to universe 1, for example, thats why universes are presents in fact in artnet protocol
a valid artnet data is only 512 channels per universes invoice. it might be less ( it is written inside the header the number size of packets) but not more

packet size may vary between 25 and 600 bytes

actually 538 is because: 9 bytes UDP protocol ( wich is counted inside arduino lib) / 17 bytes artnet header / 512 chan /

3

Thanks the quick response.

I’m not trying to send more than 512 channels.

I can’t get your sketch to work!

My troubleshooting has got me as far as noticing that the arduino is not receiving the correct packet size from vvvv

4

universe is oK?
you may change is the script the condition from ==taille_chaine_artnet to >25
if you are on a closed network, you may also uncheck a lot of conditions

it was working perfectly last year when i released the sketch with duamillanove and ethernet shield, and arduin 020

actually i m using only arduino IDE 023 because 1.0 is really BUGGY

5

I’ve tried different universes.

The sketch is looking at all universes though?

6

the sketch is listening to artnet header wich is “Art-Net”
then it looks at the universe in byte position 14 and 15

7

“you may change is the script the condition from ==taille_chaine_artnet to >25”

That seems to have worked.

Yes I couldn’t get 1.0 to compile at all. Lots of libraries are broken using it

Thanks!

8

hum, seen vvvv data sended by sneefing with wireshark: 576 bytes. devvvs ? am i missing something ?

9

I noticed that too. Was going to be my next question!

Also, do you have any idea why the arduino would be accepting >1 packet at a time in my case?

10

question is more about reading an incomplete packet.
the data length checking is a good way to filter and wait the package to be completely delivered before reading it. btw same problematic with a reading on rs232 port though ;-)

the device may receive data in buffer from different sources. we are just reading the good universe.

the 10Mbs socket is ok up to 4 universes, but i have a real doubt on the avaibility of the arduino to treat that much. ( reading, receiving, interpretaing artnet universes)

you should do your vvvv artnet sending on a timer, using main loop change information.
this to avoid to block somehow by to much sends the arduino.
with incandescent bulbs and dimmers a good rate will be at 40 fps. with leds better choose 50 or 70fps. ( the incandescent bulbs are having a kind of dampering effect ;-) )

devvvs:
script is working with my whitecat, sending artnet header and 512 channels. this artnet sending is ok with professionnall dimmers, and with artnet compliant interfaces.
VVVV artnet receiver is also receiving it properly.

so why 576 bytes ( but i may forget something … )

art-net.pdf (677.3 kB)

11

Got you. Wait for the artnet header, check value of the 512 universe bytes, then ignore everything after this until the next artnet header.

It is odd that wireshark sees 576 bytes per packet when the arduino clearly only sees 538.

Thanks for the info re: frame rates. Am I right in thinking the dmx standard is limited to 40fps but if you’re just using artnet you can go as high as the hardware will allow?

I’ve been limiting my leds to 40fps as I thought that was an artnet restriction too.

12

hi mrboni, no the fps rate is more related to hardware than anything and is not specified in the protocol.

the 40fps was once upon a time a global admitted value for bulbs to be dimmed smoothly, without steps effects.
with leds, video etc… its something else. commonly 50fps is very nice 100fps is great n but all of this will be more interresting if dimming in 16bits

depends of hardware behind the arduino. what are you exactly controlling in artnet ( if i may ask ) ?

13

I’m controlling leds using these - http://www.adafruit.com/datasheets/WS2801.pdf

14

ok. i m using a cheap IRL for this ( 0,90 euro the mosfet)
https://vvvv.org/sites/default/files/imagecache/large/images/jeenode%20mini%20grada%2012v.jpg

http://www.redrok.com/MOSFET_IRL540N_100V_36A_44mO_Vth2.0_TO-220.pdf

with 12v leds like thoses: http://www.selectronic.fr/reglette-a-leds-nue-61cm-37-leds-bleu.html

thanks to my friend jacques bouault ;-)

so you are daisy chaining in ISP…

about frequency changing on pwm to control and avoid the blinking effect on dimming, i m using SoftPwm and this type of trick for this:

//in setup()
//...
  SoftPWMBegin();
   //frequence 
   TCCR0B = TCCR0B & 0b11111000 | 001;
//...

//in main loop()
//...
SoftPWMSet  (4, rf12_data[2](2));  //D (n° de port du jeeNode, n° d'envoi depuis WCat)
    SoftPWMSet(14, rf12_data[3](3));   //A
//...

what about the system you are using?

15

as gregsn pointed out to me that i wrote that code, i am trying to shed some light on this issue…

i see the following topcis here…

(1) the ardunio might be quite underpowered to receive the amount of artnet a PC can generate in the wink of an eye. The raw processing power of the PC is unfairly higher than that of the Arduino.
This means two things: (a) its important that the state machine in the arduino can really really really deal with lost packets, as in general transmission errors are impossiblt to avoid. (b) In the other side it makes sense to patch the Artnet Sender in a way that vvvv sends only a reasonable amount of packets every second.

Even if DMX has its limits with 40fps (which is not sufficient for smooth fading), its not automatically true that the Arduino can deal with 40 packets every second. This very much depends on the complexity and the cleverness of the programming…

(2) it sounds indeed strange to me if you see 576 instead of 538 bytes in wireshark. Are you sure this does not include any ethernet frames, ip headers? see

This is the structure of the DMX packet as defined in vvvv, which gets sent out to the socket exactly this way.

TMArtDmxPacket  = record
    ID : array[0..7](0..7) of char;
    { ID - Array of 8 characters, the final character is a null termination.
    Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00 }

    OpCode : Word;
    { The OpCode defines the class of data following ArtPoll within this UDP packet.
    Transmitted low byte first. See Table 1 for the OpCode listing.  }

    { Art-Net protocol revision  -  Current value 14.
    Servers should ignore communication with nodes using a protocol version
    lower than 14. }
    ProtVerH : Byte; { High byte of the Art-Net protocol revision number. }
    ProtVerL : Byte; { Low byte of the Art-Net protocol revision number. }


    Sequence : Byte;
    { The sequence number is used to ensure that ArtDmx packets are used in the
    correct order. When Art-Net is carried over a medium such as the Internet,
    it is possible that ArtDmx packets will reach the receiver out of order.
    This field is incremented in the range 0x01 to 0xff to allow the receiving node
    to resequence packets. The Sequence field is set to 0x00 to disable this feature. }

    Physical : Byte;
    { The physical input port from which DMX512 data was input. This field is for
    information only. Use Universe for data routing. }

    UniverseL : Byte;
    UniverseH : Byte;
    
    { The high byte is currently set to zero. The low byte is the address of this
    Universe of data. In DMX-Hub, the high nibble is the Sub-net switch and the
    low Nibble is the Universe address switch. Transmitted low byte first. }


    LengthH : Byte;
    LengthL : Byte;
    { The length of the DMX512 data array. This value should be an even number in
    the range 2 – 512. It represents the number of DMX512 channels received. }

    Data : array[0..511](0..511) of byte;
 end;

and

function TMArtnetDecoder.CreateArtDMX(subnet, universe: byte; dmx : 
    PByteArray	): TMArtDMXPacket;
var
  i : integer;
begin
  fillchar(result, sizeof(result), 0);
  result.ID := cmalArtNetID;  // magic
  result.OpCode := cmalOpArtDMX;
  result.ProtVerH := 0;
  result.ProtVerL := 14;
  result.Sequence := 0;  // no sequence
  result.Physical := 0;
  result.UniverseL := ((subnet and $0F) * 16 ) + (universe and $0F);
  result.UniverseH := 0;
  result.LengthH := hi(512);
  result.LengthL := lo(512);
  for i:= 0 to 511 do
    result.Data[i](i) := dmx[i](i);
end;

…hm… i count 18 bytes of artnet header in the struct above. but perhaps the UDP header is more like 8 bytes :)

(3) on page 2 of the ArtNet spec which karistouf posted there is

…which means it isn´t a good idea anyway to check for the packet length in the arduino code. The better idea is to scan for the magic string and then count the bytes. This would also help if e.g. three packets of Artnet are received in one bunch.

(4) The Artnet nodes in vvvv will always send 512 channels at once, so if you have only 1 LED expect a 512x performance boost if you transfer only one channel with a homebrewn protocol ;)
Note that in a future (better) world, the packet size of the Artnet node could be changed by the user (and in the same science fiction world any device on the world would be compatible with that).

Note also that it is quite straightforward to concatenate an Artnet string in vvvv and send it with the UDP node.

thanks all for your patience,

best

s

16

@karistouf

That is a chunky mosfet!

Yes I’m chaining the ws2801 chips using the spi bus.

They are constant current pwm drivers so each driver takes care of it’s own pwm. The 8bit level is sent over spi then the ws2801 sets pwm.

Someone made me an Artnet - WS2801 controller for a recent project using an mbed lpc1768 but I’m trying to recreate it with an arduino, using your code for the artnet communication.

I really recommend the ws2801 and ws2803 chips. You can daisy chain loads of them. Having artnet control of them is a lovely modular solution for driving a number of leds/motors etc from software.

17

Hi, coming back from winter hollydays

Nice to read you oschatz and yes i must go back to school with udp headers

I will have a closer look to all of this next week

Arduino is enough to treat this amount of data at 50fps
Depends of job to compute after ;-)
The spi is something interresting to check ( limitations of data?, wich amount?)
40fps is ok with filament bulbs, who s filament is dampering nicely
With leds considering 16 bits is the only solution to have perfect fading from extinction to light, slowly

Oschatz i would like go know if in vvvv:

  • you are using the length description bytes, wich is something quite interresting, saying how many channels there is in the packet. It would be a good implementation
  • if you are feeding the frame information, wich is actually the only way to avoid loosed data to arrive and do bad action: sequence is actually at 0. If seq receiving hidded pin was accessible it could be great

I will make tests monday, thanks to you to have taken the time ;-)

Edit: about checking data length in arduino, i m sorry but you need to check the packet size. Or you will loose data by reading an incomplete chain.
Check of length of data is the only way with the arduino low speed to be sure of data integrity.
Thats why i m talking about the 2 bytes giving info about data length

EDIT: 576 learned something today ( very happy) thanks to have pointed to me my error.

done some tests, and definitevely i think the sequence frame number bytes should be implemented ;-)
for smaller projects , not necessary with 512 channels, the size of data also should be fixed from 512 to user customisation: 8 to 512 ? this would really ease things with arduino and atiny ;-)

whats your opinion about it ?

18

ok, i m renewing a little bit this sketch and i make an update in contribution vor a v2 pack.
thanks for feedback.
i m very interrested by achievement of your project in I2C ( never done it) and leds drivers, so if you achieve a kind of wiki about it or a sketch documented i will really have a strong eye to it ;-)

**EDIT:**done: artnet-arduino-set-v2

19

Hi Karistouf, I’ll get some info to you soon about my setup with the spi led chips. Will have arduino code, schematic, and vvvv patch.

First though I’m trying to troubleshoot a problem with the ethernet side. Using your artnet code (or even the udp example sketch from the ethernet library) I experience freezes quite regularly when receiving artnet packets.

I’m experimenting with clearing the udp buffer after every packet read but it’s not quite working yet.

One annoying thing is that using the wiz811mj (I’m using instead of the ethernet shield), Udp.available(); will not return the packet size, but the current length of the buffer. This is why I had the original problem with the packet size check.

I’d be interested to know why you were not having this problem as I thought the ethernet shield was essentially the same as the wiz811mj

20

Hi mr boni, well its rather strange and i think this is more somthing related to librairies versions in arduino core code. The check of length was working in 018 version if i remember well.
Anyway, …

Yes it would be better to flush the buffer.

Are you still experimenting freezes on only one wiz811?

Is the library for i2c ralking to leds daisy chained updated to your arduino version?

Yours, christoph

Have you got an uropean adress i can order it to make tests and see?