DeBesten / opentx

Automatically exported from code.google.com/p/opentx
0 stars 0 forks source link

Installed Rx/Telemetry Sensor Firmware Version Reporting #203

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Which board (stock / gruvin9x / sky9x / Taranis) are you using?

- Taranis

What is your openTx FW version?

- 2834

What is your openTx EEPROM version?

- 215

What steps will reproduce the problem?

- There is no function to read/display bound Receiver's or Telemetry Sensor's 
Firmware version.  

What is the expected output? What do you see instead?

A Telemetry parameter could be added to allow a user to place this information 
on one of the custom telemetry screens. 

Please provide any additional information below.

FrSKY offers a Windows utility program for updating Rx/Sensor firmware, but the 
program which connects to the device, apparently does not provide the installed 
version, only allows the firmware to be burned (with 'Download' button).

Original issue reported on code.google.com by barry.m....@gmail.com on 23 Dec 2013 at 4:41

GoogleCodeExporter commented 8 years ago
There is no way for getting the information if the sensor doesn't transmit it...
The issue is invalid
Remember this is the place for reporting issues about the radio firmware not 
about frsky products.

Original comment by romolo.m...@gmail.com on 23 Dec 2013 at 4:49

GoogleCodeExporter commented 8 years ago
This was reported as an Enhancement request.  Developers should be working with 
FrSKY directly and must have overlooked this important feature.

Original comment by barry.m....@gmail.com on 25 Dec 2013 at 5:38

GoogleCodeExporter commented 8 years ago
We haven't really collaborated on the sensor and protocol development and don't 
have access to any design material for them, we mostly just implemented the 
specs we've been given in our firmware. 
You should contact FrSky and suggest it to them directly. If they do implement 
a possibility of reading back sensors' firmware versions in the future, then we 
could consider supporting it in the firmware.

Original comment by bernet.a...@gmail.com on 26 Dec 2013 at 8:12

GoogleCodeExporter commented 8 years ago
Btw, actually the sport communication is monodirectional, no command get sent 
from the radio to query the sensor, so unless something changes I find a waste 
of bandwidth  that a sensor transmits periodically its firmware version.
So I will suggest instead to ask FrSky to implement the capability to read 
sensor version on the PC before updating it.

Original comment by romolo.m...@gmail.com on 26 Dec 2013 at 9:54

GoogleCodeExporter commented 8 years ago
Right. A collaboration with FrSky on the sensors would not be bad. Especially 
the variometer one, I can't understand how it is possible to have so bad 
results with this hardware ;)

Original comment by bson...@gmail.com on 26 Dec 2013 at 10:01

GoogleCodeExporter commented 8 years ago
Romolo you're wrong, SPORT is bidirectional, and the protocol does allow for 
querying the sensors. It's just not used at this point. 

Original comment by bernet.a...@gmail.com on 26 Dec 2013 at 11:22

GoogleCodeExporter commented 8 years ago
Sorry but I'm not wrong: what you state is exactly what i wrote.
Exactly what I wrote: "actually the sport communication is monodirectional"
We do to query the sensors, and we have no way to query their firmware version.

Original comment by romolo.m...@gmail.com on 27 Dec 2013 at 6:37

GoogleCodeExporter commented 8 years ago
@Romolo: "actually" doesn't mean what you think :)

Original comment by bson...@gmail.com on 27 Dec 2013 at 10:32

GoogleCodeExporter commented 8 years ago
Yes I think that's a language problem indeed. 

"Actually" means "in fact", so you were affirming that sport is monodirectional 
for good, instead of saying that it is CURRENTLY monodirectional in our 
implementation ;)

Original comment by bernet.a...@gmail.com on 28 Dec 2013 at 9:21