ERSKY9X Coding

[jhsa]

Thanks Mike. But so we understand, where must this be corrected then? OXs? DIY RX? Ersky9x? Multi?

João
Edit: And how can you explain that the combination DJT/ old D8R seem to work ok?
It doesn't make sense to me

[MikeB]

I believe ersky9x is fine. The data packets from the module are formatted correctly, the user data within the packets is incorrect in places.
At one time I did find a problem in the Multi module where new telemetry data was received from the Rx before previous data had been removed from a buffer, so corrupting the previous data. This problem may still exist. If the OXS works fime with the DJT/D8R combination, then the OXS is most likely OK.
You will need, I think, to try wither the Multi module with the D8R and/or the DJT with the DIY Rx to try to narrow down where the problem is.

I have just posted a new test version of ersky9x. This includes some timers on each telemetry item (unless I've missed some!).
In particular, if a spurious cell is received, causing the CTOT value to become incorrect, it will correct itself a few seconds later when the timer runs out.

Mike.

[jhsa]

I tried all the combinations module/receiver and the results are posted above. Any suggestions how to narrow the problem? If we don't find the problem, then Hub telemetry is useless with multi module and or DIY receiver. Thr DIY receiver fails with both modules, the D8R fails with the multi module. Why would the D8R work with the DJT?
This makes me think that both multi protocol module and DIY receiver are at fault?

João

[MikeB]

I'll have a look at the Multi code handling of the hub protocol again. It may just miss something.
When telemetry data arrives at the module it is, I think, sent as up to 10 bytes at a time. These are passed on in packets that can only hold 6 bytes of user data, so need 2 packets to be sent. These packets may be split by a link packet (A1,A2, RSSI etc.). During this time more telemetry data may arrive, so there is scope for problems if insufficient buffering is present.

The DJT no doubt has plenty of RAM and buffering so doesn't lose anything.

Mike.

[MikeB]

I'm not sure what hardware combination was being logged in the raw logs when I found one problem, but there seem to be exactly 6 bytes missing from the user data stream in the place I can find an error.
The packet format is exactly correct (with sequence numbers), so this suggests that the telemetry data received by the module was already missing those 6 bytes.

Mike.

[jhsa]

I'm not sure what hardware combination was being logged in the raw logs when I found one problem, but there seem to be exactly 6 bytes missing from the user data stream in the place I can find an error.

Same combination as the same normal log file posted in the same zip file as the raw log. Multi module and DIY RX.
You asked me to log a setup that I knew was going to fail..

The packet format is exactly correct (with sequence numbers), so this suggests that the telemetry data received by the module was already missing those 6 bytes.

Then we have to find out where they go missing.. Is a logic analizer of any help? Would have to learn how to work with it
Thanks
João

[jhsa]

The DJT no doubt has plenty of RAM and buffering so doesn't lose anything.

Mike.

The Multi I am using has a STM32 chip, so I guess RAM would also be ok?
Receiver and oXs have a m328p.

João

[jhsa]

Mike, please watch this video. I already reported this problem before but here it is again in case you've missed it..
Every I press EXIT the Cvolt displays 0.00. Or is this supposed to reset the telemetry?
Attached is the log file from the video, or part of it.. I do believe that when the Cvlt displays 0.00, this is logged as 4.5?

This was another multi module with m328p.

https://www.youtube.com/watch?v=9zM9s2jJ0iE

Thanks

João

[MikeB]

That is as implemented in the firmware. CVLT is 'reset' as part of resetting the telemetry and set to 4.5 volts, but, to avoid 4.5 being displayed, it is displayed as 0 until a real value is obtained.

Mike.

[jhsa]

But why does the radio give a battery "Cell" alarm when I press EXIT?

João

[MikeB]

Is this done by a voice alert?
I'm trying to locate the source of your cell alarm.

Mike.

[jhsa]

yes, voice alert.. I should really make a voice file for the low Cell..

João

[MikeB]

OK, what is your voice alert set as please.

Mike.

[jhsa]

source Cvlt
V<val
3.40V
Haptic1
play source after
on no telemetry play
name
"FLT_BATT"

[jhsa]

Mike, I believe Midelic just fixed the FUEL problem as the logs now seem to return zeros, but the FUEL bar is always visible as soon as hub data is received, even without being set. it doesn't show if the receiver is OFF. Is that normal?
Didn't you say that you have a 4 in 1 module?? This happens with both the STM and Atmega versions of the multi module.
Thanks.

João

[jhsa]

Mike, another bit of info here that might help..
Before the problem happens, I can press EXIT as i like, I see Cvlt go to zero, but no alarm sounds. After the first alarm, and even after no extra cells have other values other than zero, every time I press EXIT, i get an alarm.

João

[MikeB]

The FUEL bar is always visible if hub telemetry is being received. The original real hub always sent a value for fuel even if no sensor was connected, so it gets displayed.

I've written a python script to scan through your log file.
Looking at over 5900 user data packets, I've found 5 that are exaclty 2 bytes short.
We expect something like:
7E FD 06 0E 06 07 0E 5E 06 17 7E
but the 5 packets are missing 2 bytes so the 7E appears early

7E FD 04 0B 5E 39 27 1C 7E 7E FE <-----
7E FD 04 0F 05 5E 00 5E 7E 7E FE <-----
7E FD 06 0C 06 27 1B 5E 7E 7E FD <-----
7E FD 06 12 17 24 5E 1C 7E 7E FD <-----
7E FD 06 04 07 0E 5E 06 7E 7E FD <-----

These are created by the multi module from the received data. Either the multi module is not sending the 2 bytes, or they are not being received by ersky9x. As far as I can tell, it is the last 2 bytes before the last 7E that are missing. This suggests the multi code is not sending them.

Mike.

[jhsa]

Nice find Mike, but that doesn't explain why the DIY receiver fails with the DJT
So, perhaps there are more than just one problem, or the problem might be on Ersky9x??
But that also does not explain why the DJT and D8R work. This is crazy..

I think we are dealing with several different different problems here. It will require team work to fix this
I think the fUEL problem was fixed by Midelic.. FUEL seems to return always zero now.. At tleast for the last few logs
João

EDIT: will have to send a voltage as fuel to see if all is good..

[MikeB]

Same combination as the same normal log file posted in the same zip file as the raw log. Multi module and DIY RX.

OK, for the multi module, this is the STM chip one? I need to know how the serial is being sent, inverted or not, hardware or bit-banging.

Mike.

[jhsa]

Yes STM, I use COM 2 on 9XT, so Normal serial, not inverted.

But the multi with Atmega 328p does the same problem

João

[MikeB]

Are you using serial mode (not PPM)? The baudrate depends on this. The DJT uses 9600 baud, Multi on serial uses 100K baud.

I've also found two places where 1 byte is missing, together with unusual user data.
After you have seen some problems, pleas have a look at the DSMDIAG screen. On the bottom line are 3 (hex) numbers. These are counts of UART errors (including parity errors). Let me know if they are not 0000.

As you say, probably more than one problem.
Perhaps a test with D8R and the AVR Multi module (raw logging since I have the python script to help look at it.) as I can try that as well and this will test the Multi module specifically.

Mike.

[jhsa]

Will do when Im home Mike. Yes I use serial mode of course..

[MikeB]

I've started to do some tests. I'm using a real hub, D8R-IIplus and a DJT to start with. I logged this for several minutes, and apart from a loss of telemetry on one occasion (Tx and Rx too close I think), the log file is fine.
I'll now repeat the test using an AVR 4-in-1.

I have the python script parsing the logfile and showing the user frames and also extracting the original user data so it is easy to see.

Mike.

[jhsa]

try putting the radio in range test mode and walk away with it.. It seems to make it happen quicker..

João

[planger]

I've posted a new version of Multi on GitHub which I hope will address the above FrSkyD telemetry issues. Can someone test?

Pascal

[jhsa]

Of course, give me a couple hours

[jhsa]

Mike, I have just noticed an error in the Cvlt logging.
it seems to miss the first decimal number. It should log 4.03, it logs 4.3.
Did a little test with the latest bin from Pascal for the multi.
First log was with the original old D8R receiver.. There is a little error, but no alarms.. Please see my comments on the right side on the line where the error is. At some point the Cvlt (lowest cell) displayed 3.82V for a couple seconds, but all cells were above 4V.
Second log is with the DIY receiver.. It failed. At some point the lowest cell value just went to zero, and the Ctot increased to 16.7V. I have a 3 cell battery.

João

EDIT: will do another test with the original frsky receiver.

[midelic]

FRSKY-2017-01-31_.csv

(6.48 KiB) Downloaded 197 times

Mike ,
I'm trying to recreate the joao problem with cells voltage.
I have programmed an openx sensor to send vario Vfas and 3 voltage cells but I cannot see the cells individually on display,I have log them and is zero mostly .
Vfas is displayed correctly for a 2S lipo. I tested with XJT and multi and diy RX same firmware as joao had. All the same error.On his is shwoing cells voltage on mine no. I tried also older ersky 9x firmware the same problem.

Do you have some idea why is not cells displayed ,I see sometimes good values in the log but not consistent.
See the log attached .
I have 9XRpro TX with last firmware.

[jhsa]

Mike, there is another problem. Sometimes when I turn the radio (9XT) OFF, the haptic starts continuously until the radio finally turns OFF. Maybe something to do with the HUB telemetry as well? Normally when this happens I am receiving the telemetry from the receiver I think. Will pay more attention to it..

Thanks

João

EDIT: It happens with the 9XR-PRO as well.
I have just noticed I don't have the latest Ersky9x.. still the one you sent me.. I thought i had updated but obviously didn't
Doin' it now..

[jhsa]

Mike, 9xt last version. I just have the radio ON on top of the table receiving telemetry, suddenly it just taked the voice messages as if PB1 was pressed, and then immediately after, as if ELE was moved to the middle and then back to UP. That one is assigned to the flaps, so it said flaps first position, and then flaps up.. I didn't touch it..

Remember me reporting a couple days ago, that the backlight turns on on its own sometimes, and that the little popup menu when you press the menu key when on the telemetry screens also comes up on its own? I even made a video of it..

João