Simple lamp dimming protocol needed....with simple software - Page 1
Forum section: electronics / general

author: ocset
author_rank: Super Contributor
timestamp: October 08, 2017, 08:28:12 pm
content: 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?

author: Geoff_S
author_rank: Regular Contributor
timestamp: October 09, 2017, 08:24:12 am
content: Try googling "DALI pwm module". Do any of the hits help ?Quote from: treez on October 08, 2017, 08:28:12 pmYikes...

author: wraper
author_rank: Unknown
timestamp: October 09, 2017, 08:29:20 am
content: DMX512

author: Buriedcode
author_rank: Super Contributor
timestamp: October 09, 2017, 10:33:33 am
content: Microchip have a nice appnote on thishttp://ww1.microchip.com/downloads/en/AppNotes/01465A.pdfDoesn'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.

author: ajb
author_rank: Super Contributor
timestamp: October 09, 2017, 06:55:35 pm
content: 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.

author: Nusa
author_rank: Super Contributor
timestamp: October 09, 2017, 07:25:12 pm
content: 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.

author: dmills
author_rank: Super Contributor
timestamp: October 10, 2017, 06:11:42 pm
content: 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.

author: ocset
author_rank: Super Contributor
timestamp: October 11, 2017, 07:42:34 pm
content: Thanks, hopefully many thousands.QuoteThanks, i thought floating input pins were noise sensitive and create problems?

author: Nusa
author_rank: Super Contributor
timestamp: October 11, 2017, 08:49:22 pm
content: Quote from: treez on October 11, 2017, 07:42:34 pmThe 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.

author: dmills
author_rank: Super Contributor
timestamp: October 11, 2017, 09:35:18 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: October 11, 2017, 10:01:28 pm
content: 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 phaseThe 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.

author: Kjelt
author_rank: Super Contributor
timestamp: October 11, 2017, 10:05:35 pm
content: Quote from: blueskull on October 11, 2017, 09:53:59 pmLooks 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

author: hermit
author_rank: Frequent Contributor
timestamp: October 11, 2017, 10:18:43 pm
content: Quote from: Geoff_S on October 09, 2017, 08:24:12 amhttps://www.eevblog.com/forum/jobs/https://www.eevblog.com/forum/work-wanted/

author: julianhigginson
author_rank: Frequent Contributor
timestamp: October 12, 2017, 04:34:53 am
content: 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?

author: Kalvin
author_rank: Super Contributor
timestamp: October 12, 2017, 05:27:41 am
content: Always require full source code for the firmware and working toolchain. No source - no contract.

author: Kjelt
author_rank: Super Contributor
timestamp: October 12, 2017, 05:39:57 am
content: Quote from: blueskull on October 11, 2017, 10:52:21 pmI 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.

author: ocset
author_rank: Super Contributor
timestamp: October 12, 2017, 07:09:57 pm
content: QuoteThanks, 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.?

author: Nusa
author_rank: Super Contributor
timestamp: October 13, 2017, 12:41:49 am
content: Quote from: treez on October 12, 2017, 07:09:57 pmUnconnected 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: October 13, 2017, 09:22:49 am
content: 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%.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 13, 2017, 09:58:04 am
content: Quote from: treez on October 08, 2017, 08:28:12 pmThen you cannot afford products with software, right now. Change that.Quote from: treez on October 08, 2017, 08:28:12 pmhttp://www.eucontrols.com/XV3-10001.html