Baseflight aka multiwii port to stm32
Re: Baseflight aka multiwii port to stm32
Latest baseflight from GIT. I think this is good performance. I've had 10 satelites.
http://www.youtube.com/watch?v=GkNA_nCsTM4
http://www.youtube.com/watch?v=GkNA_nCsTM4
Re: Baseflight aka multiwii port to stm32
@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.
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.
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
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 ?
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 ?
Re: Baseflight aka multiwii port to stm32
All revisions use exactly same hardware pinout, so there should be no changes in that effect.
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
Can I set elevator to M2 instead of m6 in the command line interface or does it require altering the source code ?
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
Possible maybe, but with timer groups and stuff reserved for servos, no.
Re: Baseflight aka multiwii port to stm32
In airplane mode? You can just modify the mixer or something, any of thees changes would require recompile.
Re: Baseflight aka multiwii port to stm32
Yes, maybe try changing 336 from [0] to [1], or better yet add motor[1] = motor[0]; below it.
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
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.
But, that gives me an idea of what might be happening. I'll take a look at the code paths.
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
Acro mode is the best. I fly FPV all the time in acro.
Re: Baseflight aka multiwii port to stm32
@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 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.
Re: Baseflight aka multiwii port to stm32
No, I will not accept any code that degrades already idiotic bus down to 100kHz, sorry.
Re: Baseflight aka multiwii port to stm32
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)
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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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).
Re: Baseflight aka multiwii port to stm32
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.

Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
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
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
Re: Baseflight aka multiwii port to stm32
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?
Re: Baseflight aka multiwii port to stm32
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();
Re: Baseflight aka multiwii port to stm32
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?
Re: Baseflight aka multiwii port to stm32
angletrim is int16... so center is zero... and +/-... probably in deci-degrees or whatever multiwii uses.
Re: Baseflight aka multiwii port to stm32
Sorry for asking. What is this new setting in CLI - max_angle_inclination what this is for?
Thanks.
Thanks.
Re: Baseflight aka multiwii port to stm32
In angle/level mode, how much the copter will tilt (max) from sticks.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
Here is the latest from git: https://dl.dropboxusercontent.com/u/125 ... 022014.hex
-
- Posts: 244
- Joined: Sat Mar 23, 2013 12:34 am
- Location: Australia
Re: Baseflight aka multiwii port to stm32
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.
Re: Baseflight aka multiwii port to stm32
scrat wrote:Here is the latest from git: https://dl.dropboxusercontent.com/u/125 ... 022014.hex
Thank you
Re: Baseflight aka multiwii port to stm32
I did notice my yaw gyro has a constant positive drift. This may be caused by integer division rounding in drv_mpu6050.c
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
and for the PID part in computeIMU()
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.
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.
Re: Baseflight aka multiwii port to stm32
Sure, feel free to make a correctly-formatted pull request on github for the above 

Re: Baseflight aka multiwii port to stm32
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
If so - is this correct intention?
Reason I ask is OSD is reporting different heading to stock multiwii code
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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?
#define CAP_PLATFORM_32BIT ((uint32_t)1 << 31)
I guess.
Why would multiwii output -180..180 for heading, isn't "standard" 0..360?
-
- Posts: 202
- Joined: Tue Feb 05, 2013 10:28 pm
Re: Baseflight aka multiwii port to stm32
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?
-
- Posts: 202
- Joined: Tue Feb 05, 2013 10:28 pm
Re: Baseflight aka multiwii port to stm32
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
"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.
Re: Baseflight aka multiwii port to stm32
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.
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.
Re: Baseflight aka multiwii port to stm32
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).
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).
-
- Posts: 202
- Joined: Tue Feb 05, 2013 10:28 pm
Re: Baseflight aka multiwii port to stm32
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
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
-
- Posts: 202
- Joined: Tue Feb 05, 2013 10:28 pm
Re: Baseflight aka multiwii port to stm32
Here's a video describing the softserial frsky telemetry
https://www.youtube.com/watch?v=dahGlc3 ... e=youtu.be
https://www.youtube.com/watch?v=dahGlc3 ... e=youtu.be