ERSKY9X Coding

[jhsa]

also there is another problem in the protocol menu when selecting MULTI for the external module.. Please see attached picture

João

[MikeB]

OK button fixed in the version I've just posted.
I'll look into changing the "Option" text when time permits.

All the 'old' selection boxes are still on the display, just hidden. The old code is also still there in case I need to revert.
Clearly, some boxes get "unhidden" still.

Mike.

[jhsa]

Naughty boxes then

Thanks

João

[MikeB]

Fixed!

Mike.

[jhsa]

OK Button works now.. Naughty boxes still there

João

[jhsa]

That was fast thanks..

[jhsa]

Confirmed. Naughty boxes are gone.. Perfect, Thanks

João

[KAL]

The new protocols menu looks fantastic.
A lot easier to work with.

Klaus

[MikeB]

I am wondering if some of the other 'tabs' would benefit from a similar change. Just have text on the tab and go to a specific dialog to edit it. The mixer already works this way.

Mike.

[jhsa]

Yep, I totally agree It would work better, look better, and we would have a better overview of the settings in my opinion.

João

[MikeB]

(On the 9Xtreme)

The problem is, to make it work on COM1 i have to check the "Invert COM1" box. But if i reboot the radio, it won't work anymore unless I uncheck and check the box again. Then I receive telemetry again.

I have a fix for this, it will be in the next test version I post.

Mike.

[jhsa]

Thank you Mike

João

[jhsa]

Mike, I have just built an openXsensor that reads all 3 cells voltages as well as FasV, which is the third cell.
When telemetry is lost, for example turn the receiver OFF, it ersky9x keeps the last voltages.
Wouldn't that be a problem if there is a something wrong with the sensor? You thing your voltages are good when they actually aren't even there.. It happened to me yesterday while flying. Fortunately I was using A1 that reacts as it should, and I realised that the voltage wasn't there anymore.. A wire broke. Probably due to vibration..

Thanks

João

[MikeB]

That applies to most of the telemetry values.
To do anything would need a timeout on every telemetry value.

Mike.

[jhsa]

I think that at least the voltage is important, just like the A1 and A2 do..
Another problem that I am just seeing is the voltage sometimes reporting negative values while flying. Will have to look at the log file when I go home.. It already happened a couple times today..

Thanks

João

[jhsa]

here is the log file. First flight starts at !7:15:21.
Please look at the FUEL field. it's "Zero" for exactly 8 minutes. Then it start sending very high values. Atfer that I landed the plane to change a setting in the "Voice" menu that I had forgotten, and flew the rest of the battery.
Second flight starts at 18:02:08. At 18:02:42 the FUEL field starts sending negative values until the end of the flight..

During flight I had a couple times some "False" alarms about voltage..
One sais "Flight battery low zero point zero zero volts. I guess this was the lowest cell alarms because of the 2 decimals??
I have the same voice file for the FasV alarm and Lowest cell. Need to make a different one.

During the second flight I also had once a report of minus 14 volts, or minus 14 thousand volts.. Can't remember well, but it was a very strange value.

I had this problem on several occasions during both flights..

Thank you

João

[jhsa]

Ok, did a couple more tests.. To simulate a flight situation here at home, I logged while in range test mode.
First With the multiprotocol module.and the with my DJT module. This could rule out the modules as the cause of the problems, Well there are problems with both modules as you can see in the log file. with both I have heard that Flight battery low message followed by the cell voltage "Zero point Zero Zero volts. On the first two logs, one with multi and the other with the DJT, you can see that the Cell log stops after a while.
On the last log, with the DJT, you can see that the Ctot suddenly shows 16V instead of 11.2V.. Weird?

I have seen this happen before also with the multiprotocol module.
I couldn't reproduce the FUEL problem.. yet..

Log file attached

João

[jhsa]

Another one, lowest cell stopped working again.. 0.00 on the screen, and LOG. This time I Logged the 3 cells as well Should have done from the beginning..
Log attached. There is clearly a problem..

João

[MikeB]

What Rx and was this with the OXS?
It looks like corrupt telemetry. To get CTOT, I add up all the cell voltages received. If I get a fourth cell, then if this comes through as 0, then the lowest cell becomes 0. If it comes through as a voltage, then this gets added to the other 3 cells.
An error in the telemetry could also send a spurious fuel value that then stays present.

Mike.

[jhsa]

It's the DIY receiver, and oXs.
Well sometimes the FUEL (shat should be zero), starts being logged as a very high number..
I don't think I am sending a 4th cell, or it would be wrong from the beginning?
Here is my config.h file.
Thanks for looking

João

[MikeB]

Please try with a FrSky 'D' receiver to see if there is a problem with the DIY one.
An error in the telemetry (lost packet?), can easily result in seeing a 4th cell or a Fuel value when you are not sending one.

Mike.

Edit: For information, The 'hub' protocol sends data as 0x5E, ID, Data_low_byte, Data_high_byte, 0x5E, with the bytes between the 0x5E bytes "stuffed" so that 0x5E doesn't appear. Ersky9x requires to see exactly 3 bytes (after unstuffing) between the 0x5E bytes before the data is stored.

[jhsa]

Mike, thanks.
I will test with a frsky original receiver too, but will breadboard another oXs to test. It should work the same as in the plane, right? and don't need to mess with the planes installation..
Will do this a bit later..

Thank you for your help

João

[MikeB]

With the breadboard, you could also send the hub data (wired) directly to the radio, and set the "Usr Proto" to HUBRAW.

Mike.

[jhsa]

Thanks Mike. I prefer to emulate the over the air connection like with the model. And all COM ports are taken on this radio anyway

Ok, did one more quick test.. Please see the LOG attached.
See comments at right.
Module DJT
First test with DIY - Failed
Second and Third test with old D8R - not failed.. Maybe still need more testing but at the moment it does point to the DIY receiver as the cause of the problem.

I wonder if the FUEL problem is caused by the multiprotocol module as I couldn't make it fail with the DJT.. Need to test that as well.. Later will do the same tests using the multi module.. To see if it fails only with the DIY receiver or also with the frsky.. This would give as a pretty good idea of where the problem is.. Maybe the FUEL problem is a different one..

Also, please watch this video. I think I have found a different problem..
The popup menu that comes up when we press menu while on the telemetry screen sometimes comes up on its own. The backlight also turns on by itself.. After I made the video, it didn't happen again. Lucky I guess??
But I have seen this on other occasions too..
Thanks

João

https://www.youtube.com/watch?v=966p9jkA45A

[jhsa]

Ok, another test. Log attached. This is getting weird.
Check also the log file from test 4 posted above

Frsky DJT :
Voltage Problem

Frsky D8R - No fail ( 3 tests trying to make it fail)

Frsky DIY RX - Fail

FUEL Problem - No fail with both receivers. Always get a value of zero.

MultiProtocol Module with STM32 Processor:
Voltage Problem

Both Receivers - Fail

FUEL Problem - Fail with both receivers. After some time start receiving big numbers instead of the correct zero.
I believe we can say that the FUEL problem is on the Multi module code
It looks that we have at least two different issues here.

So, where is the voltage problem then?

Thanks
João

[MikeB]

When you get Ctot going wrong, have a look at the telemetry display that has the GPS on it. The first 6 cells are displayed at the bottom. Do you have any non-zero values for cells 4, 5 or 6?

You could try using the RAW logging on the failing setup, although it may take me some time to look through such a log file to try to locate any problem.

Mike.

Edit: If you run the Tx without any module, but connect the OXS hub output directly to the bottom pin of the module connector (with a ground as well of course), then you can check for any problems but using Usr Proto as hubraw on COM1.

[jhsa]

Will do now.. and also raw logging..
will report in a while..

João

EDIT: Can't see the other screens when doing a range test with multi
Here is what i will do.. Will log all cells before the raw logging..

João

[jhsa]

Ok. lots of weird information here.. Multi module with DIY RX.
Please check the video.

https://www.youtube.com/watch?v=oq2_TBfuqi8

Inside the zip file there are 2 logs. a normal log with lots of weird stuff
And the Raw logging. I don't know if it came out ok because I see only rubbish when I try to open the file in Libreoffice. It was more difficult to make it happen while raw logging. The problem can be seen on the 2 last raw logs, but I can't see what is logged.

It looks like that after the problem started, pressing EXIT introduces a value of 4.5 on thew Cvlt field and it sounds the alarm for some reason.

João

[jhsa]

I don't know if it is relevant but I think I still have the Ersky9x version from 17-01-2017.. I think the one you have sent me when you changed the protocol menu.. That is the one just before the test version from yesterday or day before??

João

[MikeB]

Difficult to check the raw data, but (almost by accident) I spotted some errors. This is in the user data (hub protocol) embedded in the FrSky 2-way protocol. The 2-way formatting is correct, but the user data goes wrong. I found this sequence in the user data:
5E 06 17 24 (cell 2)
5E 06 27 18 (cell 3)
5E 39 6D (error only 2 bytes between 5E bytes. 39 is the index for the OXS voltage [non-standard index])
5E 06 07 13 (cell 1)
5E 06 17 24 (cell 2)
5E 06 6D 00 (cell 7!!!)
5E 03 F0 FE (RPM)

So the user data is definitely corrupt.

Mike.

Edit: I have something else part working, individual timers on each telemetry value. I then also put a tick mark at the right of the logging menu to show those items currently being received. When displayed, telemetry items might flash when not being received.