DMX Slave Problem 95 Days and making good progress!

[chad]

Hi Ben,

Ok, Got the ws2811 component working. Thank you. One little thing. If you call refresh in a while loop it will randomly blink leds.

DMX, Tried the dmx with ReceiveDataChain in the loop. Still doesn't work.

Thanks,

chad

[Benj]

Hi Chad,

Please post your latest program and I'll do some more testing for you to see what the issue could be.

[chad]

Here is my latest test program.

Chad

Dmxtestnew.fcfx

(12.38 KiB) Downloaded 221 times

[Benj]

Hi Chad,

What value are you getting in the dmx_present variable? I'm guessing it's stuck on 0.

I'll see if I can rig something up here to test it out for you.

[chad]

Hi ben,

Yeah it is stuck on 0. If you need any help setting up something dmx that you can test with let me know. You just need a usb to serial and some free software. Just for testing you don't need the rs485 tx..

Thanks,

Chad

[chad]

HI Ben,

Just checking in...

thanks
chad

[chad]

Hi Ben. Just touching base to see if you have made any progress getting DMX up and running..

Thanks,

Chad

[Benj]

Hi Chad,

Ok in your latest program you call the ReceiveDataChain function but you don't wait at all for the incoming data to start and so it will be very unlikely to sync up correctly. I've edited your program so that it will hopefully work correctly. We now wait for up to 200 milliseconds for the data to start. If the data doesn't start in this time then we very quickly return to waiting for the incoming data.

Dmxtestnew.fcfx

(12.6 KiB) Downloaded 188 times

Let us know how you get on.

[chad]

Hi Ben,

Thank you for looking into this for me.
I tried that and It does the same. nothing. Without being able to look at the code I think that function is designed to just confirm that a dmx packet has been sent. That makes sense. IF your dmx disappears then RecieveDataChain would would wait xxx milliseconds then throw a flag so the program could shut off the led's and do whatever else you want to do when dmx is gone. Most dmx fixtures will on dmx stopping (console shutting down) wait a couple of minutes then go into a shutdown / low power mode. RecieveDataChain, if my assumption is correct, would be better named dmx_present.

Dmx should be coming in at 44hz. 200ms would 5 times a second. Much too slow to be useful.

If you look at the uart pin that the dmx is coming in on, with a scope, the pin state changes. A pin that should be just an input has an effect on the signal coming into it. I have tried every uart, every variable setting for the component. There is something broken in the component code.

Thanks,

Chad

Edit:

I dug into the RX pin transmitting when receiving dmx. When the chip decides to toggle the RX pin on the uart it modulates a 55MHZ signal. This doesn't happen if there is no dmx signal present. It happens once every 10 seconds or so. If I look at the dmx not hooked up to the chip it looks fine.

Also, The program does blink the led about once about every 5 seconds. So RecieveDataChain does occasionally spit out a 1 for a brief amount of time. Far too fast to update the oled display.

[chad]

Hi Ben,

On Sun Nov 04, 2018 11:49 am I first reported a problem with DMX. I was about 15 days into my demo and had reached the point that I was pretty sure that I wasn't doing something dumb. How long do I have wait before it is socially acceptable to be slightly annoyed?

Thanks,
chad

[Benj]

Hi Chad,

Let me look into this today for you. I'll rig up some hardware and see if I can make things sync up a bit more reliably. The DMX sync is quite time critical so maybe I can just back this off a bit to get things more stable. The fact that it is occasionally syncing up is a good sign in that we are very nearly there.

Depending on how things go I can also send you the source for the components so you can have a look and play yourself.

[chad]

Morning, (I 'm up late)

Thanks again. I hope we are close! Considering that the dmx rx uart input pin is periodically sending out a 55mhz square wave I am pretty sure something funky is going on.
I'd love to take a look at the code, I probably have more time to bang on it. I realize that dmx isn't very high on anyone's priority list but it is at the tippy top for what I want to do..

thanks
chad

[chad]

This is a scope capture of the uart RX input pin. The yellow trace is superimposed on the dmx going into the chip.
I am at 10ns per div and it is sending OUT 59.5mhz. My random stab guess is some timer is being set incorrectly initializing the uart?

Chad

DS1Z_QuickPrint1.jpg (237.8 KiB) Viewed 8263 times

[chad]

Ok, last pic.

See the block in the center. I think that should be the start code. The square is the ~60mhz output from the rx input.
The rest of the dmx packet looks like it should coming from my dmx transmitter. Maybe It will help you debug it.. Something is sending a goesouta when it should just be a goesinta.
chad

DS1Z_QuickPrint2.jpg (260.66 KiB) Viewed 8258 times

[Benj]

Hello Chad,

Right I've been testing this using a 8-bit PIC and I've replicated the initial problem you were having. The 60MHz I am guessing is simply noise due to the floating input.

I have now overhauled the components so that instead of uninitialising the UART and using delay based timings I now use the UART hardware itself.

The Master switches Baud rate to 57600 to achieve the break and MAB timings and then switches back to 250000. A new CAL baud has been added to the various CAL UART files to allow for jumping back to the 250000 baud.

The Slave sticks on 250000 baud and looks for a framing error to detect the break and then collects the data as normal.

On the PIC devices this is now working 100% and is very reliable.

I'm repeating the tests now using an ST ARM as the Slave device and currently this is not working. Hopefully I can get to the bottom of why. At the moment it appears the framing error is not being passed back through the CAL though the code looks ok to me.

[Benj]

I've uploaded the various improvements to the update system now so that at least PIC and AVR devices should work correctly.

We will continue to investigate the ST-ARM and see if it is possible to make this play ball nicely.

[chad]

Thanks much for your work. I'm super excited to get this going!

chad

P.s. My friend found this looking at the HAL. Might come in handy for the arm stuff. It looks like you can poll clk freq:

"SystemCoreClock:%u", HAL_RCC_GetHCLKFreq() / 1000000

[chad]

Found a little more on the clock.

uint32_t HAL_RCC_GetHCLKFreq(void)
{
SystemCoreClock = HAL_RCC_GetSysClockFreq() >> APBAHBPrescTable[(RCC->CFGR & RCC_CFGR_HPRE)>> POSITION_VAL(RCC_CFGR_HPRE)];
return SystemCoreClock;
}

[chad]

HI, Any updates?

thanks
chad

[chad]

Just a BUMP!

thanks
Chad

[chad]

Spent a couple of hours trying this again this weekend. Still doesn't work for me.

Chad

[chad]

So it has been 92 days and the component is still broken.

Not what I would consider stellar customer service.

chad

[Benj]

Hi Chad,

I'll ask Leigh if he has time again this week to investigate this further. We certainly have had the UART frame error working on the Nucleo which is required for the DMX comms to function but haven't tested this with the DMX component so this could be a nice next step.

Hopefully we can get this working for you ASAP.

[chad]

That would be great!!!

Chad

[LeighM]

Hi Chad,
DMX on ST ARM now fixed, update should be rolling out soon.
I2C is in progress, there's a few things involved, CAL C code, CAL component and then the target device FCDs
Leigh