DMX on F32-B not working

[nmiller0113]

For the life of me I cannot get the serial / DMX ports to work.  I have everything configured on the BBB strings settings and it's set to DMX and the right channel numbers, but I'm not even seeing DMX running on the port as I can normally see this on my LOR controllers since the status light will go solid.  I've flipped the polarity on the wires to see if it was backwards and I've tried on two different LOR controllers...both of which have worked on F16v2's and v3's over the last 8+ years.

Is there any way of troubleshooting this as I'm at a loss and cannot get any of my DMX elements to work for my halloween stuff...which is killing me.

[JonB256]

You don't mention any DMX to LOR adapters. The RJ45 DMX jacks on the F32-B put Data on pins #1 and #2

LOR requires data to be on pins #4 and #5, so you need to buy or make something to fix that.

The F16s have jumpers to do that. The F32-B does not.

[nmiller0113]

Sorry. I should have been more clear. I made my cables and I am running the LOR controllers in DMX mode. I never used the Jumper for LOR on the f16's.  As you know, the F32 has 4 serial connections per pair 1,2 3,6 5,4 7,8 and I have tried all of them and even flipped the polarity. Also, I've tried another DMX connection, to my fog machine, that I also had working on my F16's last year. The pinouts and cable creation is not something new or foreign to me

[nmiller0113]

Ok, I figured it all out and also shared these details directly with @dkulp in case there are some improvements to be made.  I figured I'd share here so that others can learn from my trial and error

After much troubleshooting and testing, all day Saturday, I figured out what was going on and why...there were a combination of things happening which led to my overall confusion and thought that things weren't working:

First, my understanding of the wire pairs to DMX Interface Number did not go in the order I thought, which I'm assuming could be corrected in code...but I could be wrong.  But then again it could have been intentional:

• Pair 1,2 is DMX 1
• Pair 3,6 is DMX 2
• Pair 7,8 is actually DMX 3
• Pair 5,4 is actually DMX 4

When trying to run Display Testing in Player (Remote) mode it acts funny.  Sometimes it won't actually do anything...sometimes it starts the test but takes a few seconds, and then it won't shut off the display testing until I restart FPPD.  I happened to try a test on a non-remote mode controller and noticed I didn't see the same issue.  I then put the controller I was seeing the issue on into Standalone mode and Display Testing began working as expected.  I assume this may be a bug, or maybe it is intentional

I didn't notice right away but FPP Connect was modifying my DMX channel count to 5 since none of my 4 DMX connections used any more than 5 channels.  When I noticed the change I recalled that some controllers need to see all 512 channels to operate.  I adjusted it and then my LOR Controllers and Fog Machine started working.  I took it even a step further, just because I like to know how things work, and learned that the minimum number of channels my 3 LOR AC and DC controllers needed to see were 10 in order to operate.  In order to overcome the issue in FPP Connect changing my DMX count, I created a couple models in xLights that I called dmxfill which insures I'm always setup for 512 channels

I hope this is helpful to everyone that comes after me with similar challenges.  I also believe @dkulp is addressing some of these as well...maybe he'll comment here but, if not, follow future FPP release notes for anything related

[nmiller0113]

Just an update to this, for everyone's knowledge.  I just stumbled upon another potential bug.  Opened a github case on it.  Here are the details, in case anyone else runs into the same issue:

In a previous issue I was challenged with figuring out which pairs of wires on the RJ-45 Port equate to which DMX port in the FPP interface for the BBB Cape Settings when F32-B (8 Serial) is configured. I noted this here on the Falcon Forums. You'll see that Pairs 7,8 equal DMX 3 and Pairs 5,4 equal DMX 4. I thought things were good until this Christmas when I added an expansion board to differential interface 41-44 (I had to use this interface to avoid GPIO0 for another issue @dkulp and I were working through) and switched my config to F32-B (4 Serial). When I switched that I realized that I had to move my DMX devices to differential interface 45-48, as that's where is moves to in 4 Serial mode. I then noticed DMX 3 stopped working. I did some testing only to find out that DMX 3 and 4 pairs are opposite on differential interface 41-44, than they are on 45-48. I'll show my example below:
Differential Port 41-44:

• Pair 1,2 is DMX 1
• Pair 3,6 is DMX 2
• Pair 5,4 is DMX 4
• Pair 7,8 is DMX 3

Differential Port 45-48 (this one seems like it is the proper mapping based on order):

• Pair 1,2 is DMX 1
• Pair 3,6 is DMX 2
• Pair 5,4 is DMX 3
• Pair 7,8 is DMX 4

I'm assuming this can be corrected in the software for the logical mappings.

[dkulp]

I'm trying to figure out this is possible.      Maybe I need another set of eyes to look at this.

From the pinout burned into the F32-B, the pins assigned for the last two differentials are:

        {  "pin": "P9-25" },
        {  "pin": "P9-27" },
        {  "pin": "P9-28" },
        {  "pin": "P9-29" },
        
        {  "pin": "P9-30" },
        {  "pin": "P9-31" },
        {  "pin": "P9-91" },
        {  "pin": "P9-92" }

From the code in FPP:

    BBBPinCapabilities("P9-25", 117).setPRU(0, 7),
    BBBPinCapabilities("P9-27", 115).setPRU(0, 5),
    BBBPinCapabilities("P9-28", 113).setPRU(0, 3),
    BBBPinCapabilities("P9-29", 111).setPRU(0, 1).setPwm(0, 1),
    BBBPinCapabilities("P9-30", 112).setPRU(0, 2),
    BBBPinCapabilities("P9-31", 110).setPRU(0, 0).setPwm(0, 0),
    BBBPinCapabilities("P9-91", 116).setPRU(0, 6),
    BBBPinCapabilities("P9-92", 114).setPRU(0, 4),

Which seems to match the PRU outputs as defined for the PRU outputs on the beagle specs (Mode 5 for DMX, Mode 7 for Strings):
http://www.embedded-things.com/wp-content/uploads/2013/08/P9.png


So it looks like the code is correct.  Which then leads to the KiCad.   The Pins seems to be labelled with the correct trace:
You cannot view this attachment.

And looking at the traces from the differential chips to the RJ45's, they seem to match between the two DMX ports:
You cannot view this attachment.
You cannot view this attachment.

Thus, I'm really not sure what would cause this unless the Beaglebone documentation is wrong.   But then the question is whether is just the Mode 7 that is wrong or is both mode 5 and mode 7 wrong.