FSFIan
-
Posts
1301 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Events
Posts posted by FSFIan
-
-
Your code snippet has to return a value to be displayed in the Lua console.
If the value can be converted to JSON (i.e. it does not contain functions or userdata, and if it is a table, the keys are either only strings or only integers), the Lua console will be able to display it. So for your example:
return GetDevice(0):get_argument_value(12)
will work.
If it doesn't, you need to follow the comments in WitchcraftExport.lua to connect to the Export environment instead of the Mission environment.
If you get an error that something cannot be converted to JSON, convert it to a string on the Lua side:
return tostring(some_other_value)
You'll probably want to replace tostring() with a function that serializes Lua tables. You can copy the functions from MiST and evaluate them in the Export.lua environment to make it available, then use something like "return mist.utils.tableShow(_G)".
-
Yes, this is possible.
1. Figure out the data format of the binary string (binary coded decimal? gray code? ...)
2. Read the value from the physical UHF radio from an Arduino sketch
3. In your Arduino sketch, figure out the position of each of the three frequency selector knobs from the value you got from your physical UHF radio
4. send those selector positions to DCS with DCS-BIOS
If you want help with that, we should meet up on Discord some time. I plan to hang out in the DCS-BIOS Discord server on Sunday. PM me if you want to set up another time.
I am pretty sure we can get this working in about an hour.
-
This problem can happen with Arduino libraries that still have (unused) debugging code left in them that uses the serial port.
Open the code files for the SevenSegmentTM1637 library and comment out every line that uses the Arduino's Serial class, such as "Serial.begin" or "Serial.print".
In IRQ_SERIAL and RS485 modes, the DCS-BIOS Arduino library supplies its own driver for the UART peripheral which conflicts with the standard Arduino libraries. As soon as any other code references the default Serial class, you get a compile error (because both implementations want to handle the serial RX and TX interrupts), even if that code is never reached.
-
Your switch contacts are probably bouncing. See here for a solution:
-
So wait, can the Mega not be used as an actual DCS-Bios board while acting as the Master?
That is correct.
The protocol that I am using over the RS-485 bus has some tight timing requirements. Because of that, I had to simplify the code that looks at the incoming export data. It only determines where an update begins and ends; there is not enough CPU time left to determine whether the master board has any outputs that need to react to a particular piece of information.
At this time, I am not even sure if there is enough CPU time to run three RS-485 buses at once reliably.
In other words: the 16 MHz CPU on the bus master spends all of its time juggling four different communication channels (one to the PC and three to the RS-485 buses), so it doesn't have time to handle anything else.
-
Your mechanical switch is likely bouncing.
Right now there isn't a really good way to do proper per-control debouncing in the DCS-BIOS Arduino library, but here's a crude but effective way to do it for all inputs: add a call to delay() to your loop() function. I'd suggest starting with 10 milliseconds and increasing in steps of 5 ms until the behavior improves.
void loop() { DcsBios::loop(); delay(10); }If you have a logic analyzer or an oscilloscope, you could also measure the duration of the bounce so you don't need to use trial and error to determine the delay.
If you don't have a logic analyzer, I suggest typing the magic words "24Mhz 8Ch" into the search function of eBay or AliExpress and ordering a logic analyzer and some test clips. These work with the open-source sigrok software (http://sigrok.org). The clips are annoying to use on anything smaller than 0.1 inch pitch pins, and they might have issues with longer captures at the full 24 MHz, but they are still incredibly useful tools for debugging and learning about digital logic circuits and you can get one for about $10 :)
-
From this:
display.showNumberDec(newValue);
newValue is understood as an integer, but your function returns a char type.
So if you would need to convert. Usually writting something like :
display.showNumberDec(newValue[0]);
you would indicate that you want the char value of this integer.
My 2 cents
newValue[0] is the first character of that string. If you pass that to a function that expects a number, it will just display the ASCII value of that character.
If you use the "print" function (which expects to deal with characters) instead of "showNumberDec", it should behave correctly, including blanking the display when there is a space (IIRC the display is blank when there is no electrical power available).
-
The switch statement in C++ jumps to the first 'case' statement that matches and starts executing the code there. It then continues executing statements within the same switch...case construct until
(a) the end of the switch...case block,
(b) or any statement that causes the control flow to leave the current block of code, such as break, continue or return.
In general, it's always a good idea to add a break; after every case, even if it is the last case in the statement, just so you don't forget when you add another case later.
If you have a switch statement with a single case, you might as well use an if statement instead.
Technically, Tekkx's variant (one switch statement) and Hansolo's (two switch statements) are not interchangeable because one calls keypad.getState() once and the other calls it twice. But as that function just returns the result of the last matrix scan, the difference in execution time would be measured in nanoseconds.
-
The one in the original post (invite code 29mF3Xn) is listed with an infinite lifetime in my discord app. Which Link did you use?
-
A continuous rotation servo motor will need some form of additional position feedback (such as a separate rotary encoder on the same shaft) to make a closed loop control. It makes the mechanical construction and the required software more complex compared to a stepper motor.
For applications that rotate over a limited range, a servo is easier to use, although it may be noisier and less precise than a stepper motor.
-
Released DCS-BIOS v0.7.1.
Changes from 0.7.1:
- fixes for the Mi-8 ARC-9 radio by ArturDCS
- fixed a bug in connect-serial-port.cmd that caused communication between PC and Arduino to fail because the baudrate was not set correctly
For comments and general feedback use the DCS-BIOS Discussion Thread. If you need help or have found a bug, please open a new thread in the Home Cockpits forum or find me on the DCS-BIOS Discord server.
- fixes for the Mi-8 ARC-9 radio by ArturDCS
-
hi,before connected, I removed hard interlock pin and this stepper free rotate 360 degree.
You know that, but the code doesn't. It still assumes it is controlling a Vid29 motor, which does have the hard stop.
You have to use the code for the Vid60 motor, as that has been written for continuous rotation steppers.
-
Hi everyone,
DCS-BIOS now has a Discord server: https://discord.gg/29mF3Xn
I'll try to monitor this whenever I can. I invite you to hang out there while you work on your simpits, nag me about bug reports I have missed, or pick my brain about DCS-BIOS, Arduino boards and digital electronics in general.
As some of you have probably noticed, the pace of DCS-BIOS development has gradually ground to a halt over the last year or two and my response times to questions have gotten worse. Long story short: I lost any enthusiasm I had to think about formal topics that I could not apply in practice and studying Computer Science got frustrating and depressing as a result. Since I already had my BSc degree, I decided to stop working on my Masters degree and get a job. Since the beginning of October I am working full time doing 2nd level support for a web hosting company.
Here's what this means for DCS-BIOS:
- The quality of the time I get to spend on DCS-BIOS has improved, because my day job does not involve programming anymore so it is not competing for the exact same brain resources I need to work on DCS-BIOS. When I am at home, I get to do whatever I am awake enough to do instead of worrying about some upcoming exam or unfixed bug.
- The amount of time I get to spend on DCS-BIOS has decreased, and I only get longer uninterrupted time slots on weekends and holidays.
The most fun I had with DCS-BIOS has always been talking to WarHog using TeamViewer or Skype, discussing the circuits and Arduino sketches for different panels. This also happens to be something I can still do reasonably well after an 8-hour work day.
I want to talk to more of you more often. A lot of problems are also easier to solve in an interactive conversation than over a web forum.
Discord has released a screen sharing feature recently. This offers an easy way to transition from a public voice chat room into a direct message with video chat or screen sharing, which can come in handy to track down bugs that I cannot reproduce on my machine.
I'll try to hang out on that Discord server after work and on the weekends whenever I can.
This week and the next I am on early shift, so "after work" means somewhere between 15:00 and 19:00 UTC.
Otherwise the typical "after work" times will be between 18:00 and 22:00 UTC.
I plan to get some version of DCS-BIOS 2.0 finished and released before the end of 2018. I have gotten used to the new job by now, have cleaned up my desk to the point where I have space for some electronics again, and plan to get a look at some of the outstanding bugs on the weekend.
-
1
- The quality of the time I get to spend on DCS-BIOS has improved, because my day job does not involve programming anymore so it is not competing for the exact same brain resources I need to work on DCS-BIOS. When I am at home, I get to do whatever I am awake enough to do instead of worrying about some upcoming exam or unfixed bug.
-
The Uno will work fine with DCS-BIOS. But for the purposes of building a simpit, I'd use an Arduino Nano instead. It's basically an Uno in a smaller form factor. You get two additional analog-only pins (A6 and A7) because it uses a SMD package for the microcontroller. It's cheaper because it uses a smaller PCB and less through-hole components which have to be manually soldered (the mini USB jack on the Nano is surface-mount and it does not have a barrel jack for V_in). The Nano can also be plugged straight into a breadboard.
The only disadvantage of the Nano is that you cannot attach Arduino Shields, but you won't need to do that anyway.
If you want to play around with Arduino Shields (which can be great for learning about Arduino or for quick prototypes), get a Mega 2560. It's only slightly more expensive than the Uno, has a lot more I/O pins, and can be used as an RS-485 bus master for DCS-BIOS.
-
The 5V pin on your Arduino is a power supply rail (i.e. that part of the circuit that is always at the supply voltage, +5V for most Arduino boards).
A general rule of thumb for power supply rails is this:
Exactly one power supply is connected to it, feeding an arbitrary number of consumers.
If you have more than one power supply active in parallel, they need to work together to regulate to the exact same voltage, otherwise the supply that is trying to regulate to the higher voltage will bear all of the load. Multiple parallel power supplies are thus only used for very high loads or if you need redundancy.
For your Arduino board, you have three options:
- Feed 7 to 12 V to the V_in pin. This supplies the linear regulator that is built in to your board, which in turn supplies 5 V to the power supply rail and needs to drop (V_in - 5V) * current_draw as heat to do so.
- Directly feed 5 V to the +5V pin, ignoring the built-in regulator. This is the best option if you already have a source of regulated 5V available.
- Keep the Arduino board connected to a PC over USB. It will power itself over USB. This option only works if the total draw from the 5V power supply on the Arduino board does not exceed about 400 to 500 mA, otherwise the polyfuse on the Arduino board will disconnect the board to avoid damage to the computer.
A 12V supply can be useful to power things that can work at 12 V, such as some backlight circuits and stepper motors. Those can be controlled from your 5 V Arduino through MOSFETs and stepper motor driver boards.
Using 12 V can also be useful if the length of your power supply lines becomes long enough so you have a signficant voltage drop (in this case you'd use it to feed a regulator that converts it to 5 V at the destination, using either the one on your Arduino board through the V_in pin or a separate one -- e.g. an LM7805 -- if you need more power). I don't expect that to be an issue in a typical home cockpit.
- Feed 7 to 12 V to the V_in pin. This supplies the linear regulator that is built in to your board, which in turn supplies 5 V to the power supply rail and needs to drop (V_in - 5V) * current_draw as heat to do so.
-
For the master, all you need to do is to upload the RS485Master example sketch to an Arduino Mega (and comment out some of the UARTn_TXENABLE_PIN lines if you connect less than three tansceivers).
RS-485 documentation is lacking right now because I never got around to properly testing all of that. I am still not sure if three transceivers on a Mega work reliably (two should be no problem at all).
If you know how an RS-485 bus works in general (so you know to connect all the "A" and "B" lines in a bus topology), the comments in the RS485Master and RS485Slave example sketches (which tell you how to connect the MAX487 transceiver chip to the Arduino) along with the MAX487 datasheet (which tells you the MAX487 pinout, where to connect 5V and GND, and that you should add a 100 nF capacitor between the two) is all you need to know.
For the master, you have to use an ATMega2560.
Slave devices can be anything with an ATMega328 or ATMega2560 chip.
For the power supply, I would recommend an old PC power supply (short the green wire on the motherboard connector to a black one to make it turn on). It is inexpensive or free to acquire and gives you several amps of cleanly regulated power at 12V, 5V and 3.3V.
Powering your Arduino boards from 5V (directly to the 5V pin) is better than 12V to the V_in pin, because you are not wasting energy in the linear regulator on the Arduino board and don't have to take its limitations into account.
If all you are running is the Arduino board itself (a few milliamps), you can power it from 12V without problems, but a linear regulator that converts 12V to 5V will waste 1.4 times its output power as heat, so if you add additional 5V loads, you can quickly reach its limits and make it go into thermal shutdown.
-
For driving a TFT display for the CDU over a SPI interface, I'd look into Arduino-compatible boards with an ARM processor. An ATMega328 can drive one, but you'll get a lot of lag when it has to push lots of pixels on a full display update (e.g. when switching to another page).
-
The board you linked is the cheapest way I know to get a MAX7219 chip. You can use it as-is if the size and color of the displays it comes with fits your needs, or you can desolder the existing 7-segment displays and just use the board as a cheap "MAX7219 breakout board".
If the pinouts and size match, you can solder your replacement displays to the same board. Otherwise I'd recommend stripboard / veroboard like CraigS did
The MAX7219 is definitely the way to go for driving 7-segment displays.
7-segment displays come in two variants: common anode and common cathode. The MAX7219 needs the common cathode type.
If you want to learn more about what the MAX7219 does, you can read its datasheet. I recommend taking a look at it even if you don't understand much of it -- over time you'll get used to how datasheets are laid out and be able to find the information you need when designing a new circuit.
-
If I understand correctly, you want to show a steady text while the master caution light is blinking and nothing when it is shut off.
There is nothing like that in the DCS cockpit, so you'll have to write some code that decides when you want to turn your message on and off.
DCS-BIOS gives you two pieces of information you can work with: the state of the master caution light and the state of the master caution button.
void onMasterCautionChange(unsigned int newValue) { // newValue is 0 if the master caution light is off, 1 if it is on } DcsBios::IntegerBuffer masterCautionBuffer(0x1012, 0x0800, 11, onMasterCautionChange); void onUfcMasterCautionChange(unsigned int newValue) { // newValue is 0 if the reset button is not pressed, 1 if it is pressed } DcsBios::IntegerBuffer ufcMasterCautionBuffer(0x10f2, 0x0008, 3, onUfcMasterCautionChange);With that information, you'd have to code some kind of time-out, i.e. turn the master caution message on when the master caution light illuminates, but only turn it off after it has either been off for some amount of time or the reset button has been pressed.
To see those code snippets, you have to use "Advanced" view in the control reference.
-
Here's how the MAX487 model numbers work. Let's use the MAX487CPA as an example.
"MAX487" -- chip identifier
"C" -- first letter: temperature range. "C" is consumer (0°C to 70°C), "E" is extended (-40°C to +85°C).
"PA" -- package. "PA" is 8-pin DIP (breadboard compatible, standard 0.1 inch pin pitch) and "SA" is 8-pin SOIC (0.05 inch pin pitch, surface mount package).
In general: you don't care about the first letter (the consumer temp. range is fine), and you want the last two to be either "PA" for the through-hole package or "SA" for the surface mount version depending on how you construct your panel. The chip is available in even smaller packages but those can be annoying to solder, and you are not that space constrained in a home cockpit, so why bother?
For the meaning of other letters, refer to the "ordering information" section in the MAX487 datasheet.
The maximum number of devices on one bus has no easy answer.
Standard RS-485 has a limit of 32 "unit loads" on the bus. The MAX487 is a 1/4 unit load device, so the maximum is 128 MAX487's on the same bus (assuming all transceivers are 1/4 unit load devices).
If you add termination and bias resistors (mandatory if your bus wiring gets longer than about 10 meters), they add a load to the bus and that limit shrinks to about 25.
Have a wiring length less than 10 meters? This app note talks about minimum spacing between transceivers. Assuming the worst case of the examples given, you may need 20 cm between each node, so a 10 meter cable would limit you to 50 devices.
In practice, I'd plan a cockpit as two or three RS-485 buses with about 10 to 40 MAX487 transceivers each, making sure that each bus length is less than 10 meters and not to add any termination or fail-safe resistors.
One Arduino Mega can handle at least two RS-485 buses, possibly three (I don't know if it is fast enough to do that yet, but the software will let you try).
Disclaimer: This is all theoretical, as far as I know nobody has tried it in practice at this scale yet.
But if everything is plugged in and it turns out that there are too many devices on a bus for reliable operation, you can always split it in the middle and add another Mega.
I expect a typical finished cockpit to use two to five USB ports: one, two or three Arduino Megas as RS-485 bus masters, and the rest for those cases where you use another Arduino-compatible board in DEFAULT_SERIAL mode because the IRQ_SERIAL code is not available (an example would be a board with a fast ARM processor to control a small TFT display for the CDU).
I hope this makes some sense, I wasn't very awake while I wrote this :D
-
Released DCS-BIOS v0.7.0.
Changes from 0.6.0:
- Added support for Bf 109 K-4, contributed by ArturDCS
- Added support for P-51D, contributed by pdmarsh
- Added support for L-39ZA, contributed by kadda11
Fixes and corrections:
by ArturDCS:
- FW-190D: corrected several instruments (see commit 47c47417b0bddc5b1c77e0567eca563bb18afd84)
- Mi-8MT: changed SPU-7 category
by PrestaMath:
- UH-1H: fix RESET/TEST and BRIGHTNESS switches on the caution light panel
Thanks and my apologies to all the contributors who had to wait several weeks to get their changes merged. I have recently started working full time and am still experimenting with integrating DCS-BIOS into my new schedule.
For comments and general feedback use the DCS-BIOS Discussion Thread. If you need help or have found a bug, please open a new thread in the Home Cockpits forum.
- Added support for Bf 109 K-4, contributed by ArturDCS
-
Ok, that's really weird. You shouldn't have to edit anything -- the %COMPORT% will be replaced by the value in the COMPORT variable, which is 6.
Maybe it makes a difference that the mode command is now called twice?
Maybe the second mode command acts as a delay and prevents some kind of race condition?
I can only guess at the reason why this works, but I am glad you found a workaround.
-
so I added it to the .cmd file and now all is great
Thanks Ian
Ok, now I am confused. It's supposed to be in that file to begin with, right before the socat command...
-
Well I guess I spoke a little too soon but I did find out EXACTLY what to ask this time. Might make a new thread in case this one gets overlooked thinking it is resolved. So here is what is happenning.
If I boot up, run the cmd file - doesn't work
BUT
If I open arduino, run the serial monitor, set baud to 250000 and test, then run cmd, works great.
So what can I alter to let it run without having to monitor the serial every time?
Thanks
Open a command prompt, execute the following command (replacing COM1 with some COM port that exists on your system) and post the result:
mode COM1 BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=off
That command is used by connect-serial-port.cmd to set the baud rate. It's probably failing for some reason.
A 3D view for the DCS: World 1.5 Open Beta Mission Editor
in Mission Editor
Posted
The instructions on GitHub tell you how to configure one of your two DCS installs to use a different Saved Games folder.
MiST refers to the Mission Scripting Tools, a very useful utility library for people who use Lua scripts in their missions. It is used as part of the mission that runs in the viewer installation. You don't need to install it separately, it is incorporated into the .miz files.