Simple lamp dimming protocol needed....with simple software

[ocset]

Hello,
We make dimmable lamps.  However, we can’t write DALI software, and rely on external  software engineers to do this for us. We realise that just about everything is DALI in lighting, ..if we don’t do DALI, then we can’t sell anything.

Do you know of a simple lamp dimming protocol which is much simpler than DALI to implement in software?    (then we could write the lamp dimming code ourselves) For example, it could receive say DALI commands from a ‘master’ via a radio link, and then give out a  simple 0-10V signal to request the dimming. We would then be capable of writing software to dim the lamp in accordance with the 0-10V signal. We could write this code ourselves. We are software numpties  but we could muster  up the small bit of code skill  needed for this.

At the moment , we rely on an external engineer to write our DALI software for us,  because we ourselves cannot manage the DALI software. However, this software engineer is  undoubtedly sabotaging our software.        

Multiple times, on   multiple products, he declares huge numbers of non connected micro pins as inputs…and doesn’t  enable internal pullups.  He does multiple other similar things.
We found this  out after 4 months of a certain product  either not working or working intermittently. The software engineer, for 4 months, repeatedly blamed our hardware, saying it was noisy and causing the micro to fail… (this was nonsense because the hardware worked fine with our own simple software) …in 4 months he never once mentioned his declaration of multiple unconnected pins as inputs……it took us, after 4 months of pulling our hair out , to go trawling through his code and realise that he had done this to us.       

Then on a few other products, he did the same again. Recently he declared 30 unconnected pins as inputs.  He has given explanations for our products not working which we have proved to be incorrect…and proved it was his software that was at fault.
He is the only software engineer we can afford. 
If we don’t find a simple way to implement DALI, or a different, simpler comms protocol for the dimming commands, then we will go bankrupt.

 

Do you know of anything?
Our software engineer is the grim reaper waiting to destroy us….goodness  only knows what bugs  and Trojans he has put in our software which will make the lamps fail in x  years time. Please help. SOS.

If we could buy an off-the-shelf  unit which received DALI dimming  commands, and  then chucked out a nice 0-10V signal for us..something like that? 

[Geoff_S]

Try googling "DALI pwm module".  Do any of the hits help ?

He is the only software engineer we can afford. 

Yikes...

[wraper]

DMX512

[Buriedcode]

Microchip have a nice appnote on this

http://ww1.microchip.com/downloads/en/AppNotes/01465A.pdf

Doesn't seem too difficult, but depends on what devices you are using.  For Manchester encoding the CLC modules are very handy, because one can just use the SPI with it for both transmission and reception.  At 1200 baud bit banging is always an option.

[ajb]

DMX is dead simple to implement on the receive side, and maybe has a reasonable chance at being a usable option in architectural installation--It's not that uncommon to see stage lighting fixtures used in architectural lighting, so probably there are DAL-DMX bridges available, and if not, there are certainly architectural controls that can do DMX.

At the end of the day, though, if, as you say, you can't sell anything without DALI, then there's not really a substitute, is there?  If you can't abide your current developer, and can't afford a better one, then it seems like your only option is for someone at your company to figure out the DALI code yourselves.

[Nusa]

If your current software developer doesn't produce useful product then you cannot afford him, no matter how cheap he is. It doesn't matter whether it's incompetence or sabotage, as you have clearly lost confidence in his ability to produce results. Find another resource or solution.

[dmills]

Treez, you got to declare the pin directions as SOMETHING! And an unused pin strapped as input is generally less of a problem then an output when setting IO directions.

How the hell have you ended up with nobody in house who can tackle simple C programming tasks? I would have thought that was pretty much a given for a hardware development company these days!

DMX is simple, but you would need a way to set the fixture address and some RS485 hardware, also it is mostly seen in entertainment applications, and unlike DALI the bus is not merely functionally isolated from the mains...

DALI does not look particularly complex actually, a smallish PIC or such, a couple of opto isolators, maybe a bridge rectifier to make it polarity agnostic, I might add a 24V transorb or something just on general principle.
It is is 1200baud manchester code with a dozen or so commands, not exactly hard to process if you have a hardware timer or two available.
You would want something with some eeprom or internally programmable flash to store the address, but that is no problem these days.

I am not totally convinced that I could stuff DALI into an 8 pin processor, but something in a 16 pin package should be no biggie.

How many thousands of modules a year are you prepared to commit to?

Regards, Dan.

[ocset]

Thanks, hopefully many thousands.

Treez, you got to declare the pin directions as SOMETHING! And an unused pin strapped as input is generally less of a problem then an output when setting IO directions.

Thanks, i thought floating input pins were noise sensitive and create problems?

[Nusa]

Thanks, hopefully many thousands.

Treez, you got to declare the pin directions as SOMETHING! And an unused pin strapped as input is generally less of a problem then an output when setting IO directions.

Thanks, i thought floating input pins were noise sensitive and create problems?

The classic digital input problem is when someone uses a single-pole switch to pull a pin high when it's closed, and left to float when it's open. Or vice versa. The classic solution to that is pull-up or pull-down resistors, either internal or external.

However, if the program never actually reads and uses a simple input-configured pin, the validity of the input on it generally doesn't matter.

[dmills]

The only time it really matters is if you are gunning for absolute lowest power consumption (A floating input can cause cmos to draw a little more power, think applications running for years off coin cells), or when some numpty has not masked things correctly in the program.

On the other hand a pin configured as input will not misbehave if strapped to power or ground, one configured as output very well may.

Regards, Dan.

[Kjelt]

Reading your opening post you are stranded in the HW-SW interface nightmare.
Because you have little SW knowledge you blame the SW engineer that blames the HW.
That is not going to work.

Ask the SW engineer the following questions to see if he is legit or just trying to make it work:
- do you have access to the official DALI specification for the specific driver type (led, fluo, hid all have different specs to meet)
- how do you handle the Dali signal: flank based or oversampling, and if so how much?
- how do you solve the randomness generator for the commissioning phase

The HW engineer should answer the following questions:
- How much mA can the DALI driver sink
- can the driver and DALI interface survive 230V mains connected on the inputs?

Although DALI is pretty simple and straightforward the problems are in the details. Many a-brand DALI equipment fails to work between brands because there are many timing issues that could go wrong.
If you are a small company you might rather implement dmx or 0-10V interface.
Although there are dali to other protocol bridges those are costly and not opportune to put in front of your lamps (€100 to €200 for a bridge is normal).

You say you make dimmable lamps, you mean the lightsource or also the fixture. There might be more money to be made to build entire fixtures and buy the €40 dali led drivers from reputable manufacturer but i dont know enough of your business case.

[Kjelt]

Just took a look at DALI standard and it seems it is not that hard to implement with a timer. Maybe you can try to read the spec and see if you can get it done? Or hire an undergrad EE/CE student?

DALI standard is not free, but I found a pirate copy here: http://www.docin.com/app/p?id=301606462.

Looks can be deceiving. Three to five man months SW and two months of multi brand interface testing if you don't want to end up with angry returns from customers because itbdoesntbwork with the hunglo controller they bought 

[hermit]

Try googling "DALI pwm module".  Do any of the hits help ?

He is the only software engineer we can afford. 

Yikes...

https://www.eevblog.com/forum/jobs/
https://www.eevblog.com/forum/work-wanted/

[julianhigginson]

If they are inputs but never read in the code, where's the problem? Or is he also connecting them to interrupts accidentally?

Also who is picking micros with 30 spare pins for your product that just go unused? maybe you need a new hardware designer, too?

[Kalvin]

Always require full source code for the firmware and working toolchain. No source - no contract.

[Kjelt]

Just took a look at DALI standard and it seems it is not that hard to implement with a timer. Maybe you can try to read the spec and see if you can get it done? Or hire an undergrad EE/CE student?

DALI standard is not free, but I found a pirate copy here: http://www.docin.com/app/p?id=301606462.

Looks can be deceiving. Three to five man months SW and two months of multi brand interface testing if you don't want to end up with angry returns from customers because itbdoesntbwork with the hunglo controller they bought 

If you can afford a legit copy if DALI spec and membership, they provide a test sequence suite.
If your product passes DALI official test and for whatever reason a controller doesn't work with it, then the controller is likely to be the one to be blamed.

I know, if you are not a member I think you are not even allowed to use the DALI symbol on your product ergo it is NOT a DALI compliant product.

[ocset]

On the other hand a pin configured as input will not misbehave if strapped to power or ground, one configured as output very well may.

Thanks, though do you believe that a totally  unconnected pin,  if declared as an output, would be totally harmless and not result in any extra power loss.?

[Nusa]

On the other hand a pin configured as input will not misbehave if strapped to power or ground, one configured as output very well may.

Thanks, though do you believe that a totally  unconnected pin,  if declared as an output, would be totally harmless and not result in any extra power loss.?

Unconnected GPIO pins would be harmless if not utilized by software. Any configuration-related power losses would be insignificant, except in extreme low-power scenarios which are probably not relevant to your situation.

[donotdespisethesnake]

In my experience, I would be wary of making generalised recommendations. The nature of IO pins varies greatly, as well as the type of process used for the chip, and noise immunity of the internal design.

In benign conditions, you can set unused pins to input or output and it will make no difference (the normal default power up state is almost always input with pull ups disabled). However, if high reliability or noisy EMC conditions are expected (industrial or automotive environments), pay careful attention to recommendations in the data sheet. Protections will depend on the nature of the IO pin. In most cases, an external pullup or pulldown should be used to ensure correct state of the pin. There may also be rise time requirements.

For robust industrial use, you need protection well beyond what is recommended in the data sheet. For example, we test to exceed ESD levels required by IEC 61010. We also ensure any external accessible IOs are immune to accidental connection to supply voltage (24V).

In extreme EMC cases, you may find the MCU cannot operate inside design parameters, so look for additional application notes from the manufacturer regarding high reliability. For example, we found the internal PLL works fine for all our products except on one product. In some EMC conditions the PLL can lock up. After consulting the vendor, we found some ways to in software to detect PLL faults and recover, but we opted to implement a hardware design that bypassed the PLL completely.

Also in my experience, you need software guys who at least have an appreciation of hardware issues and can work with the hardware designers to implement robust designs, and resolve issues encounters. The hardware designers need to be open to suggestions by the software guys. There is some truth to the adage "you get what you pay for", I see a lot of very cheap freelance contractors available, but I doubt whether they have the experience or willingness to resolve hard reliability issues that fall in the gray area between hardware and software.

The time and effort required to implement robust embedded solutions is usually woefully underestimated, there are many things that should be designed and tested which are rarely made visible as explicit requirements. For desktop or web applications, it is relatively easy to roll our new versions of firmware. For embedded systems, that is often impractical or impossible, the only option is a hardware swap out which is expensive and inconvenient. Achieving 99.99% reliability for 24/7 systems (< 1 hour downtime per year) takes a lot more effort than 99%.

[Jeroen3]

He is the only software engineer we can afford. 

Then you cannot afford products with software, right now. Change that.

If we could buy an off-the-shelf  unit which received DALI dimming  commands, and  then chucked out a nice 0-10V signal for us..something like that? 

http://www.eucontrols.com/XV3-10001.html