bnepethomas

Given I'm got a physical pit, and exploring this option right now, tell me more: 1: Did you use a short throw projector for the 90 view? 2: Whats the diameter of the curved screen? 3: And how much is this likely to cost to ship to Oz? Cheers Peter

Is this different to the earlier material you had been using? Cheers Peter

Hi Hans Check out my code, it throws the information out via UDP. Cheers Peter

Another nice piece of work overpro, loaded it all up today, and it worked like a charm, instructions on the money, awesome work, and thanks again. Cheers Peter

HI Guss are you up for an update to 1.2.7? cheers Peter

Hi I'd suggest sticking with the 'standard' LUA export where the right data it is available, hopefully that won't leave you up the creek if DCS changes something under the covers. cheers Peter

Nice work cheers Peter

Great to see, Crivi did the hard lifting, I just supplied the duct-tape :)

Great to hear you've got it running. Correct - Thread.sleep is your friend, what I did I was start with something very large (eg 500mS) and then started dialing it back. You may also want to check that the COM port is running at max speed, i.e. not 9600bps cheers Peter

I'm thinking/hoping you won't need to change the code too much. This chunk of code is a simple mod of Crivi's code - it grabs the data and exports it over UDP to the filter. This means different programs are isolated from one another meaning it shouldn't matter if one is 64 bit and another is 32 bit. My goal is to minimise any changes to Crivi's code so that is easy to update to whatever other goodies come along. I basically do two things, I use text to speech to inform me when the code has found the A10 running, and when the search completes, and then for each cycle, I grab the data from text boxes and throw it into a UDP packet. I've basically just got the code going and haven't bothered cleaning it up, as its been a year building, and now I want to do some flying :) https://code.google.com/p/bne-dcs-extract-master/ The filter listens on a UDP port on the same PC, it looks at the data received from Crivi's code and only forwards the data if it is different from the last packet, reducing the load further downstream. https://code.google.com/p/bne-ocr-oled/ The final piece of c# code looks for a "9999=" in the data, if its there, then looks for CMSP or CMSC, and throws the data at the display. All this runs on a single PC, and generates practically no CPU load. I don't think you'll need any ethernet shields as you can pass the data over the serial port to the board (which is what I'm doing). You need need to remember to insert some delay in the c# code so you don't overwhelm the serial interface. I found delays of around 50mS seem to work well for me. I have a bit of a twist in my code as I hadn't a circuit to enable me to drive 7 displays off a single Arduino, but that can be removed if only a single display is connected to the board. cheers Peter

What I did was slightly modify Crivi's framework - Here's the modified copy https://code.google.com/p/bne-dcs-extract-master/ Added speech alerts - so I knew when DCS had been discovered, and then when scanning is complete On each cycle then export values of text boxes in a UDP Packet to an intermediate filter The intermediate filter (which I need to upload) looks at deltas in displayed values and only sends differences, this reduces the load on the Ardunio. It sends the data over a UDP socket to the Ardunio receiver. Finally the Ardunio receiver https://code.google.com/p/bne-arduino-multi-oled-receiver/ Receives UDP packets, determines which display they should be displayed, and then throughs them down the comm port to the Ardunio. The Ardunio sketch is also in the project. I'll aim to upload the intermediate filter today. Cheers Peter

Awesome - things are now flashing, and I can also see the mode, thanks hugely! Time to roll it into the pit cheers Peter

and here's the result of your code, thanks again

Getting some flight time in the machine, as well as moved to Crivi's export program (which rocks!, http://forums.eagle.ru/showthread.php?t=120945). Also rearranged CMSC to put Chaff and Flare on separate lines as I only have a 16*2 oled display

Hi Crivi I finally got to test the flashing characters, still looks like we have may an issue. I'm using the exe and dll dated 9/3 4:42am but still see solid characters. Its still awesome that this exported, things are running awesome. If I could have for one more feature request, can we get the mode from the Chaff Flare Window - this isn't the A,B,C modes but the X, M, S, A that change as the mode switch is moved. Cheers Peter

Magic, thanks hugely for the quick fix. Being able to get at individual values has been really good. My CMSC is on 16 characters wide (will fix that one day), so being able to selectively trim different values is real useful. Cheers Peter

Awesome work - handles sim restarts beautifully as CMSP does what it should. Time for me to modify my OLED drivers to receive data from this. Only one little issue I've found (and again its nt a biggie) When programming the CMSP the characters flick on the value you are setting, currently the exported text stays solid. Again amazing work, Happy days - working like a charm, CMSP running,this will definitely get me a few fps, and is much more reliable than OCR. cheers Peter

Awesome I'll give it a run today. Thanks again Peter

Sorry, I should have been more specific I was hoping the be able to call an API so I can synch light state and levels from c#. cheers Peter

Hi Guys Anyone managed to work out how to control backlighting of the MFDs via S/W or API Cheers Peter

really nice work - loaded into the pit this morning to give it a run through. Once its finished searching there's no load on the CPU which is a really good thing. Couple of bugs/limitations/things to watch for: 1. Need to start the program once the sim is up and running. Not a biggie, but may be worth retrying every 5 seconds or so until the sim is found. That way you can start the program before getting into the sim 2. The CMSP (and I think CSMC) won't 'find' the display data if you launch the program when the EW panel is off, even if it is turned on later. Neither of these are reasons not to use this code, its a huge step forward, thanks again for sharing, really nice work. Cheers Peter

Sweet, so we can now get display information from cmsc/cmsp without resorting to OCR techniques? EDIT - DOH - should have looked at first page - nice work!!!!!! Cheers Peter

Hi Guys A quick update, basically I've been able use OverPro's code as is, all I did was modify screen locations, and IP address. I've pointed it to a pretty simple filter that wraps a header around it, and then send it to my existing OLED interface. Got a couple of kinks and error handling to work on, but its real nice to see the CMSP and CMSC come to life. Thanks again Overpro. Cheers Peter

Thanks for the pointer, I had an oldish USB video adapter, and was sitting there wondering what was going to blow up when I installed the driver, and had a light bulb moment. The MFD monitors are 1280*768, of which a third is hidden out of view, did the maths and discovered I can 'display' the CMSP and CSMC on the part of the MFD screen which is hidden behind the panel. cheers Peter