I set up a heli with F.Port, a R-XSR and RXSR-FPORT_FCC_ACCST_191128.frk firmware. The radio functions and the receiver telemetry (RSSI, RX voltage) work. The Brain2 telemetry and the integration don't work. I set it up with a X4r-SB and F.Port and everything works fine.
I heard on another forum there is an incompatibility with the R-XSR on F.Port. Is there anything I can do to make the R-XSR work with F.Port?
Unfortunately it doesn't depend on us but it depends on FrSky that has to release a new firmware for XSR receivers where the F.Port protocol works also for telemetry data (that works with F.Port specifications as with X4R receivers).
We had already reported the problem to FrSky at the beginning of January. But in the meantime FrSky hastily released the first versions of the new ACCST 2.X.X firmware that modify the RF operation of both TX and RX, meanwhile FrSky is also releasing the new ACCESS firmware for all their receivers, then there was the Chinese New Year that stopped activities in China for a month, and then the Coronavirus. I believe that the operation of the "BETA" F.Port protocol for XSR receivers is the last of their priorities for FrSky.
From a purely technical point of view, the problem with F.Port is that the receiver's port immediately after sending the request packets to the sensors should immediately listen (go into input mode) to receive the answers of the questioned sensors from the bus as it happens with X4R receivers:
Instead in XSR receivers the port remains in output mode, so the signal sent by the sensors to the receiver is not read by the receiver and is physically clamped:
So far FrSky has not yet been able to release firmware for the R-XSR receiver that works correctly in F.Port mode. The radio frequency signal protocol (ACCST or ACCESS) has nothing to do with the serial output protocol of the receivers.
But we still haven't completely lost hope that FrSky's engineers will succeed sooner or later (as they have succeeded in the past with other receiver models).
Continue the "battle" with FrSky to make them understand that XSR receivers in F.Port mode transmit radio channels but do not receive telemetry values because the receiver's port is always locked in Output and never switches to Input (Half Duplex).
However, we received the F.Port firmware file for X4R-SB working with the new ACCST 2.1.0 protocol (X4R-SB receivers due to their hardware will unfortunately never work in ACCESS mode). Since they have not yet published it on their website we enclose it below for those interested.
We also managed to purchase an RX4R receiver and a G-RX6 receiver and after loading the latest ACCESS 2.1.0 firmware and modifying an output connector to bring the Smart.Port uninverted signal to one of the servo connectors, we can confirm that they work perfectly in F.Port mode.
In summary, for those who want to use the simplified F.Port connection, the following verified choices are currently available:
1) Only with old ACCST transmitters: X4R-SB receiver. 2) Also with new ACCESS transmitters: RX4R or G-RX6 receiver.
For now the XSR receivers with the current firmware in F.Port mode work only as receivers without telemetry and therefore also without "Integration".
I had already tried wiring-up the inverted S.Port on the RXSR, without success. After reading this, I decided to try the same thing with an RX4R. It works!
On the back of the RX4R there's an oval-shaped solder pad. I soldered one of the spare wires to that pad and swapped it into the servo connector shell.
Are there any known issues with making the Frsky R9 mini OTA work (with ACCST 1.x firmware)?
The numerous FrSky receivers use two very specific standards:
S.Bus for the transmission of the values of the various radio channels to the control unit. Smart.Port for telemetric data reception and transmission.
Therefore if your receiver also uses these two well defined protocols (which we have already tested, verified and tested using numerous FrSky receivers and using both ACCST and ACCESS protocols testing each receiver with each transmiters) there should be no problems except specific problems in the receiver's firmware currently used for which you should contact FrSky and not us.
Unfortunately FrSky releases every week either a new receiver, or a new transmitter, or a new telemetry sensor or a new firmware for the receivers or a new firmware for the transmitters or a new firmware for the sensors and in addition to this there are also frequent releases of new versions of the OpenTX software and new data to update in the transmitter SD.
In all honesty we have neither the time nor the resources to always be able to buy all FrSky products and to try all updates. In addition to the money for the continuous new product purchases, it would not even take a full-time paid person to try and test everything. Moreover, all this would not be justified, since only 5.87% of the users of our flight control units use FrSky.
Thanks for the quick response. I agree that it is not "your" (=MSH) responsibility to confirm Frsky has followed their own protocol standards. However you *are* easier to catch hold of... ?
I wish that I had been more clear, I was specifically asking about f.port. Dual connections on these micro receivers are a pain that I don't need to deal with. If I'm going that route, I'll stick with full-sized receivers. I think that Frsky has created a cluster-* by using the inverted s.bus, and seems to have made it worse by calling out the f.port uninverted (or inverted with respect to the s.port signal used to generate it)
Having said that, would you be able to answer some pointed questions about Brain2?
1. I have tested Futaba-R2008SB s.bus (normal) and Frsky-X6R s.bus (inverted) inputs on Ch3 of the Brain2 unit, and both command signals are received by Brain2.
2. I did confirm that my R9 mini did receive s.port telemetry back from the Brain2. (specifically RPM telemetry)
1 + 2 suggest that the Brain2 can deal with both normal, and inverted input signals on channel 3. Moreover, Ch3 can deal with inverted signals in both directions. (un-inverted output-telemetry-wasn't tested...)
Questions:
1. I missed the clue in your response above, it seems like the F.port protocol works with the uninvert hack on the receiver. This would be following the f.port definition. Did I read this correctly?
2. Is it possible to have a switch in the setup so Brain2 can be configured to work with both inverted, and "normal" f.port signals?
I suspect I'm experiencing a signal inversion issue, because neither my R-XSR nor my R9 mini are presenting even 1-way communication, which I would expect even on the R-XSR; and I didn't use the un-invert hack (if that was what was tested by MSH). From a reliability standpoint, I would rather not add another component to the system, but it seems like a bi-directional signal inverter needs to be part of the system.
Thanks, any clarity about how Brain works is appreciated.
Thanks for the quick response. I agree that it is not "your" (=MSH) responsibility to confirm Frsky has followed their own protocol standards. However you *are* easier to catch hold of... ?
I wish that I had been more clear, I was specifically asking about f.port. Dual connections on these micro receivers are a pain that I don't need to deal with. If I'm going that route, I'll stick with full-sized receivers. I think that Frsky has created a cluster-* by using the inverted s.bus, and seems to have made it worse by calling out the f.port uninverted (or inverted with respect to the s.port signal used to generate it)
Having said that, would you be able to answer some pointed questions about Brain2?
1. I have tested Futaba-R2008SB s.bus (normal) and Frsky-X6R s.bus (inverted) inputs on Ch3 of the Brain2 unit, and both command signals are received by Brain2.
2. I did confirm that my R9 mini did receive s.port telemetry back from the Brain2. (specifically RPM telemetry)
1 + 2 suggest that the Brain2 can deal with both normal, and inverted input signals on channel 3. Moreover, Ch3 can deal with inverted signals in both directions. (un-inverted output-telemetry-wasn't tested...)
Questions:
1. I missed the clue in your response above, it seems like the F.port protocol works with the uninvert hack on the receiver. This would be following the f.port definition. Did I read this correctly?
2. Is it possible to have a switch in the setup so Brain2 can be configured to work with both inverted, and "normal" f.port signals?
I suspect I'm experiencing a signal inversion issue, because neither my R-XSR nor my R9 mini are presenting even 1-way communication, which I would expect even on the R-XSR; and I didn't use the un-invert hack (if that was what was tested by MSH). From a reliability standpoint, I would rather not add another component to the system, but it seems like a bi-directional signal inverter needs to be part of the system.
Thanks, any clarity about how Brain works is appreciated.
PnP
1. The S.Bus protocol is a one-way protocol in which signals are always reversed. This with any type of Futaba (R2008SB) or FrSky (X6R) receiver. The S.Bus signals of Futaba and FrSky receivers even if not identical are very similar. In almost all FrSky receivers there is a pad where you can pick up the non-reversed S.Bus signal, but this is no longer the S.Bus protocol.
2. The Smart Port protocol is also a protocol in which signals are inverted but unlike the S.Bus protocol, the Smart Port protocol provides bidirectional communication (like Futaba's S.Bus2 protocol which however has completely different formats).
3. Brain2 can handle inverted protocols such as S.Bus, Sbus2, Smart.Port but only when the correct icons of the protocols to be used are selected. All other known protocols used by all other unidirectional, bidirectional and/or telemetric sensors (not FrSky) are not inverted.
4. The F.Port protocol is a non-inverted and bidirectional protocol but is a different protocol from both the S.Bus protocol and the S.Port protocol.
5. The documents are public and can be found on the internet.
6. In the Brain setup just select the desired protocols by following the side instructions and you will receive all types of protocols. However, you must read the instructions and connection diagrams of the Wizard. Everything is explained.
At the end of all this, it is not clear why all these questions, what you would like to do and what you need.
If you only want to use one connection between the receiver and the Brain2 control unit then you will have to use the F.Port protocol. But as I have already written countless times at FrSly, in the forums and also here, with the current R-XSR receiver firmware the F.Port protocol does not work properly. You will have to change the receiver type for using F.Port protocol or with the R-XSR receiver you will have to use the two separate S.Bus and F.Port connections.
Thanks for the quick response. I agree that it is not "your" (=MSH) responsibility to confirm Frsky has followed their own protocol standards. However you *are* easier to catch hold of... ?
I wish that I had been more clear, I was specifically asking about f.port. Dual connections on these micro receivers are a pain that I don't need to deal with. If I'm going that route, I'll stick with full-sized receivers. I think that Frsky has created a cluster-* by using the inverted s.bus, and seems to have made it worse by calling out the f.port uninverted (or inverted with respect to the s.port signal used to generate it)
Having said that, would you be able to answer some pointed questions about Brain2?
1. I have tested Futaba-R2008SB s.bus (normal) and Frsky-X6R s.bus (inverted) inputs on Ch3 of the Brain2 unit, and both command signals are received by Brain2.
2. I did confirm that my R9 mini did receive s.port telemetry back from the Brain2. (specifically RPM telemetry)
1 + 2 suggest that the Brain2 can deal with both normal, and inverted input signals on channel 3. Moreover, Ch3 can deal with inverted signals in both directions. (un-inverted output-telemetry-wasn't tested...)
Questions:
1. I missed the clue in your response above, it seems like the F.port protocol works with the uninvert hack on the receiver. This would be following the f.port definition. Did I read this correctly?
2. Is it possible to have a switch in the setup so Brain2 can be configured to work with both inverted, and "normal" f.port signals?
I suspect I'm experiencing a signal inversion issue, because neither my R-XSR nor my R9 mini are presenting even 1-way communication, which I would expect even on the R-XSR; and I didn't use the un-invert hack (if that was what was tested by MSH). From a reliability standpoint, I would rather not add another component to the system, but it seems like a bi-directional signal inverter needs to be part of the system.
Thanks, any clarity about how Brain works is appreciated.
PnP
1. The S.Bus protocol is a one-way protocol in which signals are always reversed. This with any type of Futaba (R2008SB) or FrSky (X6R) receiver. The S.Bus signals of Futaba and FrSky receivers even if not identical are very similar. In almost all FrSky receivers there is a pad where you can pick up the non-reversed S.Bus signal, but this is no longer the S.Bus protocol.
2. The Smart Port protocol is also a protocol in which signals are inverted but unlike the S.Bus protocol, the Smart Port protocol provides bidirectional communication (like Futaba's S.Bus2 protocol which however has completely different formats).
3. Brain2 can handle inverted protocols such as S.Bus, Sbus2, Smart.Port but only when the correct icons of the protocols to be used are selected. All other known protocols used by all other unidirectional, bidirectional and/or telemetric sensors (not FrSky) are not inverted.
4. The F.Port protocol is a non-inverted and bidirectional protocol but is a different protocol from both the S.Bus protocol and the S.Port protocol.
5. The documents are public and can be found on the internet.
6. In the Brain setup just select the desired protocols by following the side instructions and you will receive all types of protocols. However, you must read the instructions and connection diagrams of the Wizard. Everything is explained.
At the end of all this, it is not clear why all these questions, what you would like to do and what you need.
If you only want to use one connection between the receiver and the Brain2 control unit then you will have to use the F.Port protocol. But as I have already written countless times at FrSly, in the forums and also here, with the current R-XSR receiver firmware the F.Port protocol does not work properly. You will have to change the receiver type for using F.Port protocol or with the R-XSR receiver you will have to use the two separate S.Bus and F.Port connections.
Thanks BR. I had misunderstood s.bus from Futaba.
This actually lead me down a path I hadn't thought of. I count 5 ways to get telemetry w/Frsky. Once I discount for my feeble mind and poor soldering skills, there are two that are both reliable, and effectively plug-and-play.
If I may press my luck a moment more: From my old marketing exposure, there used to be the concept of a "delighter" feature. While I accept that it is not strictly necessary, and Frsky users are not your core market; for me, a delighter would be for Brain2 to accept f.port in normal or inverted format. If it would be helpful, we can take my reasoning for the feature request off line; otherwise, I think I got what I was looking for, and am more than happy to let it drop.
Continue the "battle" with FrSky to make them understand that XSR receivers in F.Port mode transmit radio channels but do not receive telemetry values because the receiver's port is always locked in Output and never switches to Input (Half Duplex).
However, we received the F.Port firmware file for X4R-SB working with the new ACCST 2.1.0 protocol (X4R-SB receivers due to their hardware will unfortunately never work in ACCESS mode). Since they have not yet published it on their website we enclose it below for those interested.
We also managed to purchase an RX4R receiver and a G-RX6 receiver and after loading the latest ACCESS 2.1.0 firmware and modifying an output connector to bring the Smart.Port uninverted signal to one of the servo connectors, we can confirm that they work perfectly in F.Port mode.
In summary, for those who want to use the simplified F.Port connection, the following verified choices are currently available:
1) Only with old ACCST transmitters: X4R-SB receiver. 2) Also with new ACCESS transmitters: RX4R or G-RX6 receiver.
For now the XSR receivers with the current firmware in F.Port mode work only as receivers without telemetry and therefore also without "Integration".
