Thread Tools
Jul 27, 2016, 06:02 AM
working to the closest cm
jirvin_4505's Avatar

what is difference in select type?


followed the banggood link
asks you to choose flysky , frsky or jr

what would be the differences?

have both turnigy 9x and taranis .. do i need 2 different types?

cheers Jeff
Sign up now
to remove ads between posts
Jul 27, 2016, 06:04 AM
Happy FPV flyer
Kilrah's Avatar
The expected channel order for PPM mode in the firmware is different. If you can change it on your radios, or reflash the module it is not important.
Jul 27, 2016, 06:15 AM
Registered User
Note that for the Taranis with OpenTX bridging the two TX pins doesn't give you telemetry since the Taranis expects inverted Serial.

I added an XOR chip (N74LVC1G86) in my DIY module (crude sketch attached, resistor is 1k) but a normal fet/transitor should work too. And Telemetry currently also only works on 2.2.

Perhaps for one the first posts (to copy paste or link to this post):

OpenTX status
OpenTX 2.1

- Inoffcial version
- Source available under https://github.com/opentx/opentx/tre...multi_module21
- Binaries available under http://plai.de/opentx
- Telemetry not implemented
- Companion 2.1.8 will overwrite multi settings. 2.19 Companion (and current nightlies) will not overwrite setting but also do not show the settings

OpenTX 2.2
- current development version of OpenTX, not for normal users
- Multi serial support in official OpenTX repository
- Telemetry working (needs an inverter) and Spektrum (DSM2/DSMX) telemetry implemented
- Works on Horus and Taranis

Support for OpenTX and 9X might come later, but needs testers.
Last edited by plaisthos; Jul 27, 2016 at 07:00 AM.
Jul 27, 2016, 07:09 AM
Zippa Flippa
nebbian's Avatar
Thread OP
Many thanks Plaisthos, info added on post 4.
Jul 27, 2016, 08:57 AM
ErskyTx Developer
Mike Blandford's Avatar
Quote:
Originally Posted by plaisthos
OpenTX 2.2
. .
- Telemetry working (needs an inverter)
Any reason to force the need of an inverter, rather than use a software serial that handles non-inverted serial (as I have in ersky9x)?

Mike.
Jul 27, 2016, 09:00 AM
Registered User
midelic's Avatar
Yes doesn't need inverter.
Just smart copy serial routine from ersky9x.
Jul 27, 2016, 09:11 AM
Happy FPV flyer
Kilrah's Avatar
Haven't looked at the code in esky9x but we already have too much stuff potentially happening at the same time with the different functions, even hardware serial had trouble being treated without overruns, had to move to using DMA. Not motivated to throw pin change interrupts in the mix.
Last edited by Kilrah; Jul 27, 2016 at 09:18 AM.
Jul 27, 2016, 09:26 AM
ErskyTx Developer
Mike Blandford's Avatar
The code captures the signal edges using the highest priority interrupt( level 0), so it always overrides all other interrupts, nothing else uses level 0. Then adjust all other interrupt priorities to avoid overruns etc. I use about 10 different priorities.

Mike.
Jul 27, 2016, 09:36 AM
Happy FPV flyer
Kilrah's Avatar
Highest priority is better used for something important (control...) than for telemetry.
We support protocols that have to be put out at 400kbit/s. While potentially sending PXX simultaneously, and receiving 2 serial streams and a trainer signal.

If someone can integrate it and run a timing analysis with real-world signals to make sure not to disturb anything than by all means go ahead.
Jul 27, 2016, 10:19 AM
ErskyTx Developer
Mike Blandford's Avatar
A bit off topic, but relevant to possibly getting non-inverted serial available.

Crossfire (400k) and PXX are sent using DMA, interrupts should only be needed at frame end.
I'm surprised if you are getting serial input overruns on interrupt. Even at 100k baud, a byte only arrives every 100uS. With a processor clocking at 120Mhz, this is 12000 clocks. If you are getting overruns, then you have missed 2 bytes, so the interrupt must have been held off for 200uS (24000 clocks). Since, in my opinion, all a serial interrupt is likely to need to do is grab the byte and put it into a fifo for later processing, the interrupt level should be set high enough to guarantee it takes place. In any case, I would suggest the question should be, what is holding the serial interrupt off for 200uS, rather than a response of we must use DMA. If you can use DMA to provide the fifo function then that is a useful method (I use it ersky9x on Atmel ARM processors), but I would seriously wonder why an interrupt is held off for 200uS. Should the serial be at 400K, this is still held off for 50uS (6000 clocks) to cause an overrun.
If you are using a software serial input, then that is one of the 2 serial streams you are receiving, so you will only be receiving 1 other serial stream.
Trainer capture (PPM) is supported in hardware, so can allow some latency in the interrupt response, up to a whole pulse width so nearly 1mS.

I'm afraid I can't agree with "Highest priority is better used for something important (control...) than for telemetry", in my opinion you have to choose the interrupt priorities to match their timing needs and adjust the tasking priorities to process things in due time. Do as little as possible in high priority interrupts.

Mike.
Last edited by Mike Blandford; Jul 27, 2016 at 10:27 AM.
Jul 27, 2016, 10:24 AM
Registered User
wakeCTR's Avatar
First off, Thanks for setting up this thread nebbian and thanks plaisthos and medlic for the work you have put into this.

I've read through both rcgroup threads and the github documents. I still have a few questions:

1- Has the range issue with KN protocol been fixed (banggood says it is 50m with the baseplate)?
2- Telemetry is only supported on Taranis through opentx 2.2 AND an inverter mod (per Plaisthos)
  • Is telemetry needed for KN or DSM2/DSMX to work properly? (fix range issue, auto binding and model memory etc)
  • can you post a quick tutorial on the inverter mod? (link to parts, photos etc)
Jul 27, 2016, 11:42 AM
ErskyTx Developer
Mike Blandford's Avatar
I'm trying to see if the inverter mod can be avoided!
Thinking carefully about what is operating, the requirement to support a software serial is to handle this MULTI module with telemetry. Surely, in a Taranis, this means you are using this module in the external bay, and using the bottom pin of the module connector for telemetry. So the external protocol in use will be MULTI, it won't be Crossfire and the internal module isn't crossfire so no 400k protocol will be in use.
Second, if you enable the internal XJT module, this will output telemetry, I don't believe the internal telemetry can be disabled. If you do enable this, then the XJT telemetry will conflict with the MULTI telemetry and neither will work, so PXX won't be in use.
So, if the software serial is added for use when using the MULTI protocol in the external bay, you won't have all these other things going on at the same time, so there should not be any timing problems.

Mike.
Jul 27, 2016, 02:18 PM
Registered User
So far, I've been using my Banggood module in a Taranis running 2.1.7 without soldering a short across the 2 jumpers in the #2 post. It seems to be running fine right now.
What is the purpose of soldering that short across the jumpers?
How exactly is one able to determine which version (early or late) board one has?
Thanks.
Thanks to nebbian for starting this thread too!
-beanie
Jul 27, 2016, 02:29 PM
Registered User
midelic's Avatar
Short explanation is that the new board has no inductor and the tuner(shielded module) has 13 pins instead of 12 on the left side.
Jul 27, 2016, 08:44 PM
Zippa Flippa
nebbian's Avatar
Thread OP
Quote:
Originally Posted by beanie
What is the purpose of soldering that short across the jumpers?
When you bridge those two jumpers, you enable serial communication between the transmitter and the module. This lets you select which protocol you want to use by clicking on menus on your transmitter. You might also get telemetry back from your model (this process isn't completely foolproof yet).

If you don't bridge those jumpers, then you need to select the protocol by twisting the selector knob every time you change receiver types. You also will never get telemetry back from your model.


Quick Reply
Message:

Thread Tools