Jump to content

DCS-BIOS Discussion Thread


FSFIan

Recommended Posts

:pilotfly:... hi every body , Ian i ve a question, is there a way to find the signal for the force feedback on the controls ??:pilotfly:

 

I don't think you can access FFB info through Export.lua.

There might be another way (either through software or by building your own USB FFB device, e.g. based on adapt-ffb-joy), but it's not something that will be supported by DCS-BIOS.

Link to comment
Share on other sites

Ian;2951971']I don't think you can access FFB info through Export.lua.

There might be another way (either through software or by building your own USB FFB device, e.g. based on adapt-ffb-joy), but it's not something that will be supported by DCS-BIOS.

 

Hi, i thought about a theorical sollution to make it work with dcs ... i m thinking to make the servos that was already connected on my sim take there signals from the speed indication (small speed = small force and big speed = bigforce on the commands), ill give ita try ...

With respect

_________________

Kadda

_________________

My works

TL-39 (NewGen) project (Ру)/(EN)

Link to comment
Share on other sites

My turn for something very noob.

 

I finally managed to get around to start using lastest DCS-BIOS. I wanted to start making a similar setup as to what Warhog is using, i.e. a Mega as RS485 Master and then cheaper/smaller UNO/Micro as RS485 Slaves.

 

In order not to jump into a hole with too many variable I tried to do it baby steps, one thing at a time. This meant trying to hook up the Mega for the Master Caution example supplied with DCS-BIOS.

Initially I had problems getting Socat to run but a lot of back and forth between previous posts, using DCS-BIOS interactive control reference I managed to get Socat up and running.

 

However still no joy on running the Mega with Master Caution example. The pin 13 would be always on. Loaded a small standard blink sketch included with Arduino IDE (1.6.12) and that worked flawlessly with pin 13.

 

Hooked up an Uno instead and could get pin 13 to light up when pressing master Caution was on in game. Tried to change the baud rate to 115200 after speaking to a senior member but that didn't solve the missing blink of pin 13 on the Mega.

 

During investigation I found that the Uno works on baud 250000 but not 115200. Tried baud rates 115200, 250000 & 500000 for the Mega but it simply won't blink with Master Caution.

 

I even tried to run them in parallel using two instances of Socat, same result;

 

I am certain it's a pretty obvious fault on my side I simply just can't see it. Any help is appreciated :thumbup:

 

Cheers

Hans

Link to comment
Share on other sites

The baud rate is fixed at 250000 bps in newer versions. Anything else won't work.

 

However still no joy on running the Mega with Master Caution example. The pin 13 would be always on. Loaded a small standard blink sketch included with Arduino IDE (1.6.12) and that worked flawlessly with pin 13.

 

I think this is a problem that can happen with the Mega when starting the script after DCS. I first ran into this while developing the RS-485 master code and was thoroughly confused for a while, because I suspected my new code.

 

When the connect-serial-port.cmd script executes the "mode" command to set the baud rate, it resets the Mega as a side effect. After a reset, the bootloader runs and waits for a new program to be uploaded via the serial port. It receives the data from DCS. While the bootloaders on ATMega328P-based boards seem to go "this is not a valid program, let's go start the sketch!", the bootloader on the Mega gets stuck instead.

 

Workaround 1:

  • pause DCS
  • press the reset button on your Mega
  • wait for the pin 13 LED to flash twice
  • once the LED has turned off, unpause DCS

 

Workaround 2 (if this works for you as well I'll add this to the next release):

Edit your connect-serial-port.cmd script. Between the "mode" and the "socat" commands, add this line:

timeout 1

This adds a one second delay to wait for the bootloader to time out.

Link to comment
Share on other sites

Spot on Ian :thumbup:

 

I found that second solution didn't work all the times, so I increased to 2 seconds and now it I get the Mega to connected 10 out 10 times.

 

Thank you very much for your swift support :thumbup: Much appreciated Sir.

 

Cheers

Hans

 

... must spread some rep arouns :-(

Link to comment
Share on other sites

When constructing and wiring a panel how do I determine the best Arduino model to use? I have several UNOs and a Mega Arduino - but I have seen reference in the forums to the smaller boards. These smaller boards have less pins - right? So they are ore limited in the panels they could support. An Arduino mini couldn't support panels with more inputs like the UFC due to the limited pins, Or am I missing something?

 

Is a Matrix or shift register a solution being used for these smaller boards?

Link to comment
Share on other sites

I personally have used megas for everything they are not very expensive and you can always link small panels together using one mega for 2 or 3 panels. I use the prototyping board that has holes with rings round rather than stripboard and dupont pin connectors that are the same as the pins on arduinos, Do get the proper crimping tool for the dupont connectors though.

Others use smaller arduinos one for each panel and plan to have them on a master and slaves system. I am not doing a full cockpit and most of my panels are hybrids of 2 or 3 panels.

AMD A8-5600K @ 4GHz, Radeon 7970 6Gig, 16 Gig Ram, Win 10 , 250 gig SSD, 40" Screen + 22 inch below, Track Ir, TMWH, Saitek combat pedals & a loose nut behind the stick :thumbup:

Link to comment
Share on other sites

Because IRQ_SERIAL mode and the RS-485 stuff requires either an ATMega328 or an ATMega2560 processor, your choices boil down to the following list of boards (which ignores boards with ATMega32u4 or ARM processors):

 

  • Mega 2560
  • Uno
  • Nano
  • Pro Mini

 

First, we can eliminate the Uno from that list, because for the purposes of building a simpit, the Nano only has advantages compared to it. The Uno has 20 digital I/O pins, 6 of which can be used as analog inputs. The Nano has the same, but in addition it has two extra analog-only pins. Due to its smaller form factor, the Nano is cheaper to produce and easier to tuck away behind a panel.

 

Compared to the Nano and Pro Mini, the Uno has the advantage that you can connect shields to it and that it has a DC power jack, but I think both of these are irrelevant for the purpose of building a simpit. I can't imagine a situation where you'd use a shield in a panel, and you can power the Nano either over USB or through the V_IN pin.

 

The Pro Mini is a slightly smaller Nano that lacks the onboard USB-to-Serial converter. It costs about $0.40 less than the Nano. This could save some money when using it for RS-485 slave devices, where you only need the USB-to-Serial converter once to upload the firmware, but IMO saving $0.40 is not worth the hassle. The Pro Mini can be plugged into a breadboard, but some pins (notably A4, A5, A6, A7) are not in breadboard-friendly locations (and not even in on the 0.1" grid relative to the other pins). I used to recommend the Pro Mini when I hadn't learned of AliExpress prices and thought the price difference to the Nano was larger, but now I recommend the Nano over the Pro Mini.

 

In conclusion, two boards stand out for use with DCS-BIOS:

 

Use Arduino Mega 2560s for the RS-485 master, to do quick prototyping with Arduino Shields, or for panels that require lots of I/O pins.

 

I'd use Arduino Nanos for everything else.

 

The choice between one Mega or several Nanos is mostly one of personal preference. The cost per usable I/O pin is about the same. For CPU-heavy applications (stepper motor control comes to mind), spreading the load out over multiple Nanos has an advantage. Using all of the Mega's I/O pins for outputs might lead to a situation where the CPU isn't fast enough to process all of the incoming data; I haven't tried to push one to its limits yet, but I also haven't received any reports of problems so far. Using a Mega to serve multiple panels increases the length of wiring between the panels and the MCU but decreases the number of devices on the RS-485 bus. If you are not building a full cockpit, using a Mega vs. several Nanos might be the difference between needing an RS-485 bus or not.

Link to comment
Share on other sites

I have not had any problems with a Mega cpu not being fast enough I had one all pins connected plus 2 x 16/2 lcd screens worked like a dream in dcs as a full radio stack incorporating multi pos switches, toggles,push buttons,encoders,plain leds and the 2 16x2 character lcd screens.

however it may struggle with a tft. I will be testing for my cdu at some point.

AMD A8-5600K @ 4GHz, Radeon 7970 6Gig, 16 Gig Ram, Win 10 , 250 gig SSD, 40" Screen + 22 inch below, Track Ir, TMWH, Saitek combat pedals & a loose nut behind the stick :thumbup:

Link to comment
Share on other sites

Ok moore noob questions as I simply can't figure out what I have done wrong. I now have the Mega running as master and two slave units i.e. 1 & 2. The two slaves unit both show pin13 as Master Caution. I use that to verify connection.

 

Anyway I was trying to connect one of the boards as the Electrical Power Panel 'just' using the Slave example from the DCS-BIOS library and add the functions needed;

/*
 The following #define tells DCS-BIOS that this is a RS-485 slave device.
 It also sets the address of this slave device. The slave address should be
 between 1 and 126 and must be unique among all devices on the same bus.
*/
#define DCSBIOS_RS485_SLAVE 2

/*
 The Arduino pin that is connected to the
 /RE and DE pins on the RS-485 transceiver.
*/
#define TXENABLE_PIN 2

#include "DcsBios.h"

/* paste code snippets from the reference documentation here */
DcsBios::Switch2Pos eppBatteryPwr("EPP_BATTERY_PWR", 3);
DcsBios::Switch2Pos eppAcGenPwrR("EPP_AC_GEN_PWR_R", 4);
DcsBios::Switch2Pos eppAcGenPwrL("EPP_AC_GEN_PWR_L", 5);
DcsBios::Switch2Pos eppEmerFlood("EPP_EMER_FLOOD", 6);
DcsBios::Switch3Pos eppInverter("EPP_INVERTER", 7, 8);
DcsBios::Switch2Pos eppApuGenPwr("EPP_APU_GEN_PWR", 9);
DcsBios::LED masterCaution(0x1012, 0x0800, 13);

void setup() {
 DcsBios::setup();
}

void loop() {
 DcsBios::loop();
}

 

While the Pin13 does light up with Master Caution the inputs don't do anything. I hooked up the toggle switches like in the DCS-BIOS user guide, i.e. pulling inputs down to GND. I have measured the voltage on the inputs just to be sure. Un-activated the voltage is 3.3VDC and activated it's zero.

 

I am certain it is staring me right in the face. I even tried to run with both pull up and pull down resistors but no joy. I have tried above code on another board connected directly to SOCAT and there it works.

A little hint would be highly appreciated :cry:

 

Cheers

Hans

Link to comment
Share on other sites

I am certain it is staring me right in the face. I even tried to run with both pull up and pull down resistors but no joy. I have tried above code on another board connected directly to SOCAT and there it works.

A little hint would be highly appreciated :cry:

 

Cheers

Hans

 

There is nothing obviously wrong with the sketch. You can double check the following:

 

  • Is pin 2 (TX_ENABLE) connected to both /RE and DE on the MAX487?
  • No duplicate slave address on the bus? (does it work with a single slave device on the bus?)

 

If it's not one of those, you'd need a logic analyzer for further debugging. I plan to add some better RS-485 debugging capabilities in DCS-BIOS 2.0, but unfortunately that's still some time away.

Link to comment
Share on other sites

Thank you very much for taking a look Ian. Much appreciated. I now figured out what the problem was. I got it to work this evening and then it stopped working after I had disconnected my laptop to the Slave board. Turned out that I had applied 5VDC to the Nano but in the Vin, i.e. before the voltage regulator :doh: After connecting 5VDC to a 5VDC pin it was working.

Later on I plan to apply 12VDC to the Vin to ensure there is enough juice to the boards.

 

I seem to recall that earlier had issues running LCD's on 5VDC.

 

With regard to a logic analyser I have a Rigol oscilloscope DS1054Z. Can that be used for this?

 

Thanks a bunch for the assistance Sir.

 

Cheers

Hans

Link to comment
Share on other sites

Many issues with an RS-485 bus can be diagnosed equally well with either a digital storage oscilloscope or a logic analyzer.

 

The DSO shines when the problem is with analog signal integrity, because you can use it to look at the voltage difference between the A and B lines. A logic analyzer obviously can't do that. The scope is also quicker to set up and less annoying to use (no need to start/stop the capture manually). In general, I prefer to use the oscilloscope whenever feasible (I have the DS1054Z as well).

 

The logic analyzer is the preferable choice when the problem is difficult to trigger on with the oscilloscope and occurs so infrequently that you can't find it in single-shot mode. Using protocol decoders to look at the transmitted data is also a lot easier to do on a PC compared to the DS1054Z with its smaller screen and slower CPU. Due to its 8 channels, the logic analyzer can also be used to look at all relevant digital signals (DI, /RE, DE, RO) for both the master and a slave device at the same time.

 

In general, the oscilloscope is better for finding problems with signal integrity and the logic analyzer is better for finding software problems.

 

If you don't have a logic analyzer, you can grab one for less than $10 on eBay. Those are cheap clones of the early Saleae Logic 8 models. They work reasonably well with sigrok and are fast enough for any digital signal you will ever deal with on a 16 MHz microcontroller. Because they stream the data to the PC over USB 2.0, capture duration is theoretically only limited by available hard drive space. In practice, the sample rate that can be reliably sustained depends on the USB drivers and what other hardware is connected to the same USB port.


Edited by [FSF]Ian
Link to comment
Share on other sites

Ian;2961342'].. I used to recommend the Pro Mini when I hadn't learned of AliExpress prices and thought the price difference to the Nano was larger' date=' but now I recommend the Nano over the Pro Mini.[/quote']

Lol!

I bought a bunch of Pro Minis because of your recommendation but later realized that the Nano offered better features and had the USB built-in which is very convenient for me since I'm building my entire cockpit panels using USB bus only connected to a custom made 30-port USB powered hub.

So, Ian... In your experience, do you think it's convenient to have 30+ panels connected through USB bus to the same computer or do you prefer the RS485 bus any day?

I'd really like to know what you think about this suicide choice

 

Another thing I'd like to ask you is whether you're aware the latest update seemed to break DCS-BIOS communication because my panels used to work just fine with DCS-BIOS 0.xx version but not anymore with DCS-BIOS-MASTER and DCS update 2.0.4/1.5.5. I don't know if I'm doing anything wrong so please help me. Here's the code I got for the CMSP panel:

 

#define DCSBIOS_DEFAULT_SERIAL

#include <DcsBios.h>
#include <LiquidCrystal.h>

#define   CONTRAST_PIN   9 //VEE
#define   CONTRAST      100
LiquidCrystal lcd(8, 7, A3, A2, A1, A0); //pinA0=D7, pinA1=D6, pinA2=D5, pinA3=D4, pin7=Enable, pin8=RS

void onCmsp1Change(char* newValue)
{
 lcd.setCursor(0, 0);
 lcd.print(newValue);
}
DcsBios::StringBuffer<19> cmsp1Buffer(0x1000, onCmsp1Change);

void onCmsp2Change(char* newValue) {
 lcd.setCursor(0, 1);
 lcd.print(newValue);
}
DcsBios::StringBuffer<19> cmsp2Buffer(0x1014, onCmsp2Change);
//**SET BUTTONS**
//DcsBios::Switch2Pos cmspArw1("CMSP_ARW1", PIN);
//DcsBios::Switch2Pos cmspArw2("CMSP_ARW2", PIN);
//DcsBios::Switch2Pos cmspArw3("CMSP_ARW3", PIN);
//DcsBios::Switch2Pos cmspArw4("CMSP_ARW4", PIN);
//**BRIGHTNESS POT**
//DcsBios::Potentiometer cmspBrt("CMSP_BRT", PIN);

DcsBios::Switch3Pos cmspDisp("CMSP_DISP", 10, 14);
DcsBios::Switch3Pos cmspRwr("CMSP_RWR", 11, 15);
DcsBios::Switch3Pos cmspJmr("CMSP_JMR", 12, 16);
DcsBios::Switch3Pos cmspMws("CMSP_MWS", 13, 17);

DcsBios::Switch2Pos cmspJtsn("CMSP_JTSN", A7);

const byte cmspModePins[5] = {2, 3, 4, 5, 6};
DcsBios::SwitchMultiPos cmspMode("CMSP_MODE", cmspModePins, 5);

//**ROCKER SWITCHES**
//DcsBios::Switch2Pos cmspRtn("CMSP_RTN", PIN);
//DcsBios::Switch3Pos cmspUpdn("CMSP_UPDN", PIN_A, PIN_B);

void setup()
{
   DcsBios::setup();
 // put your setup code here, to run once:
//  pinMode(10, OUTPUT); //FOR BACKLIGHT
//  analogWrite(10, 80);  //analogRead values go from 0 to 1023, analogWrite values from 0 to 255
 pinMode(CONTRAST_PIN, OUTPUT);
 analogWrite ( CONTRAST_PIN, CONTRAST );
 Serial.begin(250000);
 lcd.begin(20, 2);
 lcd.clear();
 lcd.setCursor(3,0);
 lcd.print("WARTHOG READY");
}

void loop()
{
 DcsBios::loop();
}

My rig specs:

Intel Core i7 4770 @3.4Ghz // Corsair 16GB DDR3 // MoBo Asus Z87K // HDD 1TB 7200RPM // eVGA Nvidia GTX 760GT 2GB DDR5 // LG 3D 47" 1920x1080 // Thrustmaster Warthog HOTAS // Saitek Combat Pro Pedals // Thrustmaster MFD Cougar pack // PS3 Eye + FTNOIR

Link to comment
Share on other sites

I got it to work using IRQ instead of DEFAULT like the comments in your example sketch stated!!

My rig specs:

Intel Core i7 4770 @3.4Ghz // Corsair 16GB DDR3 // MoBo Asus Z87K // HDD 1TB 7200RPM // eVGA Nvidia GTX 760GT 2GB DDR5 // LG 3D 47" 1920x1080 // Thrustmaster Warthog HOTAS // Saitek Combat Pro Pedals // Thrustmaster MFD Cougar pack // PS3 Eye + FTNOIR

Link to comment
Share on other sites

So, Ian... In your experience, do you think it's convenient to have 30+ panels connected through USB bus to the same computer or do you prefer the RS485 bus any day?

Definitely go with RS-485. Even if you wait for DCS-BIOS 2.0, which will talk to multiple COM ports at once, it will still be a huge annoyance dealing with 30 USB-to-Serial adapters. Especially when Windows renumbers them at will because they don't have proper serial numbers. Even though in theory, one USB controller can handle up to 127 devices (hubs count as well), I have heard that you can run into problems with more than 20 already and would need to install another USB controller (on a PCI-E Card).

 

I got it to work using IRQ instead of DEFAULT like the comments in your example sketch stated!!

 

DEFAULT_SERIAL mode is problematic as soon as many outputs (or a few that take a long time to update, like character displays) are involved. It's kept around as a compatibility mode because it works on any Arduino-compatible board. That makes it possible to get started with whatever Arduino board you happen to already have and it enables the use of faster, ARM-powered boards for special cases like the CDU display. Those faster boards also tend to have enough RAM and CPU power to mitigate the problems of DEFAULT_SERIAL mode (they can afford a larger receive buffer).

Link to comment
Share on other sites

Ian;2965224']Definitely go with RS-485. Even if you wait for DCS-BIOS 2.0, which will talk to multiple COM ports at once, it will still be a huge annoyance dealing with 30 USB-to-Serial adapters. Especially when Windows renumbers them at will because they don't have proper serial numbers. Even though in theory, one USB controller can handle up to 127 devices (hubs count as well), I have heard that you can run into problems with more than 20 already and would need to install another USB controller (on a PCI-E Card).

 

I can fully back up up the limitation of 20 (perhaps less). I tore my hair out trying to work out what was wrong earlier in my build (thinking 127 USB devices was the limit), only managed to get it stable by adding another USB controller.

Link to comment
Share on other sites

Ian;2965224']Definitely go with RS-485. Even if you wait for DCS-BIOS 2.0' date=' which will talk to multiple COM ports at once, it will still be a huge annoyance dealing with 30 USB-to-Serial adapters. Especially when Windows renumbers them at will because they don't have proper serial numbers. Even though in theory, one USB controller can handle up to 127 devices (hubs count as well), I have heard that you can run into problems with more than 20 already and would need to install another USB controller[/quote']

 

I can fully back up up the limitation of 20 (perhaps less). I tore my hair out trying to work out what was wrong earlier in my build (thinking 127 USB devices was the limit), only managed to get it stable by adding another USB controller.

Well... I supposed this is the end for my goal of having ALL the panels connected through USB... I really thought the limit was going to be the max current and I had modified two 10-port USB huds to allow external power only with a beefy PC PSU...

Ian, what do you mean with DCS-Bios 2.0 will allow to talk to multiple comm ports? With DCS-Bios 0.2x I had 5 panels running connected via USB using different comm ports.

Also, when you say that Windows renumbers the panels at will because they don't have proper serial numbers, do you mean that they don't have vendor id as a plug and play usb device?

My rig specs:

Intel Core i7 4770 @3.4Ghz // Corsair 16GB DDR3 // MoBo Asus Z87K // HDD 1TB 7200RPM // eVGA Nvidia GTX 760GT 2GB DDR5 // LG 3D 47" 1920x1080 // Thrustmaster Warthog HOTAS // Saitek Combat Pro Pedals // Thrustmaster MFD Cougar pack // PS3 Eye + FTNOIR

Link to comment
Share on other sites

To handle multiple COM ports right now, you need to run multiple copies of connect-serial-port.cmd. DCS-BIOS 2.0 will do all of that from a single application eventually, to make it more convenient.

 

Usually, when you plug in a new USB-to-Serial adapter, Windows will assign it a COM port number. When you unplug the device and plug it in again later, it will get assigned the same COM port, but only if Windows recognizes it as the same device. If the device does not have a unique serial number in its USB descriptor (and most adapters don't, because it complicates the manufacturing process), then the COM port number it is assigned will change from time to time.

 

Now imagine having to change dozens of COM port numbers in a settings dialog somewhere every time Windows decides to do this...

 

If you prefer to connect everything directly through USB, you can certainly do it. If you have a free PCI Express (x1) slot, you can add another USB controller for about $15. DCS-BIOS will always support multiple USB-to-serial connections, but it will be designed for about five, not 30+, so I think RS-485 is the less annoying way to go in the long term.

Link to comment
Share on other sites

How do you suggest to connect 30+ RS485 devices with an Arduino Mega?

I'm converting all my panels from homerun wiring to modular each one with its microcontroller/arduino mini nano and your wonderful DCS Bios and I need to have this connectivy issue resolved asap

Thank you very much for your help, Ian

My rig specs:

Intel Core i7 4770 @3.4Ghz // Corsair 16GB DDR3 // MoBo Asus Z87K // HDD 1TB 7200RPM // eVGA Nvidia GTX 760GT 2GB DDR5 // LG 3D 47" 1920x1080 // Thrustmaster Warthog HOTAS // Saitek Combat Pro Pedals // Thrustmaster MFD Cougar pack // PS3 Eye + FTNOIR

Link to comment
Share on other sites

How do you suggest to connect 30+ RS485 devices with an Arduino Mega?

I'm converting all my panels from homerun wiring to modular each one with its microcontroller/arduino mini nano and your wonderful DCS Bios and I need to have this connectivy issue resolved asap

Thank you very much for your help, Ian

 

Do a search here on this forum for RS485. There should be a lot of info available. Ian and I will be releasing documentation on how to make an "RS-485 Bus for DCS-BIOS Dummies" (like me). Its written so people like me can understand how to set it up with DCS-BIOS and a bunch of Arduino Boards. Should be ready before Xmas. It will include PCB designs for you to copy and make your own if you have the facilities for doing that kind of thing.

 

Initially though, I think you will find lots of info buried in our forum on RS-485. At least enough to get you started.:)

 

And some pics to show you how I did some retro fitting to existing panels with a Pro Mini:

 

IMG_0539.jpg

 

IMG_0534.jpg

 

Don't look to carefully at these boards as I made a mistake in the design, but you get the idea. Its not very difficult to add one to an Arduino. Later on I just started adding them to every PCB I designed so no more retro fitting.

Regards

John W

aka WarHog.

 

My Cockpit Build Pictures...



John Wall

 

My Arduino Sketches ... https://drive.google.com/drive/folders/1-Dc0Wd9C5l3uY-cPj1iQD3iAEHY6EuHg?usp=sharing

 

 

WIN 10 Pro, i8-8700k @ 5.0ghz, ASUS Maximus x Code, 16GB Corsair Dominator Platinum Ram,



AIO Water Cooler, M.2 512GB NVMe,

500gb SSD, EVGA GTX 1080 ti (11gb), Sony 65” 4K Display

VPC MongoosT-50, TM Warthog Throttle, TRK IR 5.0, Slaw Viper Pedals

Link to comment
Share on other sites

to get myself started I bought a pack of these; http://www.ebay.com/itm/10PCS-MAX485-module-RS-485-TTL-to-RS485-MAX485CSA-Converter-Module-For-Arduino-/151919069659?hash=item235f1509db:g:JhcAAOSw~otWcm5Z

 

They will not be a neat or cost effective setup as the one Warhog is showing but you won't have to start manufacturing your own PCB's. One advange I found was that in case I was wondering if the MAX487 chip had fried then I could just take another board and try.

 

Just get the DIP-8 version and mount it on a piece of prototype board. The only external component you need is the 100nf capacitor between VCC and GND.

 

Those modules use MAX485 chips instead of the MAX487 that we recommend. The MAX485 will only handle up to 32 devices instead of 128, but more importantly, the MAX485 is not slew-rate limited, which means you probably will have to terminate the bus. If the various schematics I found online for those modules are correct, they also include termination and bias resistors on every module. If you are using termination resistors at all, you only want those at the start and end of the bus, so you'll have to modify any module you use in the middle. As far as we know, when using the slew-rate limited MAX487 and keeping the bus length below 10 meters, biasing and termination resistors are not required. (Termination is not required if the bus is short enough, and without external termination resistors, the internal biasing resistors in the MAX487 should be enough -- this is the "fail-safe feature" that is mentioned in the datasheet.)

 

If you use MAX485 chips, the necessary termination and biasing resistors will further reduce the amount of devices you can have on the bus. (see also: http://dcs-bios.a10c.de/rs485-resistors.html)


Edited by [FSF]Ian
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...