Originally Posted by (Jo)Hannes

I i understand right you invert the signal before sending the data and invert it again after receiving it. If you invert twice isnt that the same result as not inverting at all?

No it is not. This is RS232 which needs START and STOP bits for synchronisation. If these bits are not the correct polarity then no synchronisation and a load of rubbish comes out.

Originally Posted by gke

Still trying to find out what has happened to my user telemetry option on my D8Rs but I what have found is that the Rx echoes its telemetry packets through its Tx pin (marked as +5V on the V2 Version).

I have been seeing this problem with CPPM s/w for about 2 weeks. At first I thought it was my controllers but when I was convinced it was not I sent a report to Eva (10 days ago). I have not received a reply yet. Possibly things are still a little slow after the Chinese new year celebrations.

This is the problem description I sent:

1) The system starts normally with Link Quality Frames(FE) and User Data Frames(FD).
2) When the fault occurs the Link Quality Frames(FE) are still generated but their are no further User Data Frames(FD). Serial data is still being sent to the Receiver.
3) Once the User Data Frames(FD) have stopped flowing they do not restart without intervention.
4) To free the lockup it is necessary to power cycle either the transmitter or the receiver. Power cycling the controllers attached is not necessary and will not free up the system.
5) I have seen this effect on receivers with both V1 & V2 hardware. My transmitter module is running V2 RomA.

The important thing being that FE type frames containing AD1/AD2/RSSI are NOT interrupted but the FD type User Data frames work initally but then after a time they stop flowing completely.

As this has not been reported by others I am wondering if the issue is caused by my use of binary data. If I understand correctly most other people are using ASCII data. I have run some tests and the problem does not seem to relate to a specific byte.

Trevor

Just carried out a test: Once the User Data has dropped out another way of forcing a recovery is to reduce the RF level to a point where the Rx goes to the unbound state (Red LED flashing) and then restoring the RF level. Reducing the RF level in my case involved unscrewing the Tx aerial and putting the Tx in a steel cupboard in another room.

Thanks Trevor.

OK so using the programming lead for the user telemetry is working.

I need to look further but it may be that the Vout Low on my inverter is not low enough to switch off the simple transistor S8050 translator (as shown in the Protocol Document 20100921121837352.pdf) in the receiver - probably close to 0.6V. The LS04 inverter I am using has a nominal output swing 0.5 - 2.5V so as Werner says any noise and ....... .

A diode in the emitter leg of the transistor may help (FrSky?).

Of course there is no problem if you have full RS232like +/- signals.

I don't know what the receiver software does when it starts receiving corrupted user data as this will certainly result in USART framing errors. I think you are correct Trevor and the receiver code may just say "I am seeing just noise on the Rx pin" and disable the USART interrupts until the next power cycle.

This may also be a reliability issue when driving from a micro using inverted USART signalling.

I need to fix my analog scope as logic analysers don't tell the full story .

My packet receiver is below. It is called every time a character is received. FrSkyRxPacketTag is FE FD etc.. In my case I am using the FD type to build up much larger packets which can be seen in the second routine below.

On the D8R V2 the recever voltage reading (A1) seems to be scaled by 4. The second sensor input (A2) seems to be unscaled. The link quality is unscaled dB typically up around 80dB on the bench.

Greg

[PHP] void ParseFrSkyPacket(byte ch)
{
switch (FrSkyPacketRxState)
{
case WaitRxSentinel:
if (ch == 0x7e)
{
FrSkyRxPacketTag = FrSkyPacketTag;
FrSkyPacketRxState = WaitRxTag;
}
break;
case WaitRxTag:
if (ch != 0x7e)
{
FrSkyReceivedPacketTag = ch;
FrSkyRxPacketByteCount = 0;
FrSkyPacketRxState = WaitRxBody;
}
break;
case WaitRxBody:
if ( ((ch == 0x7d) || (ch == 0x7e)) && ( FrSkyRxPacketByteCount != 8 ))
FrSkyPacketRxState = WaitRxESC;
else
{
FrSkyPacket[FrSkyRxPacketByteCount++] = ch;
if (FrSkyRxPacketByteCount == 9)
{
if (ch != 0x7e)
RxFrSkyErrors++;
else
FrSkyPacketReceived = true;
FrSkyPacketRxState = WaitRxSentinel;
}
}
break;
case WaitRxESC:
ch ^= 0x20;
FrSkyPacket[FrSkyRxPacketByteCount++] = ch;
FrSkyPacketRxState = WaitRxBody;
break;

default: FrSkyPacketRxState = WaitRxSentinel; break;
}
}

void ProcessFrSkyPacket()
{
short b, nb;
double RxVolts;
short LQ;

FrSkyPacketReceived = false;
switch ( FrSkyReceivedPacketTag ) {
case 0xf0:
case 0xf1:
case 0xf2:
case 0xf3:
case 0xf4:
case 0xf5:
case 0xf6:
case 0xf7:
break;
case 0xf8: // Threshold request
break;
case 0xf9: // A2 Threshold

break;
case 0xfa: // A2 Threshold

break;
case 0xfb: // A1 Threshold

break;
case 0xfc: // A1 Threshold

break;
case 0xfd: // Data packet
nb = FrSkyPacket[0];
for (b = 2; b < (nb + 2); b++)
{
ParsePacket(FrSkyPacket[b]); // another state machine for the UAVX packets!
if (PacketReceived)
ProcessPacket();
}
break;
case 0xfe: // A1, A2, link quality
RxVolts = (FrSkyPacket[0] * 4.0 * 3.3) / 255.0;
if ( RxVolts < 4.0 )
FrSkyA1.BackColor = System.Drawing.Color.Orange;
else
if ( RxVolts < 3.5 )
FrSkyA1.BackColor = System.Drawing.Color.Red;
else
FrSkyA1.BackColor = FrSkyBox.BackColor;

FrSkyA1.Text = string.Format("{0:n1}", RxVolts );
FrSkyA2.Text = string.Format("{0:n1}", ((float)FrSkyPacket[1] * 10.0 * 3.3) / 255.0);

LQ = FrSkyPacket[2];
if ( LQ < 80 )
FrSkyLQ.BackColor = System.Drawing.Color.Orange;
else
if ( LQ < 70 )
FrSkyLQ.BackColor = System.Drawing.Color.Red;
else
FrSkyLQ.BackColor = FrSkyBox.BackColor;

FrSkyLQ.Text = string.Format("{0:n0}", LQ );

break;
case 0xff:

break;
default:
break;
}
}

[/PHP]

Originally Posted by turnale

For the hardware, I used an inverter between the arduino both the RX module and the TX module:
http://www.frsky-rc.com/uploadfile/201009/20100921121837352.pdf
The only difference are:
- R14: I used a 2KOhms resistance instead
- VCC: I used 5V
- I didn't see any difference with using or not the diode D8

The circuit is actually on the Rx board rather than a suggestion for an inverter.

It can however be used as the basis of an inverter cct and if driven from a logic circuit D8 is not required. D8 is only there to protect the transistor from a negative swing from a fully specified RS232/V.24 input.

I have just traced the signal on a V1 D8R. The following obserevations may be of interest:

1) The COM input does not copnnect directly to R14/R15. Instead it connects to R19(330R) which in turn connects to R14/R15. R19 does not seem to serve any useful purpose!
2) The RxD O/P from R13 connects to the RxD pin on the Programming port. The other end of R13 connecting to the Vcc pin on the programming port.

I will have a look at one of my V2 D8R's next time I have a need to open it up.

Originally Posted by gke

I need to look further but it may be that the Vout Low on my inverter is not low enough to switch off the simple transistor S8050 translator (as shown in the Protocol Document 20100921121837352.pdf) in the receiver - probably close to 0.6V. The LS04 inverter I am using has a nominal output swing 0.5 - 2.5V so as Werner says any noise and ....... .

I am driving the RxD input on my system from an ATXMega controller directly. This uses a 3V3 supply. I think the suggestion of noise may be correct. It certainly fits the symptoms. Now I need to work out a solution. Poor noise margins on FrSky inputs do seem to be a feature.

Of course even if noise proves to be the root cause this does not excuse the lock up problem and FrSky will need to do something about this.

Trevor

Originally Posted by Trevor_G

The circuit is actually on the Rx board rather than a suggestion for an inverter.

It can however be used as the basis of an inverter cct and if driven from a logic circuit D8 is not required. D8 is only there to protect the transistor from a negative swing from a fully specified RS232/V.24 input.

I have just traced the signal on a V1 D8R. The following obserevations may be of interest:

1) The COM input does not copnnect directly to R14/R15. Instead it connects to R19(330R) which in turn connects to R14/R15. R19 does not seem to serve any useful purpose!
2) The RxD O/P from R13 connects to the RxD pin on the Programming port. The other end of R13 connecting to the Vcc pin on the programming port.

I will have a look at one of my V2 D8R's next time I have a need to open it up.



I am driving the RxD input on my system from an ATXMega controller directly. This uses a 3V3 supply. I think the suggestion of noise may be correct. It certainly fits the symptoms. Now I need to work out a solution. Poor noise margins on FrSky inputs do seem to be a feature.

Of course even if noise proves to be the root cause this does not excuse the lock up problem and FrSky will need to do something about this.

Trevor

Hi Trevor,

Yes I agree that the diagram shows what is supposed to be in the Rx and is also a suggestion for adding outside the box to undo the "damage" so to speak. Unfortunately as drawn the transistor is not likely to be hard off. My suggestion was that FrSky put a diode on the emitter to give an external driver some chance of switching it off. I just reassembled one of my D8Rs I had open but could also try to trace what is actually there.

I doubt if many of us would be putting a device with RS323 signaling on board an aircraft theses days. Much more likely to be driving it directly from some micro with direct "TTL" level signaling from a USART. It seems a pity to resort to a MAX232 or similar.

Hopefully Eva or one of the FrSky people will spot this dialogue and respond .

Cheers
Greg

Hi Trever, hi Greg

Today I have written a test program in order to send bytes with correct and wrong baud rate to the receiver Rx. Only the bytes
with correct baud rate setup (9600 bps) are displayed correct on my dashboard. I have made the tests with approximately 10700 bps / 4300 bps.
But if have not detected a lock up problem. The receiver still transmits the bytes (USER FRAME).
Even I still receive the remote frame with my dashboard, diplaying the link quality.

The transmission of the user data (0x7E, 0xFD) is event and time triggered. No reception on RX means no
user frame will be send.

I have tested my serial LiPo monitor using an old brushed DC-Motor with many EMI, but I have had
never problems receiving the USER and REMOTE Voltage frame.

Hope it will help you.

Best regards
Micha

Hi Micha,

What s/w are you using on your Rx ? To the best of my knowledge the lockup only occurs on the CPPM s/w. V2 Rx s/w does not appear to lock-up.

Trevor

Hi Trevor

I have three V2 D8R receivers. What do you mean by CPPM s/w. Sorry, but never heard. Maybe I haven't understand your problems well.

Best regards
Micha

Hi Micha,

At the request of a number of users FrSky have produced a version of their Rx s/w that puts out a combined PPM signal on Channel8. This was released at the beginning of the month as fdd_rx_cppm_build110120.frk. Usually referred to as CPPM. This feature, previously made available on V8R7, is not useful to everyone. If you don't need it stick with V2.

By asking the question I assume you are using V2 s/w in which case I would not expect you to see the lockup.

Trevor

Hi Trevor

Thanks for your information. Now I can understand your problem. I'm flying only powered gliders and motor modells,
so I have no need for the combined PPM signal on Channel 8.

Best regards
Micha

Hallo Trevor,gke ,

I recommand for the inverter a simple transistor BC547 with two resistors 2,2 K ohm. That is easy and should work.

Yesterday I tried to use my cppm Software with an updated V1 receiver and the signal was good ,but the quadrocopter Mega 8 unit detected only no Signal.
Befor it worked with a flysky receiver with a combined PPM electronics.

As next step I tried to generate a signal with PPM signal in a similar way to
the flysky unit (with longer PPM pause) and then it worked.

What I recognized the small voltage swing of the PPM signal and so I decided to test a level shifter 3.3 V >> 5 V and then it worked. The quadrocopter unit with an mega 8 has a 5 V powersupply.

With my RS232 hub ,similar build as Snoopy Schulz showed it ,I have had only problems by bad decoupling of the pic processor. Then i noticed the same problem you have ,the data stream locked even if the pic sends data. I have the problem i can only see it on the scope ,but in that case i can not see if they are correct.

With better decoupling i had no locks anymore.

best regards

Werner

Originally Posted by flyer5

Hallo Trevor,gke ,

I recommand for the inverter a simple transistor BC547 with two resistors 2,2 K ohm. That is easy and should work.

Yesterday I tried to use my cppm Software with an updated V1 receiver and the signal was good ,but the quadrocopter Mega 8 unit detected only no Signal.
Befor it worked with a flysky receiver with a combined PPM electronics.

As next step I tried to generate a signal with PPM signal in a similar way to
the flysky unit (with longer PPM pause) and then it worked.

What I recognized the small voltage swing of the PPM signal and so I decided to test a level shifter 3.3 V >> 5 V and then it worked. The quadrocopter unit with an mega 8 has a 5 V powersupply.

With my RS232 hub ,similar build as Snoopy Schulz showed it ,I have had only problems by bad decoupling of the pic processor. Then i noticed the same problem you have ,the data stream locked even if the pic sends data. I have the problem i can only see it on the scope ,but in that case i can not see if they are correct.

With better decoupling i had no locks anymore.

best regards

Werner

Hi Werner,

I think if the external transistor has a sufficently low VCE when off it is OK. As you said any noise coupled intothe ground line giving ground bounce will stop the internal transistor from cutting off properly and the receiver software will probably ignore the Rx input from then on.

The VCE of a saturated BC547 must be just low enough to most of the time to work. The specs show 0.2V typical and 0.6V max so if you get a BC547 close to typical it will work but not with much margin.

I think FrSky needs to rethink the internal translator to make it more reliable for unipolar signalling. As I said a diode should give us another 0.6V of noise margin.

Cheers
Greg

What about an external diode connected in series with the transistor base (serial input) ? Should give you the same results...

Originally Posted by RENATOA

What about an external diode connected in series with the transistor base (serial input) ? Should give you the same results...

Turning on the internal level translator transistor is not the problem. The problem is turning it off so if you lower the input signal to 0.2V then the transistor will probably be off but if your external signal source is 0.6V or close to it then the transistor will probably not turn off completely. If you put a diode in the emitter lead then the turn off voltage at the base only needs to be lower than around 1.2V. If it is then the collector will go up to around 3.3V. Above 2V and the transistor will be full on taking the collector to around 0.6V.

If the diode is in the base then you will still need 1.2V to turn on the transistor but when you take the input diode down to 0.6 or thereabouts from your signal source then the base voltage is .... ?

The classic TTL circuit solves the problem another way:

http://en.wikipedia.org/wiki/Transis...ental_TTL_gate

If we were driving the Rx pin with a true RS232C signal as FrSky expect then there would be no problem at all. It is just that we are trying use unipolar signals with a logic low not quite low enough .

Greg

Originally Posted by flyer5

Hallo Trevor,gke ,

I recommand for the inverter a simple transistor BC547 with two resistors 2,2 K ohm. That is easy and should work.

Don't see the point you are just adding one inverter with poor noise behaviour in front of another.

Adding a diode shifts the switching threshold but does not change the noise immunity. While changing the threshold may help a little we really need some hysterisis e.g. a Schmitt trigger.

I need to carry out some tests, too much speculation at present, but I favour using the either a 2N7002 (to shift the threshold) or going into the processor i/p directly and using the Schmitt trigger that is already there.

Trevor