Frsky D8 Telemtry

Frskyx3 test build is updated - bb0
- Updated telemetry packet decoding for stream data based on new packet format information

The telemetry packet format documented in the code was not correct (corrected info below). Thanks for the capture Alex!

The vario value seems to make big changes, but that's what's in the captured telemetry packets. Have not made any adjustments for the Amps yet, let's see how this version works.

D8 telemetry packet format

Hello,
Test Ver.bb0 on Devo8s, D8R

VoltA : ok works good and follows changes fast, no jumping. perfect

Amp follows changes very slow and looks like it cuts the Spikes, tested with Digital Servo and it needs around 8 to 10 Seconds to jump from 0.5 to 1.1 ( it is to slow to use it. 2 sec to follow is better )
Alt is only following neg. Numbers and showing not any real Alt. Most time to low Values at + and -.

greetings Alex

Test build updated - 0da
- Fixed formatting of negative numbers

Single digit negative numbers were not formatted properly which may have been confusing the Alt display. Though the captured data shows both Alt and Vario starting out with some large values. Let's see how this version looks.

Not sure about the Amps. There is no filtering or smoothing in deviation. Does it behave differently with Taranis?

Hello,
Test Ver. 0da, Devo8s,d8r

VoltA : ok
Volt1 : ok
RSSI: ok

all other Data are looking wrong somehow .
Looks like they using some time a wrong Data from the Steam. It is better then the jumping build but something is wrong.
The Alt is now showing + and - Numbers but it looks not right , the Values are to low
the VSI is better and the Amp needs a long time to change.
I can see the updating at the boxes ( it does some blinking ) but some times it stops, and after the stop it updates to the right Number.

greetings Alex

Test build updated - 341
- Fixed error in sequence check

You're right, still was wrong. Was incorrectly ignoring good packets. If there's still bad data appearing periodically a video will be helpful.

The altitude is above ground level now. The ground level is set to the first value read as soon as altitude telemetry is received. The scale might be wrong though.

I just built your Frskyx3 branch from your current git and it gives me the same error as I just reported in www.deviationtx.com/mantisbt/view.php?id=679 , you may want to have a look. Returning to build 070e55e and it works fine again.
Edit: Although this could be the other way around, caused by something in the master Deviation branch, of course.

Yes, looks like it's related to the change to exclude the standard gui from the 7e. Something's being written to the model file that can't be read. Too nice out to look at it now...

Hello,
Test Ver. 341 ,Devo8s,D8r

here is the Video

www.dropbox.com/s/yit29bd4p46pkqn/BDMV.mov?dl=0

Watch for the clicking Noise, this is from moving the Servo.
It draws around 1 Amp.
There You can see the pause at Amp and then the refresh of it after around 5 to 10 Sec.
after it , it takes the same Time go go down to 0.5 Amp.

the Alt does not doing right.


greetings Alex

Thanks, the videos are great. Something's definitely wrong but not seeing what yet. That large value that pops up in VOLTA occasionally shouldn't be there. There's still something I'm not understanding about the telemetry data.

I see what you mean about the lag in the current reading, but there's no code that delays it. Does the value change more quickly on Taranis?

I've updated the test build (still 341) with some instrumentation to help see what's going on. Please make another video with this build. The changes are:
- Altitude displays raw value instead of AGL (I do suspect the altitude calculation may be wrong)
- CELL1: increments with each telemetry packet received
- CELL2: increments on telemetry packet sequence error
- CELL3: raw VOLTA before decimal point
- CELL4: raw VOLTA after decimal point
- MIN CELL: raw ALT before decimal point
- ALL CELL: raw ALT after decimal point

Hello,

the Update Speed is around 1 sec on Taranis and FrskyX.
On Servo moving it jumps at around 2 to 3 Sec. to 1.0 to 1.1 Amps.

The other Datas on Taranis is the same Speed , all around 1 Sec delay.

Doing the Test and Video of the new Build Tomorrow.
greetings Alex

Hello,
Test Ver.341, Devo8s, d8r

the 1st Video named Amp is the Amp Test with the same Servo and Setup from the previous Tests

www.dropbox.com/s/9iblnskmii01e7w/Amp.mov?dl=0

The 2nd Video is the Altimeter Test, here is the beginning with higher Pressure ( Alt lower ) and then comes the lower Pressure simulation ( higher Alt)

www.dropbox.com/s/beqr2td9frt8u2m/Altimeter.mov?dl=0

greetings Alex

you are always Welcome hexfed

Test build updated - 5bc
- Reject telemetry packets with invalid CRC
- Properly handle altitude as signed value
- Adjust altitude scaling

I don't expect any change in behavior with this test build. All the packets in the datalog capture had valid CRC so it's probably not an issue.

The large values that appear in CELL3 and 4 are incorrect. The values (converted to hex) seem to contain a sensor ID instead of a value, as if a byte was dropped from the telemetry packet. Or they could be some special value that's indicates something about the sensor? I think an error is more likely. I'll keep looking...

I've adjusted the altitude scaling. Please check if the altitude is close to ASL (when not jumping). It may still be off by some factor of 10 - every reference I look at has a different opinion on what the scaling should be.

Hello,
Test Ver.5bc Devo8s,D8r

The Alt Function is getting better !
There is only a little Glitch.
It shows the right Alt 193 Meter and then on 0:08 i give a little vacuum to simulate higher Alt.
At 0:24 i open the chamber to give it the normal Pressue.
All looks good but some wrong Numbers show between on climb (it jumps up and down a little bit ) .
Maybe it is normal (sensor Prez. and damping ), but the Alt is now working good.
Climb Rate looks good to, a little fast but looks ok.
-> maybe some fine Tuning with a little smoothing to do later

www.dropbox.com/s/tlmtbhit8bhf2cb/Alt.mov?dl=0

The Amp Function is now better to ,but a little slow, maybe here the same with the Sensor.
At VoltA is some thing wrong, here comes a very big Jump some Time.

www.dropbox.com/s/e6p54t3hb1rvh8h/Amp.mov?dl=0

greetings Alex

Making some progress The jumps to big values still needs to be solved. I'd like to give the datalog test another try.

I've made a new test build "frsky_telem" that will (hopefully) save the received packets to the datalog file. Trying to get more information about the occasional oddball numbers. Need to figure out if they're really good data or some kind of error.

One change I'd like you to make before starting the test is to set the AD2GAIN value in the model to 10. I want to see if AD2 is still updated even when used for Vario. So after that change the test procedure is:
1) Upgrade to frsky_telem test dfu
2) In USB mode copy the blank datalog.bin file from the zip to the transmitter
3) Connect to the receiver with telemetry sensors active, and make a video of the telemetry test screen
4) Continue running until CELL1 exceeds 400. That should fill the datalog file.
5) Power up in USB mode, copy off the datalog.bin file, and post that and the video.

If the capture does not include VoltA jumping to a big value, please repeat until you get a capture of that.

If anyone's following along the latest functional changes are in my frsky_telem branch in github. Does not include the datalogging code.

Thanks!

Hello,
Test Ver.8ef

there is some thing wrong with theTest Build.
It counts 10 Seconds and then the Boxes filling with garbage ( looks like overwriting the Memory of the Charset, only some Points as the Char it self )
Some times a reboot comes up with some Lines at the Back ground

greetings Alex

Thanks PB. A few of the files do have hub telemetry data so will be helpful.

Alex, I was being risky trying to datalog in the isr so not surprised that there's trouble. If the datalog.bin file is not all zeroes please go ahead and post it - it might have saved some data. I'll look at what PB's provided and come up with a next step.

The PB data has two D8R hub telemetry captures and one from an X6R in D8 mode. The data from the X6R is all nice clean full length packets with no sequence errors (but one packet with extra bytes that I'll ignore...). The captures from the D8R are not consistent. Most of the packets show invalid CRC and many short packets. But I think the captured data is suspect because there are sometimes obvious bit errors in packets where the CRC check is okay. For example what should be 5a of the fixed id is 58 or 3a in the capture. Perhaps those captures were made while the protocol was still under development. PB may be able to comment on the circumstances, but I'm not sure it matters because running even the bad data through the existing decoder did not produce the out-of-place large values seen in the videos. All the packets that got past the length, fixed id, and crc checks had consistent data for the sensor.

The frsky_telem test build is updated - 7c1. I added several more checks for the length bytes to try to reject any bad data. The CELL1-3 values indicate packets dropped due to those checks. They should all stay the same value - incrementing for every packet - if every packet is good. The CELL4 value is the number of packets containing hub telemetry, and CELL5 counts how many of those were out of sequence. The MIN and ALL CELL values are high water marks for the bp and ap VOLTA values. Please make a video

Alex, you mentioned you could get information from a FAS-40 and I think now's the time if possible. Any extra information will help.

Hello,
Test Ver.7c1,d8r

Done 2 Tests, 1st is Amp Test with Datalog1.bin:



www.dropbox.com/s/1sdrcdbfvesi6pg/Amp%20bin1.mov?dl=0

2nd Test is Alt test with Datalog2.bin:



www.dropbox.com/s/g3m7etml9npzolb/Alt%20bin2.mov?dl=0


-> Looks like there is some thing stopping the Amp Stream for short Time.
-> on reducing the Vacuum from the Alt it over shoots to - 24 short Time ( maybe the Sensor itself does it ? )

greetings Alex

Thanks Alex. This version doesn't have the datalog capture so don't need to save the files.

Didn't see the large value in VOLTA so maybe the additional length checks helped. It does seem like something's off with the altitude and vario behavior, and not sure about the amps. Is it possible to use the hub telemetry with one of your X-series receivers in D8 mode? It would be interesting to know if that combination behaves the same.

I'm going to clean up the debug code and make a pull request as this is much better than what's in the nightlies. Some info from additional testers will be helpful.

Then I think a test version to see how often the Amps sensor is reporting data...