Posts by shawn

Because DMXControl Projects e.V. will be affected by article 13 of the new copyright act of the EU, we participated in actions for the #SaveYourInternet movement. Therefore, all of our websites were offline at March 21, 2019 for 24 hours. See Directive on Copyright in the Digital Single Market

    I've just released v3.0.0-alpha of my TeensyDMX project. The CHANGELOG describes what's changed, but here is a summary of the major features:

    1. Direct hardware access and optimized buffering.
    2. Everything happens asynchronously, but there are ways to use the library in a synchronized manner.
      • The Sender can be stopped and resumed, and the Receiver can have custom responders/handlers for packets having any start code.
      • All of this means that packets of any type can be sent, received, and responded to. For example, the library, with this functionality, supports adding support for SIP, Text Packets, and RDM.
    3. Sender: Settable refresh rate and packet size.
    4. Receiver: Packet timing awareness and error counting.

    Do let me know of any bugs or problems you find.

    I wrote some DMX code that runs on the Teensy, here: TeensyDMX.


    My next major commit will be providing the ability to add custom responders that respond to any specific start code, for example RDM or those specified in Annex D of ANSI E1.11. To test this, I've implemented an RDM responder, because I believe a great way to test your own code is to use it.


    I believe my API is complete, but I wanted to know what sorts of things embedded developers might find useful in a DMX (or RDM) API that's not designed as a complete project, but to be incorporated as a building block into a system.


    Right now, it:

    1. Can change the refresh rate.
    2. Can change the transmitted packet size.
    3. (soon) Can be able to provide custom responses to non-zero (alternate) start codes.
    4. Has a goal of being a very simple but very capable API. For example, there's no need to remember to call some update method in loop(), just set or retrieve channels as you need.
    5. Does its own serial port management via ISR's; all data goes directly into the DMX buffers for reading or writing. No buffers to manage by the developer.

    Also, what are your RDM needs? Right now, I have these implemented (plus all the required ones) with what I believe is a simple API for filling in, for example, your own sensors or manufacturer-specific commands:

    COMMS_STATUS, DEFAULT_SLOT_VALUE, DEVICE_LABEL, DEVICE_MODEL_DESCRIPTION, DMX_PERSONALITY, DMX_PERSONALITY_DESCRIPTION, MANUFACTURER_LABEL, PRODUCT_DETAIL_ID_LIST, REAL_TIME_CLOCK, RECORD_SENSORS, RESET_DEVICE, SENSOR_DEFINITION, SENSOR_VALUE, SLOT_DESCRIPTION, and SLOT_INFO.


    Right now, I'm just doing this for fun because I like to "exercise" by writing protocol things, so this may not be a fruitful endeavour. I'm just trying to take the pulse of the needs of those trying to build embedded DMX-based systems.