Baseflight aka multiwii port to stm32

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

Latest baseflight from GIT. I think this is good performance. I've had 10 satelites.

http://www.youtube.com/watch?v=GkNA_nCsTM4

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Baseflight aka multiwii port to stm32

Post by mj666 »

@Timecop
I added support for the Maxbotix I2CXL series of sonar sensors to my code. I also have moved all sonar sensor hardware specific code into a "sonar.c" and "sonar.h" file. There only 3 functions needed for using the different sensors. One for initialization, another one to get altitude in cm and there is another one for getting the SRFxx firmware revision. The sensor type is not easily to autodetect since PWM requires to change the programming off the pins which is not a good plan if you are not sure whats connected and Devantech and Maxbotix share the same I2C address and I have not found an easy way to differentiate them yet. This means there is some setting in the CLI required to set the sensor type an most likely some additional parameters. This new design should allow an easier integration also into Baseflight. From start reading the code it looks to be Basefligth does not realy make use of a sonar sensor yet even the driver for the drv_hcsr04 is included? Do i miss something? The coding for Harakiri is already completed. I ordered an MB1242 sensor and waiting for the delivery. I will published the updated code after testing the new sensor. Unfortunately I was not able to build Basefligth yet with the PX4 environement.

Invid
Posts: 5
Joined: Sun Feb 02, 2014 2:39 am

Re: Baseflight aka multiwii port to stm32

Post by Invid »

scrat wrote:Latest baseflight from GIT. I think this is good performance. I've had 10 satelites.

http://www.youtube.com/watch?v=GkNA_nCsTM4

That looks great. I'm running the same build and that's not been my experience.

I found that even on the latest build (Feb 4th) from github there's a bug where it randomly locks up the FC and it flips over onto it's back.

When it does, the board ignores all input (including killing the throttle and disarming commands) and both times it happened, I had to pick up the quad at hover throttle to unplug the battery. Broke my vTx SMA connector off when it came down too.

RTH seems to work OK, just when it loiters does it seem to lock up.

Not sure how to troubleshoot this, but willing to supply info if I can to assist with figuring it out. I doubt it matters, but for information I'm using this GPS (not using the external mag) and I have the Tx/Rx pins on the Naze32 feeding FC telemetry to a minimOSD board running KVOSD.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Re: Baseflight aka multiwii port to stm32

Post by theailer »

Hi.
I'm having trouble with the airplane mixer. On my white rev3 naze it works like it should, but on the new rev4 elevator wont work.
I have the same pin connected as with the white but it doesn't send any signals to the servo. I've tried two rev4 boards and neither work, but they do work with my quad. All the other outputs work though, m1 to esc m3 and m4 to ail m5 rudder but not m6 to elevator. Even tried on the rx connector side. Am I missing something here ?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

All revisions use exactly same hardware pinout, so there should be no changes in that effect.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Post by theailer »

Yeah. It has to be me handling them wrong. Maybe I fucked them up when soldering the tx and rx pins.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

Invid wrote:
scrat wrote:Latest baseflight from GIT. I think this is good performance. I've had 10 satelites.

http://www.youtube.com/watch?v=GkNA_nCsTM4

That looks great. I'm running the same build and that's not been my experience.

I found that even on the latest build (Feb 4th) from github there's a bug where it randomly locks up the FC and it flips over onto it's back.

When it does, the board ignores all input (including killing the throttle and disarming commands) and both times it happened, I had to pick up the quad at hover throttle to unplug the battery. Broke my vTx SMA connector off when it came down too.

RTH seems to work OK, just when it loiters does it seem to lock up.

Not sure how to troubleshoot this, but willing to supply info if I can to assist with figuring it out. I doubt it matters, but for information I'm using this GPS (not using the external mag) and I have the Tx/Rx pins on the Naze32 feeding FC telemetry to a minimOSD board running KVOSD.


I'm not using external MAG and using gps neo-6m from rctimer v2. GPS Pos Hold is working fine...video is just 1:30 minutes long but my qquad was holding position around 5 minutes. So don't koniw what is with wrong with yours to have lockups. And Return to home works fine.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Re: Baseflight aka multiwii port to stm32

Post by theailer »

Can I set elevator to M2 instead of m6 in the command line interface or does it require altering the source code ?

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Re: Baseflight aka multiwii port to stm32

Post by theailer »

And to confirm the fault, it was me who damaged the board by soldering the tx-rx pins to it. Now my white board doesnt respond on M1 which is to the esc. Still would be interested in knowing if it's possible to change the pwm outs to another pin.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Possible maybe, but with timer groups and stuff reserved for servos, no.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Post by theailer »

Okey. What about shifting the motor 1 output with the motor2 then ?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

In airplane mode? You can just modify the mixer or something, any of thees changes would require recompile.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Post by theailer »

Yup airplane mode. I suppose its in mixer.c . Ive looked through the code and since I havent learned to code I guess now would be a perfect opportunity. Can you tell me if im supposed to look at line 327 to 336 in mixer.c? Or is it not that easy?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Yes, maybe try changing 336 from [0] to [1], or better yet add motor[1] = motor[0]; below it.

theailer
Posts: 49
Joined: Tue Sep 24, 2013 9:06 pm

Post by theailer »

A million thanks dude! Will check it out when I get home.

Invid
Posts: 5
Joined: Sun Feb 02, 2014 2:39 am

Re: Baseflight aka multiwii port to stm32

Post by Invid »

scrat wrote:
Invid wrote:
scrat wrote:Latest baseflight from GIT. I think this is good performance. I've had 10 satelites.

http://www.youtube.com/watch?v=GkNA_nCsTM4

That looks great. I'm running the same build and that's not been my experience.

I found that even on the latest build (Feb 4th) from github there's a bug where it randomly locks up the FC and it flips over onto it's back.

When it does, the board ignores all input (including killing the throttle and disarming commands) and both times it happened, I had to pick up the quad at hover throttle to unplug the battery. Broke my vTx SMA connector off when it came down too.

RTH seems to work OK, just when it loiters does it seem to lock up.

Not sure how to troubleshoot this, but willing to supply info if I can to assist with figuring it out. I doubt it matters, but for information I'm using this GPS (not using the external mag) and I have the Tx/Rx pins on the Naze32 feeding FC telemetry to a minimOSD board running KVOSD.


I'm not using external MAG and using gps neo-6m from rctimer v2. GPS Pos Hold is working fine...video is just 1:30 minutes long but my qquad was holding position around 5 minutes. So don't koniw what is with wrong with yours to have lockups. And Return to home works fine.

Too early to be absolutely sure after hovering only one pack, but based on scrat's suggestion, I changed my gps_baudrate to 57600 and gps_type = 1 and that seems to have solved the lockups. I'm not sure why it was working before but I imagine that communications corruption from the GPS is what was locking up the FC. We'll see.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

If you're using ublox, you should never use gps_type = 0 anyway.
But, that gives me an idea of what might be happening. I'll take a look at the code paths.

Invid
Posts: 5
Joined: Sun Feb 02, 2014 2:39 am

Re: Baseflight aka multiwii port to stm32

Post by Invid »

timecop wrote:If you're using ublox, you should never use gps_type = 0 anyway.
But, that gives me an idea of what might be happening. I'll take a look at the code paths.

Fair enough...it's a new FC and new firmware to me so I approached it with the attitude that I should get it up and running without tweaking until I know the environment better. So when I connected the GPS and started seeing sat counts on the OSD and the gps fix indicators on the FC, I left it alone.

Hopefully my experience can help prevent frustration for others. Still love the hardware and firmware though...the proof is in the flying, and the manual mode is the best I've flown so far.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

Acro mode is the best. I fly FPV all the time in acro.

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Baseflight aka multiwii port to stm32

Post by mj666 »

@Timecop,

last days I have finalized my test with the I2C sonar sensor series from Devantec (SRF) and Maxbotix (I2CXL). The changes ar done for Harakiri and working really well. I tested the SRF02 and the MB1242. The Maxbotix is working much more stable. Unfortunately it will only work with 100kHz I2C Bus clock. I did my test with reducing the clock to 100kHz and have not seen any Issues in flight behavior. ACC calibration looks to be taking longer. Not sure if some power flyers will even detect a difference?

For getting around the I2C clock issues I seen the following options.

1. Make I”C clock configurable via the CLI. User can choose manually.
2. Switch I2C clock automatically to 100kHz if Sonar and Maxbotix is enabled. Transparent for the user.
3. From the datasheet of the Maxbotix it’s also possible to operate the Bus with 400mHz but talk with 100mHz to the Maxbotix. This means switch Bus speed in operation and changes in the I2C driver. This looks to me more risky and complicated.

In the meantime I also get the build environment for Baseflight working. I can start working on the implementation for Baseflight if there is interest? Feedback from you and the community would be appreciated.
Last edited by mj666 on Mon Feb 24, 2014 9:12 pm, edited 1 time in total.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

No, I will not accept any code that degrades already idiotic bus down to 100kHz, sorry.

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Baseflight aka multiwii port to stm32

Post by mj666 »

Then there is still the option for supporting the Devantec I2C sensor series. The dual transducer versions should work better than the SRF02 and the HC-SR04 and have I2C (no pins lost).

Devantech Ltd. I2C Sonars: SRF02 SRF08 SRF10 SRC235 (all the same protocol)
Last edited by mj666 on Mon Feb 24, 2014 10:03 pm, edited 1 time in total.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Where is the code?
It all depends how clean it is and how many people will be using it.
I already know like 0 people use sonar total, so that one's out, so remainder is what the code looks like.

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Baseflight aka multiwii port to stm32

Post by mj666 »

I published my changed code files for Harakiri in the FPV-Treff Forum (you already have seen the the initial version of this). The "drv_sonar.c" and "drv_sonar.h" should work for Baseflight without much changes replacing the existing sonar driver. The driver itself needs one setting in the CLI for choosing the sensor type. Autodetecting is not easy possible. There is also some checking of some sensor specific ranges in the driver. Actually Baseflight does not make use of sonar sensor at all (only the driver for HC-SR04 PWM sonar is present). I have not touched the sonar control code in Harakiri and only did the sensor integration. This code requires some additional settings in the CLI. Crashpilot1000 has integrated my changes mainly into his latest test release. I was using this version for flying’s last days. I left all setting as default but changed the I2C bus speed to 100kHz for this tests. I have tested the following flight modi successfully without and issues (acro, level, baro, gps hold, baro + gps hold).

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: Baseflight aka multiwii port to stm32

Post by msev »

mj666 you need to make a proper diff versus baseflight not harakiri. How can you ask the original author of baseflight to scavange through non-proper version controlled code :), that is just wasting his time.

mj666
Posts: 186
Joined: Wed Feb 12, 2014 12:02 pm

Re: Baseflight aka multiwii port to stm32

Post by mj666 »

I can make diff files for integrating the new sonar sensor code into the latest test version. This part of changes I can do in may be less than one hour. This part was what I was working on for Harakiri. Anyhow someone also needs to work on the controller code witch is not there yet. Only this will make value from the sensors. At the moment I have no idea what the plans for the sonar support would be for Baseflight? Reusing the Harakiri implementation? Something different? My understanding is Multivii also does not have sonar controller code yet (only landing lights)? I have a working build environment for Baseflight also but no experience with GIT yet.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: Baseflight aka multiwii port to stm32

Post by ezio »

Hi
I want to implement MSP_ACC_TRIM in ez-gui. Can someone tell me what min,max and zero values are for the trims?
I don't have stm32 board to check.
Thanks.
Bart

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

ezio wrote:Hi
I want to implement MSP_ACC_TRIM in ez-gui. Can someone tell me what min,max and zero values are for the trims?
I don't have stm32 board to check.
Thanks.
Bart


Will you support baseflight FW in ez-gui?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

ezio wrote:Hi
I want to implement MSP_ACC_TRIM in ez-gui. Can someone tell me what min,max and zero values are for the trims?
I don't have stm32 board to check.
Thanks.
Bart


You're missing all the fun.

Code: Select all

    case MSP_SET_ACC_TRIM:
        cfg.angleTrim[PITCH] = read16();
        cfg.angleTrim[ROLL]  = read16();

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: Baseflight aka multiwii port to stm32

Post by ezio »

timecop wrote:
ezio wrote:Hi
I want to implement MSP_ACC_TRIM in ez-gui. Can someone tell me what min,max and zero values are for the trims?
I don't have stm32 board to check.
Thanks.
Bart


You're missing all the fun.

Code: Select all

    case MSP_SET_ACC_TRIM:
        cfg.angleTrim[PITCH] = read16();
        cfg.angleTrim[ROLL]  = read16();

This I already know. But this means that the middle of the trim is 32767 or there is some other logic behind this.

I made quick look at the baseflight source code and I can see that protocol is the same as in multiwii so it should work without a problem with ez-gui.
Am I right?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

angletrim is int16... so center is zero... and +/-... probably in deci-degrees or whatever multiwii uses.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

Sorry for asking. What is this new setting in CLI - max_angle_inclination what this is for?

Thanks.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

In angle/level mode, how much the copter will tilt (max) from sticks.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »

Thanks.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Baseflight aka multiwii port to stm32

Post by subaru4wd »

Where can I find the latest .hex for baseflight? The one that google chrome configurator is using?

I downloaded a .hex I found on github, but when I tried to use the STM Flash Loader, it said there was no data in the .hex

I wanted to try using the Chrome app to flash my board. But I noticed your disclaimer, and don't want to brick my Flip32 using your Chrome App since its not official hardware and stuff.

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Baseflight aka multiwii port to stm32

Post by scrat »


felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Baseflight aka multiwii port to stm32

Post by felixrising »

If you're not using cTn's excellent Baseflight Configurator for flashing and configuring Baseflight, then you're doing it wrong. TC himself uses Baseflight Configurator for flashing each board before shipping.

subaru4wd
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Baseflight aka multiwii port to stm32

Post by subaru4wd »

scrat wrote:Here is the latest from git: https://dl.dropboxusercontent.com/u/125 ... 022014.hex


Thank you

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: Baseflight aka multiwii port to stm32

Post by Plüschi »

I did notice my yaw gyro has a constant positive drift. This may be caused by integer division rounding in drv_mpu6050.c

Code: Select all

data[2] = (int16_t)((buf[4] << 8) | buf[5]) / 4;

But .. since gyro-zero calib is done the same way im not sure what actually happens. :?:

I did resolve this issue by moving the division to imo.c for the getEstimatedAttitude() part

Code: Select all

scale = deltaT * gyro.scale * 0.25f;

and for the PID part in computeIMU()

Code: Select all

gyroData[axis] = gyroADC[axis] / 4;

which gives me a much smaller drift due to better calibration resolution.

I would like to kick deltaT and substitute with looptime, which would make scale constant and kill the whole micros,currenttime,previoustime stuff.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Sure, feel free to make a correctly-formatted pull request on github for the above :)

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Baseflight aka multiwii port to stm32

Post by shikra »

Hi all - can anyone advise if "MWheading" sent from baseflight via serial request is -180-+180 like Multiwii or 0-360?
If so - is this correct intention?

Reason I ask is OSD is reporting different heading to stock multiwii code

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »


User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Baseflight aka multiwii port to stm32

Post by shikra »

mmm thanks, looks like it does following it back through....
https://github.com/multiwii/baseflight/ ... imu.c#L233

So should I put an option in OSD to fix... or will baseflight be amended to match multiwii.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

You can use the 'capability' bit and check for
#define CAP_PLATFORM_32BIT ((uint32_t)1 << 31)
I guess.

Why would multiwii output -180..180 for heading, isn't "standard" 0..360?

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

tovrin wrote:What is to stop us from taking a page from his book and creating our own fork


Nothing, and git and github encourages this. However, rather than just merging into a new codebase from baseflight why not contribute to baseflight? As a baseflight developer I'd be happier if we all worked together to improve the overall quality of the code and thus the finished product rather than having another fork?

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

I've done some software serial updates to baseflight today, from the pull request:

"Add support for 2 softserial ports on PWM5+6/TIM3_CH1+2/PA6+PA7 and PWM7+8/TIM3_CH3+4/PB0+PB1.

The software serial ports share the same baud rate both both are independently invertible.

The configuration parameter for inverting software serial ports changed. Use 'softserial_1_inverted' and 'softserial_2_inverted'.

Updated software serial to monitor serial pins for signal changes instead
of periodically sampling pin signals.

When reading the data the timer used is synchronized to the falling edge
of the start bit which allows for better synchronization at higher
speeds. The code has been tested OK from 1200 baud to 19200. 38400
baud was tested and partially usable but has been disabled because there
are too many transmit and receive errors, especially when transmitting
and receiving at the same time.

Due to the way a single timer is used for transmitting and receiving, if
data comes in while transmitting the system may incorrectly transmit a
short or long bit. However at 19200 and below this didn't cause a
problem in the limited testing I performed."

https://github.com/multiwii/baseflight/pull/50

I don't think I'm going to invest any more time attempting to support speeds higher than 19200, at least not until my oscilloscope arrives.
I'm happy with the implementation of two additional serial ports at 19200 though. That should open up the doors for some peripheral expansion.

It should also be possible to have GPS + Telemetry + GUI all working at the same time now, when armed or otherwise. However additional code changes are required for that support.

EDIT: To clarify the ports you use are as follows:

RC5 Software Serial Port 1 RX
RC6 Software Serial Port 1 TX

RC7 Software Serial Port 2 RX
RC8 Software Serial Port 2 TX
Last edited by dominicclifton on Sun Apr 06, 2014 9:14 pm, edited 2 times in total.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: Baseflight aka multiwii port to stm32

Post by Plüschi »

Baseflight - GPS

The baudrate defines of GPS are 0 = 115200, 1 = 57600 , etc, not the other way round like described in baseflightGUI.exe . This needs to be described in CLI variables wiki. The code for -1 = autobaud is not implemented, right?

The gps message parsing is done inside the serial interrupt handler. I dont think this is a good idea. I think using the built-in serial buffer and then poll for new messages all 3.5 ms would be far better idea.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Baseflight aka multiwii port to stm32

Post by timecop »

Well, nobody uses baseflightGUI.exe ? I guess.
I agree with GPS parsing. Patches welcome.
There was some work recently to get rid of -1 stuff, actually the autobaud DOES still work - i.e. if theres no data it'll go to GPS_LOSTCOMMS state and will cycle to next baudrate in the list and wait until there's some data received, bla bla until it finds the right rate or just keeps repeating if there isn't one. It just means if you entered wrong baudrate for nmea and you have actual data coming in, it'll eventually find the rate its at (assuming its something standard).

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

I'm uploading a demonstration showing software serial that I implemented sending telemetry data to an FrSky D4R-II Receiver which is subsequently displayed on a Turnigy 9XR running OpenTX and on an Android phone via bluetooth, all while simultaneously running GPS and MinimOSD. I'll edit this post with the link later on.

Baseflight now supports two software serial ports running at up to 19200 baud on RC5/RC6 and RC7/8 pins.

Enable softserial and FrSKY telemetry on baseflight using the following CLI commands:

feature TELEMETRY
feature SOFTSERIAL
set softserial_baud=9600
set softserial_1_inverted=1
set telemetry_softserial=1
save

Also requires RC input signals to be sent via PPM to baseflight via

feature PPM
save

Works fine with two camera stabilisation servos too, via

feature SERVO_TILT
save

For source see:

https://github.com/multiwii/baseflight
https://github.com/multiwii/baseflight-configurator

For apps see:

https://chrome.google.com/webstore/deta ... figk?hl=en
https://play.google.com/store/apps/deta ... o.multiwii
https://play.google.com/store/apps/deta ... .frskydash
http://www.open-tx.org/

For my Turnigy 9XR Frsky 9XR wiring see here:

https://plus.google.com/+DominicClifton ... BLiy4czD8y

See here for an outdated OpenTX / FrSKY guide for the Turnigy 9XR:

http://forum.turnigy9xr.com/converting- ... -t362.html

See here for an outdated OpenTX / FrSKY guide for the Turnigy 9X:

http://www.rchacker.com/projects/turnig ... -telemetry

dominicclifton
Posts: 202
Joined: Tue Feb 05, 2013 10:28 pm

Re: Baseflight aka multiwii port to stm32

Post by dominicclifton »

Here's a video describing the softserial frsky telemetry

https://www.youtube.com/watch?v=dahGlc3 ... e=youtu.be

Post Reply