fishpepper
Add support for the FrSky D16 protocol
D16 (non-EU) can be tested now: https://github.com/lunohod/OpenGround/commits/new_features Binding doesn't work as of now, you have to clone an existing Taranis (in D8 mode). Then just change the RX number in the Model X settings.
@lunohod Any plans to have this support the evolution? I tried flashing the new_features branch to one and it looked like all the I/O port mapping was for the other model of TX (stick input not there, battery voltage wrong etc.)
@scottjw hm, I have to test it with my evo. Does the latest version from this repository work for you?
@lunohod ya master branch from fishpepper's repo works for me. I was thinking it just had a bug with model detection or that model was hard coded. Don't know the code base well enough to figure that out though.
@scottjw I just flashed my evolution with "make dfu" from the head of the new_features branch and it is working fine. The IO mapping is almost the same, just the first 4 channels are in the different order, so you should have the sticks mapped to the wrong channels in the worst case, but no input at all is a different issue. Make sure you have cloned my repo and switched to the new_features branch with "git branch new_features". BTW, the default settings are TAER and Mode 2 in my repo, you can change them in Config->Chan CFG.
@lunohod I repeated the procedure from scratch with make dfu, after I re-saved the stick settings, calibration and model it all just worked. I guess you need to overwrite the storage/settings to update them, thanks a lot for the code and the tips.
@lunohod hey there - long time no comments here :) is the development completely dead? I found my evolution in the drawer and have an application for it with my 3" quads. They have an xm+ in there and therefore are D16 protocol...
I went and tested your branch - seems to work fine so far, but I have found a curious bug when monitoring the receiver tab in betaflight: As soon as the touchscreen registers an event, the RF module seems to reset and the receiver looses signal. Flight controller registers a fail-safe. I have not
Heres a video of the whole thing - do you have any idea how this could be solved? Maybe the timer I am trying to use gui buttons to set a channel.
@ameeuw hi! Well, all I needed was implemented and I had no new ideas. I could reproduce the bug with my emax tinyhawk in D8 mode. I guess the touchscreen irq handler is blocking the rx timer interrupt.
hey @lunohod - thank you for the super quick reply :)
What would you suggest? Move the checking of the TOUCH_INT_PIN pin from the external interrupt to the sys_tick_handler, poll every sys_tick and apply debouncing?
Debouncing in the IRQHandler seems wrong to me..
I would just set a flag in the interrupt handler and then trigger the i2c communication from the sys_tick_handler. Maybe we could/should use DMA for the i2c, but I have no idea how to do that.
@lunohod I introduced a flag to register touch events and trigger the i2c communication from the sys_tick_handler every some ms.
However, it seems that it is not the frequency of i2c reads but the way the touch_i2c_read function works
Next thing I wanted to try is to make a state machine for the byte transfer which would get called repetitively and would return immediately if a condition such as (i2c_busy(TOUCH_I2C) == 1) is not met instead of staying in the while loop.
@fishpepper do you have any smart way in mind to fix this issue? Have you worked with a DMA channel for i2c?
You are right, doing the I2C call in the interrupt handler is really stupid^3. No idea how it got there in the first place 8) Setting a flag and doing it in the systick is way better.
I guess a non blocking statemachine would be the prefered way. Are you sure that this blocking is the cause of the link loss? Does it only happen on D16 or on D8 as well?
The frsky stuff should run triggered by the timer and any blocking non ISR code should not crash the link.
Are you sure that this blocking is the cause of the link loss? The frsky stuff should run triggered by the timer and any blocking non ISR code should not crash the link.
Nope I am not sure - your thoughts were exactly mine. The ISR should be executed every 9ms no matter what blocking code happens... any further thoughts what might cause the link loss?
Does it only happen on D16 or on D8 as well?
Have not tried it on D8 - I dont think I have a D8 receiver lying around anymore. @lunohod could the D16 extension have anything to do with the link loss?
At the moment I am just trying to figure out the cause. Maybe we should think of all sources for the link loss before implementing fixes :D
Nice of you guys to be so responsive on github :)
I was able to reproduce the issue with D8 too. But I was using my branch, where the DIY-Multiprotocol-TX-Module code for both D8 and D16 is being used. It's also timer driven though. I can test later with original OpenGround code.
I just tried the master branch of this repo and the issue is there. Also removed the i2c communication from the irq handler and it doesn't help
LOL, you can't do that in the systick handler either, it's an isr too!
I moved the I2C communication to the touch_get_last_event(), which is called from the gui main loop. But I had to decrease the gui timeout, because it was skipping touch events.
@ameeuw this might be a little harder. If you want to send 16 channels, you send first 8 and then the last 8 channels alternately.
8ch mode is hardcoded, you have to remove three lines there leaving only lpass++ to make 16 channels work: https://github.com/lunohod/OpenGround/blob/d0067095f5e2ff160696f973a04789215e232e29/src/FrSkyX_cc2500.c#L177
And then you have to patch lines 160 and 165, because you have not enough adc inputs to feed all 16 channels.