sinistar

Hey there - recent F16 and Orion purchase, and this guide was a great resource for calibrating the AB. One question - I notice if I look in-cockpit at the throttle animation, the throttle will lift as it is moved forward. I assume this is the first part of going into AB? The guide refers to looking at the back of the jet in external view to determine when you have enabled AB, but I'm actually not sure when the AB is considered "lit". At one point, the inner portion of the engine begins to glow, and then with further advance the characteristic flames start. I notice that the lifting of the throttle in the cockpit (animation) seems to correspond to the initial glow in the engine. I guess the TL;DR of this: as I currently have things calibrated, the in-cockit animation of the throttle does it's "lift" before my WinWing hits the MIL/AB detent. Perhaps I should back that down a bit?

If I pick up a crate via the crew / rearm-refuel menu and move it to another location via a sling, when I drop the load it goes bouncing up into the air. I cannot seem to get it to sit properly even when my crew tells me ok to release.

Thanks for the advice and updates all. I'm now convinced I have a defective unit and will be asking for a refund.

I just recieved my AB9 and proceeded to unbox, mount and connect up to my sim-pit. I then downloaded the Cockpit software from Moza, ran that guy and proceeded with a firmware update (now v1.1.1.30). (As an aside, I am using my Warthog grip - which interestingly, the Moza Cockpit reports as a MH16) I configured my path from DCS from within the Cockpit software, and then just picked a random aircraft from the DCS Preset menu (I wanted to fly the Chinook, and realize that I'll have to make my own preset at some point). Note that the basic settings all have "Integrated FFB" as their selection. I then launched DCS (from the "launcher" within the Moza Cockpit) and brought up the main menu options - noting that the Misc->Force Feedback was already selected. Under Special->CH-47F, I tried both Trimmer Modes of "Default" and "No springs and FFB" with equal (no joy) results When I launch into an airframe, the controls work for about a second, and then after all the graphics render in, the controls freeze and the joystick inputs have no effect. Bringing up the controls menu, I see there are two columns for the MOZA AB9 (see screen shot). Any idea why? Also, back to the Moza Cockpit software, the display showing the input values is no longer registering any control inputs. If I quit DCS, the Cockpit software still does not register any inputs. It is almost like DCS causes something to hiccup. The only way I can get the inputs to register again (in Moza Cockpit) is to either power cycle the base, or unplug/plug the base's USB connection. Do any of you AB9 users have multiple columns in the control setup screen for the AB9? null

I am seeing very similar issues. Has there been any solution?

Yeah, I just don't know how patient is reasonable - and not sure on the PayPal policies on contesting a non-delivered product. However, thanks for the comment!

Hello all, I sent BuddyFox PayPal funds early this month (January, 2023). I received a confirmation email within a day, but haven't heard anything since - and have not received the product (UFC). I have tried contacting them - both from the website, and also responding to the confirmation email, without any answer. Has anyone recently dealt with them? I know I can file a report with PayPal, but I really don't want to: a- Cause any strife for BuddyFox, as I know they are a small company b- I really want that UFC! Any/all advice appreciated.

I had this issue happen to me twice a few nights ago while landing on the Syria (Al Minhad - runway 09) map on the Hoggit server. The first time, the issue was egregious enough that I had to abort the landing and go around, the second time it wasn't as pronounced and I was able to land on the first attempt.

Has anything ever come of fixing the brightness on the clock and UHF repeater? Holy cow those are bright.

Man am I frustrated. I purchased the MFG pedals a number of months ago and have been battling them on-and-off for quite some time. Things have now gotten so bad that they are basically unusable. I'm not getting much support from MFG - just suggestions on things I have already done/tried. Here are the different hardware configurations I have tried: Pedals plugged direct into MoBo Pedals plugged into Atollo powered USB hub Pedals plugged into VanTec higher powered USB hub I have tried two different USB cables I have also gone through the firmware update process on the pedals After all of this, I still have regular disconnect/reconnect while in-game. A message pops up in the upper-right corner of the DCS window (see screenshot). Most of the time, the disconnect is quickly followed by a connect message, although sometimes they don't reconnect and I have to manually unplug/plug. I feel as if this is somehow related to the querying of the pedals by the game itself, because during other uses of the computer, I don't see/here the USB connection messages. I'm hoping someone has some thoughts on what can be done? I've asked MFG for more help and/or a replacement unit, but now I feel as if they are ghosting me.

I'm going a little deep on this because I'm seeing things which don't appear to fit that model all of the time. One of my confusing situations shows up while monitoring the bottom line of the CDU - that with the blinking cursor (line 9). I would expect to see about two calls to that update every second (cursor-on / cursor-off) which is the case most of the time. However, every so often (maybe once every 5 blinks) there is an extra call to that update function. This has lead me into the danger zone of trying to understand more fully what the dataflow looks like from DCS to my serial-port connected Arduino, and as a side effect, understanding better the program flow. Unfortunately, my C++ experience is very limited which is making my research more difficult. I suppose my next route will take me into understanding the StringBuffer class defined within ExportStreamListener.h: template < unsigned int LENGTH > class StringBuffer : public ExportStreamListener { private: char receivingBuffer[LENGTH+1]; char userBuffer[LENGTH+1]; volatile bool receivingDirty; bool userDirty; void (*callback)(char*); void setChar(unsigned int index, unsigned char value) { // DCS-BIOS will occasionally send data even if it did not change if (receivingBuffer[index] == value) return; receivingBuffer[index] = value; receivingDirty = true; } public: StringBuffer(unsigned int address, void (*callback)(char*)) : ExportStreamListener(address, address+LENGTH) { memset(receivingBuffer, ' ', LENGTH-1); receivingBuffer[LENGTH] = '\0'; userBuffer[LENGTH] = '\0'; receivingDirty = false; userDirty = false; this->callback = callback; } virtual void onDcsBiosWrite(unsigned int address, unsigned int data) { unsigned int index = address - firstAddressOfInterest; setChar(index, ((char*)&data)[0] ); index++; if (LENGTH > index) { setChar(index, ((char*)&data)[1] ); } } virtual void onConsistentData() { if (receivingDirty) { noInterrupts(); memcpy(userBuffer, receivingBuffer, LENGTH); receivingDirty = false; userDirty = true; interrupts(); } } bool hasUpdatedData() { return userDirty; } char* getData() { userDirty = false; return userBuffer; } virtual void loop() { if (hasUpdatedData()) { if (callback) { callback(getData()); } } } };

Thanks - it is becoming clearer now! Are there any docs explaining the structure of that "stream" - the specifics of the CDU display (line 8 ) starting at 0x1280 for example.

Hello community, I am looking for a bit of guidance in terms of the DCS-BIOS "API". Specifically the calls associated with the CDU display. It seems that the common model for gathering CDU display data is code like this: void onCduLine8Change(char* newValue) { printLine(8,0,newValue); } DcsBios::StringBuffer<24> cduLine8Buffer(0x1280, onCduLine8Change); Where the function "printLine" is defined by the user something like: void printLine(int row, int col, char* newValue) { int16_t y = row * 32 + 6; mylcd.Print_String(newValue,CENTER,y); } (This will be slightly different depending on the display library used for the particular TFT) I guess my fundamental issue is that I am not very comfortable with C++ syntax, so am confused as to what this particular line is doing: DcsBios::StringBuffer<24> cduLine8Buffer(0x1280, onCduLine8Change); To my untrained brain, this looks like a function(method) definition of type StringBuffer<24> (inherited from the DcsBios class), but I don't think that is correct? How would it be called? Also, any hints as to the two parameters passed into that function? The first looks like some type of offset(0x1280), while the second seems to be a reference to the function just declared above this call.

This looks like great work - Kudos! With regards to the project zip file you uploaded @jj3 , what software did you use to create it?

@Tippis, can you elaborate a bit on "adding a custom radio setting file to the mission"? I'm not sure how to do that. Our squadron _really_ needs a common set of presets for our hawgs...