Gadroc

This usually means your UPS is rated for less power draw than your PC is consuming. Current high end CPUs and Graphics Cards draw a lot of power. I could trip mine running multiple different stress test / benchmacrks until I put my monitor and other peripherals on separate UPS.

Normal channel pricing on the MAX487 chips are significantly higher than that. The lowest listed price for a MAX chip at quantity of 1000+ is $1.63. Based on that pricing, plus the fact that there at least three different sets of markings on the chips pictured in the current ebay listings. I'd consider those chips a high probability of being counterfeit, meaning they may or may not match the specifications on the datasheet. That being said, lets talk about the reasons to select an RS-485 chip. There are four main differences between these chips power draw, data rate, bus load and price. Data Rate For our purposes we want the highest data rate we can sustain. We will be round robin asking boards if they have inputs so we want this as fast as possible so the latency is low between a switch being flipped and the switch acting in game. Ideally this is 250ms or less in order to "feel" right and not delayed. For DCS-BIOS which is mainly centered around an arduino echo system the majority chips (ATMEGA328P or ATMEGA32U4) can only sustain 250kbps before we start having problems keeping up. Faster can probably be attained by dropping the arduino libraries but that defeats some of the purpose of allowing folks to work in an easy environment. Some arduino compatible boards like the teensy series are able to go faster, but many of them are 3.3v not 5v. Be careful when using one of these as many of the RS-485 driver chips are 5v. In regards to RS-485 chip selection make sure the chip you select has a high enough max rate to enable your desired speed. I prefer to have my chip rated higher than my desired speed. For me that eliminates the MAX487 chip as it's max is 250kbps, so I would move to the MAX485 or MAX1487 chips with 2.5Mbps if you want to stick witht he MAX lineup. Bus Load The RS-485 standard specifies a max of 32 devices on a single bus. This is not an arbitrary number that can be played with. There is a lot of math and engineering around the electrical characteristics that these drivers are designed around. That being said as technology has gotten better chip manufacturers have started designing "partial load" transceivers where they have half or quarter of the electrical load on the bus, increasing the number of devices on the bus. For our use case we really will never have more than 32 devices on the bus. As I said above you want the latency of sending switch information at 250ms or under which means you need to poll each board 4-5 times per second. At 250kpbs you don't have enough bandwidth to send 30fps updates from DCS BIOS and poll more than a dozen or so panels. This means quarter load transmitters are not a value add for us, so don't pay more for them. Power Draw Chips can have radically different power draw and you need to do the math in terms of total power draw for your entire pit not just a single card. When calculating total power draw keep in mind there is only one transmitter at a time per bus, but everyone else is receiving. Calculating actual supply draw is a little more complicated, but the draw values in the table below will give you directional comparison between the chips. Some chips have a lower power shutdown (ex: MAX481) where you can shutdown and draw even less current. Since we never have an situation where we want micro-controller on but RS-485 off the extra feature is useless to us. In addition we are usually trying to max out the number of IO lines to our inputs so we don't want to dedicate another IO pin to control power mode of the transceiver. Chip Comparisons Here is a quick list of chips that I found which are pin compatible when using DIP or SOIC variants. I have only included chips which have higher than 250kbps as max data rate, and eliminated variants that only have features that don't matter to us. These are all 5V chips, 3.3V variants all cost $2.80+. [TABLE]Mfr|Chip|Cost|Total Cost|Max Data Rate (Mbps)|Receiving (mA)|Transmitting (mA) MAXIM|MAX485|$1.68|$84.00|2.5|0.3|0.5 MAXIM|MAX1487|$1.68|$84.00|2.4|0.23|0.3 Texas Instruments|SN75176|$0.68|$34.00|10|26|42 Texas Instruments|SN65HVD485E|$1.72|$86.00|10|1|2 Exar|SP485|$0.78|$39.00|5|0.9|0.9 Exar|SP485E|$0.78|$39.00|10|0.6|0.9 ST|ST485C|$0.76|$38.00|2.5|0.5|0.9 ST|ST485E|$0.79|$39.50|5|0.3|0.4 Intersil|ISL81487E|$1.34|$67.00|5|0.35|0.4[/TABLE] All pricing is for 50 chips from Digi-Key for an SOIC-8 chip, but I checked several reputable distributors and they are all pretty close. Through hole DIP versions are a little higher across the board. The TI chip I was refering to was the SN75176, which has obviously more power draw but significantly lower cost. It had been a while since I did a comparison and I will probably use the ST485C for my panels control boards.

I'd look at some TI RS-485 transcievers. The MAX chips are 3 times more expensive which will add up over an entire pit.

I cut all the parts out on the CNC and then hammered in the inserts after cleaning up the parts. It's possible to flip the parts and cut with the bottom side up and insert the nuts after the holes are cut before the inside profile paths. The risk is crashing the bit into the inserts which would require a new piece of wood and cutter.

Some pit progress... finally. I got the left side console console almost ready.I just need to cut out the outside wall panel and I can square up and assemble to frame. The 8/32 press fit inserts work fine this close to the edge, so I've ordered enough for the rest of the pit. I'll cut out the last frame part and can do assembly except for the two rear rails as they need the additional inserts.

Time is never my friend, but Rev 2 is now on the bench and working! Although there are a few changes from above. I switched to a different CPU to reduce part count. I had to remove the 4 HAT switch inputs, but the analog input and ADC is much cleaner with the new circuit. The new board is 2" x 3" with M3 mounting holes in the corners. I have all of the firmware running on the new CPU and have a bootloader working for firmware updates. I'm working on the configuration utility and communications now. I should be able to order the final batch of Rev 3 shortly. I've also got my throttle grip conversion complete. I've also begun work on design of my left console. The new rudder floor, stick mount and seat cradle are already cut on the CNC machine and should be put together later today.

Great job! That nice pop when the switches turn off has to be satisfying. I took a quick look through the DCS Bios code to check on those behaviors. 1) This is normal and as you said not an issue. In sim the magnetically held switches gets two inputs, one when you click the mouse button and the other when you release it. No matter the state of the magnet it will hold the switch in the on position while the mouse button is held down. When you release the mouse button it will snap back to off if the magnet was not turned on. DCS Bios sends both event but sends them instantaneously in the same video frame so the switch never has a chance to be drawn in the on position. 2) This is a problem. The 3D view in the sim is the only one that matters. That is the position that the sim thinks the switch is in and represents how it will calculate things in the simulation. This is something that would have to be fixed in DCS-Bios, it would have to check switch position before sending events.

DCS Bios protocol has all values with 65536 steps (0-65535) or 16 bit resolution, but your arduino has no where near that capability in measuring analog values. It only has 1024 steps (0-1023) or 10bit resolution. What the firmware does is take the value from reading the pot (0-1023) and multiply it by 64 turning it into (0-65535), but there are still only 1024 possible values being returned (0, 64, 128, 172...). It does this so you can put in different hardware with better/worse ADCs (8bit, 12bit) and the protocol doesn't change just the multiplier in the firmware. Reducing resolution is valid in many circumstances (this is probably one), but you've reduced it to about 131 discrete values (approx 7bit resolution). The two primary (outside flight controls) for pots are light levels and volume. At 131 you might see the stair step changes for light levels, typically I try to keep PWM to 8bit (256 values). Also the way you've reduced resolution will create inconsistent behavior on the pot. Turning the knob fast allows for a lot of different values to be generated since as long as the value is past the 500 difference mark any value is valid. Turning the knob slowly only allows for the above mentioned 131 discrete value. The point of a pot is to have an absolute mapping of position to output, otherwise an encoder is a better choice. The way I'd reduce resolution is just divide the raw reading (0-1023) by 4 to get a value between 0-255, which essentially drops the lower 2 bits of resolution. If that value is within 1-2 of the last time you reported just report the last value. Then multiply that by 257 to get it to the range 0-65535. This will filter out nearly the same amount of noise but give you 256 values instead of 131, and be more consistent with output values to position. If the potentiometer is generating more than 2bits of noise it really needs to be replaced. In this case these difference might not matter a whole lot, but they definitely will for something like a trim wheel.

You're algorithm has just effectively dropped resolution. There are a couple of other techniques to deal with this that are better. First apply filters to the raw ADC reading (0-1023) not to the expanding output (0-65535). I'd start with super sampling. Read the ADC every 50ms and every 4th reading average the last 4 readings and pass that to DCS BIOS. This will increase the usable bitrate of the ADC instead of reduce it. If that is not enough you take the supersample results from the above, but don't fully override the last reading. Do something like lastreading = (lastreading + lastreading + lastreading + newreading)/4. That will slow down change over time, so short spikes are reduced. After those changes your should only see jidder of 1-2 in raw value which is common for the least significant bit of an ADC reading. If that's to much you keep track if you are with in 1-2 of the last output and if you are only pass it on if the last few readings also that way. You would end up with something like the following (pseduo code). super_sample_total += analogRead() sample_count++ if (sample_count == 4) { sample_count = 0; new_sample = super_sample_total / 4; output = (output + output + output + new_sample) / 4; if (ABS(output - dcsvalue) > 2) { dcsvalue = output; } else if ((lastoutput - dcsvalue) < 2) { dcsvalue = output; } lastoutput = output; } Here are a few links on creating software filters for things like this: Filters (long) forum post A simple software lowpass filters

That is just an awesome setup. I already have to many projects unfinished and you have to go show this off :)

I've got 90% of the firmware workings. Oversampling and filtering on the analog inputs is done. I have also reworked the schematics a little bit adding two additional analog inputs and 4 more digital inputs. Rev. 2 Specs USB Powered (Micro USB Port) 8 Analog Axis w/ 12 bit resolution 2 Channel Transducer Amplifier (5V, 8-15x Amplification, Centering Pot) PWM Backlight Controller (Indepentent Power up to 30v / 1Amp) 32 Discrete button/switch inputs (No diodes and complicated matrix) 4 Dedicated HAT Switch Inputs Current Firmware Capabilities AXIS Mapping - Assign any of the 8 inputs to usage (X, Y, Z, Rx, Ry, Rz, Slider, Dial or Disabled). Disabled AXIS don't appear on the computer to prevent confusing the sim. AXIS Tuning - Set center and limit dead zones and axis scaling. If your sensor is not capable of a full 0-5v range the firmware can compensate (although at a reduced resolution) Button Virtualization - Each of the button inputs can be assign to any of the up to 40 buttons presented to the computer Timing wise I need to do a few more bodge wires to my sample board to verify some of the circuit changes and verify the PWM backlight. Once that's complete I'll order another sample which will take @ 3 weeks. Then I can place the order for the final boards. During that 3 weeks I'll be completing the following software items: Firmware - Add up to 3 virtual HAT switches which can be mapped to button inputs. Firmware - Add PWM control to USB interface Firmware - Add boot loader / firmware update capability Software - Calibration/Configuration Utility. Utility to map and tunes axis, configure and map buttons, and update firmware. Software - DCS BIOS backlight relay. Will listen for DCS BIOS messages and turn on /dim the backlight. Looks like pricing will be $80 ($70 if you want to solder your own headers) plus shipping. PM me if you want to commit to purchasing one at that price point.

New toy for x-mass came early yesterday. The prototype PCB for my joystick controller with built in amplifier for the transducer. Here is the raw board as it showed up. Here it is after fixing some stupid mistakes and tweaking op-amp resistors. Hardware Features * USB Powered (Micro USB Port) * 6 Analog Axis w/ 12 bit resolution * 2 Channel Transducer Amplifier (5V, 8-15x Amplification, Centering Pot) * PWM Backlight Controller (Indepentent Power up to 30v / 1Amp) * 32 Discrete button/switch inputs (No diodes and complicated matrix) Planned Firware/Software Features * HID Joystick - No driver required * Virutal Buttons on Axis Ranges * Configurable Bounds on Axis * HID Protocol for Backlight * C# API to control Backlight * Configuration GUI Tool (upload firmware, setup rotary encoders, setup virtual buttons) I've validated the amplifier works with my transducer giving a 0.5 - 4.5 volt read range for full deflection/force. In the process finding where I had the always required crossed wires on first try and fixing my resistor ranges for amplifier settings. I've just started the firmware which is needed to validate the rest of the circuit design / board layout. Let me know if anyone is interested in these, they should be perfect for converting real throttles / grips for simulator use. If enough people are I may throw up a quick kickstarter or group buy to get a bulk order in.

I have all of the indicators on the ARU2B working with a simple arduino. Most can be controlled with just a resistor and two PWM pins. The only two things that can't be controlled like that are the ball itself and the power failure indicator. The power failure needs a relay two connect it to the 400hz AC lines and the ball needs 400hz synchro drivers. I'll dig up my notes and post the required circuits if anyone is interested.

Looking great! Congrats on the new CNC machines... boy is that a dangerous part of this hobby. I've gotten lost in playing with them and making them better.

Awesome work so far. It's a very rewarding journey. My wife is never sufficiently impressed when I figure out how to build something either :lol:.