Inav: Design a FC for INAV

[digitalentity]

I think it's time to think about designing a FC specifically for INAV.

Features I want to have on this FC:

1. Future-proof design with an F4 (or even F7) CPU
2. 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations
3. Onboard baro (MS5607 or BMP280)
4. Optional onboard NRF24 receiver (placeholder for a tiny daughter PCB)
5. External I2C connector (compass)
6. External SPI connector (opflow)
7. SD-card logging
8. Hybrid 4-pin connector to PWM/SBUS receiver (3.3V + 5V both available), same pin used for PPM/SerialRX
9. USB VCP
10. At least 3 extra UARTs for GPS, MSP, Telemetry
11. 5V-level LEDSTRIP connector
12. Analog inputs for RSSI, VBAT, CURR and an extra for optical rangefinder
13. Sonar connector

What do you think?

[skaman82]

13 Sonar Pads

[Linjieqiang]

Wonderful!I have always been concerned about this project.I am designing a FC board now and ready to flash inav F4 firmware,use STM32F4RGT6.I suggest why not use Can Bus Hub like Dji to connect sonar,opflow,gps,osd or even more sensors and devices?It will save hardware resources.

[DzikuVx]

What about factor? Probably keeping 30-something (30.5mm hole spacing) would be impossible. I'm fine about that, Pixhawk size would be totally fine in my case. I would even prefer that.

It would be also very nice to have SoftSerial not conflicting with RSSI and ADC

[digitalentity]

@skaman82
Done!

@Linjieqiang
I'm thinking about being able to connect a sensor hub via serial port - this way sensor hub will be usable even with older FCs without CAN. I don't want this design to be bound to one hardware only.

@DzikuVx
I'm going to keep 30.5mm hole spacing but the overall form factor is going to be larger (longer board). USB on the side, connectors on front and rear edges.
I'm not going to make SoftSerial available on this board - F4 CPUs have enough hardware UARTs.

I'll design the board in such a way that it would be possible to use all (or almost all) features at once without conflict.

[skaman82]

1+ for 30.5mm hole spacing

[DzikuVx]

I would be very happy with 5 Hardware Uarts

[digitalentity]

@DzikuVx this might be impossible. I'm going to use UART2 RX for PPM/SERIALRX input so it's going to be UARTS 1,3,4,5

[DzikuVx]

I know I am an special case here. I have OSD via MSP, another msp for telemetry, GPS, FrSky S.Port and Blackbox. All 5 possible Uarts taken on my Sprf3.
Probably will switch osd to ltm and share it with telemetry via some Small arduino to free one uart

[oleost]

Just a question.

Hardware UARTS are fine, yes. But Softserial has proved very usefull in many cases.

With an F4 cpu compared to an F3 CPU could we overcome some of the limitations?
Or with the F7 cpu?

Not a hardware developer, nor a software. Just thinking with a more powerfull CPU maybe softserial could run at 100k baudrates?

[bk79]

I would use mpu9250 to have compass with no extra wire and an integrated
bec so to avoid having a different board and all the io pin out avaiable
Il 15/giu/2016 11:52, "Konstantin Sharlaimov" [email protected] ha
scritto:

I think it's time to think about designing a FC specifically for INAV.

Features I want to have on this FC:

1. Future-proof design with an F4 (or even F7) CPU
2. 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations
3. Onboard baro (MS5607 or BMP280)
4. Optional onboard NRF24 receiver (placeholder for a tiny daughter
   PCB)
5. External I2C connector (compass)
6. External SPI connector (opflow)
7. SD-card logging
8. Hybrid 4-pin connector to PWM/SBUS receiver (3.3V + 5V both
   available), same pin used for PPM/SerialRX
9. USB VCP
10. At least 3 extra UARTs for GPS, MSP, Telemetry
11. 5V-level LEDSTRIP connector
12. Analog inputs for RSSI, VBAT, CURR and an extra for optical
    rangefinder

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287, or mute the thread
https://github.com/notifications/unsubscribe/ALSWiiyIOmZnHBD6KjQAyiFv4M03egHBks5qL8tHgaJpZM4I2LxB
.

[skaman82]

@bk79 External compass mounted far away from the wiring is always better then a internal one.

[DzikuVx]

And this is why I like the idea of no magnetometer on this board

[bk79]

As long as it is far from ac power source (escs) it's ok and unless you
have a 250 size which is intended normally for racing i can assure it
makes really little difference to have it inside or outside the fc shell if
you like i can attach the reading coming from a sparky connected to an hexa
320 and the reading coming from a cc3d connected to an 400size with ext
compass of course in hoovering conditon for both that means low currents
radiating
Il 15/giu/2016 13:07, "Paweł Spychalski" [email protected] ha
scritto:

And this is why I like the idea of no magnetometer on this board

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226156631,
or mute the thread
https://github.com/notifications/unsubscribe/ALSWiu7Jy-WNCoqjsS2oreNx3zYu8pZ-ks5qL9zngaJpZM4I2LxB
.

[bk79]

Just as addition the bigger is the angle between escs wire and compass the
higher will be the induction current from the esc wires since their
radiation field is radial to the wire and normally the wire are on the same
plane of the fc which means low mutual induction
Il 15/giu/2016 13:27, "luciano palermo" luciano.luca.[email protected] ha
scritto:

As long as it is far from ac power source (escs) it's ok and unless you
have a 250 size which is intended normally for racing i can assure it
makes really little difference to have it inside or outside the fc shell if
you like i can attach the reading coming from a sparky connected to an hexa
320 and the reading coming from a cc3d connected to an 400size with ext
compass of course in hoovering conditon for both that means low currents
radiating
Il 15/giu/2016 13:07, "Paweł Spychalski" [email protected] ha
scritto:

And this is why I like the idea of no magnetometer on this board

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226156631,
or mute the thread
https://github.com/notifications/unsubscribe/ALSWiu7Jy-WNCoqjsS2oreNx3zYu8pZ-ks5qL9zngaJpZM4I2LxB
.

[Linjieqiang]

@digitalentity oh,I see.Your idea is great.What processor chip do you want ?I just think F7 is too expensive now.What about STM32F4RGT6?I think it's ok.Anyway,look forward to your work.Oh,I have another question.Are you going to design a FC box to damp the IMU, just like place it on sponge?The photo is that I hack ZYX-M FC.For reference only.Forgive me for my bad English.Haha……

Also,if Revo Openlrs can be supported,that's more better~!But I think it lack powerful mobile GCS for IOS or Android Phone.

[digitalentity]

Vibration damping of the sensor board is a good idea but it will make the FC harder to manufacture. You can easily soft-mount the FC itself.

[bk79]

I think thata mix spracingf3 deluxe and evo with sdcard reader is a good
starting point but with f4 processor
Il 15/giu/2016 17:18, "Konstantin Sharlaimov" [email protected] ha
scritto:

Vibration damping of the sensor board is a good idea but it will make the
FC harder to manufacture. You can easily soft-mount the FC itself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226220413,
or mute the thread
https://github.com/notifications/unsubscribe/ALSWiqdryq2DdLxUgpwUqR5cfoU0f_Ozks5qMBe0gaJpZM4I2LxB
.

[dan557]

If most people are going to use a osd on one of the uarts why not build a
max chip into the FC and with a f4 or f7 processor there will be plenty of
resources to support it .
osd support is currently being added to cleanflight
On 15 Jun 2016 4:18 p.m., "Konstantin Sharlaimov" [email protected]
wrote:

Vibration damping of the sensor board is a good idea but it will make the
FC harder to manufacture. You can easily soft-mount the FC itself.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226220413,
or mute the thread
https://github.com/notifications/unsubscribe/AD8DEZ56dN177lVJ376pk9fq_1-kMEbeks5qMBe0gaJpZM4I2LxB
.

[digitalentity]

With HD systems emerging having an analog OSD is not the best idea. Also
what if one will want different OSD? If possible I'd like to avoid mixing
flight control and vision.

[DzikuVx]

I also do not like the idea of mixing FC with OSD.

[digitalentity]

What do you think, maybe make first version F3 based?

[skaman82]

@digitalentity what would be the advantage, compared with a SPracing F3 (my board of choice at the moment) - except SD Card support?

[digitalentity]

A very brief connector layout

This may even fit into square board with 30.5 mounting holes. But more likely it will be a rectangular board with regular thru-hole connectors on both sides (motors on one, RX/extras on the other)

[digitalentity]

@skaman82 for example gyro on SPI bus, direct support for SPI external hardware (optical flow), more hardware UARTs + USB for Configurator.
EDIT: And none of those crappy JST connectors

[digitalentity]

Also, what about exposing USB as through-hole connector to be able to easily move it to the outside of the aircraft?

[digitalentity]

Laying out the board is going to be one hell of a task :smiley:

[bk79]

Spi needs a dedicated pin for each device exposing one pin only means
having a dedicate connection only for the optical flow and using f3 would
loose any benefit compared to f4 since spracing pro deluxe has everything
with less than 40$
Il 15/giu/2016 20:36, "Konstantin Sharlaimov" [email protected] ha
scritto:

Laying out the board is going to be one hell of a task 😃

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226279522, or mute
the thread
https://github.com/notifications/unsubscribe/ALSWii-MJ1mlvCrDuCfZZ7RSyzm4wY6bks5qMEYSgaJpZM4I2LxB
.

[digitalentity]

We can move CAN to the side (or lose it at all) and have 3 \CS pins for SPI meaning 3 possible external devices to connect (SPI RX + OpFlow + ...)

[digitalentity]

And I agree - using an F3 chip is not a very good idea

[bk79]

F4..ok f3...still not much gain compared to other boards
Il 15/giu/2016 20:52, "Konstantin Sharlaimov" [email protected] ha
scritto:

We can move CAN to the side (or lose it at all) and have 3 \CS pins for
SPI meaning 3 possible external devices to connect (SPI RX + OpFlow + ...)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226284267,
or mute the thread
https://github.com/notifications/unsubscribe/ALSWisMTeXkkBw_pJSaUnyF07RvNR7OMks5qMEnegaJpZM4I2LxB
.

[digitalentity]

@bk79 what would you consider "much gain"?

[skaman82]

• More hardware UARTs are always nice!
• I have nothing against a F3 version if it makes the CF cheaper. I personally don't like spending more than 30$ on a FC.
• About the usb: I have to solve that problem constantly (because SPracing boards have the USB on the rear side. I just take a micro usb connector and connect it to a cheap USB breakout board. This way I can place the USB everywhere I like. It is pretty easy. If you placing the USB on the side, there is no need to have extra pins for that - they would take away some space to.

[digitalentity]

Actually STM32F303RC costs roughly the same as STM32F405RG, so it's going to be an F4 CPU after all. The problem is UART hardware inversion which F4 chips don't have.

[digitalentity]

Actually $30 price for this FC is marginal, BOM+PCB+assembly will cost ~20-30$ if produced in low quantities. What price do you think would be reasonable for this FC?

[skaman82]

I just talked about me (personally). I see people spending 40-50$ for this easily. More likely 50$

[digitalentity]

Personally I don't like spending more than $30 on an FC as well, but I don't mind prices up to $50-60 for a decent product :smile:

Actually, a dead simple board w/o baro, w/o CAN and w/o SD-card might cost even under $20. I need to do a proper design to be able to estimate BOM and assembly prices.

[skaman82]

The original SPracing F3 was to pricey as it came out (it was about 65 or 70€). That was a deal-breaker for most and that is mainly the reason why spracing boards are not so popular. It became more popular since china started to clone this FC and sell it for about 20-25 €.

[DzikuVx]

Suggestion that came to me after todays helping fellow... If 3.3v is supposed to be available on a connector, use 2 ldos. One for cpu, one for external pin. And maybe polymer fuse as well

[bk79]

@digitalentity benefit from a faster cpu are huge quaternion can be used
sdio for sdcard is there 4 usart various i2c and three spi...

Suggestion that came to me after todays helping fellow... If 3.3v is
supposed to be available on a connector, use 2 ldos. One for cpu, one for
external pin. And maybe polymer fuse as well

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-226314901, or mute
the thread
https://github.com/notifications/unsubscribe/ALSWioPa6HyHBeV9qkjVPR8BB-SUcTOWks5qMGS9gaJpZM4I2LxB
.

[rustyoz]

I would love a board with a separate 5v rail on the motor/servo outputs with pins for an external input. I have a tilt quad and using a seperate 5v bec for servos or even high voltage servos would be a plus.

[martinbudden]

My thoughts on the iNav FC.

I'm not a hardware guy, so my thoughts should be taken with that in mind.

Thoughts on the spec

1) Future-proof design with an F4 (or even F7) CPU
Leading edge, not bleeding edge, so F4 not F7. With F4 iNav can share code with Cleanflight and betaflight. With F7 it's on it's own. And F4 rather than F3 since the FC is for iNav and iNav will add more navigation calculations in future.

2) 8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations
Yes, definitely 8 outputs. 6 is not enough for many iNav uses.

3) Onboard baro (MS5607 or BMP280)
Yes.

4) Optional onboard NRF24 receiver (placeholder for a tiny daughter PCB)
Most definitely. Note that the NRF24 requires a stabilised 3.3V power supply, and behaves erroneously if the voltage drops too low, so ensure your onboard 3.3V regulator is sufficiently powered.

5) External I2C connector (compass)
Yes. And external I2C connector can be used for other devices as well. Eg sonar, optical rangefinder etc (see further comments later).

6) External SPI connector (opflow)
Yes. And external SPI connector can be used for other devices as well. Consider having more than one NSS connector available. Other SPI signals can be shared.

7) SD-card logging
Yes.

8) Hybrid 4-pin connector to PWM/SBUS receiver
Yes.

9) USB VCP
Yes.

10) At least 3 extra UARTs for GPS, MSP, Telemetry
Yes, but see later comments on UARTs.

11) 5V-level LEDSTRIP connector
Yes.

12) Analog inputs for RSSI, VBAT, CURR and an extra for optical rangefinder
Not entirely. See later comments . In brief VBAT not required if there is an onboard BEC, and optical rangefinders seem to use I2C.

13) Sonar connector
Yes.

It seems optical rangefinders use I2C. Both the teraranger and the lidar-lite can connect via I2C. (Now that Garmin has bought PulsedLight, it's unclear whether the Lidar-Lite will continue to be available though)

OSD has been mentioned in the thread. My view is that the "natural" place to integrate the OSD is in the VTX, not on the flight controller.

Sensors

Gyro should connect over SPI, not I2C

Consider using Invensense's temperature stabilised gyro the mod-1600

I believe this is used on the pixracer.

If you don't use the mod-1600 my preference is to use the MPU-9250 with built-in compass but have the option to add an expernal compass.

Thoughts on serial ports

While I think currently you need to maximise the number of serial ports, I think in future this will be less important.

We are already seeing devices that used to be connected via serial ports using different options:

Team Black Sheep's BST(Black Sheep Telemetry) uses I2C rather than serial. I think we will increasingly see I2C used for telemetry.

We are seeing begining to see OSDs connected via SPI, and VTXs with integrated OSD.

Once the ESP32 becomes widely available I think we will see Bluetooth devices connected over I2C.

Unfortunately most GPS devices seem to connect over serial, but hopefully we will start to see GPS devices connect using I2C.

So serial ports will become less and less important. Unfortunately we still need them now. (My personal opinion is that they are a 1980s technology and I will be glad to see them go.)

Hardware and connectors

Definitely use the standard 30.5mm hole spacing. And I think you should try as hard as possible to keep the 36x36mm square form factor.

I'm not sure how many layers you are planning on using. 2-layer boards are cheaper. As I said, I'm not a hardware guy, but I do know that having a ground plane on the board "is a good thing". This would seem to preclude the use of a 2-layer board.

As far as possible use through-board connectors, not plated on connectors (like those on the NAZE rev5 and previous).

I think the micro-JST connectors as used on (eg) the CC3D are too small, so consider using the JST GH connectors which are part of the dronecode connectors standard and are used on the pixracer.

The exception being the Serial RX connector, which seems to have standardised on micro-JST.

PWM connector

Traditionally flight controllers used 3-pin connectors for PWM, eg:

VVVVVVVV
GGGGGGGG

I think this is unnecessary and wastes board space. I prefer just one connector for each PWM output, eg:

Admittedly this makes the connection of servos slightly more difficult - they cannot just be plugged directly in, but I think the tradeoff is worth it.

My further suggestions

Some of these may be slightly controversial.

One of my motivations for developing Cleanflight/iNav/betaflight software is to make the hobby more widely available. Partly by (hopefully) making the software better and easier to use, but also by making the software support cheaper and more widely avaiable hardware (that was a prime motivation for doing the NRF24 work).

One way of reducing cost is the by the use of brushed motors. Brushed motors are cheaper and don't need ESCs and so can result in considerable cost savings.

For people on a budget (and I'm especially thinking about teenagers) we should support the use of brushed motors directly. And even for people not on a budget, having a spare cheap quadcopter for practice or to take on holiday is useful.

This means having at least 4 FET-buffered PWM outputs on the board.

This is not unprecedented. The SPARKY 2 flight controller has 4 buffered PWM outputs that can be used to directly drive brushed motors.

The KISS flight controller has buffered PWM outputs, although in this case I think they are for performance reasons (and KISS know a little bit about performace).

The AlienFlight F3 brushed-octo FC uses 4 dual-channel MOSFETs for its PWM outputs (it uses Dual N-Channel Fairchild FDMB3900AN MOSFET) so 4 PWM outputs could be buffered on the iNav FC using just two of these dual-channel FETs - that should not take up much board space.

Personally I'd be in favour of buffering all eight PWM outputs. I think buffering the PWM outputs may bring other advantages - performance and the ability to drive high power servos.

Here's what I'm thinking: someone could buy a cheap brushed-motor quadcopter, say a Syma X5 or X8, or a Kai Deng K70. They could then replace the original flight controller with an iNav FC, add an NRF24 daughterboard and a GPS unit and they have a very cheap quadcopter that supports navigation. They could probably even use the transmitter that came with the quadcopter presuming it's protocol was supported, so they wouldn't even need to buy a transmitter.

Brushed motors are pretty well universal on sub-120mm copters, and I quite like the idea of a navigable small copter like that as well. [And for those of you who haven't build a brushed quad - their perfomance can be surprisingly good and the flight fast and agile.]

Onboard BEC

I'd like to have an onboard BEC. This is just so much more convenient. BEC only needs to support 2S-4S. For a 5S or 6S aircraft the FC can be powered from the balance lead.

[As an aside, I generally wire my quads that way - power the FC from the balance lead, power the ESCs from the XT60 connector. That way you can power up the FC without powering up the ESCs. That means you can do some setup operations safely without removing the props. It also reduces (slightly) the electrical noise from the ESCs to the FC. Not my idea - I first saw it on the setup pages for the Brain FC.]

The onboard BEC also makes it easier to support brushed quads. (Note, no 3.7V to 5V boost is required. The way to support 3.7V brushed motors is to use a 2S battery (or two 1S batteries), and power the FC from both cells, and then use the one cell to power (say) the front two motors and the other cell to power the back two motors.)

Digital outputs

I'd also like to see a couple of digital output pins (ie ON/OFF, not PWM). These could be used, for example, switch on LEDs if an LEDstrip was not being used, or to control a camera. These are on my "nice to have" rather than "essential" list.

[DzikuVx]

My note on Martin's suggestions:

1. Build in BEC: those things when with proper max. load tends to be big and heavy. And costly. And if it burns, one would have to usually throw whole board away. Instead I like the idea of separate power line with a jumper that might allow to use high voltage servos
2. PWM outputs with MOSFETs to brushless motors: hmm... again, not a biggest fan in this case. While I'm totally fine with another FC with brushed support and without fancy stuff like SPI,CAN or even most of UARTs, putting all possible features on one board will make this big and costly. The biggest advantage of INAV is GPS. And somehow it's hard to imagine brushed motors carrying those
3. Digital outputs: nice, too bad software is not ready for them yet. And to be useful, they would require MOSFETs
4. PWM Connectors: I would stick with traditional ones because of servos

[martinbudden]

@DzikuVx

1. I've seen from @digitalentity 's comments elsewhere that he is not in favour of a built-in BEC, so I'm probably onto a loser there :-) However, for the record, I don't agree with your big and heavy comment - this may have been true in the past, but there have been developments in BECs. A number of "small" FCs include BECs - these include the KISSFC and the LUX (which are both sub-36mm size - in that they are 36mm boards with the sides cut out). And the tiny FPV-PIKOBLX (which has 20mm mounting hole spacing) has a built-in 2A 5V BEC.
2. I find it very easy to imagine brushed-motor quads carrying GPS. The Syma X8 is a very popular 330mm brushed motor quadcopter and I bet loads of owners would love to upgrade to GPS. The iNav FC could allow them to do so, and with the NRF24 daughterboard they would not even need to buy a new transmitter. Depending on the iNav FC cost they could have a GPS enabled quadcopter with transmitter and camera for about £100. (Admittedly the transmitter and camera are both a bit rubbish, but those could be upgraded if required.) Rather than a priori dismiss the addition of FETs, I think we should let @digitalentity do a BOM and rough board layout - if they are too costly or there is not room, then fair enough - but let's not pre-judge the result.
3. Digital outputs "too bad software is not ready for them yet" - well that is something I can change :-)
4. PWM connectors. I think I have a solution that works for both of us, see below.

Possible option for PWM connectors

One of the interesting aspects of the SPRacing Mini flight controller is the addition of "fault lines" on the PCB, so that parts of the PCB that are not required can be snapped off. This could be used on the iNav FC for the PWM connectors, e.g.:

fault line ____GV12345678___ fault line
                 VVVVVVVV
                 GGGGGGGG

That way users who did not require the extra two rows could just snap them off.

The extra two rows could be outside the 36mm square size, so that snapping them off produced a 36mm square board.

[sppnk]

And..what about an on-board OSD chip? The OSD tasks probably could be done by the main processor and the design still would be compact.

Then we would need also the conectors for camera and vtx (3.wire servo conectors, or may be 4-wire connectors, including audio).

[DzikuVx]

@martinbudden

• Nice FC you have found there. Nice step-down incorporated design. Too bad BEC is taking almost a quarter of one side (not counting pins). I have 2A "small" BEC in one of my drones, but even this small one is kind of "biggish" in terms of 36mm and somehow I would be afraid to really 2A from it
  And since there will be a lot of pins in this FC, 36x36 might be just too small.
• I like faultline solution. With fault line board can be bigger than 36x36 in total. That might work.
• Digital outputs... Hmm... If they were MOSFETed and accept 500mA load that would be awesome.... With proper software support of course

[digitalentity]

FET-buffered PWM outputs:
If I have space on the board I might add FETs to buffer PWM outputs to allow brushless motors. If it will be possible I'll buffer all 8 of them. The problem here is BLHeli passthrough - buffering is going to kill it.

Sensors:
No I2C. Gyros will be SPI-bus. MOD-1600 looks promising. I'll try to get a sample and design a board to use it.

PWM connectors:
There are lots of tiny FCs and this is not going to be one of them. As we target also airplane flyers there will be no compromises - each servo/motor is going to be a 3-pin header connector. I might try a "fault line" solution though.

OSD:
I don't like all-in-one solutions. THe most logical place for OSD is VTX (or camera).

Onboard BEC:
As a replacable daughterboard - it's possible, but not as a built-in option. BECs burn out and I'll hate to replace the whole FC. Also, I like specialised solutions - dedicated BEC will handle higher loads, will be easier to replace and will reduce cost for those who don't need it.
I might add a 2-4S BEC to power FC from VBAT directly but this will be an option to power FC only, no servos, no external devices.

Digital outputs:
And your whish shall be granted :smile:

[martinbudden]

I'm OK with the decision not to have a BEC. I'd certainly rather the board space was devoted to FETs. I don't think it's really worth it to have a small BEC just to power the FC.

I'm not familiar with the BLHeli passthrough code - why does buffering cause a problem?

[digitalentity]

It's not the code, it's the hardware. BLHeli requires a bidirectional link
between FC and ESC. Mosfet buffer is uni-directional in nature. If I won't
be able to make a hardware solution it's going to be either passthrough or
buffers.

[martinbudden]

I see. If you can't make a hardware solution for BLHeli, then I suggest the best option is to buffer 4 of the 8 outputs. That way brushless quads can use BLHeli passthrough, and brushed quads are also supported. The downside is no BLHeli passthrough for hexacopters or octocopters, and brushed hexacopters and octocopters need to add additional FETs. But I think that is a reasonable compromise.

[iforce2d]

Absolute must:

• USB
• blackbox capable
• 3 hardware UARTS
• I2C
• buzzer
• vbat
• 8 outputs

Really would like

• SPI (one is enough, maybe use configurator to specify some other pin as second device SS pin, like we do for softserial now)
• 8 inputs

Don't care

• CPU type (although 3 hardware UARTs implies F3 or above)
• onboard baro
• 30.5mm spaced mounting holes
• size larger than 36mm square
• led strip stuff
• RSSI
• curr
• sonar

Prefer not to have

• onboard mag
• OSD stuff
• brushed motor stuff

Really don't want

• those little plastic plug connectors.... yuk

The main thing is to have lots of connection options, that way other parts can be added as needed and the cost can be kept reasonable. Most people will not be using iNav on a little mini-quad, so I would think the wriring space needed to add, for example, a separate OSD or whatever will usually not be an issue.

[oleost]

Regarding the positive on servo/motor outputs it would be nice with just and simple jumper solution or two solder pads one needs to bridge to get it connected with the rest of the FC.

So one could power servo independently from the FC.

[digitalentity]

That's exactly what I'm going to do

[kronosol]

Hey some thoughts here,.. @digitalentity
A nice thing to have would be a onboard bluetooth module or something like that, instead of an internal MAG. It makes no sense to put a MAG on the FC board anymore as you will get much better results with an external MAG. (NEO-M8N/beginner Questions about toiletbowling..). For the case of setup a MAG on the FC, PLEASE! find a solution to switch off that MAG, like the way they did it on Naze32 REV6 with a litte line you have to cut.
Also the same for the baro,.. and in case of setup a internal baro, please put it on the bottom side, so it is covered from sunlight and foam will not block the LED´s.
SD-Card holder just takes to much space,.. In my opinion a memory chip will be just enough? I just need a Blackbox log with a max length of 30min. Just let the code override the memory all the time, so at a failsafe/crash case you can see what happened. You really don´t need the logs of the last 3 months on your quad,..
To create a successful FC we should keep it as simple and tough as possible!
(In my mind..)
You need a GPS/MAG? Plug it in!
Your wiring is messy and USB is hidden? Use bluetooth!
You crashed? Look at the latest Blackbox Log files!
You´re sick on GPS flight assistance? Ok, Inav-FC is even light and simple enough for Racer Frames.
(...)
Btw: The final price should be max of 50€.
Btw2: Even I like the layout of the Openpilot CC3D Mini with these JST-Connectors, we should focus on established connections :)

[digitalentity]

Acc/gypo chip: MPU9250 via SPI bus. Compass built-in but can be disabled in software

Back side of standard 36x36 board is very tight. I think it's going to be either SD-card or nRF24 daughterboard. Round-robin writing is not possible with supported blackbox architecture and SDCard give us more options - like storing missions.

[iforce2d]

What exactly does a nRF24 daughter board look like? As a regular user of the nRF24, I think it's good enough if there is an easy to access SPI header. Depending on the form factor of the nRF module, I often want to mount it differently.

[digitalentity]

You'll have SPI header on new FC.

[martinbudden]

@digitalentity @iforce2d , I concur: SPI header is sufficient for nRF24, in fact it allows the user to choose their own nRF24 module. A 3.3V output pin is also required, and preferably this should be right next to the SPI header.

[krzysztofmatula]

8 outputs supporting 8/0, 6/2, 2/6 motor/servo configurations

To control gimbals up to 4 servo/forward PWM outputs could be useful (pan, tilt, gimbal mode, video switcher). So, 4+4 setup, or even 6+4 (or 8+2) option would be nice (not necessarily available on pin headers, maybe just some soldering pads for the additional 2?)

Is it technically possible on the chips being considered?

I vote for the SD card slot.
On board compass - ok, but allow it to be disabled in software.
USB slot on the side - yes.

[DzikuVx]

@krzysztofmatula motor/servo is a delicate issue. From the code point of view it's a huge mess. But I concur that 4/4 would be very useful.
You might want to take a look at #261 . With additional hardware PCA9685 (~ $4) and this change it will be possible to run up to 16 servos via external driver. So, airplane (5 servos) with gimbal and PPM decoder? Why not... On almost any flight controller

[csarka]

These are all great thoughts. I think we're going to end up with something great!

My two-cents worth:
In the $40-$50 range is worth it.
I agree with iforce2d (please don't use those little plastic plug connectors). All connections should be 0.1in standard through hole for solder pins.
It should have the standard square 30.5mm spaced mounting holes, however it's ok if the board sticks out further.
The possibility to mount the USB connection externally is a nice idea.

For skipping boot sequence (when we mess it up, haha) what about a surface-mounted button, or at least wired to the standard 0.1in pins. (No tiny solder pads.)

[digitalentity]

An update on FC progress.
I've started to sketch a board and ended up with 56x36 footprint (30.5 mounting hole pattern).

Features so far:

1. STMF405RGT6
2. 10 motor/servo outputs with possibility of 8+2 / 6+2 / 4+6 / 2+8 motor+servo mapping possible. All outputs will be buffered (optional) for robust ESC/servo signal connectivity, buffers will be bi-directional and won't break ESC passthrough. Optionally outputs can be level-shifted to 5V for even more robustness.
3. Motor outputs will be grouped to 3 groups (2 + 4 + 4) each of the groups will have an option to connect power separately or have no power at all.
4. LED STRIP and SONAR trigger would be level-shifted to 5V as well. No more hassle with diode to drop power to RGB LEDs
5. 3 SPI buses (gyro, SDcard, external). External SPI will have 3 /CS lines for external devices
6. I2C bus for external/internal device connectivity
7. 3 ADC inputs (RSSI, VBAT, CURR)
8. Native USB VCP (+extra header to break out USB connector)
9. 4 UARTs available for bi-directional communication (UARTs 1,3,4,5)
10. 1-pin PPM/SerialRX connectivity (UART2)
11. BMP280 or MS5611 baro on botom of the board (there will be place for both)
12. Push-button for BOOT mode
13. All connections done with standard 2.54 thru-hole headers.

The above connectivity took all 64 pins on STMF405RGT6 chip. It will be one hell of a work to fit everything on a cheap 2-layer PCB.

The described features might change when I get to actual PCB design and layout due to space or routing issues.

[digitalentity]

FC will have to have MPU9250 gyro (built-in compass with possibility to disable it in software).
Final price will likely be close to $40-50 for full-featured board.

With 8 servo outputs we'll be able to build very flexible airplane setups.

[oleost]

@digitalentity Does not the MPU9250 have the same issues as MPU6500 regarding vibrations?

[martinbudden]

@oleost , what are the issues the MPU6500 has regarding vibrations?

[oleost]

@martinbudden

http://raceflightinfo.com/2016/06/06/mpu6500-vibration-sensitivity-causes-quad-twitching/
http://www.rcgroups.com/forums/showpost.php?p=34649949&postcount=5537

So it can be "fixed" using vibration dampening mount, but then again I guess there would be still better result with and MPU6050 on same dampened mount as MPU6500

[martinbudden]

See also betaflight issue https://github.com/betaflight/betaflight/issues/322 for discussion.

Personally, I don't think this will necessarily be a problem for iNav, since it is targeting different uses.

[digitalentity]

I might just put MPU6500 on a separate daughter board and vibration-dampen it

[npsm]

I just came across this discussion and like to share that I already designed a board, the pcb (4-layer) is on production, components are ordered and I'm currently working on fw support. As it is an F7 the HAL driver need to be used as std drivers aren't available. You can find this work in my fork dev_f7_support branch.

Some details about the fc board,

• dimensions 36*50mm, mounting holes 30.5x30.5mm
• STM32F745 1MB flash 216MHz 340k ram. Once available from distributor upgrade to STM32F767 with double precision floating point unit 2MB flash and 512kb ram.
• 100 pin package so lots of IO
• 5x uart, all with buildin inverters on TX and RX, one with 3v3/5V select.
• 3x I2C, one of the ports can be used for sonar
• 1x CAN
• 1x external SPI
• microSD slot
• MPU9250 SPI (module GY-9250)
• BMP280 I2C (module GY-BM280)
• 6 dedicated input
• 8 dedicated output
• dedicated pins for: ledstrip, buzzer, IR transponder
• 3A BEC (module)
• voltage, current, RSSI, and spare analog in/out
• buttons for boot and reset

Renders of the board, I did't bother with adding all the 3D models so some are missing.
The GY-9250 module is intended to be stacked on top and the GY-BM280 on the bottom side. Both are modules so they can be updated changed and these componets are hard to solder. Maybe once prototyping stage is over the BMP280 can be mounted on board.

[martinbudden]

@npsm , that's a nice looking board. Can you add a link to your dev_f7_support branch?

[npsm]

@martinbudden , Thanks.
A link for the branch: https://github.com/npsm/inav/tree/dev_F7_support
Any feedback is welcome. Suggestion on how to proceed as well, as my intend is to merge later on with the main branch.
First driver I started on was the uart, I've tried to remove as much device/target specific code and moved them. I place mcu specific stuff in target/portable.h and target specific stuff in target.h(.c).

Is there better place to discuss the sw architecture?

[martinbudden]

Much as I'd like to help, I've got my hands full at the moment. So I'll watch your progress with interest, but I'm afraid I won't be able to contribute. The F4 port of iNav should make your F7 port easier.

[jflyper]

A couple of comments.

Hardware UARTS:

• If the use case permits certain latency, then I2C/SPI-to-UART expander such as NXP's SC16IS7xx family can be used. I have a semi-working driver for these chips. Having these chips on the external bus would help transitions from the half-century old technology to the current ones (as mentioned by @martinbudden ).

External I2C / SPI:

• Should have at least one line for IRQ, a couple if possible. Optional RESET line would be a gift.
• The 3 lines for CS in the current draft by @digitalentity is great; they can even be expanded into 7 CS lines at the receiving end.
• A provision for an I2C repeater would be a great addition that protects people and the bus from variety of external interferences that messes up the arbitration. May be accomplished with a small fan-out-BOB, so the priority is low.

Bus and DMA scheduling:

• Would be nice if multiple devices will use relatively slow bus (i.e. I2C). May become a challenge if try to do it correctly.
• [EDIT] #261 mentions bandwidth spreading on I2C.

FET-buffered PWM outputs:

• MOSFET can be used as bi-directional buffer / level translator if signal is active low. I'm not familiar with ESC signaling, though.

SDCards:

• +1 with @kronosol . It is also a bit of a challenge to keep the card from popping out of the holder on crashes while it is written data from the most critical moment.

[oleost]

How much more would choosing an F7 CPU over an F4 CPU add to the cost?

Looks like Raceflight is working on a F7 controller and speaks highly of it.
And guessing the better we can get basic flying to be, the more rock solid the GPS mode will become.

And are there other benefits going for F7, like more uarts/softserial, better handling of i2c devices etc?

[digitalentity]

@oleost STM32F7 chips are only available at >100 pin packages.
STM32F745VGT6 (LQFP-100) - $12.90
STM32F405RGT6 (LQFP-64) - $9.72

Price difference is not that big, it's space that I'm concerned about. I don't want to use those JST connectors - IMO they are total crap. INAV_FC is going to have only thru-hole connectors and it will be close to impossible to put 100-pin CPU, a bunch of connectors and companion chips on a small 2-layer board.

[digitalentity]

All,
What do you think about having a daughterboard with sensors (like @npsm did in his FC)? This will make design easier and probably cheaper.

[DzikuVx]

I'm not so sure about additional board with sensors cheaper. You pay for square inch of pcb. And additional board would add area overhead for connectors and extra cost of connectors or additional soldering if no connectors.

[digitalentity]

I can source MPU9250 boards for <4.7$, while the individual chips are only
available for >5-6$. I also save a few cents on a 3.3V regulator. Price
difference is not big, but it makes design considerably simpler and easier
to assemble.

[jflyper]

@digitalentity I'm not sure about the cost, too, but think it's a natural approach for a sensor/actuator rich system. And if designed properly, users will have options, e.g., a daughter board loaded with sensors, another daughter board just acting as sensor hub/bus driver, and so on.

[jflyper]

@npsm BTW, overhanging part of your F7 board makes me wonder how vibrations work on contacts of connectors, and also the overhang line; there is a row of through holes that makes this line weaker.

[martinbudden]

@digitalentity , I don't really have a preference about a daughterboard with sensors.

I would, however, like you to keep the 3.3V regulator and route it to a connector. 3.3V is useful for anything connected to the FC, in particular I am thinking about an NRF24 board, but other things also require 3.3V.

[npsm]

@digitalentity I had the same reasons for using the gy-9250 module, they are more expensive without a board than with one and free components. The MEMS components are difficult to assemble without damaging them, they are extremely sensitive to excessive heat.

@jflyper The overhanging bit is/was a concern, but I think it was the best compromise to keep the 30.5x30.5 mounting holes for compatibility. PCB at 1.6mm is pretty strong and is the total board is quite small I don't expect problems with stiffness or breaking the board. The line of though-holes between the 2 bottom mounting holes is for an gy-9250 sensor board which will be solder on both sides so no connectors, this should give a solid connection.

One of the benefits of the separate board, besides the possibility for manual prototype assembly, is that it comes with a 'free' additional LDO to supply a clean power to the sensor. There is another 3v3 LDO on the main board for MCU and on 2 connector.

About jst vs through-hole, I like both. For all criritcal stuff I prefer through-hole, motors, rx for the other I don't really care, jst is a lot smaller but through-hole is more robust. I have chosen to use both for these reasons, it nearly impossible to get as much connection options on a board this size with only through-hole, there simply isn't enough space. Most setup can be done without using any jst.

In my opinion a board should be 4 layer for the simple reason that PCB's are cheap as hell.
My board 2.7 square inch, 7usd a piece 4-layer 3,5usd 2-layer this is for prototypes at OSHpark. I'm not bothered with 3,5usd extra considering the 20~25usd BOM.
I you would scale up to production (I'am not sure about this) PCB cost become completely irrelevant. From past expereince 0.30usd sq-inch 2 layer 0.45usd 4-layer. At larger volume the would make a total price difference of 0.40usd not worth the effort and compromising quality.
Good grounding will be extremely challenging with a 2 layer board even when sticking to smaller mcu packages. At lager volume BOM, assembly and test are 95% of the total costs. Even packaging is more expensive than the pcb itself.

btw, I designed this board for myself so I'm not trying to sell anything here. Saying this, with enough interest (and help) we could run a production one all the bugs are fixed.

[csarka]

I think it would be best to keep it all on one board. No daughter boards.

[kronosol]

Hey, a daughterboard would be ok for me. Have a look at the TBS Cube, (Imagine only 2 chips).
It isn´t so much thicker as a normal FC. Of couse in these Pictures there is a PCB/ESC´s etc..
but i´m talking abut the key design! I think the max size of a FC would be around a Cube with 3cm length each side.
TBSCube 1
TBSCube 2
TBSCube 3

[digitalentity]

All,
I'm already laying out everything on one board. With carefully chosen chip placing it's not that hard. I might even get away with 2-layer board and 0603 size components for DIY assembly.

[oleost]

@digitalentity have you thought about adding Pixhawk/APM connectors on one of the uarts and sda/scl lines since 90% of the GPS devices out there at those connections?

[martinbudden]

@digitalentity , any provisional drawings/schematics available? Just for curiosity's sake.

[jflyper]

@martinbudden

I would, however, like you to keep the 3.3V regulator and route it to a connector. 3.3V is useful for anything connected to the FC, in particular I am thinking about an NRF24 board, but other things also require 3.3V.

My thoughts on the power supply voltage to daughter board wonders from time to time. I hate 5V feeds on the day I have to look for an LDO in my parts box for 3V3 sensors. Next day, however, I'm placing curses on whoever fed 3V3 when I need 5V, looking for a more scarce step up converter in my parts box and trying to recall the efficiency of step up converters.

[martinbudden]

@jflyper , I'm not talking about the power supply to the daughter board. What I am requesting is that there is a 3.3V regulator on the main board and its output goes to a through-hole connector so that it can be easily used.

I'm not too concerned about how the daughterboard, if there is one, is wired up.

[jflyper]

@martinbudden My thoughts apply to through-hole connectors, too!

An example is 5V available for most UART & I2C connectors: sometimes I love them, sometimes I hate them.

Oh, I almost forgot to mention another point. I would like to see those power supplies available, or at least jumper selectable, even when the FC is not powered by LiPo.

[martinbudden]

Well, I do agree with the sentiment that, whatever you have, you seem to need the other one.

[Linjieqiang]

Hey,Gays.What about this?

[digitalentity]

How about this:

• 10 motors
• Sonar Trig/Echo
• 3 ADC inputs
• SD Card
• SPI Gyro
• External SPI with 3 CD# lines
• I2C
• LED STRIP
• 4 HW UARTS
• PPM/SerialRX Input

[digitalentity]

Oops, forgot that F4 doesn't have the inverter. So one SPI CS# line will have to go

[jflyper]

That leave us with 3 external SPI devices. What about the shared IRQ line for external I2C/SPI devices?

[digitalentity]

@jflyper do you need more than 3 external SPI?
We don't have have IRQ for external devices, only for onboard ones.
We can probably make sonar sharted with M9/M10 pins. This allows us to have 2 more free lines.

[digitalentity]

All of the motor outputs are buffered with bi-directional 5V buffers so we'll be able to connect sonar to some motor outputs no problem.

[martinbudden]

Yes, share the sonar with M9/M10. This is especially true since I2C sonar is now supported.

[digitalentity]

Ok, this makes things simpler and cheaper. A few less components, few cents saved on BOM and assembly :smile:

[Linjieqiang]

Better than me~！Thanks

[jflyper]

@digitalentity No concrete plan for external devices, either SPI or I2C; just dreamed of "future proof". Personally, I'm looking at SPI/I2C-UART and PWM expanders for Serial and Servo maniacs, SPI-CAN and such. An SPI-GPIO expander for external IRQ multiplexing may be another addition.

Here's what I'm working on :)

You can poll a couple of devices on SPI/I2C buses, but with whole bunch of them at high rates, buses gonna get already congested by the polling traffic (especially on rather slow I2C).

[digitalentity]

Actually, we can share M9/M10 pins between:

• Motors/servos
• Sonar Trig/Echo pins
• CAN

Starts to look cool :smile:

[martinbudden]

Yes, the early discussion mentioned CAN, but I assumed it was dropped due to lack of space or pins. It's good to get it back. Even if I'm not sure what we'll use it for, yet. Build it and they will come.

[jflyper]

@digitalentity Ah, I knew there is CAN somewhere, because Sparky 2 explicitly exposes them; so there they are! I instantly imagined a micro daughter board with CAN transceiver that solders onto M9,M10,GND and 5V! (So you don't have to worry about dominant and re,re,res-something.)

[jflyper]

Sparky 2' CAN is obviously intended for BGC connection; any other use cases?

[kronosol]

Hey, as Inav is focused on GPS assisted flight modes, it may would be useful to have an extra connection for a GPS status LED which is easy to connect. Example
So if GPS is fixed the LED should just light all the time, if error it should blink.
The tiny LED's on FC and GPS aren't very useful for checking the GPS fix in flight.

[Linjieqiang]

think about adding UWB to support Indoor positioning.Please see : https://www.bitcraze.io/2016/05/loco-positioning-is-coming-soon/ https://www.bitcraze.io/2016/06/bitcraze-in-china-for-loco-positioning-production/

[tannewt]

Thats super interesting! Looks like this Kickstarter is using the same chip too: https://www.pozyx.io/

They are expensive though! $25 in singles from Digi-Key: http://www.digikey.com/product-detail/en/decawave-limited/DWM1000/1479-1002-1-ND/4805335

[digitalentity]

This is super interesting! I wonder if we can have it natively supported by
INAV?

[Linjieqiang]

I think it can be supported by INAV~!

[oleost]

Seeing they write you need 6 transmitters in the room, and a receiver on
the aircraft this is very limited usage for the average person. Just the
price alone for a complete set would be expensive.

Think the way to go is the way you already experimented with @Digitalentity
(optical sensor looking at the ground.)

1. jul. 2016 09.52 skrev "Konstantin Sharlaimov" <[email protected]

:

This is super interesting! I wonder if we can have it natively supported by
INAV?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-232886654,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFaHNogVp-i37MDDHc7FHqCmmMVGuNhEks5qVzxTgaJpZM4I2LxB
.

[jflyper]

CAT IIIc ILS for UAVs. No more crash landing.

[marelab]

What about to split the board up and make it stackable. Even with more serial ports, nice SPI extension and all the other fine details, it always comes to a point where something is missing or is to much. Splitting up the board with a base with core CPU & gyro all other Interfaces with stackable extension, even the connector design can be changed easy without the need for a complete new board. Backside thats much more work for a good design, I see a huge benefit that it can be tailored and who knows what comes up the next. I think that would be a real unique compared to the monolithic blocks we have today, keeps the freedom to fast change to a new CPU or new Sensors. I think the extra weight of conectors and pcb doesn't hurt to much for the freedom to add new chips & designs quite fast. I would always choose a modular hardware if one would be available. But anyway even the features that where discussed for a monolithic FC are great and just having more serial ports without share & disconnecting would be great and 50$ worth and having external SPI would allow to use a SPI bluetooth adapter freeing one more port.

[tannewt]

@marelab I'm launching an open source, stackable FC this week. Sign up for the announcement at https://chickadee.tech. @digitalentity already has one on the way to him.

I'll also be launching an Active Contributor Discount to give discounts (10% - 20%) to iNav and Betaflight devs. So, subscribe above and I'll launch as soon as I get the product photos done.

[tannewt]

Joshua Bardwell has an overview of Polystack, my modular flight controller, even though the site isn't live yet.

https://www.youtube.com/watch?v=CiPcDuNA0oM

[digitalentity]

@tannewt, your PolyStack looks promising, can't wait to get my hands on it. It's support will be scheduled for 1.3 as we need new IO first.

[tannewt]

@digitalentity that sounds great! You should have them by then. Theres no barometer and magnetometer mod yet anyway.

[martinbudden]

I'm about halfway through doing the new IO, see issue https://github.com/iNavFlight/inav/issues/338 , hope to do another chunk later today.

[tannewt]

You rock Martin! You are the highest score I found for my Active
Contributor Discount. Let me know if you want Polystack boards.

On Fri, Jul 22, 2016 at 11:02 PM Martin Budden [email protected]
wrote:

I'm about halfway through doing the new IO, see issue #338
https://github.com/iNavFlight/inav/issues/338 , hope to do another
chunk later today.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/287#issuecomment-234701663,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADNqU_46gVxFKZb-Sm_gZ1kqncuT9PMks5qYa5hgaJpZM4I2LxB
.

[martinbudden]

@tannewt , glad to know I score highly. Yes, I'm interested in getting a polystack board - they are a natural to use for development.

[tannewt]

@martinbudden Polystack is now available at https://chickadee.tech/!

Check your contributor score here and get your discount code: https://chickadee.tech/active-contributor

[digitalentity]

@tannewt great news!

[jflyper]

@tannewt I had a strange feeling that I was missing something important when I first saw the joshua's preview clip, but now I now what that is: a prototyping board that breaks out the bus connector signals! It will open up another new perspective in UAV electronics design and development.

[digitalentity]

While we are working towards an own FC and F4 support, I have a Pixracer on the way to me. INAV is coming to PixHawk :smile:

[tannewt]

@jflyper Like this? https://chickadee.tech/product/dbg

@digitalentity Awesome!

[jflyper]

@tannewt Gotcha!!! I also found this: https://chickadee.tech/product/g-test-bot and https://chickadee.tech/product/g-test-top. Not much detail though. Pics?

[tannewt]

@jflyper My copies of the production boards are stuck in the mail so pics will come once I get those. They are meant for testing boards before being sent out which isn't what you want. I show it and the test jig top here: https://youtu.be/B1DvmnBeOzM?t=4m48s

[Linjieqiang]

DJI company is using IST8310 chip on their drone now.So I think @digitalentity you can have a try to design FC board with this chip?The noise with AKM8963 will be bigger than IST8310 if you use MPU9250 chip.

[csarka]

I agree, MPU9250 is too noisy. I don't like it.

[digitalentity]

@Linjieqiang, @csarka
I don't want to put compass on the board at all. With MPU9250 it comes "free", without occupying extra space on the board (which is already very limited).

[csarka]

I'm sorry, I should have been more specific. I was referring to the MPU6500 gyro packaged in the MPU9250. Many people (including myself) have had lots of trouble with the over sensitivity to vibrational noise of The MPU-6500 and MPU-9250. (Search google for MPU6500 vibrations" and you'll see what I mean.)
See also https://github.com/betaflight/betaflight/issues/322

[Linjieqiang]

What progress is it now?

[myvilli]

Hi all,

I just want to give you my 2cts opinion : I think that all builders, of quadcopters, or airplanes, own and use a soldering iron.
In my case, i try to solder all the wires directly to the board, so I have no bad connections, neither jst xh or jst, and dupont cabe mixed up.

Something interesting would be that the board have all output and inputs accessible with pads.

Next thing I wanted to coment, is about the LDO and voltage regulators : they convert the over voltage into heat, wich is not really battery friendly, and makes the board over heating.
Those LDOs have also small current outputs.
I would advise using module or power chip based on MP23070.
The downside is it is using more room.

Hope it was helpful.
Regards,

[digitalentity]

I'll better concentrate on making robust firmware for the boards already out there

[Linjieqiang]

My board was out.I will push my target support code to this repertory.

[digitalentity]

Looks good. Does it have external I2C or possibility to disable onboard compass?

[Linjieqiang]

Yeah.It have external I2C and you can remove onboard compass chip.

[digitalentity]

It would be better to have a possibility to disable onboard compass by a solder-jumper or something like that. Removing the whole chips is not a very user-friendly solution.

[Linjieqiang]

But you can identified the chip id by iic.

[digitalentity]

Which compass chips are you using?

[Linjieqiang]

@digitalentity IST-8310.So first step is that I will add ist-8310 device code.

[digitalentity]

Ok, great. So it will be compatible to most GPS modules on the market. Cool.

[Linjieqiang]

Yeah.

[Linjieqiang]

I am preparing the code and pushing to this later.

[skaman82]

@Linjieqiang great, really would like to put your board in my new 450 build with inav.

[Linjieqiang]

@skaman82 Thanks.

[Linjieqiang]

@skaman82 I am making a PR on this about my board. https://github.com/iNavFlight/inav/pull/919

[adtinnis]

I have a Pixracer and have been trying both the PX4 stack and the Ardupilot stack using QGroundControl to configure it. The flight controller seems almost perfect for me. I know a lot of people like to direct solder, but I prefer plugs. It has plenty of UARTS and can support direct connection of SBUS and FrSky S-Port telemetry. I have it in a 280 class frame with GPS and external MAG. The problem I have is with the software. It is ok to configure, but then tuning is tricky. Reading through this dialog, I am surprised that there isn't more interest in the board.

I guess the two sides that I can see are 1) no built in OSD and 2) price. In the UK the cost is 50 pounds from a UK supplier, with cables, but no WIFI module. That can be bought from the UK off e-bay for less than 10 pounds.

Basically, what I can saying is; why not develop the Pixracer as a top tier target with full support including the WIFI full UART complement.