>> I purchased a few rotary encoder and a bunch of 7segment displays to >> build a physical replacement of the Bendix KX165. I'm using Arduino which >> feeds data to FGFS on a serial connection. I'd like to update >> "instrumentation/comm[0]/frequencies/standby-mhz" property using the rotary >> encoder, I wonder what's the best strategy. > I'm working on something similar too: > > http://leeds.hackspace.org.uk/wiki/index.php/Projects/FlightSimHardware
Good to know Jon, I'll be glad to talk about that with you. I like your hardware approach, getting your hands "dirty" on a naked ATMega16 should be fun too :-) > The simplest solution seems to be to simply send the active and standby > frequencies whenever there's a change (up/down of the standby frequency, > or swap of active/standby), and define a protocol that expects the two > frequencies, comma separated from the serial port. It doesn't appear to > matter that there's not a continuous data stream - the last received > value is used if there's no new data. I run the incoming protocol at > 10Hz, which seems to give a quick enough response for the on screen > version of the display. I've settled down on sending the standby-mhz only cause I will send the swap freq <-> button state too, that will swap the frequencies inside fgfs property tree itself, without the need to send the active freq too. Still I think it's better to make the external hardware send only the rotary encoder's rotations from a design perspective, and not the frequencies at all; I know that's debatable. I'm sending freq now for easy of development only. I agree sending only changing values should be more desirable but serially sent data should be sent all together, there's no way to send an input chunk and leaving the others as-is; since my approach aims at integrating several (not thousands but quite a few anyway!) physical input/output devices, I think for simplicity everything should be sent at a constant frequency. And no, I find 10hz is way too low for some other devices (maybe frequency settings updates can tolerate a 10th of a second delay, but it's still noticeable). I'm still wondering if you too have noticed that FGFS updates it's property tree with not exact standby-mhz values when using such input devices. Can you confirm? Did you solved this issue? I've also noticed you use <format>%03.3f</format> in an input chunk ... I did try that too, I hoped that would get me a 3.3 digit format but nothing! It's ignored. How's that at your side? > I'd like to be able to send values from flightgear back to the panel, so > that updates to the properties are reflected on the radio panel > hardware, but it appears I've got some bugs in my code at the moment > (seems like a race condition or memory leak) that cause things to lock > up or randomly reset. I need to get it hooked up to a JTAGICE to debug it. > > Jon > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
