FrSky Taranis - user chat

[Clive Hall]

I apologise if this is an old question, but I have not found an answer yet.

I have an early Taranis which I have easily upgraded from 2.0.20 to 2.1.9 , direct PC connection with it turned off, using Windows 7 Pro. I had a bit of trouble getting a copy of dfu-util.exe into the right folder but once that was done it took only a minute to flash the new firmware. I repeated the exercise with no problems on another two Taranis for friends.

Then I acquired a Taranis-plus which had 2.1.6 on board. I tried the same flashing method but failed to remember that a Taranis-plus would not accept the Taranis firmware. It didn't. Now all it will do is light up the display plain white, and the Haptic vibrates continually. Some voice comes through from an earlier model when I move a stick, so an eeprom must be there.

The STM32 BOOTLOADER is present so I tried to write 2.1.9 for a Taranis-plus with the battery removed and a direct connection to Win-7. It appears to begin to write the firmware but then a message appears "New firmware is incompatible with the one currently installed". I do not know what to try next, so help would be most welcome.

[Barry Cole 2]

Clive,

Do not panic. Been there done that. Watch this video, and do EXACTLY what he says.

https://www.youtube.com/watch?v=hVWwInEAsa0

Have fun.

BC

[Martyn K]

Check that you uploading the correct firmware version. Taranis and Taranis plus are different

[Barry Cole 2]

As I said. Do EXACTLY what he says.....

BC

[Clive Hall]

B.C. thanks for the pointer to the video; I did follow it EXACTLY, made sure the STM32 BOOTLOADER was in the right place, made sure that I selected Taranis Plus, and it all went precisely in step with the video until I clicked on ‘Write firmware to radio’. At this point the progress box outline appeared, empty, then after a short time the progress bar appeared. However it ran across the screen instantly and was immediately covered by a box stating ‘Could not check firmware from radio’ with an ‘OK’ button just below. When I click OK it all disappears and returns to the ‘Write firmware to radio’ page. I can not make it progress beyond that. I tried reading the firmware from the radio and there is something there. Saved it, looked at the contents in Notepad, saw references to 2.1.9 among all the code.

If I try turning the radio on it still gives the blank white display panel and the Haptic will not stop until I switch off. I am baffled. Perhaps I should give up on 2.1.9 and try to reload 2.0.20 – does this make sense? I am using a Windows 10 PC this time, perhaps that is the problem. I am inclined to go back to Win7 and try the older firmware.

[Barry Cole 2]

Clive,

I made exactly the same mistake as you, with a friend's "Plus", and I followed the video, and it worked. Try it again and be very careful. I had two PCs and ran the video on one, and the Taranis on the other. Win 10 worked for me.

Where are you??

BC

[Clive Hall]

I am in Cheddar, Somerset, 20 miles south of Bristol.

[Mike Blandford]

You could try just flashing from a command prompt.

Go to the directlory where you have companion installed, then just type:
dfu-util -a 0 --dfuse-address 0x08000000 -D x9dp_rom.bin

where "x9dp_rom.bin" is the name of the file you are trying to flash.

You will either need to put the file you wish to flash in the Comapnion directory, or enter the path to it as part of the filename.

Curious as to why you don't start the Taranis in bootloader mode normally (both horizontal trims held inwards at power on), rather than flash using the STM bootloader?

Admittedly, having flashed the wrong version you have overwritten this bootloader with a wrong version, but if you use this bootloader normally, then even if you flash the wrong firmware this bootloader will still work.

Mike.

[Barry Cole 2]

Great respect to you Mike, but I don't understand a word of that.....

Clive, make sure you plug the Taranis in with the power off.

Sorry, you are a bit too far away for direct help.

I know from personal experience that Scott's video does work.

Good luck BC

[Mike Blandford]

I do advise using the bootloader accessed using the trims, rather than the dfu-util method if at all psossible.

It provides many more options for flashing. This includes the option of putting the firmware file on the SD card and flashing it from there. This method would easily recover the problem currently being discussed.

Mike.

Edit: When trying to flash the firmware, use the "Read/Write" menu. You should see a small dialog box appear asking for the name of the file to flash, along with a checkbox "Check Hardware Compatibility". Untick this box and select the file you wish to write.

Edited By Mike Blandford on 04/10/2017 19:28:05

[Barry Cole 2]

Mike,

I sort of agree, but I seem to remember from when I did the same. Once you have put non plus into a plus, it will not turn on with the 3 finger salute system. I think that is why Scott's vid shows how to do it with the power off connection.

It was a while ago though, I am more careful now.

BC

[Clive Hall]

Barry and Mike both have it right. My biggest problem was that nothing I could do would make the Taranis respond. Companion could not get through to it, and whether I turned it on normally or with the three finger boogie all it would give was the plain white screen and continuous buzz.

Anyway, problem about solved. It is more or less working again. I went back to the PC running W7, loaded companion 2.0, attempted to restore 2.0.17 and ended up with it working again on 2.0.20. Don’t ask me how. The Haptic keeps burping intermittently but not enough to be troublesome, and the SD card is empty, so there is work to be done, but the end is in sight.

Many thanks to everyone who pointed to solutions, they really saved the day.

[Mike Blandford]

If you flash using the STM bootloader method with DFU-UTIL, then you write both the bootloader and the main application at the same time. So if you choose the wrong firmware, both are wrong.

If you use the trims bootloader, you only flash the main application, so that bootloader remains working, which is a good reason for using it rather than the STM bootloader.

For me, I always use this bootloader as it is common to all my transmitters (Taranis, 9XR-PRO, and 9X with 9Xtreme and AR9X/SKY upgrades).

Mike.

[Devcon1]

I'm having a real senior moment.

I've been using Companion 2.1.9 for over two years but have just installed 2.2.1 on a newly installed version of Windows 10, (in prep for an X10S)

All fine fine from a technical point of view but I'm scratching my head on the Transmitter Simulator regarding switch layout.

On my X9D+ real world Tx starting from left to right(ignoring sliders) it goes...

SF SE SA SB SC SD SG SH

But on Companion simulator at the top it goes...

SA SB SC SD SE SF SG SH

Now I don't have my older Companion to check but I've convinced myself the layout on both TX and Companion were the same, as I cant think of a logical reason why they would'nt match.

Am I losing it.

[Bob Cotsford]

I think I saw something on RCGroups about this being a bug that's been notified to the developers. It's the sort of thing that creeps in with software evolution, I'd imagine it would be an easy slip with the changes needed to include the stream of new FrSky transmitters. I think that the switches are only incorrect in the simulator and that all programming functions should translate correctly when uploaded to the physical transmitter.

I must admit that I've never used the transmitter (firmware) simulator before, but in my copy of 2.2.0 the switches go SA to SH from left to right.

edit - just found 2.1.9 and the switches were as per the actual Taranis layout.

Edited By Bob Cotsford on 23/01/2018 11:03:13

[Martyn K]

Here is a screenshot from v2.0.0. of the Taranis Simulator

Martyn

[Bob Cotsford]

I think 2.2.1 must have overwritten my 2.2.0 copy after all!

[Devcon1]

Thanks Bob, Martyn,

Youv'e put me back up the sanity scale a bit. I'll have a dig in the RCGroups thread.

I also noticed a new programe that was created that Bob mentioned which is the firmware simulator, now I don't recall that from 2.1.9. Is it a different tool to the simulator that is used directly in Companion.

I'll check the 2.2.1 release notes to see if it is mentioned.

Thanks

John

(I'll try a post a screenshot of mine)

[Devcon1]

It is on GitHub as a query in Feb 17 and is listed as a Simulator Enhancement to be assigned...

Doesn't cause a problem so those great guys at OpenTx will fixit when they can.

"The switch layout on simulator dose not match the real Tx layout.
In simulator switches from left to right are SA, SB, SC, SD, SE, SF, SG, SH.
But on real Tx it is SF, SE, SA, SB, SC, SD, SG, SH. as it was on V2.1 simulator.

[Mike Blandford]

In ersky9x firmware I have a "maintenance mode" that provides several features including the ability to flash internal and external XJT modules, change the SPort ID of sensors and flash Multiprotocol modules. Some of these features have been included in openTx, but others have not, and my not get included, or may tak a long time before they do get included.

I've been looking in to this and have a possible solution that doesn't rely on openTx being changed.
On the Taranis, the bootloader runs in RAM, but uses less than 64K of the 128K available.
I have changed my bootloader to include a new option "Run App". This loads and runs a program from the SD card, using 64K of RAM (max of 32K currently for the "app" code) located in the second 64K of RAM.

My idea is to have an "app" that just does the flashing of a MultiProtocol module, and then others that allow for different functions.

To use such a facility does not require openTx to be modified, just flash an alternative bootloader, then run an app from there to carry out these sorts of functions.

I've just posted a test version of ersky9x (ProvR222a2) (**LINK**) for the Taranis, Taranis Plus and the QX7(s). The bootloader in these has the options of "Flash Firmware" and "Run App". I haven't had the "Restore EEPROM" in my version of the bootloader, so I don't have that available (yet). I'll either add that, or make it another "app"!

The .zip file also includes an app for each of these transmitters, you need to use the "app" that matches your hardware.
Each "app" includes an identifier of the hardware on which it runs. The bootloader checks any "app" it loads and only runs it if the identifier matches the bootloader.

To use this with openTx, just copy the required .bin file to your firmware directory, and copy the required "app" file to an "apps" directory.
Use openTx to update the bootloader on the radio from the .bin file.
Now restart the radio in bootloader mode, choose the "Run App" option, then select the "FlashMulti" "app".

Mike

[Mike Blandford]

I've also now posted another "app". This one, called "ChangeId.app" lets you change the physical Id of a FrSky sensor, useful if you need two of the same type of sensor (e.g. FLVSS for more than 6 cells).

Mike

[Mike Blandford]

I've been investigating latency on a Taranis (plus) to a X8R receiver. The results are posted here: **LINK**.

Note the last sentence!

Mike

[Chris Bott - Moderator]

Interesting stuff Mike. In your opinion do you think the varying latencey would be noticed by us club level fliers?

Do you think anything will be able to be done to minimise it?

[Mike Blandford]

You probably won't notice the varying latency.

There are 3 parts to the latency:
1. The time between a control changing and the start of sending this to the XJT module.
2. The time to send the data to the module, the module to send it to the Rx and the Rx to send this out on SBUS.
3. The time for the Rx to start a servo pulse.

1. This is random.
2. On ersky9x, this is a fixed time as it is synchronised to the XJT heartbeat. OpenTx doesn't (currently) do this and so may have at least an extra 9mS (randomly).
3. This time is either 0mS or 9mS depending on when the Rx was powered as the servo pulse period is 18mS!

The varying latency is caused by 1. It is 0 to 9mS if the radio sends only 8 channels (or uses the "double rate" I describe), and is 0 to 18 mS if you send 16 channels normally.

In passing, going back to the 27/35 MHz days of sending PPM, the servo pulses were sent in "real time", so zero latency for items 2 and 3, but a varying latency for 1 of the frame time, from 0mS to, typically, 20 to 25 mS.

Using SBUS and either the "double rate" or 8 channels only mode minimises the latency so the variation is only 9mS. Note that if you use a SBUS decoder, it may also only output servo pulses every 18mS for analog servos, but may provide them every 9mS if you use digital servos.

Mike

[BackinBlack]

interesting observations. Has anyone found specified or claimed latency for any of the commonly used transmitter/receiver brands? There are spurious (meaningless) claims of super low latency and similar phrases, but no specific figures. What should we consider good in latency terms?

I wonder how significant this latency is when you factor in human "latency"? Our reaction time is typically 250mS for a visual stimulus, the best of us might manage 180mS.

There are many claims made for the equipment we use that are really meaningless. Digital servos for instance, just what is digital about them. If the positional/rotational feedback for the output shaft is derived from a potentiometer, as all I know of are, then that is not digital.

Ian