ERSKY9X Coding

erskyTx runs on many radios and upgrade boards
ersky9x was a port of er9x for use on the sky9x board.
ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 08, 2019 8:39 am

Today, I ran the following test inside my workshop on a single S6R (from yesterday's test group) with 9XRPRo, ErSky9xr222c9 and external XJT module with firmware XJT_141016.frk:

Connect 2x regular servos, 1x u/c servo to ESC and Battery with switch, power on Radio, then (a) power on Rx with bind button pressed and bind Rx to Tx with Rx Number 0 through 10 with no Double Rate selected, stop bind operation after successful bind, turn off power to Rx, turn on power to Rx, confirm good bind, confirm that NO Double Rate is enabled, step back 3-4 metres, exercise servos for up to 20 seconds (if possible - it was), observe operation and bind LED, stop movement, make no other changes but enable Double Rate, exercise servos for up to 15-20 seconds (if possible -- it was not, except for Rx Number 0), stop exercise, power off Rx. Repeat with next Rx Number from (a), above.

Here are the results:
Rx Num   No Double Rate   Double Rate Enabled
0                 OK              OK
1                 OK              Fail*
2                 OK              Fail*
3                 OK              Fail*
4                 OK              Fail*
5                 OK              Fail*
6                 OK              Fail*
7                 OK              Fail*
8                 OK              Fail*
9                 OK              Fail*
10                OK              Fail*
*Fail means loss of bind and report of 'no Telemetry' within 20 seconds or less.

Go back and repeat the tests for Rx Number 0, 5, 10 -- the results were the same OK/OK, OK/Fail, OK/Fail.
Run the same tests on X4R on Rx Numbers 0, 5,10 -- the results were the same OK/OK, OK/Fail, OK/Fail.
Run the same tests on S8R on Rx Numbers 0, 5,10 -- the results were the same OK/OK, OK/Fail, OK/Fail.

The S8R has whatever firmware was in it when the devices were delivered from Horus-rc about 8 weeks ago.

I realised that the S6R had my favourite (but now unofficial) firmware S6R_FCC_170217.frk (the Beta version, the first non-vibration version released in 2017) so I re-flashed it with S6RFCC20180328_1.frk and re-ran the tests for Rx Number 0, 5, 10 -- the results were the same OK/OK, OK/Fail, OK/Fail.

Out of curiosity, I re-did part of the test by binding with Double Rate already enabled -- for Rx Number 0, 5, 10 -- it made no difference, the results were the same OK/OK, OK/Fail, OK/Fail.

As Tom Hanks, in the movie Apollo 13, famously but incorrectly quoted Jim Lovell: 'Houston, we've got a problem'.

Next steps, Mike?

regards,
ozphoenix

MikeB wrote:
Mon Jan 07, 2019 4:48 pm

If you could, please try RxNums from 0-10 using the XJT and a single Rx.

Mike



User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Tue Jan 08, 2019 10:05 am

Please try RxNums 0-10 using the QX7.
For information, "Doublerate" is disabled while binding.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 08, 2019 10:25 am

Ok, but that will have to be tomorrow, our time, about 11:30am (GMT+10) - it's already past the witching hour here for today - been out to my shed in the dark and rain twice already tonight and it's been a busy day already :D Apologies for the minor delay.

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Tue Jan 08, 2019 10:44 am

I'll see if I can add something to tell me about the timing of the doublerate. When I first added it, it didn't work as I had the second data frame overlapping the first.
To avoid any other setting causing a problem, if you haven't already done this, please create a new model, so all model settings are the default, and set the protocol to XJT as required.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 08, 2019 10:52 am

MikeB wrote:
Tue Jan 08, 2019 10:44 am
I'll see if I can add something to tell me about the timing of the doublerate. When I first added it, it didn't work as I had the second data frame overlapping the first.
Mike
Ok- you mean a diagnostic version or such, for me to use tomorrow? Or, something you're going to use yourself?
MikeB wrote:
Tue Jan 08, 2019 10:44 am
To avoid any other setting causing a problem, if you haven't already done this, please create a new model, so all model settings are the default, and set the protocol to XJT as required.

Mike
Ok, understood, but I think that means I also need to go back to the 9XRPRo and do that same thing, as well - correct?

regards,
ozphoenix
Last edited by ozphoenix on Tue Jan 08, 2019 11:49 am, edited 2 times in total.


ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 08, 2019 11:14 am

Time to turn in to a pumpkin - will catch up with the conversation tomorrow morning, our time.
ozphoenix

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Wed Jan 09, 2019 5:06 am

Hi Mike,
Today, I ran the following test inside my workshop on a single S6R (from yesterday's test group) with both the QX7 and the 9XRPRo, ErSky9xr222c9 and external XJT module with firmware XJT_141016.frk with S6R Rx using S6RFCC20180328_1.frk firmware - NOTE: I increased the 'exercising' time up to 60 seconds or error, whichever occurred first.

Create a new model in both radios and select Simple 4-Ch model template, set Protocol to XJT 16 channel on Internal XJT for QX7 (disabled External Module - Orange DSMx) and External XJT for 9XRPro. Made no other changes to the model.
Connect 2x regular servos, 1x u/c servo to ESC and Battery with switch, power on Radio, then (a) power on Rx with bind button pressed and bind Rx to Tx with Rx Number 0 through 10 with no Double Rate selected, stop bind operation after successful bind, turn off power to Rx, turn on power to Rx, confirm good bind, confirm that NO Double Rate is enabled, step back 3-4 metres, exercise servos for up to 60 seconds (if possible), observe operation and bind LED, stop movement, make no other changes but enable Double Rate, exercise servos for up to 60 seconds (if possible), stop exercise, power off Rx. Repeat with next Rx Number from (a), above.

I ran the tests on the QX7 new model for the following Rx Numbers:
Rx Num   No Double Rate   Double Rate Enabled
0                 OK              OK
1                 OK              OK
2                 OK              OK
3                 OK              OK
4                 OK              OK
5                 OK              OK
6                 OK              OK
7                 OK              OK
8                 OK              OK
9                 OK              OK
10                OK              OK

I then ran the tests on the 9XRPRo new model for the following Rx Numbers:
Rx Num   No Double Rate   Double Rate Enabled
0                 OK              OK
1                 OK              Fail*
2                 OK              Fail*
3                 OK              Fail*
4                 OK              Fail*
5                 OK              Fail*
6                 OK              Fail*
7                 OK              Fail*
8                 OK              Fail*
9                 OK              Fail*
10                OK              Fail*
*Fail means loss of bind and report of 'no Telemetry' within 60 seconds or less.

I then placed the XJT module into the external bay of the QX7, disabled the Internal XJT module and enabled the external XJT module with XJT 16 channels. No other changes.

I ran the tests on the QX7 using the following Rx Numbers:
Rx Num   No Double Rate   Double Rate Enabled
0                 OK              OK
5                 OK              OK
10                OK              OK
13                OK              OK
37                OK              OK

I then returned the XJT module to the external module bay of the 9XRPro and ran the tests on the following Rx Numbers:
Rx Num   No Double Rate   Double Rate Enabled
0                 OK              OK
5                 OK              Fail*
10                OK              Fail*
*Fail means loss of bind and report of 'no Telemetry' within 60 seconds or less.

My XJT module was purchased from Horus-rc in the middle of 2018 (my first one failed internally and is unusable now) - there are no distinguishing date marks on the outside of the current XJT module. I opened it and there are no obvious 'stamped' production date numbers, but the board silkscreen had two numbers etched into it during fabrication: 170708 and D16HV3.1.161212

Hopefully, all of this gives you some clarity - my fingers are getting blisters and RSI from all of this 'stick' exercising :lol:

regards,
ozphoenix

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Wed Jan 09, 2019 9:35 am

Useful results, I'm looking at adding something to check the doublerate timing, I just need enough time to do that along with everything I have to do!
As I mentioned, I did have a bug where the second data frame was created before the first was completely sent, causing bad data. At that point I decided that doublerate (on the 'PRO) didn't work, but I then fixed the bug and it was OK.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Wed Jan 09, 2019 10:04 am

Ok, Mike - thanks for the feedback - with a little luck, you can get the time to resolve. As for now, I will not use Double Rate at all, especially on the 9XRPro with XJT, where I extensively use Rx Number(s)! One flyaway is enough :lol:

That said, if you do not get time to resolve it for a while, it is not the most urgent thing you are dealing with, I'm sure, and it's not stopping me (or anyone else, I guess) from flying - just don't enable Double Rate if you are using a Pro with XJT and want to use Rx Number(s) other than '0'! At least it appears to be THAT specific ;)

Further, obviously I will not be opening the Pro to do any mods until we're done with our testing. I'll put away my test set-up so I can get some bench space back - until I move in to my new, bigger, shed (10mx8m, mostly for workshop!) I'm a little hampered for space. But, it doesn't take long to pull it back together, if needed.

Let me know if there is anything more I can do to help.

In the meantime, I'm also looking forward to feedback from FrSky on the MLVSS issue - my big B17 will also still be flyable, but I'll be adding the FCS40 in to get the 'mix' of devices right, for now.

regards,
ozphoenix
MikeB wrote:
Wed Jan 09, 2019 9:35 am
Useful results, I'm looking at adding something to check the doublerate timing, I just need enough time to do that along with everything I have to do!
As I mentioned, I did have a bug where the second data frame was created before the first was completely sent, causing bad data. At that point I decided that doublerate (on the 'PRO) didn't work, but I then fixed the bug and it was OK.

Mike

User avatar
jhsa
Posts: 18814
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: ERSKY9X Coding

Post by jhsa » Wed Jan 09, 2019 10:45 am

Concerning flyaways, always set failsafe. That will stop the motor or engine if signal is lost. The plane will crash anyway, but it won't leave the field you're flying and will not cause damage to others..

João

Sent from my BLN-L21 using Tapatalk

My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Wed Jan 09, 2019 11:28 am

I did, I do and it was in failsafe with motor stopped, but a sidewind overcame the slight rudder I had mixed in. It glided ever so softly and straight and level - straight into a big tree 350m away, across the other side of a creek from our field's boundary. Fortunately, we are able to walk across a railway bridge over the creek - don't look down! - and we were able to use the RSSI to find it (even though the signal was coming and going) as it had fallen out of the tree.

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Thu Jan 10, 2019 10:49 pm

I've posted a special test version for the 'PRO on the test version thread (called ersky9xr_romPxxTime). This displays the times between the generation of each PXX frame on the DEBUG menu (UP LONG, LEFT a few times). The data is the 2 values on the second line of the display. On my Tx, I get 2328 for both values without doublerate and 1194 with double rate. These numbers correspond to 9mS and 4.5mS.

When the weather gets better, I want to try failsafe with a SxR where it is put into auto-level mode, with some rudder mixed in, and throttle shut. The idea is to have a significant amount of rudder to guarantee a turn, but the auto-level should keep the wings level!
I'll test it by setting mixes controlled by a switch, rather than using real failsafe (i.e. turning the Tx OFF)!

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Thu Jan 10, 2019 11:48 pm

Thanks, Mike - will download and get back to you after I've tried it, but I might not give feedback until later tomorrow (Saturday) our time, as I'm just about to leave this morning for an overnight stay away (and, no planes allowed).
Thanks for persisting on this issue -- and, lots of luck in your testing - I've been having fun of my own, doing additional testing ;)
regards,
ozphoenix

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Fri Jan 11, 2019 12:26 am

Ok, couldn't resist - just grabbed my radio and did a test.
I get 2328 2328 without Double Rate selected, I get 1194 1194 with Double Rate Selected.
Gotta run.
regards,
ozphoenix

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Fri Jan 11, 2019 12:29 am

Mike - sent you PM. regards, ozphoenix

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Fri Jan 11, 2019 7:33 am

Mike,
Are you expecting that these values might change when I get the failure? To check that, I need some time at home tomorrow.

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Fri Jan 11, 2019 4:49 pm

I doubt they will change.
Given the module works fine (including at double rate) in the QX7, I would suspect a problem with the connections between the 'PRO and the module. The module bay in the 'PRO is a bit oversize, so the module is a bit loose. The pins in the module bay are also a bit on the short size. These two things combined could lead to a poor/intermittent connection to the module.
A loose module could bend the pins, possibly leading to the soldered connection between the pins and the RF board in the 'PRO becoming cracked/broken. The short pins with the module able to move a bit could also lead to a poor/intermittent connection, at the module.
I suggest checking the soldering between the pins and the RF board, possibly allowing the pins to protrude further towards the module if possible. I would also suggest lining the module bay to make the module a firm fit, possibly one or mor layers of electrical insulation tape.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Fri Jan 11, 2019 8:16 pm

Thanks - my module bay in the 9XRPro is already lined on two sides with pieces of foam double-sided tape (but with the outer side still covered with the protective covering) to give the module a snugger fit - I made it that way as soon as I got it several years ago.

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Sat Jan 12, 2019 11:45 am

Mike,
Pardon my ignorance in the following question(s), but I usually only pay attention to things related to ErSky9x on 9XRPro and QX7 (I have each).
In the event that I decide to upgrade (in the unlikely even that I cannot get my 9XRPro back to being reliable) to either the Horus x10S or the Horus X12S, is there a compatible version of ErSky9x for either or both of these radios? If yes, are there presently any known deficiencies or 'yet-to-be-implemented' features compared to the 9XRPro/QX7 version(s)? Or, if there is not yet a compatible version, do you know when there might be?
Trying to do some prior research 'just in case'. I see reference to the Horus on the released versions site, but that shows a '.bin' for x12d - not sure if that is compatible or not.
regards,
ozphoenix

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Sat Jan 12, 2019 10:22 pm

I have a fully functioning version of ersky9x for the X12. The X12 I have is a prototype that has some hardware differences to the production version, but the firmware has a means to detect the type of hardware and adjust to suit. I had someone with a production version testing everything. I called the firmware X12d as that was what the X12 was called early on, but it is the firmware for the X12S.
Currently, as I don't have a X10 or X10S, I haven't ported ersky9x to the X10. For most transmitters, I get radios from FrSky, but I wasn't included in the X10 development!

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
jhsa
Posts: 18814
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: ERSKY9X Coding

Post by jhsa » Sun Jan 13, 2019 1:07 am

MikeB wrote:
Sat Jan 12, 2019 10:22 pm
For most transmitters, I get radios from FrSky, but I wasn't included in the X10 development!

Mike
Not nice of them.. :( :( :(

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Sun Jan 13, 2019 1:14 am

I prefer the X10S to the X12S because it's newer, is lighter and has the Li-ion battery (versus NiMh of X12S). But, I prefer ErSky9x over OpenTx or FrOS.
If colour and marketing 'freebies' added in to make a sale were irrelevant to you - that is, a radio to radio choice -- if you could have a new X10S or a new X12S and they were exactly the same price, landed at your house, which would you choose TODAY (not later, when ErSky9x will surely be ported)?

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Sun Jan 13, 2019 11:07 am

Any feedback from FrSky about the MLVSS issue, Mike?

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Sun Jan 13, 2019 7:45 pm

As I find the X12S rather large to comfortably use, I would choose the X10(S), and probably port ersky9x to it within a week or so.
I believe the X10 only needs the switch and trim inputs mapped to the correct pins, although there might be a few other changes.

No feedback from FrSky on the MLVSS yet.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
Kilrah
Posts: 9989
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: ERSKY9X Coding

Post by Kilrah » Sun Jan 13, 2019 9:47 pm

I personally MUCH prefer the X12S, feels more comfortable and convenient (with the 3rd party support bars), screen on top is just "right". I find the X10S really awkward to hold, poor screen placement, bad balancing, and aesthetically pretty ugly while the X12S is just the opposite right in the sweet spot for me.

The X10S has the screen rotated 180° compared to the X12S and the hardware doesn't support an easy flip so depending on how things are coded a bunch of UI stuff needs reworked.

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Sun Jan 13, 2019 10:39 pm

Interesting to know about the screen rotation, thanks.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Wed Jan 16, 2019 8:17 am

Hi Mike,
Any advance on the test results for the double rate issue on 9XRPro with external XJT?
Regards,
Ozphoenix

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 22, 2019 7:34 am

Mike,
Could you produce a test version for QX7 which includes the Cls1 and Cls2 totalling for the 1st and 2nd MLVSS devices, please? I am moving all of my planes to my QX7 as my 9XRPro, even with new, longer, pins in the module bay, still is not reliable. I am not sure where to go next with it - either another (3rd) XJT module or replace it with a new X10S - will decide shortly. In the meantime, I need to have those 'summation' Telemetry values (which work well in the 9XRPro version) in the QX7, which will work if I use an extra SPort device, available in the QX7.
Thanks, in advance,
ozphoenix
EDIT: Just FYI -- r222d2 on the QX7 also still causes a crash when you scroll past the current Scaler (as the 9XRPro did)in the Scaler Edit Screen on the ex Source field.

User avatar
MikeB
9x Developer
Posts: 16483
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: ERSKY9X Coding

Post by MikeB » Tue Jan 22, 2019 6:47 pm

I've now posted a "d3" test version for all radios:
Add custom names for custom telemetry values
Fix Vspd logging
Fix Vspd scaling from DSM telemetry
Voice alerts may use system voice files
Allow FM0-FM6 as switches for DR/EXPO
Limit FrSky RxNum to 63, max actually allowed.
Encoder double-click switches between CAPS when text editing.
Add Cls1 and Cls2 for total cells of two FLVSS/MLVSS
Fix Scaler ex_source editing bug
Scaler and Custom telemetry names used
Raw logging has a Hex option
Fix Crossfire telemetry bug
Handle FrSky vario from XxR when using 'D' protocol
Horus X12 add bootloader
X9E Fix hardware editing bug

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ozphoenix
Posts: 404
Joined: Fri Oct 28, 2016 11:51 am
Country: Australia

Re: ERSKY9X Coding

Post by ozphoenix » Tue Jan 22, 2019 7:58 pm

Thanks very much, Mike - much appreciated - will download this morning and update both radios - I'll still trying to understand why my Pro has turned rogue, but will keep using my QX7 as my main radio until I decide what to do with the Pro.


Post Reply

Return to “erskyTx (was ersky9x)”