Closed lancaster100 closed 6 years ago
Did you try to activate serial rx of all UARTs? (one at a time) and pick sbus in the configuration
@lancaster100 What serial port is your receiver connected to ?
Hi Mafel Yes, only have UARTS 1,3 and 6 Tried all three individually and checked checked sbus in config Still no movement with sticks!
@lancaster100 Please check on which of the UARTs your receiver is connected
Hi shellixyz Serial RX is set UART1 I have tried UART3 and 6 Receiver is connected to first pin row on board, ie PPM/SBUS
@lancaster100 I don't own this board but from the docs the RC pad seems to be connected to UART3 via an inverter. Please try to flash this and enable serial RX on UART3: inav_1.8.0_OMNIBUSF4V3_u3i.hex
shellixyz Ok thanks I will try this hex file My board is F4 Pro V2.1 not V3 - does that matter?
Hi Shellixyz SBUS NOW WORKING !!! with serial RX on UHART6 Many many thanks regards Hans
Hi Shellixyz With Serial RX on UHART6, the GPS sensor is now displaced from that port I have tried connecting it other UHARTs but can only get a partial connection, ie red GPS icon with UHART3 This does not get a GPS fix so I cant move forwards Any thoughts on solution? regards Hans
@lancaster100 If your RX is connected to UART6 then the last build from #2570 should be working as well because the only difference is that I enabled a potential inverter on UART3. The GPS to UART link doesn't need an inverter so it doesn't look like it is linked to this issue.
Shellixyz So should I flash OBF4V3 hex from the last build from 2570 and set serial RX on UART3 and set the GPS back on UART6 ?
@lancaster100 You should flash this one and leave your GPS on UART3 and SBUS receiver on UART6: inav_1.8.0_OMNIBUSF4V3.hex
Hi shellixyz flashed OBF4V3 SBUS working on URT GPS no fix , toolbar red icon only on UART1 and UART3 I have previously tested the GPS unit with original firmware 1.8 OBF4PRO 2017-11-1 and it was working properly with fix and map Any suggestions for the GPS fix
Hi shellixyz With original firmware, the GPS (UART6) only worked when the SBUS lead and receiver(UART1) was disconnected
UARTs are independent. What you said makes me think it is a hardware issue. Unfortunately I don't have this FC to try to reproduce it. Also are you certain you are using the right target for your board ? Your receiver can only be connected to UART1 if UART1 has an inverter and in this case you should use the OMNIBUSF4PRO
target.
Hi shellixyz When flashing both online and local firmware I have used OBF4PRO as the target in all cases My very first flashing with the listed hex file (1.8 OBF4PRO 1-11-17) failed to give SBUS on UART1 but also when the X6R and lead were pulled off the FC , the GPS works normally on UART6
shellixyz Comments on RCGroups refer to removal of jump resistors with positive results, ie remove SBUS resistor to get PPM to operate (Note V3 board has bridge option between PPM and SBUS) The RCG suggestion is that the common link is pulling down the signals and removal of the appropriate resistor stops this interference Does that make any sense?
when the X6R and lead were pulled off the FC , the GPS works normally on UART6
This tells me your receiver and GPS were probably connected on the same UART otherwise I can't see how disconnecting your receiver would allow the GPS to work.
Also for the SBUS receiver you should use the RC input on your board. It is tied to one of the UARTs. UART1 probably and you need the inverter present on this UART for the FC to be able to decode the SBUS data unless you hacked your receiver to get the uninverted SBUS signal.
the common link is pulling down the signals and removal of the appropriate resistor stops this interference
It makes sense. Because UART1 is tied to the inverter there is a conflict if you try to connect something else to it but you should use it for the SBUS receiver then no need to remove anything. But remember you should not connect directly to UART1 but through the RC (PPM/SBUS) input pin. You only need to unlink the UART from the inverter if you are using PPM and need a third UART for something.
I asked a friend who has a quad with an Omnibus F4 PRO and can confirm the RC input is linked to UART1. He uses SBUS on UART1, GPS on UART3 and S.Port telemetry on UART6. I can't confirm it is working with iNav though because he is using Betaflight.
From reading the forums, Betaflight can cope the FC board circuitry but INAV cannot
I have definitely not been putting more than one function on a single UART so I too am confused by this linkage between GPS and Serial RX Blue Falcon videos on YouTube refer to a cross linkage between the PPM/SBUS pin and other ports on the board but this is beyond my knowledge Could removal of the PPM jumper resistor provide a solution?
I have contacted Banggod and my last resort is to seek a refund for both boards as they are not performing the functions as advertised
You only need to remove the resistor if you want to use PPM at the same time as UART1.
I have yet to get SBUS working on UART1 with any of the available firmware online or local Guidance has stated that GPS should be set on UART6 - this works ok when nothing else is connected but will not work on any other UART When the firmware is chosen such that SBUS functions on UART6 - is there an alternative UART or port that could then drive the GPS?
The GPS can be connected to any UART. If SBUS is working on your board on UART6 it means there is an inverter on UART6 or your are directly feeding the uninverted SBUS signal to the FC. Where does your FC come from ? Does it have a current sensor (a big resistor on the power input) ? I guess you are using standard inverted SBUS and if this is the case you should not be able to make it work on UART6 with the OBF4PRO target unless there is an inverter on this UART and that it is activated somehow.
You can check with a multimeter which of the UARTs have an inverter and which one is connected to the RC input. You can get the datasheet for your MCU there: STM32F405 datasheet. You can see the pin mapping page 41. When the marking dot on the chip is on the top left corner the first pin is the one on the top of the left pin row.
If there is continuity between the FC pad and the MCU pin it means there is no inverter. If there is an inverter it only on the RX side.
If you don't specifically need a board with a F4 MCU I would advise you to use a F3 board. You won't have any inverter problem because they are intergrated on the F3 MCU.
In any case my friend confirms there is only one inverter on the Omnibus F4 Pro and it is on UART1 so it is really weird if you really got the same board that the inverted (meaning directly from the receiver) SBUS signal would be recognized on UART6. Did you connect the receiver on the RC input pad or on the UART6 RX pad ? It would be great if you could post a front and back picture of your board.
Also the only explanation I can see for two linked UART ports is that you have a solder bridge somewhere between the ports RX lines.
hi shellixyz thanks for the helpful reply my FC is the F4PROv2.1 with the current sensor I will check out the inverters with a meter as you suggest As you say the problem is related to signal inversion I understand my RXs (X6R &X8R) already have inverted SBUS signals and UART1 has an inverter I have two F4PRO v2 boards and the same problem with each one, so its not a solder bridge or random fault It seems likely that there are various clones on the market with variations because my F4PRO (Banggood)is behaving differently from Matels and Matts I notice in github F4 info that the target should be OBF4SD-should I try that? My aim now is to get the GPS wired in somewhere on the board that will accept its TX,RX,SDA & SCL wires
Sent from my iPhone
On 12 Dec 2017, at 17:54, shellixyz notifications@github.com wrote:
Also the only explanation I can see for two linked UART ports is that you have a solder bridge somewhere between the ports RX lines.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
shellixyz I will send pictures of the FC board I understood your local hex files changed the inverter locations so thats why my serial RX now works on UART6
Sent from my iPhone
On 12 Dec 2017, at 17:52, shellixyz notifications@github.com wrote:
In any case my friend confirms there is only one inverter on the Omnibus F4 Pro and it is on UART1 so it is really weird if you really got the same board that the inverted (meaning directly from the receiver) SBUS signal would be recognized on UART6. Did you connect the receiver on the RC input pad or on the UART6 RX pad ? It would be great if you could post a front and back picture of your board.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
shellixyz I connected the RX to the pins on the RC input pad I dont know where the UART6 RX pad is! I will send photos thanks hans
Sent from my iPhone
On 12 Dec 2017, at 18:51, Hans Leatherby hansleatherby@gmail.com wrote:
shellixyz I will send pictures of the FC board I understood your local hex files changed the inverter locations so thats why my serial RX now works on UART6
Sent from my iPhone
On 12 Dec 2017, at 17:52, shellixyz notifications@github.com wrote:
In any case my friend confirms there is only one inverter on the Omnibus F4 Pro and it is on UART1 so it is really weird if you really got the same board that the inverted (meaning directly from the receiver) SBUS signal would be recognized on UART6. Did you connect the receiver on the RC input pad or on the UART6 RX pad ? It would be great if you could post a front and back picture of your board.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I notice in github F4 info that the target should be OBF4SD-should I try that?
Yes for Betaflight OBF4SD should be the right target.
I understood your local hex files changed the inverter locations so thats why my serial RX now works on UART6
Yes my mod enables an inverter on UART6 to be controlled via PC8
shellixyz With the OBF4V3 firmware flashed, the SBUS RX works on UART6 I tested the continuity between the MCU pins 38, 43, & 52 and the PPM-SBUS signal pin on the RC pad Is that the correct hook up? There was no continuity in each case What does this mean?
Thats looks normal the PPM-SBUS signal pin is only connected to one UART through an inverter. So no continuity in all cases. What you should test is the continuity with the RX pads for each UART (UARTx RX pad to UARTx RX pin). You should see continuity in all cases because I'm expecting no inverter on any of them through the RX pads.
OK Do you mean each signal pin on the RC pad to each of the 3 UART pins on the MCU
shellixyz I attach photos of my board
Its from Banggood : BF3.2 Omnibus F4 V2.1 Flight Controller STM32 F405 MCU Integrated OSD Built-in 5V BEC Current Meter
Specs Firmware: betaflight_3.2.0_OMNIBUSF4SD Input voltage: 2-6S SCM: STM32 F405 MCU Sensor: SPI Sensor ICM-20608 Barometer: BMP280 Slot: standard SD card slot BEC: 5V/3A
Features: STM32 F405 MCU, Runs betaflight_3.2.0_OMNIBUSF4SD, could run faster loop time. Using F4 MCU controls OSD over SPI bus in DMA mode. OSD Configation has been included in Betaflight GUI. Built-in 5V/3A BEC. Built-in galvanometer LC filter
It seems there are variations on this board - some have SBUS-PPM resistors My board has an ic at this location Also I notice from the features that the target is OBF4SD - I have not tried this Can you point me to this target hex file?
Do you mean each signal pin on the RC pad to each of the 3 UART pins on the MCU
I was talking about pads but there is no pad for the UARTs on this board it uses connectors.
The OBF4SD target is for Betaflight. The target names are not the same between BF and iNav.
In the following pictures:
You should test continuity between the dark blue and cyan blue points with the same number. Two of the pairs should be connected directly together. The one without continuity is the one with the inverter in between. The dark blue pin of this pair should be connected to one of the pins of the transistor marked in red and the cyan blue pin should be connected to another one of the 3 pins of the transistor.
EDIT: I used pinouts from https://www.banggood.com/BF3_1_5-Omnibus-F4-V2-Flight-Controller-STM32-F405-MCU-Integrated-OSD-Built-in-5V-BEC-Current-Meter-p-1143258.html
Shellixyz I have solved the GPS problem J10 end pairs of pins link to RX6 (UART6), TX6 (UART6)and RX3 (UART3), TX3 (UART3) I guess this is why the GPS interferes with the SBUS RX when set on UART6 I have taken out the compass wires from the GPS (SDA & SCL) and connected TX to RX3 and RX to TX3 The GPS now operates fully with map fix on UART3 whilst the SBUS operates on UART6 without interference. All servo outputs are also working normally The compass function is not hooked up This is operating with firmware ODF4V3, target OBF4PRO regards Hans
What is J10 ? I don't really understand what you did but if it is working that's the main thing.
If you want to use the compass and SBUS at the same time and that the SBUS-PPM input is connected to UART6 RX then you will have no choice but to connect you compass to I2C/UART3 and your GPS to UART1
shellixyz Yes that will work Is UART1 connection for the GPS on TX1, RX1 on J5 ?
I have attached a picture of the V3 board that shows all the J connectors
Shellixyz Thanks for the intermediate email - I missed it before fixing my problem I now understand where the UART pins are located Just one thing - I dont believe the pads you circled in green are the SBUS - PPM selectors - there are no selectors on the this version of the F4 board The pads you have circled in green are marked 5V, RAM and VCC They provide the option of 5v filtered or unfiltered to the camera or VTX RAM thro holes on J16 and J17 If this option is used, only one bridge each way from the RAM pad should be used - two bridges will fry the board Many thanks for the help regards Hans
Just one thing - I dont believe the pads you circled in green are the SBUS - PPM selectors
You are right it is for the camera system power source. I was not sure because it is not specified in the BG pictures.
Is UART1 connection for the GPS on TX1, RX1 on J5 ?
Yes it is
Shellixyz Thanks again I think I'm done now
Glad for you it is working :)
So, can we close this one if solved?
Yes I will close it thanks guys for your great support
I seem to hit the same problem as lancaster100 in getting my X8R and GPS to connect to Flip32 F4V3 Omnibus( from RTFQ). This is the board I have; http://www.readytoflyquads.com/flip-32-f4-omnibus-v3
I have tried all the different versions of the firmware (including the one mentioned here) in addition to going back to the BataFlight firmware listed on the RTFQ website.
The receiver is bound and I have verified that the SBUS is working along with the PWM outputs (which of course I do not use).
I have tried turning on ports, some will reset back to off after I do the Update and Reboot sequence and sometimes the channel bars will disappear in the radio section. I then have to close the CLI and start again.
If I set the receiver mode in the tools tab to SERIAL-BUS/ BUS and then come back it will be set to off again.
I have verified all headers are adequately soldered and nothing is bridged and all wiring plugged in correctly.
The camera in and video work fine as well as the OSD.
I have removed all accessories (GPS, Camera, VTX) from the board but does not help.
Feel like I have overlooked something simple but am totally stumped.
Any suggestions would be appreciated.
@trivejb It doesn't sound like you have bridged the SBUS pads. https://www.youtube.com/watch?v=ZFVIbU4aJvo He does a good job explaining. You just don't want to bridge all 3 pads, just the Sbus to center pad.
Just bought a bunch of the V3 Pros cheap from China. Sorta glad they are taking a while to get here while I search and watch all the videos on them, so I am not as frustrated when I am trying to get them to work trying to get things done.
Adding picture. Green Pads.
@moetop Discussion about @trivejb's issue has moved to #2589
moetop, Thanks for your reply and that is something that caught my eye. RTFQ states in their instructions that SBUS is internally bridged and I did check to verify that there is continuity between the center pad and the SBUS and I also bridged with a flat tip screw driver and that did not help. Even if the is not connected you should be able to make the settings stick. My problem is nothing sticks and the FC behaves radically. I believe it is a bad card and I have contacted RTFQ.
From the instructions:
"_NOTE: S-bus is built in default selected. If you want to use PPM. you need to CUT the track, then bridge the PPM pad, even the Sbus pads do not look "bridged" with solder.but they are connected inside the board, no bridging is needed for a super clean look. OMNIBUS F4 V3 header through-hole is connected to UART6, not UART1 like all others. DSMX receiver is UART1 port"
OK... NEWBIE problem, as I knew it would be. NOT A PROBLEM WITH THE BOARD! When trying to make UART 6 active I did not understand what "MSP" was (and still do not) and was trying to turn it on. I then found a listing on Banggood showing a screen print of the port settings and have now only set Serial RX on and receiver to SBUS and now have the receiver working. Moved GPS connection to UART 1 and it works. I think that RTFQ had RX/TX marked in reverse. Mag was staying RED and not sure why but should be able to figure it out. Thanks for all the input and sorry for the confusion
Trivejb Did you fix the GPS ? If you are connecting the compass wires sca and sdl, check that they are not in conflict with another function on UART3
Hi Mafel You closed the last issue when your board worked - but my problems still persist I flashed the local hex file as suggested and it was ok I also repeated the set up settings in INAV just in case - but still no response on output bars in the INAV receiver tab using SBUS and X8R ( all connected and bound ok) I notice on Matts video he has set the mode switches on the Taranis prior to setting up the receiver in INAV I am using 9XExtreme and Ersky9X, I have simple channel settings on AETR but my mode switches are different from the Taranis switches - I guess its unlikely that the mode setup is preventing the SBUS from responding? I understand its a signal invert/pin issue Any ideas?