Weatronic 2.4 RF diagnostic tool
05-04-2015, 03:56 AM
#2652
Junior Member
Join Date: Aug 2014
Location: Wildau, near Berlin (Germany)
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
Hello wea Users,
Hello Edgar,
the fast flashing light tells you that the Battery is is low and it will not Start until it have a minimum of changing. After you have full charged the Transmitter all is good.
Kind regards from Berlin / Mit freundlichen Grüßen aus Berlin
Jens Ackermann
Service Manager / Leiter der Serviceabteilung
Hello Edgar,
the fast flashing light tells you that the Battery is is low and it will not Start until it have a minimum of changing. After you have full charged the Transmitter all is good.
Kind regards from Berlin / Mit freundlichen Grüßen aus Berlin
Jens Ackermann
Service Manager / Leiter der Serviceabteilung
06-19-2015, 06:28 AM
#2654
I got the word that, unfortunately, Jens has left the building.
I heard nothing officially yet, which leaves room for speculation, especially as Jens had built up a good reputation (at least with me) for answering questions.
I heard nothing officially yet, which leaves room for speculation, especially as Jens had built up a good reputation (at least with me) for answering questions.
06-19-2015, 08:01 AM
#2655
Junior Member
Join Date: Jun 2007
Location: Venlo, NETHERLANDS
Posts: 23
Likes: 0
Received 0 Likes
on
0 Posts
06-20-2015, 03:59 AM
#2656
Thread Starter
Jens has left Weatronic Germany.
This has no consequence to the USA as we provide full support from Houston to the customers purchasing their product through Weatronic USA/ Ultimate Jets.
This has no consequence to the USA as we provide full support from Houston to the customers purchasing their product through Weatronic USA/ Ultimate Jets.
06-26-2015, 03:33 AM
#2657
Oli,
No replacement for Jens his function has been announced, nor his departure, and that with him introducing himself here as the contact name for any questions regarding Wea.
It is therefore not strange two questions I have sent remain unanswered.
One is: what is code nr 136 in Giga for the RX status?
One plane keeps on generating this code.
No replacement for Jens his function has been announced, nor his departure, and that with him introducing himself here as the contact name for any questions regarding Wea.
It is therefore not strange two questions I have sent remain unanswered.
One is: what is code nr 136 in Giga for the RX status?
One plane keeps on generating this code.
06-26-2015, 03:47 AM
#2658
My Feedback: (1)
Join Date: Feb 2002
Location: private, UNITED KINGDOM
Posts: 3,672
Likes: 0
Received 26 Likes
on
16 Posts
136 is 8 and 128
8 is HF connection ok (uni or bi-directional mode)
128 The Rx is on uni-directional mode
So the connection is ok but is in uni-directional mode, which I think means telemetry is not working
See http://www.weatronic.com/en/UserFile...on-NavView.pdf
8 is HF connection ok (uni or bi-directional mode)
128 The Rx is on uni-directional mode
So the connection is ok but is in uni-directional mode, which I think means telemetry is not working
See http://www.weatronic.com/en/UserFile...on-NavView.pdf
06-26-2015, 04:28 AM
#2659
Thanks Harry, didn't know the codes were added.
It comes together with an audio "minimum" or something alike, which is worrying in flight, however no degradation in controllability was noticed. Once it was in the higher part of a tow flight, once in closer range.
Micro 12 and DV4BT all at 2.63.
But on both occasions another XT(not WEA) was a bit too close for comfort, some sailplane pilots think they need to sit on Your lap when You tow their models!
It comes together with an audio "minimum" or something alike, which is worrying in flight, however no degradation in controllability was noticed. Once it was in the higher part of a tow flight, once in closer range.
Micro 12 and DV4BT all at 2.63.
But on both occasions another XT(not WEA) was a bit too close for comfort, some sailplane pilots think they need to sit on Your lap when You tow their models!
06-26-2015, 10:57 PM
#2660
Richard, with those codes its NOTHING to worry about. The downlink is only a fraction of the signal strength of the uplink and you will not have any control degredation.
I notice code 136 is more frequent when flying with other transmitters radiating but hardly at all when flying 'solo, so if you had a very close Tx that is probably the cause .
The codes are on the web site but if you "hover" your mouse near the code on the "Nav View" download it gives you the meaning of the code.
David.
I notice code 136 is more frequent when flying with other transmitters radiating but hardly at all when flying 'solo, so if you had a very close Tx that is probably the cause .
The codes are on the web site but if you "hover" your mouse near the code on the "Nav View" download it gives you the meaning of the code.
David.
06-27-2015, 02:03 AM
#2661
David, pheew, thanks for confirming my observations with regard to nearby Xmtrs.
In another tug I have now a full house of telemetry, after long tries it finally works. Alas, for this setup, You need both a vario (single version suffices for powered planes) AND a MuxBox...
PT1000 temp sensor connected to the cyl head (wow, does a tug engine heat up...) This HAS to be connected to a MuxBox, does not work with the vario!
Press altitude coming from a Wea Vario, together with vario signals. The vario signal is a good indication during turns, when it is difficult to maintain a constant ROC. GPS altitude lags too far behind with fast climbing, high powered tugs.
Pitot airspeed, plugged into the vario. This is the best!
With the short anouncement file installed on the DV4 it works better as before, only WEA forgot to correct the temp sensor, where all values are preceded by a MUXBOX---PT1000 sentence. I have just asked WEA to correct this on their user forums, no idea if they read that...
I have a three position switch on which I can select all these three values!
I will write some more plus pics later....
In another tug I have now a full house of telemetry, after long tries it finally works. Alas, for this setup, You need both a vario (single version suffices for powered planes) AND a MuxBox...
PT1000 temp sensor connected to the cyl head (wow, does a tug engine heat up...) This HAS to be connected to a MuxBox, does not work with the vario!
Press altitude coming from a Wea Vario, together with vario signals. The vario signal is a good indication during turns, when it is difficult to maintain a constant ROC. GPS altitude lags too far behind with fast climbing, high powered tugs.
Pitot airspeed, plugged into the vario. This is the best!
With the short anouncement file installed on the DV4 it works better as before, only WEA forgot to correct the temp sensor, where all values are preceded by a MUXBOX---PT1000 sentence. I have just asked WEA to correct this on their user forums, no idea if they read that...
I have a three position switch on which I can select all these three values!
I will write some more plus pics later....
07-11-2015, 06:23 PM
#2662
My Feedback: (2)
Today I experienced a malfunction of my DV-3 Tx module in my 9C transmitter. The unit has worked for approx 4 years. Today when I turn on the transmitter all three lights on the RF module flash rapidly and the receiver does not respond. If I push either the #1 or #2 button on the RF module the lights then work normally and the receiver responds. Does any one have any ideas or suggestions.
See attached short video on YouTube: http://youtu.be/f1g19or8DTA
See attached short video on YouTube: http://youtu.be/f1g19or8DTA
07-12-2015, 12:35 AM
#2663
Thread Starter
Today I experienced a malfunction of my DV-3 Tx module in my 9C transmitter. The unit has worked for approx 4 years. Today when I turn on the transmitter all three lights on the RF module flash rapidly and the receiver does not respond. If I push either the #1 or #2 button on the RF module the lights then work normally and the receiver responds. Does any one have any ideas or suggestions.
See attached short video on YouTube: http://youtu.be/f1g19or8DTA
See attached short video on YouTube: http://youtu.be/f1g19or8DTA
The flashing scheme is explained in chapter 9.2.2 of my receiver manuals ( chapter 9.2.4 for the Gizmo manual )
07-12-2015, 06:08 AM
#2665
Thread Starter
Yep, that is perfectly normal. This is the way the system warns you to upgrade your receiver firmware.
08-28-2015, 02:07 PM
#2666
Crashed. What was the problem?
Guys, I just had a turbine shutdown in flight, resulting in a crash that seriously damaged my the plane.
The turbine (Gaspar xicoy ECU) indicates that there was a throttle signal outside of the valid range, resulting in the turbine going into a failsafe shutdown.The plane was flown by friend who is a much better pilot than I am. He maintained control of the plane thru the crash.
I'm using a Futaba 12FG, with the DV4 module. The plan has a 12 channel micro receiver. Attached is the log.
I'm struggling to understands what is the root cause.
Looking a the log, I'm not sure if the turbine shutdown happened at 432 seconds or 448 seconds. After the shutdown, the plane glided for about 6-10 seconds (it was low to start with). I think its likely it was in the 3 second issue at 432 seconds.
Potential causes
1) The transmitter: The Frames Tx-1 and Frames Tx-2 goes to 0 for 3 seconds starting at 432 seconds into the log. At the same time the Tx voltage drops. However the Rx was configured to go to get the turbine to idle and the pilot reported having control of the plane.
2) The Receiver: Channel 3 (throttle stick) diverges from the Servo 4 (going to ECU) signal at 448 seconds. There are no mixes, so their values should be the same/close. However it does not seems that it went outside the programmed range for the ECU (the throttle % range in Weatronics for this Radio/Rx is Idle --> about -45.8, Full Power --> about +54.5%). Yet the log maybe meaningless at this point, since the telemetry back to the transmitter is not available as the Tx is reporting no RF connection with the Rx.
I need to figure out if I need to deal with a Tx issue or a Rx issue.
The log is attached with a PDF extension. Need to be changed back to NAV for loading into GigaControl.
Any help appreciated.
Thanks
The turbine (Gaspar xicoy ECU) indicates that there was a throttle signal outside of the valid range, resulting in the turbine going into a failsafe shutdown.The plane was flown by friend who is a much better pilot than I am. He maintained control of the plane thru the crash.
I'm using a Futaba 12FG, with the DV4 module. The plan has a 12 channel micro receiver. Attached is the log.
I'm struggling to understands what is the root cause.
Looking a the log, I'm not sure if the turbine shutdown happened at 432 seconds or 448 seconds. After the shutdown, the plane glided for about 6-10 seconds (it was low to start with). I think its likely it was in the 3 second issue at 432 seconds.
Potential causes
1) The transmitter: The Frames Tx-1 and Frames Tx-2 goes to 0 for 3 seconds starting at 432 seconds into the log. At the same time the Tx voltage drops. However the Rx was configured to go to get the turbine to idle and the pilot reported having control of the plane.
2) The Receiver: Channel 3 (throttle stick) diverges from the Servo 4 (going to ECU) signal at 448 seconds. There are no mixes, so their values should be the same/close. However it does not seems that it went outside the programmed range for the ECU (the throttle % range in Weatronics for this Radio/Rx is Idle --> about -45.8, Full Power --> about +54.5%). Yet the log maybe meaningless at this point, since the telemetry back to the transmitter is not available as the Tx is reporting no RF connection with the Rx.
I need to figure out if I need to deal with a Tx issue or a Rx issue.
The log is attached with a PDF extension. Need to be changed back to NAV for loading into GigaControl.
Any help appreciated.
Thanks
08-28-2015, 04:02 PM
#2668
Thanks for checking. I downloaded and change the extension and it opened fine in gigacontrol 2.63 and gigacontrol 2.7
Just to confirm, the steps are:
1 -Click on the attachment and select "SAVE file"
2- go to the folder where it downloaded. You should be able to see the full name, including the extension (L39 RIP - Copy.pdf). If you don't see the .pdf portion, go to the Tools -> Folder Options -->View and deselect "Hide extensions from know file types".
3- After you can see the .pdf extension, I click on it to be able to rename it. You can then replace the .pdf with .nav
4- Ope with Gigacontrol
Can you try again?
Thanks!
Now I realize that you used the .pdf extension just so you could post it on RCU because the .nav can't be uploaded..
08-30-2015, 11:26 AM
#2670
Thread Starter
Hello Edgar.
The engine shut down does not come from the throttle order at 432 s
Here is a screen shot of the log analysis at this point:
The shut down throttle value is -45.8% as seen on (1).
At 432 s the throttle signal was at +1.2% as seen on (2) or roughly 50% of stick position.
Immediately after this, the telemetry return drops to 0% as seen on (3).
The cause of the engine shutdown was a loss of RF link for a few 10th of seconds at the 435 s time marker. This was not long enough to trigger a failsafe condition.
However it was long enough to trigger a turbine shutdown from the ECU.
Here is a screen shot of the RF link loss:
The event occurred as followed:
1) Loss of Tx frames ( telemetry return ) for 3 seconds showing a signal degradation.
2) Brief loss of Rx frames ( both at zero ) for less than 1 second.
3) This event is too short to trigger a failsafe condition on the receiver. It is not felt by the pilot.
4) The ECU picks it up and shuts the engine down.
It looks like an antenna masking condition or blanking zone.
The engine shut down does not come from the throttle order at 432 s
Here is a screen shot of the log analysis at this point:
The shut down throttle value is -45.8% as seen on (1).
At 432 s the throttle signal was at +1.2% as seen on (2) or roughly 50% of stick position.
Immediately after this, the telemetry return drops to 0% as seen on (3).
The cause of the engine shutdown was a loss of RF link for a few 10th of seconds at the 435 s time marker. This was not long enough to trigger a failsafe condition.
However it was long enough to trigger a turbine shutdown from the ECU.
Here is a screen shot of the RF link loss:
The event occurred as followed:
1) Loss of Tx frames ( telemetry return ) for 3 seconds showing a signal degradation.
2) Brief loss of Rx frames ( both at zero ) for less than 1 second.
3) This event is too short to trigger a failsafe condition on the receiver. It is not felt by the pilot.
4) The ECU picks it up and shuts the engine down.
It looks like an antenna masking condition or blanking zone.
08-30-2015, 11:35 AM
#2671
Thread Starter
Not a Tx issue as source frames are stable ( 45 average ) and Throttle channel makes sense and is continue.
The discrepancy between ECU channel and ECU Rx feedback is due to the fact that the RF connection is lost on the ground after the crash and the log records the last known Rx position for a little while before dropping off the recording.
The DV4 module did its job properly.
The receiver could be the weak link in this event but the antenna drop looks more like a masking condition.
The troubleshooting procedure at this point would be to put the plane in the exact same position as when the engine shot down and do a range test to check the antenna reception diagram as per the advanced range procedure described from page 34 onwards in the micro 12 manual:
http://www.geohei.lu/olin/data/model...%20rev%204.pdf
The discrepancy between ECU channel and ECU Rx feedback is due to the fact that the RF connection is lost on the ground after the crash and the log records the last known Rx position for a little while before dropping off the recording.
The DV4 module did its job properly.
The receiver could be the weak link in this event but the antenna drop looks more like a masking condition.
The troubleshooting procedure at this point would be to put the plane in the exact same position as when the engine shot down and do a range test to check the antenna reception diagram as per the advanced range procedure described from page 34 onwards in the micro 12 manual:
http://www.geohei.lu/olin/data/model...%20rev%204.pdf
08-30-2015, 11:58 AM
#2672
Hi Oli.
I was hoping you had some time to take a look at this. Thanks!
There was some carbon reinforcement in the fuselage area. although the plane had flown with those, It seems quite possible that there was a blanking. It just escaping me when I look at the log.
I'm still confused how the Rx/ECU reacted to the 1 second period with no frames. I configured the Rx so that the failsafe condition value for the throttle is the equivalent of idle. However, since the Rx did not went to failsafe, it should not had mattered.
I would have though the Rx will continue to send the "last known value" the the ECU. I see that the ECU servo value was 53.3% at the time of the Rx frames lost. It should not have caused the ECU to go to failsafe/shutdown.
As per Gaspar ; The fadec ecus do have failsafe, to use it you should program the throttle signal to a value lower than STOP signal, if you have the STOP to -100% that is 1000uS, just set to -110%. This will allow the ecu to be aware of the failsafe condition, set the engine to idle for 2 seconds and if condition persist, shut down. Also will record the failsafe events and cause of shutdown.
This should mean that there was a signal provided by the Rx to the ECU that was below the Stick down / Trim Down value for about 3 seconds. The only "interesting" period of 3 seconds I could find was the period where the Frames Tx were 0, starting at 432.
I think I was misinterpreting the transmitter status codes. So the Frames Tx values are related to the telemetry function?
I was hoping you had some time to take a look at this. Thanks!
There was some carbon reinforcement in the fuselage area. although the plane had flown with those, It seems quite possible that there was a blanking. It just escaping me when I look at the log.
I'm still confused how the Rx/ECU reacted to the 1 second period with no frames. I configured the Rx so that the failsafe condition value for the throttle is the equivalent of idle. However, since the Rx did not went to failsafe, it should not had mattered.
I would have though the Rx will continue to send the "last known value" the the ECU. I see that the ECU servo value was 53.3% at the time of the Rx frames lost. It should not have caused the ECU to go to failsafe/shutdown.
As per Gaspar ; The fadec ecus do have failsafe, to use it you should program the throttle signal to a value lower than STOP signal, if you have the STOP to -100% that is 1000uS, just set to -110%. This will allow the ecu to be aware of the failsafe condition, set the engine to idle for 2 seconds and if condition persist, shut down. Also will record the failsafe events and cause of shutdown.
This should mean that there was a signal provided by the Rx to the ECU that was below the Stick down / Trim Down value for about 3 seconds. The only "interesting" period of 3 seconds I could find was the period where the Frames Tx were 0, starting at 432.
I think I was misinterpreting the transmitter status codes. So the Frames Tx values are related to the telemetry function?
08-30-2015, 08:53 PM
#2673
HI Edgar.
Sorry to hear about this..
I have looked at your file and will add some thoughts. I don't completely agree with Oli,
. Here is my argument..
Firstly, the log file cannot confirm if the Rx went into fail safe, as it was mute for up to 4 seconds..
The down link was lost at 431s, and for the next 4 seconds there is no data being sent from the Rx to the Tx.
(With this current firm ware, when the down link is lost, the system carries on writing down the last known values for all the Rx fields, for up to 8 seconds!!! The Rx does not store information and then transmit it as a backlog!
I think this is wrong and quite confusing as the values are not correct. In my opinion it would be better to have 0’s recorded during times of no down link.)
Whatever is happening at the Rx during this time, it is not being recorded, so it's not possible to know what is going on.. Sooooo, the Tx/Rx connection may have been broken for this ENTIRE 4 second period.. Who knows??
At 435 sec, the down link is re established, but by this time, I guess the damage has been done. Whether this is a shielding issue, or some other problem I cant help.
I feel your pain.. The exact same thing happened to me with a Micro 10 in a Bandit a few years back. Never got to the bottom of that either, apart from mine definitely went into fail safe, as the ECU recorded and reported it.
Still, you have more data than you would with the Bat 60 (Aye Oli
)
Roger
Sorry to hear about this..
I have looked at your file and will add some thoughts. I don't completely agree with Oli,
. Here is my argument.. Firstly, the log file cannot confirm if the Rx went into fail safe, as it was mute for up to 4 seconds..
The down link was lost at 431s, and for the next 4 seconds there is no data being sent from the Rx to the Tx.
(With this current firm ware, when the down link is lost, the system carries on writing down the last known values for all the Rx fields, for up to 8 seconds!!! The Rx does not store information and then transmit it as a backlog!
I think this is wrong and quite confusing as the values are not correct. In my opinion it would be better to have 0’s recorded during times of no down link.)
Whatever is happening at the Rx during this time, it is not being recorded, so it's not possible to know what is going on.. Sooooo, the Tx/Rx connection may have been broken for this ENTIRE 4 second period.. Who knows??
At 435 sec, the down link is re established, but by this time, I guess the damage has been done. Whether this is a shielding issue, or some other problem I cant help.
I feel your pain.. The exact same thing happened to me with a Micro 10 in a Bandit a few years back. Never got to the bottom of that either, apart from mine definitely went into fail safe, as the ECU recorded and reported it.
Still, you have more data than you would with the Bat 60 (Aye Oli
)Roger
08-31-2015, 07:11 AM
#2674
Thread Starter
I'm still confused how the Rx/ECU reacted to the 1 second period with no frames. I configured the Rx so that the failsafe condition value for the throttle is the equivalent of idle. However, since the Rx did not went to failsafe, it should not had mattered.
I would have though the Rx will continue to send the "last known value" the the ECU. I see that the ECU servo value was 53.3% at the time of the Rx frames lost. It should not have caused the ECU to go to failsafe/shutdown.
At this stage, it is not guaranteed that the engine got shut down in flight due to an invalid ECU signal, as this could have been triggered on the ground.
The problem is that the failsafe signal seen by the ECU could have been after the crash! As Roger points out, once Tx frames go to zero, the log recording is meaningless as it is taken from the DV4!
You need to check the ECU memory and try to get a time stamp at the beginning of the flight that coincides with the DV4 log to see if the ECU shut down signal was in flight or on the ground after the crash.
Could you also send me your micro 12 config file so I can see how the failsafe was programmed?
08-31-2015, 07:13 AM
#2675
Thread Starter