OpenPilot

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OP-1740 UAVO_GetSetFunctionsTakeEnum - getting started
OP-1740 UAVO_GetSetFunctionsTakeEnum - getting started
Be done with my bad previous whole week, and be done with 15.02 hopefully.

Be done with my bad previous whole week, and be done with 15.02 hopefully.

OP-1821 Tricopter tail servo wrong speed on wizard
OP-1821 Tricopter tail servo wrong speed on wizard
OP-1821 Commit bug fix

Given more configuration control options one could certainly make this obey the rules that would then be in place.

Given more configuration control options one could certainly make this obey the rules that would then be in place.

Point taken with current working of configuration. However, the whole configuration of the receiver port on the revo is a bit fuzzy I believe. I think it needs a rethink, as the drop down box opti...

Point taken with current working of configuration.

However, the whole configuration of the receiver port on the revo is a bit fuzzy I believe. I think it needs a rethink, as the drop down box options do not cover all hardware capabilities on that port. My example above is just one case.
But yes, that is a separate issue.

It's a tricky one, as if that line is connected to the minimosd DTR line, it needs to be driven correctly or the OSD will malfunction. Therefore, even if the port is being used for Telemetry, and n...

It's a tricky one, as if that line is connected to the minimosd DTR line, it needs to be driven correctly or the OSD will malfunction. Therefore, even if the port is being used for Telemetry, and not the com-bridge, the config shouldn't change.

Having just checked https://wiki.openpilot.org/display/WIKI/Revolution+Board+Setup#RevolutionBoardSetup-Flexi-IO there should be no conflict as there are two telemetry options; "Telemetry" and "Telemetry+PPM", neither of which currently use pin 9, so it's effectively free to use for DTR.

What about cases when the receiver port USART is not being used as part of a comm bridge? In this case, DRT will be initialised and possibly upset any other configuration on that pin. For example, ...

What about cases when the receiver port USART is not being used as part of a comm bridge?
In this case, DRT will be initialised and possibly upset any other configuration on that pin.
For example, if one was using telemetry on the receiver port, and a motor on PC8.

OP-1837 Fixed a wrongly named config.

OP-1740: Force latest Pathfollower changes to use uavobj enums.

Merge branch 'next' into rvonlehe/OP-1740_UAV0_GetSetFunctionsTakeEnum

Conflicts:

flight/modules/PathFollower/inc/vtollandcontroller.h

flight/modules/PathFollower/vtollandcontroller.cpp

flight/modules/PathFollower/vtollandfsm.cpp

    • -10
    • +5
    /flight/modules/PathPlanner/pathplanner.c
    • -2
    • +18
    /flight/modules/Stabilization/innerloop.c
    • -180
    • +355
    /flight/modules/Telemetry/telemetry.c
OP-1849 Fix GCS HW Settings tab to only display receiver port com-bridge if available

OP-1489 Support programming/update of minimosd using USB VCP port
OP-1489 Support programming/update of minimosd using USB VCP port
Detailed instructions for port/OSD wiring and software procedure recorded in issue.

Detailed instructions for port/OSD wiring and software procedure recorded in issue.

OP-1849 Uncrustify

OP-1849 Support programming/update of minimosd using USB VCP port
OP-1849 Support programming/update of minimosd using USB VCP port
Uncrustified code pushed

Uncrustified code pushed

Interesting. The FLEXI has 10k pull-ups, while the MAIN only has a 10k pull-down on the RX line. I don't have one of these receivers to measure, but it looks as if the device may be passive in betw...

Interesting. The FLEXI has 10k pull-ups, while the MAIN only has a 10k pull-down on the RX line.
I don't have one of these receivers to measure, but it looks as if the device may be passive in between frames so the pull down on the MAIN port may be preventing the UART from properly detecting the START bit in the byte frame.

OP-1837 Uncrustify

ooh, true, i forgot to do that https://reviews.openpilot.org/static/nitx73/2static/images/wiki/icons/emoticons/sad.gif

ooh, true, i forgot to do that

I started out with only main port but i ran in to weird issues with signal levels. My USART reading was off the charts and totally fucked up. I was told there should be no electrical difference bet...

I started out with only main port but i ran in to weird issues with signal levels. My USART reading was off the charts and totally fucked up. I was told there should be no electrical difference between the two ports but looking at the schematic I can see that the main port has an inverter added and the flexi has pullups on tx and rx. I cant see that the Main port has any pullups.
https://www.dropbox.com/s/jxzxbiivh2d2376/BitScope%20DSO%202.6_230.png?dl=0
https://www.dropbox.com/s/vx2lnu9n40dw5fs/BitScope%20DSO%202.6_231.png?dl=0
The above images are from my scope. Thhis is the signal from the receiver before and after connected to the Main port. Connecting to the Flexi port did not show this issue at all.

Maybe it is the Multiplex receiver that has an issue, but I had to move to Flexi to even get any data in that was readeable.

uncrustify

uncrustify

Is there any reason to limit SRXL to only the FLEXI port? Why not MAIN port as well?

Is there any reason to limit SRXL to only the FLEXI port? Why not MAIN port as well?