DCS-BIOS over RS485

I don't understand.  What "return wiring"?

I also don't understand how "train line" would be more wiring than "spider web". It's a "branch line". It goes one way.

Another name for train line would be "daisy chain".

The RS485 bus goes from one panel to the next, then you put a terminating resistance on the end farthest from the master.

Or, run a long bus with "tap point" connectors to plug in your panels.

The 'return line' would be because the cockpit is essentially a 'U' shape, with the master behind the dash middle of the 'U'. That means the line would go all the way to the end of one console, then return back to the center of the 'U' before going to the other console

Does that make sense?

Cheers

Les 

Have you already tried to use the second and/ or third RS485 bus of the Mega?

Naturally the master sketch has to enable that setup.

So one bus line could go to each side console and the third bus may be used for the Main panel.

Regards, Vinc

Errrr, no...... 'cos I didn't know I could do that!

So, if I understand what you are saying correctly, I can connect 3 MAX487 chips to the Mega on the TX/RX1, TX/RX2 and TX/RX3, and have one 'network' for each part of the rig?

Les

You could also run a long USB cable to the master at the back end of the left console and run the bus all the way round ot the back of the right console.

Or run 3 separate masters at the main panel end.

I have the hardware to do all four of those options

The question is, which is the best in terms of least lag / dropouts / conflicts?

5 hours ago, lesthegrngo said:

So, if I understand what you are saying correctly, I can connect 3 MAX487 chips to the Mega on the TX/RX1, TX/RX2 and TX/RX3, and have one 'network' for each part of the rig?

Les

Yes, it is intented to do exactly this.

But I haven't done so yet.

Extract from the master sketch:

/*
If you have less than three transceivers connected, comment out the corresponding 
#define UARTn_TEXENABLE_PIN lines for receivers that are not present.
*/
#define UART1_TXENABLE_PIN 2
#define UART2_TXENABLE_PIN 3
#define UART3_TXENABLE_PIN 4

Regards, Vinc

I will try it; why not! I hope that it doesn't give memory allocation issues or suchlike but there is only one way to find out. Tomorrow I will make a PCB shield for the mega with three MAX478 chips and connections and see how it goes

Cheers 

Les

Guys, pretty certain that the answer is yes, but want to check before committing to cutting PCB's - the TXEnable pin can be any pin I choose, right?

Cheers

Les

Yes. Usually pin 2 as it's next to 1 and 0.

If you're using more than one branch, you'll need a TXEN for each.

Thanks for confirming

Due to my limited production methods I have to have the TXEnable pins in reverse order so that I can lay out the traces without having to make a more complicated double sided PCB

Cheers

Les

Could always use link wires. 

PCB cut and populated already, nice and neat. Just got to modify the sketch and try it now

Cheers

Les

Guys, looking at the DcsBiosNgRS485Master.h file in the library, it shows the following lines

#define UART1_TXEN_PORT PORTE
#define UART1_TXEN_DDR DDRE
#define UART1_TXEN_PIN 4

#define UART2_TXEN_PORT PORTE
#define UART2_TXEN_DDR DDRE
#define UART2_TXEN_PIN 5

#define UART3_TXEN_PORT PORTG
#define UART3_TXEN_DDR DDRG
#define UART3_TXEN_PIN 5

It is calling out pin 5 twice, but also it is in conflict with the sketch which also defines the TXEn pins

I will be setting up as follows

TX1 / RX1 will use pin 4 as TXEn

TX2 / RX2 will use pin 3 as TXEn

TX3 / RX3 will use pin 2 as TXEn

I assume that I do not have to make any more references that defining the TXEn pins in the sketch in the following bit of code

#define UART1_TXENABLE_PIN 4
#define UART2_TXENABLE_PIN 3
#define UART3_TXENABLE_PIN 2

and the UART1 will be allocated by the library sketch definitions with this part of the code, right? 

#define uart1_txen_setup() UART1_TXEN_DDR |= (1<<UART1_TXEN_PIN)
#define uart1_set_txen() UART1_TXEN_PORT |= (1<<UART1_TXEN_PIN)
#define uart1_clear_txen() UART1_TXEN_PORT &= (1<<UART1_TXEN_PIN)

#define uart2_txen_setup() UART2_TXEN_PORT |= (1<<UART2_TXEN_PIN)
#define uart2_set_txen() UART2_TXEN_PORT |= (1<<UART2_TXEN_PIN)
#define uart2_clear_txen() UART2_TXEN_PORT &= (1<<UART2_TXEN_PIN)

#define uart3_txen_setup() UART3_TXEN_PORT |= (1<<UART3_TXEN_PIN)
#define uart3_set_txen() UART3_TXEN_PORT |= (1<<UART3_TXEN_PIN)
#define uart3_clear_txen() UART3_TXEN_PORT &= (1<<UART3_TXEN_PIN)

Cheers

Les

There should be a RS485Master.ino within the librarys' example folder to adjust your settings. Ofcourse the TX enable definition must harmonize with the above .h file.

Maybe you found the first issue to avoid further problems

Regards, Vinc

The defines in the includes are defaults. 

If you define them again after the include, your new value overrides the default.

got it, thanks

An aside, did I see somewhere that it is better to connect the Master Mega via USB 2.0 rather than 3.0 and above?

Cheers

Les

Tried it out today, I must have something wrong as it didn't work. I can see the master lights flashing, but none of the slaves are showing any lights. All the gauges do the start up routine so it's at least partly OK.

Tomorrow I'll recheck it all out, see if there's  a stupid error in the setup.  I will probably start by going back to my old master and single bus setup to test out the wiring to rule that out

Les

I have it working, one of the Nano's had the I2C scan sketch installed which apparently stopped everything else from being able to work with the RS485

However there is still something not right, as the gauges periodically flicker full scale as though there is a momentary power interruption.  I have a 5v supply connected directly to the RS485 mega on the RS485 bus so I know that that is not the cause of it. I also notice that the VHF radio panel only has three of the five OLEDs displaying at any one time

Nonetheless it is progress and I will keep niggling away at it

EDIT here's a video showing the behaviour I was describing

Les

Try disconnecting things from the power. It might be your supply can't handle the load.

definitely seems to improve if I disconnect stuff; may have to try and find a more powerful 5v PS

I have an old ATX power supply somewhere, I wonder if I can repurpose it

That'll give you 12V as well. 

Plenty of guides for that online.

I'm disappointed to report that despite putting in a dedicated 5A 5v power supply the gauge twitching is still there. Interestingly it seems to manifest itself when a device is connected that has an OLED or LCD display attached. I also tried a single Mega Master rather than the three bus version and it is the same

However, when I used two Megas as masters, and ported the OLED and LCD connected devices to one and the non OLED / LCD devices to the other, it works fine

I have four Megas so can add a couple more if necessary, and if it works I'm not going to complain. However it would be good to know why it behaves like that

Les

On 12/13/2022 at 2:57 PM, lesthegrngo said:

I also tried a single Mega Master rather than the three bus version and it is the same

As that was your configuration before going the 3 bus way, the behaviour is really strange!

Regards, Vinc

it is strange, it's almost as if the OLED / LCD devices interfere with the signal somehow. I had previously noted that you can't run an OLED and a stepper motor successfully one one Nano as the stepper movement is massively impacted. My suspicion for that is that the stepper update  cadence is directly related to the OLED refresh rate, and the U8G2 driven OLEDs would slow it down to a point where it was useless.

However I can't imagine why there would be any effect on other Nanos that are just connected via RS485

Despite this, the multiple Mega master solution does seem to be a viable one so my intention is to use one dedicated Master for all the stepper motor driven devices, and one or two others for all the remaining OLEDs, LCD's and things like the CLP

One other thing I will try is some 5v bus bars so that the 5v supply to the devices are not just on the RS485 lines. I doubt it will make any difference but costs nothing to try

Les