amarante68 Posted March 22, 2009 Report Share Posted March 22, 2009 Hi Several years ago it was easy for me to send 16bits value to FS via epicinfo. Today I started a new project and part of my coding do not work anymore. I know your epicinfo.doc but maybe I forgot somthing anyway. nqw(SetXX,nav1_active); for example do not sent anything yet. Is it correct if I say we can use soft axes: X4 TO X15 Y4 TO Y15 U0 TO U15 V0 TO V15 nqw(SetY6,nav1_active); //is in the epl code also tried with several soft axes U,X,Y I put in EPICINFO5.cfg: NAV1_RADIO_SET=Y6 Also tried :FSUIPC_WRITE_15=Y6,2,0350 //nav1 ofset EpicInfo5 4.9.4.0 in the \modules directory. FSUIPC4 4.5 FSX Regards Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 22, 2009 Report Share Posted March 22, 2009 Several years ago it was easy for me to send 16bits value to FS via epicinfo. Today I started a new project and part of my coding do not work anymore. I know your epicinfo.doc but maybe I forgot somthing anyway. I'm afraid I've forgotten everything. I've not used EPICINFO for nearly 10 years and have no EPIC card to test with. Certainly nothing in EPICINFO has changed for all that time -- excepting the conversion to FSX for EPICINFO5. But that has never been tested by me on an EPIC, only via logging . The testing was done by others and there was no bad feedback. Really it should all work the same as the only changes were in the interface to FSUIPC, which I could test by simulation and logging. Can you use the Logging facilities in EPICINFO to work out what is going on? Also log IPC reads/writes in FSUIPC. Are you able to re-test with FS9? If it works there but not in FSX then I have a bug. Else it is something you are forgetting. Pete Link to comment Share on other sites More sharing options...
amarante68 Posted March 22, 2009 Author Report Share Posted March 22, 2009 I made a test sending the same value to an other ofset instead radios ones. I send U16 to 3B78 alternator amp. I see the correct value with the loging fsuipc monitoring(red test). I succeed so it means that I can comunicate values trough EPICINFO5. But I dont succeed with any radios freqs. If I set 113.70 on the NAV1 virtual FSX radio I will find with FsInterrogate the 1370 value. I should be able to set 113.70 if I send 1370 U16 to 0350 ofset!!! But it does nothing. Then I put the ofset 0350 in loging monitoring. The value is strange. For 113.70 instead showing 1370 like fs interrogate it shows 4976. I dont see the patern here. Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 22, 2009 Report Share Posted March 22, 2009 I made a test sending the same value to an other ofset instead radios ones.I send U16 to 3B78 alternator amp. I see the correct value with the loging fsuipc monitoring(red test). I succeed so it means that I can comunicate values trough EPICINFO5. Oh, good. That's a relief! 113.70 instead showing 1370 like fs interrogate it shows 4976. 4976 in decimal is 0x1370. That is correct BCD encoding for 113.70 frequency. You evidently have FSInterrogate showing decimal instead of hex? Maybe you are sending the wrong values? If you are sending 1370 decimal that represents an invalid frequency (105.5A) so will probably be rejected by FSX. for 113.70 you have to send 0x1370, or decimal 4976. I dont see the patern here. The pattern is clear if you use the correct number base! Regards Pete Link to comment Share on other sites More sharing options...
amarante68 Posted March 22, 2009 Author Report Share Posted March 22, 2009 OK Of course the patern is ovious now. I didn't know about this BCD thing. I dont'understand why radio freq is represented as a decimal but in fact it is a 0x value. Other gauge seems to show and work with decimal. Since I use Epic I don't remember having to convert in 0X. Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 22, 2009 Report Share Posted March 22, 2009 I dont'understand why radio freq is represented as a decimal but in fact it is a 0x value. Yes, all the radio frequencies have always been in "Binary Coded Decimal" in all versions of FS I've ever worked with, right back to FS4. Make for easy conversion into characters -- each decimal digit is just 4 bits, 0-9, so shift out 4 bits, add the character '0', and you have the printable digit. They are all documented this way, with examples. Applies to ADF and Transponder too. Regards Pete Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now