Open GoogleCodeExporter opened 8 years ago
Being a feature for a very restricted audience priority goes to low.
About alarms, the internal module in taranis comes (if i'm not wrong) in
production units without the buzzer so setting the alarm means to interact with
internal settings of opentx.
Again a feature for a very restricted audience.
Original comment by romolo.m...@gmail.com
on 30 Jul 2013 at 11:14
Agree that low priority/restricted audience.
Regarding the request for alarm queies is that they can be used in the D8
protocol as a way to provide "is alive"/"is connected" functionality between
3'rd party and Tx module. This is not needed when a link between Tx and Rx is
established.
Original comment by es...@solbu.org
on 30 Jul 2013 at 11:36
Issue 84 has been merged into this issue.
Original comment by bson...@gmail.com
on 1 Aug 2013 at 7:54
Issue 85 has been merged into this issue.
Original comment by bson...@gmail.com
on 1 Aug 2013 at 7:54
#84 and #85 is quite different from #83. #84 and #85 can easily be merged, as
they both deal with some sort of active communication between 3'rd party and
the Taranis itself.
However #83 is different. This deals with transparent communication between
3'rd party and equipment in the model over S.PORT rather than the Taranis
itself.
From the 3'rd party perspective, this should be transparent if he connects to
the Taranis or the serial port on the XJT.
After a merge of all three issues, the new feature request would be:
Support for two serialport modes:
1. Two way Transparent Telemetry/S.PORT communication, allowing 3'rd party
communication over the S.PORT bus to S.PORT sensors in the model (Formerly #83)
2. Two way Taranis communication, allowing 3'rd party to read and write Taranis
channels and variables (Formerly #84 and #85)
In my mind, option 1 (Former #83) has endless higher priority than Option 2,
also the former #85 would have higher priority than #84
Original comment by es...@solbu.org
on 1 Aug 2013 at 9:16
Just a note:
"Format would depend on the mode currently used. D16 ->S.PORT, D8 ->
"OldSchool" protocol."
The module in the Taranis always supplies S.Port protocol whatever the mode, so
this is what you'll get.
Unless you want to code the reverse-conversion in openTx of course ;)
By the way, as a developer you could code the entire functionality yourself if
you really need it! We always welcome contributions :)
Original comment by bernet.a...@gmail.com
on 11 Aug 2013 at 7:56
I would like to contribute, and if no-one else needs this feature, i might have
to brush up my C++ skills and submit a patch eventually :) I don't yet have a
Taranis or a XJT to play with, so there is no hurry :)
Regarding the internal module always outputting S.Port. This should not be a
problem for me as i intend to support S.Port.
Would you happen to know if this is also the case for the serial port on the
XJT? (D8 mode vs D16?)
Original comment by es...@solbu.org
on 11 Aug 2013 at 9:16
No idea about the XJT... BUT if it's intended to connect an FLD-02 and have it
work, I'd expect to have the old protocol at least when in D8 mode...
Original comment by bernet.a...@gmail.com
on 11 Aug 2013 at 9:18
That was my assumption, and also why i assumed the "native" stream would be
available before parsing for the internal module as well (Hub protocol if in D8
mode and S.PORT if in D16)
I have seen some debug logs, but these are in text format and very cluttered
with additional data, do you guys have any raw binary logs? (I guess raw
logging could be a feature request before the streaming of it to serial :P)
Original comment by es...@solbu.org
on 11 Aug 2013 at 11:01
I'd like to see the serial port enabled asap so that it can be used with a
Bluetooth module for updated Android app connectivity. As it is, we have to
record the logs, then transfer it to a PC to review log data such as GPS tracks.
Original comment by jalowe1234@gmail.com
on 18 Aug 2013 at 10:35
CC to FrSky for another users' request.
Implementation: an "UART" setting on the "Hardware" radio setup page with
different possible choices: OFF, Telemetry output, and provisions for other
future capabilities.
Original comment by bernet.a...@gmail.com
on 23 Sep 2013 at 3:19
Yes, telemetry values sent to serial port (when logging) would be wonderful.
Original comment by pch...@comcast.net
on 31 Dec 2013 at 11:20
I've just made this mod to that blindly output smartport bytes on the Taranis
serial.
https://github.com/KipK/opentx/commit/de27fe7c291860754fea9dee939811280b573b3e
This should work, but I think it needs a TTL inverter on this port too.
Original comment by hotlobst...@gmail.com
on 18 Jan 2014 at 1:16
I would also like to request output of the telemetry values to the serial port.
I will be glad to provide software and source code to display the data in
Google Earth.
Original comment by rjbeckw...@gmail.com
on 17 Sep 2014 at 1:00
Cool, but now we are on github!
Original comment by bson...@gmail.com
on 17 Sep 2014 at 5:43
"2. Two way Taranis communication, allowing 3'rd party to read and write
Taranis channels and variables (Formerly #84 and #85)"
+1000
Sending "CLI" commands over usb serial (or serial3) to query, modify, add or
otherwise change configuration "on the fly" would be hugely powerful.
Something like "OpenTX Terminal"?
This would allow configuration in real time both from Companion and other
potential 3rd party "helper" apps making the turnaround time (a deterrent)
modifying a setting in Companion to seeing it in operation on the TX just about
nothing.
This may have a much wider audience than initially suggested.
Original comment by adrian.d...@gmail.com
on 6 Mar 2015 at 7:19
Original issue reported on code.google.com by
es...@solbu.org
on 30 Jul 2013 at 7:06