ERSKY9X Coding

[MikeB]

The way I've handled the "CHECK_FOR_BOOTLOADER" is the module main code only looks for the bootloader request while it hasn't yet received a valid MULTI packet. This is to prevent the module from dropping out to the bootloader once it has started working normally, possibly causing a loss of control.
If you use the General/Run Maintenance, then normal operation of the module will have started, so it is normal you can't flash without the bind button that way.

Mike.

[kiwihornplayer]

Hi Mike

Noticed the problem with using 3-pos dual rate switches which has been mentioned elsewhere. Third position always resets to first position values. It is possible to create a combination of any two of Hi - Mid - Low depending upon which switch is configured first but not all three.

Please download the er9x manual from the link below and check / learn how to program Dual and Triple rates.
HI, Mid and LOW are just names, all of them can assume any value. Low can be bigger than HI or MID, for example.

viewtopic.php?f=5&t=6473

(Another face palm) Late at night reading printed manual in workshop - missed the para relating to 3 pos sw at top of following page. Simple when following very clear instructions.

2. Also noticed one of the non-customisable screens appears like a telemetry screen showing Fuel bar at top, RSSI and SWR bar values at bottom along with numeric values. There is no access to this screen so is an additional to the two custom telemetry screens. Might be a hangover from another radio version.

Nope, that is a screen that is present in all versions of ersky9x [/quote]

Strange one that. Never seen it before and after leaving TX switched off overnight that particular screen with fuel bar and other stuff has disappeared - suspect it was a hangover after replacing openTx FW.

3. Is there any way to configure Timer 1 or 2 to provide a continuous accumulated time (ie engine hours) that stays with a particular model and does not reset with TX-off or long Menu button press? Similar to the way the non-editable 3rd timer shows total TX running time.

Go to "Model Setup / Timers" menu, scroll down to the last page, and you will find the model's total time..[/quote]

Thanks for that. I was aware of that screen. Raises another question - is it possible to reset that timer somehow to eliminate the workshop model setup time? I thought I could do a workaround by copying the completed setup to a new model but that method copies the elapsed time as well. There is probably something I have completely missed.

Cheers

[jhsa]

I think a reset of the timer would miss the point of having it completely, but maybe a "Stop Total Timer" option that we could turn on when working on the model, or experimenting with the programming..

About the telemetry screen, If no valid telemetry is being received, the FUEL bar, along with the other information will not be displayed.. The screen is still there..

João

[jhsa]

About the total timer, thinking further, I can see at least one situation where the total timer would have to be reset..
when using a model as a template to another model. In this case the Total timer needs to be reset, so, yes in my opinion there should be 2 extra options: "Reset Total Timer", and "Stop Total Timer".

João

[ys11]

Mike
It's make sense.
That is safeway.
I'm now very happy, and now going to put module inside my TX.
I can handle every protocol, because I have 2 FW to interchangeable at once.
Now around here is very good weather to fly, but in 2 weeks, we will have rainy season, so I have so many time to modify and make maintenance RC gears.
ersky is awesome lol
Thank you, thank you so much.
ys11

[MikeB]

Regarding the "Total Time" screen, a LONG MENU press does set this back to zero when on that screen.

Mike.

[jhsa]

Didn't think about it, thanks..
But a option to reset it, as the other timers also have, would prevent more questions like the one above, as it would make it obvious
And it would match the other timers

João

[kiwihornplayer]

About the total timer, thinking further, I can see at least one situation where the total timer would have to be reset..
when using a model as a template to another model. In this case the Total timer needs to be reset, so, yes in my opinion there should be 2 extra options: "Reset Total Timer", and "Stop Total Timer".

João

Thanks João

I Just found by accident that it can be reset with a Press of the Page button on left while in the 3rd timer screen. There could be a hidden stop/start button combination that hasn't been discovered yet - I'll report back if I find it.
Now all that is needed is "stop/start total timer" that can be programmed to a switch or THs like the other timers.

Cheers

[jhsa]

Mike, I just had a weird problem on my latest Ar9x radio..
I connected to the sim, just to find a good model for my son, and this model by coincidence had a throttle active / inactive, datalogging active / inactive Programmed on the THR switch.

Every time I would turn the switch ON, it would start playing, but Then I would lose all audio. rebooted several times, the same. debug always shown 1 voice underrun.

The I loaded another model with the same voice files programmed on the same switch, and it worked fine.. returned to the sim model, and now it doesn't fail.. Weird. any ideas of what might have happened??
Been trying hard, and can't make it fail again..

Thanks

João

[MikeB]

I've just posted "d4". This has some improvements on the LUA operation, and frees up some RAM on the SKY/PRO/AR9X boards.
For now, you don't need the 'l' version if you have the 'SAM4S8 processor, the heap now auto adjusts to the available RAM space.
There is an extra COM2 function (untested) "TEL+BTdir". This is intended to provide two-way data transfer between bluetooth and COM2, while still processing the the telemetry data received on COM2 (for mavlink mainly).

On a Taranis QX7, I have the S6R script (slightly modified) running, allowing me to read/change values on the S6R/S8R. Currently, I don't have the images displaying, but all else is working.

Mike.

[jhsa]

Thanks Mike

João

[tsenecal]

not sure if i didn't look hard enough, or if the discussion on this just trailed off into the ether... does the maintenance mode on ersky9x support flashing the 4-in-1 multiprotocol stm32 module? if it does, what do i need to do to get that to work?

[jhsa]

Not yet, but it would be a nice feature
I have 2 radios with STM32 modules installed internally

João

[MikeB]

With scripts now working (whether LUA if re-enabled) or the new "slim" scripts, it may well be the case that a number of possible enhancements the ersky9x are possible by using a script. I may need to add something specific to get a value back from a script, but the following is one example.
One request is to extend logical switches to have "Range" as in L1 V1 Range C1 C2.

Now a script can get the V1 value by using the script "getvalue()" function. It is then very easy for the script to compare the result with a couple of constant values. At the moment the problem would be returning the result to a logical switch if required, depending on what the result is needed to do. The script may be able to do the required function itself (e.g. speak a value).
Currently a way of returning the result is to write to a telemetry value, e.g. "Cus1", storing 0 or 1 there, then set up a logical switch as:
L1 v>val Cus1 0
to get a logical switch that is set if the value is within the required range.

A script may also be able to monitor telemetry value for max and min levels.
Again, I may need to add something like access to switches (physical and logical) to find their current state so a switch may be used to reset a max or min value.

Mike.

[ozphoenix]

Hi Mike,
I am having a tough time with Ersky9x and QX7 and eepeSky working together -- I am not sure which forum/thread to put this one so, unless you say otherwise, it goes here. Apologies for the length of the description.

As you know from other posts, I have a 9XRPro with 221 REVB-X (13.05.2017) which has 20+ models in it and works really well. I've secured a QX7 as a 'back-up' radio and you have now helped me get a relatively good version 221 X9D (10.07.2017) which you provided yesterday (that fixed a couple of issues). I am using the latest 'test version' of eepeSky (4th July 2017, 15:23) on Windows 10.

All I then wanted to do was copy the first 20 models from the 9XPro to the QX7, which initially had only one basic model (Model1). At this point, I encountered a number of problems, tried all workarounds/ideas/suggestions I could find on threads, etc - now, I'm out of ideas, I think. Perhaps you can help - basically, I can manually enter and save new models directly into the QX7 without problem using any Model number/location. After enabling, I can make backup copies of each radio's EEPROM and see those backups available for restore and can perform a restore without error, so I know that each EEPROM is writing properly. If I connect both units to my PC through USB, I can see all EEPROM files and folders and all FIRMWARE files and folders on the units through both Windows 10 and on the relative/respective menu drop-downs in eepeSky. I can read and write files across the USB directly from/to the SD in the 9XRPro and the QX7 without Windows 10 or eepeSky reporting any error (but, see below when attempted Write Memory to TX error on the QX7). I can connect one radio through USB and put the other radio's SD card in a PC slot (and vice-versa) and everything above appears to also work ok.

BUT, I have two seemingly-related error scenarios:

Error Scenario a. any updated EEPROM bin file created in eepeSky (from dragging 20 models -- either singularly or as a block -- between opened EEPROM files, that is, from the 9XRPro EEPROM bin file to the QX7 EEPROM bin file) -- and then saved and put onto the SD card of the Qx7 (either directly within the PC's SD slot or across a USB cable to the EEPROM folder on the QX7) from within eepeSky is successfully saved without error but will not Restore properly from within the QX7 EEPROM menu options - I get messages 'EEPROM Formatting. BAD EEPROM DATA and (EEPROM RESTORED) when I try to use the QX7's Restore EEPROM option. I get back to one Model.

Error Scenario b. any EEPROM image read directly from QX7 Tx to Memory (in eepeSky) completes without error and shows any models which also display on the QX7, but any attempt to then do a (modified or not) EEPROM image write directly back to QX7 Tx (Write Memory to TX) across a USB cable gets an error after (always) 6% of the Destination WRITE Operation, says Operation failed (with the usual two failure message popups) - then, if I close the EEPROM model window (using the 'X' box) in eepeSky, I am asked to save or discard, I can select 'save' and it seems to save and close without error. I restart the QX7 and SOME of the 20 models are in the QX7 but not ALL -- Models 1 to 13 are present, not Model 14, Model 15 is there, but not 16 through 20 (though, on the latest attempt, Models 1 to 13 were present, not 14 or 15, but then 16 was present, but not Models 17 to 20) -- those two variants of Model numbers are consistent, each time I try it -- gaps around the higher order model number locations -- always, below slot 13 models are present. So, eepeSky seems to selectively lose models when trying to (erroneously) write directly to Tx memory. If I read the QX7 EEPROM directly back to the eepeSky program (Read Tx to Memory), Models 14 and 16 through 20 (or the latest small variant) are (indeed) missing. But, I can copy (say) Model 2 to Model 14 using the QX7 Model Select menu and it seems to save properly, as noted at the top of this diatribe.

I have tried numerous and various combinations of new USB cables and different USB sockets, etc - no difference.

Just FYI - within the models which DO transfer, there ARE some model settings which are not translated correctly between the 9XRPro and the QX7 (such as what are the various switch default settings, and what Haptic settings are used, etc) but maybe those are because of difference in the switch mappings, etc within the individual radios???

I might be able to provide more details if you ask me specific questions, but I think I've narrowed the error scenarios down to these comments (there were many consuming steps and repeats and repeats to get to this point). So far, I have failed to get all 20 models transferred across using any form of eepeSky tool.

I have attached a downloads.rar file enclosing my 9XRPro bin file (with all 20 models) and my last QX7 bin file made from a Write Memory from Tx (with missing models -- you will note that the QX7 memory file is very small compared to eth 9XRPro file).

Your consideration would be greatly appreciated.

Regards,
ozphoenix

Downloads.rar

(7.62 KiB) Downloaded 199 times

[jhsa]

You're not trying to write eeprom to the tx while having both radios connected to the computer at the same time, are you??

The 9XR-PRO and the X7 have completely different switches. Not sure a direct conversion would even be possible..

João

[rsilk49]

A puzzle for the scalar scholars:
Can this be achieved using scalars and voice alerts? Or will it require the enhanced logic of a script?

"Issue alert when Mah reaches 1000, 2000, 3000, etc."

[jhsa]

simple logic switches should work
No need for scripts for such a simple thing..
Actually, the voice Alerts alone should be able to handle that
João

[rsilk49]

I have already set up 3 separate voice alerts for mah = 1000, 2000, 3000,
But I am issuing a challenge for the scalar gurus -- you know who you are! Can it be done with only 1 alert?

[MikeB]

I am having a tough time with Ersky9x and QX7 and eepeSky working together -- I am not sure which forum/thread to put this one so, unless you say otherwise, it goes here. Apologies for the length of the description.

I have a fix for the 6% problem, I'll get back regarding the other things later.

Because of the different switches on the radios, 9XR-PRO models will need the switches converted "by hand" in many cases.

Mike.

[ozphoenix]

Hi João,

No, I am not - I tried that then thought it might be contributing to the problem, so made all further attempts with only one device attached at a time (though, it should be able to work, provided you highlight the correct eepeSkye window before writes or reads, I think). So, that was no longer a contributing factor.

As for the switches, as I noted, I figured that the differences would prevent a direct conversion. But, that is not the main problem I am having, just a small hindrance to easier conversions

I figure that Mike will see what is needed, once he can look at my EEPROM files and the coding behind the QX7 side

Thanks for your input

Regards,
ozphoenix (otherwise known as Peter Moffitt or Peter M.)

You're not trying to write eeprom to the tx while having both radios connected to the computer at the same time, are you??

The 9XR-PRO and the X7 have completely different switches. Not sure a direct conversion would even be possible..

João

[ozphoenix]

Ok, great - thanks, Mike.

Regards,
ozphoenix

I am having a tough time with Ersky9x and QX7 and eepeSky working together -- I am not sure which forum/thread to put this one so, unless you say otherwise, it goes here. Apologies for the length of the description.

I have a fix for the 6% problem, I'll get back regarding the other things later.

Because of the different switches on the radios, 9XR-PRO models will need the switches converted "by hand" in many cases.

Mike.

[MikeB]

Only have one radio connected at a time.
Note that the EEPROM on the 9XR-PRO and that on the QX7 are completely different (512K for the PRO and only 32K on the QX7). Because the QX7 is only 32K, the data is compressed before storing so it all fits. You can't backup the EEPROM from a 'PRO and write it to the QX7.

What should work is to read/open the EEPROM from the 'PRO, then read the EEPROM from the QX7, drag and drop models from te 'PRO window in the QX7 window, then write the QX7 EEPROM back to the radio. At present, it stops at 6% because it thinks it should be writing 512K.

Mike.

[ozphoenix]

Hi Mike,
As noted, I initially tried two radios connected, saw that I was having some sort/number of problems, then went to one radio (though, I still do think that two radios connected should be an allowed 'norm' of operation - but, as the developer, you have the final say, obviously)

I also understood (early in the process) that one could not/should not attempt to back up from the 9XRPro and restore directly to the QX7, which is why I went the eepeSky route - and, that's when my problems compounded But, thanks for the confirmation.

I look forward to the solutions to both error scenarios, even if they both turn out to be my own ineptitude -- but all in your good time - much appreciated.

Regards,
ozphoenix

Only have one radio connected at a time.
Note that the EEPROM on the 9XR-PRO and that on the QX7 are completely different (512K for the PRO and only 32K on the QX7). Because the QX7 is only 32K, the data is compressed before storing so it all fits. You can't backup the EEPROM from a 'PRO and write it to the QX7.

What should work is to read/open the EEPROM from the 'PRO, then read the EEPROM from the QX7, drag and drop models from the 'PRO window in the QX7 window, then write the QX7 EEPROM back to the radio. At present, it stops at 6% because it thinks it should be writing 512K.

Mike.

[MikeB]

Only one radio connected at a time is required, I think, as you could connect to of the same type of radio and it would not easily be possible to know which was which.

I've posted a new test version of eepskye that should write the QX7 EEPROM correctly. I copied (drag and drop) a number of models to a QX7 and wrote the EEPROM back and all appears to have worked correctly.

Mike.

[ozphoenix]

Mike,

I found that new test version a few moments ago, before your post above - it shows a new CRC for the .exe in the archive, but the unpacked eepesky.exe still shows the April, 2017 date in the About screen and still gets the 'fail' at 6% -- are you sure the .exe in the zip is updated to the new version?

Regards, ozphoenix

[bob195558]

Hi ozphoenix,
Did you go here: (viewtopic.php?f=7&t=4676#p65894) ?

Bob B.

[MikeB]

Looks OK to me, yes the about data is still April. You did download the .zip labelled "12-Jul-2017 10:50", extracted the .exe and put it in your eepe directory.
The file eepskye.exe should be dated 11/07.2017 13:52.
It wrote to the QX7 correctly when I clicked on the "Write Memory to Tx" button on the toolbar.

Mike.

[ozphoenix]

BobB - yes, I did.

Mike - yes, I did - attached is a screenshot of my eepe directory - I am using the most recent (your update) .exe file.

Some more information:
1. On the second, third and fourth tries, the 6% error did not occur, so put the first failure down to fumble fingers ... or something. The Write Memory to Tx now appears to complete without error.
2. The file saved using the updated eepe -- whether to the local disk, to the EEPROM on the QX7 (across USB) or by a Write Memory to TX -- when re-read into eepe, has the models missing from the saved file (same models as before - no need to attach a new screenshot).
3. If I do the EEPROM Restore using the (missing models) file when stored on the SD card of the QX7 across the USB, I now get a successful completion of the EEPROM Restore process without error message (though, of course, the models are still missing).

So, it now seems that the remaining problem is to get eepe to create a file for QX7 without missing models.

Hope this helps.

Regards,
ozphoenix

[jhsa]

Just to make sure.... You are using eepskye, not eepe, right?
I'm asking because you mentioned eepe several times on your previous post..

João