New FrSkyX protocol

Cereal_Killer wrote: Where can I get the newest? I had just downloaded and flashed the one I did (572bda9) two nights ago.

It's the same place that you had downloaded. It's just been updated yesterday. That's why yours is 1 version behind.

www.deviationtx.com/downloads-new/catego...7-hexfet-frskyx-drop

Ah cool, thanks!

Ok so not complaining here but is there any place (other than reading code) to find the changes from one build to the next? "Build release notes" of the like...

Cereal_Killer wrote: Ah cool, thanks!

Ok so not complaining here but is there any place (other than reading code) to find the changes from one build to the next? "Build release notes" of the like...

You can goto github and check the commit log. Here is the one for frskyx_drop from Hexfet. It lists the specific changes associated with that particular version. Hope this help.

github.com/hexfet/deviation/commits/frskyx_drop

Hi,
Any way to get raw S.Port data out the back of the tx (maybe via the unused serial port that is the trainer port) like you can from the s.port mirror pin on taranis?

edited to add:
Absolutely any pin would be great, I figured that serial port would be convenient but literally any pin would be great, even if I need solder to a MCU leg directly!

+1
or via miniusb port

just to inform you that the last test build (543f89d) is ok for me, i fly all the afternoon this Sunday without any problem, i don't Watch the telemetry a lot because i fly fpv but for me it's more correct i note less corrupte data on the telemtry screen

Thanks for the report. I've made a pull request with the same changes that are in the test build.

S.port data out would be a nice addition - I'll take a look. Waiting till I have equipment before more changes (4n1 board just made it in-country).

Test build frskyx_telem is available.

• Fix GPS scaling for altitude and speed values. Fix GPS time display where hours and minute values were swapped.
• Remove multiplier for fuel telemetry value. Documentation says should be percentage number 0-100.
• Remove scale multiplier for RPM and report raw value. Need to add ability for multiplier for displayed value
• Fix minimum cell value calculation

Based on testing with XSR receiver and this most excellent S.port Telemetry emulator running on a Pro Mini.

All the other telemetry values matched what the emulator is sending. Would like some real world verification, especially for the GPS data.

Hello,

same Reboot on 7E with FrskyX and Bind

Greetings Alex

EDIT:
On my 8s with Bild 5.0.0 from vlad_vy 10.10.2016 the Bind and RX is working ( no 4in1 )
On the 7E with Build 5.0.0 from vlad_vy 05.10.2016 it does Reboot to (no 4in1 )

Thanks! I'd never looked closely at that code before. The first loop will never terminate if get_tx_id returns 0, or a number with one bits only in the last bit of each nibble, or a multiple of 47 that's unchanged by the and operation. A bit surprised it's happening to multiple people (including me).

get_tx_id always returns the same value for a given transmitter and fixed ID. I've pushed the fix below. This guarantees the loop will exit. The set of frequencies used will still be determined by the tx id.

The frskyx_telem test build is updated. All fixes for hub telemetry. These apply to Frsky protocol as well - the hub telemetry code is shared.

• Improve minimum cell algorithm for hub telemetry
• Fix interpretation of telemetry value for CELL voltages
• Remove scaling from RPM and report raw sensor value

Tested with D4RII with Frsky and code from this library . All the other hub telemetry sensors were fine.

The frskyx_telem test build is updated.

• S.Port telemetry packets output on trainer port for FrskyX (serial 115200 bps, 8, n, 1)

Tested on Devo10, and likely to work on all Devo tx.
No protection against conflict with PPM In, so don't do that.

This change is not included in the pending pull request as they really aren't related.

Interesting that the over-the-air protocol does not include the CRC of the S.Port packets. Have to calculate it and add to conform to the s.port protocol.

edit: had to disable extended telemetry for the f7 build. Exceeded memory by 4 bytes.

Wow, impressive! Thanks for getting to that!

Would it be better to output it at the same baud as s.port is IRL?

The 115200 rate is the current default, so using it won't break anything else. Though I think only debug builds send to the usart currently. And mwm's voice alerts feature...forgot to mention the conflict there.

Changing to 57600 would probably be best if it increases compatibility with existing decoder devices.

Need ideas on how to handle conflict with PPM In. And I'd like to get info on the Frsky UART telemetry devices so we could do a full-duplex serial link.

Also looked at using FREQEST to adjust the FINE freq setting. I'm planning to add FREQEST and received RSSI as telemetry items. You can manually adjust your FINE setting base on the FREQEST value. The FREQEST value is pretty noisy so don't want to attempt an automatic adjustment. It does work - my tx showed FREQEST of -15 when FINE was set to 0. Changing FINE to -15 resulted in a FREQEST value around 0. But in my limited indoor testing it didn't make a difference in RSSI when wandering around the house.

Branch with s.port out the trainer port is here .

Nice work! Maybe add a protocol option to enable sport telemetry serial out. The user can then choose to enable it if he's not using the trainer port for other stuff.

@Hexfet,
FRQEST was tried before(years back) to be used,But is useless.
If you want to use some more reliable indicator to adjust fine variable the best is LQI.
I will introduce it in multi in the future to be displayed on 9X/9XR or Taranis,
Any telemetry frame had LQI bytes at the end the calculation is.
Lqi=packet[Len-1]& 0x7F;
Lqi<50 good (middle of channel bandwidth)The maximum energy received /transmitted is on the middle
LQi>100 not good.,channel hit at the end of bandwidth
The idea is of the best transmission to be sure the channels is hit at the peak or closer.
If you want to have some idea how it looks like LQI with channel frequency .
Offset is the fine variable(translated in frequency hertz)in our case.

see below

@ Hexfet,

Are you in the US? I have a frsky s.port to UART adapter (think it's called a FUK-3 but I may be wrong on that name, it's definitely what you're talking about but I've never needed it for anything). If I can drop it in the mail cheaply [CONUS] it's yours. If you're not US I may as well just order you one from banggood...

m.banggood.com/FrSky-Smart-Port-Converte...le-SPC-p-929073.html
Edit: this is what I have, for $3 i''ll just buy you one from China anyway (hell I've got that many points it'll only cost me a few cents cash). PM me your address, I'll order it this weekend

Thanks for the offer CK, but I'm talking about the Frsky sport to uart converter . Sends two way serial data at low bit rates.

Thanks for the heads up midelic. I'll add LQI to the telemetry test page as well. When LQI is high, does FRQEST reliably indicate the direction to adjust the frequency to improve LQI?

petsmith, I'm leaning towards checking if ppm in is active and disabling the serial out if so. If that turns out to be hard I'll make a protocol option.