Bluetooth mobile phone dashboard for FrSky? Common protocol?
Posted: Mon Aug 02, 2010 5:27 pm
Has anyone thought to make a "bluetooth" extender for the FrSky Tx module, so that one can program and use a standard bluetooth enabled cellphone as dashboard?
i.e. using something like http://www.sureelectronics.net/goods.php?id=402 (manual at http://www.sure-electronics.net/downloa ... 1.0_EN.pdf )
I guess this very quickly brings up one issue. Maybe the FrSky community (us and rcgroups i guess..) should try to come up with a "standard" protocol within the frsky protocol, so that one can make hubs and dashboards that work across platforms.. I.e. PIC, arduino etc based hubs work equally well, and Dashboards using LCD, Android, iPhone, Symbian, Windows mobile, LED, sound etc etc work equally well...
I guess this could be achieved by setting up a set of common identifiers, (altitude, airspeed,G forces etc), then spend a predefined length for the value for each identifier, say 6-8 bits
I guess it would all come down to us using a common set of enumerations (with proper unit declaration) and same bitlength of those defined parameters..
Have you done enough work on your compression/aggregation protocol to start sharing it Bruce?
(i suspect you are the one that has gotten the furthest still
i.e. using something like http://www.sureelectronics.net/goods.php?id=402 (manual at http://www.sure-electronics.net/downloa ... 1.0_EN.pdf )
I guess this very quickly brings up one issue. Maybe the FrSky community (us and rcgroups i guess..) should try to come up with a "standard" protocol within the frsky protocol, so that one can make hubs and dashboards that work across platforms.. I.e. PIC, arduino etc based hubs work equally well, and Dashboards using LCD, Android, iPhone, Symbian, Windows mobile, LED, sound etc etc work equally well...
I guess this could be achieved by setting up a set of common identifiers, (altitude, airspeed,G forces etc), then spend a predefined length for the value for each identifier, say 6-8 bits
I guess it would all come down to us using a common set of enumerations (with proper unit declaration) and same bitlength of those defined parameters..
Have you done enough work on your compression/aggregation protocol to start sharing it Bruce?
(i suspect you are the one that has gotten the furthest still