Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

DALI comms link often takes several goes before it works

Status
Not open for further replies.
T

treez

Guest
Hi
We are doing DALI comms with our LED drivers as in the schematic on page 3 of AN1465….
https://ww1.microchip.com/downloads/en/AppNotes/01465A.pdf

The waveform at the RX pin of the micro is as in the attached. (as you can see, rise time is a little slow unfortunately, due to the opto capacitance and pullup resistor)
Many times either the TX , or the RX, or both, (we are not sure which) is not working. Do you think the problem may lie in the slow rise time of the signal ? (as shown in the attached) If so we will reduce the pullup resistor value....but one of the products is very power sensitive , and there isnt scope to reduce it by much.

We send config data to the driver via DALI when in production, and the driver sends back acknowledge data, to confirm what data it “thought” it got sent……..but this RX/TX scheme often fails, ….some units take 4 or 5 go’s before the config process comes up as OK. Its really slowing up our production.
Does anybody know what may be causing this?
The Softy who wrote the config software is no longer with us.

Sometimes when config fails, the driver fails to send back acknowledge data, sometimes it sends back the ACK's but it still fails.....all the units will eventually config correctly, but it often takes several goes.
 

Attachments

  • MAP027.BMP
    378 KB · Views: 93

To me, it looks like a hardware problem rather than software. I'm not sure exactly where you recorded the waveforms but I assume one is from the transmitter and the slower one is at the MCU RX pin. For Manchester transmission to work reliably, the timing has to be right and if the software measures time between transitions it would probably struggle. As a test, try dropping the load resistor on the output side the opto to say 1K. Assuming you are using a 3.3V supply and not 5V as in the data sheet, the opto current will only be about 0.3mA which is much lower than it's specification quotes.

Brian.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
I'm not sure exactly where you recorded the waveforms but I assume one is from the transmitter and the slower one is at the MCU RX pin.
Yes the slower one is the MCU RX pin.

The other is indeed from the transmitter, which in this case was just me "dummying" it with a PIC because i dont know how to do DALI comms......i was just wanting to see that the DALI hardware basically worked and took the DALI rail up and down etc.

- - - Updated - - -

About 14 months ago, one of our DALI comms LED driver products couldnt be dimmed by DALI at all, in spite of the softy doing the DALI software for it......then we asked him to just stop using the DALI libraries, and just bit-bash the recieved DALI dimming signal and then do dimming from there.................in this way, he managed to get all the units responding correctly to the DALI dimming commands.
(As you know, a DALI dimming command is only two bytes, so it was quite easy for him to bit-bash it)
 

Anyone with sense would bit-bang a routine that was capable of sending any data. The principle is the same no matter what the data is so a generic timing routine is all that's needed. The encoding is basically a low then a high or a high then a low, it's the timing between the edges that is important.

Decoding in software is done by looking for the direction of signal transitions and the period between them so a skewed rise/fall time can result in wrong data being decoded.

Try dropping the load resistor on the opto output first, it should speed up the signal edges. If it fixes the problem, at least you know where to concentrate attention toward a permanent solution (if that isn't it!).

Brian.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Thanks, i will try that tomorrow if i am allowed to.
Coming to it, if the problem is really the slow edges, then i wonder if we should just get the software re-written to do it in bit-bang style, and make sure the software takes into account the slow rise time?
After all, this is simply a program which is used during production, to configure the units, not in the field.
 

Are you saying DALI isn't used in normal operation and you only use it for factory configuration?
If so, you are doing it a rather complicated way!

Brian.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Confused :-o
Does it work in the field then? You implied the problem only showed up in production so I'm now confuddled as to whether you believe the problem is in the test rig or the final product.

Brian.
 

If your testbench hardware doesn't comply to the standard, can't you use a standard DALI gateway (e.g. Lunatone USB interface)?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top