Jump to content

Gadroc

Members
  • Posts

    1060
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Gadroc

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. That is just an awesome setup. I already have to many projects unfinished and you have to go show this off :)
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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:.
  16. The OpAmps in the configuration of the second schematic are inverting amplifiers. They invert around the reference voltage which is roughly 4 volts. The first amplifier is configured with a gain of roughly 12.5x. So when 4.16 volts is read from the transducer (full defection) which is .16 volts above that's amplified to 2 volts and then subtracted from the 4 volt reference giving you 2 volts total. The second amplifier has a gain of 1x so amplitude is the same on output but it's inverted again so the the 2 volts is converted to 6 volts. [TABLE]Input Voltage|OpAmp 1 Diff|OpAmp 1 Amplified Diff|OpAmp 1 Output|OpAmp 2 Diff|OpAmp 2 Output 4.16|0.16|2.00|2.00|-2.00|6.00 4.00|0.00|0.00|4.00|0.00|4.00 3.84|-0.16|-2.00|6.00|2.00|2.00[/TABLE] On my transducer when mounted like your going to grip it Y is inverted on the transducer output. So the single inverting amplifier actually makes the pulling up on the transducer go positive Y. X on the other hand is already correct, so the second amp makes the polarity the same on output of amplification as the input. Technically you don't have to do this as you can invert the axis in game, but I didn't want to be restricted to using the input only on games that can invert axis. Since the OpAmp I had was a 4 channel amp it was simple to add this. You can make both the X and Y circuits look identical bypassing the second op amp if you don't want the complexity, or want to reduce the parts costs. I'm thinking about how to do a circuit board with a few jumpers to allow you to invert either or both X and Y axis. The opamp chip i'm buying has 4 op amps so it's not much more cost.
  17. Also I'm looking into other op amps that have a rail to rail capability, which might eliminate the need for a secondary power supply. I have to order some parts to test it so will be a week or so before I can tell if it's possible.
  18. Here is a new circuit diagram. Changes... * Went back to using inverting configuration on the op amps. As it was a little easier for some things. * Removed filter caps. Testing showed they didn't do anything. What they where originally filtering out ended up being bad wire connections. * Added a second opamp stage to fix X directions. * Fixed voltage regulator to be 7808 instead of the wrong 7805 Slew Amplifier 1.2.pdf
  19. I got my amplifier up and running. It's a modified version of Mike Powell's circuit. I switched it to be non-inverting instead of inverting and added some filtering. I then hook it in through a BU0386X. Also it looks like the F-16 RDR cursor might be wired differently. In order for my transducer to work I had to short pins 2/3 and 5/6. One not on the difference between your circuit and this one. In yours you use the 1k pot to center the transducer to dead center. In this one the reference voltage for the opamp is adjusted to match the transducer. The nice thing about that is 2 less wires I have to run up to the transducer. A quick video. I cut off the video a little fast but the cursor is pretty stable. When calibrating the jitter is only spanning value of 3. I have attached the circuit I'm using on the breadboard. Any electrical engineers out there I'd love some feedback on the circuit. (Removed bad circuit diagram... see later message for update)
  20. Once I get it dialed in I'll post the files.
  21. Working on converting my A model throttle into a C model, and getting it converted to a joystick. First test print of my right grip is done. Need to tweet a few tolerances and fix the speed brake switch foot print, but doesn't look that bad. I'm using the hat switches out of a TM Warthog Throttle, but the Speed Brake, China Hat and Slew Cursor are from the real throttle. I'm waiting on moving over the boat switch from the warthog as it's a destructive operation. They unfortunately soldered switches directly to circuit boards.
  22. I'm almost finish with my right grip conversion. Will be printing the next prototype today/tonight. I'm using the coolie hats and boat switch from my TM warthog. I'll post up the model once I test it.
  23. Here is the link to Mike's circuit. It's for the RDR Cursor on an F-16 throttle, but I think it's the same sensor.
  24. The original amplifier works on 5v. I was testing that last night. There is an unexpected 5th lead on the original amp which I haven't figured out yet. It's tied to the centering pot for one of the axis and looks like it has 5.6nF capacitors to both power inputs.
  25. Awesome work so far! I just started working on converting my throttle as well. Current intent is to use the parts from my Thurstmaster Warthog to convert the right grip, just using the force sensor from the original grip. I'll 3D print a replacement body using the right plate and metal cover from the warthog. Did you get any further in your slew control? I opened my throttle up and the amplifier in mine seems to be working, although I'm not sure I'm getting independent X/Y output from it. Almost seems Y mirrors X output (Y goes down in voltage when X goes up.) I don't have the sensor mounted or a hat on it so it may be working just hard to use. What where the behaviors you saw on the included amplifier when you said they didn't work? I have ordered parts to create Mike Powell amplifier and Bodnar's amplifiers as a back up.
×
×
  • Create New...