FSFIan

Der TM Warthog ist auch nicht frei von Macken. Nach ein paar Jahren entwickelt sich "sticktion", d.h. der Stick "klemmt" ein bisschen und feine Korrekturen werden deutlich schiwieriger. Dann muss man den Stick auseinandernehmen und neu einfetten. Es ist immer noch ein super Stick, aber bei dem Preis haette ich eine bessere Verarbeitungsqualitaet der internen Mechanik erwartet. Wenn du einen guten Stick in der oberen Preisklasse suchst, wuerde ich mal einen Blick auf den neuen Stick von VKB werfen.

Quote from the GitHub page: While it's technically possible to make this work for some other unit types, I won't do it. This is a quick and dirty proof of concept, and given that ED plans to implement 3D preview capabilities into the standard mission editor, it's not worth the effort. It's open source though, so feel free to fork and extend it.

That won't work for a two-position toggle switch that is currently in the open position. Should work for anything else I can think of right now.

You need to plug in via USB and you probably need a way to disconnect the MAX487's DRIVER OUTPUT line so it doesn't fight with the USB-to-serial converter. In an ideal world, you'd work on your sketch in IRQ_SERIAL mode until it does what you want it to, switch it to RS485_SLAVE mode, and then never touch it again, but given that DCS-BIOS is still in an early proof-of-concept phase an occasional recompile and reflash for all panels will probably be required if/when I make changes to the communication protocol.

Einmal "deutsches Tastaturlayout" googlen gibt als ersten Treffer den Wikipedia-Artikel: https://de.wikipedia.org/wiki/Tastaturbelegung Der hat mehrere Varianten als verlustfrei skalierbares SVG, gerne auch zum Ausdrucken :) In der deutschen Wikipedia sind die einzelnen Tasten zu anderen Artikeln verlinkt, der englische Artikel verlinkt direkt zur eigentlichen SVG-Datei.

Weil dein Betriebssystem der Meinung ist, dass die restlichen 11 GB RAM besser für andere Dinge verwendet werden sollten (einerseits Dateicache, andererseits Reserve, um neue Speicherallokationen sofort bedienen zu können). Früher wurde die Auslagerungsdatei erst dann benutzt, wenn der RAM fast vollständig belegt war. Moderne Betriebssysteme verschieben Speicherseiten, auf die seit längerem nicht zugegriffen wurde, schonmal vorsorglich in die Auslagerungsdatei, auch wenn der RAM noch lange nicht voll ist. Der Platz, der für den Dateicache verwendet wird, wird normalerweise bei Anzeigen von "belegtem Speicherplatz" nicht mitgezählt. Ein weiterer Effekt könnte sein, dass manche Daten sowohl im RAM als auch in der Auslagerungsdatei stehen. Ich weiß nicht, ob Windows sowas macht, aber wenn I/O-Bandbreite da ist (also nichts anderes gerade auf die Platte zugreifen will), und Platz in der Auslagerungsdatei da ist, dann kann es Sinn ergeben, ein paar Speicherseiten schonmal "auf Verdacht" in die Auslagerungsdatei zu kopieren. Man verliert dadurch nichts (die I/O-Bandbreite und der Plattenplatz wären sonst ja ungenutzt geblieben), aber für den Fall, dass man in Zukunft was auslagern will, liegen die Daten schon auf der Platte: wenn es seit dem "präventiven Auslagern" keinen Schreibzugriff mehr gab, kann man sie einfach im RAM überschreiben und muss nicht mehr warten, bis sie auf die Platte gesichert wurden. Fazit: früher war die Tatsache, dass überhaupt ausgelagert wurde, ein Anzeichen dafür dass man zuwenig RAM verbaut hatte. Heute nutzen Betriebssysteme die Auslagerungsdatei auch dann, wenn alles in den RAM passt, denn es könnte ja jederzeit ein neuer Prozess vorbeikommen, der mal eben 10 GB Speicher haben will...

I have modified your sketch to write to a character LCD and tested it with my LCD shield. It works as expected (there is a delay of up to two seconds before it reacts to changes because of the two delay(1000) calls). Here's the code I used: /* use '#define DCSBIOS_DEFAULT_SERIAL' instead if your Arduino board * does not feature an ATMega328 or ATMega2650 controller. */ #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" #include <LiquidCrystal.h> LiquidCrystal lcd(8,9,3,5,6,7); void onUhfFrequencyChange(char* newValue) { /* your code here */ while(*newValue>0){ _write_to_digit_zero(*newValue++); _write_to_digit_one (*newValue++); _write_to_digit_two (*newValue++); _write_to_digit_three(*newValue++); _write_to_digit_four(*newValue++); _write_to_digit_five(*newValue++); _write_to_digit_six (*newValue++); _write_to_digit_seven(0x20);//writes blank to eight display digit //since <string> is seven chars? } } DcsBios::StringBuffer<7> uhfFrequencyBuffer(0x1180, onUhfFrequencyChange); /*assign Display pins to Arduino pins*/ int _reset = 3; int _FL = A0; int _A0 = A1; int _A1 = A2; int _A2 = A3; int _A3 = A4; int _A4 = A5; int _WR = 4; int _CE = 28; int _RD = 26; void setup() { DcsBios::setup(); _my_Reset(); /*Reset the Display*/ delay(500); /* Test write to display not using DCS data*/ _write_to_digit_zero (0x20); _write_to_digit_one (0x30); _write_to_digit_two (0x32); _write_to_digit_three (0x32); _write_to_digit_four (0x32); _write_to_digit_five (0x32); _write_to_digit_six (0x32); _write_to_digit_seven (0x32); delay(2000); } void loop() { DcsBios::loop(); /* Heartbeat LED is board accepting flash*/ digitalWrite(5, HIGH); // turn the LED on delay(1000); // wait for a second digitalWrite(5, LOW); // turn the LED off delay(1000); // wait for a second } /* Reset the Display ...clears character RAM * Flash RAM... resets internal counters */ void _my_Reset(void) { lcd.clear(); delay(1); delay(400); } void _my_WR(void) { //digitalWrite(_WR,HIGH); delay(1); //digitalWrite(_WR,LOW); delay(1); //digitalWrite(_WR,HIGH); } /* This Function writes to far left hand digit on Display*/ void _write_to_digit_zero(char my_ascii) { lcd.setCursor(0, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_one(unsigned char my_ascii) { lcd.setCursor(1, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_two(unsigned char my_ascii) { lcd.setCursor(2, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_three(unsigned char my_ascii) { lcd.setCursor(3, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_four(unsigned char my_ascii) { lcd.setCursor(4, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_five(unsigned char my_ascii) { lcd.setCursor(5, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } void _write_to_digit_six(unsigned char my_ascii) { lcd.setCursor(6, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } /* Last digit on Display far right*/ void _write_to_digit_seven(unsigned char my_ascii) { lcd.setCursor(7, 0); lcd.write(my_ascii); delay(1); delay(1); _my_WR(); } DCS-BIOS 0.5.0, DCS-BIOS Arduino Library 0.2.3. Can you get a simple example (e.g. the MasterCaution example sketch) running, to make sure that the data is getting to your Arduino board? Do you see the RX LED flashing? I don't think it's the wiring, because you said writing characters in your setup() function works as expected.

The CH340 chip is no problem under Windows (IIRC Windows 10 installs the correct driver automatically without user intervention). The guy who had problems was apparently using a certain version of Mac OS. Under Linux it's recognized out of the box as well. If you buy an Uno or Mega with the CH340, be aware that you can't use it as a HID device, because that's done by reprogramming the ATMega16U2 that usually does USB-to-serial on these boards. For use with DCS-BIOS, the only difference that a CH340 chip makes is that you save some money.

Hi cBass, I can't see anything wrong with the code you posted. (The while loop does not need to be there, but wouldn't harm anything either.) newValue is a 7-character C-style string (i.e. a character pointer to the first of seven bytes, followed by a null terminator). After one or more new characters have been received from DCS, when the complete update has been processed (so the local copy of the string is known to be in a consistent state), the StringBuffer class will call the onUhfFrequencyChange callback function once with the new value of the string. Please post the complete sketch and tell me the model of Arduino board you are using (I guess it's a Mega because of PORTK?). I assume you have tested your _write_to_digit_n functions independently and they are known to work. Which version of the Arduino library are you using?

You might want to read up on the difference between DCS and DCS-BIOS. :doh: DCS being the flight simulator developed by Eagle Dynamics, and DCS-BIOS being an add-on that adds connectivity to Arduino-based hardware panels.

If you want to choose a decent low-cost multimeter, there are many excellent resources on the internet, such as and . But what if you want to spend even less and don't care if the thing might blow up if you try to measure a wall outlet because all you want to do is basic electronics work? Shopping for any multimeter without relying on reviews is a challenge, because one of the most important questions is not answered by the spec sheet: does it have a decent continuity tester? After all, it will likely be the function you use the most. If you have a crappy continuity tester, you might miss a short caused by a small solder bridge or a tiny bit of copper shaving that's hard to spot with the naked eye. If you want to see the difference between horrible and excellent continuity test modes, see and . I can recommend the Uni-T UT136B if you are looking for a cheap meter that is sufficient for working on your Arduino-powered panels. It's available from eBay or AliExpress for less than $20 shipped. I got one after stumbling upon this thread on the EEVBlog forums. Pros: auto ranging the continuity tester, while "scratchy" due to not being latched, is reasonably fast usable tilting bale (depending on the surface of your table you may need two hands to adjust the range switch, but the meter won't fall over easily just from a small tug on the probe leads) The frequency measurement function can be handy to verify that a DCS-BIOS RS-485 bus is working by measuring the TXENABLE pin on a slave device (using the multimeter for a quick check is more convenient than breaking out your logic analyzer or oscilloscope) accurate enough (you don't need more than 4000 counts for this kind of work) milliamp range measures up to 400 mA (many other low-cost meters force you to the 10A range above 200 mA already), that should be good enough to decide if you need an external power supply for your Arduino or if you can still power it over USB Cons: At this price, I wouldn't trust the claimed safety rating (CAT II 600V), so only use this for low-voltage work To get to the continuity test mode, you have to select diode test and then press the SELECT button, which is acknowledged by a short beep. But I guess you get used to the extra step and if you are in an environment where that acknowledgement beep would annoy other people, you wouldn't use the continuity buzzer anyway. The test voltage on the diode test mode is not high enough for LEDs On my unit, one of the input jacks wobbles slightly

There is no debouncing logic in the DCS-BIOS Arduino library right now. It simply did not come up with the type of push buttons I used for my tests. The physical signal on the Arduino's input pin will bounce for a certain time after a change (how long that time is mostly depends on the mechanical construction of the switch in question). The logical signal (that the Arduino passes on to DCS-BIOS) will bounce if the Arduino happens to sample the physical signal twice during such a "bounce window". There are several ways to avoid this: Option A: Decrease the overall polling rate. If the signal is bouncing for 2 ms but is only checked once every 20 ms, there won't be any problems. Option B: Only decrease the polling rate after a change has been detected (i.e. after detecting a change, stop checking for changes for a certain amount of time). Option C: like B, but only stop checking for the specific control where the input changed A crude version of option A can be easily implemented by calling the delay() function from your loop() function. It's not ideal, because that delay time could be used to update outputs, but it probably won't be noticeable for reasonably small delays. Option B would need a change in the DCS-BIOS Arduino library internals so that classes like Switch2Pos can tell the rest of the system "please add a debounce delay now". Option C needs an individual debounce timer for each control, which needs more memory. Memory is a limited resource on the ATMega328 (we only have 2048 bytes), but the vast majority of panels should have enough to hold debounce timers for all inputs. I'll probably implement option B at some point, but I'd like to focus on improvements to DCS-BIOS itself first.

In this case, the Arduino is acting as a HID device, so it will show up just like another joystick. Through Helios flexible mapping system, it should be possible to get most inputs to work (even rotaty encoders if you assign different joystick buttons for different directions). If you want any outputs (LEDs, steppers, etc) you will need to use EOS (or something else supported by Helios, such as Phidgets boards).

Du musst nach dem Einschalten der CDU vier Minuten warten, bis das Navigationssystem kalibriert wurde. Danach wechselt die Anzeige von "ALN UNS" ("alignment unsure"?) auf "ALN RDY".

[ame] [/ame] If we assume that your camera is looking straight down, has a 50 degree field of view, and makes circular instead of rectangular photos, it will see an area in the shape of a circle -- the intersection between a cone projected by the camera and the ground. Half of that cone is a triangle with a right angle and we know the altitude and the field of view of the camera, so we can use trigonometry to figure out the radius of that circle. aircraft * /|\ - /ɑ| \ | / | \ | / | \ | altitude / | \ | / | \ | +======+======+ - |------| r tan(ɑ) = r / altitude r = tan(ɑ) * altitude In your example, the angle alpha would be 25 degrees (half of the field of view). In Lua, like in most programming languages, the trigonometric functions use degrees instead of radians, so you have to factor in a conversion factor: function getReconCircleRadius(fovAngleDegree, altitude) local fovAngleRadians = fovAngleDegree / 180 * math.pi local halfFovAngleRadians = fovAngleRadians / 2 return math.tan(halfFovAngleRadians) * altitude end

I was quoting your text, but I was limiting my quotes to what was on the Kickstarter page, since that's the one that has the button to back your project and it doesn't link to this thread. Thanks for posting that update to the Kickstarter page, even if the main description remained the same. Regarding "The board is Arduno which is USB plug& play.": [ame] [/ame] I'll shut up now.

If someone who is not already familiar with DCS-BIOS reads the following statements from the Kickstarter page, they will assume that they won't have to do any configuration steps themselves: It's no unreasonable assumption, as a panel driven by a Leo Bodnar board would fit this description, and you could even imagine a version of DCS-BIOS that would use something like USB HID instead of serial ports and could autodiscover newly connected devices. But while it's a reasonable assumption in the absence of other information, that's not how DCS-BIOS actually works. The Kickstarter page does not mention Windows changing COM port numbers behind your back, the need to edit connect-serial-port.cmd, or the need to manually run connect-serial-port.cmd before running DCS. The Kickstarter page says "For issues regarding DCS-BIOS visit the ED-forums." That means that if this project attracts any users who expect to be spoon-fed, they will find the DCS-BIOS thread and I will have to deal with them. And I know from prior experience that this can be very annoying and take all of the fun out of writing software. There would be an easy way to avoid this problem: honestly state up front what the user is expected to learn and configure by themselves. I have not seen a single argument defending the claim that the panel advertised on Kickstarter will be "plug and play"; instead, there were the following arguments (paraphrased): The Vive isn't quite plug and play either, but it's still a great product! I know DCS-BIOS requires some fiddling, so my kickstarter backers, whom I didn't warn about that on the product page, should know that too I already knew what DCS-BIOS was before reading the Kickstarter page, so anyone else should, too Plug and play means not having to solder the switches (no, it doesn't.) As long as there seems to be no genuine interest in honestly letting the backers know what to expect, any significant success of this crowdfunding campaign carries the risk of flooding me with clueless, entitled "support calls". If you want to thank me for building DCS-BIOS, please do so by not misrepresenting its capabilities.

It would help if you'd post your code. Also, are you testing this in SP or MP? Any errors being reported with message boxes or in dcs.log?

Did the main thread disappear? Clicking the link in the first post yields an error message: "Invalid Thread specified. If you followed a valid link, please notify the administrator" EDIT: that was probably a side effect of the two threads being merged.

It probably doesn't delete the old version because the ZIP files have different names. Check in your My Documents\Arduino\libraries folder and make sure there is only one version. The change from 0.2.3 to 0.2.4 only had a minor bugfix that did not affect the protocol, so if your existing panels already work you won't have to recompile and reflash.

At the moment, I try to support about five different configurations: DEFAULT_SERIAL on ATMega328 and ATMega2560 (if it works on one, it should work on the other, as it only depends on the standard Arduino Serial library) IRQ_SERIAL on ATMega328 RS485_SLAVE on ATMega328 IRQ_SERIAL on ATMega2560 RS485_SLAVE on ATMega2560 I don't plan to add to that list any time soon. Every additional entry on that list means more time spent testing and less time spent implementing new features. I added the Mega because it has about the same price/performance ratio as the equivalent number of GPIO pins in Arduino Nanos, several people had already started building with the Mega before I switched to interrupt-driven comms, and it was similar enough to the ATMega328 (same architecture, just different names for the peripherals, i.e. USART0 instead of USART) that it required relatively little effort to implement. The Due is an ARM processor, where dealing with the serial port will probably work differently enough that I can't use the same code. And an ARM processor is overkill for the kind of panels DCS-BIOS enables, with the possible exception of drawing the CDU on a 320x240 graphic display. The Due should work in DCSBIOS_DEFAULT_SERIAL mode, with the limitations that mode brings with it (i.e. possible data corruption when dealing with too many outputs or outputs that take a long time to update, like displays). Because the Due has a lot more RAM, it can probably deal with DEFAULT_SERIAL mode a lot better due to a larger receive buffer.

Released v0.2.4 of the Arduino Library. fix DcsBios::ActionButton (buttons would get stuck) fix DCSBIOS_RS485_SLAVE on ATMega328 controllers Please post comments in the DCS-BIOS Discussion Thread.

What bugs me is that the Kickstarter page makes false claims about the capabilities of my software. I don't want to deal with support queries from angry users who expect DCS-BIOS to be something it is not. I enjoy supporting people who are curious and eager to learn. But dealing with people who expect me to spoon-feed them everything because they refuse to read the manual ("but the guy said it would be plug and play!") will be very frustrating. At a certain point, I can ignore them, but I have to deal with them at least long enough to distinguish between "this guy is lazy" and "might just be a language barrier". The Kickstarter campaign page tries to appeal to people who don't want to learn how to build and program these boards by claiming the product is plug and play. Such claims will create the type of user that I don't want to deal with. This is false. DCS-BIOS does not enable plug-and-play operation of those panels. The user has to learn a few things about how DCS-BIOS works and do a little work themselves to get the panel to run. This part is advertising a feature as working and finished that is still very experimental. As far as I know, no one has tested this with more than two or three panels yet, and currently there is a bug that prevents it from working entirely. There is a reason this feature is not even mentioned in the User Guide yet. I am fine with people using DCS-BIOS for commercial purposes, but please do it in a way that does not create more frustrating work for myself.

You are, but someone who just reads through your Kickstarter campaign page isn't. You make it sound like they don't have to learn about these things, it even has "plug and play" in the project name! Nothing wrong with that, but if you advertise "plug and play" those things become your responsibility. I admit I don't know much about CNC machines, but I think if you break two or more drill bits while milling a single copper clad board, you are doing something wrong. It can be made safe from the taxman, but the amount of paperwork required to do this is not worth it. Why? To save money compared to building myself? Arduino Nano (including the USB cable) for $2.48 20 toggle switches for $6.26 10 potentiometers for $2.90 10 potentiometer knobs for $0.88 10x MAX487CPA for $1.20 That's all of the neccessary components for $13.72, which is about $11.28 below your kit price. That still doesn't include the PCB, which will be about $30 shipped for 5 pieces, but if we are not going for accurate dimensions anyway I might as well build it on Veroboard. I don't think your kit price is too high, but I do think that to compete with DIY, you will have to offer something that I can't build myself for less with components to spare afterwards. Maybe offer a custom CNC-engraved faceplate or something. The other possible reason to back your kickstarter is to help you start your business, in case I am interested in your future products. To do that, you'd have to convince me that you will be able to achieve your goals, i.e. that you know what you are doing. You seem to be a business analyst who is just getting started with electronics. Nothing wrong with that, but being able to build a basic panel and being able to bring an electronics product to market are two very different things. There is no information at all about the other guy's (Lodewijk) qualifications. The domain that you have printed on the silkscreen of your board is not even registered. Do you have so little faith in your own success that you are not willing to invest the small fee for a one year domain registration? You also did not address any of my previous comments regarding regulatory compliance. Yes, you can ignore all of those and hope for the best, and it will probably work, but if that's your plan you should add "might get sued into oblivion" and "product may be held and/or destroyed by customs due to lack of CE certification" to the "Risks and challenges" section on your kickstarter page. And then there is the part about helping kids in Africa that just made me go WTF? You won't help anyone by teaching them about "electronics and flight simulators", because there is no money to be made there. The market is just too small. Consider this: Saitek is certainly using mass production for their switch panel, and at about 120 Euros it's still considered expensive by a lot of people. They are targeting the market of all FSX users. Projects like yours are targeting a subset of DCS users that fly a particular airframe. You won't be able to bring the price down through mass production.

For the curious, here's a link to the kickstarter project page that avoids this forum's auto-embedding feature. Please don't call DCS-BIOS "plug and play". It is not. The TM Warthog is "plug and play" with the A-10C in DCS: World -- the user plugs it in, starts DCS, and it works. A preprogrammed Arduino board is not "plug and play", even if we assume DCS-BIOS is already installed (which may require manual editing of Export.lua and messing with firewall rules). The user will have to learn about serial ports, find out which COM port the Arduino Nano is connected to, edit a batch file, manually run that every time he starts DCS, and even if it works once it may break again later because Windows decides to change the COM port number. I encourage the use of DCS-BIOS in products like this, but I'd like to avoid setting false expectations. DCS-BIOS is far from the point where the user doesn't have to learn about its inner workings to use it. It is also still at the "proof-of-concept" phase and everything is subject to change in the future, so the sketch on that Arduino may require multiple updates if you want that panel to continue working years from now.