Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi Pete,

I'm not sure if you still support EPICINFO 4.22, but here is my issue:

It *appears* that scaling is not functioning correctly on at least

pitch and bank, I have not researched others as of yet.

Previous setup that seemed to work perfectly:

FS2002 w/patch

EPIC D card

EPICINFO 4.22

FSUIPC (older version, don't recall exact version)

New setup that does not work correctly:

FS2004 w/patch

EPIC USB firmware ver: 7.01

EPICINFO 4.22 (same Epicinfo.cfg as before)

FSUIPC 3.65

I have scaled roll thusly:

PLANE_BANK_DEGREES=Scale 361,-179,180

I am hoping for a number 0-360 but EPICINFO.LOG shows otherwise.

Ultimately I would like to scale it as PLANE_BANK_DEGREES=Scale 65536,-179,180 for a return of 0-65535, but that doesn't work either.

Here are the pertinate snippets of Epicinfo.log with the airplane in a roll to the left and samplings of data through the roll.

Am I doing something wrong???

Thanks,

James

********* EPICINFO Module, Version 4.22 (9DEC03) by Pete Dowson *********

Panel=AIRCRAFT\FA18\panel\panel.cfg

Epic Ref= Default

CFG: Reading C:\FS2004\EPICINFO.CFG

************************************************

CFG: Processing section [Default]

CFG: AxisReads=both

CFG: Log=2

CFG: SMCP=0

CFG: LogButtons=0

CFG: RESEND=511

CFG: Sets=MCP GPS

CFG: PLANE_PITCH_DEGREES=Scale 361,-179,180

CFG: PLANE_BANK_DEGREES=Scale 361,-179,180

EPICIO.DLL found: linking to it now ...

EPIC device USB0 Opened

453 SendQP(1, 100)

453 QP100 = Install Done

************************************************

453 SendQP(1, 103)

453 QP103 = Initialisation Done

453 PH013 = 079 001, 00179 [Hex 4F 01, B3 00], orig val=0 [0x0000000000000000] PLANE_BANK_DEGREES

453 PH014 = 079 001, 00179 [Hex 4F 01, B3 00], orig val=0.00203789 [0x3F60B1C500000000] PLANE_PITCH_DEGREES

1110 PH013 = 079 001, 00179 [Hex 4F 01, B3 00], orig val=0 [0x0000000000000000] PLANE_BANK_DEGREES

65500 PH013 = 088 001, 00188 [Hex 58 01, BC 00], orig val=7.57709 [0x401E4EEF63400000] PLANE_BANK_DEGREES

65641 PH013 = 090 001, 00190 [Hex 5A 01, BE 00], orig val=10.006 [0x40240311D9D00000] PLANE_BANK_DEGREES

66141 PH013 = 011 002, 00211 [Hex 0B 02, D3 00], orig val=30.8197 [0x403ED1D58FC80000] PLANE_BANK_DEGREES

66688 PH013 = 075 002, 00275 [Hex 4B 02, 13 01], orig val=95.0512 [0x4057C34645120000] PLANE_BANK_DEGREES

67141 PH013 = 050 003, 00350 [Hex 32 03, 5E 01], orig val=170.312 [0x406549F908540000] PLANE_BANK_DEGREES

67188 PH013 = 057 003, 00357 [Hex 39 03, 65 01], orig val=176.824 [0x40661A5E7DD50000] PLANE_BANK_DEGREES

67313 PH013 = 016 000, 32784 [Hex 10 00, 10 80], orig val=197.431 [0x4068ADC8E38D0000] PLANE_BANK_DEGREES

67407 PH013 = 030 000, 32798 [Hex 1E 00, 1E 80], orig val=211.348 [0x406A6B2689250000] PLANE_BANK_DEGREES

67813 PH013 = 097 000, 32865 [Hex 61 00, 61 80], orig val=278.26 [0x407164271F800000] PLANE_BANK_DEGREES

68282 PH013 = 071 001, 32939 [Hex 47 01, AB 80], orig val=351.631 [0x4075FA1791C68000] PLANE_BANK_DEGREES

68328 PH013 = 077 001, 32945 [Hex 4D 01, B1 80], orig val=358.417 [0x407666AB1EFC8000] PLANE_BANK_DEGREES

Posted

I'm not sure if you still support EPICINFO 4.22

Well, if I can remember enough I can. I can't test anything here though.

It *appears* that scaling is not functioning correctly on at least

pitch and bank, I have not researched others as of yet.

Previous setup that seemed to work perfectly:

FS2002 w/patch

EPIC D card

EPICINFO 4.22

FSUIPC (older version, don't recall exact version)

New setup that does not work correctly:

FS2004 w/patch

EPIC USB firmware ver: 7.01

EPICINFO 4.22 (same Epicinfo.cfg as before)

FSUIPC 3.65

Since EPICNFO is the same both times, and certainly FSUIPC's pitch and bank must be the same for FS2002 and FS2004 else things like the PM AI display would have gone wrong, I can't see where any of the changes could have affected anything ...

I have scaled roll thusly:

PLANE_BANK_DEGREES=Scale 361,-179,180

I had to read the docs to work out what that was supposed to do!

I am hoping for a number 0-360

Why 0 AND 360? Shouldn't you only have one or the other? Shouldn't your 361 be 360?

Here are the pertinate snippets of Epicinfo.log with the airplane in a roll to the left and samplings of data through the roll.

Let's see:

453 PH013 = 079 001, 00179 [Hex 4F 01, B3 00], orig val=0 [0x0000000000000000] PLANE_BANK_DEGREES

Original value = 0, which is 179 bigger than your minimum. According to the docs:

val you get = (Range * normalised value) / (max - min)

Your range is 361, your normalised value is 179, your (max-min) is 359, so

361 * 179 / 359 = 179 to nearest integer. Which is what you got.

Taking one more, for 'proof':

67188 PH013 = 057 003, 00357 [Hex 39 03, 65 01], orig val=176.824 [0x40661A5E7DD50000] PLANE_BANK_DEGREES

361 * (176.824 - (-179)) / 359 = 357.806, or 357 as an integer.

All the others work out correctly as well. As far as I can see this is all exactly and perfectly as it should be according to what you've set. Your values are all 0-360. What precisely is the problem?

Regards,

Pete

Posted

Pete,

The problem lies when roll exceeds 180 degrees and and is presumably a negative number. The "original value" shows correct, but the PH13 bytes 2&3 value still has the 32767 added. It is my understanding that the scaling would return a PH value from 0 through 359 in bytes 2&3 if scaled to 360.

James[/code]

Posted

The problem lies when roll exceeds 180 degrees and and is presumably a negative number. The "original value" shows correct

Maybe we could have been more productive here if you'd pointed out where your concern lay initially? ;-)

Anyway, I'm not sure how you work out that you are getting negative numbers. The original values in the log extracts you showed were all positive, look:

67313 PH013 = 016 000, 32784 [Hex 10 00, 10 80], orig val=197.431 [0x4068ADC8E38D0000] PLANE_BANK_DEGREES

67407 PH013 = 030 000, 32798 [Hex 1E 00, 1E 80], orig val=211.348 [0x406A6B2689250000] PLANE_BANK_DEGREES

67813 PH013 = 097 000, 32865 [Hex 61 00, 61 80], orig val=278.26 [0x407164271F800000] PLANE_BANK_DEGREES

68282 PH013 = 071 001, 32939 [Hex 47 01, AB 80], orig val=351.631 [0x4075FA1791C68000] PLANE_BANK_DEGREES

68328 PH013 = 077 001, 32945 [Hex 4D 01, B1 80], orig val=358.417 [0x407666AB1EFC8000] PLANE_BANK_DEGREES

Let's take ine if these and work out what the scaling should theoretically be doing according to the documentation:

"orig val=211.348", and your SCALE is "361,-179,180"

211 is over the max of 180, so set it to 179 (max-1).

Then (361 * (179 - -179))/ 359 = 360 or pretty close

Actually, this applies to ALL of those values over 179, so they should ALL have been returned the same, as 360. That's presumably a bug in EPICINFO (and presumably a very long standing one), but I'm certain it isn't what you are asking to be fixed here -- after all, why would you want all values 180-359 set to 360?.

Somehow you seem to be asking for a value, returned by FS, which is in the range 0-359 already to be scaled to a range of 0-360not sure why.

Maybe FS2002 returned the vaues -179 to +180, not 0-359? You seem to forget that I haven't changed EPICINFO between version 4.22 which you say was okay, and version 4.22 which you say is not? So why point at EpicInfo?

I think you need to do the same logging again with FS2002 and compare them. Meanwhile, for FS2004, try scaling 0-359 to 0-359 (or, in other words, don't bother with the scaling?)

Regards,

Pete

Posted

Pete,

Maybe we could have been more productive here if you'd pointed out where your concern lay initially?

Yes, I imagine we could have. I have never been good at troubleshooting.

Anyway, I'm not sure how you work out that you are getting negative numbers.

Your docs for Epicinfo state that PLANE_BANK_DEGREES will return a value range of -179 to 180 (without scaling), and that if the number is negative then 32767 will be added.

Somehow you seem to be asking for a value, returned by FS, which is in the range 0-359 already to be scaled to a range of 0-360not sure why.

Maybe FS2002 returned the vaues -179 to +180, not 0-359? You seem to forget that I haven't changed EPICINFO between version 4.22 which you say was okay, and version 4.22 which you say is not? So why point at EpicInfo?

Maybe that is the key? Is FS2004 returning 0-359 instead of what your docs say for Epicinfo of -179 to 180? I don't know. Is your "original value" showing what is actually being returned from FS? Even without any scaling I still get one side of the range with 32767 added.

Maybe FS2002 returned the vaues -179 to +180, not 0-359? You seem to forget that I haven't changed EPICINFO between version 4.22 which you say was okay, and version 4.22 which you say is not? So why point at EpicInfo?

The reason I point at Epicinfo is because from what I can tell in the logs it is not returning the documented value for PLANE_BANK_DEGREES of -179 to 180 with the only change being FS2002 to FS2004 and a later version of FSUIPC.

James

Posted

Your docs for Epicinfo state that PLANE_BANK_DEGREES will return a value range of -179 to 180 (without scaling), and that if the number is negative then 32767 will be added.

Ah, maybe that should have been reviewed with each release of FS. Sorry. Not having used EPIC stuff since FS2000 makes this quite difficult for me.

Is your "original value" showing what is actually being returned from FS?

I am pretty sure I wouldn't have used the term "original" for something derived.

Even without any scaling I still get one side of the range with 32767 added.

I would really need to compare the results from FS2002 and FS2004 to offer an sort of comment on this. Sorry. Have you removed FS2002 already?

Regards

Pete

Posted

Pete,

I will try to get some FS2002 data for you. If you prefer not to fiddle with this, since EPIC seems almost extinct in the ever expanding world of flight simulation, I am willing to modify your source code for my purposes.

Thanks for your time,

James

Posted

I will try to get some FS2002 data for you. If you prefer not to fiddle with this, since EPIC seems almost extinct in the ever expanding world of flight simulation, I am willing to modify your source code for my purposes.

No, it's okay. I'll sort it when i understand it. I am thinking of incorporating everything into FSUIPC for FSX and beyond (WideServer and GPSout are already absorbed), or at least making the other DLL's mere satellites (depenfing on size). I'll be looking at what I might be able to do for EPICinfo in due course. it is just in testing I will have some difficulties now.

Pete

Posted

Hi Pete,

Well, I made a log from FS2002 and I'm afraid the data appears identical to FS2004. I'm not quite sure why my old EPIC D code ever worked before! The only change would be possibly FSUIPC. Both EPIC's get the same data in the PH's. I suppose I could try an old version of FSUIPC to see if the data is different?

One thing that is obvious though is that the scaling values appear correct in bytes 0&1 but not in bytes 2&3. Bytes 2&3 still have the 32767 added when the number is negative. For the time being I will use bytes 0&1 and convert to 16 bit.

Any ideas on how to proceed from here? I am a poor troubleshooter. The goal for me is to get the scaled value in bytes 2&3. I will ask Ralph to look at it also.

Thank you,

James

Posted

Well, I made a log from FS2002 and I'm afraid the data appears identical to FS2004. I'm not quite sure why my old EPIC D code ever worked before! The only change would be possibly FSUIPC. Both EPIC's get the same data in the PH's. I suppose I could try an old version of FSUIPC to see if the data is different?

I've had a look at the code for this inside EPICINFO, and in fact FSUIPC is not involved at all! Those two variables, like nearly all of those listed for PHs, are obtained directly from the FS PANELS.DLL using the same interface as used by Gauges in FS panels.

The only thing I can think of it that you are comparing some results from a much older version of EPICINFO. I do have some changes marked as being done in EPICINFO version 3.893, which affects the conversion of the floating point values I get from FS for these variables (all angles):

PLANE_BANK_DEGREES

PLANE_PITCH_DEGREES

ATTITUDE_INDICATOR_BANK_DEGREES

ATTITUDE_INDICATOR_PITCH_DEGREES

but currently I don't see how these could affect the scaling. The change seems to have been to normalise the integer result to a value between 0 and 360.

I'm not sure how EPICINFO then arrives at what you see. I really am so busy at present, and this would take quite a bit of ancient code analysis for me to figure out, especially without my old EPIC ISA boards usable (I've no PCs with ISA slots these days). I do have a USB EPIC here someplace, but I really never got into programming that so that would take even longer.

On second thoughts, maybe I can run EPICINFO with the logging and so on and no EPIC card? I don't remember. I'll check that out when I get a chance. My problem still is making enough time to embark on something like this. I need a space of 2 or 3 days to suddenly appear. Very difficult at present.

Is it really possible that you only recently upgraded to EPICINFO 4.22?

Regards,

Pete

Posted

OkayI'd obviously forgotten a *lot* about EPICINFO.

It is indeed quite possible for me to run it and test it (well all except the talking-to-EPIC bits) with no EPIC attached. I'd forgetten entirely -- in fact I remembered later that I'd even recommended this once for non-EPIC users as a way of tracing the behaviour of the assorted Gauge variables.

Anyway, it makes everythnig MUCH easier, and it definitely means I can see a future for it, or an equivalent facility possibly built into FSUIPC, for FSX and beyond. I'll just need someone around like your good self to test it on real EPICs for me! .

Tracing through the code for the Scaling option you are using I can see why the 32768 bit is being added. The -ve number flag isn't cleared by the scaling code even though, post scaling, the result must always be positive.

As far as I can see this error has ALWAYS been there, it is an integral part of the way it was coded way back when. I don't know what you did originally to get around this nor why you remember it differently -- what HAS happened in between, for you?

Anyway, I've fixed it (one line) and I am attaching 4.23 -- the first update for nearly 3 years as far as I can tell! Please confirm it's okay for you now.

Oh, one minor thing. I think the correct SCALE lines you want should be:

PLANE_PITCH_DEGREES=Scale 360,-179,181

PLANE_BANK_DEGREES=Scale 360,-179,181

The RANGE you want is 360 (0-359), and the upper limit of the input is 181 (this is exclusive, as documented, making the max acceptable 180).

Regards,

Pete

EpicInfo4230.zip

Posted

Pete,

OkayI'd obviously forgotten a *lot* about EPICINFO.

You and me both!

... and it definitely means I can see a future for it, or an equivalent facility possibly built into FSUIPC, for FSX and beyond. I'll just need someone around like your good self to test it on real EPICs for me! .

Excellent! I'll do what I can! ;-)

As far as I can see this error has ALWAYS been there, it is an integral part of the way it was coded way back when. I don't know what you did originally to get around this nor why you remember it differently -- what HAS happened in between, for you?

I have no idea how I got it to work before! The more I look at it, the more I am stumped!

Anyway, I've fixed it (one line) and I am attaching 4.23 -- the first update for nearly 3 years as far as I can tell! Please confirm it's okay for you now.

Wonderful! Thank you for the speedy fix! I will report my progress.

Oh, one minor thing. I think the correct SCALE lines you want should be:

PLANE_PITCH_DEGREES=Scale 360,-179,181

PLANE_BANK_DEGREES=Scale 360,-179,181

The RANGE you want is 360 (0-359), and the upper limit of the input is 181 (this is exclusive, as documented, making the max acceptable 180).

Ok, perfect, thank you, will give it a go!

Posted

Hi Pete,

I am happy to say that it appears the scaling is working properly now! Thank you very much for the repair. If I find any other anamolies I will post them for you.

If there is any way I can help in the future please let me know...

Thanks again,

James

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.