DALI 2 / Manchester encoding using UART

[Maggie]

Hello,

I am looking at starting a project that requires sending a small and limited amount of data over a network to multiple devices or nodes over 100m+ of cable. Maybe just as a broadcast message to all nodes.
They do not really need to have unique ID's as the nodes would act as receivers only (Maybe).
I have been looking at the DALI 2 interface which seems to be fairly robust and easy to implement from the actual circuit / physical side of things but the coding appears complex to ensure it is DALI2 compliant.

However, I do not need this to be DALI2 compliant but to simply transmit a few bytes (From a master) once or twice a day to multiple modules all at the same time. The nodes or modules do not need to respond back, although that might be nice, but then the slaves or nodes would require network addresses if they did.

Some PICs have a DALI control module and a Manchester code module (UART). My question really is does Proton Basic support DALI2 and or Manchester coding over a DALI network? Now of course it can be done at a lower level using the PIC DALI module (UART) but really I just need a very simple cut down version just to send a few bytes to multiple modules but in an hash environment next to other power cables.

Thought I just ask on here to see if this project has some potential or if it is something that perhaps is not worth the hassle and development time.
Has anyone here played withe DALI2 / Manchester encoding using the UART to manage the data coming in. DALI2 / Manchester coding requires critical timing to detect the bit changes but but does the URAT take care of this when using PICs with DALI URART control modules? I am sure it does but before I dive into this as such, it always good to see what issues problems other have come up against.

I have been reading data sheets and looking at many options but to hear first hand from other Proton users is always a nice place to start

Thanks

[John Drew]

Hi Maggie,
Did you consider just using RS485 and ethernet cable and a checksum and send the data two or three times from USART.
I've used 9600baud TTL over ethernet for a 100 metres as an experiment in an RF field without loss of data.
I appreciate my situation was non commercial.
John

[Maggie]

Hi John,

Thanks for your reply.
Sorry for the long answer and waffle coming up.....

I have considered almost everything form CAN  to just AC relays each end and most other things in between including fibre links and RS485 using either my own protocol or even MODBUS or another building management system.
Although RS485 is very easy using the PIC UART, the issue is that because each module or node has a 3 phase supply going into it and the network is over a long distance, with at least 32 modules (Min acceptable), one of the requirements is that the data side / bus must be isolated. Now, that's not a difficult thing to achieve but it puts the cost up. Plus for RS485 I would think its needs isolated anyway due to unwanted ground loops etc. All this will also be in a noisy environment. The bus or main cable line will be a 100m cable with each node joining the bus by a 5m cable.

What I do like the look of and have been testing here is using digital industrial inputs, like a PLC input. The MAX22191 device (have a look, its a great small chip) is a low cost, easy to use single input and its output can be isolated by a optocoupler but also takes it power form the bus (parasitic). And at around 2.4mA current is nice and low. The MAX22191 accepts a 24v binary input (-60 to +60 Tolerant).

I need to transmit only one of 16 codes to all nodes at the same time. So having 4 inputs would give me that. But I would then need to drive the 4 lines (24V/0V per channel = 8 wires) from some sort of high side or push pull line driver from the master. The data will only change maybe twice each day so its not fast data as such just switching 4 inputs to give 1 or 16 options at each node.

The downside to this is that the cable needs to really be 8 core and maybe shielded, and then their is the problem of connecting each of 4 channels to each node. I suppose I could even have four DPDT relays driving the channels, by either switching 24V or 0V on each line. As the MAX22191 is a 24V digital input IC, would driving 32 (or more) together cause an issue? Effectively, all 32 inputs would be in parallel.

I like the DALI 2 network, because its very robust next to mains cables and uses only 2 wires (Twisted pair?). The DALI interface is simple its just the firmware that may cause an issue.

That's when I thought about just having my own protocol / commands using a simple DALI 2 interface but using the Manchester coding with one of the PICs that has the Manchester coding supported UARTs.

If possible I would prefer if each node was only a receiver so it does not have to have an address. Although it would be nice to have half duplex data to report back issues and to confirm reception of data.
Another option maybe is instead of each node being on a bus the first node can simply receive the data form the controller and then retransmit it out on another socket to the next node and so on. This would remove the node limit and and not need an address and be half duplex.

All interesting, but I would like to use either 4x MAX22191 Ind. inputs, RS485 or a DALI 2 bus using my own Manchester protocol, all though I will consider anything and everything else.


Thanks.

[Giuseppe MPO]

This might interest you:

https://www.microchip.com/content/dam/mchp/documents/OTH/ApplicationNotes/ApplicationNotes/TB3201-Implement-DALI-2-Transceiver-90003201A.pdf


Greetings Giuseppe

[John Drew]

Thanks Maggie for the detailed explanation. I understand at a basic level the complexities of an industrial environment but not enough to speak wisely.
Your reply boosted my knowledge. Good luck with the project.
John

[Maggie]

I have been reading more data sheets and also the App note you linked to above, which was very interesting, thanks.
I might be wrong but to me and the way I understand this that Dali uses Manchester encoding (One of its forms anyway) but of course the data structures and framing are laid out by the DALI standard ( IEC62386).

So, my question is that if I use a DALI physical interface and network (Which seems pretty straight forward) and I use a PIC with UART that has Manchester encoding then I can simply send my own bytes across the network, which should be as reliable as the DALI network. As I do not need it to be DALI compliant and I only need to send one of 16 bytes a few times each day, It should be fairly robust? I could also add a CRC or some other checksum. And as I only need to send data and not receive it, I could simply send the same data maybe 5 times when a change is made with a few seconds in between. Maybe also send the data say 3 times and the receiver only acts if all three transmission are the same and the CRC or other checksum is correct.

From what I have read a UART with Manchester encoder would take care of all the timing and coding leaving me with just the received data, is that right? If that is the case, then not only do I end up with a reliable, robust twisted pair differential bus that's opto-isolated but a coding scheme that's may be more reliable than than just send 'normal' asynchronous data, as to me the way the Manchester coding represents the bits (Effectively with a built in clock within the data) would be a reliable method to simply send data to over a two wire isolated bus in a noisy environment.

Now I just need to find a supported PIC with a Manchester UART that's actually available for making some sort of bench prototype.
And of course I need to now learn about using a PIC UART with Manchester encoding.

If anyone on here has used a UART with the Manchester code support, it would be good to hear from you with any advice or issues that you had.

Thanks again.

[JonW]

Take a look at this video, it shows how Manchester code can be achieved using a PIC

[top204]

Manchester encoding/decoding can be a lot more complex than the high-low and low-high for 1s and 0s. It can also be created to extract a clock pulse from the transitions, because every bit has a transition and each transition is the same time length. I created a simple demo in the "C:\Users\User Name\PDS\Samples\Proteus\" folder for the Positron8 compiler, quite a few years ago, that implements a simple form of manchester encoding/decoding, but the forms that also create the clock pulse can also be created easily with the compilers with a bit of research.

I think TimB did something similar quite a few years ago for an interface he was creating.

[xldaedalus]

If reliability is important, its hard to beat RS485, even if you are bit-banging Manchester.  You can use it like any other async serial communications.  Youd on't have to use an special packet structures, or checksums, although these things will increase reliability. You can use UART interrupts for sending and receiving.  You could probably acheive > 115,4Kbps. I prefer using 5v to power the transceivers, even if I'm using 3.3v MCU, I add level shifters to the data lines.  The number of nodes is a function of the RS485 transceivers you use 32 is common, you can buy 64, 128 and 256 node transceivers.  Good costs more.  I'd use 64 node transceivers if you know you have 32 nodes right now. Isolating the RS485 will add at least $10-15 per node to your project, more if you buy the prefab RS485 Isolation.  It's a question of what is the cost of failure?  If this is a professional situation, whose equipment you will not personally have control of, I wouldn't do it any other way - for unsupervised safety and reliability.

[Maggie]

Thanks for your replies.

Sorry for the long reply......

Actually, RS485 was my first choice for all those reasons, but as this project will sit in an industrial environment and the the slave will run on a 3 phase 415V system with lots of power cables around going to each slave or node, I would need a fully isolated 485 network, as testing time is limited, I decided against it. Of course its nice and easy to use the Proton and a PIC EUAST for 485. The good thing is that I only need to send a few bytes of data maybe two or three times a day. The speed can be very slow, maybe even 9600 or 1200. As I do not need a reply from the slave devices I only really need to send a broadcast message as such so all slaves on the network can receive the data and do what they need to do.

Basically I need to transmit 1 of 16 options to all the slaves a few times a day, so even just one byte would work, but I could have some sort of CRC or checksum and maybe a start and end byte or command. As each slave will not need an address I can simply resend the message a number of times, maybe 5 times over 5 seconds and repeat it 5 times every 60 seconds, then stop sending. All slaves could simply only act on the data if certain rules are met, such as receiving the same data 3 times in a row for example.

It would be nice to have a slave address for each and the master to talk to each one in turn, but as their will be many repeat networks of 32 slaves in one installation, managing the addresses and for each individual network becomes a bigger issue, plus the customer needs to be able to simply swap or replace slave units without any configuration of addresses etc, simply plug in and turn on. This is why I thought sending a broadcast message, as I do not need to assign addresses and manage it. I suppose I could have some other automatic method to assign an address on start up. Maybe program the PIC with an unique ID when they are programmed, maybe in the first two bytes of EEPROM for example and simply request a response from each address to see if its present.

The total length of the main network will be around 100m, with maybe a 5m stub cables coming off to feed each slave. However that's a massive issue in itself, It may be far better for the network cable to got to each slave then direct to the next.

Also, their seems to be a lot of conflicting data about the type of cables, screening, connectors and the physical side of a network, which also needs to be waterproof to at least IP65 or 66.

One of my thoughts, which is a bit messy, is to use a 4x MAX22191 IC (Industrial Digital Isolated 24V Input at 2.4mA) and have 4 binary digital inputs on each slave. Have all 32 slaves in parallel simply, daisy chaining from one to the other. Then have the master switch a 24V isolated supply for each of the 4 inputs lines, giving me the 16 options I need. The MAX2219 and an opto seems robust and low cost and would be quick to get working. Its just a case of how to supply a 24V signal to each of the 4 lines. Maybe a simple relay switched supply, or perhaps a high or low side line driver or even a push-pull line driver so each line is never left floating and would either be 24V or 0V.

Anyway, sorry for all the waffle, especially that this is not directly related to Proton as such, but Proton will be used for all of the code.

Thanks

[Maggie]

Ah, just realised that I have more or less just repeated myself, sorry!