RCExplorer F3FC target

[lkaino]

I have attached the HEX here for testing iNav target on the RCExplorer F3FC board.

I kindly ask anyone interested with the board to test the HEX. I'm mostly interested if the on-board barometer is working. Please post findings here.

inav_1.2.0_RCEXPLORERF3.zip

[wilco1967]

Hi Ikaino,

Flashed OK in the F3FC, but no baro..... Gyro and ACC seem fine....

Further, Serial RX under ports doesn't want to 'stick'... doesn't matter if I set if first on the ports tab, or on the configuration tab. in fact, it doesn't seem to save any setting done under the ports tab.

Ehhh... just noticed, ALL 3 uarts show as uart1 on the ports tab.... that has probably something to do with not being able to save....

PPM sum receiver works. SBUS doesn't because of above.

Wilco

[lkaino]

Thanks for testing. I will get a board this week and check what's wrong with those.

[resokk]

@wilco1967, my version (with target files): f3fc.zip

@lkaino, maybe it will be helpful for you...

[wilco1967]

Thanks ! I will give this a try this evening.

[lkaino]

@resokk, nice! Have this been working for you? Yes I notice now what might be wrong with I2C and UARTs.

Can you explain what these do and are there some other iNav specific macros?:

define NAV

define NAV_AUTO_MAG_DECLINATION

define NAV_GPS_GLITCH_DETECTION

This might be needed also:

define NAV_MAX_WAYPOINTS 60

[wilco1967]

Hi Resokk

Thanks a lot for your help. I'm typing this as I'm testing, so could be a little confusing.

For the moment, Only testing the F3FC loose on the bench, without motors / servo. Want to know first if it works before taking apart the Tricopter (V3) which currently runs iNav 1.2.0 (version from yesterday), on a Flip32 clone (naze clone from banggood)

Flashing works fine, ACC, Gyro and BARO all work. have to use 180 deg pitch for correct alignment (using iNav configuration).

When trying to set SerialRX - SBUS it accepted the Serial RX, and it accepted the UART1 port selection, but it would not accept SBUS from iNav configurator. (even trying few times). However, when setting to SBUS from the CLI, it worked fine.

Receiver via SBUS works, Receiver via CPPM also works

Smartport telemetry (Frsky XSR receiver) works. MSP over a bluetooth adapter on UART1 & 2 & 3 works.

External Compass (5883) via I2C works (haven't try to calibrate yet, but they show in sensors tab.

I can't get the ACC to calibrate, using the 6 orientation iNav methode. All values ACCGainX/Y/Z stay at 4096, But the pitch/roll/yaw graphic works just fine, and shows the correct orientation. So it might be OK after all.... probably this is a iNav 'problem', not the sensors themselves.... EDIT: tried a few times more, and now managed to get it calibrated... perhaps I was trying to be too accurate before.... now did it a lot faster, and not as accurate, and repeat a couple of times, and it seem to have accepted it.

GPS (old RCTimer Ublox6) works via UART1 & 3 (haven't tried 2)

MW OSD via UART3 works. VBAT works Current Sensor, seems to work... I get a reading (0.2 amps), which seems right for just the electronics, but not loaded yet.

So far so good.

However, there seems to be one potentially (?) serious problem. Could be nothing / or just me.... proble is, sometimes the cycle time goes to 23000ísh. (normal 2000) and CPU load > 700% !!! (normally only 1%), When this happens, the telemetry stops, and serial communication with the iNav configurator becomes really slow. cannot figure out what causes this. Happened a few times. My best guess is, its when I connect or disconnect anything from the serial ports while running, but not always.... doesn't seem to happen when I don't touch anything.

So basically, everything critical seems to work on the bench... The only thing not tested yet are the motors and servo.

I guess I will take apart the old tricopter, and put the new F3FC in, but need to do some soldering. But that will have to wait to earliest friday.

THANK YOU VERY MUCH !

[resokk]

@lkaino NAV_AUTO_MAG_DECLINATION meens enabled "automatic declination" by default (similar (copied from?) feature to APM) - evaluation of dec by GPS location with lookup tables (F3 support only as far as i know). NAV enables iNav features (may be defined by default?) NAV_GPS_GLITCH_DETECTION - (feature from APM (similar/copied)) - can help alert the pilot to a bad GPS position (to reduce the incident of fly-away)

I know NAV_MAX_WAYPOINTS, NAV_BLACKBOX

[resokk]

@wilco1967 Don't you forgot about "If the flightcontroller is mounted in another angle or upside down, do the calibration steps with the flightcontroller pointing as shown in the pictures, not the quad"? :) F3FC is CW180FLIP mounted acc/gyro... So 1) up-side down 2) up-side up 3) usb up 4) tail down 5) usb down 6) nose down - and accgain_x = 4065, accgain_y = 4089, accgain_z = 4007. Only one problem - 0a21d9eeb2c66b3c146dc0b75573b6b6dfb2d44d - attached new build (with this fix) or accgains are about 8000-8100 :) F3FC.zip

Some times i have a lot of i2c errors (it makes a long looptime) ... Reboot (without power-off) fixes problem - seems like a problems with baro :( And i have problems with compass calibration - can't get stable N-E-S-W pointing :(

[wilco1967]

Ahh... After trying you hex file, where I had the ACC errors, I compiled my own hex, using your target.c files and the most up to date git files. Then the ACC calibration worked... Now I can understand why....

Didn't see any I2C errors, but we'll keep a lookout....

Haven't tried the compass calibration yet.. just the loose sensor

[resokk]

@wilco1967 did you have successful (stable) MAG calibration?

UPD: i have successful MAG calibration (incorrect sensor alignment). "sometimes the cycle time goes to 23000ísh. (normal 2000) and CPU load > 700%" - i have the same behavior while i2c errors

[wilco1967]

Not tried yet... The compass is still loose, so it would fail any way....

[lkaino]

Great progress!

So the cycle time peaking is currently the only known issue left. Has this been noticed with any other boards? Does it go away if the baro is disabled?

I'll get my board today or tomorrow so I can start testing. I don't think the Neo 7M GPS that I have has a compass so I can't test the I2C compass yet. But you verified that it's working.

[wilco1967]

Alright, fixed the compass to the F3FC, and tried a compass calibration.... Was a little confusing initially and some trial and error finding the correct mag allignment but once I sorted that out, compass calibration seems to have worked.

I have my 5883 upside down, so I assumed I should put in CW180degFLIP.... but apparently, because the entire F3FC board is already set as 180pitchdegree (so upside down, front becomes back), This seems to have transferred over to the magnetometer as well.... So I ended up with default / CW0deg for MAG alignment.

Looking at the old way Multiwii sensors were supposed to move didn't help much.... seems like that is no longer valid for cleanflight / iNav. just found it by trial and error until it seemed right.

Whatever.... Compass works, and I can calibrate.....

Regarding the cycle time problems.... it looks indeed to be associated with I2C errors... normally, the board gives me only a few I2C errors on startup (1..2) , but than doesn't move anymore. But sometimes, and that seems to be related when I touch things, the I2C counter starts running up, and the cycle time becomes very high (27000 ish uS, > 700% CPU load, and slow to respond. But that seems related to electrical problems from me touching electronics with my bare hands (yeah, I know.... sorry). Doesn't look like a software issue.

Currently feeding the mag / I2C off the 3.3 volt connection... maybe moving to 5 volt will help. As far as I remember, the old compass I used for testing was originally intended for 5V operation, or at least, it always has been used on 5 volts....;-) but usually works just fine.

So, software seems fine so far....

Tomorrow / Saturday I'll take the tricopter apart, and convert to the F3FC, and see if it flies... I'm pretty confident this will fly.

One other question. Just a 'nice to have'.... nothing important.

Is there any way to use softserial ? 3 UARTS sounds like a lot, but used up quickly Enabling softserial doesn't seem to do anything right now. Also in the Triflight code, I noticed it was deactivated / experimental (todo).

If I use SBUS and SmartPort telemetry, UART1 & 2 are taken. GPS takes up UART3.... that leaves me without anything to connect a bluetooth dongle or an OSD

So for now, I used CPPM to free up UART1, which I plan to use the GPS. (BTW, the new Frsky XSR receiver is great... offers both CPPM and SBUS, so easy to switch). UART2 is for telemetry, and UART3 for bluetooth / OSD (which ever I need).

With softserial, I could put the telemetry on softserial, as it is not critical, and it always worked well on my old Flip32 clone. Then I could use SBUS for control.

I assume, softserial would go on pins PWM5 or 6 ? Again, not important..... just nice to have.

[resokk]

@lkaino i2c errors have too strange origin: i left board for an hour - everything fine, but sometimes a few minutes (untouched) can bring "error session".

Some debug enable understanding of source - it's baro (write device id in debug[] while errors). With baro disabled (in compile time) i have no problems any time. I spent a two weeks on it but have no luck - thats why i don't send any PR on target.

@wilco1967 i disable soft serial, mags (except hcm5883), baro (except builtin) and sonar (except hcsr04) - they can be enabled in target files.

[lkaino]

@resokk Do you have the mag on the i2c bus when the errors occur? Not that it should matter.

Sounds like something is wrong in i2c driver if it can add 20 ms+ blocks to the execution. Have you checked at which point in i2cRead() or Write() does the timeout occur?

How long is I2C_LONG_TIMEOUT really? Seems like it loops the I2C_GetFlagStatus() for 40k times so that might add some milliseconds delay to the execution.

[wilco1967]

So you think it's a software issue ?

I've left the controller running for the whole morning on the desk, but also left it running while driving back from work.... 6 hours so far, still working without a glitch...

So, don't know.... doesn't prove one or the other I guess....

I'll start converting my Tri this afternoon... hopefully get a flight out today. I'll let you know what happens. BTW: has ANYONE already flown with this version ?

[lkaino]

@wilco1967: Only saying that the huge peaks in execution time are most likely a software issue.

The reason for not getting proper responses from the barometer might be a hardware issue.

[wilco1967]

I do getting proper response from the Baro, AND the Compass.... Only sometimes I start getting numerous I2C errors, and the cycle time goes sky-high (>27000 uS)... So far that only happend when I was touching the board, connecting / disconnecting thing, etc. Perhaps it is a software issue, that it is supposed to time-out on I2C faults earlier, without driving the CPU cycle time through the roof... just guessing. As I see it, I could still fly without baro/compass, so why should an I2C failure stop the rest ?

rebooting the board always helps and all works again normaly..., I've seen one time when the board booted, I didn't get baro, but after a power cycle all was fine again....

Today haven't seen the fault, so we'll try flying it later... Worse that can happen is a crash, and we got plenty of experience with that.... ;-)

[wilco1967]

Alright, No flying for the moment...

Seems like the motor / servo layout is wrong.

when using iNav, set up as a tricopter, it get the following respons (all wiring connected as per F3FC standard)

inav (tricopter) motor nr -> what is moving 1=tail motor 2=servo 3=right 4=not available (set up as tricopter)

if I set it as quad, testing motor4 will run the left motor. rest stays same The servo will move hard over, because it gets a signal for 1000 uS (I haven't activated oneshot, so it sees a valid signal).

I'll have a shot at changing the pin numbers. I assume those are the ones found in target.c, right ? (I'm absolutely not a programmer, but I can manage to compile the source).

EDIT: I managed to get at least the motors correct, but can't figure out the servo.... it responds to changes on motor-4 (if I select quad), but it will not move at all when selecting tri...

this is what I got to: (target.c) const uint16_t multiPPM[] = { PWM6 | (MAP_TO_PPM_INPUT << 8), // PPM input PWM3 | (MAP_TO_MOTOR_OUTPUT << 8), // TIM3? (motor 1 = Tail for Tri) PWM4 | (MAP_TO_MOTOR_OUTPUT << 8), // TIM3? (motor 2 = Right for Tri) PWM1 | (MAP_TO_MOTOR_OUTPUT << 8), // TIM1? (motor 3 = Left for Tri) PWM2 | (MAP_TO_MOTOR_OUTPUT << 8), // TIM17? ("motor 4", will move the tail servo) PWM5 | (MAP_TO_MOTOR_OUTPUT << 8), // TIM3? 0xFFFF };

I simply swapped some lines, that moved the motors to the correct spot... perhaps not the correct way to do it, but it seems to work...

The servo i guess should be found somewhere else in the code (after all, these lines here are called 'motors'), but can't figure out where....

The motors work correctly now, tricopter wants to stabilize correctly, but no tail servo........

[lkaino]

Can you test with this one, rebased the PR and applied the fixes to target.h.

Wasn't able to reproduce the I2C errors with just the bare board connected to USB for 10 minutes.

inav_1.2.0_RCEXPLORERF3.zip

[wilco1967]

YES.... correct.... motors move correctly, and also the tail servo works correct....

Could you also post the source files (target.h / target.c / whatever else you changed) Thanks a lot.....

I'll fix up all the parts, and see if I can get it to fly.... but looks like it will...

[lkaino]

You can find the files and changes in the PR: #439

[wilco1967]

Alright, it flew !

your latest hex file did the trick. Everything seems to work fine.

just two little issues.... Baro is very 'itchy'... On a 3S battery, it was OK at first, but on 4S, it became very jumpy.... tried tuning it down, but seems to come from the baro going up/down few meters, while the copter actually stationary. The Baro is hidden inside the front spacer, so should be out of the wind.... Didn't see any I2C errors. I'll stuff the front space with some foam or whatever I can find. On the old Flip32 clone, alt holt was not perfect as well, but workable... Will test some more tomorrow.

Another thing is, I lost telemetry completely after a while. power cycling the board resolved that. It was still flying normally, and EZ-GUI showed all normal. no I2C errors, normal 2000 cycle time....

Anyway, that will get sorted out sometime.... not critical.

Thanks a lot again !! I owe you guys a beer !

[wilco1967]

I tried to find those files, but if I merge them with the latest source, it won't compile. found them at https://github.com/iNavFlight/inav/pull/439/commits/8cc5947b86ef223a2b22742ee7fa9c91fc5b08dd but that doesn't work

also found https://github.com/iNavFlight/inav/commit/79e50a148c39e45f3bcb94ff84eab656fdb2980d, but that is empty....

Probably my fault, but could you give a hint where to look ? Thanks a lot....

EDIT: Never mind.... managed to get it working. I'm just very new to GIT. Had difficulty getting your tree cloned... it would always get the master. copied your tree using zip file, but then the compiler complained it was no git file.... there is probably a trick for that, but I don't know. By copying the contents of the zip file, over the directory containing the master, and just overwriting everything, it seemed to work.... It compiles now, and downloads ok, and everything seems to work fine... not flown with the self compiled code, but see nothing wrong.

Will this get pushed over to the master anytime soon ?.

[wilco1967]

Some update....

There is definitely something not right with the baro. With the iNav code, I get proper baro values and mag values. However, no matter how I try, I can't get the alt hold tuned.... even if I take out all the I and D of both the alt and vel controllers, it is still very jump.... sometimes it seems to hold just fine, but than suddenly, it rockets up in a series of fast throttle burst, Even the slighthes amount of I (0.001) and it will start to go up and down.... The baro is inside this front spacer, and I even put some cotton over the baro, to stop even the slightest of light getting in through a gap (I can't see any, but just to be sure). doesn't make a difference.

Alt hold wasn't perfect on the flip32, but that worked reasonably well. Other than the flight controller, everything else is the same hardware. Even used the same PID settings, and it flies pretty much the same as before, except alt holt...

So I tried Tri-flight, to see if that worked any better. With Tri-flight, when I connect the compass, the baro will not work at all.... it doesn't even see the sensor. The compass works though. When I disconnect the compass, the baro starts to work again (after a reboot)..... Very strange.

So Tri-flight is even worse.... tried both the version from RCexplorer website (6 june ?) and one I found on githup from 24 july.. Both same behaviour. . If this had anything to do with pull-up resistors on the I2C bus, I would expect it to affect both iNav and Tri-flight the same, but they definitely behave totally different. On iNav, both work (at least, I get normal sensor values, and no I2C errors.) Also tried powering the compass from 5V rather then 3.3 V... no difference.

I'm at a loss..... Any ideas ?

[lkaino]

Okay that doesn't sound good, there's similar reports in the RCE forums.

You previously mentioned that it was better on 3S battery, have you tested that again?

I'll ask David to check if he can find something wrong on the board.

[wilco1967]

Don't think it's the sensor code itself. Today testing was mainly on 3S, but happens also on 4S.

I just happened to have some initial 'stable' alt hold on 3S, but that was only couple of seconds before I had to change the battery, and that was, as it turned out later, just a lucky shot... It sometimes can seem like it hold (also on 4S), but than the slightest disturbance will start rocketing up. Even dropping the throttle to almost zero, it will still go up. most of the time (95%) it never even starts steady. Tried all kinds of extreme PID settings.... both on Alt PID as on Vel P&ID... doesn't even behave like a 'normal' PID controller should work I'm a (proces) control engineer by profession, So I'm supposed to know just a little about PID control (but I'm used to Integral times in seconds to minutus, not milliseconds) ;-).

I have some blackbox logs and Taranis telemetry logs attached, if that helps.

Worth mentioning, the (baro) Alt and (GPS) GAlt worked all the time, and show pretty much the same values. Also mag worked fine, No I2C errors (just one or two on bootup, but than steady. haven't had any problem with looptimes / I2C errors anymore)....

I don't think it's the sensors or the sensor code itself, but somehow the altholt PID algorithm screwed up. Triflight probably has an error in the sensor code (making the baro not working when connecting the mag), which I guess you must have corrected in iNav.

Perhaps problem with alt hold is common on all F3 boards ? . Does anyone have a proper working baro (in ALT HOLD) with any kind of F3 board with the githup source from the last few days, after the many changes done ?

My last flight on the F1 board (flip32 clone) was using: INAV/NAZE 1.2.0 Aug 9 2016 / 16:48:24 (c65e9c9), and that worked fine.... I would have to piggyback the old F1 controller on top of the F3FC to test current github code on F1 (only rewire the motor & servo PPM wire to the F1 to test, F3FC just becomes Power Distribution Board)

F3FC code used today was

INAV/RCEXPLORERF3 1.2.0 Aug 12 2016 / 22:16:31 (8cfc74b) and

INAV/RCEXPLORERF3 1.2.0 Aug 12 2016 / 19:04:32 (c333926)

(one I got from you, the other self compiled). Both same effect. F3FC-2016-08-13.csv.txt LOG00196.TXT

Thanks a lot for your help, very much appreciated !~

BTW, are you the same person as 'Lauka' over at RCExplorer ? (lka = lauka ?)

[lkaino]

Did a review to the driver code, it is solid, no bugs there.

The temperature reading from the baro is very stable, although +5 degrees higher than ambient temperature.

The pressure reading is fluctuating, short term and long term. I have never played around with pressure sensors so I have no idea how accurate readings to expect. When I raise the board about 1 meter and lower it back down, every time it is lowered the pressure reading gets higher than it was before. Weird.

Yes I'm the same guy, I have been using these two nick names lkaino and lauka. Don't remember why I chose lkaino here in github, maybe lauka was taken. At least it's taken now.

[wilco1967]

My guess, it probably related to the changes made in the main code.... I read about others having similar problems with alt hold, on other boards.

Alright, that will be found sooner or later...

I am pretty much sure the F3FC related changes are fine as you said...

Once it gets included in the master tree, more people will start using it... Any faults will be found.

Thanks again !

Btw, so you are also the guy behind triflight ?. Do you know why triflight doesn't like baro and compass at the same time ?

Will the tail servo changes from triflight ever make it into iNav? For my style of flying, the tail is just fine,but it wouldn't hurt...

[wilco1967]

Hi Ikaino,

sorry to bother you again, but I think this involves TriFlight as well.

Yesterday,, a new change was made on githup changing the I2C frequency See issue 465 (increase GPIO speed) When I use that version, I get the same problem with the Baro no longer working when the compass is connected. Without the compass, the baro works just fine. This is exactly the same behavior I noticed when I tried Tri-flight a few days ago.

If I undo the changes regarding the I2C bus, both compass and baro work again.

[resokk]

@wilco1967, check pwm_mapping.c for target specific mapping (smth like #if defined(RCEXPLORERF3) - it must contains MAP_TO_SERVO_OUTPUT - it was my error before :)

[wilco1967]

Ok... found out the problem was the pull-up resistors on the external mag board,

Replaced the compass with another board I had lying around, which doesn't have pull-up resistors, and now both compass and baro work just fine together.

They also work together in Triflight.

So the problem was too many pull-up resistors.... there is 10kOhm on the F3FC, and the compass also had 10kOhm.... that was apparently too much combined....

Tomorrow I will flight test again, and see if this also does help something on ALT hold (don't think so, but we'll see...). After all, I had good values on both compass and baro with earlier I2C code.

Update: nope.... as expected.... no difference..... still the same problem

[wilco1967]

@lkaino @resokk Do any of you have a working alt hold (flight proven) using the RCExplorer F3FC board ? If so, could you please share any settings. Thanks !

I run out of option of what to try, and nothing seems to make any (positive) difference.....

[lkaino]

@wilco1967 I haven't received my M8N gps with a mag yet. It's on slow boat from China.

[wilco1967]

So is mine..... same boat perhaps ;-) So you've never flown your F3FC ? Do you know of anyone else who has a succesful alt-hold on F3FC ?

[lkaino]

Heh, probably. Many gps's fit on their big boats that sail once a month :)

I have flown it on mini and baby tris. My V3 is on naze still. About to convert it once I get the GPS. Don't know anyone. Haven't heard anyone trying inav on it. David is also waiting on his gps I think.

[wilco1967]

I've been flying my F3FC for a while now using iNav. All works fine.

Only one 'problem'.... I've run out of free serial ports..... UART1 for GPS UART2 for SmartPort telemetry (Taranis) UART3 for OSD (MWOSD)

For Bluetooth, I would have to disconnect the OSD.

As far as I can tell, it seems like softserial is not enabled in the F3FC target a.t.m. I really could use the softserial ports somehow enabled, but I have no clue on how to do that... SPort would be fine on softserial (of even fall back to Frsky telemetry) Receiver already connected as PPM, rather then SBUS to free up a serial port.

I tried to copy some parts in target.h that seemed relevant from another target.h (FuryF3)... and added softserial in the target.mk file. Also increases serial_port_count to 5. It compiled alright. It even shows softserial in the ports tab, but when activating softserial, the board freezes.... Not really a surprise I guess....

Anyone, who is better in programming, could get softserial working on F3FC, or could explain what to change ?

Thanks a lot !