When i saw the new FlySky FS-i6S RC transmitter for around $50 i immediately thought it would make a nice “always with me” tx for my TinyWhoop. Unfortunately i only run FrSky gear, this one is FlySky… So what now? I am going to swap the hf module to a CC2500 transceiver module and write my own firmware for the FS-i6s! OpenGround will become the counter-part of my opensource firmware OpenSky that runs on FrSky receivers. I am not affiliated with Flysky or FrSky in any way. This is just my personal hobby project.
This is an ongoing project. For now i will write single blog posts and collect them on this page. Once finished this will become the main project page. My code will be hosted on github: https://github.com/fishpepper/OpenGround
Current blog posts:
- OpenGround – Part 13 – switching from the st peripheral lib to libopencm3 (3/3/2017)
- OpenGround – Part 12 – Turnigy Evolution – I/O mapping (1/23/2017)
- OpenGround – Part 11 – CC2500 adapter board (10/8/2016)
- OpenGround – Part 10 – Status update & some UI impressions (video) (10/3/2016)
- OpenGround – Part 9 – CC2500 & some UI work (9/27/2016)
- OpenGround – Part 8 – Buttons, Lazyness, GPIOS, and memory locations on STM32F0 (9/23/2016)
- OpenGround – Part 7 – Using the FT6236 touch controller / I2C on the STM32F0 (9/22/2016)
- OpenGround – Part 6 – Using the ADC of the STM32F0 in DMA mode to read multiple channels (9/19/2016)
- OpenGround – Part 5 – driving the HSG12864 Display (ST7567 controller) (9/18/2016)
- OpenGround – Part 4 – running GDB on the STM32F0 (9/17/2016)
- OpenGround – Part 3 – SWD/ST-Link debugger (9/16/2016)
- OpenGround – Part 2 – FS-i6s DFU Bootloader access (9/15/2016)
- OpenGround – Part 1 – Components & Pinout (9/15/2016)
stay tuned for more 😉
i bought at sale the evolution, any way to get hex, im not linux user to compile and any picture of flashing method? thanks a lot
Does openground support the x series receivers front frsky?
Unfortunately not right now. All it takes is someone who implements the code. Seems like midelic did some work on the x protocol recently for his receiver developments.
I’m having issues flashing as well. Grabbed the Hex from the thread (as I don’t know exactly what I should be doing with the generated binary) and got the evo into DFU, but when I try to flash I get
“2017-10-06 @ 20:31:21 — Detected device with total flash size 128 kiB
2017-10-06 @ 20:31:21 — Address load for option bytes sector failed with unknown error. Aborting.”
1. What should I be flashing (assuming I need to figure out how to create the hex to flash with BF).
2. What’s the status of the Evo support at this point? Is it mostly working?
Flashing should work even if the hex file is wrong. What was the commandline?
Hi,
I see this project have stalled.
Is there anything I can do to help out? I really would like to see a newer version, preferably easily installed aswell.
If someone of you has hardware V2.2, could you send me your dump of the firmware?
handy-max(at)hotmail.de
Also, I can get into DFU mode, but then I’m getting errors, what am I doing wrong?
dfu-utils prints this: SET_ADDRESS not correctly executed
Ok, I’ve found why I was seeing no ADC inputs and why I could not go into the GUI and got stuck in the debug console. By exploring the different commits, the latest was to fix a bug about how often ADC inputs were processed… by moving the call adc_process() from the gui_loop function to the frsky_send_packet function. But as I’m trying to modify the firmware for using the native A7105 module for Flysky and Hubsan protocols, frsky_send_packet was never called and ADC inputs were not processed. Once I had ADC working, I noticed that switching between the console and the GUI happened by toggling SWA (supposedly CH0) instead of SWC (CH3). Besides, AETR channels were mixed and some of them inverted… So I suspected the Turnigy Evolution detection code and yes, my FS-I6S is detected as a Turnigy Evolution (config_hw_revision=1). Forcing config_hw_revision=0 makes channels work as expected. Just FYI, my PCB reads FS_I6S_V2.4 2015/12/29 like yours.
Thanks and keep up the good work!
So you have the original tx module installed? Hmm I have one pin open and detect a pull -up/down on that I/O for switching between i6s and evolution. In case you left the original tx inside this is probably misinterpreted as the evolution resitor. I did not investigate much to find a physical pcb difference.
Hi Fishpepper,
Really nice work, I’ve been following your projects for some time and it’s awesome! I’m trying to come around and build your FC and 4-in-1 ESC, but I need to improve my soldering skills first. Anyway, with OpenGround I’m hitting the same wall as Jonas was below: I cannot get out of the debug window and, if I force the GUI, I see no ADC inputs. I’ve tried with a fresh git clone of your repository and have the same problem. I’ve tried switching to an older arm-none-eabi-gcc compiler version and still no luck. When compiling this is my command line:
/usr/local/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc -c -O1 -g -I./ -mcpu=cortex-m0 -mthumb -Wl,-Map,openground.map -DHSE_VALUE=12000000 -Idevice -Icore -Iperipheral_lib/inc -Iperipheral_lib/eeprom_emulation/inc -I./src -DSTM32F072 -DUSE_STDPERIPH_DRIVER -DUSE_FULL_ASSERT -DBUILD_TARGET= src/main.c -o src/main.o
I flash it via make flash, but I never go past the debug console with the message “gui: entering main loop”
Has there been any progress on this lately? Really looking forward to hopefully being able to use the finished product on my I6S!
Keep up the great work!
Still work in progress. But already good enough for casual micro copter flying 😉
awesome job man, but i have another question which is not covered by this project. From my perspective flysky protocol and receivers are more then enough for me. but there is always a but 🙂 i need more mixers and ability to mute one of CH1-CH4.
What do you think, hardware will handle 1+ mixers? Lets say for example 3 like i6x has.
Thanks.
A mixer is just some lines of software code 😉
yeah but question probably if there will be enough memory to store them ?
How do I input the code into my evo to bind with frsky?
I’ve hit an issue, perhaps someone knows the solution.
I tried compiling and flashing a new version of the firmware, and now the ADCs are no longer being read out.
This results in me not being able to toggle away the console and show the gui.
Commenting out this switch in the code, so that it always shows the gui, I notice in the channel inputs and stick calibration screens that indeed the values are not changing. Other things such as display and sampling the buttons appears to work just fine.
What’s more odd, I still have a .bin file that I compiled (and downloaded from the device again via st-link) at an earlier time, and as soon as I flash that image back, the ADCs are working as expected.
Thinking this was an issue with the source code, I tried going back to whatever changeset the working bin was compiled from. To no avail, whatever I compile and upload seems to have non-working ADCs.
Anyone has an idea what could have changed?
Do you use the code from the master branch? Which tx do you use, fs-i6s or evolution?
I flashed the master tree yesterday on my i6s, it is working fine for me.
The master branch of the original repo, using a fs-i6s.
I think it’s something to do with my setup or something, as I had been able to compile a bin earlier and that one still works if uploaded.
Problem is I don’t know where to look for the issue.
What version of the arm gcc are you using?
What could also help is comparing what arguments gcc is ran with.
Mine looks like this (when running make):
arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m4 -Wa,-amhls=build/lst/crt0_v7m.lst -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -MD -MP -MF .dep/crt0_v7m.o.d -I. -IChibiOS_3.0.2/os/common/ports/ARMCMx/devices/STM32F4xx -IChibiOS_3.0.2/os/ext/CMSIS/include -IChibiOS_3.0.2/os/ext/CMSIS/ST -IChibiOS_3.0.2/os/rt/include -IChibiOS_3.0.2/os/rt/ports/ARMCMx -IChibiOS_3.0.2/os/rt/ports/ARMCMx/compilers/GCC -IChibiOS_3.0.2/os/hal/osal/rt -IChibiOS_3.0.2/os/hal/include -IChibiOS_3.0.2/os/hal/ports/common/ARMCMx -IChibiOS_3.0.2/os/hal/ports/STM32/STM32F4xx -IChibiOS_3.0.2/os/hal/ports/STM32/LLD -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/DACv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/GPIOv2 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/I2Cv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/OTGv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/RTCv2 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/SPIv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/TIMv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/USARTv1 -IChibiOS_3.0.2/os/hal/ports/STM32/LLD/FSMCv1 -IChibiOS_3.0.2/os/hal/boards/ST_STM32F4_DISCOVERY -IChibiOS_3.0.2/os/various -IChibiOS_3.0.2/os/hal/lib/streams -Imcconf -Iappconf -Ihwconf -Iapplications -Inrf -IChibiOS_3.0.2/ext/stdperiph_stm32f4/inc ChibiOS_3.0.2/os/common/ports/ARMCMx/compilers/GCC/crt0_v7m.s -o build/obj/crt0_v7m.o
You can ignore that last comment, wrong project 😉
What could also help is comparing what arguments gcc is ran with.
Mine looks like this (when running make):
/usr/bin/arm-none-eabi-gcc -c -O1 -g -I./ -mcpu=cortex-m0 -mthumb -Wl,-Map,openground.map -DHSE_VALUE=12000000 -Idevice -Icore -Iperipheral_lib/inc -Iperipheral_lib/eeprom_emulation/inc -I./src -Iperipheral_lib/STM32_USB_Device_Driver/inc -Iperipheral_lib/STM32_USB_Device_Library/Core/inc -Iperipheral_lib/STM32_USB_Device_Library/Class/hid/inc -DSTM32F072 -DUSE_STDPERIPH_DRIVER -DUSE_FULL_ASSERT -DBUILD_TARGET= src/main.c -o src/main.o
…
Are you sure you have built fishpepper/OpenGround master?
Your make command contains STM32_USB_Device_Driver, maybe you have built jacobs fork?
He tries to add USB joystick emulation support.
looking forward to the evolution final version.
Realy like the haptic from the TX but the mini RX are useless with the brownout issues.
Any timeplan for when you will have a final version ?
will there be a way to use FRSKY rx with openground and the Taranis ?
OpenGround can “clone” your Taranis or any other Frsky TX. That way both can control the same receivers without rebinding 😉
I love the work you’re doing here. I’ve been following since the beginning and it’s really quite impressive.
In terms of completion what percentage would you say this is now?
Keep up the great work!
You can use it for smaller quads (100g). All the basic stuff works.
is there a walk through available anywhere on how to get the frsky firmware to work with the evolution?
Not yet. I will write a tutorial in the near future.
Do you think, you can flash the fs i6 firmware to the fs i6s? I have a problem with the afhds…..
No, the i6s and the i6 use a totally different hardware and a different processor. This will not work 😉
Thank you so much for your work on openground – i love the idea open software on devices.
As my turnigy evolution is in the mail I am fondly awaiting a tutorial for how to install openground and the cc2500 module on the tx.
Thanks again – your work is much and greatly appreciated!
Hi there. I would like to flash my flysky i6s, what are the compatible receivers and is it possible to downgrade back to the flysky firmware.
Thanks!
In order to run OpenGround you will have to swap the RF module inside the I6S. Once modified the only way back is swapping the module again and uploading the original firmware you backed up. When running OpenGround you can use all FrSky D8 protocol receivers (D4Rii, VD5M, ..).
Is it at all possible for x4rII rx compatibility?
no, only D8 mode for now.
Will this work with the Turnigy Evolution i want to donate and hellp you with this project.
Yes, this will work with the evolution. The latest master code autodetects Evo and I6s 🙂
It seems the CC2500 modules are no longer available from banggood and won’t be restocked.
Are there any good alternatives?
I’d like to modify the Evolution to be able to bind it to FrSky receivers.
The website says restock on 23rd january. At least for this module .
The website is not always accurate and someone from BG said it won’t be restocked, but I’ll wait another week: http://forum.banggood.com/forum-topic-231998.html
So I guess there’s not much of an alternative available? How about using PPM in combination with an XJT module?
Seems like you can still buy those on aliexpress:
https://www.aliexpress.com/item/Hot-Sale-CC2500-PA-LNA-Romote-Wireless-Module-CC2500-SI4432-For-RC-Quadcopter-Helicopter-Multirotor-Model/32740012877.html
I am not sure if it is exactly the same module, someone will have to test those 🙂
Hi Simon
One major issue with both the Evolution and the I6S is the lack of AFHDS (V1 technically) that’s used on the majority of Flysky compatible integrated FCs
Looking at the original I6 it seems like it has the same FS-HS060 (2014.11.28 Ver1.2) RF Module.
Below is a dump of the I6 firmware.
Do you think it would be possible to add AFHDS to the newer models, using the FW from the I6?
https://gist.github.com/nathantsoi/ab352234dedfaf0451c5faa50bfeb9a4
I’m looking at the firmware now but it’s a bit beyond my Arduino coding ability!
Cheers
Dean
Sure, if someone picks that up it should not be that hard to add FlySky support to Openground.
Grand, thanks for the reply.
Are you writing the firmware from scratch or is it possible to extract data from the original FW?
There’s also this project that may have the required code for AFHDS.
https://github.com/pascallanger/DIY-Multiprotocol-TX-Module
What are you using for writing Openground? If I get time I’ll see if I can wrap my head around it.
Thanks for the work so far!
My firmware is written from scratch. It does not use any FlySky code. I used some GPL libraries e.g. for the touch controller and the display.
How does the protocol work then? Are you using a library or writing the protocol from scratch too?
I think that’s quite a bit beyond my abilities!!
Thanks for the work, the Evo stuff is brilliant and I really think it will take the community be storm!
Thanks! The firmware is written from scratch. There is no library but I reused parts of my OpenSky code.
I’m looking into this at the moment. I’ll keep you posted on how it goes. Might be a better solution for telemetry than hacked firmwares like the i6 needs to add extra fields.
Hello FishPepper,
Did you ever manage to re-flash the original firmware on the remote again?
I made a backup, but when flashing it back on and resetting I keep getting the flashing backlight.
I can flash it with other software just fine and it will run, just getting back the original firmware dump seems to fail.
This flashing backlight, any idea whether it is some kind of built-in error indicator?
I accidentally deleted my FSi6s firmware dump with a make clean directly after dumping it… So I was never able to look at it. However, I recently tested the code on a Turnigy Evolution (which works to 90%, only small differences in ADC pins).
After that test I successfully restored the firmware dump to the Turnigy evolution. So i think it should work for the i6s as well. Did the flash verify suceed?
Yes, rom verify succeeded.
If you want I can send you the i6s firmware dump I’ve made.
I’m a bit reluctant to try it on my evolution until I have the open firmware up to a point where it is usable enough and I’m sure I won’t need the stock firmware anymore.
Until that time, I think I’ll keep my evolution with the stock firmware and develop on the i6s.
Hi Jonas,
Could you share stock firmware for i6s ?
Thanks
Please do not post any links for the stock firmware here as this is probably a copyright violation 😉
yeah you right! if somebody have backup of stock firmware for i6s, please send me to
dmytro dot vasylenko at gmail dot com
Thanks.
Hi ! verry nice job ! I have just one question :
Is it possible to extract the original firmware of a Turnigy Evolution ?
Thx
In principle yes, you can make a backup of the flash content. It seems like the stm32 rom bootloader can read out the original firmware. I did not investigate it further as I do not own any Flysky gear.