F4B/F16B and DMX working!

[dkulp]

Just wanted to let everyone know that I managed to get DMX working on the F4B and F16B today!    I wasn't able to use it this year because as soon as I enabled the +Serial version, some of the pixels would "strobe" random colors and such.   I was determined to get it working. 


I spent quite a bit of time this week digging through PRU code, optimizing things, testing stuff, etc...   I think it's now fully working.  I was able to have 4 strings of 100 pixels on each of the 4 F4B outputs and also have DMX running and no strobing or anything.   


I submitted a pull request so hopefully they'll grab  it soon.   If anyone wants to test it now, you would need to ssh to your BBB and run:

Code: [Select]

cd /opt/fpp
sudo git remote add dkulp https://github.com/dkulp/fpp
sudo git fetch dkulp
sudo git checkout -B f4b-dmx dkulp/f4b-dmx

The PixelNet outputs likely need some similar tweaks, but I'm not really sure.  I don't have any PixelNet stuff.

[CaptainMurdoch]

Thanks Dan, I'll definitely be taking a look.  The original library code wasn't really optimized for what we are doing with it, so thanks for taking a look at this.  This will make a lot of users even happier.

[JonB256]

I use both of those devices so I really appreciate the work.

[dkulp]

I managed to do some more testing with this and ran into a couple issues I need to resolve:


1) If no sequence is running or anything, then the serial out code doesn't send anything and the DMX controllers lose the signal.  For controllers that go into a color morph thing when they lose a signal, this is a big problem.  I'll need so find some way of sending blank channels out if nothing has been sent for 250ms or so.   Not sure if this is easier to handle in the PRU code or in the FPP code.


2) F4B isn't working.  I've been doing all my testing on an F16B as both of my F4B's were buried under the snow in my front yard.   Running with it set to "F4B w serial" works fine with the data going out serial port 1 is working perfectly.   I went out and dug out one of the F4B's and tried that and I'm not getting any signal from the DMX port on there.   No idea why yet.   Could be a bad 485 chip or could be code issues or gpio pin issue or soldering issue or..


Also means I need to get another F4B to have for testing...

[David Pitts]

I managed to do some more testing with this and ran into a couple issues I need to resolve:


1) If no sequence is running or anything, then the serial out code doesn't send anything and the DMX controllers lose the signal.  For controllers that go into a color morph thing when they lose a signal, this is a big problem.  I'll need so find some way of sending blank channels out if nothing has been sent for 250ms or so.   Not sure if this is easier to handle in the PRU code or in the FPP code.


2) F4B isn't working.  I've been doing all my testing on an F16B as both of my F4B's were buried under the snow in my front yard.   Running with it set to "F4B w serial" works fine with the data going out serial port 1 is working perfectly.   I went out and dug out one of the F4B's and tried that and I'm not getting any signal from the DMX port on there.   No idea why yet.   Could be a bad 485 chip or could be code issues or gpio pin issue or soldering issue or..


Also means I need to get another F4B to have for testing...

You can have mine. PM me address.

[dkulp]

1) If no sequence is running or anything, then the serial out code doesn't send anything and the DMX controllers lose the signal.  For controllers that go into a color morph thing when they lose a signal, this is a big problem.  I'll need so find some way of sending blank channels out if nothing has been sent for 250ms or so.   Not sure if this is easier to handle in the PRU code or in the FPP code.

Fixed this in the PRU code. 

[JonB256]

Would the "always transmit data" check work? I had to do that on a Pi and FPD because of dmx spotlights.

[dkulp]

Would the "always transmit data" check work? I had to do that on a Pi and FPD because of dmx spotlights.

Possibly, but for this specific case updating the PRU code to detect if it hadn't send anything for 200ms and resend was easy.   Just a few lines of code in an already "busy wait" loop of the code.  Thus, it would have no affect on what's running on the main processor or anything, wouldn't affect power usage/sleeps, etc.....


That said, it's quite likely all the DMX outputs for all the platforms should have something similar in them.   There's a bunch of DMX controllers that don't like losing a signal. 

[CaptainMurdoch]

If I recall correctly, the "Always Transmit Data" option was added specifically for this scenario, but that was before we had the new threaded Channel Output classes.  We could possibly enhance the ChannelOutputBase class to allow a subclass to indicate that its output thread should start at startup and always stay running.  Currently the Channel Output threads are spun up on demand and torn down when there is no output needed (ie, no sequence, effect, pixel overlay, testing, etc.)  I'd want to think through the ramifications though.  Some users may not want DMX output on all the time, they could be relying on the current functionality to put their controller into test mode.  "Always Transmit" could be a flag in the channel output setup rather than a global flag.

[JonB256]

"Always Transmit" could be a flag in the channel output setup rather than a global flag.

I have had a few DMX controllers that would go into test after a loss of signal. Not sure what their setting was and I couldn't control it. Because I had "Always Transmit" checked, I would see an occasional flicker on some Pixelnet controlled lights but the DMX floods stayed dark. (The floods were from Ray Wu and he said he didn't know how to change that test mode setting)

[dkulp]

2) F4B isn't working.  I've been doing all my testing on an F16B as both of my F4B's were buried under the snow in my front yard.   Running with it set to "F4B w serial" works fine with the data going out serial port 1 is working perfectly.   I went out and dug out one of the F4B's and tried that and I'm not getting any signal from the DMX port on there.   No idea why yet.   Could be a bad 485 chip or could be code issues or gpio pin issue or soldering issue or..

OK.  Got the F4B working, kind of.   There is an error in the board itself.  The data in pin of the 485 chip isn't connected to the appropriate pin on the BBB header.  Thus, to get it to work you have to use a short wire or similar to jumper from Pin 25 of the P9 header over to Pin4 of the 485 chip.   Once you do that, the DMX stuff works fine.

[JonB256]

Great troubleshooting. I'll probably solder a wire on the back and glue it down. I have several F4Bs that I might want to use for DMX.

update - might be tough on the back. My F4B boards have solder points on top instead of the header block your picture shows for Pin 25.
On top might be easier.

[Gary]

Does this mean that the F16-B can output Pixelnet AND DMX... at the same time?

[dkulp]

Does this mean that the F16-B can output Pixelnet AND DMX... at the same time?

No... PRU0 is used for the pixel data and PRU1 is used for either DMX or Pixelnet.   

[Gary]

No... PRU0 is used for the pixel data and PRU1 is used for either DMX or Pixelnet.

Okay. I'll keep on using my Lynx USB Dongle...