Thread Tools
Jan 02, 2019, 04:20 PM
Build more, websurf less
FlyingW's Avatar
When you use five channels, you get resilience against any one of them suffering interference. The ULRS automatically switches among the chosen channels.
Sign up now
to remove ads between posts
Jan 03, 2019, 12:59 AM
Registered User
Thread OP
It should work with several channels too, check with the spectrum analyzer and try different channels combinations.
Jan 03, 2019, 03:23 AM
Registered User
Okay, good to know! Thank you FlyingW and flipflap for your help! I am glad that it works now! Now the only thing I have to figure out is why the telemetry data is not sent to the yaapu telemtry script!

btw: I found out that my TELEM1_BAUD still was on 57, so I changed it to 19 but then no Mavlink data gets received by the ULRS. If I change it back to 57, it works again. How can this be?
Jan 03, 2019, 05:54 AM
RC fanatic
Quote:
Originally Posted by KadaverJoe
Okay, good to know! Thank you FlyingW and flipflap for your help! I am glad that it works now! Now the only thing I have to figure out is why the telemetry data is not sent to the yaapu telemtry script!

btw: I found out that my TELEM1_BAUD still was on 57, so I changed it to 19 but then no Mavlink data gets received by the ULRS. If I change it back to 57, it works again. How can this be?
Where you say, "no Mavlink data gets received by the ULRS", where are you looking to see no data? If you look in ULRS CC app on the Stats screen (at least from memory I think its this screen/tab), do you see Mavlink messages received in there? Remember, Mission planner must still connect to the UART on the Tx using 57600baud, even though the flight controller talks to the UART of the ULRS Rx at 19200baud.

FlipFlap - I don't see any details on the 'Stats' screen/tab on your CC description on this page: http://www.itluxembourg.lu/site/ulti...tatus_overview - maybe needs some info added to complete the CC manual.
Jan 03, 2019, 06:37 AM
Registered User
Quote:
Originally Posted by athertop
Where you say, "no Mavlink data gets received by the ULRS", where are you looking to see no data? If you look in ULRS CC app on the Stats screen (at least from memory I think its this screen/tab), do you see Mavlink messages received in there? Remember, Mission planner must still connect to the UART on the Tx using 57600baud, even though the flight controller talks to the UART of the ULRS Rx at 19200baud.

FlipFlap - I don't see any details on the 'Stats' screen/tab on your CC description on this page: http://www.itluxembourg.lu/site/ulti...tatus_overview - maybe needs some info added to complete the CC manual.
Hi athertop,

I was looking on the main page of the ULRS CC page on the bottom left, where is the telemetry overview. There I can the the Downlink-bar is white and Mavlink packets are received. Also I see it at the upper right corner, where the Serial overview is. Mavlink is blinking there. If I change the SERIAL1_BAUD in my Pixhawk 4 to 19, nothing happens there anymore.
Jan 03, 2019, 07:28 AM
Registered User
Thread OP
ULRS does only support 19200 on plane side, so if it works it's at 19200 bauds.

Remember that pixhawk only takes the baudrate changes on reboot, I wonder if this can be related to your observations. Try with a reboot of the FC after changing the baudrate.

https://docs.px4.io/en/peripherals/s...iguration.html
Jan 03, 2019, 07:39 AM
Registered User
Quote:
Originally Posted by flipflap
ULRS does only support 19200 on plane side, so if it works it's at 19200 bauds.

Remember that pixhawk only takes the baudrate changes on reboot, I wonder if this can be related to your observations. Try with a reboot of the FC after changing the baudrate.

https://docs.px4.io/en/peripherals/s...iguration.html
I rebooted it every time I changed the baudrate
Jan 03, 2019, 03:23 PM
Registered User
CHOYADO's Avatar
Quote:
Originally Posted by flipflap
Hi Choyado,

For the point 1., where after monthes the firmware gets corrupted, and is working fine after a reflash : this is specific to the OrangeRX modules and can be solved easily.

In case of too low voltage, a micro controller can start acting erratically, including jumping to random instructions including running bootloader code when it's not expected. In this case the firmware can get corrupted.

The protection against this is called the BOD (brown out detect), but on OrangeRX modules it's not activated by default.

It's possible to activate it by changing a fuse setting as described here : http://www.itluxembourg.lu/site/hobb...fuse-settings/

Other modules such as ULRS Minis have the BOD activated by default.

Check the OrangeRX FAQ for other recommendations regarding these modules : http://www.itluxembourg.lu/site/hobb...z-modules-faq/


For the point 2., servo jitter is caused by RF signal causing interference on the servo wire. It's not a common issue with ULRS as you can see in this thread, and the most common cure is to use a capacitor between the servo signal wire and ground.

If another servo brand is less sensitive to this, you should be good trying several capacitor values. In this case small capacitors will work better than large ones.

Apart from this try moving the antenna or replacing the antenna (never use the stock antennas or monopole antennas).

Regarding fast servo movements, it's related to the refresh rate : it's slightly slower than a normal 2.4GHz system but it provides full telemetry. If that's a problem you can use 8 channels and will get faster refresh rate because a full 16 channels PPM frame is already 40 ms just to read.


For the 3., if you've got RSSI working on Pixhawk I don't know why it wouldn't work on Qgroundcontrol. Check the RSSI as RC channel configuration here : http://www.itluxembourg.lu/site/ulti..._a_servo_value
This is the second time this has happened. I have a habit of changing the modules in the back of my Taranis with the power off. Then I turn on the transmitter and change the model selection. I did the exact same thing the last time this happened. Something about that process must do something to the Orange RX module. The model that I switched from both times was using the external module in R9M mode. This time I was at the flight field ready to fly so it was especially frustrating. Unfortunately now I can't seem to get the TX module to recover. I have re-flashed it and I get confirmation that the flash was successful but when the module is turned on I only get a red indicator light...sometimes it flashes...sometimes it is solid. ULRS CC will connect to it but I can't configure any parameters and I don't get any status information.
Jan 03, 2019, 03:34 PM
Registered User
Thread OP
If it's flashed correctly, but no status in ULRS CC it's the RFM module that has a problem.

I don't know if you changed the BOD fuse yet http://www.itluxembourg.lu/site/hobb...fuse-settings/ ?
Jan 03, 2019, 04:08 PM
Registered User
CHOYADO's Avatar
Quote:
Originally Posted by flipflap
If it's flashed correctly, but no status in ULRS CC it's the RFM module that has a problem.

I don't know if you changed the BOD fuse yet http://www.itluxembourg.lu/site/hobb...fuse-settings/ ?
I haven't yet. I do not have a USBasp. Can the programming be done with an arduino?

How are the connections made to the module?
Last edited by CHOYADO; Jan 03, 2019 at 04:52 PM.
Jan 03, 2019, 05:05 PM
Registered User
Thread OP
Of course the best is to use an ULRS Mini which has already the BOD set correctly, and protection resistors.

What happens here is probably an issue related to a low voltage at some point, as the BOD isn't active it triggers code anywhere including code from the bootloader. It can then by misluck modify the main firmware, that's why you had to reflash it. It's also possible that it outputs some bad voltages on the pins of the atmega, potentially destroying some RFM IO pins.

All of this is sorted out in the ULRS Mini modules. But if you want you can use an USBasp programmer to flash the fuses of an OrangeRX. I wouldn't go into the trouble of programming it with an arduino, even if that's possible.
Jan 05, 2019, 06:22 PM
Registered User
All works but no any buzzer sound. Is it always connected to Atmega 328p pin 12 (Arduino D8 ) ?

I use OrangeRX 100 mW receiver as TX mockup. PPM and Mavlink works correctly, analog RSSI shows 0...3V according to -95...-10 dB, but no any signal on pin 12 at any RSSI level. Latest firmware installed. What can be wrong ?
Jan 06, 2019, 10:16 AM
Multirotors are models too!
Flipflap,

I remember you mentioning there was an open source version of this firmware that people could tinker with. I looked, but didn't see it mentioned in this thread,but it is a huge thread. Do you have a link to the open source version?

Thanks
Latest blog entry: Test entry
Jan 06, 2019, 01:46 PM
Registered User
Thread OP
Hi Rusty, it's here : https://github.com/tadam777/Projects
Jan 06, 2019, 01:56 PM
Registered User
Thread OP
Quote:
Originally Posted by RD00
All works but no any buzzer sound. Is it always connected to Atmega 328p pin 12 (Arduino D8 ) ?

I use OrangeRX 100 mW receiver as TX mockup. PPM and Mavlink works correctly, analog RSSI shows 0...3V according to -95...-10 dB, but no any signal on pin 12 at any RSSI level. Latest firmware installed. What can be wrong ?
Hi,

The OrangeRX 100mW RX doesn't have a buzzer, and the buzzer signal isn't available on the 100mW boards.

Notice that the pin 8 you're referring to for the buzzer is only valid for ULRS Mini boards. On the OrangeRX 1W TX it's on the pin 14 (Arduino pin D10). But nothing on the 100mW RX.

If you're designing a new board I'd recommend to start from the ULRS Mini schematic : http://www.itluxembourg.lu/site/apmp...mate-lrs-mini/


Quick Reply
Message:

Thread Tools