Weatronic RF link quality tools/database
08-20-2011, 04:37 PM
#27
RE: Weatronic RF link quality tools/database
ORIGINAL: luv2flyrc
hi Oli,
When you have a moment could you give me your thoughts on these files. log #33 is short, the turbine shut down while on the ground taxiing to the runway. GSU said Failsafe as reason for shut down. The concerning part is that the jet was no more than 30 feet away from me with no obstructions.
Log 34 is the flight immediately after the shutdown and all went well
Regards,
Mike
hi Oli,
When you have a moment could you give me your thoughts on these files. log #33 is short, the turbine shut down while on the ground taxiing to the runway. GSU said Failsafe as reason for shut down. The concerning part is that the jet was no more than 30 feet away from me with no obstructions.
Log 34 is the flight immediately after the shutdown and all went well
Regards,
Mike
, but your RF frames look very good.What I don't truly understand is why there is a difference between the throttle channel signal and the throttle servo one. See attached graph. I assume there is no mix or curve programmed either in the transmitter or the receiver. The signal that goes to the ECU (the throttle servo one) goes lower than the received by the receiver (the channel one). This may be related to the shutdown[sm=confused.gif]
08-20-2011, 05:09 PM
#28
RE: Weatronic RF link quality tools/database
Thanks Edgar,
Did you notice that at 106/107 seconds the TX frames drop to 0. TX status code 160, No RF connection. I believe this is when the failsafe must have occured. Does this make sense? I'm new at it and I'm still trying to figure out what the data is telling me.
Kind Regards,
Mike
Did you notice that at 106/107 seconds the TX frames drop to 0. TX status code 160, No RF connection. I believe this is when the failsafe must have occured. Does this make sense? I'm new at it and I'm still trying to figure out what the data is telling me.
Kind Regards,
Mike
08-20-2011, 05:21 PM
#29
RE: Weatronic RF link quality tools/database
Weatronics only uses 1 antenna to transmit the data back to the transmitter. Its a weaker signal than the one going to the receiver. It's normal that it will drop for a few seconds and should not have any impact in the system operation. It won't cause a shutdown.
However, sending a too low signal to the ECU can cause a shutdown if it goes outside of the normal throttle range understood by the ECU. That's why I'm confused with the 'gap' between the throttle signal send by the transmitter and the one send to the ECU by the receiver. Think we need Oli or David here
However, sending a too low signal to the ECU can cause a shutdown if it goes outside of the normal throttle range understood by the ECU. That's why I'm confused with the 'gap' between the throttle signal send by the transmitter and the one send to the ECU by the receiver. Think we need Oli or David here
08-20-2011, 05:32 PM
#30
RE: Weatronic RF link quality tools/database
Ok thanks Edgar, I think I get it now ie. the TX frames count reflects receipt of transmission from the receiver to TX.
I'm not sure what's happening regarding the throttle channel vs throttle servo output. There are no mixes or curves set up on that channel. I may have inadvertently messed something up in setting up the throttle failsafe though.
I'll go back and have another look at that.
Thank you for the help.
Mike
I'm not sure what's happening regarding the throttle channel vs throttle servo output. There are no mixes or curves set up on that channel. I may have inadvertently messed something up in setting up the throttle failsafe though.
I'll go back and have another look at that.
Thank you for the help.
Mike
08-21-2011, 10:54 AM
#33
Thread Starter
RE: Weatronic RF link quality tools/database
OK. I had a look at your log files. they are looking good.
Flight 33 : No failsafe / 0 losses of feedback communication ( 136/168 events )
Lowest RSSI 1 rx: -57 dBm
Lowest RSSI 2 rx: -52 dBm
Lowest frame rx1: 64
Lowest frame rx2: 63
Average RSSI rx values: -40 dBm
Lowest RSSI 1 tx: -136 dBm
Lowest RSSI 2 tx: -136 dBm
Lowest frame tx1:0
Lowest frame tx2: 0
Average RSSI tx values: -54 dBm
Note that there is a significant difference between the antenna 1 average RSSI ( -54 dBm ) and antenna 2 ( -34 dBm ). This means that the antenna 1 get a bit of a masking effect.
Flight 34 : No failsafe / 0 losses of feedback communication ( 136/168 events )
Lowest RSSI 1 rx: -57 dBm
Lowest RSSI 2 rx: -52 dBm
Lowest frame rx1: 0 ( 62 )
Lowest frame rx2: 0 (56 )
Note that the event showing 0/0 does not correspond to a failsafe. This might be due to a configuration error.
Average RSSI rx values: -70 dBm
Lowest RSSI 1 tx: -136 dBm
Lowest RSSI 2 tx: -136 dBm
Lowest frame tx1: 29
Lowest frame tx2: 29
Average RSSI tx values: -83/-71 dBm
Note that there is a significant difference between the antenna 1 average RSSI ( -83 dBm ) and antenna 2 ( -71 dBm ). This means that the antenna 1 get a bit of a masking effect.
You would highly benefit from relocating antenna 1.
Flight 33 : No failsafe / 0 losses of feedback communication ( 136/168 events )
Lowest RSSI 1 rx: -57 dBm
Lowest RSSI 2 rx: -52 dBm
Lowest frame rx1: 64
Lowest frame rx2: 63
Average RSSI rx values: -40 dBm
Lowest RSSI 1 tx: -136 dBm
Lowest RSSI 2 tx: -136 dBm
Lowest frame tx1:0
Lowest frame tx2: 0
Average RSSI tx values: -54 dBm
Note that there is a significant difference between the antenna 1 average RSSI ( -54 dBm ) and antenna 2 ( -34 dBm ). This means that the antenna 1 get a bit of a masking effect.
Flight 34 : No failsafe / 0 losses of feedback communication ( 136/168 events )
Lowest RSSI 1 rx: -57 dBm
Lowest RSSI 2 rx: -52 dBm
Lowest frame rx1: 0 ( 62 )
Lowest frame rx2: 0 (56 )
Note that the event showing 0/0 does not correspond to a failsafe. This might be due to a configuration error.
Average RSSI rx values: -70 dBm
Lowest RSSI 1 tx: -136 dBm
Lowest RSSI 2 tx: -136 dBm
Lowest frame tx1: 29
Lowest frame tx2: 29
Average RSSI tx values: -83/-71 dBm
Note that there is a significant difference between the antenna 1 average RSSI ( -83 dBm ) and antenna 2 ( -71 dBm ). This means that the antenna 1 get a bit of a masking effect.
You would highly benefit from relocating antenna 1.
08-21-2011, 11:01 AM
#34
Thread Starter
RE: Weatronic RF link quality tools/database
ORIGINAL: Edgar Perez
The signal that goes to the ECU (the throttle servo one) goes lower than the received by the receiver (the channel one). This may be related to the shutdown[sm=confused.gif]
The signal that goes to the ECU (the throttle servo one) goes lower than the received by the receiver (the channel one). This may be related to the shutdown[sm=confused.gif]
What you're showing here is a consequence of displaying two data in the "show occurred values" or " show visible values" modes.
If you look at your picture, the vertical scale is not the same for the channel and the servo. This is the reason for the offset. Just a scaling problem.
If you display the same data in the " show possible values", then the vertical scale will be the same for both signals ( ie from -200% to +200% ) and you'll see that both data are the same, except during the loss of Tx transmission feedback where the channel signal readout is lost and left at the last known value.
Have a look at the data in the left table and you'll see that both values stay the same.
However this does not explain the engine shut down event and I do not have and answer for this at this stage.
08-21-2011, 11:50 AM
#35
Senior Member
My Feedback: (1)
Join Date: Jul 2003
Location: Leinstrand, NORWAY
Posts: 215
Likes: 0
Received 0 Likes
on
0 Posts
RE: Weatronic RF link quality tools/database
Hi Ollie,
I have a few question about this failsafe log. Lets say the micro receiver goes into failsafe i dont think that will ever show in the log. Reason i wonder is that i see the scenario as follows.
1. Good signal two way communication
2. Lesser signal, tx looses frames and it goes to one way communication from Tx to Rx
3. Looses signal, RX goes to failsafe
4. Signal improves and it goes into one way communication
5. Signal is back at full strength and we have two communication.
So while that failsafe was valid there was no way for the Rx to tell the TX that it is in failsafe. Or course if it tell the TX that it would not be going failsafe in the first place. It is my personal experience that what you will see is just holes in the graph when Tx lost the frames the Rx is trying to send to it. Exaclty when failsafe occours you can not see. Of ourse this could be solved by buffering data in the RX and resend when available. Would be complex an require a handshaking protocoll as well as bandwith would be a problem of it buffered for a long period of time.
I guess with bigger receivers it is not a problem as you could read logs of the onboard memory card.
Then i wonder in the above example if there is such a buffer or some of the parameters is just repeated as it clearly states 0 frames tx for two seconds, and rssi as -136 dbm which looks like a default minimum value. However it also states a rx voltage of 6.7 volts, so how can the RX now that the voltage at that time is 6.7 volts in the rx when it receives 0 frames ie no com. Its also states no feedback from RX in the events tab.
I have a few question about this failsafe log. Lets say the micro receiver goes into failsafe i dont think that will ever show in the log. Reason i wonder is that i see the scenario as follows.
1. Good signal two way communication
2. Lesser signal, tx looses frames and it goes to one way communication from Tx to Rx
3. Looses signal, RX goes to failsafe
4. Signal improves and it goes into one way communication
5. Signal is back at full strength and we have two communication.
So while that failsafe was valid there was no way for the Rx to tell the TX that it is in failsafe. Or course if it tell the TX that it would not be going failsafe in the first place. It is my personal experience that what you will see is just holes in the graph when Tx lost the frames the Rx is trying to send to it. Exaclty when failsafe occours you can not see. Of ourse this could be solved by buffering data in the RX and resend when available. Would be complex an require a handshaking protocoll as well as bandwith would be a problem of it buffered for a long period of time.
I guess with bigger receivers it is not a problem as you could read logs of the onboard memory card.
Then i wonder in the above example if there is such a buffer or some of the parameters is just repeated as it clearly states 0 frames tx for two seconds, and rssi as -136 dbm which looks like a default minimum value. However it also states a rx voltage of 6.7 volts, so how can the RX now that the voltage at that time is 6.7 volts in the rx when it receives 0 frames ie no com. Its also states no feedback from RX in the events tab.
08-21-2011, 12:01 PM
#36
RE: Weatronic RF link quality tools/database
Oli,
Thank you very much for your analysis.
I will move antenna #1. BTW, HOW do I know which one is antenna #1 on the Micro as they don't seem to be marked with any sort of identification?
There must have been another reason for the turbine shut down then other than RF; although the reason given by the GSU was "failsafe"
Regards,
Mike
Thank you very much for your analysis.
I will move antenna #1. BTW, HOW do I know which one is antenna #1 on the Micro as they don't seem to be marked with any sort of identification?
There must have been another reason for the turbine shut down then other than RF; although the reason given by the GSU was "failsafe"
Regards,
Mike
08-21-2011, 04:29 PM
#37
RE: Weatronic RF link quality tools/database
ORIGINAL: olnico
No Edgar.
What you're showing here is a consequence of displaying two data in the ''show occurred values'' or '' show visible values'' modes.
I this stage.
No Edgar.
What you're showing here is a consequence of displaying two data in the ''show occurred values'' or '' show visible values'' modes.
I this stage.
Thanks. I was struggling to make sense of it.
08-22-2011, 12:42 AM
#40
Thread Starter
RE: Weatronic RF link quality tools/database
ORIGINAL: oistein
Hi Ollie,
I have a few question about this failsafe log. Lets say the micro receiver goes into failsafe i dont think that will ever show in the log. Reason i wonder is that i see the scenario as follows.
1. Good signal two way communication
2. Lesser signal, tx looses frames and it goes to one way communication from Tx to Rx
3. Looses signal, RX goes to failsafe
4. Signal improves and it goes into one way communication
5. Signal is back at full strength and we have two communication.
So while that failsafe was valid there was no way for the Rx to tell the TX that it is in failsafe. Or course if it tell the TX that it would not be going failsafe in the first place. It is my personal experience that what you will see is just holes in the graph when Tx lost the frames the Rx is trying to send to it. Exaclty when failsafe occours you can not see. Of ourse this could be solved by buffering data in the RX and resend when available. Would be complex an require a handshaking protocoll as well as bandwidth would be a problem of it buffered for a long period of time.
I guess with bigger receivers it is not a problem as you could read logs of the onboard memory card.
Then i wonder in the above example if there is such a buffer or some of the parameters is just repeated as it clearly states 0 frames tx for two seconds, and rssi as -136 dbm which looks like a default minimum value. However it also states a rx voltage of 6.7 volts, so how can the RX now that the voltage at that time is 6.7 volts in the rx when it receives 0 frames ie no com. Its also states no feedback from RX in the events tab.
Hi Ollie,
I have a few question about this failsafe log. Lets say the micro receiver goes into failsafe i dont think that will ever show in the log. Reason i wonder is that i see the scenario as follows.
1. Good signal two way communication
2. Lesser signal, tx looses frames and it goes to one way communication from Tx to Rx
3. Looses signal, RX goes to failsafe
4. Signal improves and it goes into one way communication
5. Signal is back at full strength and we have two communication.
So while that failsafe was valid there was no way for the Rx to tell the TX that it is in failsafe. Or course if it tell the TX that it would not be going failsafe in the first place. It is my personal experience that what you will see is just holes in the graph when Tx lost the frames the Rx is trying to send to it. Exaclty when failsafe occours you can not see. Of ourse this could be solved by buffering data in the RX and resend when available. Would be complex an require a handshaking protocoll as well as bandwidth would be a problem of it buffered for a long period of time.
I guess with bigger receivers it is not a problem as you could read logs of the onboard memory card.
Then i wonder in the above example if there is such a buffer or some of the parameters is just repeated as it clearly states 0 frames tx for two seconds, and rssi as -136 dbm which looks like a default minimum value. However it also states a rx voltage of 6.7 volts, so how can the RX now that the voltage at that time is 6.7 volts in the rx when it receives 0 frames ie no com. Its also states no feedback from RX in the events tab.
Hi Oistein. Interesting question.
The succession of events you are describing above is correct for a loss of dual way communication. However I believe that the receiver is memorizing the events and you would be able to seen a failsafe condition in the event tab of the Navview window.
Look at log 34 of Mike. He has got 0 rx frames showing at 470s. However the Tx frames are 63/66 at this time stamp. So obviously the recording capacity is there. Since the system has not recorded any failsafe event, I take it as a miss programming issue. I will come back to this soon.
On the log 33, the data that is missing is simply left at the last known value ( one can clearly see the flat values during the loss of com in the screen cap below ). In the previous versions of Gigacontrol, the log would have displayed a void. I think that it was less misleading on that matter.
08-22-2011, 01:04 AM
#41
Thread Starter
RE: Weatronic RF link quality tools/database
Now let's talk about Mike configuration of his system.
As I mentioned previously, there was a very short loss of frames on Mike's log 34 with no failsafe event:
It appears that the receiver configuration was put with a failsafe timeout of 1000 ms or one full second. This means that the system would trigger a failsafe event only after one full second without any frame received, or after having lost 100 consecutive frames. I recommend to set the failsafe timeout to 1/3 second or 300 ms for fast models and 1/2 second or 500 ms for slower models.
Since the datalog takes values every second, the failsafe condition would possibly not be picked up on the log.
Similarly, the range warning is set at very low values of 20% on the receiver and 1% on the transmitter.
I personally recommend to increase these values to 50% at the receiver and 30% at the transmitter.
That way, if you hear 3 low pitch beeps, you know that you are reaching the datalink range limit with a margin of 30%.
If you hear 3 high pitch beeps, you know that you are reaching half way of the radio link range limit.
As I mentioned previously, there was a very short loss of frames on Mike's log 34 with no failsafe event:
It appears that the receiver configuration was put with a failsafe timeout of 1000 ms or one full second. This means that the system would trigger a failsafe event only after one full second without any frame received, or after having lost 100 consecutive frames. I recommend to set the failsafe timeout to 1/3 second or 300 ms for fast models and 1/2 second or 500 ms for slower models.
Since the datalog takes values every second, the failsafe condition would possibly not be picked up on the log.
Similarly, the range warning is set at very low values of 20% on the receiver and 1% on the transmitter.
I personally recommend to increase these values to 50% at the receiver and 30% at the transmitter.
That way, if you hear 3 low pitch beeps, you know that you are reaching the datalink range limit with a margin of 30%.
If you hear 3 high pitch beeps, you know that you are reaching half way of the radio link range limit.
08-22-2011, 04:18 AM
#42
RE: Weatronic RF link quality tools/database
Thanks Oli, I will make those adjustments to the set up.
Without really knowing what I was doing, my thought process on setting the failsafe time to 1000ms was that I didn't want to have my turbine shut down with a small rf blip. Even 1 sec seemed pretty short to me. I will re-adjust as you suggest.
Regards.
Mike
Without really knowing what I was doing, my thought process on setting the failsafe time to 1000ms was that I didn't want to have my turbine shut down with a small rf blip. Even 1 sec seemed pretty short to me. I will re-adjust as you suggest.
Regards.
Mike
08-22-2011, 01:14 PM
#43
Thread Starter
RE: Weatronic RF link quality tools/database
ORIGINAL: luv2flyrc
Thanks Oli, I will make those adjustments to the set up.
Without really knowing what I was doing, my thought process on setting the failsafe time to 1000ms was that I didn't want to have my turbine shut down with a small rf blip. Even 1 sec seemed pretty short to me. I will re-adjust as you suggest.
Regards.
Mike
Thanks Oli, I will make those adjustments to the set up.
Without really knowing what I was doing, my thought process on setting the failsafe time to 1000ms was that I didn't want to have my turbine shut down with a small rf blip. Even 1 sec seemed pretty short to me. I will re-adjust as you suggest.
Regards.
Mike
08-24-2011, 01:53 AM
#44
Senior Member
My Feedback: (1)
Join Date: Jul 2003
Location: Leinstrand, NORWAY
Posts: 215
Likes: 0
Received 0 Likes
on
0 Posts
RE: Weatronic RF link quality tools/database
ORIGINAL: olnico
Hi Oistein. Interesting question.
The succession of events you are describing above is correct for a loss of dual way communication. However I believe that the receiver is memorizing the events and you would be able to seen a failsafe condition in the event tab of the Navview window.
Look at log 34 of Mike. He has got 0 rx frames showing at 470s. However the Tx frames are 63/66 at this time stamp. So obviously the recording capacity is there. Since the system has not recorded any failsafe event, I take it as a miss programming issue. I will come back to this soon.
On the log 33, the data that is missing is simply left at the last known value ( one can clearly see the flat values during the loss of com in the screen cap below ). In the previous versions of Gigacontrol, the log would have displayed a void. I think that it was less misleading on that matter.
Hi Oistein. Interesting question.
The succession of events you are describing above is correct for a loss of dual way communication. However I believe that the receiver is memorizing the events and you would be able to seen a failsafe condition in the event tab of the Navview window.
Look at log 34 of Mike. He has got 0 rx frames showing at 470s. However the Tx frames are 63/66 at this time stamp. So obviously the recording capacity is there. Since the system has not recorded any failsafe event, I take it as a miss programming issue. I will come back to this soon.
On the log 33, the data that is missing is simply left at the last known value ( one can clearly see the flat values during the loss of com in the screen cap below ). In the previous versions of Gigacontrol, the log would have displayed a void. I think that it was less misleading on that matter.
With the regards of the sample at 470: I dont see how that would indicate that the recording capasity is there. Tx frames are 63/66. So what is Tx frames? Is that the number of frames received by the Tx from the Rx? I beleive so. 0 rx frames would mean that 0 frames was received by Rx from the Tx meaning no control basically for 1 second. Obviously the Rx need use telemtry to the Tx to tell how many frames was decoded correctly. In that case 0, which i do not beleive. I think its a timing issue since sample 469 show Tx in state 168, i.e. no coms from Rx. So i guess that is the reason.
On the other case i totaly agree that last know value is very confusing if the value is missing, the '-' showing void value should be used so it clearly shows that it did not decoded the data from Rx at all. So, to the next question, how many frames are needed to decode the data sent from the Rx to Tx. Can they send all data in one fram,e or not? I assume this will even change when you in the future add more telemetry data. Will there be any data taking presence in regards to telemetry? Obviously the control link has presence, but in the future we might quite few frames to include all data that goes from the receiver to the Tx.
Would be interesting to hear whether there are any buffers and retransmitt, but as of now i doubt it. I think it buffers for may a second. So if you loose coms suddenly there will never be a failsafe set. I might be wrong, but i have seen failsafe beeing set and its not in the log.
08-26-2011, 05:16 AM
#45
RE: Weatronic RF link quality tools/database
Oli,
I've noticed an anomaly of some sort with my receiver log file. The receiver log seems to only record rx frames for 1 rx, rx2 is reading 0 frames for 99.9% of flight log, while the tx log for the corresponding flight records good frames on both rx's. This concerns me as from the receiver perspective, it appears that only one receiver is working.
Receiver is 12-22R Gyro 3. I'll post the log files here. These are from a ground test. Logs 1 & 2 are from the transmitter, corresponding receiver log is #3. There are two transmitter logs as I induced a failsafe in the test by shutting off the transmitter.
Mike
I've noticed an anomaly of some sort with my receiver log file. The receiver log seems to only record rx frames for 1 rx, rx2 is reading 0 frames for 99.9% of flight log, while the tx log for the corresponding flight records good frames on both rx's. This concerns me as from the receiver perspective, it appears that only one receiver is working.
Receiver is 12-22R Gyro 3. I'll post the log files here. These are from a ground test. Logs 1 & 2 are from the transmitter, corresponding receiver log is #3. There are two transmitter logs as I induced a failsafe in the test by shutting off the transmitter.
Mike
08-27-2011, 09:20 AM
#46
Thread Starter
RE: Weatronic RF link quality tools/database
Hello Mike.
I have checked your log files. The Rx file shows 0 frames for Rx 2 with a good and coherent RSSI 2. The corresponding Tx file shows 100 frames on Rx2.
So I believe that the Tx file is correct and the Rx file is wrong. Otherwise RSSI 2 would be very low in that condition.
Try to swap the memory cards and do another similar test. Could be a card problem.
I have checked your log files. The Rx file shows 0 frames for Rx 2 with a good and coherent RSSI 2. The corresponding Tx file shows 100 frames on Rx2.
So I believe that the Tx file is correct and the Rx file is wrong. Otherwise RSSI 2 would be very low in that condition.
Try to swap the memory cards and do another similar test. Could be a card problem.
08-27-2011, 09:22 AM
#47
Thread Starter
RE: Weatronic RF link quality tools/database
ORIGINAL: oistein
Would be interesting to hear whether there are any buffers and retransmitt, but as of now i doubt it. I think it buffers for may a second. So if you loose coms suddenly there will never be a failsafe set. I might be wrong, but i have seen failsafe beeing set and its not in the log.
Would be interesting to hear whether there are any buffers and retransmitt, but as of now i doubt it. I think it buffers for may a second. So if you loose coms suddenly there will never be a failsafe set. I might be wrong, but i have seen failsafe beeing set and its not in the log.
08-27-2011, 01:10 PM
#48
RE: Weatronic RF link quality tools/database
ORIGINAL: olnico
Hello Mike.
I have checked your log files. The Rx file shows 0 frames for Rx 2 with a good and coherent RSSI 2. The corresponding Tx file shows 100 frames on Rx2.
So I believe that the Tx file is correct and the Rx file is wrong. Otherwise RSSI 2 would be very low in that condition.
Try to swap the memory cards and do another similar test. Could be a card problem.
Hello Mike.
I have checked your log files. The Rx file shows 0 frames for Rx 2 with a good and coherent RSSI 2. The corresponding Tx file shows 100 frames on Rx2.
So I believe that the Tx file is correct and the Rx file is wrong. Otherwise RSSI 2 would be very low in that condition.
Try to swap the memory cards and do another similar test. Could be a card problem.
So, I've gone back to using 2.33 until I can test further.
Mike
08-31-2011, 10:02 PM
#49
RE: Weatronic RF link quality tools/database
Hi Oli,
Would you mind having a look at this log file. It was the maiden flight of My Super Bandit. The Rx is a Micro 12, and I have a Link vario with a Pitot installed.
I noticed no problems during the flight, however on looking at the data there was some strange returns at 568s, 623s and 760s. At 760s the frame count for both Tx’s and both Rx’s is 0. I have never had this happen before.
Attached is a screen shot and the original file, converted to *.pdf.
Thanks
Roger
Would you mind having a look at this log file. It was the maiden flight of My Super Bandit. The Rx is a Micro 12, and I have a Link vario with a Pitot installed.
I noticed no problems during the flight, however on looking at the data there was some strange returns at 568s, 623s and 760s. At 760s the frame count for both Tx’s and both Rx’s is 0. I have never had this happen before.
Attached is a screen shot and the original file, converted to *.pdf.
Thanks
Roger