Frsky D8 Telemtry

Hello,

there is only rssi and volt1 at D8 Mode

i think

That makes sense because I don't see a place to plug the hub into an X receiver. The data from PB contained a file named X6R with D8 format telemetry which leaves me wondering.

I've made the datalogging safe (I think) - zip file here . Each capture you make please first copy the datalog.bin file from the zip file to the tx so I can tell when the capture ends. The "bytes left" value on the datalog screen will stop at zero when the datalog is full.

CELL1 counts the number of packets containing hub data. These will also be written to datalog.bin up to its capacity (about 780).
CELL5 is incremented each time current (Amps) telemetry is updated.
CELL3 and CELL4 increment with each update of altitude bp and ap values, respectively
MIN and ALL CELL are the most recent bp and ap values

The frsky_telem test build is updated with the same code that's in the pull request.

Hello,
Test with Datalog Ver.

1st Amp Test:
www.dropbox.com/s/i5yxz9e2r3y07g9/Amptest1.mov?dl=0





2nd Alt Test ( 3 times in a Row on Video ) :
www.dropbox.com/s/qzmb4ys89owdc4m/Alttest2.mov?dl=0





-> VoltA is jumping again

greetings Alex

The datalogs and videos are very helpful

Fixed the jumping VOLTA issue by extending the decoder to require the end-of-frame marker. I guess the rx module takes care of that for the PXX interface since opentx doesn't require it. The malformed telemetry data always occurred when the voltage bp telemetry was split across two rx packets. Seems like the rx drops a couple bytes now and then. Unfortunately I'm having to rebuild my dev box so no new test build yet.

All the other displayed values accurately reflect the values received in the telemetry. Didn't find any other errors in decoding or display.

The current values appear to be updated about as often as the altitude so it doesn't seem to "freeze". Maybe the slow response is due to measuring a fairly small signal for a 100A sensor? All the received values are just single digits as the resolution is 100mA. How does deviation compare to what taranis reports?

The vario telemetry seems to spend a lot of time at the endpoints (+/- 10.2m/s). That's not very fast from what I remember from soaring. What's typical values for an RC sailplane?

The altitude seems okay though the behavior at ground level is a little jumpy with the decimal point moving around. Maybe everything within half a meter of ground should be displayed as 0? The altitude and vario might benefit from averaging, but that's a future effort.

Hello,

i can try the logging with the fas-40 from my Tow Plane to Day and load it up. Maybe the Datas have better Resolution on the 40 Amp Sensor.

The Climb Rate we use at Sail Planes for Thermal hunting is around +/- 1 m/s for finding it .
An average sail Plane falls around 30 to 50 cm/s and a Value of 0 is flying into a lift, after this we search the Center of the lift Point to gain Alt.
So the best is to have a good Resolution around the +/- 1 m/s and the higher or lower Values are more for statistics .

btw for Info:
Many here at the Club use a Device named Picolario, it is a stand Alone Vario with Altimeter and Datalog Function wich sends the Data on 433 mHz LPD Freq.
It sends the Alt and RX Volt as spoken Message. The Vario Beep Tones are high Pitch for Climb and low Pitch for Sink and at variable speed.
The Software on it does an Auto adjust on the Range of this Tones, so you can find the Center of the Lift better .


The most Telemetry Vario Devices are not thad prez. , most Time there is Delay of around 1 sec. and the building of the Software is very complex.
I use the Internal Vario most Time on light Planes where i cant install the Picolario ( old Ver. is the Size of a Lighter).

Some Tests here at Club find the usable Alt at higher 150 Meters, at this Alt you can not perz. see the Lift.
An Alt of 150 Meters is very high for 1.5 Meter Wing Span and there we only need the Signal for Lift and not thad Big Software around it like the Picolario.
Some Times we need to find the Sink Spot to get the Plane save to the Ground


Greetings Alex

Interesting info. Sounds like fun That Picolario is a nice design.

Test build frsky_telem is updated to match the pull request (includes the VOLTA jumping fix).

Hello,

here is the Datalog and Video with the Fas-40 and normal Prez. Altimeter on Frsky Hub
The Fas-40 does not show up on Display ( i think it has a other ID as the Fas-100 from the prev. Test )






www.dropbox.com/s/0lgqvgp3gglwg2b/datalog3.mov?dl=0

i let the other Video Files there , so you can compare all 3.

greetings Alex

Looks like something went wrong with the hub telemetry transmission. After the first sequence the packets indicate they have hub data but it's just the same bytes repeated over and over. They are new packets though because the rx telemetry values, downlink RSSI, and LQI are changing, so it's not a problem with the logging.

The first sequence contains temp, accelerometers, and altitude sensor data. Don't see any voltage IDs. The packet with sequence number 5 is missing so maybe it was in there. Is this from a telemetry setup you always use, or did you have to change something for this test?

Here's the first part of the telemetry data

Hello,
this is the normal Setup from my Tow Plane. I use it with my Taranis.
I changed nothing, only Bind with the Tx.
I testet it with the Taranis after the Video because i had no Amp reading at the Devo and on Taranis all was ok and counting right

-> there was only the FAS-40 and the normal Alt Sensor connected on the Hub

Do you need a 2nd Log from it ?

greetings Alex

Yes, please try again to make sure it wasn't a one-time glitch. If it still has the same behavior I'll make a new datalog version to get more info.

Interesting about the sensors. Some of the captures from PB also had accelerometer and temp data that always appeared to be at max value. Not sure what's happening there.

Hello,

the Test with my Tow Plane.
No changes, only Bind to the Devo 8s




greetings Alex

Thanks. Shows the same data except the packet with sequence number 5 is present in this capture. I've created a frsky_telem2 test build to try to get some more information. All received packets will be saved to the datalog file instead of just the valid ones. I don't expect this to reveal much because the videos seemed to indicate not many packets were being dropped. The CELL1 value counts the packets recorded, and the datalog file holds 819 so no need to go past that. CELL2 counts packets that pass the initial validity checks.

There's also a TEST protocol option. It is a wild guess at a possible cause. Here's the train of thought. If the same telemetry setup works with Taranis, and we're processing the telemetry correctly, then the difference must be something the Taranis is sending to the receiver that we don't. The received packets that have hub telemetry include a sequence number that only increments when hub telemetry data is present. The FrskyX protocol has both tx and rx sequence numbers, which must be in step to keep stream telemetry going, and is from the same company. So maybe the D8 protocol needs a sequence number in the transmit packets when hub telemetry is active? Perhaps? I could not find any SPI captures that show the tx data while hub telemetry is active so can't confirm that way.

The elephant on the train tracks is that this only started when you plugged in the FAS40. Unless the previous tests were made with a different hub? If so is it a different version or different firmware? The first test below is to see what the hub does by itself.

When set to 0 the TEST protocol option does nothing - this is the default. Setting it to 1-4 sends the next expected sequence number in successive nibbles of tx packet bytes 4 and 5. This may or may not cause a difference. It may break the protocol. Any new info might be helpful.

Please make the following tests. Definitely save the datalog for the first two, and any after that show different behavior - on the telemetry test page, rx light flickering, loss of bind, etc. Only need a video for test 2, and any after that show something different on the screen.
1) Recording with only the hub plugged into the receiver - no sensors. Protocol option TEST set to zero.
2) Recording with the telemetry set up as you normally have it. TEST still zero.
3-6) Same as 2 but with TEST set to 1,2,3,4.

Hello,

i rebuild the setup from my Tow Plane without the Hub on my Bench (High Prez. Altimeter as Hub for the Fas-40)
and all works.
It looks like the Hub it self is the Key of the Problem.

-> the Connection over the Altimeter use the RX and G Pin, then The Altimeter do the same to the RX.
-> on the Hub we us a 2 Wire Connection named Data out and then from Hub to RX the RX and Ground.
-> the Same is with the FAS-40 direct to the RX, here is RX and G used and all is ok at Deviation

I tested to connect the Data out to the RX and noting does show up

doing later the the new Home Work

greetings Alex

my 2 ct,
do we need the Hub Thing working ? how many are in use at the Field ?
After available of the High Prez. Altimeter the most use it for the Hub, to bad that i have not some other Sensors to connect it onto the 2 Wire Data in of the FAS - Series.
But i think the Temp and some Other Sensors are only usable with the Hub itself because they have no Cpu inside and sending only Analog Values.

Yes, it seems the hub behaves differently than the altimeter. That's a good test.

The manual for the high precision vario shows a diagram where the hub is plugged into the vario, then the vario connected to the rx. Could you try that also, with the FAS40 plugged into the hub?

I don't know how many folks are using the hub, but I'd prefer not to leave an unfixed issue if possible. However if these tests don't turn up any clues it will probably be necessary to have SPI captures to make any progress. Haven't been able to find any so far.

Hello,
the Test with my Tow Plane ist the FAS-40 over the Hub

greetings Alex

From what you described above I understood you have the hub connected directly to the receiver. According to the documentation an alternative configuration would be to connect the hub to the high-prez vario, then connect the vario to the receiver port. I wonder if that would change the behavior. Though you're probably right the difference is in the hub itself.

Hello,
Yes , High Prez. Vario as an Hub for the FAS-40 or FAS-100. So you do not need the Hub between .
Only for Temp and some other brainless Sensor we need the Hub, and then is the Hub on the RX and all Sensors goes into the Hub

My Test 1 is FAS-40 or 100 -> High Prez. Vario -> RX , here is all ok ( Data is shown on Display but not 100% ok )
My Test 2 is Altimeter and FAS-40 --> HUB --> RX, here is only the Altimeter shown and no FAS Data on Display.


greetings Alex

p.s. now doing the Homework

Hello,
logging Test

Number 1 is without Sensors, Number 2 is with Sensors on Hub
2nd Number is TEST Set Number

- On 2_1 ( Hub with Sensors and TEST Set to 1 ) VoltA was working short Time (around 5 Sec. )
- On 2_3 VoltA and Alt was working short Time, looks a little bit better then 2_1

2nd Part






1-2-3 is renamed from Forum Software, it has to be 1_0
2-2-3 is renamed from Forum Software ,it has to be 2_0

greetings Alex

Interesting! Looks like the hub sends both temperature and altitude values even if no sensor is plugged in. The temp values are always -16 which is in the valid range for the temp sensors so not sure how to reject it. (Need to fix the display since temp is currently interpreted as unsigned).

Setting TEST protocol option to 3 does change the receiver behavior. The sequence number continues counting past 7 and stops again at 0xf. So maybe it's mod 16 instead of mod 8? or it could count up to some other number. At least it seems we've found what value to change on the tx.

I've updated the frsky_telem2 test build. The TEST protocol option now only has two values - 0 and 1. When set to zero the sequence counter will increment mod 16. If this works then we've got it. If not, please set the TEST option to 1 and make a datalog capture. In this mode the sequence counter will be mod 256, but if the receiver goes back to zero before that the datalog will tell us what the cycle value should be.