@brad112358 guess i‘ll have to wait for what i get, myairbot is doing a bit of a surprise thing here. you need to pick V5, item description says you‘ll get V6, then it‘ll be 6.something really. my guess is i‘ll get a V6.2
@iter, Am I missing something? The datasheet seems to indicate that PB6 can be assigned USART1_TX, but not RX. Is there something I’ve missed?
You are completely correct. My bad.
So basically, USART1 is useless for bidirectional applications. Its RX is always inverted and both of the TX options are non-inverted.
Ari.
OK. I’m feeling far less confused today, partly because I took a closer look at the code.
First, regarding RCIN on LED/WS2812 pad. SBus receivers should, indeed, work on this pin. No inverter or UART needed. Ardupilot does use software serial for this input when required. It may not be as efficient as an inverter and UART, but it has the advantage that just about any receiver can be connected to this pad. Of course, on V6.1, you could also use the SBUS pad since the inverted RX1 can’t be used for much else.
Second, I’ve confirmed through testing (on master) that Airbot’s, um, unfortunate, decision to leave out the non-inverted RX1 pad on V6.1 need not prevent us from having 2 full serial ports + I2C as we had on V6. By moving the compass/I2C to the PB9/CAM_C pad and the new PPM/PB8 pad, we free up TX/RX3 to replace the now crippled TX/RX1. This is convenient for wiring a GPS/compass as the new I2C pads are next to TX/RX6.
I’ve made some changes to the hwdef.dat file (in addition to the feature @vierfuffzig added) and built and tested the result with BRD_ALT_CONFIG=1 and serial 1 disabled. My compass, GPS, and telemetry all work as expected.
@iter , I’m guessing you have no trouble building your own firmware. Let me know if I’m wrong and let us know how this works for you.
Here are the changes I’ve tested:
diff --git a/libraries/AP_HAL_ChibiOS/hwdef/OmnibusNanoV6/hwdef.dat b/libraries/AP_HAL_ChibiOS/hwdef/OmnibusNanoV6/hwdef.dat index 71678ee7a3..47dd965f37 100644 --- a/libraries/AP_HAL_ChibiOS/hwdef/OmnibusNanoV6/hwdef.dat +++ b/libraries/AP_HAL_ChibiOS/hwdef/OmnibusNanoV6/hwdef.dat @@ -1,6 +1,6 @@ # hw definition file for processing by chibios_pins.py # Omnibus F4 Nano V6 only -# with F405 mcu, mpu6000 imu, bmp280 barometer, 7456 series osd, no flash log storage +# with F405 mcu, mpu6000 imu, bmp280 barometer, 7456 series osd, flash log storage MCU STM32F4xx STM32F405xx @@ -17,10 +17,10 @@ FLASH_SIZE_KB 1024 FLASH_RESERVE_START_KB 64 # order of I2C buses -I2C_ORDER I2C2 +I2C_ORDER I2C2 I2C1 # order of UARTs -SERIAL_ORDER OTG1 USART1 UART4 USART6 +SERIAL_ORDER OTG1 USART1 UART4 USART6 USART3 #adc PC1 BAT_CURR_SENS ADC1 SCALE(1) @@ -40,9 +40,20 @@ PA6 SPI1_MISO SPI1 PA7 SPI1_MOSI SPI1 # note that this board needs PULLUP on I2C pins +# TX/RX3 pads PB10 I2C2_SCL I2C2 PULLUP PB11 I2C2_SDA I2C2 PULLUP +# PPM/PB9 pads +#PB8 CAN1_RX CAN1 GPIO(54) +#PB9 CAN1_TX CAN1 GPIO(55) + +# use RX3 / TX3 pins as USART3 (= SERIAL4) and I2C on in BRD_ALT_CONFIG=1 +PB10 USART3_TX USART3 ALT(1) +PB11 USART3_RX USART3 ALT(1) +PB8 I2C1_SCL I2C1 PULLUP +PB9 I2C1_SDA I2C1 PULLUP + # SPI2 for flash PB15 SPI2_MOSI SPI2 PB14 SPI2_MISO SPI2
that‘s great news brad!
I should be able to build this locally. The hardware is with my friend now, but I can have it here in a day or two to test. Are you on a particular branch in the repository that I can check out? I want to make sure we’re working from the same configuration.
Ari
I’m currently testing on the tip of master. I’ll probably move back to the Copter-4.0 branch to reduce risk before I fly, though. I’m not sure the alt-config stuff is supported there, but the changes would be similar.
I do still have some questions about the V6.1 SmartAudio/TX5 and CameraControl pads.
I think PB9 was labeled Cam_C on the V6 board, but it doesn’t seem to be the same as CameraControl pad on V6.1. SmartAudio was PA2 on the V6 board, but it didn’t seem to buzz out when I checked on V6.1. I suspect it connects through a resistor, perhaps it also did on V6, but I haven’t confirmed this yet.
We should make these pads available for something.
I’d also like to add alt-config support for CAN Bus on PB8 and PB9, but when I tried, it didn’t compile so I must have missed something.
–Brad
Maybe you can make branch, or I can, so we’re testing the same thing.
Ari.
Did anyone test OSD yet on the V6.1 board? I connected a camera and transmitter today and I’m getting just the bare camera signal passed through with no OSD text at all. I tried both master and the released V6 4.3 firmware. This works on V6. Unless I’m missing something, they must have changed something they didn’t mention in the change notes.
I buzzed out the signaling between the MCU and the OSD chip and everything looked the same as on the V6. Then, after double checking that the same firmware worked on one of my V6 boards, I powered back up the V6.1 board and OSD is magically working. I’m suspecting a bad solder joint was made to work by the pressure I put on them with the probe, but it’s also possible the board is bad in some other way. If it fails again, I’ll have to send it back, or reflow some of the pins.
There is one other strange thing though. They have ground off the label on the surface of the OSD chip package. I’m not sure what they are trying to hide, but two little bits of ink showing outside of the ground off area don’t seem match the label on the V6 chip. The photos on the getfpv page show a chip with the same label as the V6 version and not ground off. I consider this very fishy.
What’s strange is nothing from Airbot. I asked one of their retailers for a manual and they replied, and copied Airbot on the reply, saying they have asked for it and linked to their product page for it. Don’t understand this.
I’m not very surprised they are not responsive. I tried to order the V6 board from Airbot at the end of Feb when I started tinkering with sub-250g builds. Eventually I gave up and ordered from getfpv. Airbot didn’t bother to tell me it was not in stock until I asked them for shipping status two weeks later. After canceling my order, they said they would let me know when it was back in stock and I’ve not heard from them since.
Unfortunately, I have more strange things to report as well regarding the OSD. Apparently, what made it finally work (sort of work, the image is also shifted about 10% to the left) was having no video input signal. When I reassembled everything on the bench for one last check, it failed again. Turns out I can connect everything except the video wire from the camera. As soon as I connect a video signal, the OSD turns off. I can have OSD data or camera image, but not both. I tried switching aspect ratio and from NTSC to PAL. When the camera signal goes away briefly for the mode switch I see the OSD data, then when the video signal starts again, OSD is gone. Everything still works with the same firmware and settings on my V6 boards.
Given the ground-off label, I’m thinking they changed the OSD chip and don’t want anyone to know what the replacement was. And Ardupilot doesn’t make it happy somehow. I’ll try contacting getfpv and airbot, but unless this gets resolved quickly, I’ll probably investigate the long term availability of the Kakute F7 Mini V2 boards. It seems to have a lot more ports available.
I asked GetFPV customer support and they CCd me on an email to airbot and we went from there. PM me an email address and I’ll include you in the email thread.
Ari.
BTW, I’m still waiting for the hardware to get back to me so I can test the build.
Ari.
Well, I did get a response from Airbot (that’s admirable). The “manual” is the same image shown on at least one retailers site. Same line also “100% compatible”. Perhaps this is true for BF.
still waiting for my board. i do live a couple of 100 m away from airbot warehouse actually, but email correspondence is via china. i’m not 100% positive everyone at airbot has a precise concept of what board revisions they really do or don’t have in stock…
ok, got a board from a friend to test with as airbot didn’t ship yet.
- ws2812 pin takes RCINput as expected, working with PPM, SBus, CRSF perfectly well.
- TX6 / RX6 pads work perfectly well, default to SERIAL3 = GPS
- TX3 / RX3 pads work perfectly well, default to I2C, can be used as UART3 with above mentioned ALT CONFIG added to hwdef
- USART1, as expected due to changed inverter layout, does not work afaik can tell
so moving I2C to PB8 / PB9 and using TX3/RX3 as USART3 most likely is the best option to keep 2 full USARTs and one I2C on this board variant.
this hwdef has I2C1 on PB8 / 9 added, plus USART3 = SERIAL4 on RX3 / TX3 pads in BRD_ALT_CONFIG 1
compiled plane and copter firmwares with those changes, based on current master: https://github.com/vierfuffzig/Chibios-miscellaneous/blob/master/omnibusnanov6x_firmwares.zip
appreciate testing, with the obvious precautions.
@brad112358 adding CAN exceeds available memory by more than 11k, it just don’t fit unless disabling a noticeable set of other features. even after kicking chute, sprayer, mount, SMBUS and FUEL there’s still ~5.5k missing.
arm-none-eabi/bin/ld: region flash overflowed by 11116 bytes
2 Likes
I’m new on this thread, stumbled across it after receiving two of these v6.1 boards over the weekend. I’m curious if anyone has tried using f.port with the “new” inverters on uart6?
One comment on the above discussion about the split 5v, most FCs have usb in behind a diode so that not all the 5V devices are powered when only plugged in via usb. There will be a voltage drop across that diode which will make it appear like two seperate 5V supplies, but in reality, it’s one BEC but some devices are behind that diode.
Regards,
LitterBug
1 Like