2

I'm creating a library designed to send UDP packets over a local network to a string of 100 ArtNet3 compatible DMX controllers.

I have ArtDmx packets sending and rendering successfully. Now I'm attempting to pre-buffer the data in the DMX controllers to help out with network delay. The documentation says to send an ArtSync packet to tell the controllers to render the previously received ArtDmx packets, which is what I've implemented. I am also sending one ArtSync packet before the ArtDmx packets to tell the controller to buffer the data instead of rendering them. These ArtDmx packets have their sequence property filled with a per universe/controller incremented value starting at 1.

The problem, I think, is that the OpCode is not being recognized. When I watch the traffic with Wireshark, the ArtDmx packets' OpCode is recognized as 'ArtDmx (0x5000)'. The ArtSync packets on the other hand are showing up as 'Unknown (0x5200)', even though the value matches the documentation . Is there something I'm missing? Here is the documentation.

aj.toulan
  • 1,341
  • 1
  • 16
  • 25

1 Answers1

0

I believe that my version of WireShark simply doesn't support ArtSync operation codes, and is inevitably irrelevant. It could be that WireShark only nativally supports an earlier version of ArtNet, perhaps ArtNet or ArtNet 2, which may not support the feature. ArtNet3 was developed specifically for larger networks displays.

As fare as buffering goes, it could be that I misinterpreted the ArtNet 3 documentation.

When a node receives an ArtSync packet it should transfer to synchronous operation. This means that received ArtDmx packets will be buffered and output when the next ArtSync is received.

Where is says that "[...] recieved ArtDmx packets will be buffered [...]", is grammatically correct when referring to multiple controllers, when pluralizing 'packet', but incorrect when referring to one controller. The ArtNet3 compatible controllers I'm using will only render the last ArtDmx packet sent once I send the ArtSync packet.

aj.toulan
  • 1,341
  • 1
  • 16
  • 25
  • It's amazing how one character can completely change the meaning of a feature description. Nevertheless, I have 100 controllers running at 50+ frames per second. Sending the data in reverse order also helped a lot, so the packets for the controllers at the end are sent first so all the data gets to where it's going at basically the same time. – aj.toulan Nov 04 '15 at 17:30